Jump to content
  • Advertisement


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


Game designing "Do and Don'ts"

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


Share this post

Link to post
Share on other sites

  • 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!