The Problem with Existing Engines
When we started building Gamingar, the first question wasn't "which engine should we use?" It was "do any of these engines actually solve what we're trying to do?" The answer, after weeks of prototyping, was no.
Existing game engines are built around a set of assumptions that made sense in 2010: input is binary, rendering pipelines are fixed, and the game loop runs at a constant tick. Gamingar needed something different — an engine that treats input as a continuous signal, not a discrete event.
The Technical Challenge
The core innovation in the Gamingar engine is what we call Adaptive Input Resolution (AIR). Instead of mapping button presses to actions, AIR treats every input device as a stream of state data. The engine then runs a small inference model on that stream to determine intent.
This sounds expensive. In practice, the inference model is small enough to run at 4000Hz on commodity hardware — fast enough that the player never perceives it as latency.
What We Learned
The biggest lesson from building Gamingar's engine was that performance comes from architecture, not optimization. We spent the first six months getting the architecture right. The last three months were spent making sure we hadn't broken anything. The optimization happened mostly for free, as a consequence of the architecture we'd chosen.