This is a game that I wrote during a 24 hour code blitz competition. It got third. My theme was chapulas. It is your basic side scroller. I used only Windows API calls, once again, instead of employing DirectX or OpenGL. It is, um, a little fun to play i guess. I never got to implementing AI, so you just jump through the levels avoiding minor nuisances like water, lava, and spikes.

Full color graphics painting a whopping 4 Levels of jumping. Whoo! Plus, you control a crazy dude in a cape and moon shoes trying to save the world! Actually, that's not a bad premise...I might have to come back to this.

You could probably learn a good deal from this if you can read my code. After around 12 hours in, 24 hours awake, I started to lose it. Many basic parts of game programming and efficient Windows drawing are illustrated. Yep.

The code illustrates many typical elements of game structure. Programming a game is totally different than programming your everyday app. Game's hog resources and their loops are constantly using the CPU.

A game starts with a loop. This loop runs as long as the game does. In an application, the program would stop whenever the user was not using it, allowing other applications to run. It even stops while the user is working on it so that other applications can do background work. A game, however, wants to run constantly. It has a great deal to do, and it becomes a great load on the system. A game has to be able to run as hard as it needs to, but still has to allow other processes to work.

In my code, I show a good method of implementing a message loop for a game in Windows. Usually, you would use the GetMessage API call. This would get a message from the OS for different events like mouse movement and keyboard presses. For instance, it would return when the user clicks on the window, and pass the WM_LBUTTONDOWN message to a function in your program. This will wait until there is a message before returning, but games do not just stop when there is no mouse or keyboard input!

Instead, one would use PeekMessage, with a PM_NOREMOVE flag. This will just look and see if there is a message and tell you if there is. If there is one, THEN use GetMessage to retreive it. This way, the body of the game loop always executes, and animations can occur when the user is idle. Look at the GameLoop function.

To get your animations running fluidly, timing becomes a big issue. You would move and update objects in your game world every time the loop runs. You would pass the amount of time elapsed since the last iteration of the loop to this function. To get the elapsed time, you would use an API call to receive the current time, and of course subtract it from the old time. But some discrepancies occur.

Every once in a while, you unfortunately call the function when some background process is doing work. The time you receive is not consistent to the times you have gotten before. In fact, it is very very wrong. Your game will seem to 'skip' and you'll scratch your head for weeks. But, there is a way to even out those bumps.

You simply, after getting the delta time, take the average of that one and the last 30 or so delta time's you have returned in the past. This will return a result with a consistent error. Look at my Timer class.

The animation still isn't fluid! Some applications are fighting with the game for use of the processor. So, you can yield to another process after every iteration of the game loop. Simply add "Sleep(1);" at the end of the loop.

You are working with delta times in the milliseconds. When you are working with fractions of seconds like this, you ought to be working in fractions of pixels. For really fluid animations and specifically movement, you would use floats to define the coordinates. That way, if an object is supposed to move 1 pixel per second, this object would move .6 pixels in .6 seconds, and if another .6 seconds occured, he would move to an offset of 1.2 pixels. Otherwise, rounding would occur with integers, and the object would move 2 pixels, an error of .8 pixels per second.

The Level Editor was written in Visual Basic 6.0. It is a simple tile painting type editor. You simply create a level, and then type in the tile map you want to use and save. Then re-load, because I was lazy, which should load the tile map you wanted to use. Then you just click on the tiles to the left, and then paint on the canvas to the right.

The tiles need properties. There are 5 properties: Background, Foreground, Solid, Passable, and Death. They do what they imply. Death is very unforgiving as a tile. If you even touch it slightly, you die a horrible death. Well, not really, you simply restart the level. By the way, sprites in levels are hard-coded. I had only 24 hours!

Again, the editor was written in Visual Basic 6.0. This is used to compile a sprite file, which consists of a bitmap of ALL frames and a data file containing information about the position of a frame on this large bitmap and collision rect information.

To use it, you simply add all frames in their correct positions, determined by the games code. Then for each one, you define a series of rectangles called collision rects, which are used by the game for deciding when you have hit a sprite or a wall. Another rect is the Bottom Edge rect, which simply is used by the game for when to stop with gravity and where you can die by Death tiles. After you save the file, you load it into the game.

Programming - Dave Wilkinson

Art - Lindsey Bieda

Level Design - Bradley D. Kuhlman

Special Thanks to the PittGeeks for their continued support of Computer Science and this competition. Plus the prizes!

[ download (6.28MB) ] - The project with graphics, editors, and source.

[ source directory ] - Click here to view the 'Chalupas' source directory on the server.