Difference between revisions of "2D Room system architecture"

From RogueBasin
Jump to navigation Jump to search
(Blanked the page)
 
Line 1: Line 1:
The 2D room architecture has very simple set of defined elements. Its popularity is because of various reason including easy implementation and easy to for the players to understand. The architecture has only four parts. The main drawbacks with this system architecture is that use of physics and RNGs becomes difficult. The architecture is quite good for telling epic save the world stories.


== Application Input Output System (AIOS) ==
This part is used to implement fundamentals of the architecture as drawing images on the screen, accessing writable media and communicating with the operating system. In the early days of computing this was implemented in assembler and implemented a scripting language to allow the rest of the games to be constructed easily. In the modern era of computing with object oriented languages this parts of the application implements an API (or several) for the rest of the game to use. There are a few games that implement scripting languages but with the OO and application languages like Java, C#, Javascript, Python, Scheme, Lua it is commonly easier and faster to integrate and existing language if required. When using a framework such as unity or RPG maker most of the work has already been accomplished and this part can possible be skipped (as it already is implemented).
== Application State ==
In the classic RPGs that used this system architecture the game state was a few attributes, a location, quantity of items. In the modern era of computing the game state in this system architecture is minimal and can in most cases be stored in a simple text file, one for system settings and one text file for the save file. The exception to this is when there is a need to store randomly generated dungeons. It is possibly to store random dungeons in very little space because of how RNG in computers work. This is done by storing the seed value of the dungeon in a single parameter. Check information on RNG regarding this. A limitation to this technique that changes made to the random dungeon cannot be stored. An alternative to using simple text files is to use serialization techniques in modern object oriented languages, however this technique has the problem that save files stop working across different versions of the game. This limitation makes the serialization techniques unsuited for storing save files. It is possible to use a database like SQLite, however the amount of code required to retrieve and store data in a database makes this a decent but not perfect solution. 
== Room Space ==
The individual rooms in the game. A room in an object oriented language is a simple object with a few methods to render and calculate physics. There may quite a few methods to allow mixing different attributes from different rooms. For instance modern 3D JRPGs have battle rooms that inherit the landscape of the in game map. In a basic game every room is coded from scratch, tough more advanced application may use different types of code reuse to make it easier to create new rooms. It is advisable to support room transitions that store a stack of active rooms to support GUI and NPC stores within the game. Several stacks may be required if the game has a lot of complex transitions or if the GUI is implemented as rooms.
== Room Transitions ==
This one of more defining elements of this system architecture. The simplest transition is teleportation from one location to the next. In old adventure games teleporation was used for implementing doors (see world builder[https://en.wikipedia.org/wiki/World_Builder]). There would be a script that checked if you clicked on the door, and if you did the door would be changed to opened. When clicking on the opened door the game would then teleport the player to the new location.
Other transition methods between room is when clicking or entering a store, sometimes a completely new user interface pop up and when clicking exit from the store the player is returned to the same location. This can easiest be implemented by
using a stack of rooms. Allowing stacked transitions allows some other types of effects, for instance when speaking with NPCs the background is shown. Allowing to sack rooms makes it also easy to blend attributes from multiple rooms to fix a few of the drawbacks of the architecture.

Latest revision as of 14:55, 26 September 2019

Retrieved from "http://roguebasin.com/index.php?title=2D_Room_system_architecture&oldid=49083"