Archived

This topic is now archived and is closed to further replies.

Game designing "Do and Don'ts"

This topic is 4966 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

I would like every reply to this to offer one piece of advice for someone designing a game (be it programming, artwork, sounds, concepts, design document, community, whatever), for example: -Do learn this concept and this before beginning -Do use linked lists when doing such-and-such or -Don''t start an MMORPG if you''re just beginning or before learning such-and-such -Don''t use this colour as a transparent colour key for your sprites Hope it isn''t too vague, but hopefully everyone who reads this will be able to pick up all the ideas laid down beforehand and add one themselves. Thanks!

Share this post


Link to post
Share on other sites
A few obvious ones:
- Do think before coding. Don't hack. Classic CS is good for you.
- Do get out every once in a while. Fresh air makes you smarter.
- Do keep source code documentation up to date. It's boring as hell, but worth it.
- Do widen your horizons. Specialize, sure, but also dabble with something else entirely.

- Don't micro-optimize unless a profiler specifically tells you to.
- Don't be an unprofessional primadonna like Mel, a Real Programmer. Unmaintainable code is not cool.
- Don't reinvent the wheel. STL probably has what you need.

[edited by - LNK2001 on April 4, 2004 11:26:55 AM]

Share this post


Link to post
Share on other sites
1. Coding is the second to last stage, the last one being the testing. Write your application design first.
2. Comment your code as if you are explaining it to someone else.
3. Starting up with an MMORPG and the like is not a good idea, start by doing a tetris clone and go from there.
4. Working in a team without a good team leader who knows what he is doing won't last long.
5. avoid memory leaks as much as possible.

[edited by - _Idan_ on April 4, 2004 2:34:25 PM]

Share this post


Link to post
Share on other sites
Don''t ever struggle to understand your own code 3 times. The first time might be a coincidence, but if you can''t look at a section of your code and know what it''s doing twice, you need to rewrite it or comment it.

Don''t be clever. No one''s impressed. Readability and maintainability are the top goals of software design. Your ''clever'' code won''t be faster than my readable code in 99% of the cases after my compiler is done optimising.

Do error check everything. You think you''re being lazy by not checking for null file pointers and the such, but things will fail eventually and a robust program is the difference between a quick fix and hours trying to hunt down a bug. Every system call has the potential to fail. Make sure you''re checking for that (well, i don''t usually check output because that''s obvious anyways).

Do, in a related note, double and triple check pointers and arrays. You want to be absolutely certain you don''t have any overflows. Buffer overflows are bad for security, and can be the most difficult bugs to fix. For the C people out there, never use strcpy or sprintf. use strncpy or memcpy and snprintf. And so on. i like C and all, but there are a lot of pitfalls.

Share this post


Link to post
Share on other sites
-Writing code off the top of your head may work eventually, but it sure as hell wont look pretty.

-Sometimes it''s definately worth it just to take the easy way out and code your project in Java instead of the good old see-pee-pee

Share this post


Link to post
Share on other sites
- DO make sure you TOTALLY understand pointers. Beginners often do not completely understand them, and this will really hold you back. If you can''t dynamically declare, initialize, maintain and pass to functions a pointer to an array of pointers to arrays, you need to study pointers a bit more. Don''t necessarily code like this, but at least be able to do it.
- DO spend a couple of hours and learn how to use the debugger. Beginners think it''s some kind of complicated tool that''s difficult to learn, but it''s not. Those couple of hours spent learning how to use the debugger will save you hundreds of hours later. There are SO MANY posts made in these forums that would have been easily solved if the person had just stepped through their code.
- DO comment your code. Even you will forget how your nifty algorithm works 6 months from now.
- DO bookmark http://msdn.microsoft.com if you do any Windows programming.
- DO read "Code Complete" by Steve McConnell and "Writing Solid Code" by Steve Maguire. You''re probably not going to need everything in these books, but the stuff on defensive programming should be mandatory reading for all programmers. Also, if you''re past the "absolute beginner" stage, any debugging articles/books by John Robbins are GOLD - I can''t recommend this guy enough.


- DO NOT throw away your pen and paper. Before coding too much, draw out your basic objects, how they should work, what they need to contain, etc.
- DO NOT worry too much about optimization until you run your code through a profiler (another tool worth learning) - but don''t shut off your brain when you code either.
- DO NOT post asking for help until you have at least tried to figure out the problem yourself. You don''t learn as much if someone solves your problem for you. And remember GOOGLE IS YOUR FRIEND.
- DO NOT copy/paste someone else''s code as your own. Give credit where credit as due - at least add a comment to your code thanking the original author and describe where you got the code from.

Share this post


Link to post
Share on other sites
Not specifically related to games but:

- Refactoring is your friend. Don''t worry about making a mess of something.

If you have a routine / set of routines which isn''t working very well, has bugs and/or is not scalable or adaptable enough, don''t be afraid to scrap it and start again. The result usually gets much better with each iteration.

As you will be using source code version management, and test-driven development, you will be able to easily tell if your new implementation works (as well as the old one anyway), and you can always revert if you find you''re at a dead end.

Every time I write a similar mechanism, it gets better. It''s a successive approximation to perfection. You will probably never get there, but nearer is better.

I know it''s been mentioned before but:

- Don''t optimise too early

Mark

Share this post


Link to post
Share on other sites
Have probably been said already...

1. Do clearly comment all your code. Do it. Trust me, in a few months you’re going to need to know what your code does.
2. Do not put the majority of your code in one large file. The thing will just keep growing and growing until it is unmanageable. This is pretty damn obvious, but I missed this one on my first project

Share this post


Link to post
Share on other sites
Read my signature.

---------------------------------------
"Each refinement in the definition of the task becomes a refinement in the algorithm." Frederick. P. Brooks, Jr.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The topic made me think this was about game DESIGNING, not coding. But maybe it''s supposed to be about designing code for games?

Share this post


Link to post
Share on other sites
- Do constantly evaluate you design: having a function that does a job is good, having two functions that do that job is okay, having three functions that all do that job is cause to start re-thinking...

--
Never
My game

Share this post


Link to post
Share on other sites
DO re-use portions of your code where possbile. For things that are the same or similar every time (eg. DirectX initialization) it will save you a lot of time and effort. However DO write these portions of code for yourself in the first place, and ensure you understand them. Since you will be re-using the code, try to optimize it within reason once your sure of how it works.

DO give enough details of your problem when asking questions. People will be able to help you much easier if you give them as much of the relevent information as possible, such as what language you use, which IDE/compiler, links to tutorials if the problem is with code from a tutorial, etc.

DO try to help other people with thier programming problems if your fairly sure you know the answer - explaining to someone else is a good way of learning things yourself.

DO make an effort to use correct spelling and grammar in forum posts, as well as formatting techniques such as punctuation and paragraphs. This will make your posts easier to read and your questions more clear, so you are more likely to get the help you need, or conversely save you from having to explain the help you gave someone else again. You do NOT have to hit return at the end of each line when posting on the gamedev.net forums, the text will wrap.

DO use anchor tags to make 'clicky' links for any urls in your posts if you have time, as this saves people responding to your posts a lot of time and effort when following links. People may sometimes not bother to visit a url if it isnt provided as a 'clicky link.'

DONT give up if a specific technique or problem is difficult, as these are often the most rewarding to solve, and are most likely required for you to progress as a programmer. Try to solve the problem yourself, look at any avaliable documentation, search google, gamedev.net, or similar sites for tutorials, and lastly, post on the forums for help. You should try to solve problems for yourself before posting when possible, as you will often learn better that way, as well as saving others the effort of helping you.

DONT needlessly insult others in forum posts - even if thier question seems fairly obvious to you, just remember that there are most likely people who find the solutions to YOUR problems obvious as well.

[edited by - kazgoroth on April 5, 2004 11:14:04 AM]

Share this post


Link to post
Share on other sites
Some safety...
Dont keep trying to solve a problem until you are exhausted, leave it for some time.

Your brain needs rest and relaxment....

Dont use Highres in 17 inch display, above 1024x768.
Dont keep staring and focusing on a same point, keep eye balls moving.
Prefer printer to read docs.
dont look at display when not needed.
(Some of these are not neccessary in case of LCD disp)

Dont sit on a chair where your back angle is less than 90.
Dont force your wrist to lift your hands.
Keep your wrist on a ground where your fingers have easy access to keyboard.
In simple words your body should be in 100% relax pose.

Dont work in a darkroom, keep constast of light of room balanced with your display.
Prefer a theme/color_scheme with dark over light contrast instead of light over dark.
Warmup your body after every hour by jumping/dancing/jogging...ie refresh every muscle of body


[edited by - DirectxXx on April 5, 2004 11:58:21 AM]

Share this post


Link to post
Share on other sites
I don''t understand the science behind the dark room "screen glare". I heard it (for the TV screen though) was just a marketing myth to sell lamps or something. Apart from eye strain, does working in a dark room really make it any worse?

Can anyone explain this so that I can stop doing it ( I prefer working without the light on usually ).

Share this post


Link to post
Share on other sites
I dont want to drift the original topic of this thread so "no one should continue this reply".

I was not talking about glare or reflection of bright objects over screen. I was talking about a darkroom and bright display.

Im not sure but what i know is that siting in front of a CRT monitor does not causes harm to eyes, but some tirness related to eyes cause these problems.

Personally my experience is that I lose my focus much faster in dark then in a lit room when working on my PC.

[edited by - DirectxXx on April 5, 2004 5:34:12 PM]

Share this post


Link to post
Share on other sites
Do be critical of what you read, particularly on the net. It takes much less knowledge to sound credible than it takes to actually be correct.

Do read my signature.

Do learn the standard CS algorithms and data structures.
Do learn when to use them and, just as importantly, when not to use them.
Do use libraries, both standard and third party. You do not have to reimplement the functionality they provide, nor debug it, nor maintain it, nor improve it. Become familiar with their usage and, in time, you''ll come to understand their implementation.

Do learn multiple programming languages, preferably unrelated (i.e. not "C and C++"). Idem with multiple APIs, multiple environments, etc. Not only seeing the same problems approached from different points of view will give you a better understanding of the underlying issues, it does give you more options to deal with a given problem by letting you choose the appropriate tool. One size doesn''t fit all.

Do experiment. Be curious. A program that doesn''t work can potentially teach you more than a program that does.
Do learn from your mistakes instead of being afraid of making them in the first place.

Do not let expectations of perfection stand in the way of your program. There is no such thing as a perfect program or a perfect design (unless you are Don Knuth).
Do not try to write a fully generic flexible game engine when you really are trying to write a game, for it makes it likely you will never actually finish the game. The game comes first. If you can reuse some engine components, so much the better. If not, you''ll have learned what you need to change.


“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
— Brian W. Kernighan

Share this post


Link to post
Share on other sites
quote:
Original post by fallenang3l
quote:
Original post by Unsuspected
what''s a profiler?


And before anything else mentioned here, learn to use google.


DON''T be a complete asshole. Everything is already somewhere on the web so telling people to use google could apply to any question.

Share this post


Link to post
Share on other sites