Our website uses cookies to enhance your browsing experience.
This book offers insights into C++, including algorithms and practices in game development, explores strengths and weaknesses of the language, its established workflows, and hands-on solutions. C++ continues to dominate the game development industry today thanks to its combination of high performance, flexibility, and extensive low-level control capabilities.
In the early 2000s, as developers sought ways to create more realistic and immersive game worlds, a unique game engine emerged, offering a completely new approach to architecture. CryEngine, developed by the German studio Crytek, revolutionized the industry with its stunning graphics and cutting-edge microkernel architecture.
It all started with a tech demo called "X-Isle: Dinosaur Island." Built by a rather small team, the demo turned heads among publishers and developers alike. Back then, most game engines relied on a monolithic architecture with tightly coupled components, but the Yerli brothers (Avni, Faruk, and Cevat Yerli) had a different vision. Inspired by the design of the QNX operating system, they applied the principles of microkernel architecture to a game project. This laid the foundation for an engine that would later become one of the most technologically advanced of its time.
Investors and studios put their faith in this approach, in which CryEngine isolates only critical functions in the central core, while the remaining components run as separate modules. Such modularity enabled developers to swap out components without destabilizing the whole system. Some implementations took it further, allowing individual logic modules and dynamic libraries to be reloaded at runtime, making it possible to update NPC behavior and fix logic bugs without restarting the game—only truly critical errors would cause a crash. Even then, a fallback handler could swap in the default module, reconnect the failed components, and let the session continue. This architecture also made it practical to create new features, as well as debug and optimize subsystems, without having to rebuild the entire engine. The brothers pushed the idea of supporting multiple genres on a single technology base, but it didn't quite work out, leaving CryEngine with the "best engine for FPS" reputation.
The first commercial game to demonstrate the power of the microkernel approach was Far Cry (2004), which impressed players with its vast open areas, long draw distances, and realistic vegetation, as well as a world that responded dynamically to the player's actions. The second version of CryEngine, used in Crysis (2007), became the technical benchmark for the new generation of graphics hardware, setting the standard for rendering performance; meanwhile, the phrase "But can it run Crysis?" became a meme among gamers.
The microkernel approach behind the engine left a mark on the entire game development industry, pushing concepts like scalability, fault tolerance, and cross-platform adaptability into the mainstream. Other engines began adopting similar practices. In fact, after the release of Crysis 2, scalability and adaptability became standard expectations in engine development.
CryEngine, like all major game engines at the time, was cross-platform from release. The renderer supported OpenGL and DirectX 8/9 and was designed for open environments; a single game level could contain areas spanning up to three square kilometers. The physics system was built entirely in-house, yet that never compromised its quality. It handled rigid bodies, fluids, vehicles, cloth simulation, soft-body objects, and ragdoll physics—in every respect, the technology reached an exceptionally high standard for a proprietary solution.
Its inverse kinematics technology allowed layering multiple animations onto a single model at once, which made character movement look far more natural. A module written in Lua, rather than C++, handled the NPCs' AI. The scripts could be changed without recompiling, a rare feature at the time. CryEngine also gave us Far Cry and its many expansions, as well as the MMORPG AION. NCSoft licensed CryEngine for AION, although the company later reworked it extensively to fit the demands of multiplayer online games.
In 2004, following the release of Far Cry, the shader module gained support for Shader Model 3.0, and the engine was updated to 1.2. Shaders unlocked a long list of visual effects: per-pixel lighting, bump-mapped reflections, refraction, smoke, animated textures, transparent computer screens, see-through surfaces, and bullet decals. One particularly notable feature was the fog rendering, which looked far more realistic than what competing engines of that era could pull off.
In March 2006, Ubisoft acquired full rights to the Far Cry franchise, along with a license to CryEngine. This covered the entire IP, including the trademark, logo, characters, story, and setting, as well as exclusive rights to the source code and the underlying technology—meaning the original team could no longer use any of the old code to develop a new engine.
After Crytek released the final patches for Far Cry, development of the technology split into two separate paths. Ubisoft, now holding the Far Cry franchise and a licensed copy of the engine's source code, went on to develop its own version for Far Cry Instincts and Far Cry Instincts: Evolution on Xbox, Far Cry Instincts: Predator on Xbox 360, and Far Cry Vengeance for the Nintendo Wii. According to Louis-Pierre Farand, lead producer on Far Cry 2, the resulting Dunia Engine retained only 2–3% of the original CryEngine's source code (Pic. 2.7).
Picture 2.7
In turn, Crytek's developers continued developing their own technology platform and created a new engine, CryEngine 2, which marked the next step in its evolution and was fully independent of Ubisoft. Like its predecessor, the engine was written in C++, but unlike the original, it did not aim for cross-platform support. It targeted a single platform: Microsoft Windows with DirectX. At the time of its release, CryEngine 2 ranked among the most technologically advanced and photorealistic game engines on the market, setting new standards for rendering, physics, and dynamic environments. However, its demanding hardware requirements and dependence on Windows and DirectX limited its audience to owners of high-end gaming PCs.
The engine kept every feature from the previous version and even improved most of them. CryEngine 2 handled massive open environments just as effectively, while a new asset streaming system allowed levels to load dynamically as the player progressed. Crytek was also among the first studios to ship a 64-bit build of a game. Because game worlds had grown considerably since Far Cry, rendering them took far more system resources, making 32-bit systems inadequate.
The microkernel architecture remained intact as well: the compiled engine was split into separate DLLs, with each component packaged as its own library and loaded on demand during gameplay. This meant developers could swap out or modify individual pieces without touching the rest of the engine.
CryPhysics, the new in-house physics engine Crytek built for this version, was designed for multithreading from the start and fully integrated into CryEngine 2. It opened the door to far more extensive physics interactions and allowed the engine to apply physics simulation to nearly every object in a level, including trees and vegetation, so they reacted realistically to gravity, wind, explosions, and collisions.
As with the previous version, the transition to CryEngine 3 came with friction, both within the team and among executives. A completely different team took over development, so the results were a mixed bag: some parts impressed, others fell flat. CryEngine 3 was officially announced on March 11, 2009, and released that same year on October 14. The first game to use the new engine was the first-person shooter Crysis 2.
The engine was originally developed with DirectX 11 support, but Crysis 2 shipped without it—as well as DirectX 10—until a patch came out. The likely reason was Crytek's push to turn Crysis 2 into a cross-platform release. One major drawback of staying PC-exclusive was piracy: every legitimate copy sold was reportedly matched by about ten pirated downloads. As a result, the studio shifted its focus toward consoles.
Modern versions of CryEngine continue to build on the ideas behind its microkernel architecture while gradually expanding the use of AI in both tooling and graphics. The philosophy established by the Yerli brothers left a lasting mark on the game industry, proving that modularity, flexibility, and scalability can coexist with high performance.
A related branch of the technology now lives on as an open-source engine, O3DE, which evolved from Amazon Lumberyard. Lumberyard was based on a 2015 version of CryEngine, whose source code is available separately. Amazon licensed the CryEngine source code, refactored and reorganized the project, and released it on GitHub as Lumberyard under a proprietary license. Later, the company handed the project over to the community as O3DE, making it freely available as open source. By the time it became open source, more than $50 million had reportedly been invested in the technology—some estimates place that figure above the development costs of Unity and Unreal Engine, or at least on a comparable level. The original modular architecture now takes the form of independent Gem components that developers can freely add to or remove from a project (Pic. 2.8).
Today, O3DE remains under active development. Although the engine offers a rich feature set, it has yet to achieve the same level of adoption as Unreal or Unity.
Picture N2.8
Among many well-known game engines, many of which trace back to the United States, there are a few notable exceptions from Eastern Europe that have shaped the industry in their own way. One such example is Dagor Engine, developed by Gaijin Entertainment. The engine stands out not only for its technical features and its ability to run on virtually any platform with a GPU and at least some kind of CPU, but also for its distinctive architecture built around data-driven design principles. Today, it's publicly available, so anyone can explore what's under the hood.
The engine's history goes back to the early 2000s, when an in-house game development tool gained wider recognition after the release of IL-2 Sturmovik: Birds of Prey (2009). The game showed that the engine could handle complex physics models, render realistic visual effects, and put data-driven design to real use.
Data-driven architecture is an approach where application logic comes mainly from data rather than being hard-coded in the source. For game engines, that means most elements of the game world—objects and their behavior included—are described in data files such as JSON, XML, or other structured formats. The engine interprets these files at runtime, which brings a few clear advantages. Data and code stay separate. Objects and their properties are defined declaratively—describing what should happen rather than how to implement it. And configuration becomes dynamic, letting developers make changes without recompiling or even restarting the game. Put together, these traits naturally evolve into a component-based system that's defined and configured entirely through data.
In traditional engines, changing game object behavior often requires writing or modifying code, recompiling it, and then testing the result. Here, game designers and artists can adjust object parameters, effects, and even core behavior simply by editing data files—effectively making changes on the fly. During an internal tournament for one of the studio's games, the admins spawned random level objects mid-game by simply dropping blk files (Dagor's equivalent of JSON) into the level folder. Cars, weapons, fridges, and a couple of tanks started appearing out of nowhere for the players.
Data-driven architecture pairs naturally with a component-based approach to designing game objects. Over time, developers start thinking this way by default and can't imagine working otherwise. In Dagor Engine, each object can be built from a set of components, with each one handling a specific functional aspect. This makes it easy to create new object variations just by combining and configuring existing components. Once again, all of this happens on the fly, without recompiling the engine and often without even restarting the game.
Contrary to the common belief that runtime data interpretation slows games down, a well-designed data-driven architecture can still deliver high performance. The evidence is indirect but visible: the company's games run at acceptable frame rates on mobile devices and the Nintendo Switch, neither of which is exactly known for raw power.
The resource system is a cornerstone of the data-driven architecture. The engine organizes all game data into a hierarchical structure of configs, each with a unique identifier and loadable on demand. In Dagor Engine, the code might look something like this:
/data/
/vehicles/
/tanks/
/t-34/
model.blk textures/
diffuse.dds normal.dds specular.dds
weapons.blk collision.blk
/weapons/
/guns/
/85mm_zis/ ballistics.blk Visual_effects.blkThe *.blk files are a special structured data format used in the engine. While similar to JSON in function, they are optimized for fast loading, efficient processing, and overriding of sections and properties. When loading, the game can pull in values to override object properties from another config. It typically looks something like this:
visual_effects.blk graphics {
rendinstDistMul:r=0.5 grassRadiusMul:r=0.1
}
visual_effects.@1.blk graphics {
override@rendinstDistMul:r=0.8
}The final configuration ends up with rendinstDistMul = 0.8.
Despite all its advantages, data-driven architecture also comes with serious drawbacks. The first is debugging complexity. Since behavior comes from data rather than code, debugging takes a lot more effort and usually needs specialized tools to track how data changes ripple through the system. In real projects, this often means maintaining separate visual debugging tools tailored to a specific engine.
The second drawback is interpretation overhead. However efficiently the engine optimizes data processing, runtime interpretation still introduces additional costs compared to hard-coded logic.
Pic. 2.9 shows the systems developers can configure just by modifying scripts, without rebuilding the entire engine—and, as you can see, that covers almost the entire engine.
The history of the video game industry is full of technologies that arrived ahead of their time. One such example is the X-Ray Engine, created by programmers Alexander Maksimchuk and Oles Shishkovtsov for the S.T.A.L.K.E.R. series. The game was originally going to be about robots on some unknown planet filled with anomalies and lasers. At some point the team realized they did not need to invent either the planet or the robots—the perfect anomalous zone with the perfect atmosphere already existed just a three-hour drive from their office.
Picture N2.9
First shown back in 2001, the engine went on to become the foundation for one of the most immersive gaming worlds ever created. Its graphics held up impressively well for the time. The engine could render up to four million polygons on screen, far beyond what even many late-2000s games could handle. It managed large-scale environments just as well, whether enclosed interiors or open areas reaching up to two square kilometers. On top of that, it ran a full dynamic day-night cycle with lighting changes, along with weather effects like rain, wind, and fog. The dynamic lighting in particular still impresses, producing memorable shots and an atmosphere that's hard to forget even now.
For physics, X-Ray relied on the open-source Open Dynamics Engine (ODE), also released in 2001. It handled rigid-body dynamics and collision detection, and worked well for simulating vehicles, creatures, and objects in a dynamic environment. On paper, the engine's integration system was stable enough that physics shouldn't have broken down without reason. In reality, players of the first S.T.A.L.K.E.R. game soon got very familiar with all kinds of physics anomalies—from flying bodies to bizarre object behavior. Those quirks eventually turned into one of the series' signature traits, inspiring memes and funny clips. Well, it simply fit the nature of the Zone—after all, anomalies are part of the setting.
This engine is a textbook example of monolithic architecture (not to be confused with a unitary one). It is divided into separate parts, but those parts are tightly bound together rather than loosely coupled. Unlike systems where components operate relatively independently, X-Ray Engine functions as a tightly integrated whole, with all components deeply interconnected.
Monolithic architecture (Pic. 2.10) brings both clear advantages and serious drawbacks. Tight integration across graphics, physics, and AI—and the ability to build gameplay mechanics directly off how components interact—enabled developers to use and plan resources more efficiently through custom allocators, object packing, fast message queues, and similar techniques. With no abstraction layers standing between components, interaction stayed direct and fast, which mattered a lot on the hardware available at the time. Developers could precisely control memory usage and CPU time, which proved critical for a project this demanding.
This unified structure also meant the engine, the game world, development tools, and subsystems could share one coherent vision, with everything working together naturally. Removing or isolating any individual part would inevitably reduce functionality and hurt overall performance.
However, the same characteristics that boost performance can also limit scalability, make individual components harder to update, and introduce various challenges, especially on multicore systems. As the system grows, maintaining it and fixing bugs becomes exponentially more difficult, since changes in one part often ripple through neighboring subsystems.
In fact, complexity ended up being the biggest technical issue of the X-Ray Engine. Beyond the random crashes familiar to every fan—hello, "bug trap"—the engine also suffered from micro-freezes and brief stutters that showed up across every game in the S.T.A.L.K.E.R series. They were especially bad in Shadow of Chernobyl, where, in extreme cases, the game could turn into a slideshow while running at a normal frame rate. The root cause was architectural: the engine relied heavily on a single CPU core, a limitation that only became more painful as multicore systems took over.
Picture 2.10
The last official version of the engine is X-Ray Engine 1.6.02, used in Call of Pripyat. The fan community didn't stop there, though. Enthusiasts kept refining the technology, creating unofficial engine versions that fixed many critical issues, introduced new features, and—most importantly—added support for multicore processors and multithreading.
Technical problems aside, the engine remains an important milestone in the history of game development. Its strengths—dynamic lighting, advanced physics, and the A-Life simulation system—were years ahead of their time and gave players plenty of standout moments. And perhaps this monolith really did make someone's dream game a reality.
Monolithic architecture—with all its strengths and weaknesses, and above all when applied deliberately—serves as an excellent example of a particular approach to building game engines. It also offers a valuable lesson for the industry as a whole. The engine's core concepts and many of the practices developed around it would later inform the 4A Engine, built by former members of the team for the Metro series.
From the outside, the game development industry may seem to advance at a rapid pace: new rendering technologies, new approaches to rigging, better-looking models, voice acting, and the growing use of AI for animation. Under the hood, however, all these things still rely on well-tested, established solutions that are extremely difficult to replace or change in any fundamental way. I would even argue that, outside conference talks, game development remains highly conservative. Big studios avoid risks, while smaller teams often lack the time and resources to take them, even when they'd like to. Real architectural innovation is rare. Against this backdrop, the adoption of concepts from the web—as seen with the Godot engine and microservices architecture—becomes particularly interesting.
Most architectural styles receive their names once communities or conference speakers notice a recurring pattern and start shaping it into something more defined—there is no secret council of architects deciding what the next major trend will be. More often, developers independently arrive at similar solutions as an engine's ecosystem evolves and new challenges emerge. The approaches that prove most effective at adapting to change and leveraging it eventually become recognized architectural patterns that others follow. Microservices stand out here, because when the concept first emerged, no game engine or game actually followed those principles. In fact, the term gained recognition through the article "Microservices" by Martin Fowler and James Lewis, published in 2014. In that article, the authors laid out the common traits of this relatively new architectural style. Looking at Godot, I see many of those same ideas at work. At its core, the microservices approach breaks a complex system into numerous small, autonomous services, each providing a specific set of features.
In the context of game development with Godot, this idea evolves into a microservice-like architecture where the game no longer exists as a monolithic mass of code but as a system of components that talk to each other. Physics, AI, UI, and the audio system—each of these elements can exist as a separate module with a clearly defined way of interacting with the rest. I would not call this approach perfect, but it does allow developers to focus on individual aspects of the game without constantly worrying about how a change might affect the rest of the project.
Godot first appeared in 2014 and has since won over many developers thanks to its simplicity and reliability. Its name comes from the character who never arrives in Samuel Beckett's play Waiting for Godot. What sets Godot apart is how it organizes game logic through a system of nodes and scenes. Imagine a construction set where every piece of the game—from a character to an interface—is a separate building block that snaps easily to others. Although Godot wasn't originally designed with microservices in mind, its node-based architecture and modularity ended up fitting that philosophy surprisingly well. The result was an architecture where different components can be developed almost entirely independently of each other.
Godot's signal mechanism provides a particularly elegant way to connect these components. Imagine a player picking up an item: the inventory system emits a signal, and other systems can react to it. The UI updates, the achievement system logs progress toward whatever is being collected, and a special abilities system recalculates character stats. None of these systems needs to know how the others work—or, in some cases, even that they exist at all.
In fact, the engine's core philosophy revolves around adding new features by creating new modules rather than modifying existing ones. Developers can reuse component modules across different projects, and if a module has a bug, it is less likely to affect the entire game. Of course, no game can be broken down into modules indefinitely, but this approach at least cuts the chances of the entire thing crashing due to a single faulty component.
That said, this architecture is no silver bullet—though for smaller projects it often works exceptionally well: you snap together a set of component modules, wire up their signals, and—voilà—everything comes together and works as intended. As a project grows, though, the sheer number of interactions and gameplay systems tends to introduce excessive complexity and slow things down. The signal system can become a bottleneck, while modules may start competing for updates. The real takeaway is that micro-modules only make sense where they provide a clear benefit. For example, separating game logic from visual presentation almost always pays off. On the other hand, splitting tightly coupled mechanics into independent services or modules often leads to unnecessary complexity later on.
Another important distinction is that, unlike traditional microservices in web development—which run as separate processes or even on different machines—all game components operate within the same process (or a small number of processes). This sidesteps a lot of communication and synchronization headaches typical of classical microservice systems, the kind of problems that would only get in the way at such a small scale.
Even so, this approach has gained a dedicated following: more than a dozen relatively large games shipped on Godot in 2024 alone. That may not sound impressive compared to the thousands released on Unreal Engine or Unity, but it is a significant achievement for a project maintained primarily by a handful of core developers and its community.
Author: Sergei Kushnirenko
Sergei has over 20-year experience in coding and game development. He graduated from ITMO National Research University and began his career developing software for naval simulators, navigation systems, and network solutions. For the past fifteen years, Sergei has specialized in game development: at Electronic Arts, he worked on optimizing The Sims and SimCity BuildIt, and at Gaijin Entertainment, Sergei headed up the porting of games to the Nintendo Switch and Apple TV platforms. Sergei actively participates in open-source projects, including the ImSpinner library and the Pharaoh (1999) game restoration project.
Game++. Part 1.1: Game engine architectures
Game++. Part 1.2: Game engine architectures
Game++. Part 1.3: Game engine architectures
0
0
0
0