Jump to content
  • Advertisement
Sign in to follow this  
buumchakalaka

Good habits for game development

This topic is 2115 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Edited by rpiller

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!