Everyone Knows I’m In Over My Head

I just got finished reading chapter 3 and I am just clueless what the second half of it meant. I’ll start to explain the first half and see if it comes to me.

The first part of the chapter goes into describing what a game engine does and how it helps to make one. Please chime in to correct me if I am wrong, I am learning this, not teaching it. A game engine is a part of the program that creates the parameters for your game to run. It sets the screen dimensions, the devices it will interact with (a keyboard, mouse, game controller, etc,) sound devices, and a myriad of other things. A game engine is where you put all your code with how your program will interact with your operating system and hardware.

An interesting thing about the game engine is that one created, it can be become the foundation for you to make an entire set of games. I will use the example of NCSoft; they have about six games out right now that all seem to be the same game in different genres. I’ll bet they all use the same game engine and just have different designers making the rest of it. A game engine is something they probably make, refine, and perfect to be the base of all their games. It sounds daunting, and it sure as hell looked it.

The first part of this chapter talked about something that helped me see games in a different way. It would take pages of my blathering to explain what I see now, but the core was learning of cycles, which can also be referred to as frames.

Every game goes through a cycle. The cycle takes the current game state, applies the changes the user applied, adds the variables the game applies, and then ends. Greek, right? Well, let me try to clear it up. Remember Asteroids? The game has random bouncing rocks, and a space ship you control to destroy them. Well, what happens is that the program is made to create rocks, and let them move randomly until they hit each other, get shot by the space ship, or hit the spaceship. In the sense of one cycle here is what happens:

Game clears the screen
Game calculates where the rocks are.
Game calculates where the rocks are moving to.
Game calculates any collisions
Game calculates any user input (shooting, moving, etc.)
Game draws the rocks, ship, and shooting.
Game ends.

The cycle has ended and a new one begins. The new cycle now clears the screen, runs where all the calculations say the object now are, and draws the screen again. It repeats it till a variable comes up that will change the calculations, say running out of rocks, or the ship being destroyed. So, that being said, the number of cycles you run per second will determine how smooth the game graphics appear. Just this little description of cycles has made years of playing games much more understandable.

I hope that made sense, if not, let me know. Ok, I’m off to make sense of the game engine code the chapter has in the second half. I still don’t have a clue what most of it means. Once again, wish me luck.