4 Data and logic

 

This chapter covers

  • What a simple data-oriented architecture looks like.
  • Where to store the balance data - the data that doesn’t change during gameplay.
  • Where to store the game data - the data that changes during gameplay.
  • How to implement our game logic functions.

In the previous chapters we learned how to write high-performance code using data-oriented design. Now we’ll use what we learned in chapters 1-3 to architect a simple version of our survivor game. In this chapter we’ll cover the parts that are engine agnostic: the game data, and the static logic functions that transform it. In Chapter 5, we’ll cover the board, which takes in input and draws our sprites to the screen, and the game loop, which drives our board and controls our menus.

To help show what a DOD architecture looks like, we will create a basic version of our survivor game, as shown in Figure 4.1.

Figure 4.1 Screenshot from our basic survivor game. The player is the black dot in the middle. The enemies are the gray dots. The user can move the player around the screen while the enemies bounce around. If the player touches an enemy, the game is over.

The gameplay is simple: the user controls the player (the black dot) and tries to avoid enemies (the gray dots). If the player touches an enemy, the game is over. To keep things simple, the player won’t shoot anything. We are just avoiding enemies here.

4.1 Simple DOD Architecture

4.2 The Balance

4.3 The GameData

4.4 The Logic

4.4.1 Logic accessibility

4.4.2 AllocateGameData() - Allocating all the data for our game

4.4.3 StartGame() - Initializing our gameplay data

4.4.4 Tick() - Handling frame-by-frame gameplay

4.4.5 Handling user input

4.4.6 Functions called by Tick()

4.5 Conclusion

4.6 Summary