Nazeeh’s Little Corner on the Web

So how does a game work? Is programming a game similar to programming a web page or an application? Well, not really. A lot of the programming concepts you already know will apply and be helpful of course. You’ll just learn how to apply those concepts to game engines versus applications. I am a big fan of learning by example, so let’s see how a game such a Pong would be developed.

I am going to take a small tangent to describe what Pong is in case you’re not familiar with it. Pong is one of the simplest games out there, and one of the first.. It’s basically a simulation of tennis using very simple graphics.

As you can see, the game has two paddles that are represented by short vertical bars, a net that is a dashed line, and ball that is a square-like shape. The game is played by two players, each moving one of the pads up and down to place it in front of the ball to hit it back to the other player. You score when the other player misses the ball. Simple enough, right? How do write such a game?

This game follows the same stages that most games use. When you create a new game in XNA Game Studio Express, these stages are actually spelled out for you in the code. How convenient! Let’s take a look at each stage and what happens in it.

Initialize

The first thing you want your game engine to do is initialize. In this stage, you place code that will run only once during the lifetime of the game. So actions such as loading user preferences, detecting some kind of hardware or user state, and so on, are best placed here. You are basically scouting and setting the stage for you game before it actually starts. For something like Pong, I can’t imagine much being loaded here beyond maybe the top high scores. This is in preparation for displaying them at the end of the game along with your current score.

Load Content

All games will probably have some kind of graphics to display. For a game as simple as Pong, the graphics may be created by the game at play time (creating a couple of vertical bars is quite easy). But for argument’s sake, let’s say Pong’s developer decided to create the game’s graphics outside of the game. So at this stage, you would probably load up pictures (or textures as they are usually called – more on that later) of the vertical bars, the net, and the ball. You can create such “graphics” very easily in an application like Paint.

You probably want to preload as many of your graphics and sounds at this stage as possible. By doing so,you don’t have to load them mid-game, which decreases the game’s performance until loading is done. Trust me on this one… I made this mistake when I was learning, and it wasn’t pretty.

Update

This stage is possibly the most important stage of all and the one that ends up harboring the majority of the code. By default, the XNA Framework’s Game will try to call update sixty times in one second. The purpose of this stage is to do the following:

• Read user input

All games need some means for the player to control what’s happening. For a game like Pong, that could be an Xbox 360 controller where we care only about the up and down directions of the left thumbstick. So at the update stage, you write code to poll each of the two connected controllers. This code asks “Hey, where’s your left thumbstick? Up, down, or middle?” Using the information the controllers return, you know which way each one is pointing. Excellent! We just read the users’ inputs! Now let’s move on and do something with them.

• Compute game state

The game state refers to the current state of the game, along with any new information we may have solicited (such as controller input). In Pong, that would mean where the ball is now on the screen as opposed to where it was last time Update was called. Where are the paddles? These are all functions of time, of course, especially for the ball since it is moving a certain distance for every unit of time. So it’s pretty useful that you always get a GameTime object in the Update method that tells you how much time has passed since the previous call to Update.

Another thing you might want to figure out here is whether the ball made contact with one of the paddles. You do this by using something called “collision detection.” The principle is self explanatory: Two things collide, and you detect it! So if the ball hits a paddle, you know that you need to update the direction it will travel from now on since it “bounced” off the paddle.

• Update game state

So now that you have computed a new game state by applying any new information you got this time to the game state of the previous time, you end up updating the game state with that new information.

Think of it this way: New game state = Old game state + new information..

• Handle game screen transitions

This is really more of a special case scenario, but it happens in every game. You know, when you start a game and you have a menu of Start, Options, and Exit? Or when you are done with a game and you are shown a high scores screen? These are all screen transitions, one of which is the actual gameplay screen. So when you start the game, the first screen is the menu screen; you pick an option, and you are transferred to the gameplay screen. If you win, or die trying, you move to the high scores screen. The game has to detect such trigger conditions in the update stage and if they occur (you won the game of Pong!), the game will move you to the next screen, which is the high scores screen.

Draw

This is the stage that your players will see all the time. The draw stage is when you actually draw the game screen and present it to the player. Drawing in a game happens frame by frame. Let’s take the example of the ball moving in Pong; as the ball is moving, what you are really seeing is a very fast sequence of the entire screen being drawn over and over but with the ball placed in a different location every frame. The concept is similar to that of a flipbook: the smaller the distance the ball is moved every frame, the smoother the animation will appear.

The draw stage usually starts with a call to clear the entire screen, so you get a new empty canvas to draw on every time. Then you start drawing static things such as your background (which in our case is just black). Once you are done with that, you want to start drawing the paddles and the ball. You know where to draw them on the screen because the game state that was computed in the update screen will tell you where they should be. After you’ve drawn everything, you tell the game engine to show the user what you’ve drawn. And that’s what the user will see.

Let me recap. Think of it as though you’re an artist who will draw a picture but won’t show the audience anything as you draw. You paint the background, then the ball, the paddles, and the score, and when you are done, you flip it around to show us what everything looks like. As we’re looking at it, you’re already drawing the next frame using information about where things have moved since the last picture. When you’re done, you flip that around, and we see the new frame. All this happens so fast that we don’t see the flipping; instead, everything looks like one picture with stuff moving on it. What happens if nothing has changed between frames? Well… the same frame gets redrawn anyway. Behold the illusion! Sneaky game developers!

The entire cycle

So to recap, the entire cycle is:

If you spend some time to let this sink in, you’ll start to see how it would work for any game. Pong is a very simple game used to illustrate this cycle, but the important point is that this cycle applies to something as complicated and big as Halo as well. Think about it…

Move on to part 2

Thanks for reading! I'd love to hear your thoughts, feel free to leave a comment below. Don't forget to subscribe to my RSS Feed!

This entry was posted on Wednesday, November 7th, 2007 at 11:59 am and is filed under Beginner Game Tutorials. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.