When discussing a new feature, I often start with a simple question that turns out to be less obvious than it sounds:
What exactly are we trying to verify?
Sometimes it turns out that we’re testing functionality provided by a platform, a third-party library, or a framework rather than our own system.
In game development, it is useful to make sure the team does not accidentally start testing Unity itself instead of the game built on top of it.
Things become more interesting when a company uses its own game engine.
Because the engine and the game do not always remain independent systems. In some cases, one simply cannot exist without the other.
At some point, you realize that part of your game tests are not actually testing the game. They are testing the platform underneath it.
This observation made me look at custom game engines from a different perspective.
When the Engine Becomes Part of the Game
In an ideal world, the engine and the game are separate systems.
The game can evolve independently from the engine, and the engine can evolve independently from a specific game.
In practice, this is not always the case.
I’ve worked on projects where the only way to validate engine behavior was through the game itself.
When that happens:
- engine defects appear as game defects;
- game tests start acting as platform tests;
- regression becomes more expensive;
- root cause analysis becomes harder.
As a result, new engine versions become difficult and painful to release. Significant effort from the game team may be required just to integrate and validate changes.
In many cases, this can be traced back to the fact that the platform and the game were not designed as independent systems from the beginning. As a result, both the engine and the game become harder to test.
The Problem Is Not the Runtime
When people discuss game engines, the conversation usually focuses on:
- graphics;
- performance;
- physics;
- networking.
But from an engineering perspective, these are only part of the picture.
An equally important question is:
How easy will it be to work with this system in five years?
Modern game engines provide much more than a runtime.
They come with an entire ecosystem:
- development tools;
- profilers;
- diagnostics;
- documentation;
- CI/CD integrations;
- testing frameworks.
For example, Unity provides the Unity Test Framework with support for both Edit Mode and Play Mode tests. Unreal comes with its own set of tools as well.
When a company builds its own engine, this ecosystem does not automatically exist. And maintaining it at the same level requires significant investment.
Conclusion
When evaluating a custom engine, it is useful to ask more than just:
How powerful is our engine today?
Another question is just as important:
Do we have an ecosystem that allows us to efficiently develop and test games, while also making future engine upgrades manageable?
The cost of a modern game engine is not limited to the runtime itself.
A large part of that cost lives in automation, testing, documentation, internal processes, and architectural decisions.
These things are rarely visible at the beginning of a project. Yet over time they consume years of engineering effort in testing, debugging complex issues, and maintaining the platform.