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.

“Next Title,” and SRG Direction

As with every new venture, the first year of SRG has been extremely educational. I’ve learned a ton on new techs, on time management, development estimation, writing, and a plethora of other things. However, there is one lesson that stands out above all others: Ship.

This isn’t a crucial lesson for everyone, but it is for me.

As of today, I’ve spent just shy of 700 hours just implementing Lyceum. That isn’t much, by many metrics. It’s a lot to me, especially for what I had intended to be a “less than a month” project.

The crux of my problem is that like many indie devs, I aim high. Even when trying to aim low – Lyceum was literally the smallest project out of ~30 I had fleshed out – we aim high. I have cut and culled features ruthlessly and yet it’s still far too large as an initial project.

Nobody sets sail in an unfamiliar industry to make mediocre products. We do it because we think we have something unique to offer. But the biggest thing standing in the way of offering that product, for many of us, is an excess of ambition. I don’t want to ship something that I am not personally wowed by, but that’s an extremely high bar.

There’s a wonderful quote by Ira Glass about this issue and my intent is to follow his advice, in spirit if not in letter.

I’ve considered several post-Lyceum projects for SRG. Some of my personal favorites so far:

• “Superorganism” game: You control some species of superorganism to solve problems. Maybe something like this video: fire ants making a living raft.
• Rube Goldberg-style tower defense: Incoming enemies are physical objects with various properties. You need to build a contraption that keeps them out.
• Robotrek meets Sims meets roguelike: You build a robot and define its behavior policy (a la Final Fantasy 10’s gambits?), then set it loose in a dungeon environment. Its success enables you to build better/smarter robots and explore other environments.

All fairly ambitious, whether you think they’d be fun or not.

Instead, my plan is to build games that are so small that I can’t help but finish them. I also don’t care if they’re profitable, or even likely to be. Hell, I’m not even all that concerned with them being fun. I care most that they are done.

To that end, the next game I have in mind is based on this looping GIF. I don’t know who originally made it, but the basic idea as a game is to allow players to adjust the arc and angle for each cup in order to create a “path” for the ball to travel.

Because I think this would be quite hard to actually play successfully, I’m thinking that play does not have a ball limit – they just keep spawning, and you keep trying to tweak the path to get them further and further along. Perhaps there would be bonus points for certain types of paths that are tricky?

Anyways, it’s a small game with small goals. 🙂
We’ll see!