What’s in a Game? - Game Coding Complete - page 26

'

After you finish this chapter, you ll have a good understanding of the main compo-

nents of game code and how they fit together. The rest of this topic digs into the
details of these systems and how they work.
The important lesson to learn here is that you

ll be able to build much better games if
you really understand the architecture, the components, and how everything fits
together. In other words, think and plan before you start coding, because a great
foundation can hold a big game, where a crappy one simply can

'

' t hold up to the

'

strain. We all hear this good advice over and over, but it s easy to neglect because it

takes a lot longer to get something up and running. Think of this like you would
approach building a house. Don t be like the guy down the street who just starts put-

ting up walls without really thinking through how big his house needs to be, whether
it needs a second floor, and how he wants to live in it.

'

Game Architecture
There are as many ways to assemble the subsystems of a game as there are game
programmers. Being a game programmer, I ll give you my opinion of what the sub-

systems are, what they do, and how they communicate. You may do things differ-
ently, and that

'

m going to present is
geared toward understandability, not necessarily efficiency. Once you understand
something, you can find your own path to making it run pegged at 60Hz or better,
but you sure can

' s perfectly fine by me, especially since what I '

' '

s going on.
I can ' t say this enough — you don ' t have to do things my way — but since my way is
the easiest for me to describe, it makes some sense that I

t get something to run that fast if you have no idea what

ll preach a little of my own
opinions. As you read this chapter, think first about what problems I

'

m solving with
this system and at least grab hold of the subsystems and what they do on their own.
If you come up with a better way to build this mousetrap, call me, and I

'

' ll hire you.

Let s start at the top level and work our way down. You can take every subsystem in

a game and classify it as belonging to one of three primary categories: the application
layer, the game logic layer, and the game view layer (see Figure 2.1). The application
layer deals with the hardware and the operating system. The game logic layer man-
ages your game state and how it changes over time. The game view layer presents the
game state with graphics and sound.
If you think this architecture sounds familiar (and you ' re familiar with MFC ' s docu-
ment/view architecture), you

'

t burn this topic in disgust just
yet. While I loathe programming in MFC as much as the next person, there is amaz-
ing flexibility in separating a game into these three independent systems. Another
popular design pattern, the Model-View-Controller, seeks to separate the logic of a

' re exactly right, but don '