Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases
October 31, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Why your Games are Unfinished, and What To Do About It
by Arian Allenson Valdez on 11/13/13 03:05:00 am   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


This post originally available on my dev blog.

So, you've got a new game idea, and it's going to change what everyone knows about the genre! Great!

After making a Game Design Document, you proceed to make some art, or maybe a prototype. You even got that fancy gimp program, or started using a new 'multi-platform' library.

Time went on and you hit a wall. Maybe it's that annoying bug in the second level. Your plan's aren't panning that well. It's just too much work.

You start making excuses. The game idea wasn't that great. It might actually be a bit boring. The art looks crappy.

You abandon the project. There are better ideas you say.

If the above sounds like you, then the bad news is with the way things are going, you might not release any games at all and just lock them inside your head!

The good news is, you're not alone. Almost every game developer lose interest in projects they are working on.

Coming from my personal experience, and interviewing a few other successful game developers, I've compiled a list of things to do when you find yourself killing off your own games.

1. Stop Editing

When writing, authors typically have one rule when making their first draft, and that is to kill the 'infernal internal editor'. "Don't edit, just write!"

This actually carries over to a lot of other creative industries, including game development. When developing a game, always make it so it just barely passes, and move on. The more you work on other parts of the project, the more motivated you will be. Don't try to perfect your game on the first run, remember, you can always edit it later on.

2. Make A Deadline

Deadline Image

This goes hand in hand with Number one. Enforce a 
time constraint, do your best to stick to it, and you'll find  yourself working on the essential game aspects.

There are lots of events with this in mind, such as OGAM (One Game A Month), and Ludum Dare.

3. Go For Small Games - if you're just starting

When you're just starting, start small. Making a fun solid game/minigame is a HUGE leap for a game developer, and having at least one released game already puts you ahead many of your contemporaries.
 "But that super awesome MMORPG with that unique mechanic is going to be huge" you say. That sort of enthusiasm will go a long way, but if you haven't even been able to create one small game, do you really have what it takes to commit yourself to such a big project?
If you're game idea simply and absolutely cannot wait, then try creating what's called a 'Vertical Slice'. Instead of creating your entire game, why not try creating one scene, one battle, or one encounter? This nets a plus on all components, because you can instantly:
  • Test out your idea
  • See if it's actually fun
  • And actually have something to show for your effort

4. Make it a Habit

Whether you're someone who makes games as a hobby, or someone who really wants to get into the industry, then make it a habit. Do one part of your game, everyday. It doesn't matter how much you can do in a day, the important part is that you work on the game.
You can even get yourself a to do list. Ticking something as done gets a nice feeling to your stomach!

Don't worry about the technology Image5. Don't worry about the technology

Your salivating over that new libgdx library that can compile to every platform known to mankind. You want to use Haxe because it's fast, multiplatform, and l33t. Microsoft killed XNA, and you avoid it like a plague.
The thing is, Don't Care! Remember, you're making a game, and it doesn't matter what language you use.
If you're game is boring, no one will play it, even if you used the newest, shiniest language to have ever existed.
The next tip is also an inherent flaw of game programmers, but can be applied to game developing in general.

6. Keep It Simple Stupid!

If you're a programmer, just code, don't edit (slightly bringing us back to tip #1). 
Design Patterns? Throw 'em away. Component Based Systems? So last year. Event Listener's inefficient? Leave them be.
Keep it Simple Stupid (KiSS) is an actual programming methodology. It's what it says on the tin, just keep your code simple. Don't get fancy with design patterns, component based systems, or making your loop run in the most efficient way possible. Pre-Optimization is the root of all evil.
Take pride in doing what you did, even if it was bad code. You might have a game with bad code, but at least you're not the other guy who has no game but good code.

7. Public Beta Tests

When loosing motivation, try being public! Share what you have so far, be it a doodle, a screenshot, or maybe even a demo. Get a friend to play your game, and with the internet, you can't have excuses for not finding anyone.
The feedback you'll get for your game is priceless, outlining what's fun and what's not, and it may even be the push you need to make it big.

8. Flow

If there was ever a point in your life where you've done something that you didn't even realize time passing, then you've undergone flow (which is what hypnosis puts you in). When you're in this state, you're so focused on what you're doing that you won't even notice a plane crashing next door (okay, maybe that was an over statement).
The point is, we can be totally immersed in one activity, and this is what you want to happen when developing your game. Close out your browser, and focus, have fun, and don't think of any thing else. Throw out coding practices, optimizations, and don't perfect stuff. Just do it.

9. It's Dead Jim

Maybe the game really didn't pan out as you've hoped to be. The gameplay was really flawed and it's not fun.
Sometimes, we need to quit when it's simply not working. (Seth Godin tackles it in his book, The Dip: A Little Book That Teaches You When to Quit (and When to Stick))
Remember, there is nothing wrong with making a game and just leaving it at that. You've gained experience, and that's always a plus. But don't just leave your game in the back of your hard drive, going back to tip #7, be Public! Share it on forums, saying it was a game you did in your free time that was left unfinished.
What do you know, maybe someone even gives you valuable feedback that turns out to be all that you needed...

Related Jobs

InnoGames GmbH
InnoGames GmbH — Hamburg, Germany

Mobile Developer C++ (m/f)
Activision Publishing
Activision Publishing — Santa Monica, California, United States

Tools Programmer-Central Team
Amazon — Seattle, Washington, United States

Sr. Software Development Engineer - Game Publishing
Intel — Folsom, California, United States

Senior Graphics Software Engineer


Luis Guimaraes
profile image
"If you're game is boring, no one will play it, even if you used the newest, shiniest language to have ever existed."

I have a leap-of-logic saying about it: "Good code is code that runs. If your game is not played, your code doesn't run, therefore your code is bad."

TC Weidner
profile image
I tend to think of code and design as two different entities. Code is just the lines of logic that bring the design and game to life. If it executes that well, if it runs the game without bugs, if it doesnt crash, if it does what it was meant to do well, then it good code.

Now its the game design itself that is responsible for the fun.

There are lots of bad games with good coding, and there are lots of good games hampered by bad coding. What we all aspire to is good games with good coding

Mihai Cozma
profile image
Very very good points. I'm glad I discovered all those things myself, although sometimes (very rare) I still get motivation drops :)

Rakib Solewalker
profile image
Wow, this really reflects me and the way I was approaching my current project. I have never coded a full game even a small one, yet I was going for a big project with 8-12 months of estimated development time. After a month of brainstorming and prototyping, I realize the game is not fun or I am losing interest in the project. Yet I decided to keep working.

Now I realize, I should pause the project and create a few really small games so that I get a feel of achievement, and be confident that I can finish something. I hope I am heading the right pah, I don't want to spend 8 months just to realize I can't finish or the game is boring.

Thanks for the points, it was just at the right moment for me :)

Kujel s
profile image
I ran into this on my first serious project (an RTS btw) and I had to scrap my project and focus on some smaller projects first. Now I have a larger code base and more experience coding a full game and pretty much everything is going smoother.

Jesse Mikolayczyk
profile image
My first 'large' game project was a collection of mini games so it worked out well that I could complete and test small sections of the game and really feel like I got a lot done, even if it was such a small section of the whole game. I do have a comment about the coding section though. Although I agree its good to start with the idea of 'just get it done', you can't leave the code unoptimized. Unoptimized code will just cause further headaches in the future. An example I have is a path finding AI algorithm I had that worked but was around 500 lines of code. I optomized it down to about 200. Later I found a bug (already in the code, not due to optimizing) but it would have been much harder to find and fix in the unoptimized code.

Dominik Gotojuch
profile image
I do agree that programmers often tend to overthink it when it comes to coding their game (story of my life), but I strongly disagree with embracing bad coding practices. Why? That annoying bug in level two that you mention might not even exist if you program your game with some common sense and good coding practices. If you did the opposite, good luck and have fun traversing spaghetti code.

Arian Allenson Valdez
profile image
Very good point @Dominik When I wrote this, and when I asked other game developers, I framed this first and for most for beginners. The general consensus is that most new programmers worry too much about their code that they cant do anything. I'm all for good code (as I'm a programmer myself) but what I aim to mean in this post is MAKE MISTAKES with your code and move on, hopefully for the better :)

Curtiss Murphy
profile image
Perfectly meshes with the the 12-week challenge over on the Unity forums! One-month was too short for me, whereas a 12-week deadline was short enough to keep the scope in control and long enough to build something meaningful. And I couldn't agree more with #3 Go For Small Games and #6 Keep It Simple, helping newbies to actually build something.

Finish it. Release It. Repeat. Announce to the world your intentions and then build it! Link to the 12-week challenge:

Carl Rutter
profile image
One thing I struggle with is burnout. I work full time as a game programmer already and make my own games in my spare time, so it is hard to do the one thing a day(#4) without burning out. I find nights off where I just play games useful for this, but would like to know how others cope with this?

On the motivation side I find going to game networking events help a lot with my motivation.

Arian Allenson Valdez
profile image
One game a day might not work, but if you're free on weekends, why not try creating one game on that day? The point of it is trying to see what you can come up with in the shortest amount of time (so you can cut out fat and work on the gameplay). Ludum Dare and One Game A Month are perfect examples of this - Ludum Dare happens once in a short time frame, so if you can set out to be free that day, you can join! OGAM is more relaxed, and you could do it on your spare time in the span of a month.

Andrey Coutinho
profile image
The best way to learn some of these lessons is to participate in a Game Jam. The joy of having a finished product in the end is motivational to the point where you unconsciously start trusting your "productive self" way more than your annoying "internal editor/critic".

I'm currently participating NaNoWriMo (for those who don't know, it's an annual writtng event that challenges writers all over the world to write a novel in 30 days), and I can relate to this article in so many aspects. "Don't Edit", "Have a Deadline", "Flow", "Go for Small", "Keep it Simple Stupid" and even "Don't worry about technology" (as in "don't bother trying to find the perfect word processing software and story creation tools, write even with pen and paper if you have to") have everything to do with my experience after these (as of right now) 15 days of frantic writing.

Writing and Game Development share more in common than most people would think.

ganesh kotian
profile image
Thank you so much for the post

Brian Tsukerman
profile image
Great advice here. I'm still working on applying #4, but #9 seems like one that will be tough to overcome. I'll have to look into that book by Seth Godin.