Dinodash: From Native C++ Game Engine to Web-Deployed System
How I built a multi-runtime system that compiles a native game engine to WebAssembly and runs in the browser.
Dinodash started as a low-level systems project: a real-time 2D game engine written in C++ using Raylib. The goal was to explore performance-aware graphics rendering, game loops, physics simulation, and state management.
Over time, it evolved into a multi-repo system spanning native execution, web deployment, and platform adaptation. It transformed a local desktop game into a browser-accessible interactive application.
Project Structure
Dinodash
Core C++ game engine (native runtime)
Dinodash-web
WebAssembly compilation + runtime bridge
Dinodash-play
Deployment, hosting, and browser integration
The Engineering Problem
Rather than treating this as "just a game project," I approached it as a systems engineering challenge:
How do you take a performance-sensitive native application and re-architect it for a fundamentally different runtime model (the browser) without losing determinism, performance guarantees, or structural clarity?
Core Engine Architecture
At the base is a traditional real-time engine with deliberate constraints:
Deterministic game loop
Consistent behavior across frames
Delta-time physics
Frame-rate independent simulation
Event-driven input
Responsive controls without polling
Separated render pipeline
Logic decoupled from visuals
The engine is data-oriented and minimal. There are no unnecessary abstractions and no deep object hierarchies. Logic is explicit, debuggable, and deterministic. This predictability becomes critical when porting to the web.
The Browser Challenge
The browser is not a native environment. It imposes fundamental constraints:
- No direct system-level access
- No native threading model
- Event loop owned by the browser
- Rendering mediated through Web APIs
This is where the architecture shifts from "game dev" to systems translation.
The Migration Strategy
Instead of rewriting the game in JavaScript, I used compilation + adaptation, not reimplementation.
Same engine, same logic, same determinism. Just a different transport layer. This avoided logic divergence and ensured identical gameplay semantics across native and web runtimes.
The largest challenge was preserving frame pacing and input responsiveness under the browser's event-driven loop.
Design Principles
Engine Authority
The game engine remains the authoritative system. The browser is just a host, so there is no logic duplication across runtimes.
Determinism First
Fixed update patterns, consistent state transitions, no browser-driven logic ownership.
Platform as Adapter
Treat the platform as an adapter layer, not a rewrite target. Code structured for migration, not lock-in.
Technical Takeaways
Dinodash reflects a simple philosophy:
"Build systems that survive environment changes."
Structure first. Systems second. Platform last.