Developing fun

A query for “video game architecture” in the library of the Institute of Electrical and Electronics Engineers delivers 446 results, whereas the query “software architecture” delivers a whopping 83,009 results. Clearly, video game architecture is a less researched aspect of software architecture, even though there are over 2.5 billion people who play video games around the world. In this essay we delve into the world of video game architecture and try to lift the veil of mystery of designing these popular software systems.

Requirements

The first step in any software project is defining the requirements, or at least it should be. However, defining requirements and designing the software are not so straightforward for video games, compared to other software.

Fun-ctional requirements

The quintessential requirement for video games is to be “fun”. This requirement alone makes video game development very different from other software. Ask two software engineers to define what is fun and you will get two vastly different answers. Now ask an artist what fun is and they will also explain it in a vastly different way. A design may sound like fun, but it might turn out to be very dull. This is why functional requirements are generally less suitable for video games.¹

Luckily for OpenRCT2, the formula of the original has already proven itself in terms of being fun. There are also two decades worth of players that can share potential improvements and other feedback with the developers. This means OpenRCT2 is actually able to formulate more functional requirements, like having multiplayer.

Non-functional requirements

Video games tend to have stricter requirements for optimization.¹ RCT2’s architecture is greatly influenced by the necessity for it to be very efficient. The fact that it is entirely written in assembly should say enough about that. OpenRCT2 does not have strict performance requirements, since most users will have very powerful systems compared to what was required for the original. That being said, there are players having performance issues and the developers do take time to optimize the game performance-wise.²

Another requirement that differs from most software is that games can have the requirement to run on multiple platforms. These platforms are not just PC but can also be console or mobile. This also applies to OpenRCT2. The original only ran on Windows and Xbox, but one of the goals of OpenRCT2 was to make it available for macOS and Linux as well. Currently, the project even supports an Android build. Configuration management becomes more important when you support more platforms.¹ The OpenRCT2 continuous integration needs to check whether changes compile and pass tests on multiple platforms.

Lastly, a non-functional requirement for video games is that there is generally more pressure on releasing as quickly as possible.³ This also has effects on the quality of the documentation and design. OpenRCT2 is open-source, so it does not have this pressure. However, we think most developers would prefer creating new functionality over documentation.

Architectural design

The second step in a software project is to use the defined requirements to come up with a design. There are many ways to design software systems. Some notable designs include the notorious spaghetti code⁴ and the big ball of mud⁵, a software system without a perceivable underlying architecture. Both are examples of designs that make systems difficult to change or maintain, so it is important to avoid these kind of designs.

A survey among video game developers showed less time is put into design because of the fun requirement. Participants noted there is less time spent thinking about architecture because the system is very likely to change after the initial design. Especially for one-off games, architecture is deemed less important.³

For a series, more thought is put into the architecture since components can be re-used in the next game. Rollercoaster Tycoon (RCT) 2 is part of a series and also re-used parts of the first game.⁶ Moreover, before Chris Sawyer developed RCT, he developed Transport Tycoon. Since that is also a simulation game, parts of the design could be used in the RCT games as well, so the architecture can be considered quite “mature”. OpenRCT2 is easier to develop because of that. For example, RCT2 already contained a GameAction system, which queued user commands and executed them from a central component. This made multiplayer gameplay relatively straightforward to implement.⁷

In a previous essay, we showed that the architecture of OpenRCT2 closely resembles the model-view-controller (MVC) architectural pattern. The MVC pattern is frequently used in the design of games and it is considered a good base architecture for game development.⁸ There are several reasons as to why this architecture is beneficial to the design of video games, including OpenRCT2.

Firstly, it makes it easier to support various input devices.⁸ The user input is decoupled from the rest of the system through the controller component of MVC. The controller can be seen as an interface that can be implemented for different platforms and a variety of input devices such as joysticks, mouse/keyboard and touchscreens. OpenRCT2 runs on different platforms, including Android, where a touchscreen is the default input device. The decoupling of the user interface (i.e. the view compontent) from the rest of the system made it easy to port to Android.

Secondly, MVC makes it easier to support different platforms and hardware. The view component of MVC is decoupled from the model and the controller, which allows the view to be adjusted based on the system the software runs on. Some users might have high-end computers, others might run the software on a low-end laptop and some might play the game on a console. All these platforms have different hardware specifications that influence the application’s run-time performance. Since the view is independent of the model and the controller, the view can be adjusted accordingly. In OpenRCT2 this is demonstrated through the possibility of using different drawing engines (OpenGL, Software or Hardware based).⁹

Overall, the MVC pattern appears to be a good architectural pattern that can satisfy the unique requirements of video games.

Development process

The third step in a software project is to transform the design into an actual implementation. In this section; we will investigate what causes the development process for game development to be different from non-game development, we will highlight in which ways these differences manifest, and how the development process of OpenRCT2 compares to the rest of the industry.

An obvious example of how game development differs from non-game development is the composition of the development team. As multimedia assets such as audio and graphics are an essential part of a video game, these development teams usually consist of both programmers and artists.¹⁰ This increases the importance of proper management, and also raises the question on how teams are best formed. Combining programmers and artists into a team can offer the benefit of improved communication.¹⁰ On the other hand, not combining them could aid the sharing of specialized knowledge.¹⁰

Another difference can be seen in the preproduction stage. This stage is made more complicated partially by the less formal requirements of a game. Before the formulation of a (technical) specification, a Game Design Document (GDD)³ is often made. High-level artistic elements such as a game’s story, characters, and general game-play are described in this document. A more usual specification is made afterwards. Therefore, there is an extra step compared to the preproduction stage of a typical software project.

Although a thorough preproduction stage is paramount for a succesful game development process,³ errors in this stage are very common in game development.³ There are multiple causes of game developers not spending enough time and energy on the preproduction stage: it is common and expected that requirements are discovered when moving from preproduction to production,³ pressure leads to short-term thinking,¹ and there are indications that in software development culture energy spent on planning and designing architecture is not rewarded much.¹ This could be a major cause of so few projects being completed within the projected budget and time.

Agile processes are common¹ in game development. In contrary, standard waterfall models are not.¹⁰ This can be explained by the need for iterative¹⁰ development: prototypes and iterations are used to ‘find’ the fun, and to fine-tune game-play.

OpenRCT2’s development process is atypical in numerous ways. Due to the goal of recreating the original game, there was no need for much artistic work or preproduction. Moreover, the majority of early development has been single-handedly done by IntelOrca. Early development consisted mostly of reverse-engineering, which is a very specific development process. As this recreates the original game, not much thought has to be put into architectural decisions.

The projects that aim to provide free replacement graphics and music for OpenRCT2 are not yet active. Attracting artists to work on these projects would incorporate them in the development process. On the other hand, translators have been part of the development process relatively early on and are actively maintaining 19 translations.

Arguably, OpenRCT2’s development process is more similar to that of other open-source projects. The majority of development is done by a small set of core developers, while users are encouraged to get involved. Communication among and between developers and users occurs online.

Maintenance

After the development process, the final step in a software project is to maintain the implementation. Over the years, the maintenance process of game software has been changing. In the past, conventional video game consoles didn’t have any maintenance period. When online services such as Xbox Live for the Xbox came, the developers maintained their software through downloadable patches. In PC development, developers wait for a period of time to receive as many bug reports as possible and then work on a patch.¹¹ A patch may fix bugs, add features or alter gameplay. In the case of massively multiplayer online (MMO) games, the shipment of the game is the starting phase of maintenance. These are in continuous maintenance as new features are added and the game-world is changed continuously.¹¹

Software maintenance is delayed in games more often than in non-game software. One of the reasons for this is that there is a chance that the game may not be a success. If maintenance of a game starts early, all efforts put in may go to waste. Conventional software requires continuous maintenance and competes in the market based on new features, but that’s not the case for some games. Hence this can be another reason for lack of maintenance.¹ The cloud changes the way games are maintained. These days, the game maintenance process is starting to look similar to non-game software.¹

The original RCT game which was played on a console or a Windows PC, had very few patches. Now, the OpenRCT2 software is a little similar to conventional non-game software. Development in OpenRCT2 is quite active. Maintenance of software also goes hand-in-hand. Reports of bugs are actively monitored and fixed along with altering or adding new features to the game. Every now and then, after certain number of fixes and new feature additions, there is a new release of the game.¹² Furthermore, a launcher is available, which automatically updates OpenRCT2 and keeps the latest stable build up-to-date.

Conclusion

Video games have different, less-formal requirements compared to non-game software, such as the need to be fun. This leads to significant differences and specific challenges in choosing architectural designs for games, and for the development processes of games. Due to OpenRCT2 being a reimplementation of a pre-existing game, its architecture was already defined based on the requirements set by RCT’s original developers. OpenRCT2’s development and maintenance processes are mostly shaped by its reverse-engineering origin and open-source nature.