You can make a dozen games this year. Sound impossible? It’s not. Try this simple game development methodology from someone who has pulled it off and see for yourself that 12-in-12 is a reasonable goal.
The McFunkypants Method
I’m going to share with you my personal game development methodology. I don’t claim to have invented the world’s only system for reaching the finish line – far from it. This is merely a spellbook, a toolbox filled with my own personal tips and techniques that I use to battle the demons that try to prevent me from launching a game. These demons include feature creep, all-or-nothing design, and unbounded optimism. These are tricks I’ve developed in the course of succeeding where I had failed in the past.
You see, in 2012 I achieved the lofty goal of creating 12 games in 12 months. Surprisingly, it wasn’t all that hard: it didn’t take any more work than my many failed projects had in previous years.
So what was the difference? A more mature, more seasoned, less wide-eyed and less optimistic approach. Don’t get me wrong: there’s nothing at all wrong with optimism. In fact, I encourage it! Without it, none of us would be gamedevs. Without some optimism you’ll never get anywhere. I just needed to approach my projects with a slightly more humble mindset.
I’d like to share some of my tricks and tips with you here. I ask that you consider each of them, yet feel free to accept or reject them as you see fit. No one technique can work for every person, but if you take away a single technique or mindset that helps you pull off the One-Game-A-Month goal of 12 games in a single year, then I’ll be happy.
Join us!
Try using these tips in your next game project. Perhaps they will help you out too. Maybe you’ll come up with your own best practises that are different or better. That’s great! Like with most advice, the key is to consider the message, accept or reject each point as you personally see fit, and adopt (or adapt) those practices which appeal to you.
Reach the Finish Line More Often
90% of game projects never see the light of day. My own personal experience confirms this. I’ve been making games for over twenty years, and of all the games I started – filled with enthusiasm, a detailed plan, and infinite brainstorms worth of ideas – only a small percentage were ever released. This caused me years of heartache. I was a good coder, I could produce acceptable artwork, I had enough good ideas to feel confident about my plans, and yet that wonderful state where the game is ready for the public was an elusive target.
Why? Because actually implementing all these exciting plans always involved challenges that I hadn’t predicted. Plus, the enthusiasm I had for each project would typically wane as the finish line approached. The going would get tough, the money would run out, the due date would pass me by, and the fun would end. All that would remain was that slog though the final stretch that many devs call the wall.
The wall is the point in a software development project where it is no longer fun. All the easy-to-implement things have been coded, and what remains is the busywork: bugfixing, tricky bits of code, repetitive tasks, parts that rely upon things outside your control, that one missing level or sound effect, installation issues, user testing, that reported bug which you can’t reproduce, and app store submissions.
Finishing a game could be thought of as analogous to climbing a mountain. With luck, you can do so with nothing more than sneakers and ambition – but this generally results in catastrophic failure. Instead of free-climbing my mountains without a thought or a plan, I started bringing ropes and holds, studied the rock wall beforehand, took note of sections that would be tricky, and paced myself.
How? Reduce Risk: Use Save Points!
Imagine having to finish an entire game without a single game save. This is how many game developers create software: all-or-nothing, no safety net, you either hit it out of the park or crash and burn. No middle ground. No accounting for unplanned contingencies. This is a sure fire way to unintentionally aim for failure.
After you do this a few times, you will start to see the pattern: optimistic plans without save points along the way are extremely risky. Why not lower the risk and give yourself multiple exit points along the way?
Start to Finish
Let’s dive in. I’m going to use a game I wrote in a weekend as an example to illustrate many of these points. This real-world example should help to prove this works.
1. The Brainstorm Stage
Brainstorming is the best. I love jotting down vast lists of item types, treasures, quests, character names, level ideas or building blocks. It is fun, and it’s a great way to start working on a game. But there’s a hidden trap: brainstorms are, by their very nature, about quantity, not quality. I like to joke that an acronym for brainstorm is B.S.
If you do begin each project with a huge brainstorm, great. But don’t start working on your game until you’ve thrown 99% of what made it onto your initial list into the “save it for version two point oh” wishlist.
2. Make Two Lists: Needs and Wants
One great way to pare down the massive, feature-creepy, overly optimistic tome that is a typical gamedev’s brainstorm is to rate each bullet point on a few scales, like:
- Originality
- Viability
- Ease of development
- How much art it would require
- How fun it sounds to play
- How fun it sounds to code
Sort your list and discard the vast majority of your ideas. Save most of them (especially the hardest ones) for later.
For each item in your top picks, ask one final question: is this a must have or a nice to have? For the first prototype, focus solely on the essential, couldn’t-possibly-work-without-it features.
Secondly, think: how difficult will each item be to implement? Does it require a lot of code or content? Don’t be at all ashamed to plan in a lazy way right now: you will have to be disciplined enough to put many of your greatest ideas on the back burner simply because implementing them will take a large number of hours of work. Be lazy: choose the most essential features that are easy to create.
What are are aiming for when you attack your giant brainstorm is to pare it down to the absolute essentials only. Distil your idea to the single core game mechanic you like the most that would be easy to implement. Do one thing well, not a dozen things half-baked.
This will be your MVP: your minimum viable product.
3. Write the Elevator Pitch
Once you’ve described the MVP to yourself – which means being able to describe the entire basic concept of the game in one paragraph, with one or two features at most – it’s time to refine it.
Pretend you need to convince a major publisher executive of the viability of your game during a chance meeting in an elevator. You have ten seconds. Can you describe your game so enthusiastically, so interestingly, so mindblowingly that in that brief moment you could score a huge upfront royalty payment and publishing contract?
Write this elevator pitch down. Edit it. Make it shorter. Pretend, instead of the above scenario, this would be the text copy of the back of your game’s box if it was sitting on a store shelf. Imagine a gamer picking up the box and turning it around. They have hundreds of other games to choose from, but they’ve decided to give you a dozen seconds of their time to considering yours. Does this pitch sell the game?
If you read it to a friend (or even better, a stranger) are they intrigued? Excited? Enthusiastic? If you can say yes to these questions you know you’re on to something good.
Just for fun, and to illustrate all my points, I’m going to show you my work-in-progress for a recent game I made. The elevator pitch at the beginning went something like this:
You are the villain. Two lovers desperately want to embrace each other. Your mission is to keep them apart by building walls that drive them farther apart without ever making it impossible. A turn-based strategy puzzle game based on A-star pathfinding.
4. Draw a Stick Figure Storyboard Comic
The next step, before you start coding or creating vast libraries of content that may or may not make it into your final game, is to do a rough sketch of the game in action. You do not need any artistic skills: these can be black and while crayon stick figure thumbnails. What you’re aiming for is a visual representation of the entire game – from beginning to middle to end.
Draw a bunch of panels on a piece of paper and start with a rough approximation of what the title screen or main menu will look like. In the next panel, draw what happens next. An intro? Level one? Continue as if you are making a play-by-play of the game itself, from moment to moment. The more panels you need to create to fully visualize your game the more work you will be assigning to yourself. Therefore, aim to fit the entire thing on a single page. Less than a dozen panels is wise – but the sky’s the limit.
I’ll show you my work-in-progress shots of a puzzle/strategy/tactics game I programmed recently called Pathos. To begin, here’s the rough sketch that I used to plan the game mechanic quickly:
As you can see, I’m a big fan of puns. I played with all sorts of game title variants that played off the a-star pathfinding algorithm, and I threw in a lot of Dungeons and Dragons RPG-style imagery, since that is what inspires me. I love fantasy world maps and figured it would be the ideal level select screen.
The reason that making a quick storyboard is important is that it will give you a more concrete description of what actually happens in the game. Moreso, it lays things out visually. How many buttons can you fit on one screen? How big is the avatar? What direction is the movement? Where is the score or health bar? These thumbnails are a wonderful way to see the game from a designer’s perspective. They will also help you during coding in numerous ways. For example, you’ll now know roughly how many icons or button images you need to draw, what the levels art will require, and even what the game will look like – from a basic layout perspective.
If your comic doesn’t look like a fun game now, then you’ll have saved yourself weeks or months of work by knowing already that some changes will need to be made. If the comic seems to go on forever, then you’ll see the obvious warning signs that the workload is too large and you need to reduce the quantity of scenes or levels or gameplay elements.
Just like an elevator pitch, this one page stick figure comic-style storyboard is an ideal BS filter. Show it to friends. Do they want to play this game? Do they think it would be worth your time to turn into a reality?
5. Make a No-Art Early Playable
The next major handy tip for this challenge is to make a playable game in the first day. No title screen, only one level, and just the primary gameplay mechanic.
It won’t be great, it won’t be finished, and it certainly won’t look that great or be all that fun. That said, this step is your best weapon. Challenge yourself to create a codebase that compiles and runs in the first few hours. Make it so that you can accept inputs, move around, animate something, and trigger some sounds. This prototype, lousy a game as it may be, is going to be your best friend.
The sooner you can have a working early playable prototype, the more likely you are to succeed. It will be your first “save point” – a resting plateau on the way to the top of the mountain that you can fall back on. It represents a vision of the working game. From here on you will be able to polish your game for as long as you like with the knowledge that you have something in hand that “works”.
Here’s what the first prototype looked like. It was a simple example of pathfinding in action, with NO ART – just colored rectangles.
Getting to this stage took a lot of programming time. I estimate that half the lifespan of the project was spent with the game looking like the image above. The no-art approach is ideal for programming: it saves time, helps you figure out the bugs, and forces you to focus on the “feel”.
No-art prototypes also have one other major advantage: in previous games, I would make beautiful mockups in Photoshop and gather hundreds of lovely looking sprites in preparation for the game. After development was complete, the vast majority of the art had to be replaced, resized, or thrown out. I’ve wasted thousands of hours making game-ready artwork before coding; these days I know that the tech specs and evolving gameplay mechanics will mean that much of what you make at the start won’t make it into the finished game.
6. Start Making the MVP Look Pretty
Once the game mechanic you’re working with is starting to function, you can start to add polish to your minimum viable product. At this stage, you still shouldn’t have a main menu or title screen, but the movement and game rules should be in place to cover the primary mechanic.
You are now ready to commit to a particular pixel size for your sprites, to decide upon layouts and color schemes and how many tiles you want on-screen, and to begin dropping game-quality art into your game world. This is also the time to experiment with performance and deal with all the tech constraints such as maintaining a good framerate and staying below your desired bandwidth or texture size.
Back to my example project, here’s the first working prototype, using only a couple placeholder sprites. The distance from one location to another is now being measured, and we’re ready for some actual levels:
7. Achievement Unlocked!
Good news: this is your next “save point”! You have a game that “works” in that it functions. You can click the screen and something happens. There’s no personality and only one level, but at the very least it is something that you could send to a friend and ask them to play. You have something that compiles.
What we’re aiming for here is functionality: something, anything, that you could stop working on and yet have something to show (and play!). It may be horribly un-fun or ugly as sin, but that’s not in the slightest bit important. At the very least, you’ll have a code project that compiles without errors and produces a deliverable.
Only once you achieve this “early playable” are you certain to hit the finish line, because from now on you could conceivably ship it.
8. Work on Only One Feature at a Time
With the central gameplay mechanic in hand, the world opens up to you. The possibilities are endless and the fun part begins. Maybe you’ll choose to add some levels, write some dialog, or develop some characters in inhabit your game world. Maybe you think a fancy particle system, cool music, or a high score list is essential to your vision of what the game should be. Great! Dive in!
Just remember one thing: don’t work on a little of this or that all at once. Focus on one task and finish it to the minimal basic complete state before moving on.
You may get bored of working on something and need a break. That’s fine – but attempt to be disciplined enough to keep working on the minimal system until it exists in a state that you could walk away from if need be.
For example, before implementing combat or health or particle effects, concentrate on the character movement and collision detection to the point that you can confidently say that the character moves, bumps into walls, and responds to keyboard, mouse or joystick controls.
Only then should you move on to weapons, or advanced movement like jumping, or detecting whether or not the player is touching lava specifically and needs to receive damage.
By working as linearly as you can (within reason), you will find that you are juggling fewer things at once. Your mind will be free to concentrate on a single task at a time rather than being overwhelmed by fifty different bugs in fifty different classes. This is essential to keep your motivation, concentration, and enthusiasm. Nothing makes you want to quit more than having so many problems to solve that you get discouraged.
Just like with a leaky dam, a single hole is easy to plug. If, instead, fifty different holes all appear at once – if you jump from one challenge to another without finishing the one you were working on previously – you’ll soon find yourself sitting in a huge mess of buggy code that is so complex and has so many problems scattered about that you’ll get that horrible feeling that comes with the realization that you are going to have to gut everything to fix them all.
9. Keep Hitting Save Points
In the life of a gamedev, you create a metaphorical save point any time you complete an MVP or playable prototype or released version of a game.
Remember to save this playable version of the game somewhere other than your working folder. Use version control. Zip up the game and toss it onto your backup drive. Email it to a playtester. Whatever you do, ensure that if you destroy everything from this point on, you could step back one version and ship it.
Always aim to create many iteratively improved and incrementally enhanced working, functional, executables. If you’ve gone more than a day without having a solid backup version of your game that could, if needed, be made public, then you should be getting nervous.
Naturally there will at times be long stretches where you’re hunting down bugs for hours on end. When you get to a point where the game seems vaguely functional and isn’t totally broken, save a backup. There – you’ve created another save point.
For this reason, the linear, iterative approach outlined above also holds true for your art content or game levels. Work on polishing one good level at a time. This way, if you run out of time, money, patience or enthusiasm before you finish all 99 levels you’d planning in your design document, the three or four that you did finish are good enough that you could still be proud of them.
To put it more simply, strive to at all times have a version of the game available that you could walk away from and put live. This is a safety net. After all, life might throw an unexpected crisis at you tomorrow. Sickness, family stuff, an oncoming bus – whatever the cause, you’ll always sleep better with a save point at the ready.
Remember, you can always come back to it and create a vastly improved and expanded version 2.0.
Iterative, linear, step-by-step, one-thing-at-a-time development is the secret to 12-in-12 success.
10. Reach the Finish Line!
One you’ve hit a few save points, your game is going to be in great shape. At one point, you’re going to decide that it is time to call it done. It is important to realize that you’ll never add half the features from your original brainstorm document. It is likely that many more will have moved from your version 1.0 to your version 2.0 wishlist.
Let’s return to my example project game. At this point, I’d been working on and off for a weekend and was ready to ship it and walk away. I’d changed the name, added some nice artwork, coded a parser for the data format that my level editor used, and found some sounds and music. It was a game. It was playable. I was proud of it. I called it “Pathos” and this is what it looked like. Feel free to click the image below to read more and play the game.
Remember: Accept Your Limitations
All gamedevs are enthusiastic, creative people. Sadly, it is this boundless enthusiasm and creativity that can get us in trouble. As optimists, we have in our imaginations a grand vision of what could be: that ultimate game that you just know would sell like hotcakes.
Each individual part of this grand dream project sounds like something that you could easily do – and this is probably true! However, if you add up each task, your ample ability is simply not what will limit you; it is your time that is in short supply.
Remember that most games you play on console, for example, have had a hundred people working on them, full time, for several years. If you are a solo indie attempting to compete with these kinds of teams all you have to do is a little math to realize that the human-hours of labor add up to more than one indie developer’s lifetime.
You simply have to accept the fact that you need to aim lower in order to finish unless you want to spend years on a single game. Considering that the average good indie game nets a few thousand dollars of profit, you cannot afford to spend hundreds or thousands of hours on your game unless you’re betting the farm on a life’s work or epic masterpiece. You need to design games that would take 20 to 50 hours of work.
By all means, dream big – but build iteratively. Build a minimum viable product, and if playtesters love it, add a bit more and call that version 2.0. Continue working this was for as long as you like!
Remember: Accept Imperfection
Perfection is, by definition, unattainable. You’re going to have to swallow your pride and accept imperfection. To neglect this is to chain yourself to the project for an eternity. Remember, you can always make a sequel. Releasing your game even though you know you could improve it forever is a good thing. Not only will it lift a huge weight off your shoulders and give you something to be very proud of, but once it gets into your player’s hands they may come up with new features you’d never considered.
Remember: Release Early, Release Often
When you run out of time, energy, money or motivation, launch what you have. If you’ve adhered to the save point system development methodology, you should have something playable at any stage of the project, even if there are all sorts of features left over in your wishlist or to-do list. That’s okay!
The “release early, release often” mantra is repeated over and over again by successful gamedevs for a good reason. You need player feedback. You need real world tests. Coding in a black box, hiding away in a bunker until the moment of final release, is a mistake. For one, you’re seeing your own game though your limited perspective. You’ve probably noticed times when you proofread your own emails but the world’s most obvious typos get through. This is because after a while of looking at the same thing your mind starts to grow numb to the critical eye. A fresh set of eyes sees things in a different light.
You might find that a certain mechanic, while seemingly brilliant on paper, is boring or frustrating once implemented.
Additionally, games that release early and continue to be developed are the ones that gain the greatest exposure. You generate more “newsworthy” information. You build buzz. You attract followers. You get people testing your game and gain valuable knowledge that will influence your designs.
Players might offer criticism or kudos that surprise you. Features you thought were important might be met with disinterest, while those you thought were unimportant might turn out to be everybody’s favourite. It is important to see how the public reacts to your game and react accordingly. This saves you time and heartache. It gives you direction for future releases. Most importantly, it will give you new fans, followers and a well-deserved pat on the back.
Plus, the knowledge that someone out there played and enjoyed your game is golden.
Now Stop Reading and Start Coding!
Now that you’ve been given that extra little bit of motivation and a glimpse into my personal gamedev methodology, I encourage you to get off the internet and just dive in. Planning or researching for too long can be an energy and time drain. Sometimes all you really need to do is make a new folder, create a blank project, and start coding. Fire up your gamedev engines and hit the afterburners.
If you follow this basic philosophy of game development I am confident that you will reap many rewards. The most basic will be lower stress. More enjoyment of the process, more tangible, playable builds, and more chances to get player feedback are also the benefit of this save point system. Finally, by chopping projects into small discrete sections, you are sure to be able to post a new game each and every month this year.
If you’re up for this kind of challenge, I warmly invite you to join OneGameAMonth, a gamedev challenge that has been accepted by over three thousand indie gamedevs just like you.
OneGameAMonth is gamedev with gamification added: you earn experience points, levelups and achievement awards for making games. You get to connect with a very engaged and active community of peers that is supportive, helpful and welcoming. Hundreds of games of every genre are being posted there right now. Join us!
Good luck with your future gamedev projects. You can do it.