Projects‎ > ‎


Continuing the mistakes I made with Twinz and Man With Backpack into the year 2011.

Technical Details

SDL and SDL_mixer


For some reason, I still haven't learned my lesson after Twinz and Man With Backpack (i.e. that I should not be allowed to continue making games) and so I recently decided to do another "Game In An Afternoon" project, wherein I don't plan anything in advance and just make stuff up as I go.

Sometimes this results in a semi-playable game. In this case, it resulted in Robotron without shooting.

I took inspiration from games such as Blast Arena, Robotron and Man With Backpack when I noticed that the core thing about their game-play is that they were very spare in terms of graphics. Nothing on-screen was unnecessary - everything was there for a specific game-play related reason, and there were no "environmental" features such as walls or other inert elements. The top-down view allowed the entire screen to be used as "game-play space" and the aforementioned lack of walls made it seem as though there was more of it than usual.

How to Play

The goal of each level in turboburger is to collect all of the various items scattered around the screen whilst avoiding the monsters that are constantly chasing you. Once all of the bonus items have been collected, the monsters will start to die, one at a time, until they are all gone. Once this happens, there is a short period of time before the next level begins in which you can do stupid things such as drink poison in order to ruin your score.

Player 1 uses either WASD or the arrow keys to move. If a joypad is detected, two-player mode is enabled.

There's a download link below - just be aware that there aren't any "real" levels yet.

Feel free to make your own...

Creating Levels

The level format isn't difficult to figure out. It's a plain-text .CSV file that can be edited with either a simple text editor (such as gEdit or Notepad) or a spreadsheet program (such as Calc or Microsoft Office Excel), depending on which you have/prefer to use. Each file contains a one-line "header" followed by a list of "actors" that should be created.

In a spreadsheet program, the header line looks like this:

 Level name (top line)
 Level name (bottom line)
 Next level file name.

...and like this in a text editor:

"Level name (top line)","Level name (bottom line)","Next level file name."

Every other line is in the format [Type][X][Y], with [0,0] being the top-left corner of the display and [640,480] being the bottom-right. Note that the border is 32 pixels thick, and so you can't place anything with an X or Y coordinate of less than 32. If you were to place an actor at [0,128], they would be pushed back into the playing area and appear at [32,128] instead.

For example, a typical level file might look like this:

 My custom
level file
 burger 6464
 skull 128128
 poison 64128

...which would look like this in a text editor:

"My custom","level file","level/map2.csv"

Possible actor types are:

burger - 10000 points. This is the titular turboburger.
pizza - 1000 points.
disk - 100 points.
jewel - 10 points.
money - 1 point. Hackers take note: Any undefined actors behave like coins do.
poison - Won't actually kill you, but will take 1000 points off you.
skull - Kills you on touch. Generally targets player 1. Can't go through other objects.
ghost - Kills you on touch. Generally targets player 2. Can go through other objects.

Note that these must all be in lower case or they won't work.

Bugs, Glitches and Other Unintentional Features

Due to the way in which I was adding code almost at random whilst making this game, a few bugs crept in. I think I've fixed most of them, although there is one which I intentionally kept.

Since skulls always chased the first player in the actor list (i.e. player 1), player 2 was pretty safe. In order to remedy this, I added ghosts. Ghosts behave almost identically to skulls, except they search through the player list backwards. This means that they will find player 2 first if more than one player exists.

Thinking that this wasn't enough to make ghosts different, I decided to get rid of the collision checking that prevented skulls from going through other objects. This meant that skulls were still unable to go through other things in the world, but ghosts could now go wherever they wanted - including through skulls. The problem was that skulls would now detect a collision with the ghost and get stuck inside them, unable to move until the ghost moved away.

I could fix this (all that would be necessary would be to have skulls ignore ghosts when checking for collisions) but I decided to keep it in, with the explanation that even the skulls were frightened of the ghosts and became scared stiff if they got too close.

There was another side effect to this change. The collision code was originally added to prevent skulls from moving inside each other, so that they stacked up into what appeared to be a single skull. Since ghosts aren't restricted this way, ghosts can and do "stack up" if the player steers them into a group.
SelectionFile type iconFile nameDescriptionSizeRevisionTimeUser

Version 1.0  1640k v. 2 22 Dec 2010, 02:51 Go Busto