Which potential design errors early on in the development cycle should one pay especially attention to? Can anybody explain from experience? My point being that writing a demo/an engine/a game from a hobbyist's point-of-view, it would be very helpful to have some pointers to the most common traps and pitfalls that come back to bite one later as the code grows. I am talking specifically about software architecture and design here. Something that is especially common in the area of *game programming*? Alex

Quote: to the most common traps and pitfalls that come back to bite one later as the code grows

Design is either suitable or unsuitable for problem at hand. If you have solved problems from same domain, and were able to evaluate the final result, then you will have gained useful experience. If you have not done that, any advice will be hit-or-miss. It may be suitable for your particular problem, or it may not be. Console programmer's advice will be much different from client PC developer or Phone developer or server-side advice.

Best design for this particular case is one that gets the job done, just that, exactly that and nothing more. Everything else is secondary.

Unless you already know how and why to design something, you will not have the knowledge nor experience to make justified choices.

But the first biggest mistake:
- Failure to specify exact requirements

Demo is not an engine is not a game. What kind, what resources, which language, which target platform, which audience, what budget, for which purpose. Be concrete, specify problem at hand, show your solution and explain why you chose that.

Without that, the best anyone can provide is just lots of handwaving. What worked, or was even vital for someone else might be completely wrong for you.

Quote:Original post by Antheus
Design is either suitable or unsuitable for problem at hand.

Design is also flexible enough or too inflexible to handle last minute changes fairly smoothly.

Quote:
If you have solved problems from same domain, and were able to evaluate the final result, then you will have gained useful experience.

How about the domain of win32 game development?

Quote:
If you have not done that, any advice will be hit-or-miss.

There's an off-chance that from somebody else's experiences valuable insight can be gleaned though.

Quote:
It may be suitable for your particular problem, or it may not be. Console programmer's advice will be much different from client PC developer or Phone developer or server-side advice.

Agreed and acknowledged.

Quote:
Best design for this particular case is one that gets the job done, just that, exactly that and nothing more. Everything else is secondary.

Unless you already know how and why to design something, you will not have the knowledge nor experience to make justified choices.

This is a matter of degree and not "all or nothing at all" though. A choice might be unjustified but still may end up working to some degree. Another choice might be unjustified and cause real trouble. Furthermore even a *complete beginner* can make the design decision to build a resource management system based on what they have read about *and* it might be a fairly well justified design decision too.

So I happen to think: there are degrees.

Quote:
But the first biggest mistake:
- Failure to specify exact requirements

Demo is not an engine is not a game.

That's a given. :-)

Quote:What kind, what resources, which language, which target platform, which audience, what budget, for which purpose. Be concrete, specify problem at hand, show your solution and explain why you chose that.

Without that, the best anyone can provide is just lots of handwaving. What worked, or was even vital for someone else might be completely wrong for you.

The default assumption has to be win32 game programming at hobbyist level in c++. Still fairly vague but then again I wasn't even inquiring about anything specifically related to any project I was working on necessarily.

Obviously there are design decisions that are generally (that means minus exceptions) a good idea. Obviously there are many design decisions that are so specific to a particular genre/engine/game that these are too specific to be of any general use.

Perhaps this is more an inquiry about which parts of a demo/engine/game might be *particularly sensitive* to flawed early-on design decisions.

Alex