This is a discussion of my Falldown submission for Low Rez Jam 2016. Some vital stats on the game:

• Programming Language: Python 2.7
• Toolkit: Pygame (yes, the old, tried & true Pygame)
• Editor: Vim
• Platforms Supported: Windows, Linux

What Went Well

Finished Game

First and foremost, I finished a game! To boot, Low Rez Jam marked my first-ever game jam. Nevermind the fact that Falldown x64 is a rehash of a project I have done before. I still finished and released a game.

“Quantum Mechanics”

My favorite design feature is the concept of an “update delay”. The idea is: every object in the game is “eligible” to move only after waiting a certain amount of time. In other words, there is no concept of “velocity” in Falldown x64. Objects do not move a certain number of feet per second, or miles per hour, or any other “speed.” Instead, objects move exactly 1 space (i.e., 1 “quantum”), after a given time interval. So, a fast-moving object (like the ball) simply doesn’t have to wait as long to move as a slower-moving object (like the row of blocks the ball is rolling on).

That design greatly simplified collision detection. There is no “bullet/tunneling problem” in Falldown x64. Collisions are reliably handled with simple overlap tests.

Cool Score Splash Messages

I like how score updates turned out. Every time the ball passes through a gap, a score update pops up on the screen. That score update is driven by event-based messaging in the game engine. The game detects a collision between the ball and the  gap, and queues up a message for the Text Display Manager. The Text Display Manager processes the message and puts text on the screen.

Cross-Platform Support

Falldown x64 is cross-platform because Python and Pygame are cross-platform. I used cx_freeze to ‘compile’ the Python scripts into executable files.

I am only missing a Mac build. The reason is: cx_freeze can only produce executable files for the platform it runs on; it does not cross-compile (e.g., make a Windows executable from a Linux computer). But I don’t own a Mac. Does anyone want to donate a Mac I can use to create a Mac build? 🙂

What Went Not So Well

I should preface this section by saying: All things considered, my 1st game jam was a success. The points that follow describe what would have happened ideally. Having said that, the discussion of what went not-so-well can be summed up as, “I didn’t finish pretty much anything that makes a game a game.”

I went into the Low Rez Jam wanting to make a game with features:

• a fun, challenging difficulty curve
• retro 2D visual effects (maybe a particle system)
• nostalgic retro sound effects & music
• interesting gameplay elements (e.g., powerups, powerdowns, traps, etc.)

The game I made has none of that stuff. For starters, I began development almost a week after the jam started (even though I registered for the jam on time). I was not procrastinating; life happened. Once I did start, aside from a few days of “controlled burn,” I did not spend as much time developing the game as I could have under different circumstances. Still, I had ambitions to design good code, review it iteratively, tweak it, then add awesome gameplay features. Then, before I knew what happened, I would have a runaway hit that would pay my mortgage!

That didn’t happen. The reality was that I barely finished; I submitted the game less than 5 minutes before the deadline, and I was scrambling just to turn in a working program. I am happy that I finished, but I still learned a few lessons:

Start With Better Code Structure

I started off by prototyping a few things that I needed to work out in “draft” mode. At that time, I wasn’t concerned with my code design, so I did not organize my code as well as I could have. When the time came to begin development in earnest, I ended up simply continuing from my poorly laid-out “draft” mode code.

The code I wrote certainly worked, and it was rooted in knowledge I’ve gained from reading books and watching videos made by the experts. However, the structure of my code did not scale well. That left me scrambling to organize code mid-project when I could have been more productive in other areas. I know better, and I should have started off better.

Implement Messaging

I’m not talking about messaging as in Facebook Messenger; I’m talking about game subsystems messaging other subsystems.

A well-designed game (even my own Gamma Engine) enables systems to place messages in a central message queue, to be picked up by other systems. For example, with a message queue, a collision detection system can leave a message for the sound system, to trigger a sound effect when Thing A collides with Thing B. Using messaging in this way provides flexibility in handling various events that take place.

Unfortunately, I did not leave myself enough time to implement messaging the way I wanted to. As mentioned above, the score update and “Level Up” text displays do use messaging, but I should have incorporated messaging all across the board.

Include “Game Stuff”

A game should have non-playable, but still necessary, “game stuff.” Such stuff includes an introduction, main menu, setup options, in-game pause, credits, and any other elements that are expected in the software of a video game. I did write the game code with math to enable the game to be played full-screen, or in a window scaled from its original size. However, I didn’t have enough time to implement and test window resizing.

Add Sound and Effects

Of all the features I didn’t get to in trying to meet the Low Rez Jam submission deadline, sound is the most disappointing. I had ideas for audio that would have added retro ambience and flair to the game. Had I fully implemented messaging, adding sound would have been trivial.

Playtest

I didn’t playtest the game at all. As a result, the gameplay and difficulty curve are not balanced.

The lack of balance is directly caused by my not leaving enough time to add finishing touches. I wanted to program the difficulty so that, as the player progressed, the rows moved faster and also the spacing between each row decreased.

I was working on the difficulty curve on the last day of the jam, and I ran into some problems during my last-minute push to finish the game. As a result, I had to leave out the row spacing tweak. I also had to leave the gameplay largely unrefined.

Conclusion

Despite everything the game is missing, I am still proud that I accomplished my goal of finishing and releasing the project. Next goal: release a quality product 🙂

As for Falldown x64, I may decide to update the game to fill in the gaps, and I’m also pretty sure I’ll put the code on GitHub. And now that my feet are wet, stay tuned for more games!