Thread: right and wrong ways to do things?

>is there a right and a wrong way to structure and write an engine?

There are right ways, and wrong ways... but no one way is right. you should look into software design and design patterns if you really want to learn how to properly structure a large piece of software.

I find that the reason tutorial code and demo code like that is so neat is because they are only implementing one thing at a time and not in the context of a game engine.

I've seen terrain code that looks wonderful, but it won't work for a flight sim, won't work with a texture manager, etc, etc.

When you add all of this into a game setting or a game engine, there is a whole hell of a lot more going on than just showing someone an algo or a demo of some new trick. Thus the code tends to get a lot larger, but larger doesn't equal incoherent or ugly.

Sometimes you just can't make it 'pretty'. I say if it works and it works well then keep the code. Tidying up stuff that works just to make it look better (besides simple comments) can land you in serious trouble when you find out your 'housekeeping' has jacked up your algo.

Keep in mind that every engine works differently and is coded differently. Just make the new algo or tutorial topic fit into your engine structure and you have done your job. It is not your concern to make your code look exactly like the demo code.

I'll prob get flamed for this but often super optimized code is some of the hardest stuff to read, but it is absolutely required in the world of game programming.

Your wisdom comes from the trenches Bubba, which is the only place real wisdom can be gained.
Academics in their ivory towers may have things of beauty in mind when they design magnificent multitier architectures with grand class hierarchies, but their creations hardly ever pass the test of time.
They tend to be impossible to maintain, perform poorly, and take forever to implement.
Of course it's not them who ever get to face (or even notice) the consequences of those flaws, so they never learn from them and continue to create the same kind of things to be implemented by the workerbees who are the ones getting their pay cut and face being fired when another product goes over budget and ultimately fails in the market.

In the real world the only thing that counts is whether it works. 90% of all code is write-only anyway, as anyone working in software development (as a programmer, not as a senior architect straight out of university) for more than a few months will know.

This part of any game engine is very important and is often overlooked becouse people just want to jump into coding the freatures of the engine right away. You just need a system that is one, easy to expand without moving to many things around, that complements your continued learning and upgradablity. Two easy for you and other programmers to be able to interperate without to much explanation of the structure. Three, simplicity in an engine can be your best friend or your worst enemy, some parts need complex structure and some just dont, be careful.