Right after the Phoenotopia Flash game wrapped up development in 2014, there was some pondering over what to do next. At the time, there was just me and one artist. But, I had nothing for her to do.

Me: “Nothing to draw right now, so… talk to you again in a few months?”

You can’t part with someone and then rehire them a few months later – not in a traditional workspace anyway. But we were amateurs, and luckily, she had other gigs lined up. Things run differently in the super indie space.

I abandoned Flash and ActionScript3 and started to learn Unity, the rising game engine of the time. During these periods where I was figuring out what to do next (it’d end up being Phoenotopia Awakening), no art was being created at all.

Zero Art! Seems kinda wasteful, doesn’t it? 🤔

(A visualization of “perfect work”. Everyone works at full sprint, churning out work nuggets without need for communication. Perfect “Hivemind”!)

In game development (and perhaps any collaborative endeavor) you’ll run into bottlenecks & slowdowns trying to get development up & running. I’ve long wrestled with this phenomenon, repeatedly brushing upon what I’ll now call the “Imagination Gambit”. Today I’ll talk about what that is.

Collab Model A: Request work *AFTER* things are ready

In a simple model of collaboration, you request something only after the rest of it is done. For example, say this was about music:

Director: “We’ve made a new biome! It took 3 months to create the graphics and levels, but you can now run & hop through the area. Take a look at the build and write music for it!”

Musician: “Okay!”

In the above simplified scenario, there’s no waste – the musician scores what he sees. But while waiting for the environment to shape up, he sat idle for 3 months. Extrapolate this over a year, the musician could make 4 songs, which is not very efficient. We want to increase concurrency.

(A visualization of Collab Model A. Other team members are blocked awaiting communication on what work to do next)

Collab Model B: Request work *BEFORE* things are ready

When you can’t wait for others to finish their work before starting yours, you have to imagine what their work will eventually produce – and start building around it. It’s a “gamble” with the “imagination”, if you will.

Director: “We don’t have the biome *yet*, but we’re sure there’ll be a completely underwater aquatic biome in the future. Here are references of what it might look like:

Musician: “Okay!” (proceeds to score song)

(One of the references that helped form the Aqua Area. I had watched an episode of “Princess Connect” and this environment caught me)

In this improved model we’ve got more concurrency. The musician can work before graphics, levels, or even gameplay exist. Now everyone just has to meet at the finish line at the same time.

(A visualization of Collab Model B – communicating a job occurs earlier thanks to “Imagination Gambits” – it starts to resemble the idealized “Hivemind” model a little more)

This doesn’t always proceed smoothly. There are tradeoffs.

The Trade Offs

First is the communication cost. When you can show someone something in-game, a lot of information is immediately conveyed : how it looks, how it plays, lighting, enemy behaviors, pacing, atmosphere, etc.

But when a thing only exists in your imagination, you have to use words. Quite a lot of words it turns out! It’s not easy to get someone else to imagine what you’re imagining.

(email exchanges between the musician & myself circa 2023. At 18 pages of discussion for one song, this is considered a smooth ride. I now get why ‘managering’ is a role in big companies)

The second tradeoff in this model is the extra risks. What if you “imagined” incorrectly?

Director: “Funny story, the area that was planned to be the aquatic biome is now a desert biome. Sadly, the aquatic song you made will have to be binned”

Musician: T_T

When you’re gambling upon an imagining far into the future, there’s a risk that what you imagined will not come to pass. Maybe the graphics end up too similar to another area. Or maybe swimming feels cumbersome once you can actually play it, so the aquatic area gets cut.

What yesterday was a win for efficient concurrency has today turned into a wasteful expenditure of everyone’s time and resources. We’ve defeated “idle time” (model A) but gained “wasted work” (model B). Can we call that a win?

(Nelle building a shelter. Hopefully she did some ‘preproduction’ first, or she’ll find out the hard way…)

Some Actual Examples

It turns out the scenario I’m describing with the aquatic song actually happened. The song “Sea Within” was scored 3 years ahead of the actual aquatic area existing.

Only recently did designing, artistry, tilesetting, and lighting converge to bring the aquatic area into existence:

(Behold! The Aquatic Area!)

What do you think? Does the song fit the area?

We count this one as a success. Despite the 3-year gap between scoring and building the space, the original “imagining” held. The song will need some updating, but much of what was established initially will stay.

Here’s an attempt that didn’t land.

(“Blythe Braves” and “Ashley Ryker”. Will their battle be legendary?)

Meet “Ashley Ryker” – intended as the main character’s rival. Early on, I knew Blythe should have one. A Shadow to her Sonic. A Zero to her Megaman X. I imagined Ashley as a gun-slinger taking inspiration from the Wild West, and I conveyed this to the musician. The song “A Rival from the West” was created as a result.

However, a western-inspired Ashley did not come to pass. It fit the maritime theme better if Ashley was a Space Pirate. As a result, “A Rival from the West,” with its cowboy whip, western whistling, galloping guitar, and other bespoke elements, is now a musical expression for a character who no longer exists.

The song has become “homeless” you could say.

The Territory in which it Comes

I’ve been using music as an example, but the same problem of imagining a future task, communicating, and delegating it early to allow concurrency applies to all areas of game development. You can create an enemy before the environment it belongs in is finalized, design a level before its puzzle mechanics are settled, or research a technology before knowing if the game will even need it.

Every time an “imagination gambit” fails, time and resources get spent, and more “homeless” assets are created.

And that’s okay! That’s not unusual. It’s part and parcel of game development. It comes with the territory.

If that were not the case, there would not exist any obsolete code, scrapped levels, tossed songs, or discarded characters ever. But look around, and the examples abound.

(Even Nintendo has scrapped some amazing designs)

Unused homeless assets are imaginings that didn’t land. When I was starting my game dev journey, I’d bemoan having to scrap anything. It felt wasteful. I was taught to eat every grain from my plate.

But I know better now. Game development is a tangled web of layered dependencies. Levels can’t proceed without enemies, enemies can’t proceed without programming, programming can’t proceed without design, and so on. Expecting the best answer on the first try is unreasonable. If one waited until every piece was perfectly known before making a move, nothing would move.

The Imagination Gambit

So, gamble upon your imaginations! It’s a skill that can be honed and improved – the hit rate gets better. Don’t panic if ‘homeless’ assets pile up because they’re the scaffolding to build the real game.

(This scene was proposed for the box art. It’s currently homeless but maybe it can be used for a future music CD?)

I don’t advocate for being purposely wasteful – one must still be judicious about what is unexplored potential and what is cruft. Of the homeless assets, we regularly evaluate their potential to be repurposed elsewhere.

Budget for them in morale and in the schedule. By being receptive and adapting to newly unfolding discoveries, we can create a better game. From my experience anyway.

Thanks for reading! Next update will be at the end of November.