Powering Play: DeHub's Custom Mobile Game Engine
By DeHub Team — 2022-01-05
In Q1 2022 we built a custom game engine optimised for mobile devices.
"We wrote our own engine" is usually a warning sign. Unity and Unreal exist, they are extraordinary pieces of software, and most teams who reject them are solving a problem they invented. So the burden of explanation sits with us.
The actual constraint
Our games do not run as standalone installs. They run inside the DeHub app, which is React Native, already carrying a video pipeline, a feed, and a wallet stack — on phones that in a large part of our audience are several years old.
That combination is the problem. Embedding a general-purpose engine into an app like that means shipping a large runtime alongside everything already there, paying its startup cost every time somebody taps a game, and fighting it for the graphics context our video player also wants.
For a title you download and launch on its own, none of that matters. For five games that have to open from a tap inside a social app in under a second, all of it does.
What we optimised for
The engine was built around a short list of properties, none of which are impressive in isolation:
- Near-instant start. A game in an arcade competes with scrolling. If it takes five seconds to load, it loses to the feed permanently.
- Small footprint per title. Adding a game should add a game, not another runtime.
- Predictable behaviour on old hardware. Consistent frame pacing on a four-year-old midrange Android mattered far more to us than what the engine could do on a flagship.
- Native access to the wallet and account layer without a bridge between two worlds that each think they own the main loop.
That last one is the piece nobody sees. Arcade titles need to read an identity and write a score that lands on-chain. Doing that across an engine boundary is a permanent source of friction.
What it cost
Everything a general engine gives you free, we did not have. No mature editor, no asset pipeline, no third-party plugin ecosystem, no large pool of developers who already know the tooling.
That is a real and continuing tax, and it is the reason this is not general advice. We took it because the alternative was worse for our specific case, not because building an engine is clever.
Whether it was right
Mostly yes, with one caveat.
The arcade shipped five titles in a quarter and games opened fast enough to compete with the feed, which is the outcome the whole exercise was for. Later titles landed without re-architecture. On old hardware — where a lot of our audience actually is — it behaved.
The caveat is talent. Every developer who works on our games learns a system that exists nowhere else, and that has slowed hiring in a way we underestimated in 2022. If we were choosing again with the same constraints we would probably make the same call, and we would budget for that cost honestly rather than discovering it.
The test we would apply
The question is not "could we build our own?" — a competent team can build almost anything and that is why the question is useless.
It is: can you name the specific property you need that the off-the-shelf option cannot give you, in one sentence, without using the words flexibility or control?
Ours was that a game had to open from a tap inside a React Native social app, in under a second, on a four-year-old midrange Android, while a video pipeline was already resident. That is a real constraint with a real number in it.
If the answer is vaguer than that, the honest conclusion is that you want to build an engine, which is a different thing from needing one — and considerably more expensive than it looks from the first title.