Post-mortem of Week Two

April 05, 2016, 7:20pm

It’s Monday afternoon and I’ve had a chance to get some sleep after finishing the game for week two. If you’ve played it, you might notice that due to bugs, it’s practically unplayable. If you are fortunate enough to be able to play for a bit before it bugs out, you might come to the unfortunate conclusion that the game isn’t even fun.

So what went wrong?

That’s a question I’ve been asking myself all day. I’ve narrowed it down to three issues:

1. The design was too ambitious.

2. The technology was too ambitious.

3. Not enough time.

Let’s tackle them one by one.

1. The design was too ambitious.

I’ve been toying around with the idea of a game based around a gun that is aimed via algebra equations for a while. My buddy Greg flies jets for the Navy and has spent the past few months on an aircraft carrier in the middle of the Pacific Ocean which provided the inspiration for this game.

There’s a pretty great anecdote from George Fan, creator of the fantastic Plants vs. Zombies franchise about how he chose plants and zombies as the characters for his tower defense game. You might think that he chose two popular character types at random (it could just as well have been cats vs. ninjas) but there’s actually a lot more thought put into it. You see, the enemies in tower defense games have to be slow and numerous and the protagonists have to be rooted to the ground. It so happens that plants and zombies fit that description perfectly and the charming puns and descriptions followed naturally.

I had the same sort of idea with this game. Aliens are attacking your ship, which lies at the origin of a cartesian plane, and it must be defended with a laser that aims via y=mx+b equations and a missile which finds its targets with cartesian coordinates.

On paper, it actually sounds pretty simple. Much simpler than week one’s crazy tamagotchi/MOBA hybrid. In practice, it was pretty difficult to make the enemies spawn and attack slow enough to allow the player adequate time to calculate and enter the algebra equations while still eliciting exciting gameplay.

When I set out to build a new game every week, I decided that the minimum requirement is that each game explores an idea, concept or technology. Being fun is NOT a requirement, nor is being 100% functional and bug free. So technically, I’m still on track.

One of the problems with building a game in such a short timeframe is that it allows no room for iteration. The first couple of days are usually spent coming up with a concept and design and the later days are spent coding, but when design issues come up during the coding phase there is no slack time to revisit the design. I learned that a bad design can have adverse effects on engineering as well.

2. The technology was too ambitious.

While at EdSurge (where I was most recently employed until two weeks ago), I got a chance to work with D3 which is a pretty awesome javascript framework for data visualization. It’s sort of tricky to use but you can create some pretty amazing data visualizations with just a few lines of code.

I wanted to do a project in D3 while it was still fresh in my mind and this algebra shooting mechanic seemed like the perfect candidate: D3 makes things like dynamic axes and plotting points easy!

Well, it turns out that it wasn’t quite so simple. Plotting data points is easy enough, but D3 transitions tend to happen very periodically, instead of multiple times per second so it’s hard to create dynamic AI. It’s also tricky to be moving back and forth between pixels and graph units (even though D3 does have built in xScale and yScale functions). It’s also hard to make changes to the data mid-transition: for example, when destroying an alien mid-transition, it will throw an error when it tries to reference that alien again.

I think all of these obstacles could be overcome with enough time and effort, but it’s hard to make that extra push late on Sunday night when the payoff isn’t there. Put another way, no engineer wants to kill themselves to implement a mediocre design.

3. Not enough time.

When I say not enough time, I don’t mean I should have taken more time to work on this particular game. What I really mean is I should have aimed for a less ambitious design. I have a ton of game ideas, and the goal of this game-a-week mission is to test as many of them as possible. Starting out of course, the ideas are bursting out of the seams and there is a tendency to want to squeeze as many ideas into each game. This is a marathon, not a sprint, and there will be plenty of opportunities to explore all of my crazy ideas. And a few months (or years?) from now when that bursting torrent of ideas becomes a slow trickle and inspiration becomes scarce, I will be grateful for having kept a few of these ideas in storage.

In the meantime, it’s on to week 3 with these lessons learned.