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.
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.
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.