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:

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

@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