Engineering case study / Modernizing a browser-based WebAssembly game runtime
Diablo Web
A compatibility and architecture modernization of existing open-source browser and game-engine work, with typed runtime orchestration around WebAssembly, workers, canvas and browser storage.
Context
This project builds on existing open-source browser ports and game-engine work. My work focuses on modernizing the web application layer and extending how the runtime is integrated, validated and delivered.
Problem
Coordinate a stateful WebAssembly runtime, asset loading, browser persistence, canvas rendering and worker messages without allowing engine details to leak through the whole React application.
Constraints
- The engine and original game assets are upstream work and are not owned by this project.
- Long-running runtime work must not block the browser UI thread.
- Legacy data formats and browser compatibility shape the integration boundary.
My contribution
Frontend modernization, runtime boundaries, protocol validation, tests and delivery.
System boundaries
Architecture
Lifecycle, controls and user-visible state
→Initialization, storage and asset sequencing
→Validated messages and off-main-thread execution
→Upstream engine execution and rendered output
Important technical decisions
- Worker protocol validation rejects malformed or out-of-order messages.
- Runtime orchestration is isolated from presentational React components.
- Vite replaces older delivery tooling while retaining required WebAssembly behavior.
- Browser storage and MPQ loading are treated as explicit runtime services.
Testing and quality
- Automated tests cover web-layer behavior.
- CI checks changes and deployment readiness.
- Typed protocols reduce integration ambiguity.
Results
- Modern React and TypeScript application shell
- Explicit worker and runtime boundaries
- Public browser demo with documented upstream attribution
Trade-offs and limitations
- Browser execution remains constrained by upstream engine and asset compatibility.
- Canvas output is not a conventional accessible DOM interface.
- The integration prioritizes compatibility over rewriting upstream engine internals.
Alternatives considered
- A full engine rewrite was out of scope and would erase the value of the upstream work.
- Main-thread execution was avoided because runtime work could compromise interface responsiveness.
Current status
Functional public modernization project. Diablo, its assets and the original engine remain the property of their respective owners and contributors.