I''m searching for a book that teaches modular/tight code design with a slight slant toward game applications. Or a complete focus on game apps. =P -- Seems that many of my projects are never completed due to code design and accepting nothing less than a Carmack picturesque engine in terms of code flow. --- Thanks Any input is much appreciated. Andy

quote:Original post by skillfreak
Seems that many of my projects are never completed due to code design and accepting nothing less than a Carmack picturesque engine in terms of code flow.

Read this. In particular, take the following to heart:

quote:
"[G]ame-driven development" [is the most important thing for making a great game on time]. It''s easy to lose sight of what your final goal actually is. Neversoft went through some very hard times in our early years, where we were less focused. The key is to ensure that everything you do is focused on shipping a quality game on time. The quality of the code is a secondary consideration. The quality of the next game is a secondary consideration. The only thing that really matters is the game.

In other words, you code doesn''t need to be pretty or elegant. It needs to work. It needs to deliver.

Quit dicking around and get writing!

I would agree (fast functional code wins out over spotless code) but I know one very popular source of "spare time" games is the demo you want to show off when you''re applying for a job.

In that instance, I think having clean code does help--a hack here and there to save time or precious cycles can be ok, but I think a generally organized structure will help.

Of course, everything of what I think will be put to the test in a little over a year when I''m looking for such a job and hopefully my game project is at the very least a functional engine.

Experienced programmers write reasonably clean code naturally.

Spend a little time thinking about what the structure ought to be. Keep it simple, just whatever objects come to mind. Don''t try to design for the future at this point, with the abstract base classes and private implementations and what not. Just keep it simple. Take a very basic set of features, and work out how to implement them.

Then hack away at that until you reach a point where you realise your framework is wrong. (This might be ten versions down the line. It might be before your first attempt to compile.) Adjust until the current bit of code you''re trying to do will fit.

Then grab the next feature and work it in. Change the structure as needed. Lather, rinse, repeat.

Some changes will of course repay the effort many fold in the future as the ''framework'' improves. But remember your deadlines.

Thank you everyone for yur input. =) def keep everything said in mind.