After finishing the first edition, I got feedback from peers, and things slowed down to a halt while I was preparing a second revamped and extended edition. A couple of years later – this past week – I realized that the old text in its unpublished state wasn’t helping anyone, and that along the way, I’ve picked up an ongoing audience of readers that are into hobby videogame development. I decided to go ahead and share the previously unpublished first edition:

It’s free! Read:
The Young Videogame Developer’s Journal

Browse, print, share, and link to this e-book however you’d like.

Interested in playing any of the games mentioned in that e-book, to put the text into context? Most of them are available at the Archives page at InteractionArtist.com.

(Originally posted as GameDevLessons.com Vol. 9 Sec. 4)

Alice in Bomberland is a videogame for iPhone and iPod Touch that I developed along with a team of supporting artists, published by Sonic Boom. I wrote a lengthy essay on the meaning and design of Alice for my admissions essay to Georgia Tech’s Digital Media program. It’s available online both as a print-ready PDF and in HTML with extra in-document links.

(Originally posted as GameDevLessons.com Vol. 9 Sec. 3)

Puffs of dirt kicked up from tires, smoke after explosions, empty shell casings ejecting from automatic rifles, and splashes of water are all particle effects. Shattered pieces of scored gems in a puzzle game, splatters of blood from gunfire, broken glass, chunks of wood, snowflakes, sparks, and shards of plants are all particle effects.

Particle effects are categorically different from most other objects in a videogame. Note the following differences:

• Particles don’t influence gameplay. They don’t knock things over, respond to being stepped on by enemies, or inflict damage. A game that has particle effects, generally speaking, would play out exactly the same without the particle effects.
  
  
• The game needs to move and draw many particles at once. Dozens or even hundreds of particles may be constantly present – perhaps as rocket thrust, boat wake, or damage smoke – and during intense action the game may need to handle many thousands of particles. This means they must be small in memory and require minimal processing.
  
  
• Particle effects are dynamic. Particles spin, rotate, fade, bounce, drift, fall, and sometimes even produce sounds (when they start, fizzle out, or hit the ground).
  
  
• The number of particles must be limited to protect the game’s framerate. Drawing and moving thousands of particles every second can pose a serious risk to game performance.
  
  
• Particles spawn with some randomness. Because many particles can be spawned from a single event, introducing slight randomness into the initial location, velocity, and lifetime avoids particles overlapping one another, increasing the odds that each one using processing and rendering time gets seen.
  
  
• Particles only last a few seconds. What makes particles exciting is their movement. Once the particle’s action is complete it needs to be made available for a future effect.
  

Benefits of a Fixed-Size Array

There are dozens of container structures that are more complex, robust, and flexible than fixed-size (i.e. normal, basic, no frills) arrays – linked lists, vectors, and so on. Why do I recommend using fixed-size arrays for particle effects?

• Arrays are extremely fast to access.
  
  
• Arrays avoid overhead from memory allocation or deallocation, and in so doing also avoid cumulative memory fragmentation.
  
  
• The usual downside to using fixed-size arrays – that they have a maximum number of elements allowed at once – is desirable for particle effects! This ensures the number of particle effects are kept within a sane limit.
  

Code, Applied to Asteroids Source

In main.cpp of the sample Asteroids starter source…

After:

#define ROCK_NUM 25

Add:

#define PFX_NUM 1000 // maximum number of particle effects

After:

obj_typ ast[ROCK_NUM];

Add:

struct pfx_typ {
  float xv, yv; // component velocity
  float x, y; // position
  int life; // frames until it vanishes
  int color; // color of this particle
};

int pfx_alive = 0;
pfx_typ pfx[PFX_NUM];

Before:

void drawThings() {

Add:

void pfxJet(int spawnNum, obj_typ *fromObj) {
  int toSpawn;

  if( pfx_alive + spawnNum >= PFX_NUM ) {
    toSpawn = PFX_NUM-1 - pfx_alive;
  } else {
    toSpawn = spawnNum;
  }

  float cosPower = -cos(fromObj->ang) * 0.5;
  float sinPower = -sin(fromObj->ang) * 0.5;

  int colorForThisSet;

  colorForThisSet = 224+(rand()&0x1F); // shade from 224 to 255

  if(rand() & 0x01 == 1) {
    // bold reds
    colorForThisSet = makecol(colorForThisSet, 0, 0);
  } else {
    // bold yellow
    colorForThisSet = makecol(colorForThisSet, colorForThisSet, 0);
  }

  for(int i=0;ix = fromObj->x - 3 + (rand()&0x07);
    effect->y = fromObj->y - 3 + (rand()&0x07);
    effect->xv = fromObj->xv+float(-127+(rand()&0xFF))*0.002+cosPower;
    effect->yv = fromObj->yv+float(-127+(rand()&0xFF))*0.002+sinPower;
    effect->life = 60+(rand()&0x7F);
    effect->color = colorForThisSet;
    pfx_alive++; // raise the particle count to include the newest one
  }
}

Before:

drawLine( &ship , makecol(255, 255, 0) );

Add:

// move and draw particles in the same pass
// remember that we may have a TON of particles,
// so it's good to only iterate over the list
// as few times as possible

for(int i=0;i
life > 0) { // move and draw it
    effect->x += effect->xv;
    effect->y += effect->yv;

    circlefill(screenBuffer,
      int(effect->x), int(effect->y),
      int(effect->life>>6), // radius as life/64
      effect->color);
  } else { // remove it from the list
    pfx_alive--; // decrease number of live particles
    if(pfx_alive >= 0) { // providing we had 1+ particle left:
      pfx[i] = pfx[pfx_alive]; // copy last particle onto this one
      i--; // reconsider this particle
    }
  }
}

After:

ship.yv += sin(ship.ang) * thrustPower;

Add:

pfxJet(10,&ship);

That’s it! The code includes a number of strange optimizations – none of which I benchmarked (feel free to inform me if I’ve been silly to cache the array accesses into pointers, etc.). A few examples of minor optimizations shown here are bit shifting for division, bitwise AND as alternative to modulo to limit rand, and end-swapping in an array to avoid gaps without element shifting. Because particles can number in the thousands, particle programming is one of the areas where otherwise outdated or trivial optimizations (that otherwise should be avoided to keep code readable) can make a significant difference.

Modified Source

Here’s an updated example main.cpp file with the above changes made, in case the above insertion hints proved tricky to follow: Asteroids main.cpp with particles.
(Note that this requires core.cpp and core.h from the main starter source.)

(Originally posted as GameDevLessons.com Vol. 9 Sec. 2)

To play, you’ll first need to compile the source into an executable. This can be done in only 5-10 minutes following the steps below, and is the first step to your exploring the elements of programming. Unzip/copy these files into a new folder before continuing (you can unzip them anywhere; creating a “Projects” folder on your desktop works).

Use Left and Right keyboard arrows to turn the ship.
The Up key applies forward thrust.
Spacebar “fires” (drops) a green laser.
Press the Escape key to quit.

Are you only seeing a small white line on an otherwise completely black screen? Perfect! That’s all there is to the program in its current form. The rest, as you’ll find outlined in the comments of the code (the core.cpp, main.cpp, and core.h files), is up to you.

Once you have the program compiling – on whichever operating system you prefer – for next steps, read through the comments in the project’s main.cpp file. See if you can figure out how to modify the text to perform some of the remaining tasks. For a conceptual explanation of programming, check out Text Lessons Vol. 1. For a detailed introduction to different programming structures as they relate to videogame programming, check out Text Lessons Vol. 5.

Compiling on PC/Windows

Download and install Dev-C++ 5.0 beta 9.2 (4.9.9.2) (9.0 MB) with Mingw/GCC 3.4.2.

After it’s installed, run Dev-C++, check the “Tools” menu for “Check for Updates/Packages”, then under “Select devpak server” choose “devpaks.org Community Devpaks”. Press the “Check for Updates” button, then check the boxes to install Allegro (the library for audio, input, and graphical functions) and Allegro Supplement (documentation and sample files) – if you’re having a hard time locating those options in the list, click the heading of that names column to alphabetize the listings.

Next, use the File menu to create a New -> Project, type Empty Project, with the “C++ Project” radio button filled. Name it “Asteroids” and save the “Asteroids.dev” project file in the same folder as the downloaded source files.

To add the project’s files to the project, use the Project menu to find the option for “Add to Project”, then select all 3 files that were copied from the downloaded asteroids_ex.zip file (core.cpp, core.h, and main.cpp). Click on any project file in the left hand project view to see the contents of that file – main.cpp is the most interesting, as it’s where the game-specific action takes place.

Before we can compile, we need to add the Allegro library to the project’s setup. Under the “Project” menu, open “Project Options”, then flip to the “Parameters” tab. Under the right-most dialog box, the one headed “Linker”, type in “-lalleg” (minus the quotes). Press Ok.

Lastly, use the menus to go to Execute, then “Compile & Run”. The game (at this point only a white line on a black screen) should open, which you can interact with by using the arrow keys and spacebar. Press escape to quit.

Any time you make changes to the program source, you can update the game itself by repeating that last step to “Compile & Run”. Each time the game is compiled, the “Asteroids.exe” file in the same folder as the source files will be updated. That file is the program which you can share with others.

Compiling on a Mac or Linux

If on a Mac, download Xcode for Mac-only Development from Apple’s website to get all developer’s tools installed – if you’re on Linux, the OS shell probably already is set up for all of the commands that we’ll need. Also download the Allegro source for Linux (I found that here). Double click that downloaded allegro tar.gz to turn it into a folder, then use the Terminal to ‘cd’ command your way into that new allegro-4.2.2 folder (need to learn the Basic Terminal Commands?), then type the following lines into the terminal to install Allegro:

chmod +x fix.sh
./fix.sh macosx
make
sudo make install
sudo make install-man
sudo make install-applehelp
sudo make install-framework
make
sudo make install

Followed by using the Terminal to navigate into the folder containing the Asteroids game sample source. Then type in this command:

g++ main.cpp core.cpp -o asteroids-mac `allegro-config --libs`

NOTE that the ` is a BACKTICK on the same key as tilde (~), NOT a single quote/apostrophe from the same key as the parenthesis (“).

To edit the code, open main.cpp using any plain text editor (TextEdit, TextWrangler, DashCode…). To recompile the program to reflect changes made to main.cpp, repeat the step above for typing “g++ main.cpp…[and the rest]” in the Terminal.

(Originally posted as GameDevLessons.com Vol. 9 Sec. 1)