Back to General and Gameplay Programming

Game Engine Architecture

Helter Skelter · 2005-07-07T19:22:28

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 IcecfoxIt'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.

General and Gameplay Programming Programming

Started by BoReDoM_Inc July 04, 2005 01:03 AM

50 comments, last by Helter Skelter 18 years, 10 months ago

CTar

1,134

July 06, 2005 05:35 AM

Quote:Original post by cdoty
Has anyone read Introduction to 3D Game Engine Design Using DirectX 9 and C# (http://www.amazon.com/exec/obidos/tg/detail/-/1590590813/qid=1120613357/sr=8-9/ref=sr_8_xs_ap_i2_xgl14/002-0173183-8392036?v=glance&s=books&n=507846)?

This sounds like a decent starting point for understanding 3d engine design.

I have read it, it was pretty good. Gave me an understanding of what a game engine actually was. If you're already using C++ I would say that 3D Game Engine Programming is better, but 3D Game Engine Design Using DirectX 9 and C# are better if you aren't that experienced.

Helter Skelter

332

July 06, 2005 05:41 AM

Quote:Original post by Icefox
I'm not sure it's possible to write a good book on "game engine design", because the topic is far far too broad.

How is it too broad? Designing a game engine isn't any different than designing any other type of program. You're still faced with the exact same issues such as resource management, user input, visual presentation, communication between objects, communication between subsystems, triggering events, maintaining collections of data, etc. I don't see anything about games that make them so unique as to require a domain specific approach to design. If the same design methodologies and patterns are applied to just about every other type of software (graphics editors, word processors, databases) why aren't they suitable for game design?

There's plenty of software design resources on the web so there's really no reason to believe they don't exist. I also find it hard to believe that a book (or other resource) specific to game engine design is any be more beneficial than existing information even if the contents are domain specific.

Clarification from Helter Skelter
This post was very badly worded and definitely did not convey the point I was trying to make. I have scratched off the above post (kept for historical purposes) and included the following equally feeble clarification:

1. By saying that designing game engines is no different than designing any other application I meant to convey that we don't need to create any special processes, practices, or patterns to design game engines.

2. The comment about a book on game engine design not being beneficial was worded incorrectly. I mean to say that it would be more beneficial but content doesn't need domain specific practices or patterns.

3. There's some context missing after the 'domain specific' comments. It was intended to express that a good book with practical and valuable information on game design IS possible.

After reading this post a couple of extra times the only reason I can think of why it came off so feeble minded is I was thinking of more than just your post when I wrote it.

The following is a quick and far from complete list of existing design patterns that can be easily and quite successfully applied to game engine design without the need to include domain specific characteristics.

	Abstract factory	Interface	Balking			Iterator	Builder			Observer	Container		Pipeline	Command			Proxy	Delgation		Scheduler	Event Listener		Singleton	Extensibility		State	Flyweight		Strategy	Immutable Object	Visitor

Feel free to browse through the following:

Resources:

Wikipedia: Design Patterns
Intro to design patterns
Another intro to design patterns
Introduction to design technique
Yet another intro to design patterns
UI Design Patterns

Books:

Design Patterns
Although this book is 10 years old and the notation is fairly dated the quality of this book is still high. If you find one used and at a good price I highly recommend it. This book continues to receive good reviews. The contents on the CD do not work very will with current browsers.

UML Distilled - Third Edition
Design Patterns Explained
Applying UML and Design Patterns
Software Architecture in Practice
Pattern-Oriented Software Architecture
Software Architecture: Organizational Principles and Patterns

[Edited by - Helter Skelter on July 7, 2005 4:41:22 PM]

Anonymous

July 06, 2005 02:03 PM

Quote:Original post by cdoty
Has anyone read Introduction to 3D Game Engine Design Using DirectX 9 and C# (http://www.amazon.com/exec/obidos/tg/detail/-/1590590813/qid=1120613357/sr=8-9/ref=sr_8_xs_ap_i2_xgl14/002-0173183-8392036?v=glance&s=books&n=507846)?

This sounds like a decent starting point for understanding 3d engine design.

Don't buy it. I have it on my bookshelf, not because I was learning about 3D engines but C#. Having some background on the subject of DirectX and 3D programming in general allowed me to appreciate how bad the book actually was and how many bad design decisions the author makes.

There are plenty of other, better books out there than for you to waste your money on this.

Saruman

4,339

July 06, 2005 02:13 PM

Quote:Original post by Anonymous Poster
Don't buy it. I have it on my bookshelf, not because I was learning about 3D engines but C#. Having some background on the subject of DirectX and 3D programming in general allowed me to appreciate how bad the book actually was and how many bad design decisions the author makes.

I agree I flipped through this book as a co-worker owns it and it was just horrible. Only buy this book if you want to learn nothing about real game engines and/or engineering/design. It is basically a bunch of DX samples hacked together to magically work.

If you are serious about game engines then go buy Eberly's books, there is a reason why so many people appreciate them.

CTar

1,134

July 06, 2005 02:15 PM

Quote:Original post by Anonymous Poster
Quote:Original post by cdoty
Has anyone read Introduction to 3D Game Engine Design Using DirectX 9 and C# (http://www.amazon.com/exec/obidos/tg/detail/-/1590590813/qid=1120613357/sr=8-9/ref=sr_8_xs_ap_i2_xgl14/002-0173183-8392036?v=glance&s=books&n=507846)?

This sounds like a decent starting point for understanding 3d engine design.

Don't buy it. I have it on my bookshelf, not because I was learning about 3D engines but C#. Having some background on the subject of DirectX and 3D programming in general allowed me to appreciate how bad the book actually was and how many bad design decisions the author makes.

There are plenty of other, better books out there than for you to waste your money on this.

The reason it makes "bad" design decisions is that it is aimed at beginners, if you were to explain how to create a game engine which have a good design(like David Eberly does) and you still didn't assumed more about the reader and explained everything in as much detail as this book does you'ld probably end up with a >5000 pages book.

BTW no book could explain a game engine with only "good" design decisions since what one might think of a good solution seems like the worst possible solution to another.

Saruman

4,339

July 06, 2005 02:20 PM

Quote:Original post by CTar
The reason it makes "bad" design decisions is that it is aimed at beginners, if you were to explain how to create a game engine which have a good design(like David Eberly does) and you still didn't assumed more about the reader and explained everything in as much detail as this book does you'ld probably end up with a >5000 pages book.

So what? You should NOT be teaching beginners bad design and how to do things improperly. Also game engines are NOT for beginners.. at all! Beginners should be learning the engineering fundamentals and acquiring the mathematical skills they need if they want to build game engines. After having the proper needed skills they can easily read through David's books with good understanding.

It is quite the common myth that beginners should start with a lesser text with horrible design principles that is easier. All it does is teach bad habits and how to do things improperly. Quite honestly if somebody 'can't handle' David Eberly's books than quite frankly they should not be making game engines. That C# book is basically a hacked together cut & paste to make beginners happy that something is on the screen, all the while teaching them how to do things improperly.

Reading a book and learning bad design and hacking garbage implementations together will actually set someone back. They should be learning proper development and attaining the skills needed to attempt such a large project.

Quote:
BTW no book could explain a game engine with only "good" design decisions since what one might think of a good solution seems like the worst possible solution to another.

Wrong. No book could explain a 'perfect' game engine design is how it should be worded, for the reason you stated. But Eberly's books do in fact present a good design.. great design actually following the concepts of proper software architecture and patterns. Sure there are many differences in how you build an engine, but by not using design patterns and hacking code (such as in the C# book) than that is classified as bad design.

Helter Skelter

332

July 06, 2005 03:27 PM

Quote:Original post by CTar
The reason it makes "bad" design decisions is that it is aimed at beginners, if you were to explain how to create a game engine which have a good design(like David Eberly does) and you still didn't assumed more about the reader and explained everything in as much detail as this book does you'ld probably end up with a >5000 pages book.

Horsepucky!!! First of all 'creating' a game engine is significantly different than designing one. While Eberly's books might show you how to approach various implementation issues they're crap when it comes to design. Beginner or not I have yet to hear of an acceptable reason for teaching bad design habits. The more bad habits you expose beginners to the harder it becomes for them to overcome them later on.

Quote:Original post by CTar
BTW no book could explain a game engine with only "good" design decisions since what one might think of a good solution seems like the worst possible solution to another.

Absolutely WRONG!!! Software design is both a model and a process. Regardless of which one you choose there are is a set of concepts, guidelines, and principles that are applied. As long as the design does not violate those items it can and usually is considered 'good'. Even though you may not agree with the approach or decision concerning particular issues it does NOT mean it's a bad design.

Helter Skelter

332

July 06, 2005 03:36 PM

LMAO DAMNIT!!! You beat me again.

Quote:Original post by Saruman
It is quite the common myth that beginners should start with a lesser text with horrible design principles that is easier. All it does is teach bad habits and how to do things improperly.

Definitely agree with this. If you're teaching someone CPR, to be a lifeguard, or how to drive you don't skimp on the edu-mac-ation. I've always wondered why people think that you have to omit technical concepts and details in order for someone to learn.

Then again...John Edwards got a TV show so it must be some kinda of karma based balancing act for the universe.

Icefox

238

July 06, 2005 05:19 PM

Quote:Original post by Helter Skelter
Quote:Original post by Icefox
I'm not sure it's possible to write a good book on "game engine design", because the topic is far far too broad.

How is it too broad? Designing a game engine isn't any different than designing any other type of program. You're still faced with the exact same issues such as resource management, user input, visual presentation, communication between objects, communication between subsystems, triggering events, maintaining collections of data, etc. I don't see anything about games that make them so unique as to require a domain specific approach to design. If the same design methodologies and patterns are applied to just about every other type of software (graphics editors, word processors, databases) why aren't they suitable for game design?

*grins* Exactly. Finish reading my post, please.

Quote:Original post by Icecfox
But you can't write a book on "game engine design" simply because there are far, far too many different types of games for one set of design rules to be broadly applicable, short of the fundamental principles of programming itself.

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.

-----http://alopex.liLet's Program: http://youtube.com/user/icefox192

kelcharge

180

July 06, 2005 06:06 PM

I have recently started on my own "game engine" and it is actually easier than I thought it would be. I read no articles or tutorials or books on the subject at all, I just started off by making a few games and then taking bits and pieces out of them to create my "game engine".

True God of the TribunalKelchargeMy Site My Ugly Forums

Game Engine Architecture

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Game Engine Architecture

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines