Sign in to follow this  
Mihulik

Game Engine Design and Implementation by Alan Thron

Recommended Posts

Mihulik    128
Hi,
have you read (or at least browsed through) [url="http://www.amazon.com/Game-Engine-Design-Implementation-Thorn/dp/0763784516/ref=sr_1_14?ie=UTF8&qid=1294829438&sr=8-14"]the book[/url]?
Is the book similar to [url="http://www.amazon.com/Game-Engine-Architecture-Jason-Gregory/dp/1568814135/ref=sr_1_1?ie=UTF8&qid=1294830027&sr=8-1"]Game Engine Architecture[/url] by Jason Gregory? I guess so.

Thanks for your replies :)

Share this post


Link to post
Share on other sites
Halifax2    295
It has been released fairly recently, as such I don't think people have had much time to pick it up yet. I haven't even heard of the book until now, but I have read [i]Game Engine Architecture [/i]by Jason Gregory. Although I haven't read Thron's book, I took a look at the free preview which provided a lot. In comparison I believe Gregory's book is more about the theory of game engine design, forcing you to consider how things should be implemented and what your needs are, while Thron's book is more of an exploration of all possible options and implementations; furthermore, it appears to do a lot of hand-holding. (Whether that is a benefit or not is up to you.)

Whichever book you choose is really a matter of taste. However, I can personally recommend Gregory's book.

Share this post


Link to post
Share on other sites
Mihulik    128
I've already read Gregory's book. :) It's an almost perfect book. It's clear that Jason knows what he's talking about! :)

The reason why I asked about the book is that I'm considering buying the book.

However, I'm afraid that the book is too similar to Gregory's book (and possibly worse) so buying the book would be a waste of money. :)

Share this post


Link to post
Share on other sites
CodeDemon    363
I've looked through the table of contents. It looks like it covers a variety of practical implementations for different subsets of what goes into building a game engine. But it focuses more on where the industry has been instead of where things are going and it looks like it tries to keep things pretty simple using off-the-shelf open source libraries like SDL, Ogre, Bullet, etc. Not to say that this is bad, especially for not someone who is relatively new to the subject. I just don't think it's indicative of where the industry may be heading currently on the PC and in the next console generation, where you need to really think about thread scalability and parallelism. If you're looking at building a next generation engine that will be able to maximize current and future hardware, this book probably won't be much help.

Share this post


Link to post
Share on other sites
way2lazy2care    790
[quote name='CodeDemon' timestamp='1295022480' post='4758888']
I've looked through the table of contents. It looks like it covers a variety of practical implementations for different subsets of what goes into building a game engine. But it focuses more on where the industry has been instead of where things are going and it looks like it tries to keep things pretty simple using off-the-shelf open source libraries like SDL, Ogre, Bullet, etc. Not to say that this is bad, especially for not someone who is relatively new to the subject. I just don't think it's indicative of where the industry may be heading currently on the PC and in the next console generation, where you need to really think about thread scalability and parallelism. If you're looking at building a next generation engine that will be able to maximize current and future hardware, this book probably won't be much help.
[/quote]

do you know of any books that deal with this specifically? I have been wary of buying books in the past for the reasons in your post, but if there is one that deals with parallelism better I'd love to read it.

Share this post


Link to post
Share on other sites
Mihulik    128
[quote name='way2lazy2care' timestamp='1295026630' post='4758915']
[quote name='CodeDemon' timestamp='1295022480' post='4758888']
I've looked through the table of contents. It looks like it covers a variety of practical implementations for different subsets of what goes into building a game engine. But it focuses more on where the industry has been instead of where things are going and it looks like it tries to keep things pretty simple using off-the-shelf open source libraries like SDL, Ogre, Bullet, etc. Not to say that this is bad, especially for not someone who is relatively new to the subject. I just don't think it's indicative of where the industry may be heading currently on the PC and in the next console generation, where you need to really think about thread scalability and parallelism. If you're looking at building a next generation engine that will be able to maximize current and future hardware, this book probably won't be much help.
[/quote]

do you know of any books that deal with this specifically? I have been wary of buying books in the past for the reasons in your post, but if there is one that deals with parallelism better I'd love to read it.
[/quote]

I'd be very interested to know about such a book if you knew such one, too. :rolleyes:

Share this post


Link to post
Share on other sites
Chris Reynolds    110
Many people like to argue otherwise, but game engine design that truly utilizes paralellism is in its infancy, if not non-existant.

Not sure I'd be picking up a book on it this early - you'd be putting a lot of trust in an author. Rather, study concepts and toss around your own design ideas. Unlike traditional game engine design, you might not be reinventing the wheel.

Share this post


Link to post
Share on other sites
CodeDemon    363
[quote name='way2lazy2care' timestamp='1295026630' post='4758915']
do you know of any books that deal with this specifically? I have been wary of buying books in the past for the reasons in your post, but if there is one that deals with parallelism better I'd love to read it.
[/quote]

[quote name='Mihulik' timestamp='1295035770' post='4758977']
I'd be very interested to know about such a book if you knew such one, too. :rolleyes:
[/quote]

[quote name='Chris Reynolds' timestamp='1295070577' post='4759168']
Many people like to argue otherwise, but game engine design that truly utilizes paralellism is in its infancy, if not non-existant.

Not sure I'd be picking up a book on it this early - you'd be putting a lot of trust in an author. Rather, study concepts and toss around your own design ideas. Unlike traditional game engine design, you might not be reinventing the wheel.
[/quote]

I'm not aware of any such book, but Chris has it right, it's too early to tell exactly how things will pan out. It's new ground.

The type of parallelism we see in today's game engines is the result of a mostly top-down approach architecturally. In other words, it's been pretty much bolted on. It tries to logically partition work within different sub-systems into separate threads. This is where you get your typical two-thread architecture where game logic and rendering are broken into separate threads, or your three-thread architecture where physics is performed within its own thread distinct from the game-logic and rendering. Many engines also do their I/O asynchronously, loading and processing resources in the background. Newer engines targeting DirectX 11 or a future version of OpenGL may take advantage of deferred rendering contexts, farming out some of the work in building the command buffers / display lists, alleviating the load on the main rendering thread. Engines optimized for the PS3/Cell are obviously a bit different due to the SPEs.

This is all perfectly fine and good for current hardware, but in the end, none of if these models scale all that well beyond that. Try to take such an engine and reuse it on a new hardware platform with a couple of more cores, and you'll find you won't be able to do much more with it without serious modification. Yeah, sure, maybe you can do a little bit more, but you're no longer able to maximize the hardware. You can't design scalable systems around logical partitions of specific modules and sub-systems.

The same goes for trying to design it around a single type of concurrency pattern or concurrent-language idiom. There is no one-size-fits-all solution, there is no silver bullet. You can't constrain yourself to a single recipe. This is why I think developers saying things like "software transactional memory is the great panacea for everyone's scalability woes" are quite misinformed. Do you compose your data structures using a single type of algorithm? Do you try to use an associative hash-table with open-addressing to solve all of your container needs? Of course not, that's madness! So in order to build scalable systems, you need to understand all of the tools you have at your disposal, their benefits and their trade-offs, and apply them correctly.

Thus you need to dive into the deep end and build everything from the bottom-up with scalability as one of your prime goals. You need to look at ways of maximizing read-sharing, minimizing write-sharing, and coming up with good mechanisms for distributing/balancing work among threads, using your entire repertoire of concurrency tools and recipes.

But I digress. From the ToC of the book, I don't think it even covers the two-thread game logic + render model, and if it does, I'd be surprised if it did more than just gloss over it.

Share this post


Link to post
Share on other sites
CodeDemon    363
[quote name='Mihulik' timestamp='1295178283' post='4759595']
Thank you for the very worthwhile post. Have you been considering writing a book? ;)

It really seems the book isn't worth buying. :)
[/quote]

First, the book seems to be worthwhile for someone who's looking at trying to manage complexity within their engine better and hasn't yet had a taste of working on larger software projects or game development projects. But if you've already got a bunch of books on this subject, I think it's just more of the same.

As for writing a book on this, hahaha. Sorry, I'm afraid I don't have the patience and I'd feel too dirty doing so. I don't know enough on the subject to offer a comprehensive delivery on the materials. And besides, it's really too early for such a book. It's going to depend on what we get in next generation consoles, as that will largely drive the direction the industry will take.

Will the console manufacturers feel content in shipping new consoles with power-concious, low-cost, middle of the road performance? For example, something with 4 general purpose cores and GPU on the same die. Yeah, that'd be great to have now in consoles, but I think in a couple of years it'll be pretty mediocre for something built on a 22-28nm process node. But the console builders may very well do this to maximize their own profits, and consumers will still buy it up as it will be able deliver games slightly better than today's but at 1080p resolutions and 60hz frame rates. If that happens, it might put a stop to the need to investigate this further.

I think the magic number is 8. If we start getting 8 or more cores to work with, that will force developers to start approaching things differently.

If we're lucky, we might get that in next generation consoles, or we might get something even better. Maybe something like Larrabee. Who knows, I'm not privy to that kind of information.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this