Abandoning your game and moving on — Indie dev reflections.

Francis Rei L. Israel
5 min readDec 13, 2019

“A work is never finished… only abandoned.” — Paul Valéry, but in French and before Oscar Wilde and George Lucas kinda quoted him.

A header image for WyVRn, containing a lich who is riding a dragon, which is flying towards a skyscraper-sized tortoise.
Dragon vs enormous turtle!

So, this week, I’m releasing my VR project, WyVRn. I probably should’ve done so long ago.

(Read a slightly updated version of this article here!)

The game is about being a lich, riding a dragon, and doing the bidding of The Professor in his petty relationship drama. I probably went too far adding things to the project around the time I put the player into a hamster ball and put that hamster ball into a pinball machine.

An image of a colorful, WyVRn-branded pinball machine in a video game.
Spaceballs the pinball machine! Spaceballs the flamethrower!

It started off innocently enough. I would wait to hear back from someone about things like voice acting, or wait for certain plugins and software to update so compatibility issues would be resolved. While I waited, I would toy around with stuff in the meantime.

Then I ran out of things to wait out on long before I ran out of oddball VR ideas. And I began stapling increasingly irrelevant side-projects onto this one instead of giving them their own room to grow into fully-fledged projects. And in not letting an idea grow, you block yourself from growing alongside it.

So, how do we know when to abandon a work and move onto others before that scope creep sets in? How do we differentiate between ideas that legitimately belong together and ideas that need their own space? First, let’s explore why it’s so hard to abandon your works.

Indie Devs and Abandonment Issues

Indie game developers seem to have a particularly hard time letting their babies out into the wild, either hiding them from the light of day, or keeping them in a perpetual “early access” state.

I would blame this largely on the availability and value of resources. In this market of post-release patching, you see games get released because they ran out of time and hit a deadline, which is ultimately because they have a budget. Mistakes can be fixed later.

For me and many others, this is more of a hobby. Time isn’t that much of a limiter, and making money isn’t necessarily the end goal. So, while a publisher will force a developer’s hand, a fully indie/hobbyist dev lets their child stay home a bit too long.

Half of my short trailer is only kinda related to the main game.

The particularly indie fear of abandoning a baby isn’t to be blamed only on deadlines, however. There is also a fear of rejection. What if this thing you’ve poured so much of yourself into doesn’t turn out good? The responsibility for this failure doesn’t have as many bodies to spread the bad feeling a round.

So, you don’t have external deadlines to push you forward, and a more personal fear of rejection holding you back. How do you counter this? What do you do to force your own hand?

Maximum Allowable Product?

You’ll see a term in product/game development Minimum Viable Product, which is covered in depth elsewhere, so I won’t belabor the point. You ask yourself “What is the least you can do and still have ‘a game’?” The concept forces to get the core down so you can get feedback early and quickly. Then you get on iterating.

A robot rides on the shoulders of a legless dragon made out of tubes and boxes. He flies over a castle launching fireballs.
Early programmer art made of power towel rolls and cardboard boxes is enough to start getting feedback.

If the Minimal Viable Product defines a starting point, perhaps you can define an endpoint with the opposite, a Maximum Allowable Product.

Set out what counts as ‘enough.’ Do you have a story? Cool, lay out the beats. Lay out your basic game mechanics. Anything you add to these things in game development must be direct improvements to these notes. You can make the story better, more fleshed out, but you can’t make another story. Save that for sequels, DLC, card game flavor text, spinoffs, whatever. Use the story to scope out how many levels/how much map you need. Stick to that. You can flesh out your mechanics and apply existing mechanics to other things, but can’t invent new mechanics to shoehorn into the rest of the game.

Applying theoretically to WyVRn

Okay! Let’s take all that and see what it says about what should and shouldn’t have been in my game.

Getting the dragon to move on moving platforms? Yes. Being on the dragon is a mechanic, and this is an improvement on it.

Making new enemies to fight? Good up to a point. That point isn’t firmly defined by this concept. Don’t go crazy, I guess.

The texture creation tool being used to map textures to a mechanical person.
This “clockwork zombie” and its multiple variants was a good use of time spent for this game.

Time trial/race on the dragon? Getting colder. You aren’t inventing anything new, just reapplying what you’ve got, but this (in my case) is not servicing the core of the story anymore.

Letting the player get off the dragon and onto a hamster ball? No. The mechanic for movement was the dragon. The ball doesn’t even fit thematically.

A wireframe hamster ball sits atop a child’s slide, about to roll down into a ballpit at the bottom.
This katamari-inspired level might have been a good idea for gameplay, but not for this game.

Putting that hamster ball into a pinball machine with working flippers? No. This is so out of the original scope. No, it doesn’t matter that you were recycling assets from the game.

Side level where you walk around with a marionette? Please stop.

A marionette shaped like previously-seen mechanical men is dangled from a set of disembodied VR hands.
The marionette also had guns. You moved around by setting him on the ground and ‘dragging’ the world towards you.

So, are you taking that stuff out?

Nope! This whole deal is about letting go and abandoning your precious children instead of lingering on them forever, and subtraction counts as lingering. Don’t remove stuff unless it will directly improve the game. The things I’ve stapled on are mandatory and, I think, out of the way enough that they don’t detract anyone who wants the ‘purer’ experience.

Now that I’m free, I’m going to go on to do more short VR experiments, like Unicorn Carnival (reverse ringtoss!), or what I’m tentatively calling “Paranormal Photography”, where ghosts are invisible to you, but not to your low-battery cellphone camera or your polaroid.

VR Unicorn is about to stick its horn through the hole of a donut.

With these smaller, more-focused projects/experiments/proofs of concept, I’ll at least know how to avoid gluing them together like some kind of gamedev chimera. But, in case you want to see what that chimera looks like, check out WyVRn on Steam! Finally coming out of early access on Friday the 13th of December 2019!

--

--

Francis Rei L. Israel

By day, embedded software engineer. By night, experimental VR game developer.