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!

I figured out why my game was running so slowly!!  The solution was to install Bumblebee.

The Bumblebee I installed is a software package that takes advantage of NVIDIA’s Optimus Technology.

Optimus is NVIDIA’s proprietary, battery conserving, “hybrid” graphics technology. It optimizes battery life by switching between 2 video processing chips: (1) an all-purpose,  power-conservative chip, and (2) a dedicated, high-performance (and power-hungry) graphics chip. Optimus defaults to running programs on the all-purpose chip and disabling the high-performance chip. When higher graphics performance is needed, Optimus switches automatically to the high-performance chip.

Unfortunately, as far as I can tell, NVIDIA does not support Optimus on non-Windows operating systems (even my laptop’s BIOS setup screen said to enable Optimus only with Windows XP/7/8).

However, not to be defeated or excluded, smart Linux nerds created Bumblebee.

Bumblebee solves the performance issues with my game because it does not use the stock nvidia-libgl package. Instead, Bumblebee uses the mesa-libgl package that I described as running my game fast. Yet, it still enables fast 3D performance, using what appears to be a customized revision of the nvidia-libgl package. Bumblebee seems to address whatever issue  was in NVIDIA’s own GL library files that caused slow performance in my game.

The only (minor) drawback is that Bumblebee does not support automatic switching from the Intel chip to the NVIDIA chip. To use the NVIDIA, I have to prepend a specifier in front of the command for whatever program I want to run. For example, what used to be “playgame” is now “optirun playgame.” The “optirun” specifier causes Bumblebee to work its magic and use the high-performance chip.

All things considered, that is a miniscule issue, and I don’t mind manually controlling the graphics chips. It’s part of being a badass.

Mass KonFuzion out.

This is part 2 of a long rant that should I have written in smaller, more frequent updates, over the past year or so. In part 1, I described the Linux laptop that is the subject of the rant you are about to experience. It is worth a read.

I have been using the aforementioned laptop for game development because I want to see how far I can push it. It is by no means a powerhouse; it has a modest Intel Core i7 at 2.4 GHz with 6 GB RAM and an NVIDIA Quadro NVS 4200M video chip. The main CPU can be clocked faster than 2.4 GHz, but then it runs disconcertingly hot. The graphics chip is meant for business, not games. Yet, I accept the modest specs because I am making a game with the simplest graphics possible.

But now, I am encountering problems with my graphics rendering that I hadn’t noticed before, because until now, I hadn’t been concerned with graphics performance.

In troubleshooting, I found that, as usual, there are a number of different ways to get graphics working on Arch Linux with an NVIDIA graphics chip. Those links only point to the graphics drivers themselves. They do not relate to the graphics standards that software/games might be built with. In Linux, the options are, essentially, OpenGL (which has been around forever) and now Vulkan (which is new, circa Feb 2016).

If you looked at the content behind the links (though you weren’t expected to), you probably saw instructions to install mesa-libgl or nvidia-libgl, depending on which driver is installed. Those libgl packages contain different implementations of the OpenGL standard. mesa-libgl is open-source; nvidia-libgl is NVIDIA’s proprietary package.

Apparently, the two packages behave differently…

(As an aside, I mentioned before that my game engine is based on OpenGL. Therefore, now that Vulkan is here, I am technically using outdated technology. That is ok for now, because that outdated technology is well-established and well-supported.  The point is: Even though I am aware of Vulkan’s existence, I will focus on OpenGL for the purpose of this rant. One day in the future, I may write a different rant about Vulkan + Linux.)

My 2D game with runs smoothly with mesa-libgl, as it should, because the graphics are rectangles and circles. For reference, it looks like this:

However, with mesa-libgl, more fully-baked games (i.e., some Steam-powered games, and especially 3D games) run like a snail sliding on a molasses.

On the flipside, when I install nvidia-libgl, Steam games, other 3D games, and for that matter, other 2D games that aren’t mine, run perfectly.  But with nvidia-libgl, my game runs like a turtle climbing a mountain.

Here is a clip of the exact same game, running with nvidia-libgl installed, instead of mesa-libgl. Nothing else has changed, and the video is not doctored in any way:

I am not exactly sure what is causing the performance discrepancy. I will investigate it, figure it out, and report back.

Problems like this highlight my computer’s status as a bad game development machine. Every now and then, I have to spend an awful lot of time troubleshooting issues that are not related to the game itself. But, because I am a badass masochist, I wouldn’t have it any other way.

Mass KonFuzion out.

 

P.S. I hope this blog is detailed  enough for experts, but accessible to beginners. Basically, if my wife can follow along, I’ve done a good job. But if you think I’ve done a bad job, let me know in the comments.

My computer is a terrible system for game development system, and I am foolish for using it. Let me explain…

I installed Arch Linux on my laptop.  I did that because I wanted to be a bad-ass. I wanted 100% control over every software application, every device driver, every bit of firmware.. Basically, I wanted to learn a metric ton of information, partly for myself, and partly so I could teach it to other people.

So far, my mission has been largely successful. I’ve essentially hand-built my system. In the process, I’ve learned just how many tiny components power a computer system, and how many of those components simply work on Windows PCs/Macs, right out of the box. The number is shocking. For that matter, even certain other Linux distros–Ubuntu et. al.–“just work”.

But as I said, I wanted to be a badass, and Arch is a Linux distro for badasses (i.e., masochists).  With Arch, if you didn’t explicitly install a thing, then that thing is not on your computer. That includes components you needed, but weren’t aware you needed, because those components come installed on most computers by the time they reach your hands… To describe a few concrete examples of what I am talking about:

• By default, Arch is just a command line; it does not come with a windowing/GUI component. I chose exactly which desktop environment/window manager to use (XFCE4), which involved manually tweaking some config files and/or adding plugins to get the taskbar to look right, and to include things you’d expect to see, such as a clock, calendar, battery monitor, volume control, etc.
• I installed Microsoft fonts because the default fonts in Arch look like actual crap. I also fought with font rendering to get the equivalent of ClearType in Windows. Without font smoothing, my display looked jagged and uneven.
• I auditioned one sound system, and then another sound system, before figuring out exactly how the crap to set up the sound system to play audio from 2 or more programs at the same time. That’s not even an inherently useful activity (why would I need to listen to an MP3 at the same time as I’m watching a YouTube video?), but it’s something that other computers I’ve used just simply do.
• I wrangled wireless drivers and firmware. Anyone who has configured wifi on a Linux computer knows the struggle.. Seriously, read the wiki. I mean, don’t read it, but just look at it..
• I discovered that the default mouse driver didn’t work with my laptop’s touchpad, but it did work with track pointer thing. It turned out that installing a different driver worked perfectly.

I hope you haven’t been slow-reading each one of those links. But if you have been, you’ll notice that every problem encountered in Arch has at least 2 possible solutions. All of the possible solutions might work, with varying levels of compatibility with the rest of the computer’s software/hardware. As the system administrator, I have had to research the solutions and figure out which one would work best for my computer. The Arch Linux community is large and immensely helpful, but it also values self-sufficiency.

Again, I have learned a lot. But damn, Linux is annoying.

You may have noticed that this post did not talk much about game development. That is why you should read part 2!

 

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.

Blurrgghh!!!!

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!

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.

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