Falldown now has a working graphical menu!  It looks like this:

Extremely Rudimentary Main Menu

Ok, fine.  Calling the menu “graphical” might overstate its visual appeal at this point.  I have yet to put in a title graphic or an options/configuration menu.  But still, that simple screenshot represents a lot of work.

To create the menu, first, I had to fire up the GIMP to design the menu art.  For now, I am keeping it simple; the art consists of the words “Play Game” and “Exit” as large textboxes, which I exported to PNG image files.

With art assets in hand, I researched how to (A) load the image files using SDL_Image and (B) convert the images into a format that OpenGL would play with nicely.

After all that, I updated the game’s state management, so it would know whether you (the player) were interacting with the main menu or playing the game.  Based on that game state, the game logic would respond differently to mouse clicks/key presses.

To round it all out, I made a few large tweaks to the game’s memory management.  The tweaks ensure that the game uses memory for the main menu’s image files only when it needs to display them.  The tweaks also make sure that the game properly allocates and releases the memory used by the ball, the rows, and other under-the-hood data structures, as you switch back and forth from the main menu to the game.

But a picture is worth a thousand words, and a video is worth a thousand pictures, which is 1,000,000 words.  With that,  here are those words:

I still have quite a bit left to add, such as sound, music, graphical effects, levels, scoring, etc.  I also need to update the menu/user interface to allow decision confirmations (e.g., “Are you sure you want to exit?”) and game saves.

But more important than the stuff that is missing is the stuff that is present: Falldown is built on a hand-crafted game engine.  So far, writing this game has taught me valuable lessons about “tangibles,” like software project management, source code management, and testing/debugging.  It has forced me to learn a few things about system memory management, game state management, geometric reasoning, collision detection (both static and dynamic), and user input management.  Lastly, it has also taught me about some intangibles, such as design and decision-making.

Or, in short, working on this game has been awesome so far, and I will definitely keep working on it.  Stay tuned!

(See What I Did There?  Falldown is shaping up.. :-D)

Falldown is really starting to take shape. Now, the game finally has reliable collision detection of a moving circle against moving rectangles.

That concept (detecting collisions between moving objects in a computer simulation) is much trickier than it sounds. Seriously, you have no idea how many resources I read before I finally succeeded.  Just about every word in that previous sentence is a link to an article, blog, or book that I used along the way to making the collision detection in Falldown work, and that’s just a sample.

In addition to the collision detection, I fixed errors in the game loop that were causing an unsightly display stutter/hiccup.  In short, the game animates smoothly, and the controls respond smoothly.

But don’t take my word for it; see for yourself!

I decided to do this the hard way and build this game using my own, hand-crafted game engine. Yikes!  “Why would you do that?” you ask, puzzled by my masochism. Well, I want to learn how to develop a game from scratch.

Now, I need to add other video game elements, like difficulty levels, high score tracking, menus, sound/music, etc.  But even though the game needs some work before it can be considered complete, it is nearly ready to be played by you!  I will release the game (and the source code on my Github page) once it has reached “playable demo” status.

I have to thank many people for teaching me what I’ve learned so far (manyof whom or may not know me.. yet…).  A few names stand out:

• Glenn Fiedler – gafferongames.com
• Dave Eberly – geometrictools.com
• Randy Gaul – randygaul.net
• Allen Chou – allenchou.net
• Christer Ericson – realtimecollisiondetection.net

Stay tuned for more updates!

Last time we talked, I was working on Falldown in Python. Since then, I’ve switched over to C++. I switched because I got as far as I wanted to go in Python; but, my end game was always to write the game in C++.

Now that the code is in C++, I have been working at incorporating some best practices of game development. One particular best-practice that I spent some time implementing is a fixed simulation timestep. I applied a technique that a game developer, named Glenn Fiedler, described on his blog. I will not rehash what he wrote, because (a) I couldn’t say it better than he already did, and also (b) his blog deserves a read-through (well, after you read through my blog). However, I will attempt to show you what it looks like.

In my code, the fixed timestep is .016 s. On my machine, Falldown can render anywhere from 800 to 1000 frames/sec, which means that the system spends anywhere from .001 to 0.00125 seconds drawing. In words, the game can render a frame 12 to 16 times in between each simulation step. To figure out what to draw in between simulation steps, the game interpolates between the latest known simulation state and the previous known state.

The green outlines in the animation above represent the latest-known simulation state. You can see that the green outlines update not-that-often, relative to the rendering refresh rate. The ball and the rows appear to “catch up” to the positions of the green outlines.

Stay tuned; I still have more work to do.

I fixed the collision detection (yaayyy)!! How I fixed it: I reduced the time step of each frame in my game loop, and I fixed the order of the game loop. If that sounds like gibberish now, hopefully it won’t by the time you reach the end of this article.

First, let’s talk about the game loop. In short, the game loop is a repeated sequence of steps the game program follows. For Falldown Rebirth, the game loop is something like:

1. Process input
2. Move the Falldown platforms
3. Move the ball
4. Check for collision
5. Process the collision
6. Draw the frame

Step 1 takes the controller input (right now, the “controller” means the keyboard). Step 2 moves the platforms up the screen. Step 3 accelerates the ball based on the force of gravity in the game, as well as the controller input from Step 1. Step 4 then checks to see if the ball is touching/overlapping a platform. If so, then Step 5 “processes the collision.”

In this game, “collision processing” is as simple as tweaking the position of the ball so it does not overlap with whatever platform it is touching. To keep things simple (and also arcade game-like), this game does not calculate momentum. As a result, there is no bouncing or anything that resembles a realistic physics simulation (except for the depiction of the ball rolling). In a more complicated game, collision processing might include figuring out how hard the ball bounces off of a surface, or some other response.

Once all that is done, the program draws everything to the screen, and then runs the loop again.

So where does the aforementioned “time step” come into play? The time step determines how far the ball and the platforms move during steps 2 and 3. The smaller the time step is, the less movement there is in each frame, and the more accurate the collision detection is. There is more to it than just that, but for now, reducing the time step fixed the problems I had. So now, the game looks like this:

(Side note: I know the video looks choppy. It’s the best I can do right now; I can’t find a screen recorder that captures smooth videos of my Pygame windows.)

Hopefully, this brief overview explains what I’ve been up to. In future revisions of the game, I want to implement more robust collision detection to handle a fast-moving ball and fast-moving platforms.

Stay tuned!

Also, if you’re interested, the code for the game (well, at the time of this writing, most of the code for the game) is up on my GitHub page.