Hi, I'm Henry. In 2012 I quit my job as a programmer at BioWare to spend a year making my own indie games. This blog is about what happened next...

Like Spaceteam? Want to support my work?
Join the Spaceteam Admiral's Club!

Spaceteam Schedule

I’ve been calling Spaceteam my “one month” project but it’s also an experiment to see how long it takes to make a simple game from start to finish. I expected my estimate to be a bit off, and I think that’s fine as long as I’m honest about how much time and effort it actually took. That’s why I want to document it here, so I can learn from it.

So far the time I’ve spent on it has been:

  • Two weeks part-time prototyping the basic idea in Unity.
  • Two weeks part-time porting the prototype to Cocos2d (Unity is overkill for my game).
  • Three weeks of full-time development (so far).

I’d like to have the game finished by the end of the month (September 30th). And by “finished” I mean submitted to the iTunes App Store (apparently the review/finalization process can take a couple of weeks). I think it’s a reasonable goal based on what’s left to do, and my rough schedule is as follows:

  • One week to finish the remaining features, detailed below (“Alpha”).
  • One week to balance, polish, fix bugs, and incorporate feedback from playtesters (“Beta”).
  • One week to prepare the final build for submission, make a website/company logo/press kit, start contacting review sites, etc.

Now, let’s check back in three weeks to see how accurate I was! I’m sure I’ll run into some hurdles, but that’s the point of this project.

Alpha

There’s enough of a game here already to play with other people and have fun. But there are a few things that I think the game needs to feel complete, and that don’t seem too extraneous:

  • Sound
  • The “Threat”
  • Random Events
  • Wormholes

I have lots of other ideas, but it looks like I’ll have to save them for a possible sequel!

Sound

This game needs sound. I think a few simple clicks, pings, buzzers, alarms, and crashes will go a long way to adding to the chaotic atmosphere and also providing feedback for your actions. Music wouldn’t work so well since everyone’s playback would be a little out of sync (and it doesn’t make sense for a game whose central mechanic involves shouting at each other).

The “Threat”

One of the problems I’ve seen in playtests is that if a team is doing ok, but not great and not terribly, then the ship will pretty much stay in the middle of the screen and the level will just keep going until they eventually win or lose (or get bored). This can get tiring pretty quickly, so to fix it I’ve decided to add a pervasive “threat” of some kind (eg. an enemy ship, an exploding sun, a poison gas cloud, etc.) that gradually approaches the ship from behind if you take too long on a level (Thanks to Ben for the idea!). This will keep the pressure on and ensure that the level ends in a reasonable amount of time.

Random Events

As you play, the levels get progressively harder, but there’s no real difference from one play session to the next (other than the people you’re playing with). I think adding a touch of variety will help make each session feel different, and encourage replayability. My current idea is to add a random event/condition every few levels, and I’ve come up with a few cheap ways I can do this:

  • Asteroid Field (much higher chance of asteroids)
  • Electrical Storm (much higher chance of panel sparks/shocks)
  • Magnetic Storm (much higher chance of dangling panels + weird gravity when they come loose)
  • Heavy Turbulence (much higher chance of shaking/flaking panels)
  • Slime Containment Malfunction (much higher chance of slime)
  • Translator Malfunction (some/all panel labels are written in an alien language)
  • Label Maker Malfunction (some/all panel labels are missing)
  • …any other suggestions?

Wormholes

This one is a little unnecessary but I already did most of the work for it while prototyping so I’m going to add it anyway. Wormholes are an external hazard (like asteroids) that your team can avoid by flipping your iPhones upside-down. If you collide with the wormhole, it warps or twists your panels for a certain amount of time and—like most effects in the game—makes it harder to operate the controls. If you survive there may also be a beneficial effect (like skipping a level, for example) but I need to test this to see how well it works. Having an upside means you’ll have to make a quick decision about whether to avoid the wormhole or intentionally go through it, and I like the added chaos that choice introduces.

If anybody has any advice or suggestions, please let me know! Feel free to comment below or reply to me privately if you prefer.


A Confession

I have a confession to make. When I was first making plans to go indie I made a couple of promises to myself:

  • That I would devote more time to my life outside work: reading, music, exercise, meditation, playing, spending time with Sara.
  • That I would focus on the essential aspects of the game first, and not be distracted by small details/polish until absolutely necessary (I’m a perfectionist, and I have a hard time finishing projects)

What have I done so far?

  • Gone on an intensive work binge for my first two weeks, at the expense of all those other things.
  • Made a logo.

Now, I have mixed feelings about this.

I definitely want to find a healthier balance between work and life. But right now I’m really excited about starting this project and I figure I should put that energy to good use. I’ve been justifying this “crunch time” as a focused push to get the game ready to play by people whose opinions I respect (eg. last Wednesday at MRGS). If it continues, it’s going to be a problem, but I think everything I’ve done so far has been valuable. Perhaps it was still too intense.

I also think that spending time on details is important. Sometimes I need a distraction to clear my head, and working on the art, sound, logo, etc. is part of the reason I went indie. I like that stuff. If inspiration strikes (which it did for the logo) then, again, I don’t want to waste the opportunity. But I need to recognize when it’s gone too far and when my underlying motivations are to avoid important work. That’s going to be difficult.

Luckily my fiancée Sara has agreed to be my “producer” and to call me out when it becomes clear that I’m going off course. Thank you darling, for all your support.

So, the question I’m asking myself (and you!) this week is: What’s an appropriate work/life balance for an indie dev when you work from home full-time, and how do you achieve it?

…and since I spent a whole day of work on it and want to show it off 😉 here’s the Spaceteam logo I came up with:


My First Ideas

I’m going to start by making some iOS games. I have several Apple devices for testing and making mobile games will force me to keep my scope manageable (I tend to get over-ambitious). I also just like touching things, so the touchscreen is going to be an important part of my games.

The “Big” Idea

The project I’m most excited about right now is inspired by Galaxy Trucker (the board game), Star Control II, Escape Velocity), and a dash of Google Earth. It’s a 2D space exploration game centred around building (and rebuilding) a spaceship from simple blocks. You drag and snap together modules representing thrusters, cargo holds, lasers, sensors, tow cables, solar panels, robot arms, etc. each affecting your ship’s capabilities. Then you zoom off and explore a (fictional) galaxy, meet aliens, discover exotic nebulae, dodge asteroids, and inevitably get into a heap of trouble and rebuild your ship according to the situation at hand. I call it Shipshape.

There are a bunch of space games for iOS already, but they all seem to have intimidating UIs with lots of menus, and are mostly in 3D (which adds additional complexity). I want a game that’s easy to understand and play, with a strong focus on touch input that feels right. That means no virtual joysticks, for example :)

The “Small” Idea

However, Shipshape is pretty ambitious, so as a practice run to get a feel for the process of creating an iOS game I’ve decided to start with a much smaller project that I can finish in one or two months.

It will let me make mistakes on a small scale, teach me how to estimate tasks on my new work schedule and hopefully be a good stepping stone to Shipshape.

That game is…

Spaceteam

Spaceteam is a local multiplayer co-op iOS game where you shout nerdy things at each other for a couple of minutes before you all die. At least that’s what it sounds like to people watching.

So… you’re in a spaceship and you each have a randomly generated control panel with buttons, switches, sliders, and dials. You need to follow time-sensitive instructions being fed to you by the ship’s autopilot. However, the instructions usually refer to controls on someone else’s screen, so you have to shout the instruction to them before the time runs out. Meanwhile they’re doing the same to you. Oh, and the ship is falling apart.

I still have lots of balance and polishing to do, but the prototype is already pretty chaotic and fun. It currently supports up to 4 players, but there’s no reason it couldn’t stretch to more (except for sanity, and probably network issues).

I have lots of ideas for directions to take this mechanic in, but this project is an exercise in keeping scope small so I’m trying not to add more than absolutely necessary.

Remember to work together… as a SPACETEAM!

This player is in a spot of bother.