Jump to content

  • Log In with Google      Sign In   
  • Create Account

Like
27Likes
Dislike

Why your Games are Unfinished, and What To Do About It

By Arian Allenson M. Valdez | Published Nov 15 2013 05:32 PM in Business and Law
Peer Reviewed by (Glass_Knife, Dave Hunt, jbadams)

games development marketing business motivation beginner

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 plans aren't panning out 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 loses 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


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.

i-download+

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 of 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 your 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!

5. Don't worry about the technology


i-download+

You're 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 your 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 losing 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 anything 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...



About the Author(s)


Indie Game Developer, Life Long Learner, and LifeHacker, primarily interested on innovative game experiences, but also works on F2P MMO stuff and casual games.

License


The GNU Lesser General Public License (LGPLv3)




Comments

1. Stop Editing

 

I don't think writing and programming works the same way. When programming, what we have done previously can greatly affect what we are doing now. I like to keep my code in as good of a state as possible all the time. I believe it saves time in the long run.

 

2. Deadlines

 

Do you have any tips on how to actually go about keeping the deadlines?

 

6. KISS

 

What is simple? How do I know if I'm keeping my code simple? Explain what simple is! 'Simple' is a word lots of programmers throw about but it means nothing most of the time, because almost everyone has their own idea of what 'simple' means. DO WATCH, EVERYONE: http://www.infoq.com/presentations/Simple-Made-Easy

 

8. Flow

 

"Throw out coding practices, optimizations, and don't perfect stuff. Just do it." As I said about item number 1, I don't think it's helpful to just code like there is no tomorrow.

 

Othewise I agree, especially about making your project public as early as possible.

I mostly like the article, but #6 might be the worst advice you could ever give someone writing a game they expect to maintain. While you can certainly go overboard, just going wild and writing the sloppiest code you can is not only not simple, it creates a maintenance monster you have to deal with if you ever plan to support that game.

 

You can say "Well these are just throw away games", but you should practice how you play, so to speak. You say it yourself in #4: Make it a habit. That includes not writing crap code because "meh who cares, we're throwing it away".

 

Design patterns don't exist to stroke someones ego about how smart they are, they exist to create code that isn't a monster to deal with later. People not treating games like real software is what has gotten us in to some of the bug ridden hellscapes we've seen in games before. No one cares how fun your game is if it's a buggy mess.

^ That. It seems to me that one of the most prominent reasons why people leave unfinished coding projects is "Gah, everything is a mess now!".

 

Then dealing with your bad architecture simply outweighs the desire to finish the project.

 

"GoodCode" ™ is there to make it easier to keep working on the codebase later instead of throwing it all out and start again.

 

Even if spaghetti code right now works, the hassle of modifying it to do something else later might be a big factor on dropping the project. You should only code "carelessly" only if you're committed to refactor your code when the time to do so arrives. 

I like this process. I decided to program what I called a customizable game script and I did "Code like there was no tomorrow." I didn't use fancy OOP or anything. I just hacked out the code. However, I did keep it simple. My variable names and function names were good, and I commented it well. I also organized it well so I could find stuff. 

 

So, it was easy to convert it to OOP later. 

 

It is sort of like sketching. Why spend days or months on something that isn't going to be successful even if all of your code is perfect?

 

Why go worrying about data management if your game is terrible to begin with? 

 

Remember when we were kids and we made games? We made them to be fun. Game can be basic, but if it is fun, we played it. 

 

We need to go back to what a game is first. A game isn't a PS3 or XBOX video game. A game was chess before it was COD. A game was hide-and-seek before it was chess. Etc. 

 

The code for a game doesn't make it fun, it only makes it work. 

Very good article on motivation :)

 

My only disagreement is that you should not write code "a la crazy". I'm not saying you should immediately start optimizing everything and/or adhering to the most perfect code standards and patterns. But clear and well organized code goes a long way to keep you motivated, especially when you start encountering bugs you absolutely need to correct before anyone can play your game properly.

 

Balance, i say :)

Hi Guys, I wrote the article 

 

I have received lots of feedback about the 'just code' stuff, and the reason I included it there is because when I asked a lot of game developers, most unanimously agreed that new developers worry too much about code instead of actually enriching their game (How do I use design patterns? What is the best engine to use? What are good coding practices?)

 

Here is a comment written by Andrey C. from Gamasutra:

 
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.

And I think he hits a lot of what I'm trying to say in the head. Get productive and stop your internal editor for a while. The un-maintainable code base is all right, it's just basically a prototype.

 

@TheChubu said that "Gah, everything is a mess now!" is a prominent reason for leaving unfinished coding projects. The point I'm trying to make is that new developers should hop over it, not around it! "Everything a mess?" You can't start over, continue hacking your game tongue.png

 

@tufflax said that good code should be kept, because "I believe it saves time in the long run." This is another bane of new developers. A small game should be faster to code if it is just coded. If not, then that might be a time to agree that there is something fundamentally wrong with the code. Also:

What is simple? How do I know if I'm keeping my code simple? Explain what simple is! 'Simple' is a word lots of programmers throw about but it means nothing most of the time, because almost everyone has their own idea of what 'simple' means.

 

As I said, KiSS is an actual design principle that has been carried over to software development. Explaining what it is, when there are a lot of articles and even books that cover the topic, would not be productive. The article is aimed to show the way, not pave the way. (it introduces KiSS, but the reader is expected to research KiSS).

 

Hope you guys found the article useful!

Is Pre-optimisation really that evil? Many game companies end up finishing their game, only to want to add extra content. If your game isn't optimized beforehand, you will have to sift through hundreds of thousands of lines of code, just to change it all. This is just my opinion, but I feel that Pre-optimization does reap its rewards in some cases.

@Solid_Spy This article is aimed at beginners, not game companies. Game Companies would be smart to make their codebase extensible and maintainable. 

 

However you mentioned pre-optimisation, and yes more often than not, it is really that evil.

Nice article! I'm pretty sure this article is great for indie game developers with an aim of 1 week to 1 month development. If I have to apply it to a very short dev life cycle, then this is what I really need, especially talking about deadlines with team of at most 2 programmers.

I'm currently in the process of writing a tetris game. On a small scale project like this, I'm trying to keep the KISS principle, nevertheless I often find that I need to refactor the code because otherwise it becomes unreadable...

 

I also noticed some design flaws that I'll leave in the code (e.g. I didn't consider the field where the blocks fall down as a gameobject, which I should have in hindsight). It's an experience I'll take with me into my next project, but I won't fix it in the current codebase as it is not a "showstopper".

 

One should always consider the tradeoffs and take the one that moves the project ahead and doesn't delay it needlessly... The time you take polishing your code, is time lost where you could be learning about some new concepts. E.g.: in my case, refactoring to add another gameobject for the field with falling blocks, would be less valuable to me then learning about the best practices of sprites, because my tetrisgame could use some code where it is easy to render a rectangle with a specific texture (because I'll certainly need it again in this project and I'll need it in my next project).

I've been an indie gamedev for a quarter of a century.

 

this is 100% spot on.

Re #6, I try to follow the phrase; "Start as you mean to go on".

 

When you're nearing release and you need to make some quick changes, cutting corners is probably not so bad as the impact is relatively low. But if you're cutting corners from day 1, it *will* come back to bite you in a big way at some stage.

 

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."- Donald Knuth

 

When Donald's statement is viewed with its original context intact it suggests you should only be optimising the parts of your code that are worth optimising, not that you should throw caution to the wind and write sloppy code from the start. His beef was with people who don't profile their code to find where the inefficiencies are before they start optimising. 

 

Selecting the right data structure or methodology for your game is *not* premature optimisation. It's common sense.

#4 is the most important point; I usually refer to it as "Just do it."

 

 

#9 is a bit wrong I think;  in general abandoning a game isn't a good idea under any circumstances.

Rework it instead.

 

sources: 10 years of indie game development

Thanks for writing the article, it's stashed in my bookmarks as my weekly reminder of things not to do! :)
 
For whatever its worth, I'm horribly guilty of #6 (KISS) on a routine basis and occasional waves of #1 (Stop Editing).
 
Personally, my greatest reason for abandoning ship is perhaps "burn out", as is often the case with most anything that I do in life -- "if it's worth doing, it's worth doing right" mindset. 
 
From an online article source that escapes me at the moment, I think the general rule of thumb given was a 1:1 ratio; every hour of work needs an hour of relaxation. (A bit overkill in need for relaxing for me, personally, but to each their own).
 
I strongly agree with the ratio given because of my own life experience: my development cycle lives and breaths on a 15 day on followed by 15 days off cycle, with no deviations from that rule. I've found in the past year of getting back into development that my overall motivation levels feel fresh & renewed each time I go back to working on the project.

Note: Please offer only positive, constructive comments - we are looking to promote a positive atmosphere where collaboration is valued above all else.




PARTNERS