4.4
Supporting the Creative Team
But how should software architecture be used to support the needs of the creative team?
In Nordmark [18] the second of the four RQs is: ”Is software architecture helping game developers doing their job?”. The conclusion to this question sums up the findings in a concise manner [18, pages 82 – 83]:
“From this research, we can clearly see that the game devel- opers reap many benefits from their use of software architecture. From a suitable software architecture, both the creative team and the technical team are able to do their job in a quicker and more efficient way.
If we first look at the creative team, there is one example which illustrates very well how software architecture help them do their job. In the documentary “Beneath the Surface” pre- sented in Section 9.2 they present the possibility to use rapid prototyping when developing their games. This allows the cre- ative team, helped by the technical team, to implement early versions of their ideas quickly, and try them out in-game. If if works well, they can develop the idea further, and if not they can scarp it early, freeing up time to do other things.
Furthermore, the creative team is able to implement levels and characters without having intimate knowledge of program- ming languages or the inner workings of the game engine. This allows them to focus on their predominant task; developing the content for the game.
A proper software architecture also allows the creative team to request new functionality. If this is a new module, or just an extension to an already existing module, the technical team should be able to consider the actual implementation cost, and if the cost/benefit trade-off favours the benefit, they can imple- ment and integrate it into the game engine without unnecessary workload or ripple-effects.
Another benefit for the technical team is that a sound soft- ware architecture which separates generic functionality and game-specific functionality allows for a higher amount of reuse. They can reuse the core components, and replace them if nec- essary. If we look at the sand engine example in Section 9.1, this shows us that the correct use of software architecture allows the company to extend and modify the capabilities of the game engine without affecting too much surrounding code.
Reuse of components and software architecture allows for quicker development cycles and a higher focus on the unique
34 CHAPTER 4. SOFTWARE ARCHITECTURE IN GAMES
parts of the game (i.e., the content).”
As this captures the essence of how software architecture can be used, as discovered in Nordmark [18], there will be no further discussion of the findings here.
Chapter 5
Game Development
In this chapter the relevant particularities of game development will be pre- sented, as well as a short history of game development.
5.1
History of Game Development
This section is based on a similar chapter in the report “Software Architec- ture in Games” [18], which in turn is based on chapters 16 and 17 in “Game Architecture and Design” by Rollings and Morris [21].
The origins of computer games and the development of these to the home user, started in the 1980s. The four major home computers at the time were the Commodore 64, Sinclair ZX Spectrum, and the Amstrad 464. All of these machines were using slow, 8-bit processors, and with a very limited memory available.
Within these computers there was literally no variance in the available hardware, simplifying the development requirements greatly. The developer also worked directly on these machines. As a consequence of this, there were no risk of the game developed to be too slow, since the programmer constantly verified that the experience was according to the requirements.
Another consequence of the very limited resources was that the develop- ers had to utilize every last bit of memory and every last clock cycle to make the best game they could. Therefore they would drop the Operating Sys- tem (OS) and all auxiliary functions, and program directly to the hardware available1.
Since there were no good assemblers or compilers at the time, the devel- opers had to assemble the program themselves. The developer would then write down the op-codes (instructions for the processor) and convert them by hand to hexadecimal digits. These digits could then be entered directly into memory, and then tested. This process was difficult, and since the dif-
1
This style gave birth to the term “writing directly to the metal”
36 CHAPTER 5. GAME DEVELOPMENT
ferent machine series had different hardware, there was no simple way of porting a game from one platform to another.
After a while, there were released assemblers that were reasonably effi- cient. This simplified the programmers work quite a bit, removing the need to manually convert the op-codes to hexadecimal. However, there were still several problems. Since the assembler was a software program, it needed a bit of memory to run. This caused a problem, since the games needed every last bit of memory, forcing the games to be assembled in pieces, and then glued together in memory afterwards.
Another problem they had was that they could not debug the program running on the computer. Although mitigated by the limited amount of code, this still was a problem.
After years and years of development, introducing new hardware, OSs, and programming languages, modern day game development was born with the release of Doom, the first game written almost entirely in a high-level language (C).