About Travis

Just another blade of grass billowing in the breeze.

The Back Burner #2 – Turnit

Being a fan of old-school arcade games, I spent a lot of time playing through various classics via MAME as a younger human. The Classic Arcade Hall of Fame would include such venerable hits as Galaxian, Pac-Man, Asteroids, Missile Command, and so on, but I found myself strangely drawn to the oddball games that didn’t receive the acclaim that the aforementioned garnered (rightly) with ease from casual and hardcore gamers alike.

One game that I stumbled upon during one of these many late-night, bleary-eyed MAME-athons was Cameltry. (I’m not totally sure on the pronunciation. I’ve vacillated between pronouncing it “camel-tree” and “camel-try” at various points, depending on the weather and the alignment of the planets.)



The object of Cameltry is simple: roll the ball around until you reach the exit. If you don’t reach the exit before the clock hits zero, it’s game over. There are various obstacles along the way, such as breakable blocks and tiles that sap precious seconds away from the timer. It’s a short game, but it definitely provides an ample amount of fun.

With Cameltry in mind, I set out to create a worthy homage. Turnit was the result.


Turnit title screen

The basic idea of the game would be essentially the same as in Cameltry. You would rotate the world in order to maneuver the spherical character toward the exit. In Cameltry, though, you just had to beat the clock. With Turnit, I was wanting to have a collection aspect, where you would be required to collect a certain number of items in order for the exit passageway to be unlocked. I was hoping this would allow me to construct more puzzle-like levels, since the player would have to go searching through the nooks and crannies of each stage in order to grab the necessary items. This was possibly a mistake, since this extra complexity slowed the game down somewhat, making it less of a fast-paced arcade experience and (slightly) more of a considered experience. I never made it close enough to the finishing line to make a definitive assessment on this, however.

Rotate that playfield like you mean it!

Rotate that playfield like you mean it!

Like Cameltry, Turnit is mainly tile-based (though underneath, it uses polygons for collision detection). To add some spice to the game, there would be time-sapping blocks, breakable tiles, laser beams, rotating beams, gears, magnets, pinball bouncers, and possibly some more that I would add later. Hitting a time-sapper would, as in Cameltry, knock a few seconds off the timer and bring you a little closer to your demise. The magnets would either cling you to them or repel you away, depending on their label. One cool feature that I thought would add some interesting puzzle elements was the colored spheres. These would roll around the level the same as the player, only they would unlock matching-colored walls if they were fitted into the appropriate slot. It’s a simple thing, really, but it seemed like this feature by itself would greatly increase the possibilities as far as designing intriguing levels and paths through which to roll.


Lots of stuff to roll around, through, and between…

Of course, as is the usual course of these things (and the main reason for creating these Back Burner diaries), I stopped working on the game for a couple of years, and it receded noiselessly into the background. Once I was finally able to begin working on it again, I ran into some difficult bugs that I wasn’t able to iron out to my satisfaction, which kind of soured me on the whole thing. This was partly due to the fact that I was using a few different libraries (Chipmunk, OpenLayer, and Allegro), some of which had become incompatible with later versions of the other pieces. Todd helped me quite a bit by creating a version that worked with Allegro 5, but by that time I was ready to throw in the towel.

Saying goodbye to Turnit was kind of bittersweet for me. I thought it could have been a pretty awesome game if it was competed. It was one of the few games I ever worked on (along with vGolf and Dot to Dot) that I just really enjoyed playing. There was a lot of potential here, but alas, such is the way of things.

Below is a video of the last version that shows a brief glimpse of Turnit’s gameplay. The frame rate is off a little bit, so it looks slightly sped-up, and there is no sound. Until the next episode…

The Back Burner #1 – Cloud Skipper

Anyone who has programmed or done any kind of work for any length of time has what is often referred to as the “back burner.” It is here that projects that one has lost enthusiasm for working on or have grown beyond their intended scope (or insert other excuses here) are placed, to be worked on at a later date. Unfortunately, as many have discovered since the microprocessor was first unleashed on the world multiple tens of years ago, this later date often never comes, and so these projects end up languishing. There they sit, in a directory we used to browse through daily and whose contents we knew intimately, gradually fading from our priorities until they eventually wither and fall off the stem. Years later, we stumble across an old .zip file filled with source code and graphics, and we’re reminded of what could have been had we had the tenacity to finish the job, right before we go back to the more pressing concerns of the present day.

The preceding paragraph was an overly verbose way of saying that there’s a lot of stuff that we start but we never finish. Cool ideas dissolve into the mists. Bleary, dark-circled eyes stare into the distance, perhaps as the brain they’re attached to imagines what these ideas would have formed into if they were given a chance to blossom.

There are several projects in the archives of T³ Interactive that have sat lonesomely on that back burner for many years. One such game is Cloud Skipper, a simple Java-based arcade game inspired partly by Icy Tower.

Cloud Skipper Title Screen

Title screen for Cloud Skipper

The goal in the game would be simple: reach the upper layer of the atmosphere without falling to your death. This climb could be achieved by leaping from cloud to cloud, reaching progressively higher altitudes. There would be no scoring other than the current altitude and a timer that would record how long it took you to make the journey. Cloud Skipper was destined to be an arcade game in the strictest sense, at least as I originally envisioned it.

Game Mechanics

The gameplay in Cloud Skipper would be very arcade-like, with a player-controlled sprite who would skip along the clouds (hence the name) as he made his way skyward. You begin each game on the ground, and the only thing you see are random clusters of clouds floating across the playfield. The catch is that once you land on a cloud segment, that piece of cloud will disappear, forcing you to leap to another one. In theory, this would increase the action and force the player to continually move. You get about half a second or so once you land on a cloud segment before it evaporates, so you have a bit of leeway, but not that much. Once the player reaches an altitude of 20,000 feet, he wins the game. If you manage to fall off the bottom of the screen at any point along the journey, you’re met with the dreaded Game Over.

Cloud Skipper in-game 0

Starting at ground level…

I decided to simplify things and make both the cloud segments and the player circular. I did this for two reasons. One, detecting collisions between circles is pretty straightforward, and I already had collision-detection code for circles from previous projects (vGolf and Dot to Dot, and probably some other ones I’m forgetting). Two, making everything circles would simplify the leaps for the player since they would be aiming for objects with uniform shapes (with differing sizes) throughout the adventure.

One thing you’ll notice if you play the game is that the clouds wrap around to the other side of the playfield once they go off the right edge of the screen. This ensures that there will generally be at least somewhere you can leap to, though it may be difficult to do so successfully, and if you just miss hitting a cloud segment before it glides past the edge, you’ll always have another shot at it once it reappears on the opposite side.


The graphics for this game were meant to be very simple and cartoon-y. In fact, everything that shows up on the screen during the main game (with the exception of the player sprite, the Game Over image, the moon, and the victory sequence) was created using Java graphics primitives. As you scale higher and higher, the background gradient darkens, signalling the thinning of the atmosphere, and the moon’s visibility becomes more prominent. As you can see from the screenshots, I decided to make the playfield more vertically oriented, since the game is focused on continuous upward movement.

Cloud Skipper in-game 1

Movin’ on up…

The HUD is rather sparse, but the player doesn’t need that much information in this game. To the right is a gauge that indicates how high up you are presently and how much further you have yet to ascend. There are two white lines on this bar, one showing the current highest-reached point, and the other demarcating how far you can fall before you drop off the screen and to your death. Centered at the top of the screen is a display of the current altitude, in feet, and the current time elapsed in this game session.

Cloud Skipper cloud segment

Highlighting the cloud segments

I wanted to make sure that the cloud segments were differentiated so that the player could discern when he’s standing on one specific segment. Since I made all the clouds in the game white (possibly a bad decision), I decided to add little gray arcs along the top of each cloud segment to make the division between them clearer, especially in large bunches.

Cloud Skipper Game Over

That guy looks familiar…

When you reach 20,000 feet and land on the top of the atmosphere, you’re treated to a little dance by Cloud Skipper‘s rotund hero, and the moon in the background sends a cheesy grin toward you across the vacuum of space.

Cloud Skipper victory

Time to celebrate!


I had a lot of fun working on this one, and it may not technically be considered “on the back burner” since the main game itself is basically complete. The gameplay is a little rough, because there are many times where you will land on one cloud segment and several adjacent segments will disappear all at once, putting you in immediate peril. Plus, the randomness of the clouds means winning isn’t always a matter of pure skill so much as getting lucky in the cloud placement. It is somewhat entertaining, though, and I think it could have been molded into something better if I had the time and inclination to smooth out the rough edges.

If you have the Java browser plug-in installed, you can can play it here if you so choose. The controls are the left and right arrow keys and Z to jump. (For testing purposes, I left these cheat keys enabled: W for a big jump and Q for a massive jump.)

Thanks to Todd for giving me the idea to do this write-up. Until next time…

The Art of Explosions

Since man first began to yearn, he yearned to blow things up. Once man began to create video games, he yearned to replicate blowing things up digitally.

When it comes to action/shooter games, great gameplay is generally what differentiates the fun and memorable from the mediocre and forgettable. To me, though, one crucial element to a great shooting game is the feedback you get while destroying your foes. This feedback mainly comes in the form of explosions.

In my mind, there are three key parts to a masterful explosion: the sound, the animation, and the particle effects. Of course, there are other things to bear in mind when it comes to the pure atavistic joy of blowing things up, but when I consider all the many explosions I’ve encountered within the confines of video games, the best ones excel in each of these areas. I’ll break these down in the following article.

1. The Boom

Without a good BOOM or BLAM or KABOOM (or insert whatever explode-y sound you like here), the destruction of a baddie feels weak and unfulfilling. The more earth-shattering and booming with bass the sound effect is, the more satisfying the explosion. When I shoot an enemy fighter ship down with my fully-powered plasma cannon, I don’t want to hear a *dink* or a *thunk* or a *thwip* or any of those tinny sounds that one might hear if he were to kick a stuffed animal. I want to hear a visceral, thunderous sound that will make all the world’s denizens quake in fear of my unbridled might.

2. The Animation

When talking about 2D sprite-based games, a good explosion animation will generally involve flames or some sort of flame-like construction. I’m guessing this is because we’re all familiar with fire and its destructive capacity, and thus most reality-based explosions include an element of flames. You can do explosions without flames (see Geometry Wars), but in all likelihood, an enjoyable explosion will involve the orange, lapping fingers of the goddess of destruction.

Tatsujin 2

A nice mushroom cloud. (from Tatsujin 2)

A slick game explosion should mimic the actions of a real one. It starts with a small spark in the middle of the enemy (or at the point where the projectile strikes the baddie), then mushrooms out to its fullest extent, before the flames dissolve into the empty space where the now-deceased enemy used to be. Some like to put arms of fire that blast outward from the explosion’s center and possibly rotate slightly as they evaporate, an effect that I personally endorse, but so long as the central mass of the explosion is filled with a brief, blinding flash and a thick veil of fire, it has the makings of an agreeable decimation sequence. It’s also worth considering including ancillary explosions, either within the central mass or along the periphery. These extra blasts serve to emphasize the main devastation while not overpowering it.

Raiden DX

Yes, please… (from Raiden DX)

Another thing to bear in mind with explosions is size. A good explosion should be at least as large as the object you’re decimating, but preferably somewhere between 1.5x and 3x its size. The reasons for this should be apparent, of course. Firstly, an explosion must, by definition, be as large as or larger than the exploding target, or else it would be an implosion. Also, it just doesn’t feel right, to speak non-technically, when an object you’ve been blasting away at just pops and fizzles inward like a deflating balloon (unless, of course, the enemy is a balloon). When it comes to size in this arena, bigger is almost always better. (This may not be 100% true, though, especially in shoot-em-ups with lots of enemies on-screen. It might be best to limit the hugest explosions to the bigger, more important enemies, like bosses, to keep the screen from becoming too cluttered.)

3. The Particles

I’m not going to lie: I really like particle effects. So perhaps others might not see particles as being as important to explosion-y goodness as I do. I believe that particle effects really help to flesh out explosions and make them more exciting and fluid, while also adding an element of randomness that makes everything look more organic. Particle effects are like the sprinkles on a piece of cake. Sure, the cake can be just as delicious without them, but having sprinkles gives it that extra bit of sweetness and crunch that can push it over the line from “Yeah, this cake is good” to “Ooh, this is some great cake!”

Geometry Wars

Avast! There be particles! (from Geometry Wars)

Particle effects are also fairly straightforward to implement in most cases, and particle-handling and display code can generally move between projects relatively easily with minimal change. Even if you’re just using primitive shapes, like single-colored rectangles and circles, the randomness these particles exhibit makes them visually appealing and adds greatly to the experience of destroying things. These particles don’t necessarily need to be primitives, of course. They can be animated sprites of their own, like rotating debris or mini explosions, or even just lighting effects that disperse outwards. Whatever the case, the more particles there are, the more heightened the sense of frantic action and intensity, which creates a more enjoyable gaming experience.


The destruction of bad guys is as crucial to the life of a shoot-em-up as blood flowing through a human’s veins. If it’s done well, it can result in some awesome experiences that are hard to replicate in other entertainment mediums, like television and movies. A good visual and aural response to obliterating an on-screen foe really amps up the connection between the player and the action that’s happening on the screen, which makes the destruction that much more visceral and pleasing.


In the mid to late ’90s, I burned a lot of time in front of one computer or another, and a large amount of this time was spent within the confines of MS-DOS. It’s obviously not the best operating system around, but it’s what my first PC had, and it was simple and straightforward once you knew the commands and were familiar with the little nuances.

LIST is a file viewing and browsing utility written by Vernon D. Buerg, who died in December 2009. It’s simple enough. You type LIST at the command line and a nice, columned view of all the files in that directory fill the screen. You navigate between files and directories by using the arrow keys to move the cursor around. Hitting enter on a directory enters that directory, while hitting enter on a file opens that file up for viewing. Hitting the ESC key goes back to the file listing or back to the command line, depending on whether you’re viewing a file or not. There are also other commands, such as hitting E to edit the file using EDIT.COM, Microsoft’s DOS text editor.

Viewing files in LIST

This program was great when having to sort through several files and view their contents, especially text files. Just hit enter on the text file and the text immediately displayed on the screen, then hit the arrow keys or PGUP/PGDN to scroll through the file contents. Hit ESC to go back and browse through the other files in the directory.

One nice thing about LIST is that it shows the file regardless of whether it’s a text or binary file. In modern operating systems and desktop environments, this isn’t generally the case. This allows you to check for text strings within the binary that can give you a useful indicator of what the binary file is and does. An example of this being handy is in the case of some old DOS games. Some of these may have had music that was in, say, MOD format, but the music files would be named something like MUSIC00.MUS. By using LIST, you would be able to see the file’s header string and determine that yes, this is a MOD file, and now you can rename it to MUSIC00.MOD and open it up in your tracker of choice.

The header string for a DOS executable is “MZ”

Of course, now a program like this may be seen as (and probably is) a relic of the past. It’s a great example of the “do one thing and do it well” philosophy, though, and its capabilities haven’t really been replicated in any other utilities I’ve come across for modern OSes like Mac, Linux, and Win 7.

LIST’s primary job is in its name: to list files. It does that job efficiently and doesn’t get in the way. So thanks to LIST for all those nostalgic, rose-tinted memories of sitting in front of a screen of brightly lit text on a black background for hours on end, reading text files, rummaging through subdirectory after subdirectory, and checking to see if that .GSZ file is really an .EXE.