WordLeap Postmortem


It was a couple of years ago when I first laid my eyes on what would become WordLeap. As often happened when I was visiting Travis, we started talking about the things we had been working on. Travis showed me one of his unfinished projects titled Vocabuleaper.


I was quite impressed with Vocabuleaper as soon as Travis started showing me how the game played. It immediately struck me as a game that I would like to see finished. After seeing how our recent collaboration on vGolf turned out, this project seemed like another perfect project for me to finish up. I was focused on developing Paintball Party 2 at the time, but I made a mental note of my desire to work on this project at a later date.

Pretty soon after that I began hearing news of a new indie game marketplace called Indievania. In the mean time, there was talk among the Allegro developers of an Android port. Vocabuleaper seemed like a perfect fit for mobile devices. I figured I could work on a PC version of the game and release it on Indievania. By the time I was done with that, Allegro would be ported to Android and I could release a mobile version.

With motivation in place, it was time to start thinking about how to take Vocabuleaper from its current state into a finished product. I quickly whipped up a prototype to get the ball rolling on this project. It was at this time that I decided to title the project WordLeap, so named because I vaguely recall Travis mentioning that WordLeap was an alternate title and the game files suggested to me that was also the case.


After I had the basic game implemented, I started to think about features I would like to see in a game like this. The original game was about the challenge of making awesome words and trying to get the high score. While I would consider a game like that complete, I wanted to try something I hadn’t tried before.


A few years ago I played a game called Hotel Hell which left an impression on me. That game, though quite simple and short, had some elements which made me feel like I had been somewhere. Hotel Hell was a memorable place to me, so memorable that I consider it a good game despite the mundane gameplay mechanics.

While I couldn’t quite place exactly what made the game that way for me, I was able to hone in on the feeling I got from it and associate that with some of the other memorable experiences I have had in gaming. The Metroid Primes are good examples of the kind of games which made me feel like I had been somewhere. That is a feeling I wanted to evoke in the players of WordLeap.

My early gaming experiences would also play a role in the design of WordLeap. While there are a lot of things I like about games, the one thing that stood out to me the most was the sense of discovery, of wanting to experience what lies beyond the exit. It was the thought that there was some amazing visual or aural experience in the next level that motivated me to push through the challenges.

One final influence that deserves a mention is Lumines Live! It is a game where no attempt is made to tie everything up into a nice little narrative, a puzzle game where the main focus is on getting the high score. It provided a sense of discovery through the unlocking of new skins as you got to higher levels. This is something I really liked and helped cement the idea I had for what I wanted to do with WordLeap.

The main game would naturally become a sort of story mode where the player must face increasingly difficult challenges to make their way through various places. The challenges would be abstract representations of what someone would face on a real journey. The idea of the player trying to reach enlightenment was ultimately the result of our brainstorming sessions.

The feeling I wanted the game to have, the amalgamation of the feelings from the influences described above, would come from changes in scenery and music as the player progressed through the levels. The gameplay would be essentially the same throughout, only adding in extra elements along the way to increase the challenge.

Now that I knew what game I wanted to make, it was time to start developing it, programming all of the systems I would need to make this vision a reality.

Development Challenges

The first challenge I faced during development was coming up with a way to handle the levels. Travis laid his vision for how the levels would look in an e-mail he sent me when we first started working on the project.

The way I was thinking of doing the backgrounds would be using basic polygon shapes. Have 2-3 layers of parallax and have the playfield appear to scroll up and to the right. For instance, the first level might have just mountain-like green polygons. The second level could have polygons that are rectangular and look like buildings. The third level could have polygons that look like trees. When you finish a level, there would be some kind of transition effect and it would scroll seamlessly into the next background type.

There were a few mock-ups like the one below attached to this e-mail which would ultimately inspire my solution:

test4He mentioned wanting to use fractals, but I quickly dismissed that possibility after doing a little research. It seamed like a rather complex solution. Instead, I thought it would be cool to have a shape palette for each level. We could generate the background by randomly picking a shape from the palette and placing it next to the previous shape. Each shape would be required to line up at a specific point to ensure the shapes would all fit together seamlessly. This solution wound up working rather nicely.

One of my favorite tricks with hardware accelerated graphics is using greyscale textures and applying color to the polygons to give the final result. I knew I wanted the level transitions to be seamless so I put that trick to good use. All shapes in the shapes palette are greyscale. This made it possible to smoothly fade between levels. I was very pleased with how this all turned out.

The Touch Effect

After I had finished what I thought was most of the coding, I decided to try and get the game running on Android. Allegro’s Android port still had a lot of rough edges at the time, so it took me quite a while to get it set up. I did manage to get the game running and was met with some disappointing results when I attempted to play the game.

I imagined the game would work rather naturally with touch controls, but I found that it was very hard to play. My initial disappointment quickly faded and I went into problem solving mode. This is where I made one of the biggest changes to the game, resizing the game board from 10×10 to 7×7. This was a difficult change, since I didn’t design the game (I have a tendency to not want to alter someone else’s work), but I knew it would be necessary if we wanted to have a single version of the game on mobile and PC.

Now it was a lot easier to touch the tile you wanted, but this wasn’t enough to fix the game. Since your finger is in the way when you touch a tile, you can’t be sure you have touched the correct tile. This was remedied by implementing what I call a touch helper, a little bubble that pops up above your finger indicating the contents of the touched tile.

With these changes in place, the game was actually playable, but playing with touch was slower than playing with a mouse. I needed to do something to keep my vision for parity between all versions of the game intact. This is when I decided to change the game from a timed system to a move-based system.

Originally, the life bar acted as a timer that would decrease slowly until it ran out and ended the game. This was changed so that the life bar acted as a move counter instead, decreasing with each move you make. This change would ensure that one platform wouldn’t have an advantage over another and we could have a single set of leaderboards shared amongst all versions.


After having finished most of the game, I thought it would be cool to include a music player mode. This ended up being the unlockable Music mode. I thought it would be a cool way to relive the adventure in a passive way. I think the idea came from not only the music test mode in old console games, but also games like Metal Gear Solid 2: Substance (Casting Theater) or Metroid: Other M (Theater Mode). The mode was later renamed to Scene mode since it reminded me of old demo scene demos that featured cool artwork and MOD music.

I added an Unlock Content option to the profile screen to allow players to unlock all of the content without having to play through the story mode. After reading an article on Kotaku about one player’s frustration with locked content in certain types of games, I decided this would be a good feature to add. Not all players are going to be interested in playing Story mode, and those players should still be able to enjoy all of the available content.


Working on this project has been a great experience for me. I enjoyed managing the project, coding, and doing music and sound. It was a lot of work, but I am very happy with the way the game turned out. I am reminded of the days when we used to take turns on the old Packard Bell 486 SX 25, trying to make our dreams a reality.

Be sure to check out T³ Chronicles #1: WordLeap Pseudo-Postmortem for Travis’ take on the development of WordLeap if you want to read more.

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 Control: I Must Run

Controls in video games have always been an important area of focus for me as a game developer. Maybe it’s the countless hours of gaming over the years that have molded my idea of how games should control, but to me it is intuitive. The idea when programming controls is to understand what the player wants to do based on the input you are receiving from them. Controls are a fundamental part of video games and should be well thought out.

I was recently looking around in the Nintendo eShop and came across a game called I Must Run. It looked like fun, and for a couple of bucks I figured it was worth the gamble to try it out.

I Must Run is an auto-run platformer similar to Canabalt and BIT.TRIP RUNNER. Your character automatically runs and you have to react in various ways to keep from getting killed. You have the ability to jump, punch, and slide, and you will need all of these moves in order to survive.

The game is pretty good, overall, but there is one very annoying issue with the controls that keeps me from thoroughly enjoying the game: when I press the slide button, it only slides if I happen to be on the ground before the button press occurs. The entire design of the game centers around anticipating what’s going to happen next and reacting quickly. Having to focus my attention directly on the character sprite, waiting for him to land before giving him the next command is a serious design flaw.

As a player, my intentions are clear. When I press the slide button, I want to slide. There is no good reason for the game not to recognize this fact and act accordingly. From a programming perspective, it would only take, at most, a few lines of code. This leads me to the conclusion that the developer didn’t consider player intention when programming the controls. By not doing so, the developers held this game back from being great.

Super Mario Land 3: Super Mario Grows Up

I am a huge fan of the Super Mario Bros. series of games. I have played every game in the series, most of them fairly thoroughly. The one game in the series that I missed was Super Mario Land for the Game Boy.

I recently obtained copies of all three Super Mario Land games from the Nintendo eShop and have been playing through them. I had played the latter two before but hadn’t really thought too much about the design of the games. After playing through all three games recently, I noticed how the Super Mario series has progressed over the years.

In the original Super Mario Bros. you simply wanted to get to the end of the game and defeat Bowser. How you get to the end was up to you, but you had no other explicit goals. Super Mario Land pretty much replicates this design without deviation.

Super Mario Land 2 introduces secondary goals which are conveniently tallied up for you on the file select screen, much like Super Mario World. In Super Mario Land 2, secondary goals consist of finding secret exits in the levels that open up paths to additional levels. Many of the secondary goals are not revealed explicitly in the game Unlike Super Mario World, there is no way to know where to look for many of the secondary goals or whether you have finished all of them.

Super Mario Land 3 takes secondary goals into their current state. Firstly, they’ve added a treasure collecting aspect to the game. You can clearly see all the treasures you have each time you complete a level. Secondly, levels with secret exits are clearly marked on the map screen, much like Super Mario World. Thirdly, the game tells you to “PLEASE RETRY” when you beat the game if you haven’t completed all of the secondary goals. And lastly, after beating the game, the levels that contain treasures that you haven’t gotten yet are now marked so you know exactly where you need to be looking to complete the rest of the goals.

What separates this game from previous games in the series is that you are basically told that you aren’t done yet if you haven’t completed all of the secondary goals. Newer games in the series further integrate secondary goals into the game, giving the player the impression that they aren’t done until all of the goals are completed. For instance, Super Mario World 2, the next game in the series, gives the player a score for each level (up to 100). The secondary goals are the same for each level, find a certain number of certain types of items. As a gamer, seeing less than 100 compels me to go back in and try to get everything.

All of the newer Super Mario games have these integrated secondary goals that keep you playing until you have done everything there is to do. This is what Super Mario is these days. To me, Super Mario Land 3 represents the moment when the Super Mario series went from being an adolescent to being a young adult.