   Good habits for game development
  Hello!Im starting to make big proyects (of course, big in relation to my previous proyects) and I'm beginning to consider how to make game more efficiently.One thing I realized about my little experience is that is very important to design the whole game and the structure of the code before start writing, although I have not put this into practice.So what I should consider about this point?And in general, what I should consider for become a better game developer and make better games?Thanks you for the help!!   
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.;My personal and non-professional opinion: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.