Pipelines

Demon wrestling is part and parcel of the indie dev life. Lately I’ve been meeting the following three in the ring:

1. Being too close to your project makes them, paradoxically, hard to see. Changes seem miniscule (progress feels more stagnant than it is). Clear flaws are overlooked.
2. Finding the local peak in your game’s designspace takes time. Gathering feedback from extensive testing is slow. Slower still is the feedback processing by your subconscious mind.
3. Project velocity is “feast or famine”. States of flow are fickle. More often, your game is your Sisyphean boulder.

I’ve hatched a ridiculous plan to best these demons. Years from now, remembering this plan will likely force a cringe, but the sweetest fruits aren’t found on the well-trod paths.

The Plan: Game creation is a pipeline (think GPUs).

Made concrete: More games under simultaneous development. Code quagmires and demotivation will be met not with grit but with give. A given day may yield greater leverage on another project, and free of deadlines or external demands, that’s where I’ll go. Additionally, in those foggy hours where I can’t code, I may still be able to productively test, or draw, or do some other mentally orthogonal task. Victory.

Clear downsides:

1. Nothing ships until the pipeline gets filled.
2. What hype a game may find could die in the longer wait for release.
3. Provides more opportunity to fall prey to idea theft, if I happen upon something compelling.
4. Greater task switch overhead. Slow to switch, but also demands more documentation to ensure nothing is forgotten.

I expect (1), (2), and (3) to be ameliorated by breaking the pipeline metaphor. It’s less a strict pipeline, more a technique to defeat the aforementioned demons. Rather than spending time uniformly, I will lean heavily into a handful of games. “Shipped” is an important feature! When I get stuck, I switch. Let my subconscious figure it out in the interim.

On (3): Cloning is a real problem, but the fear of idea theft is much exaggerated. Everyone in the industry is awash with their own ideas – why would they want yours?

If a Product X of mine miraculously gains popular appeal, and gets stolen before I can ship it, c’est la vie. Hopefully my diverse portfolio will shield me somewhat.

Time will tell.

(4) I think less a drag and more a boon. It requires correct documentation practices; clear, intuitive design; and thorough journaling of the game’s history. These will support debugging and improve chances to catch design flaws. They also create a solid feedback loop on how well I’m coding and commenting, and will help expose where in the product lifecycle I’m weakest. Not concerned, altogether.

Anticipated/observed upsides:

1. Distance between you and your creations provides fresh perspective. If it’s boring, you’ll realize it. Rabbit holes and feature creep have less pull. Personal testing will be strengthened by forgetting the “happy paths.”
2. I expect feedback only grows more diverse with time. The pipeline insulates us from our knee-jerk reactions, allowing time for accurate feedback to emerge and take shape. The game is better for this.
3. Repetition of each phase of the software lifecycle helps delineate exactly what each phase is, what it requires of you – a learning opportunity!
4. Unexpected connections enrich designs. Serial work on one game limits chances to see parallels between mechanics and themes. A pipeline full of games being revisited regularly provides ample opportunity to make those connections. Each game is better for this.
5. The Pipeline demands toolchain investment. The pain of kludgy solutions may be ignored when infrequently felt, but becomes intolerable quickly with regular repetition. Though costly, the amortization is made clear. Higher efficiency and quality are the prize.

These arguments may hold up, or they may not. Without data, they carry no weight. It wouldn’t take much to shift the plan from awesome to awful or vice versa.

I know of no data other than the great mass of teams who seem to do just fine with serial development practices. Popularity has never made particularly great arguments, though, especially where intuition drives.

The cost of implementation is low enough, and the upsides tempting enough, that I will give it a shot.

I would like to re-arrange the site soon, to align better with the pipeline. I may need to find a new hosting platform/tech to make that palatable.