Make yer own!

The very first computer programs, for gigantic systems that filled entire floors of buildings, were essentially just giant equations. Whole basements were full of nothing but extremely large, extremely precise calculators. The notable thing about these old systems is that they were one-pass – you gave it some input, you started it running, it gave you some output and then it stopped. Games tend to follow a slightly different model: You start it, you give it input WHILE it is running, it changes what it’s doing accordingly, until you actively TELL it to stop. How do we achieve that effect in our program?

Loops, of course.

Almost all programming languages have some sort of loop structure that makes it easy to do something either until there’s a reason to stop, or a fixed number of times. C# and C++ have quite a number in common (as do quite a few other languages), so let’s focus on the ones we’ll see – and use – frequently in our programs.

for (starting condition; test condition; change every step)

The for() loop is a good way to step through a list, or do something a fixed number of times. Remember ints from our last entry? Let’s say you have a list of things (we’ll call it myList) that has ten items in it, and you want to do something to each one of those items:

for (int i = 0; i < 10; i = i + 1)
{
    // Do something to myList element i
}

Note: It’s almost always true (and easy to forget!) that when you’re “counting” in programming, you start with zero instead of one, so a list of ten elements would be numbered 0-9 instead of 1-10.

This loop would make a new integer, i, and set it to zero. Then it makes the test (i < 10) – if that is TRUE, it does everything inside the curly braces. After it’s done with that, it does our “step” (i = i + 1), makes the test again, if it’s true… and so forth until the test is FALSE. When i is no longer less than 10, it skips the braces, and TADA! We’re out of that loop.

While this kind of loop comes in handy, and it’s POSSIBLE to make a loop that never ends with it, there are some more convenient and easier-to-read ways to make a loop that “goes on until we say otherwise” – like the while loop.

while (test condition)

This loop will execute everything inside until the test condition is false. Ah-HA! This is more like what we would want to do with our game. We’d set up a boolean to keep track of whether the game was still going or not, and change it whenever we decided the game wasn’t going anymore:

bool gameRunning = true;
while (gameRunning)
{
    // Do the game stuff here
 
    // Is it time to quit?
    if (we quit the game)
    {
        gameRunning = false;
    }
}

A few extra steps, but it’ll run until we actively do something to make it quit.

Some very general food for thought: Most games, if not ALL games, have a structure very similar to that. We set up a while loop that runs until some test is false. Inside this loop, there are three major steps that happen:

1. Get the input from the user. Read their joystick or keyboard, keep track of what they pressed, things like that.
2. Update the game itself. Move the player based on what the joystick said, move the enemies, adjust the score, etc.
3. Draw everything to the screen based on what we just updated.

This can happen either as fast as possible, or once every update of the screen (commonly 60 times per second). If you read about development of other games, you’ll see a lot of professional developers grousing about “60 frames or death”, especially on console games – the speed of the updates determines the speed of the animation, and 60 frames is a pretty solid industry standard now. The old Speed Racer cartoon was animated at 12 frames per second – remember how jerky it looked at times?

A special note to those of you who chose XNA as your platform du jour for writing a game: The default XNA Game object defines its own Update() and Draw() methods, that get called automatically. You’ll have to write your own HandleInput() method, and call it from your Update() method, but the principle is the same – SOMEWHERE in the project is code that, until it’s stopped, calls Update() and Draw() automatically.

All of this helps us break down our design document a little more – out a your list of things that Space Invaders “does”, there are three major categories:

1. Things that happen every frame – The aliens moving, the background stars scrolling.
2. Things that happen every frame IF something causes them to -  Your shot moving. Can’t move a shot if you didn’t shoot!
3. Things that happen only ONCE, when some event causes it – The score updating, or an alien exploding.

Starting to get a big list? Good. We’ll cross items off one by one as you add them in. Tomorrow’s post will be a bit more philosophy of game design, and next week we’ll start actually MAKING THINGS HAPPEN!