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.

Round 1 of Zebulon User Testing: It’s Confusing

It’s pretty much taken as gospel in the web startup world that nobody is the usability design guru they think they are. An iterative approach of: rapid prototype; put in front of a few people to get their feedback; and repeat is the cheapest and fastest way to design the things people use.

I know this. But it’s still tough to put your baby out there and then see how badly it fares.

I hit an early prototype milestone last week. The graphics are crude, but the game play works and it’s tricky but possible to win. Here’s what the game looks like:

Happy with my progress, I put a copy onto my iPad mini and went out to lunch with my old SurveyMonkey Seattle crew, so I could show them my progress. They were champs, and let me sit down with them one at a time so I could watch them interact with this game for the first time. I wanted to see if they could figure out the gameplay on their own, so I didn’t give any coaching or tutorial – I just handed them the iPad.

It was humbling. My friends were really nice, but it was clear that the interface was baffling. Which in retrospect, makes total sense. Here’s my key learnings:

Clicking (pressing your finger) is the primary interface; dragging is a secondary interface, and only works if there’s an obvious target and destination. 

In Zebulon, you drag ships between planets. And you click on planets to pick what that planet produces, or to see information about that planet. But you can’t make much of anything happen just by clicking on a planet; the gameplay is about drag ships between planets. This was not at all obvious to my poor testers.

Visual consistency is paramount. 

For the player attack ship, I had an orange-hued ship sprite. Because attack is red, right? But the enemies are color-coded as red. So red meant “enemy” to my testers, and they wondered why an enemy ship was orbiting their planet, when it was supposed to be their ship. (I changed the hue to green in the video).

There can only be one kind of power-up indicator. 

Nobody understood the difference between planets having two modes: building the planet,  and a finished planet which produces goods. I’ve been struggling with the visual indicator – I’m back to the ring which cycles from gray to green to yellow – but I need to go back to the drawing board on this.

Razzle-dazzle to fake it until you make it. 

People loved the fairly cheap visual effects that I tossed in – a particle emitter for ship engines, planets that “pop” a bit when you drag over them, ships in orbit, etc. Even though it doesn’t do much for game play, these bits of polish told my testers “this is a legit game, keep trying.”

This feedback is invaluable. But it’s demoralizing; I’m back to the drawing board on a lot of things. But it’s better to discover these problems as soon as possible. If anything, my take-away is that I could have started testing even sooner, and saved myself more time.

Damn the Torpedoes, Full Zebulon Ahead

Game development is definitely taking longer than I’d thought.  I’m not even talking about sourcing visual and audio assets, or fighting with the SDK or debugging code; it’s the endless hours that disappear into getting the right working system in place. Coding patterns for is-a subclasses and has-a relationships, interactions and messaging between systems.. and the refactoring everything because it wasn’t the right approach.

And there’s the top-level conceptual questions, ranging from: “is this game even fun?” to “should I keep a few dozen objects in one screen area, or will we have a giant view area you pinch and swipe across?”


Do you accumulate a currency of “power units” or whatever to spend, or are you just struggling to build objects? Should the player control where each object goes, or do they have a mind of their own?

How should we display the build-status of a planet? The energy-status? As two arcs?


Or should energy be a glow (pulse?) that builds up?

I was feeling pretty down last week (which was week #3). My friends gave me a much-appreciated pep talk, and suggested that I do something I should have done when I started: read Ryan and Chris Campbell’s excellent ongoing narrative about their friendly competition to build two games. (Disclaimer: I had the pleasure of meeting these guys while we were at SurveyMonkey).

Beyond the tips and breakdowns they give for their problems and approach,  it’s such a comfort to see that I’m not alone in this, and yes, it’s hard.

So. As I enter week #4, what should I do?

At this point in time, I need to stop refactoring, I need to stop trying out different gameplay ideas. I just need to finish a working first-draft of the game I had originally set out to build: a graph based tower defense game where units are built and then have an autonomous life of their own. Which works on iPhones (4s and newer) and iPads.

I’m sure I’ll have tons of changes and new ideas after this MVP is wrapped up. But rather than constantly building up and tearing down a myriad of ideas and explorations, I should stay the course.

Zebulon Part 2: Status Update

I’ve been focused on writing my game for a week now, and I’m happy to say that I achieved the (modest) goals I set out in my last post. The artificial deadline approach worked as a motivation!

The wise approach would have been to focus on workshopping the gameplay by starting with crappy graphics targeting one particular device, like an iPhone 6. This would have let me figure out what ideas work, and which ones didn’t.

I took the opposite approach, and instead worked top-down on “first impressions” such that the game would look decent on any iOS device, starting with the launch icon and home screen. While these are just placeholder graphics, being able to have something that looks kind of like a game from the start has the important emotional impact of making me feel like I’m making progress.

Simulator Screen Shot Apr 5, 2016, 12.53.39 PM.png

The home screen was adapted from a vintage sci-fi book cover; I’d love to follow this aesthetic if I can.

Simulator Screen Shot Apr 5, 2016, 12.54.52 PM.png

What’s interesting about the home screen is that different iOS devices have much different resolutions and aspect ratios. The above is an iPad air; for an iPhone 4s, the aspect ratio makes this screen look like:

Simulator Screen Shot Apr 5, 2016, 1.03.15 PM.png

From day 1, I’ve worked to ensure that graphics and elements are scaled to work on any device. I’ve avoided making different graphics specific to different aspect ratios, preferring to scale, position, and clip in code.

For the game itself, I abstractly describe objects in a space that is logically 150 x 100 units. There are nodes (planets) and edges (paths between planets). I wrote a layout engine that  dynamically picks the actual size and position of objects based on the device’s screen.

Simulator Screen Shot Apr 5, 2016, 12.52.52 PM.png

Levels are described in a JSON file, using a 150 x 100 unit layout as e.g.:

    "version": 1,
    "name": "Getting Started",
    "nodes": [
        { "id": 1,
          "x": 0,
          "y": 0,
          "neighbors": [2,4],
          "properties": { "role": "colony"}
        { "id": 2,
          "x": 20,
          "y": 50,
          "neighbors": [1,3,4],
          "properties": { "role": "empty"}

JSON parsing in Swift (or Objective-C) is a bit more work than you’d expect, because the language is typed. The code looks like:

let data = JSONData.dataUsingEncoding(NSUTF8StringEncoding)
let json = try NSJSONSerialization.JSONObjectWithData(data!, options: .AllowFragments) as! [NSObject:AnyObject]
guard let version = json["version"] as? Int,
    let name = json["name"] as? String,
    let nodes = json["nodes"] as? [[NSObject:AnyObject]] else { return level }

Overall, I thought Spritekit does a great job of making it easy to build event-handling (for clicks), object display, and animation effects. Most of my time was spent on asset-wrangling and getting things to display at the right location and size. Weirdly, the one chunk of code that took me hours to get working properly was to display a texture as grayscale (for when a planet object is disabled). There are a variety of approaches; some lost the alpha channel, and others would simply not properly convert between the different image formats. Here’s the final version which works nicely:

func convertToGrayScale(texture: SKTexture) -> SKTexture {
    let originalImage = texture.CGImage()
    let context = CIContext()
    let inputImage = CIImage(CGImage: originalImage)
    let filter:CIFilter = CIFilter(name: "CIPhotoEffectMono", withInputParameters: [kCIInputImageKey : inputImage])!
    let result = context.createCGImage(filter.outputImage!, fromRect: inputImage.extent)
    return SKTexture(CGImage: result)

I plumbed in a dialog which opens when you click on a planet, so you can change its behavior (this is how you play the game). Nothing fancy here aside from a lot of layout work; though I’m still having a devil of a time getting the side-arrow to work uniformly on all devices.

Simulator Screen Shot Apr 5, 2016, 12.58.41 PM.png

And there you have it! A week of progress. Let’s see how the game is looking next week!


Zebulon Part 1: Game Concept

A few years ago, my wife and I were driving from Raleigh, North Carolina towards the shore and passed a sign for the town of “Zebulon.” I loved that name. Zebulon… it sounds like something out of a 1950s pulp sci-fi book, the home planet for a bunch of alien space invaders or something like that. (Yeah, it’s a minor Biblical name, but did you know that before Googling it? I think not.)

Ever since then, I’ve vaguely talked about writing a computer game called Zebulon. Hopefully, by sharing my intent and thoughts, I’ll motivate myself into actually doing this – mostly because now I’d worry about self-shame if I procrastinate any more.

The goal is: publish something for iOS. It doesn’t need to be successful – I know how crowded the app store is, and how brutally difficult marketing can be – but I want to just prove I can get an app out there which runs equally well on my phone, iPad mini, and iPad pro. My bar for success is low; I’d be delighted if (a) my nieces and nephew like this game enough to play it for at least one hour, and (b) they tell at least three of their friends about it. If time allows, it would also be really cool if my wife (the musician) could supply some killer tunes and sound design.

While I could make this broadly cross-platform by using Unity or even just a web-based Javascript game, I’ve opted for SpriteKit on Swift. It’s a reasonably simple environment, the graphics run smoothly, and there aren’t licensing fees to worry about.

But what about the game itself?

At a high level, I prefer games that can be played off-line, but have AI opponents. I like strategy games, both turn-based and real-time; nothing too twitchy or ultra-fast-paced. Games should take less than 20 minutes, and be different each time. You should win more often than you lose, but victory should always be a challenge. The enemy shouldn’t win by “cheating” based on asymmetric knowledge (a.k.a. spying on you, if you can’t spy back).

I’ve been noodling on the idea of a graph-based tower defense strategy game for a while. In tower-defense games (like Plants vs. Zombies) you have to make optimization decisions between investing in future production capacity (e.g. Sunflowers) vs. building out defenses in the form of placing automated widgets (e.g. pea shooters). There are strategic considerations in picking what items you can build, and where to place them. Most of the games in this genre are on a grid, such that enemies enter from one side, and must be stopped by your widgets before reaching the other side. Grid-based tower-defense games are fun, but the category is pretty well saturated at this point.

What if we move to a graph, such that you battle for control of nodes and movement can happen along edges? This would make certain parts of the map more critical to capture, or easier to defend; and perhaps part of the game could be manipulating the graph itself, to add or remove edges.

In the tradition of many space games, each node could be a planet or sun system – let’s call them planets for now. But what are nodes – what are you building, what can you control? What flows along the edges – energy bursts, fleets of ships, missile attacks…?

I’ve wasted a lot of time in the past few weeks noodling on this. I have a notebook full of different game ideas, and several half-baked mockups in Illustrator.

In one concept, I thought about allowing you to colonize a planet; once it was yours, you’d have 1-4 slots for “satellites”. Each one could provide attack, defense, or production capacity. You’d need serious investment to colonize nearby planets, or to launch a massive attack.  But there wind up being a LOT of things on the screen, and clutter and usability become a serious problem.

In another concept, each planet could have a single function – you “buy” the ability to change what it does. You’d be chaining the graph together, such that each node has inputs and outputs. It’s graphically simple – there are a handful of icons you’d drag onto big circles – but I worry that it would neither be intuitive nor interesting.

Screen Shot 2016-03-24 at 5.04.32 PM

I dunno. What would be fun? What is easy to use on a small touchscreen, such that clumsy finger presses wouldn’t ruin a game? The holy grail is finding a game with simple mechanics yet also delightfully deep complexity.

I’m not there yet. But I’ve decided that I’ve got to stop planning the game (and then backtracking), and instead build some actual foundation in code. No matter what, there’s going to be:

  • An application with an icon.
  • Splash screen with a “start” button.
  • Game scene with a graph with some nodes (colorful circles) and edges (lines) that register click events when pushed.
  • Game settings.

So! That’s my goal for this next week (ending April 1st, 2016). Just get those core bits working, so I can then play with different game mechanics. I’ll take notes along the way, and share what I learn in my next post.



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.