Good habits for game development

Try to work out what features you want to implement before anything else. Start with general ideas and work your way down to specific features and requirements. Once you have all of your features in a list, you can start to design your architecture to implement these features, making sure to find solutions to dependencies between them. (this can be the hardest part!)

Don't bother with any pseudo-code after you've finished the architecture, as you've got all the elements needed to begin coding the actual game. When you do this, make sure to always write code that doesn't depend on a feature you haven't implemented yet. This should help you keep your game testable and cut down the amount of coding you need to do in between new builds, which will keep you motivated.

• Write clean code the first time through. Don't write messy code and promise yourself that you'll "clean it up later".
• Recognize that clean code is better than fast code. It's easy for clean code to be made fast, but hard for fast code to be made clean.
• Counter tip: Don't be so obsessed with clean code that your project's progress stalls.
• Avoid macroes, except when they make your code easier, safer, and cleaner.
• Avoid globals, except when they make your code easier, safer, and cleaner.
• Avoid gotos, except when they make your code easier, safer, and cleaner.
• Avoid people that say macroes, globals, and gotos are perfectly fine.
• Avoid people that say macroes, globals, and gotos are never allowed.
• Listen to people that say macroes, globals, and gotos should be rarely* used, but who recognize exceptions.
• Use RAII, Single Responsibility Principle, and other similar concepts.
• Don't embed content into code - load content from file or something similar.
• Create and use a consistent coding style for your code.
• Use the C++11 smart pointers and std::make_shared(). (use Boost's versions if you can't use C++11)
• Avoid calling 'new' and 'delete' yourself, except in the rare situations** where they are required.
• Don't re-invent the wheel, unless it's a small wheel, isn't in the standard library, and won't take you long.
• Make your code as self-documenting as possible, so it can be easily understood without comments.
• Comment the code it anyway.
• Finish the projects and features you start.
• After you learn to finish the projects or you start, then learn to shoot the projects or features that need to die.
• Worry about writing poor code. Aim for high quality code, or at least good code.
• Don't worry about writing perfect code.
• Really. Don't worry about writing perfect code.

*90% of the time, a global shouldn't be a global, 95% of the time, a macro should be a template or a regular function, 99.9% of the time, a goto is being misused. 100% of these percentages are made up, but illustrate a point anyway. =)

**I find that it's rare, but not extremely rare. For performance reasons, probably 19 out of 20 of my dynamic allocations should be smart pointers - but I suppose that would vary from project to project. The vast majority allocations should be on the stack, and neither smart pointers nor raw allocations.

Lots of good points in the previous posts. I'll second the point of designing ahead of the code. Don't implement any features you don't really need, and know what you do need before you start implementing stuff :) A 100% detailed design upfront would be nice, but not usually possible. But you at least need an overall game design, and a decent amount of full detailed stuff plotted out before you get coding.

For example, you might have a few levels planned out for a side scroller, with various platform and enemy types in them. Once you code all that up, you have all those components to mix and match in new, not-pre-planned levels, and maybe think of ideas for some more things to add. But you need those first levels designed before you start coding, or you risk falling into the trap of "engine" coding, which often results in lots of those unnecessary features :)

Also, use a coding style appropriate to the complexity of the game. Full C++/OO/RAII/smart pointer style is great for most things, but maybe a little overboard for Pac Man. If your game is similar to something done on SNES or earlier, chances are it was written in assembly with little if any heap allocation (usually using statically allocated pools for things that are dynamic in nature, but have a maximum number that can be on screen at a given time), and probably wouldn't run into many difficulties coding it in C.

And when commenting code, don't go overboard. Usually it will do to give a quick plain-English overview of what a function is trying to accomplish, or a block of code in longer functions. Only comment line by line if you're doing something particularly confusing, such as highly optimized code.

Quality content creation is time consuming. Background graphics, animations, sound effects, music, level design. But don't involve other people in your project until you have the design worked out well enough that a) they'll have something moving around on screen soon, and b) you're relatively confident that the project is not going to fizzle out due to excessive complexity or simply not being as much fun to play as you thought it would.

Be aware that 50% of the production time is finishing the last 10% of the game. If it doesn't look "almost done", you've got a long way to go :) But sometimes the transition from looking like a bunch of separate components into being a cohesive whole game can happen pretty much overnight.

i want to add that during development keep in mind that at some point you will need some debug information displayed in the game. a really simple example: mouse coordinates (screen vs world), number of textures, number of vertices, state of an agent and so on, and so on. so when you think about the structure of the code, think about that too.

If you want to design your game (or more precisely your game engine) up front, before coding something wrong and useless, elaborate your requirements in detail: there are features you really need, features which are likely to be useful, with vastly different priorities, and features you don't need.

Apart from discovering important decisions and complications early in the process to adjust your game design towards feasible objectives, knowing what you want is necessary in the choice of libraries, data structures, algorithms, contrasting architectures.

• Don't reinvent the wheel. Use third party libraries and engines as much as possible. Learning how to work with these tools is just as valuable as skill - perhaps even more valuable - than learning how to write them yourself from scratch. Familiarity with certain engines and libraries are very marketable skills.
• Use source control. Break your project into clearly defined chunks of work which can be accomplished in a reasonable time frame and check it in to your main branch after each one is complete and working.
• Ensure that each chunk of work has some clearly defined purpose. The vast majority of these chunks should relate DIRECTLY to the end-user (the player) and thus contribute to the gameplay in some way. Anything that doesn't is either a waste of time, or a utility to make your (the developer's) life easier - in which case you will need to make sure the time it takes to complete vs. the time it saves you in the long run is definitely worth it. This will help you manage the time spent making tools, refactoring etc. and encourage you to focus on the actual game.

Regarding up-front design - be aware that often, things will change as development proceeds. You may find that ideas you thought sounded fun on paper turn out to be terrible, in which case they will need to be dropped or re-worked entirely. Features that you wanted may turn out to be too processor intensive to work together, and scaled back or dropped accordingly. Early prototyping will help discover some of these issues ahead of time, but ultimately you will need to be flexible. Heavy investment in up-front design can be just as much of a waste of time as doing none at all and rewriting things several times, since you may actually have to do that anyway.

I think an object oriented language is the way to go for organization and maintenance (not speed though but it's fast enough for 99% of the code).

- Encapsulate as much as you can. I end up re-factoring my code all the time. To think you'll get it right the first time every time, or that you won't change your mind is silly, and the more you have things encapsulated the easier it'll be to re-factor things around without breaking the things that rely on the code. It also allows for experimenting with new ideas without breaking existing code. Even if you think something is small, encapsulate it because chances are you'll come back and make it more complex eventually and doing this can really make your life easier later.

- Make self containing code as much as possible. The more your code relies on each other the harder it'll be to make changes without breaking a bunch of stuff. This again allows for easier changes that don't break as much code if any. I like using event programming for this so that my objects fire events and other objects can subscribe to these events if they want. This way my objects aren't tightly coupled together (ie the HUD object doesn't need to directly know about the Player object), and don't rely on polling systems which waste time.

- Always make sure your code compiles each day that you are done with it. Don't leave compile errors overnight. Logical errors are OK to leave, but be sure to note them.

- I'll contradict Servant's comment and say, never use goto, global's, or macro's. In my 15 years of programming I've never used goto outside of first learning it. It's simply not needed. Globals took longer for me to realize their danger but eventually I have seen the harm they cause and haven't used one myself (libraries you use might) for probably the last 8 years. Stick to a singleton if you need something like a global. Macro's start out making your code easier and then you start abusing them and they actually end up making your code harder to read & maintain.

- The biggest thing I think is to make your functions small! They should be visible on about 1 "screen". Any bigger than that and it's most likely doing too much and should be split. It will also be harder to maintain than a small specific function. This is important, as it's all to common to see new programmers putting so many things into giant functions. Don't do it! This is worth repeating. Practice doing this until it's second nature. This is a big one.

Source control. I cannot describe the peace of mind it brings.

Design the game first! Code is a thing but the game has certain things it needs to do. There are no "features you want to implement" but rather features the game needs to run (technically those would be the aforementioned requirements). Anything else should not be there... unless it brings you cleaner, safer code to manage without running out of sanity.

One thing that helps me get things done is having a deadline. Preferably a deadline that you cannot push back like for a contest. When you have a deadline it helps you keeps your project simple and cut out unnecessary features so the focus becomes finishing the game rather than trying to see how many awesome features can make it into the game. Even if you cannot find a contest or other hard deadline still try to set out a realistic timeline for yourself and follow it. If you find your initial estimates weren't accurate adjust them. But break up your project into smaller pieces and tackle one piece at a time.

[quote name='rpiller' timestamp='1357223603' post='5017110']
Stick to a singleton if you need something like a global.
[/quote]

Sorry, but if you've been using singleton's "instead of" globals then you have still been using globals during the past 8 years. A singleton isn't better than a global just because it's wrapped up in a fancy class, and using a singleton because "you need something like a global" is a terrible reason to use the pattern. You should use a singleton if you need a singleton; that is:

• If there must only ever be one instance created. Note that this is different from only wanting or needing one instance -- if you only want or only need one instance then don't bother with additional code to enforce it and instead only create one -- the singleton is appropriate when it would be an error for there to be more than one instance.
• If you need global access.

Unless you need both of those requirements the singleton is not the right pattern for your situation, and it's exceedingly rare to genuinely require that there must only be a single instance.

If you "need something like a global" then use a global, don't shoe-horn your code into an unnecessary pattern under the impression that your code is somehow better because you avoided a global -- you haven't avoided it at all -- a singleton by definition is global, and still has all of the potential problems associated with that, but now has the added baggage that you're also enforcing the (usually unnecessary) single-instance requirement as well. Writing more code to enforce a requirement you don't actually have -- that there be only one -- can never possibly be simpler than just using a global and not creating more, and it reduces the flexibility of your code.

A quick search for singletons will turn up plenty of additional discussions on the topic, but I'd like to suggest that singletons should be added to the list of things that should usually be avoided along with goto, globals, et al.

For C++, I'd recommend reading C++ Coding Standards by Sutter and Alexandrescu. The table of contents by itself is helpful, but the full book contains discussion like reasoning and exceptions to the general rules. The only problem is that it predates C++11.

I just came across this the other day. Scott Meyers' range of Effective C++ books are also a great read on best practices

@jbadams

I stand by the small section of my comment you decided to quote. IF one wants to go the global route, use a singleton because it offers more benefits than a pure global. You may not think those benefits are worth anything but I do. Benefits in refactoring at a later date to actually be a normal object, better organization & structure, encapsulation, etc. A singleton is clearly better than a global because it's wrapped up in a neat little class and you get the benefits that classes get. Because that allows for more flexibility and organization than a loose global variable. Yes, they have the same scope, but one adds more benefits than the other, does it not?

I don't get belittling the benefits of what a class offers and clearly " just because it's wrapped up in a fancy class" is belittling what a class offers in it's tone.

A singleton is clearly better than a global because it's wrapped up in a neat little class and you get the benefits that classes get. Because that allows for more flexibility and organization than a loose global variable. Yes, they have the same scope, but one adds more benefits than the other, does it not?

No, it doesn't. The one and only thing you get out of a singleton that you don't get out of any other global (class) is the enforced restriction that there may only be a single instance, and this is an additional limitation that simply isn't necessary in the majority of cases. If you have a global variable or function and you want to wrap it in a class to provide encapsulation, validate changes, or whatever then by all means put it in a class, but it simply doesn't need to be a singleton, and unless you actually need the highlander rule ("there shall only be one!") you're not gaining any additional benefits from choosing a singleton instead of a regular class.

You obviously understand that globals can potentially cause problems, so the suggestion that a singleton -- which is still global and therefore still susceptible to all the same problems -- is better doesn't make sense. The benefits you listed aren't the benefits of a singleton, they're the benefits of a well designed class which probably doesn't need to be restricted to a single instance in most cases. Singletons increase coupling and make your code less flexible by discouraging re-use. Wrap your variables or functions in a class if you want to -- but why make it a singleton if it isn't an error for there to be more than one?

A singleton IS a global, so you're breaking your own rule of "never use a global" every time you create one.

If you have a genuine need for a singleton then by all means use one. If you're happy to use them in your private code-bases and you aren't experiencing problems then by all means continue to use one. But if you're going to suggest to a less experienced programmer that a singleton is a suitable replacement for a global when it imposes a restriction that isn't usually relevant and leaves the data global an alternative point of view needs to be provided.



...and in the interest of staying on topic, I think the more general case of the point I've been trying to make is:

• Whenever possible, choose the most suitable tool (whether that be a language construct, a language itself, a piece of software, etc.) for the task you are trying to accomplish. Learn the tools that are available to you and their intended purposes so that you don't need to try to use a screwdriver to hammer in a nail.

//EDIT: I just wanted to specifically respond to the following in addition to the above:

I don't get belittling the benefits of what a class offers and clearly " just because it's wrapped up in a fancy class" is belittling what a class offers in it's tone.

I'm not belittling what a class offers at all, I'm belittling what a singleton offers. Singleton is a specific design pattern with additional constraints above-and-beyond those normally imposed by any other class, and to suggest it be applied as a blanket solution to a problem it doesn't actually solve -- that is, trying to avoid the potential pitfalls of globals by using a specific type that is still global -- just doesn't strike me as something that should be in a discussion of "good habits". Use a singleton if you think it's actually the appropriate thing, but if all you need are the benefits of a class then just use a regular class rather than a singleton.

The tone you're picking up on is directed specifically at the mis-application of a singleton, not at the use of classes in general, and certainly not at you personally -- we're all trying to provide helpful information, and I simply felt that one of your points amongst an otherwise good post needed correction. A singleton just isn't appropriate as a blanket solution to situations where you feel the need to use a global -- it doesn't change the scope (which is the original problem) and it introduces additional constraints that may or (more likely) may not be necessary.

Thanks for all the answers, I will put in practice some of your tips in my news proyects!

And in general, what I should consider for become a better game developer and make better games?

Finish what you start ... when you start a game, finish it.

This leads to a natural corollary, Don't start things that are too big for you to finish.

I have to agree with the comments suggesting source control, even for relatively small hobby projects. I've found it really helps me stay organized--the free online repository site I'm using has a built-in issue tracker, which has been much more useful than my previous system of scribbling down random problems and planned features as I thought about them in a notebook. It encourages you to set specific, incremental goals--and them meet them before moving on to something else.

[quote name='TheSasquatch' timestamp='1358625548' post='5023275']
the free online repository site I'm using has a built-in issue tracker
[/quote]

Which free online repository site are you using?

the free online repository site I'm using has a built-in issue tracker

Which free online repository site are you using?

Didn't want to sound like I was advertising, nor stir up a Git vs. Hg firestorm, so I didn't name names, but I suppose there's no harm in saying Bitbucket. Github probably has similar features, but the deciding factor for me was Bitbucket's unlimited free account for those with a .edu email address. As a broke grad student, I couldn't turn that down.