Game Engine Architecture
Chapter 1 - Introduction
The typical game development team consists of:
1. Engineers
Generally divided into runtime and tools programmers. Runtime programmers create the parts that end up in the final product, while tools programmers automate or facilitate the development process.
Example fields that engineers work in are AI, Audio or Physics. Some engineers specialize in one field and others generalize their skills.
2. Artists
Artists create the game content. There are as many types of artists as there are types of content. Some general categories are Concept artists, 3D Modelers, Texture artists, Lighting artists, Animators, Motion capture actors, Sound designers, Voice actors and Composers.
3. Game Designers
The game designer creates the interaction between the player and the game. They can work at different levels of detail within the player experience. They create things like the level design, high-level player goals, geographical areas, encounters and puzzle elements.
4. Producers
The producer has a different role for each different studio. They could be HR and schedule managers, lead game designers or the liason between the business unit and the game developers.
5. Other Staff
Outside of the people creating the game, there are people supporting the game development through marketing efforts, management and IT.
6. Publishers, studios
A publisher handles the marketing and distribution of a game. It's usually a large corporation. There are also game development studios who work directly for a console manufacturer: these are called first-party developers.
Analytical and Numerical mathematics
Mathematical models can be analytical or numerical. The analytical method represents equations like y(t) = gt^2/2 + v0 * t + y0, in which y can be evaluated from a constant and a few starting conditions.
The numerical model might be expressed as y(t + dt) = F(y(t), ý(t), ´´y(t), ...), in other words, the future value of y can be found as some function of its first, second and possibly higher-order derivates at the current time.
Numerical models suit games very well, because of the "game loop" that iterates with some time interval.
Trade-offs and the "General-Purpose Game Engine"
The creation of any efficient game engine involves trade-offs, depending on the target platform and what kind of game it is designed to run. For example, rendering of indoor environments employs very different techniques compared to rendering a vast outdoor environment.
The indoor engine might use a binary space partitioning (BSP) tree or portal system to ensure that no geometry is drawn that is being occluded by walls or objects that are closer to the camera. The outdoor engine, on the other hand, might use a less-exact occlusion mechanism, or none at all, but it probably makes aggressive use of level-of-detail (LOD) techniques to ensure that distant objects are rendererd with a minimum number of triangles, while using high-resolution triangle meshes for geometry that is close to the camera.
Unity does support both LOD and Occlusion Culling, but a specialized engine will always produce more impressive results.
Quake and Quake II
When id Software created Quake and Quake II they separated the game code from the system code, creating one of the first game engines. Many game engines emerged from the source code of Quake. The source code is openly available.
Physics SDKs
There are two major proprietary physics SDKs used by the industry: Havok and PhysX. PhysX is a free binary distributed by Nvidia, but it is optimized to run on their GPUs.
There are also free & open source alternatives: the Open Dynamics Engine, as well as I-Collide, V-Collide and RAPID.
Multiplayer support
Multiplayer support in a game engine isn't necessarily a complex thing to implement, but it does affect many parts of the engine code, including the game world object model, renderer, human input device system, player control system and animation system!
Therefore, retrofitting multiplayer support into a single-player engine is somewhat daunting (but possible!)