Difference between revisions of "System Architecture, the strategy to complex implementations"

From RogueBasin
Jump to navigation Jump to search
m (Added newline)
(The article is not well written, and it seems like it's bad spam text generated from a neural network.)
 
(6 intermediate revisions by one other user not shown)
Line 1: Line 1:
Imagine you are making a game and you have an item that allows you to switch health with a monster. On level 100 you encounter the Lich King with negative health that takes damage from healing potion. What exactly is supposed to happen when you switch health with the Lich King? Will the player die?, will the Lich Kind die? or will the Lich King suddenly become a King and the Hero will become the undead Lich Hero with negative health?
This is what system architecture solves or is trying to solve, a strategy to deal with complexity. If you don't have any system architecture you will end up building the next NetHack that has required 20+ year of development to fix every possible odd quirky use of every item and spell.<br>
<b>When selecting system architecture remember that feature can always be added later while time spent on useless features is time lost forever</b>.


== Gunshot Coding ==
Code by trial and error (or slugger coding). This means coding without a plan which is good if you don't need to create a story. you write some code test it bug fix, write a bit more and so on. The game can become quite strange when coding by trial and error. [[DoomRL]] and the original Rogue are designed like this. It is recommended to avoid this style of coding if the story in the game is important as it is very difficult to predict play style and how the actual world will become. 
== 2D Rooms ==
In this architecture the game consist of a number of rooms with some variables that connect each room. The roguelite "binding of Isaac"[https://bindingofisaacrebirth.gamepedia.com/Binding_of_Isaac:_Rebirth_Wiki] uses this architecture as does the game [[Elona]]. The architecture is heavily used by JRPGS and is probably the model that is found most frequently in RPGs. The problem and benefit with this architecture is that interaction between rooms are limited, random generation of contents can be an issue. The architecture allows easy creation of overhead maps, special physics, combat screens and many other game features. This type of architecture is very good for creating interesting stories. '''This architecture can be considered best by test'''.
== Cellular Automata ==
The world consists of small cells (or atoms) and the world is described through the interaction of these cells. Very much contents can be created with very little effort using this architecture. Spelunky is an example of this architecture, tough the original game of this architecture is Boulder Dash[https://www.youtube.com/watch?v=FiEVfa1OK_o] for 8 bit machines. The game architecture allows easy modeling of falling stones, traps, rolling boulder, flying projectiles and other physical game elements. The architecture simplifies implementation by describing complex interactions using multiple simple mechanics and game cells (or atoms).
== Woke Architecture ==
There is a modern saying go woke go broke. Don't use politics as your system architecture, your game will fail badly and nothing will be created and the horror you make will be avoided by all human beings. The only game which was 'woke' and actually successful is the board game monopoly that was created to critique capitalism. Don't expect to make the next monopoly unless you actually do some research of actual social subject. If you do the research there is still nothing that ensures that the research will define a well behaving system that can be used to create a rogue game. Avoid this architecture unless you have some real reason to make a "woke" game.
The game undertale[http://undertale.wikia.com/wiki/Main_Page] is not a game of this type as the architecture is based on independent 2D rooms. For an actual none rogue woke game built by a small team see[https://en.wikipedia.org/wiki/BattleTech_%28video_game%29] which focuses heavily on so called virtue signaling (tough battle mechanic is not woke).   
== Object Oriented Architecture ==
Not to be confused with Object oriented programing or what is called object oriented system architecture. Object oriented programming is sometimes considered a system architecture, however things are a bit confused in the professional world of computing when talking system architecture. Actual system architecture in this context is an Object Oriented Architecture that copyies your Live Action Role-Playing Game, or copying some real life events. The point is that if you copy your LARP or RPG sessions you will, with some computing skills, have the ability to implement exactly that LARP or RPG session.
== No Architecture ==
This what you do if you go to a conference and implement the system architecture ideas you hear about. The problem is that many of these conferences discuss low level system architecture that you don't need to care about when making a Rogue game using languages like Python, (Javascript and other languages solve those issues). This is worse than gunshot architecture as you believe that you have an architecture while in reality you don't have an architecture that is sufficient to make a rogue game.
It is a problem with professional coders with bad habits and less with amateurs (probably). Avoid getting lost in coding details when thinking system architecture. 
== Random Number Generator Architecture ==
This is an architecture where every problem is phrased as being a choice with different types of probabilities. An example of this architecture is Darkest Dungeon[https://darkestdungeon.gamepedia.com/Darkest_Dungeon_Wiki]. The architecture focuses on successive random choices that are selected one after another. It has the advantage of allowing the creation of a complete game with very little code and mechanical parts.
----
== Alternative Architectures ==
----
Below are some more unusual architecture that could be used but are not recommended unless you are making a very unique rogue game. Also included are designs and architecture influencing decisions.
== Vector Room ==
There was a game called Harpoon using vector maps with variable clock times. This game was very realistic warfare simulator. While no roguelites exist using vector based maps with variable clock times there certainly is a few rogulites focusing on warfare that could benefit from this architecture.
== Code Generation ==
In the future people don't code machines, machines code humans. At the very least there is research in generating code by automatic means and this could allow generating your roguelite using an advanced code tool. This one is more for researchers than game makers.
== Visual Novel ==
You create a visual novel and then add roguelike elements to your visual novel. There are a number of roguelikes of this genre but as a system architecture it is incomplete as it cannot describe how to create the roguelike parts. Probably a game like Omega Labyrinth Z should be included in this category.
It is recommended to include visual novel elements into your game instead of the other way around.
== Assembler Architecture ==
This is an old way of writing code from the days when code was written in assembler. For instance the game Cadaver[https://en.wikipedia.org/wiki/Cadaver_(video_game)] is an example of this type of game as is Princess Maker[http://princessmaker.maison-otaku.net/Pm1stats.htm]. This is an architecture where you write your own script language to simplify game mechanics. The aim is to write a script language that is simplifies the job of creating the game sufficiently to solve an architecture problems. It is possible to write script languages within script allowing any amount of complexity in the game. This architecture is basically abandoned as high quality languages exist that can be integrated into other languages easily (like Python,JavaScript, Scheme, Forth).   
== Orthogonal Design ==
This design can be found in the original Doom and Super Mario Brothers. It is a design principal where every item is different from every other. See discussion of doom[https://www.youtube.com/watch?v=yuOObGjCA7Q] for an in depth description of this method. Beside being primarily a design principal and therefore not solving all architecture problems it is also very poor choice for modern games as the design method was create good games on resource starved hardware. The design method also creates very strange games, neither hunting demons with shotguns or having a plumber saving princesses makes for a convincing story. This design principal is very difficult to follow when using a random number generator.
== Minimal Design ==
The modern way of designing game with an old history going back to games like Boulder Dash[https://www.youtube.com/watch?v=FiEVfa1OK_o](which is also a cellular automata architecture). As it is mostly a design method it cannot solve all of you system architecture questions need but can reduce the complexity of the game. The best modern example of this design philosophy is Dark Soul. The principle focuses on maximising the use of every game mechanic, tough it can be viewed as lazy. The principal goes great with random number generators. 
== Model View Controller ==
Not an architecture by itself but an influential design pattern used very frequently in applications. This is in principal a more general version of the 2D Room architecture. The principal here is the state logic of the application is not part of the GUI. See the discussion[https://www.youtube.com/watch?v=1IsL6g2ixak].
== Total Quality Management ==
This is a famous organisational method that could be used to implement system architecture. See a discussion here[http://blog.bid-org.com/toyota-motors-the-king-of-total-quality-management/] about the method. The method increases response speed to reduce quality issues in your product or service drastically. This method could be useful for those trying to sell an online roguelike that needs maintenance or a rogue developed iteratively with input from players.
== Soviet Military Machine Architecture ==
Or any other method used to construct military machines by governments that no longer exists the last hundred of years. While computing is much more complex than anything designed in civilian industry the military industrial complex has been building very complex machinery for a long time. The problem accessing this information is that it is commonly a state secret and that any failures are commonly hidden from public knowledge. However because Soviet Union collapsed there is plenty of accurate information on Soviet military machine architecture. Some of the Soviet military machines were effective others not very effective. The methods used to build MIG-29, SU-27, T-34, T-64, T-72 and other effective fighting machines can be used to solve system architecture issues. For quick info on Soviet military architecture see[https://www.youtube.com/watch?v=PJ_IxNQK3pw&list=PLlgs-bz3H7FNkwxytsjn-p-hdW7bGfw22] or use your favorite search engine to find information.
[[Category:Developing]]

Latest revision as of 14:57, 26 September 2019

Retrieved from "http://roguebasin.com/index.php?title=System_Architecture,_the_strategy_to_complex_implementations&oldid=49085"