As not actually having ever worked in the game industry I couldn't speak from experience, but there are many design patterns that carry over from engine to engine, things like scene graphs, these can be used for more than just one thing, however rendering is the use found in this book.

Event managers typically all do the same thing as well, take a type of an event and send it to a set of listeners, no matter how you do it , you are accomplishing the same thing. I think there are many different sub systems that eventually are pluggable into any engine, but maybe you mean the model-view structure architecture discussed in the book, I guess the answer would be no, there are probably companies who do it differently, however this was is quite flexible and allows to interface with different types of players/npc's.

Speaking as a game programming / software engineering student, I find the structure used in this book to be one that has made the most sense after almost a full year of reading software engineering books and trying to get my hands on anything I can.

Also, I found reading Chapter 2 to be a bit difficult to comprehend at first. If you start digging into the source code you may find it to make much more sense. The drawings in that chapter didn't really do much for me haha.

I've worked on nine professional games across five different studios. Every single game is different. Even games in the same studio can be very different. The Sims Medieval's architecture is fairly different than our current game. There really is no recognized standard architecture across all companies in the games industry. In general, we do abstract a lot of the same things, like the OS, graphics, sound, input, and anything else that talks directly to the hardware. Games have to work on a number of different devices, so creating these abstraction layers is key. That's one of the core philosophies of our book.

The separation of view and logic should be very familiar to you, since it's really an adaptation of MVC. Even still, many games don't decouple those systems. It just depends on the team.

-Rez

Take a look at some different games that would be made super easy with messaging systems, I was just playing the indie game 'Uplink' , you get sent emails, how easy would it be to make an email event, rather than coupling emails to a function?

Originally posted by narshe
Rez, what about the generic event messaging system that is used between layers in the book; is this something that is commonly used in most games?

Yeah, the event system is one of those patterns you see in pretty much every game.

-Rez

I've seen a lot of engines where the word "architecture" doesn't really apply at all.

Some of them are actually quite famous and have shipped tons of games - but under the hood they are something of a mess. This happens more often than you'd expect it to - since so many games are bootstrapped from almost nothing, undergo rapid development without a lot of time to really clean up the architecture. Also - multiplatform support and heavy optimization tend to throw chaos into any clean engine.

Take that same crazy engine and rapidly develop sequel after sequel, adding more platforms and different systems for visualization culling, and you've got a little nightmare machine in code.

What I find strange is that the games built with these engines are still good, even great, even legendary. But, the experience of working on them, at least from an engineering standpoint, tends to be less so.

Bottom line - an engine's raw capability isn't linked directly with the elegance of its architecture - I've seen the opposite to be more true than false! But, I think elegance of architecture IS linked strongly to the happiness and productivity of the programmers working on it. What I find most odd about this is of all the disciplines that can throw a huge monkey wrench into a game project's ability to ship on time none beats programmers. That said, programmers tend to create their own hell because it isn't an animator or game designer writing the engine in the first place.

In this industry, time constraints contribute most strongly to everyone's woes, programmers and game engine architecture included.