Evolving a Live Game Engine: Introducing ECS Without a Full Rewrite | Alex Zhorau | GameDev Day 2026
In a Nutshell
Alex Zhorau shows how to incrementally integrate ECS into a live game engine by bridging existing actors and components rather than replacing everything at once. The core strategy uses representative components to link old objects to new ECS entities, allowing mixed systems to access both worlds and enabling gradual migration of logic to ECS-only components and systems. This hybrid approach delivers architectural flexibility first, while performance gains require isolating new ECS code from legacy systems that can't be multithreaded.
These notes were generated by AI and may contain inaccuracies.
Alex Zhorau presents on integrating the Entity-Component System (ECS) into an existing live game engine without requiring a complete rewrite. The talk covers obstacles encountered during integration and methods to overcome them. Alex has experience introducing a custom ECS system in World of Tanks at Wargaming, worked with Unreal Engine's Mass Entity framework at Splash Damage, and has dealt with ECS-dependent engines in various contexts. He currently works at Meta as a game developer.
Entity-Component System is an architectural model focused on collective processing of composite objects. The three main concepts are:
- Entity: A lightweight identifier available via API that can be moved freely without carrying any programming logic
- Components: Simple data containers without any logic, representing data formation
- Systems: The integration point for programming logic that performs operations on entities meeting specific criteria based on presence or absence of components
Systems operate on entities that contain specific component combinations. For example, one system might process entities with components B and C, while another processes entities with component A.
The mental model of the system is essentially a point where you integrate logic that performs specific operations on specific components
This model resembles shader programs where operations are performed on all objects meeting defined criteria.
ECS provides three primary benefits:
- Clear and logical scalability
- Better performance
- Potential improvements to composition tools
Architectural benefits may appear before performance benefits manifest in the system.
Logical Scalability
ECS commits to configuration rather than inheritance. Beyond this, ECS provides a second dimension of scalability: new behaviors can be attached by writing new systems without affecting existing entity and component structures. Systems can also be replaced with new behavior types, giving two dimensions of expansion instead of one.
Performance Benefits
ECS enables mass processing operations, reorganizing memory to make entity browsing cache-friendly. The archetypes model organizes components into matrices where components of the same type are stored in connected arrays. This arrangement enables faster processing due to processor cache proximity.
Multiple systems can be organized into a graph based on component access types, enabling parallel execution. Individual systems can also run in parallel using parallel iteration loops to process operations on multiple entities simultaneously.
Authoring Tools
ECS unifies the way game elements are organized, potentially improving tools in engines with long histories that have different setup methods for game elements.
Integration scenarios include:
- Live game as a service with existing engine in production
- Game in production phase with existing engine
- Prototypes with deep inheritance sequences for actors with logic
- Godot-like node models with recursive data structures or scene graphs
- Unreal Engine-style actors with logic and added components
- Unity-style game objects with components containing logic
Existing content, tools, and codebase manipulating current actor types must be considered. The core engine is assumed to be written in C or C++.
Before rewriting, define goals:
- Using ECS only as a performance enhancer
- Using ECS for standardization and replacement of game logic writing
- Changing organization to a new model entirely
- Impact on artists - whether to introduce completely new workflows or hide changes from them
Critical milestones include:
- Implementing the ECS core (existing library or custom implementation)
- Integration with the current world
- Editor and sequence portions if exposing ECS to artists
- Network replication for multiplayer games
- Scripting system considerations
The ECS core represents a small portion of the total work required.
Bringing in a library and setting it aside for new logic only creates significant problems. The old world remains unchanged, and any ECS-reliant feature needs to interact with current logic, making implementation nearly impossible. This approach requires rewriting everything from scratch and prevents using ECS until complete rewrite occurs.
Gradual integration involves exposing existing objects to the ECS system, adding new ECS components and systems that interact with the current world, and transferring responsibilities from old to new world only when needed. Each step must support useful gameplay to avoid delaying functional ECS implementation.
Identify isolated islands of logic within the engine. Multiple component models may exist in older engines, with some deeply embedded in subsystems preventing transfer. More specific component models representing game logic portions can be moved gradually to ECS.
Even with single component models, isolated actuator pieces with minimal subsystem interaction can be transferred. Components are placed inside entities without reimplementation, creating entities that integrate existing components. The Actor itself can be treated as a special component type with logic inside, requiring additional systems to access and execute methods within those components.
Transfer Considerations
- Components must be easily transferable to ECS
- ECS libraries allowing random type classes as components enable minimal code rewriting
- Object lifecycle deeply embedded in current engine creates extraction difficulties
- Custom memory allocations and creation control complicate the process
- Object-oriented models often store pointers to other components, creating issues with ECS memory organization
Pointer Storage Problems
Performance-oriented ECS systems organize memory into tightly packed matrices. When gaps appear, swapping and removal processes occur, moving components into gaps. Raw pointers to component instances become invalid when components move, creating significant problems.
Solutions include:
- Rewriting all pointer usage locations
- Replacing raw pointers with shared pointer-like structures
- Adding support for multiple memory models within ECS, allowing old components to remain scattered while new components use compact storage
Instead of moving components directly, create a bridge to existing components without touching them. Build links between actors and entities, with every actor having a corresponding linked entity. Systems API can be expanded to allow writing or referring to both ECS components and actors or actor components.
Component carriers (box components) store pointers to existing components A, B, and C, with special representative component carriers storing pointers to representatives. This approach avoids touching current actor performance entirely.
This method proves useful when components are deeply ingrained or when engine modification authority is limited. Unreal Engine's Mass Entity system requires implementing this approach to reach actors due to deep codebase integration.
The bridge approach enables:
- Connecting ECS world to non-ECS world
- Writing new ECS logic that interacts with non-ECS world
- Creating mixed systems accessing both ECS components and actors simultaneously
- Adding new ECS logic types to existing world
- Rewriting Actor Components to ECS for performance improvements without changing system code
Performance Implications
- New ECS systems and components achieve regular ECS performance since they exist in their own isolated world
- Memory access for actors and actor components typically encounters cache misses since arrangement into memory-friendly arrays is not guaranteed
- Multi-threading considerations arise when actor codebase may not support multithreaded access, requiring hybrid systems to run on game thread
- Hybrid systems lose some ECS performance benefits when constrained to game thread
Component data can be copied into special synchronization systems. This requires determining the source of game data and handling synchronization when data is modified from either side. This approach becomes necessary when non-ECS world needs access to ECS data for backward compatibility reasons.
Alternatively, if ECS becomes the source of truth, representative components can store entity handles that implicitly find ECS components during data access, eliminating need for additional synchronization systems.
When identical components are used for actors outside the main game thread, extreme caution is required because ECS memory can be affected by multiple threads running simultaneously.
Networks present a complex challenge with two fundamental options. The first approach involves reusing existing network replication within the engine, using actors as a bridge for network replication when they support data replication. This method is easier but introduces an additional layer of data copying, potentially creating many representatives when copying numerous entities.
The second approach uses a completely isolated layer for copying the ECS system, providing greater control and benefits such as data aggregation from ECS components. However, this is fundamentally similar to developing a new network copying layer from scratch, which can be problematic due to resource constraints and the existence of competing network copying models.
If the current network replication model is completely abstract from actors, ECS components can potentially be linked to this abstract network system. This becomes significantly more difficult when the network copying system is deeply ingrained in the actors.
Scripting support can be dispensed with if the primary goal is performance enhancement through ECS. However, scripting support becomes essential when using ECS as a complete replacement for game logic writing, particularly when there's heavy existing reliance on scripting without ECS access.
Three distinct paths emerge for scripting integration. The target audience for scripting must first be defined—whether artists, game designers, or those with varying technical knowledge levels who might use scripting for rapid prototyping.
The first approach hides all ECS patterns entirely, rebuilding them as an object-oriented model on the scripting side with direct one-to-one mapping of C++ ECS components to scripting components. Methods within these components can perform operations or execute logic. The benefit is that no new models are exposed, avoiding overwhelming current scripting system users. The drawback is the inability to achieve ECS flexibility.
The second approach exposes all ECS patterns on the scripting side, revealing not only components but also systems and queries. This allows writing systems that find appropriate components and entities to perform operations. While ECS performance cannot be achieved through scripting due to lack of caching compatibility and multithreading support, flexibility is gained through the ability to extend logic by overriding additional systems.
The third approach uses a hybrid scripting model where all ECS patterns are exposed for system writing, while still allowing additional logic within components. This mixed approach is less verbose and acknowledges that scripts often serve to write additional setup for particular game states, where writing systems for each exceptional case would be impractical.
The hybrid model includes conditions like "on entering the world," "on leaving the world," ways to respond to component calls, and "on tick" functionality. While not purely ECS, this approach remains less verbose and provides practical flexibility.
Two approaches exist for composition tools. Integration into existing component editors is possible when component templates and editors already exist. Alternatively, a completely new editor flow can be introduced.
From an artist's perspective, there is no fundamental difference between ECS and non-ECS component models. Adding a component remains the same process regardless of the underlying system. Background systems contain logic, but artists interact only with components.
If representatives are assigned to entities in the background, the system can determine whether a component is an old representative type (added to the representative) or a new ECS component (added to the ECS counterpart). This approach fails when the editor lacks component model support or when working with actor-only models without component support.
When introducing new authoring tools, greater freedom in implementation is gained, allowing for more modern and beautiful interfaces. However, this creates a different compositional flow requiring artists to learn when to follow new versus old workflows.
The launch phase determines overall success, with each stage requiring usable results and verification methods. Without proper offering processes, success cannot be achieved.
The first phase may not involve the ECS system itself, potentially introducing only authoring tools such as editor edits without programming background. This allows testing whether artists understand drastically changed workflows and provides intermediate layers preserving data from new authoring tools in old formats, avoiding modifications to distributed binary files.
The second phase introduces the ECS system core along with world integration. This tests whether transferred logic functions correctly without writing new logic, performing software regression testing to ensure ECS core compatibility with existing engine systems.
The third phase involves testing visual aesthetics features that enhance game appeal without breaking complex gameplay subsystems. These features can be disabled if necessary. The purpose is testing the workflow of new authoring tools with the ECS core, verifying that artists produce content correctly and engineers implement features properly.
The final phase introduces gameplay features including network integration and complex gameplay features with long-term consequences. This performs full stress testing on all previously applied components.
ECS can be integrated into existing engines, though it requires more effort than building from scratch. The integration process is noticeable but possible. The "everything from nothing" approach should be avoided, as waiting for complete engine rewrites before release will never succeed.
Complete elimination of the old approach is unlikely and unnecessary. The process represents gradual evolution toward a new model, allowing stops at any point or decisions to invest additional resources for improved efficiency and scalability.
Existing external engines like Unreal, Unity, and Godot have their own ECS integrations. Unity has the DOTS package, while Unreal has the Mass Entity package. Both face similar problems described in the presentation, where features from the current Actor world cannot be found in their respective ECS systems.
New engines developed from scratch or existing ones have begun gradually incorporating ECS systems. Extra efforts are required to maintain multiple representations, confirming that integration is possible but not free.
Survey results indicate most people use object-oriented programming, some use ECS, and a fair number take hybrid approaches. For new engine development from scratch, adhering to the ECS approach in its essence is strongly recommended. An ECS core can always be wrapped in more object-oriented approaches later if needed.
ECS deals with batch processing of objects and sets specific standards for this method of writing, being more beneficial for modern infrastructure. For existing engines that cannot be completely rewritten, hybrid approaches similar to those described are necessary.
While performance is commonly cited as the primary ECS reason due to more convenient and multiprocessable codebase organization, architectural benefits include more flexible game architecture through changed thinking patterns. Scenes are composed of components, with logic written by inquiring about entities matching certain criteria.
This provides an additional layer of scalability in logic writing. In hybrid approaches, architectural benefits are gained first since performance gains are more difficult to achieve. Subsystems written entirely in ECS provide high performance, while intermediate data situations vary.
Scripts can be written using the ECS model, gaining flexibility without performance benefits. Ironically, programmers historically tended to write manager patterns that wrap objects and perform operations, essentially attempting to write ECS-like patterns without ECS.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
