Fifth edition ?

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • We're not actively working on a 5th edition. I wouldn't expect one any time soon.

    • Even if we started on it today, it would be 6-8 months in the works before you'd be able to buy it anywhere.
      Author, Programmer, Brewer, Patriot
    • Yes and no. Advances to architecture tend to come to fields of programming rather than game creation as a whole. It's also important to realize that while certain techniques are very common (like the actor/component system), they are not universal.

      For example, in GCC, we have different View objects that present the world to the player and AI characters. You can have different representations and allow communication back to the Logic through this system. Unreal 4 does something similar with their character controllers, allowing you to easily possess a Pawn. Unity doesn't have this concept at all.

      Even if the architecture is similar, the specific implementation will often be different. For example, managing game objects is something every game needs to solve. Most games I've worked on use an actor/component system similar to the one I wrote for GCC. Unity's GameObject/Component system is very similar to this as is the one we built on RatRace at SuperEgo Games. Many companies use a hybrid inheritance/component model. The Sims 4 had a ScriptObject class with a GameObject subclass. GameObject's could have components that defined behavior. Sims were actually a subclass of GameObject. Unreal 4 has a similar approach, where the Actor is the top-level game object, but you can also have a Pawn or Character, which are subclasses of Actor that have hard-coded components.

      There are also some more subtle differences. For example, in Unity, all components are ticked by calling your Update() function. This is done through a C# concept called reflection which scans the object for a function named "Update" and calls it if it exists. Unreal 4 has a virtual Tick() function that's called on components, but you have to set a certain bool to true or it won't get called. In my own game engine, I don't have an update on game objects or components. I have a different system called the EntityComponentSystem which uses processes to tick certain components that need it. Same concept, different implementations.

      A lot times you'll have different names. The Process system in GCC is basically a cooperative multitasking system. We called them Tasks on The Sims 4 (or services, which were something else) and cooperative threads on The Sims Medieval. They were Actions on RatRace.

      As for new techniques, there are a few that come to mind. We touch on multi-threaded programming in the book, but at this points it's standard to use multiple threads. Modern CPUs aren't significantly faster, they have more cores, so most modern games scale using threads. Usually you have at least two: the main thread handles the game logic while a second thread handles all the rendering. Most big games have a thread for resource loading and you often have threads for other big tasks, like pathfinding in RTS games. The Sims 4 ran the scripting layer in its own thread.

      Unless you're a big company with internal tech, you're probably using an established game engine. Unity dominates the indie market, but Unreal 4 is catching up since their announcement of going free at GDC. Those are the big contenders right now. We have tons of mobile game companies out here in San Francisco and most of them use Unity.

      The shader pipeline is becoming more common, especially with Windows XP dying and no longer having to support DirectX 9.

      More and more companies have embraced data-driven architectures. For example, on The Sims Medieval, every interaction was a subclass. On The Sims 4, most interactions were just instances of the SuperInteraction class with different data sets.

      Hope that answers your question. :)

    • Thanks Rez. I'm doing a 2D game and using MonoGame. I'm a programmer so learning how engines work and writing one from scratch is really appealing to me. Unity's 2D support is getting better but I still thought writing my own engine could be beneficial. I'm doing it for fun for the most part, so I don't care as much about whipping out games as fast as possible. Once I have the first game complete, I'll probably have a fairly solid 2D engine at that point and wouldn't need to bother with another. If I ever went 3D, I'd probably use Unity or Unreal.

      I would think a 5th edition could just have additions to it and maybe some of the alternative ways to accomplish the same thing shown too, like you mentioned. Like I said, the 4th edition is a very solid book already. :)