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.

In this first installment, I briefly explore how I got started making Missile Cards, cover the concept of a “minimum viable product”, and discuss the importance of keeping your scope narrow when trying out experimental game concepts you aim to sell.

Minimizing risk while making unique games

If there’s one thing I’ve learned from creating and launching several games over the past few years, it’s that pouring years of hard work into a game project doesn’t guarantee that it’ll be well-received or commercially successful. Making games for fun is one thing, but if you’re also aiming to sell your games and earn some decent income to fund future projects, you have to be willing to learn and adapt your approach to minimize risk as the industry shifts.

The types of games I most enjoy making are experimental, strange, dark, weird, (often) creepy, and fairly niche projects. Interactive fiction, horror RPGs, card games, and other varied genres that relate. Aiming for the unusual helps them stand out from the sea of “samey” games out there, but it also increases the chance that they aren’t going to resonate with a large enough audience to make them commercially viable.

It’s a big part of why I’m increasingly pushing towards trimming the fat, making smaller games faster, and working hard to keep things like scope creep and development time to a bare minimum.

That’s where this devlog adventure begins.

I started developing Missile Cards on November 12, 2016, because I needed a short break from my bigger long-term projects. When you grind away at something for over a year or more without being anywhere near close to the finish line, the stagnating feeling that comes with glacial-paced progress can be a real killjoy. I needed to finish something, to feel that sense of completion again and regain some positive fuel to pour back into my other projects.

For the past three years or so, I’ve been making games on the side while still freelancing full-time to make ends meet. 2017 is the year I hope to launch several new games and gain enough traction to justify spending more of my time on gamedev. It’s an ongoing process, but between my larger-scale long-term game projects, I’m pushing to crank out a few cool smaller things. That’s where Missile Cards comes into play.

Missile Cards is a complete 180 from my horror and RPG-focused leanings. It’s bright, colorful, retro, and very different.

As a huge fan of unique digital card games and retro Atari games, I came up with the weird idea to basically re-imagine Missile Command as a turn-based card game. It’s a risky move, given the odd mash-up and fairly niche genre combination, but keeping things moving along quickly and intentionally limiting the scope of the project minimizes the risk. By the time it launches, Missile Cards won’t have to sell a ton of copies to justify the time I’ve put into it. That’s by design.

My goal for this project from the very beginning was to create a small, highly re-playable game, then test it, polish it up, and launch it on Steam–and all in just a matter of a few months. If it sells a ton, great! If not? Well, I won’t have spent a year grinding on it only to have it fail. And if a project is going to fail, it’s always best to fail fast and fail forward by learning everything you can from the experience then move on.

Here are a few other great reasons for making smaller high-quality games on an ultra-condensed timeframe.

4 Benefits of Making Small Games Fast

1) It lets you experiment.

Building a big, sprawling game around a very experimental, untested idea or genre can be hazardous. Hell, building a big game of any sort, especially when you’re a solo dev or small indie team, runs the risk of everything falling apart when you inevitably hit the wall. Making smaller games minimizes the impact of a potential failure, giving you more room to try out weird and cool ideas that might be too risky otherwise.

2) It helps you stay motivated.

Personally, I’ve found that the longer a project takes to make, the greater the chance I’ll lose interest in it and let it fall to the wayside to focus on other things. I’m not alone in this. Keeping your dev cycle intentionally short, without crunching yourself to death, lets you stay focused and hit the finish line before you run out of steam.

3) Constraints breed creativity.

Limiting your scope can be incredibly empowering as a dev. Rather than trying to jam everything under the sun into your game, narrowing your scope and laser targeting on the most interesting elements can let you really find the magic in a simple design. Take a game like Downwell, for example, which hangs its simple (but striking) visual style and straightforward gameplay on a very powerful hook: its super unique gunboots mechanics. That really makes the game something special.

4) It cuts down on financial risk.

Making games isn’t only about making money, obviously, but it sure stings when you spend a few years working hard to develop a project that fizzles at launch and doesn’t come close to breaking even financially. This is common for a lot of devs. However, by creating a game in a short timeframe, it makes it possible to break even much faster, so any sales above and beyond that point are a win.

Aiming for a minimum viable product

Today’s digitally-evolved world of Early Access, DLC, and post-launch game updates is well-tuned to the concept of the “minimum viable product,” which is what you want to aim for when making a smaller game.

For indie devs, this entails creating and launching a small but high-quality game that’s fun, polished, and packing just enough features and content that people feel ok spending whatever price you set for it. This lets you get a game out into the wilds, gather initial sales, user reviews, and broader player feedback, then decide how to proceed.

It doesn’t make sense to spend tons of time packing your game with lots of extra content and features only to discover post-launch that it isn’t selling well and nobody really cares about all the junk you spent many extra months added-in anyway. I’ve been there before with past projects, and it sucks.

With Missile Cards, I actually started with a fairly narrow scope, then I trimmed it down even further. The original idea called for three planets, each with wildly different styles of card gameplay and a handful of unique bases to unlock. Early-on in the prototyping phase, I realized it would have taken a lot more time to create all of the unique game art, achievements, back-end code, and new card mechanics for the large number of areas I had planned out. Additionally, I didn’t feel like I’d have enough interesting new mechanics to roll out across all of those extra stages. The design plan just felt unnecessarily bloated. So I condensed it all down to a single planet and a handful of unlockable bases, then I focused on making each base a meatier chunk of content that can keep you engaged for a longer period of time.

On the surface, the game’s five core bases don’t really look like a lot of gameplay, but each has its own unique deck of cards, special hazards and defenses to play with, and challenging missions to complete in order to progress. They’re designed for players to spend a decent chunk of time on across numerous matches before progressing. The game is also pretty hard, so it takes some time to hone your strategies to stay alive. Between missions, Steam achievements, and a few other systems I’m working on, there should be a lot of incentive to keep playing bases you’ve unlocked and mastering them over time.

Making these tough calls is an important aspect of keeping your scope in check and pushing towards building a minimum viable product in a short timeframe. Ultimately, I’m aiming for a very reasonable price point of around $4.99 or so, which feels about right for the amount of content planned for the game’s launch build. We’ll see how that goes.

Getting your prototype working ASAP

GameMaker: Studio is great for rapid prototyping, whether you’re using GML or the drag-and-drop system. Missile Cards is 99% GML at this point, having recently made the transition to using code for pretty much everything. Initially it took me a few days to get the core gameplay loop in place and functioning the way I needed it to. That’s fairly fast, considering the level of complexity that’s under the hood with the various card systems.

With any game development cycle, roughing your gameplay into place and finding the fun is an important step to lock down early on. The sooner you can get your core gameplay loop working, the sooner you can start testing everything to see how it feels. A lot devs just dump in colored boxes or ugly programmer art as placeholder to get their systems working. Go with whatever works for you.

I’m more of a visual-oriented designer, so my first prototypes looked a bit closer to what I have now, but the early card art and UI design was still a patchy mess. That’s totally fine during the prototype phase. It’s really all about getting your game working and making sure you’ve got something solid before spending more time on the look and polish. Once you find the magic, then it’s go time to whip the rest in shape.

One month and two days after I started developing Missile Cards, I had a fairly polished and playable vertical slice. I took some screen grabs, cut a quick trailer, and launched my Steam Greenlight campaign. Everything you see on my Greenlight page was created in just over a month of dev time. Not bad for about 32 days of off-and-on work. Greenlight, of course, is a whole other challenge. I’ll dig into that more in the next installment. Until then, stay tuned and happy coding!

Have any questions or comments? Please drop me a line in the comments section below! I’d love to hear from you!

2 Responses to GameDev Behind The Scenes #1 – Making A Small Sellable Game Fast by @nmeunier

Hi buddy,
Great article, look forward to follow up articles. I like the game concept as well. Seems to me that this type of game would work well on mobiles? Have you considered this?
I’d be more inclined to play it on my mobile than PC?
Just my thoughts.

Thanks a bunch for the comment! Absolutely, I didn’t talk about it in this series, just yet, but my plan is also to bring the game to mobile…after the Steam launch. What I’ve found is that if you go mobile first, then try to get on Steam, you tend to get lambasted — or are given a hard time, at the very least — by that community. It can be harsh.

It really is a good fit for mobile, and that’s been part of the battleplan all along. I’m just covering my bases and going with a Steam launch first to avoid hassle down the road (and hopefully generate a bit more income). There are a few other good reasons to launch on Steam before mobile, too. Steam is pretty easy to update your builds in. Once your game is live, you can basically just upload a new build and push updates live within seconds.

So if users inevitably find bugs or have issues, it makes it generally fairly easy to patch and update with minimal fuss. For iOS, updates have to go through an approval process, and every update resets your user reviews, which offer valuable social proof for potential customers.

So basically, the more kinks you can iron out before you launch on a more restricted platform, the easier time you’ll have fixing things quickly — at least that’s been my expreience so far.