Overview

Have you ever bought a (text) book because it looks very interesting, but just leave it staring at you on your bookshelf for months, or even years? This is exactly what happened to me when I bought "Game Engine Architecture" by Jason Gregory a couple of years ago. However, this year I decided to give it a go and read the entire book from cover to cover. I have to admit that I skimmed through some of it, but I think that's understandable considering that it has over 1,200 pages. In this article, I'm going to tell you the main takeaways I took from reading this book. So, let's dive in!

What's the book about?

If the title wasn't clear enough, this book covers the ins and outs of the architecture of a video game engine. A little bit over 1/3 of the book is spent covering the fundamental tools, software engineering concepts (including a chapter dedicated entirely to parallelism) and math for understanding a game engine. Then, it goes into an overview of 5 low-level engine systems and focuses another considerable section of the book in explaining the rendering engine, animation systems, collision & rigid body, audio and also some gameplay systems. If you want to know more about the specific topics that each chapter covers I recommend that you look for the book on your local Amazon page, select the Kindle version and read the contents table in the sample.

Who should read this book?

I strongly recommend this book to anyone who falls into any of these 3 categories:

• You work or want to work in the video game industry, regardless of the specific area.

• You want to implement a specific feature or concept that is mentioned in the book.

• You want to get a grasp on any of the topics covered in the fundamentals section or also get a grasp on more advanced physics and math concepts that are covered in specific engine sections.

Even if you're not a programmer, it will be very helpful for you to just skim the contents of the book and familiarize yourself with the concepts of the building blocks of what allows modern games to be made. I mean, the main reason I decided to finally read it was because a producer from CD PROJEKT RED recommended it to me as essential reading. It's important to mention that the book doesn't cover completely any particular subject but it provides a lot of resources and further reading recommendations if you want to learn more about a specific topic.

My main takeaways

Design before you implement!

Can we add a multiplayer mode?

If you want your game to support multiplayer, it's best to design it from day one. This is because a multiplayer mode has an impact on the design of several game engine components. Even though it is possible to make a multiplayer mode for an already single-player game, it can be very difficult and time-consuming. On the other hand, going from a multiplayer game to a single-player is easier because it can be treated as a special case of multiplayer that has just one player.

Taking control of the controls

Dedicating a considerable amount of time to the implementation and design of Human Interface Devices (HID) is essential because they form the bases for allowing player mechanics. Besides, I think this is even more important now that it's possible to use different controllers in every platform or even for adding support for special controllers for people with disabilities.

Physics can make or break your game

If your game is going to have any sort of physics or collision system, it is very important to consider the impact it will have on all the other areas of development of the game. Not allowing each department to have enough time to accommodate for this, can make the gameplay experience unbearable for players.

More often than not, the inherently chaotic behavior of a physics sim can actually detract from the gameplay experience rather than enhancing it.

- Jason Gregory, Game Engine Architecture

KISS Data-Driven components

Having Data-Driven components in the development of the game can have a lot of benefits but it's always important to carefully consider what should and what shouldn't be data-driven. Jason Gregory recommends following the KISS ("Keep It Simple, Stupid") mantra when designing and implementing data-driven tools.

To paraphrase Albert Einstein, everything in a game engine should be made as simple as possible, but no simpler.

- Jason Gregory, Game Engine Architecture

The tools make the game

Tidy your resources

Having proper resource management systems is like having a proper organization in your room or workplace. You can make a game without worrying too much about it but you'll just make the life of everyone involved in the project a lot harder. Taking the time to design and even implement good resource management systems will allow the whole team to be more productive because it'll make it easier to add, get or modify any asset of the game. Having a resource database would be ideal but it's also important to consider the implementation time of such a system.

Crush those bugs with ease!

Every programmer knows the struggle of having to deal with bugs. However, it is always better when you're able to detect those bugs early during development and not because you read a ton of angry reviews from players that stumbled upon a bug that the programming or QA teams weren't able to find. While it's impossible to find and fix every single bug and release your game within a reasonable timeframe, it's possible to decrease the number of bugs that make it to the final release of the game.

This can mostly be done by having the right tools for debugging, ranging from the use of logging & tracing to having in-game menus or consoles, drawing facilities and in-game stats. The implementation of these tools will take time but they will save a lot of pain from the team in the long run.

Memory management shapes decisions

Whenever you have to make an implementation decision of any kind, memory management is what will always tip the balance to one side or the other. It should always be one of the main concerns and topics of discussion because not taking care of memory management can lead to results ranging from slowing down the game to causing unexpected crashes.

Tips for programmers

• Programmers need to understand how strings work within their development environment. Especially to know how they are being stored and also to consider how they will be localized.

• An excellent gem of a tip that Jason Gregory gives is to arrange the members of a struct/class by the size that they will occupy in memory. This will allow them to have better alignment & packaging which will optimize the memory usage of that struct/class. Jason goes over the details of this in the section called "Data, Code and Memory Layout" of Chapter 3.

Why can't I save anywhere?

People, including me before I read the book, often wonder why not every game has the option to be able to save whenever you want. Well, the answer, as in many other design decisions, is memory management. Implementing a system that allows you to save anywhere means that the size of the saved game data file must increase significantly. This also comes with the implication of the correct memory management to make this possible.

Audio is king

Audio is probably one of the most important features of a game. It's sad and hard to understand for me why so many companies still leave audio as an afterthought or something that will be added after everything else is finished. Video games are after all audiovisual works. The chapter dedicated to audio in the book does an excellent job of reinforcing the fact that audio is an essential part of a game. It's also very useful for programmers to understand all the engineering that goes behind audio to improve its implementation in the game. A great implementation of audio in a game can even support other areas of the game. For example, character dialog can allow players to understand the intention of AI enemies and make it seem as if they were smarter than they actually are.

Having something > being something you're not

One of the concepts that stood out the most to me in the entire book is the importance of correctly understanding composition and inheritance and when to use each. Whenever you're designing classes for a system or feature of a game, it's always very easy to fall into the creation of monolithic hierarchies or the deadly diamond problem of multiple inheritance.

The book gives a great example in which you have the design of land vehicles and water vehicles which derive from a base vehicle class.

However, if you want to add amphibious vehicles to this design, you end up with a diamond-shaped hierarchy, which is a big no-no.

The usual solution to these types of problems tends to be to design a base class that has all the functionality that the child classes might need and implement a way for the game to know when to use each. However, this is just the wrong design and bad use of inheritance because you're forcing every class within that design into being a class with behavior that might be unnecessary because they will never use it.

The solution to this problem is to consider composition when designing your classes and convert "is-a" relationships into "has-a" relationships. The correct use of composition will allow each class to have the specific functionality that it needs, nothing more and nothing less. The ideal solution would be to implement generic components. However, they're trickier to implement because they require the game object code to also be written generically.

What's next?

As you can see, many considerations need to be taken into account when making a game and it's very important to understand what goes underneath the hood of a game engine to make the best decisions for your game. One of the key areas, which is also going to be my focus of study for the next few months, is the rendering engine. So be on the lookout for that!

Meanwhile, I invite you to tell me in the comments if you've had the opportunity to read/skim through this book or if you have any other insights on things that need to be considered when making a game!