Have you ever wondered what goes on behind the scenes throughout an indie game’s development cycle? In this ongoing devlog series for my upcoming game Missile Cards, I’m peeling back the curtain to share my processes, thoughts, tips, and experiences as I develop and launching a small commercial game on Steam using GameMaker Studio.
Life is unpredictable. Game dev is messy business. Things never go as planned. I’ve learned to both expect and embrace this. Case in point: I was originally going to spend this installment talking about my experiences with getting Missile Cards pushed through Steam Greenlight last month, but that’s now moot. Steam is ditching Greenlight very soon and replacing it with something very different.
It brings up a good lesson: things change rapidly in the game development world. Platforms, technologies, and even strategies for creating a successful game won’t always be a sure thing down the road. But some things never change…like the importance of actually finishing and shipping your game. It’s a lot harder than you might expect.
That’s why we’re about to dig deep into the dangers of scope creep and why it’s so important to muscle through that last stretch of your project to hit the finish line.
Finish. Your. Damn. Game.
Most gaming enthusiasts have an ever-growing “pile of shame” stacked with older games they haven’t finished (or even played). As game developers, our piles of shame are a little different; they’re stacked with half-baked ideas and games prototypes we started making then lost interest in and abandoned. I’m guilty of this. You’re guilty of this. It’s a thing that happens.
Prototyping is an important part of the game dev cycle, and not every idea you start tinkering with will spin into something worth fleshing out into a complete game. That’s fine. But making a game — yes, even a small one — takes a lot of time, energy, and hard work. If you’re never actually finishing and shipping any of your projects, you’re missing out on a lot of important opportunities. Potential sales is the obvious one, although there are many useful insights that can only be gained from putting your game out into the world for people to play and respond to. Also, the process of launching a game in and of itself is an invaluable, and often humbling, leaning experience.
Here are three (of the many) good reasons to finish your game:
1) An un-launched game doesn’t do anything for you.
Sitting on an unfinished project means you’re not earning any income from it. It also means that nobody is playing it. Neither of those things are good. What’s the point of pouring your heart and soul into making a game if it never sees the light of day?
2) Unfinished games take a mental toll.
I don’t know about you, but starting to work on a project, getting it past the half-way point, then letting it gradually fall to the wayside and gather dust makes me feel like crap. Even as I’m charging forward with cool new projects, those lost projects haunt me in the back of my mind, and they weigh heavily on my creative soul. Some are easy to forget (they were garbage), but the good ones left behind are what keep me up at night, whispering to my consciousness: “Finish meeeeeeeeeee.”
3) Finishing a game frees you up to focus on new projects.
Granted, work on most games these days continues beyond launch, as players expect a certain measure of support and updates. Still, launching your game and surviving the inevitable window of bug fixes and update requests eventually frees you up to start working on your next project. That can be incredibly exciting and cathartic.
It’s easy to make progress on your project during the early stages when you’re brimming with ideas and excitement. Still, after months (or years) of development, when all the fun creative tasks have been tackled, your game’s to-do list will gradually begin to morph into a laundry list of unpleasant chores you’ve been putting off. Bug fixes. Optimization. Game menus. Audio. Final polish. Platform-specific code fiddling. All things that are super important but nowhere near as cool as seeing your core game loop come to life.
By that point, a lot of developers are tired and ready to wrap it up and move on to something fresh again. It takes a lot of stamina and dedication to see a game through to completion. People often say the final 10 percent of your game project is going to be the most grueling and take the longest to muscle through. They’re not wrong.
Many indie developers, however, don’t even get to that final 10 percent. They never even get close. Or if they do survive to the home stretch, it takes way, way longer than they expected. A lot of different things factor into this, but there’s one culprit that blindsides even the most well-intentioned game makers.
The slippery slope of scope creep
Scope creep is a game killer. It’s one of the biggest reasons people never finish their games. The larger, more complex, and more unwieldy your game design gets, the greater the chances of it bogging down your development time and growing into a gnarly beast that’ll hungrily consumes all of your free time and sanity without an end in sight. That’s usually the point where a lot of devs will give up on a project and drop it to start something fun, cool, and new.
Thus the vicious cycle continues.
One of the best ways to battle scope creep is to set intentional constraints for your project. In the last installment of GameDev Behind The Scenes, I discussed why it makes so much sense for solo devs and small teams to consider crafting smaller on a faster cycle. Keeping scope creep under control is a key benefit of this tighter, more streamlined approach to game development, though it’s not a perfect system, as you’ll see in a moment.
As I type this now, Missile Cards has been in part-time development for just a hair over four months. I’m super happy with how it’s shaping up, and it’s (thankfully) almost ready for launch. That’s a pretty short dev cycle even for most indie games, but getting to this point easily took me a few months longer than I had originally planned. It could have been much longer, too, as I almost fell prey to one of the most common sinkholes of game development.
A real-world example of battling scope creep
Here’s a look at scope creep in insidious action, using my own game-in-progress as an example.
Missile Cards started out as a “tiny” project to begin with: I set out to make and launch a Missile Command-inspired turn-based strategy card game within a few months (three months was the sweet spot I had in my head at the time). I was lucky, in that it only took me a few days to get a prototype I was happy with, then spin that out into a fully playable vertical slice of the game.
That early prototype was fairly solid, and I was surprised by just how much fun I was having playing the basic core loop over and over again across several days of testing (which is easy to say about your own projects, of course, but isn’t always truly the case).
It gave me hope and set my mental gears turning about how to start fleshing things out into something folks wouldn’t mind spending $5 on. Take note: This is the point — when you’re excited and bristling with “cool ideas to add” — that things can start to get dangerous.
My notebook scrawlings, after a short, frenetic flurry of brainstorming, called for three full planets worth of content for the game. It didn’t seem like that much work on the surface. Easy-peasy!
Based on my core design, however, that would have amounted to roughly:
- 15 unique unlockable bases (each requiring its own unique music track, background art, special mechanics, base art and animations, etc).
- 15 separate finely-tuned and balanced 52-card decks (each requiring a careful mix of hazard cards, ability cards, and an array of different weapon card combinations and damage strengths, plus the art and code required for all of this)
- 90 missions to unlock (3 core missions and 3 special bonus missions for each base, including tons of variables and code to make it all jive.)
That may not sound like a lot to the average player or even most developers, but I’m just one guy working on this thing on a very part-time basis while also juggling other projects and a full-time freelance workload.
Like most developers starting out a new project, I was oblivious to how long it’d actually take to create all of this. I figured I could do it all in the super strict three-month timeframe I had set for the project. Once I actually dug into creating the first planet’s worth of content, I quickly realized just how much work it’d take to triple that first bit of content to bring my original concept to full fruition.
Suddenly my small, short game didn’t seem that small or that short at all, which is exactly the polar opposite of what I set out to accomplish with the game.
At that point, after mulling things over for a few days, I made the tough decision to scale it all down to one core planet’s worth of content, then double down my focus on making that as tightly tuned, polished, and replayable as possible. As a compromise, I dropped in some extra code that would give me the flexibility to add on more levels and content post-launch, if the game sold well enough to merit it. To extend replay, too, I also decided to ramp up the difficulty curve a little and weave in just a few more upgrades to help players progress over time.
Scope creep crisis averted! And I ended up with a tighter, still very satisfying game in a third of the time it would have taken to make otherwise.
Ultimately, I’d rather give players a shorter, tighter gameplay experience and leave them happy and wanting more — especially when the alternative means quadrupling your dev time, charging a higher price, and piling on half-baked content that doesn’t feel as unique or satisfying. For me, it also just didn’t make sense to go overboard on content and extras for such an experimental, unproven idea. I know there’s a definite niche for Missile Cards, but it’s hard to say exactly how well it’ll do at launch, especially on Steam.
The whole point of Missile Cards, too, was to create something small, fun, and polished in a very short timeframe. Settling on that constraint from day one, and sticking to it despite the siren’s call to leap down the idea rabbit hole, saved me from what could have spun into a nightmare that I may have been tempted to abandon, like other projects in the past.
Identifying scope creep before it’s too late is very hard to do when you’re in the thrall of the creative process, but making those tough calls is crucial to avoiding one of the most common pitfalls developers stumble into.
Remember: cool ideas always have a hidden cost to them. Most aspects of game development tend to take a lot more time to implement and polish than you expect they will. It’s always important to step back, reign it in, and consider the potential future impact creative decisions might have on your game down the road. This can prevent a lot of headaches and wasted effort.
So where does this leave Missile Cards?
Surviving the home stretch
After about four months in development, I’ve got the core game all in place and tuned to a point where it feels good. It’s not quite 100% finished just yet, but it will be in the next couple of weeks, and most of what’s left is really a matter of adding more polish to a few spots, finishing some lingering menu bits, fixing a few bugs, and fine-tuning the later stages, difficulty-wise.
That feels great, but I’m not out the fire yet. It’s missing one absolutely key ingredient every game needs: real-world player testing and feedback. Up to this point, I have done some light public alpha playtesting, and I’ve used that feedback to help improve and add features to the game. Initial feedback from the early Missile Cards demo I released a month or two ago was encouraging and quite positive, but it’s nowhere near enough for me to be comfortable shipping it just yet.
Some of the most useful feedback I received actually came from a few bits of unexpected YouTuber and livestreaming coverage the demo received. Getting an “over the shoulder” view of someone playing your game live and seeing how they interact with it when you’re not sitting in the room next to them is powerfully informative. It helped me spot and fix some potential design issues early-on, and ultimately prompted me to add several important features to the game.
With launch only about two months away, the next step is get a much bigger batch of in-depth player feedback on the near-final build. For that, I’m rolling out a closed Beta test for Missile Cards on Friday (2/24) — you can sign up here if you’re interested — and that’s going to be vital for making final adjustments and getting a sense of what people think of the game before I prep for launch in April.
Finishing your game is a huge accomplishment and milestone worth celebrating. Unfortunately, that’s also when a lot of the real work truly begins — from final beta testing to actually planning and executing a successful launch.
Not sure what that all of that entails? Stick around, because I’ll be sharing my behind-the-scenes efforts leading up to and beyond the upcoming Missile Cards launch on Steam in April. In my next installment, however, I’ll report back on how the Missile Cards beta test went and share my process to help you run you own closed beta.
Nathan Meunier is a long-time freelance writer, author, and part-time indie dev. His upcoming GM:S project, Missile Cards, is launching on Steam in April! Follow him on Twitter or check out his other projects at www.nathanmeunier.com