Hi,
have you read (or at least browsed through) the book?
Is the book similar to Game Engine Architecture by Jason Gregory? I guess so.

Thanks for your replies

Nobody read the book?

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 Game Engine Architecture 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.

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.

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.

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.

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.

'CodeDemon' said:

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.

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.

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

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.

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.

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

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.

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.

Thank you for the very worthwhile post. Have you been considering writing a book?

It really seems the book isn't worth buying.