Wow I go away for two days and look what happens. thanks a heap everyone for all the feed back. I just skimmed through I'll have to save this thread and read the lot later. Thanks a heap everyone, looks like to the book store I might be going :P

Quote:Original post by Icefox
*grins* Exactly. Finish reading my post, please.

Well....not exactly. For the most part I think we're both on the same page except I disagree with the notion of the topic being too broad to allow for a good (or even excellent) book on game engine design. I do believe that a GOOD book on engine design CAN be written that provides a solid foundation for designing game engines regardless of the genre. The omission of implementation details doesn't mean the content will end up being too generic or less useful than traditional books on design.

Unfortunately the post that you're replying to wasn't exactly clear (my fault). I corrected a couple of items but ended up striking everything out and including a clarification. Check the original message for the updates. Hopefully this post is less feeble :)

Quote:Original post by Icecfox
It's really a question of how specific and general you want to be. If you want to have a book on low-level organizational details and algorithms used in games, you'll probably have to restrict yourself to a single genre. And if you want a book that covers the broader concepts, you end up with a book on software design as a whole, not game engine design specifically.

I'm not exactly sure what you're referring to regarding organizational details (it's a bit subjective) so I'll save that for later. Algorithms however are an implementation detail and fall into a completely separate part of the process. During the design phase an algorithm may be represented by the Strategy pattern. By doing this in the design you know the why it's used, where it's used, and what it's supposed to do. What you don't know however are the details of the implementation. This eliminates the need to immediately decide on what the specifics are during the design phase. By not doing this you may run into a situation where you spend two days deciding on an algorithm only to change it later to something totally different.

If you apply low level details during the design process you've just violated a fundamental design principle. The end result is most certainly going to be getting locked into a specific genre (not really surprising). Obviously algorithms for a FPS are probably not going to translate well to a tile based RTS. If you attempted to explain this in a book you would need to cover as many implementations as possible. Not only would this make the book extremely large it's not necessary and not very practical. On the other hand, the use of an abstract representation eliminates the notion of genre specific implementations. Explaining what the pattern represents, what it's used for, and how it can be applied when designing a game engine can probably be done in the same amount of space as a single algorithm.

I think that one of the bigger problems (and probably the motivation of the OP's topic) is that existing material doesn't take traditional design topics and show how they apply to games. The intent should not be teaching the target audience everything about design. I think that expecting this type of material is pointless and impractical. While this might seem obvious I just want to make sure you don't think that's what I'm suggesting. The result that I personally would like to see is a book on game engine design that provides a solid foundation that can be built upon over time. The following approach could be used to present game engine design in 3-5 parts (125 to 250 pages depending on number of parts or content). Here's one possible breakdown:


Part one begins with an overview, introduction, and solid presentation of design practices. A very good outline can be found here. I think that by using the information on that page (or similar text) it could be easily expanded to about 100 pages and be very easy for beginners to understand. Two parts which would be very beneficial are Design Principles and Design Concepts.


Part Two introduces the traditional design pattern catalog. Unfortunately some of the items in the catalog would need to be (to a point) condensed or omitted due to size. Of course some are obviously more important than others and some might not apply very often in game design. I think one of the bigger problems that beginners face is misunderstanding the purpose of specific patterns. Some such as Strategy, Facade, State, Momento, Visitor are quite often misunderstood because they [for some people] clash with certain game terminology.


Part Three starts with the practical application of the design process. This includes creating requirements, recognizing dependencies, analyzing unique components of the game engine, and whether certain functionality is better represented in the game engine or in the game itself. There are enough generic components such as networking, user input, rendering/drawing, communication, and resource management that they can be presented without dealing with implementation details.

Regardless of whether you're creating an RPG, FPS, or RTS the same design issues are typically going to be encountered. If a beginner (or even intermediate) programmer reads a traditional book on design they may not understand the application and benefits of say the Abstract factory pattern in games. With a traditional book they may understand that it's used to create objects without knowledge of the class or implementation it may not be clear on how to apply it to their engine design. Quick example:

When the source code for DOOM was released a lot of groups started popping up to fix bugs and expand it. Some of those modifications included the addition of weapons, creatures, and other items. Unfortunately the overall architecture of Doom required the engine to be modified rather than the game in order to include the new items. Migrating the new item from one Doom project to another was problematic and tedious due to everything being hard coded. This approach posed difficulties even in expanding a single code base.

The issue in the above example is not genre dependent. By showing how an Abstract Factory can be applied to the problem they get an idea of how to spawn objects in the engine without knowing the specifics of the game itself.


Part Four takes the requirements and list of components and starts breaking them down into smaller representations. This exposes the reader to applying and dealing with aggregation, inheritance, abstraction, artifacts, association, and loose vs. tight coupling. Uses real world examples presented in an abstract approach.


Additional topics can be presented as well. Depending on the overall contents of the book it might be beneficial to include a part dealing with UML notation and as icing on the cake a section showing how design patterns are represented in different genres. This is just a rough description and it could certainly use a few revisions to break it down into a more precise list.