Jump to content

  • Log In with Google      Sign In   
  • Create Account


Game Engine Design and Implementation by Alan Thron


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
10 replies to this topic

#1 Mihulik   Members   -  Reputation: 124

Posted 12 January 2011 - 05:03 AM

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 :)

Sponsor:

#2 Mihulik   Members   -  Reputation: 124

Posted 13 January 2011 - 09:27 AM

Nobody read the book? :)

#3 DenzelM   Members   -  Reputation: 295

Posted 13 January 2011 - 10:11 AM

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.
Denzel Morris (@drdizzy) :: Software Engineer :: SkyTech Enterprises, Inc.
"When men are most sure and arrogant they are commonly most mistaken, giving views to passion without that proper deliberation which alone can secure them from the grossest absurdities." - David Hume

#4 Mihulik   Members   -  Reputation: 124

Posted 14 January 2011 - 10:11 AM

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. :)

#5 CodeDemon   Members   -  Reputation: 363

Posted 14 January 2011 - 10:28 AM

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.

#6 way2lazy2care   Members   -  Reputation: 782

Posted 14 January 2011 - 11:37 AM

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.

#7 Mihulik   Members   -  Reputation: 124

Posted 14 January 2011 - 02:09 PM


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. :rolleyes:

#8 Chris Reynolds   Members   -  Reputation: 110

Posted 14 January 2011 - 11:49 PM

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.


#9 CodeDemon   Members   -  Reputation: 363

Posted 16 January 2011 - 01:41 AM

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. :rolleyes:


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.

#10 Mihulik   Members   -  Reputation: 124

Posted 16 January 2011 - 05:44 AM

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

It really seems the book isn't worth buying. :)



#11 CodeDemon   Members   -  Reputation: 363

Posted 16 January 2011 - 01:13 PM

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

It really seems the book isn't worth buying. :)


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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS