Time for a Game Redesign? Nah…

Despite more game iterations, Zebulon still hasn’t been going well. It’s confusing; in particular, the non-obvious rules around how the graph works, and the mechanic of dragging ships between planets.

Do I stick with what I have, or do a big re-design?

My original goal was just to publish an iOS game, of any kind. It would just give me bragging rights, and maybe a few hundred downloads. A redesign to make a better game that wouldn’t move the needle much isn’t a good use of effort.

But a redesign is still an interesting thought exercise. Let’s pretend I wanted to spend the effort to keep “core” of the game, but make it meet the usability of its tower defense peers. My game’s essence is:

  • There are discrete planets, with individual roles.
  • Roles interact with one another according to simple rules; the effects are stronger the closer the planets are.
  • Multiple simple interactions can lead to complex behaviors.
  • I want at least two kinds of “production”; I’m now leaning towards cash and energy. Cash is a discrete unit that accumulates, energy is an ongoing localized effect.

There doesn’t need to be a graph – or at least, not overtly. My original idea had been for the game to be centered around graph manipulation, but has two problems:

  1. It seems to appeal more to me than my early testers, and
  2. It’s a pain to generate 2D graphs such that the lines don’t cross, or get too close to, other planets.

So, let’s look at a random handful of other games I admire.


I spent many, many hours playing Spaceward, Ho! on my old Macintosh when I was a teen, and it’s clearly a strong influence on Zebulon. It’s not a tower defense game per se, since you’re not dropping of autonomous units which repel waves of attackers in real-time; rather, it’s a turn-based strategy game where you have to juggle which resources you spend on terraforming vs. mining vs. research; ship-building; attack vs. defense. I loved trying to optimize its gameplay, and appreciated how well-balanced the game was overall. I will say that I’m not a huge fan of the fleet-management aspect of the game, however. The interface has a lot of dialogs and widgets; especially in later versions of the game which added features to appeal to more hard-core users.


Obviously, Plants vs. Zombies is one of the great tower defense games. It’s not that complex a game, but the genius is in the simplicity and the evolving challenges the designers throw at you (now, play it at night! Now, you need to pot your plants! Now, we will randomly steal your plants). The core mechanics are:

  • Picking your six characters from among dozens of options
  • Spending resources on increasing production (sunlight) vs. defense
  • Building interactions between items; primarily in the same lane, but also between multiple lanes.

The interface is mostly drag-centric (pull items from the top menu), with some tapping to pick up sunlight. The “genius” is in how freakin’ well balanced it is – it’s always a challenge, but never crushing.


I love the aesthetic of  Unstoppable Gorg, and it brings some clever additions to the genre; you can rotate an entire orbit “ring”, and enemy waves come in looping paths that require you to juggle the location of your defenders. Note that from a very high level design perspective, it’s not that different from Plants vs. Zombies, inasmuch as there is a tray of options at the top, with a counter and meters shown in the upper-left; and you select which handful of ship options you want at the beginning of a level.

With all this in mind, I busted open Illustrator to try a new Zebulon game design mockup:


I’d move to a having a currency, and embrace the traditional tower defense trade-off of using a “slot” to generate money vs. doing something useful. I’d still like there to be interactions between neighbors based on proximity, which could allow for some interesting emergent behaviors. Your job is to build out each planet in a strategic way, such that planets support one another to repel the enemy.

…but let’s stop there. I’m not going to start over; what this game needs is more wrapping up, and less improvement.



When I was a teenager, I published a video game. It even got a bit of distribution in the kind of free CD-ROMs you used to find tucked into enthusiast magazines. A few people emailed me. Then, I kind of forgot about it. 

One of my servers recently died. As I was cleaning it up and copying over the important bits, I found the old code archives for this game – and I paused to give it a look, not unlike the way you’d flip through a photo album you found while cleaning out a closet. 

The thing is, the game was pretty good. While I’m not exactly proud of the code, it’s nowhere near as badly written or organized as I thought. I’d written gobs of documentation. The game design was unique, and the graphics were good (but by modern standards, very tiny; I was designing for a 640×480 screen). 

I didn’t even know that open source was a thing at the time; I’d released the game as vaguely-worded “freeware” and posted links to the code. (It’s now GPL). 

Spiked is 17 years old. It was written for the old MacOS (pre MacOS X). It requires two people to sit down and compete using the same keyboard. But it’s a thing I made, finished, and published – and that’s pretty cool. The least I can do is give it a small breath of life and write about it; and post the source code on GitHub where it will be (somewhat) immune to bitrot. 

In honor of my younger self, I give you part of the original Spiked documentation I wrote in 1997. 

Spiked 2.1 is a two-player arcade game of cunning, physics, and brute force. One player pilots a green ship, the other player a red ship. There is a horrible, nasty spike that floats around the screen (hence the name of the game, eh?) The only way to die is to touch the horribly, nasty spike. The game follows the gladiator paradigm: the player who walks away alive, wins. So, spike your opponent and achieve victory. Each player starts with three lives. A match lasts between 1-5 minutes, about the attention span of your average computer game player. 

The game plays in a straightforward fashion. The players, the spike, and other items are dumped into a closed arena. Everything interacts with everything else according to the laws of physics. If you bump into your opponent, he/she WILL fly backwards. You can even move the spike if you shove it hard enough (of course, it has 200 times the mass of a player, so it can take a while to build up its momentum). A simple strategy would be to get your opponent between you and the spike, and then you accelerate towards your opponent to shove him/her into the spike. Unfortunately, your clever opponent will probably just move and you will find yourself kissing the spike, which is bad for your health.


Lots of other things float about the arena. Rocks are massive and basically just get in the way. Ram them to move them. Once in a while, a rift in space opens and deposits either a new rock or a gift.

Gifts make Spiked interesting. These little packets ‘o goodness just float around, waiting to be picked up before they either blow up or are pushed off the edge of the screen. Inside the gift you will find a useful item which can be used to either attack your opponent or get yourself out of a scrape. 

At the top of the screen, you will find an icon representing your ship’s currently selected item. The default item is bullets. At any time, you can press your specified “Use Item” key to either shoot or invoke that item. Or, if you have other items in your inventory, you can cycle through your items to select the item you wish to use. It is always a good idea to build up a small arsenal of items which you use to hunt down and eliminate your opponent or to save your own sorry skin. The items are:

  • Bullets. Each ship is equipped with a small cannon that shoots bullets a short distance. You have infinite bullets, but all they do is push things out of the way. Bullets also destroy gifts, and rocks if you hit ’em enough.
  • Cannonball. This item is really cool. It moves very quickly and shoves things aside. Try blasting your opponent into a spike with one of these! Cannonballs are also a great way to eliminate annoying rocks.
  • Twister. This nasty item prevents whatever object it hits from accelerating. When you hit your opponent with a twister, a energy field clogs their engines, leaving them helpless . Take advantage of them and gently nudge them into a spike. Another use of twisters is to stop gifts which would otherwise float away.
  • Gravitron. Be careful with this toy. You shoot forth a tremendous ³lasso² that drags whatever it hits towards you. This can be really cool if you attach the gravitron to your opponent so that they are dragged into a spike. Of course, if you attach a gravitron to a spike, then the spike will start chasing you and you will probably die. Pity.
  • Speeder. When you invoke a speeder, you rocket forward in whatever direction you are pointed. This provides you with a way to hammer your opponent or to escape.
  • Rockyspiker. If this hits a rock then the rock turns into a rockyspike; or, if it hits a rockyspike, the rockyspike turns back into a rock. A rockyspike is like a spike in that it kills things, but is has far less mass and the rockyspike will blow up if it hits the real spike.
  • new life. You don’t use this gift. You just pick it up. I’ve noticed that people are more than willing to die to pick up a new life, which seems rather odd…




So there you have it. A 2-player game where the strategy is to manipulate an environment using the physics of randomly presented items. It was written in C++, painstakingly animated frame-by-frame to plug into a 2-d sprite library for which I simulated all the physics, for a now-defunct operating system. 

Not bad, much-younger-me. I need to live up to your example.