Game designing "Do and Don'ts"
Author
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!
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]
- 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]
Do think about (and write it down) your application structure before starting to code. Like the overview in enginuity pt2.
[edited by - Structural on April 4, 2004 2:01:10 PM]
[edited by - Structural on April 4, 2004 2:01:10 PM]
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]
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]
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.
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.
-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
-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
- 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.
- 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.
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
- 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
quote:Original post by LNK2001
- Don''t be an unprofessional primadonna like Mel, a Real Programmer. Unmaintainable code is not cool.
woh~
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
