A New Menu For You

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

Extremely Rudimentary Main Menu

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!

Falldown is Shaping Up

(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:

Stay tuned for more updates!

Oh Yeaahh! Fixed Timestep, Yeah!!

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.

Falldown Interpolation Demo

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.

It’s Working!

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.

Gah!! Faulty Collision Detection!!

Falldown is coming along.. But baaauugghhhh!!! There are errors with my collision detection! If the ball is at the left-most edge of the screen when it is falling, it might fall straight through the rows. This video illustrates what happens.


The error only happens on the left side of the screen, but not the right side..

But, with a little help from my friends (and their books), I’ll have a fix in no time.

And then I’ll blog about it.

Stay tuned!

What Is Falldown?

Falldown is a game that, as far as I know, originated on the TI-85 calculator. I never owned a TI-85, but I had Falldown on my TI-83 (which, despite the decrease in numbering, was released a few years after the TI-85). But I digress..

Falldown is essentially a reflex game. You control a ball; the game spawns a never-ending series of rising platforms, with gaps randomly scattered along each platform. The goal of the game is to achieve the highest score possible by guiding the through the platforms by rolling it into the gaps. When the ball reaches a gap, it falls down to the platforms below it. However, if ball is pinned against the top of the screen, the game ends.

Points accumulate as long as the ball is still rolling (i.e., not smashed). But also, the longer you “stay alive,” the more difficult the game becomes. The difficulty increases in two ways: 1) By decreasing the space in between platforms and 2) By decreasing the number of platforms on each row. Here is an example of what Falldown looks like on the calculator:

It’s brilliantly simple, yet addictive; casual, yet surprisingly difficult.

I’m remaking it for several reasons:

  1. It’s my one of my favorite video games
  2. It’s simple
  3. It’s entertaining
  4. I didn’t want to make a Pong or Breakout clone;

all of which are great reasons. But more importantly, programming Falldown exercises serious programming skills:

  1. Object-Oriented Design/Programming
  2. Game Flow Control
  3. Simple physics
  4. Collision Detection/Response

My version looks like:

(It’s not that pretty-looking right now, but it will be)

I’m hoping to make my take on Falldown (titled Falldown Rebirth) as fun and addictive as I found the original calculator version. I will keep blogging about the game and the things learn along the way.

Ultimately, Falldown Rebirth is a pet project that I am programming in Python, using Pygame. I haven’t decided how to distribute it yet, but if there is interest, I’ll make it available.

Falldown Is Reborn

It’s been a little over a decade since I last put any real effort into game development. A decade!! That’s absurd, and I finally have done something about it. Behold Falldown Rebirth:

Falldown Rebirth – Play Demo

The game isn’t fully-baked yet, but it’s on its way. What it has so far:

  • Fixed-timestep Physics Simulation
  • Physics decoupled from graphics frame rate
  • Collision Detection
  • Crazy-rudimentary collision response

What it still needs:

  • Game levels (controlling the rows)
  • Difficulty levels
  • Pretty graphics
  • Powerups/powerdowns
  • Fun