Rebuilding Ten Legacy Slot Games on a Reusable HTML5 Engine
I independently recreated ten legacy C++ slot titles as playable desktop-browser proofs of concept, building a reusable HTML5/CreateJS engine that made nine titles repeatable and a tenth deeply customizable.
NexGaming had a collection of older slot games originally built in C++. The titles still had value, but the original technology limited where they could run and how easily they could evolve. The company’s owner asked me to prove whether those games could be given new life in a browser. The real question was not whether I could reproduce one screen. It was whether I could rebuild the behavior of multiple legacy titles through a reusable platform instead of creating a separate one-off port for every game.
The proof of concept at a glance
Nine titles proved reuse. A tenth proved extensibility.
The diagrams use fictional game labels and abstract symbols. No proprietary artwork, title names, payout tables, or mathematical parameters are reproduced.
Platform result
One browser platform supported ten playable legacy-game recreations
Repeatable core pattern
Advanced customization
- Custom bonus round
- Wild and free-spin logic
- Layered effects
- Expanded game-specific UI
Reusable architecture
Shared runtime below, title-specific behavior above
Launch a fresh game instance from the standalone menu.
EaselJS · TweenJS · SoundJS · PreloadJS
Proof-of-concept progression
The architecture investment paid forward as the pattern became reusable
Behavioral discovery, engine design, extension points, and mathematical tuning.
Reuse the common runtime while concentrating on configuration, assets, and rules.
Deliver another batch without rebuilding the platform around every title.
Add specialized mechanics and richer effects while retaining the underlying architecture.
Manual behavioral validation
Recreate the observable behavior, then compare it side by side
Each browser version was checked against the running C++ original rather than treated as a line-by-line code translation.
Animation remained prototype-grade; the engine, calculations, and playable game loop were the feasibility target.
The impact path
Inherited
NexGaming had older C++ slot titles with valuable gameplay and artwork, but their original technology limited support for newer platforms.
Owned
I studied the original C++ source, assets, and running games, then designed a browser-native architecture from scratch rather than attempting a mechanical code conversion.
Changed
I ran the original C++ game and its HTML5 recreation on separate monitors, comparing reel stops, timing, game states, wagers, paylines, payouts, and visible behavior until the proof of concept matched convincingly.
Result
10 — Playable browser proofs of concept
What I inherited
The problem and the reality around it
The problem
- NexGaming had older C++ slot titles with valuable gameplay and artwork, but their original technology limited support for newer platforms.
- C++ and browser JavaScript could not be translated line by line, so each game’s behavior had to be observed, understood, and recreated for a different runtime.
- The titles shared important mechanics, but their assets, reel specifications, paylines, payout behavior, and specialized features varied enough that one-off ports would create repeated work.
The constraints
- The immediate goal was a desktop-browser proof of concept rather than a production or real-money release.
- Credits were simulated within each playable prototype and reset with the game session.
- Artwork and animations were reconstructed for functional validation while a possible professional remastering phase was being explored.
- Individual game names, identifying artwork, sounds, payout tables, exact mathematical parameters, and the owner’s identity remain excluded.
What I owned
My responsibility in the work
I studied the original C++ source, assets, and running games, then designed a browser-native architecture from scratch rather than attempting a mechanical code conversion.
I created the reusable engine and standardized extension points for title-specific JavaScript configuration, assets, paylines, payouts, and custom behavior.
I implemented the core game loop across reel behavior, weighted symbol selection, game states, wager deductions, payline evaluation, payouts, credit updates, loading, rendering, sound, and event flow.
I cleaned, resized, converted, rebuilt, and recreated prototype artwork and animation assets so each title could run coherently in the browser.
I validated the recreations manually against the original games and demonstrated the completed browser library to the company’s owner.
How I approached it
Decisions, tradeoffs, and delivery
There was no practical line-by-line translation from the C++ applications to HTML5 and JavaScript. I used the original source, assets, and running games as evidence, then recreated their behavior through a browser-native engine built on CreateJS. The engine owned the common runtime: reel behavior, weighted symbol selection, game states, asset loading, animation and event flow, simulated wager and credit transactions, payline scaffolding, evaluation, and payout processing. Each title supplied JavaScript configuration and custom logic for its unique symbols, dimensions, paylines, payout specifications, sounds, artwork, and specialized rules. That separation allowed the games to remain distinct without repeating the entire runtime.
- I ran the original C++ game and its HTML5 recreation on separate monitors, comparing reel stops, timing, game states, wagers, paylines, payouts, and visible behavior until the proof of concept matched convincingly.
- I customized and extended CreateJS across canvas rendering, sprite and reel animation, asset preloading, sound, tween sequencing, and event handling.
- I separated common runtime behavior from per-title JavaScript packages so each game could plug its unique configuration and logic into predictable engine hooks.
- The first three games absorbed almost six months of architecture and pattern discovery; the next six were completed as two batches of three once the reusable foundation stabilized.
- I then extended the same underlying architecture for a tenth title with a specialized bonus round, wild and free-spin logic, richer effects, custom animation controllers, and expanded game-specific interfaces.
- I prioritized playable mechanics and mathematical correctness over final animation polish because the project’s purpose was proving feasibility before a professional design phase.
How I led
The team and stakeholder system
I owned the project end to end as NexGaming’s hands-on Director of Engineering. I reconstructed and adapted prototype assets, extended CreateJS where the engine required more control, and validated the browser versions manually by running each recreation beside its C++ original on a second monitor. The first three games consumed almost six months because they carried the architecture and pattern-discovery work. Once those interfaces stabilized, the next six became much easier to add as two batches of three. I then used a tenth, more specialized game to test the limits of the architecture with a custom bonus round, wild and free-spin behavior, richer effects, expanded interfaces, and title-specific animation controllers.
Results
What changed
10
Playable browser proofs of concept
Ten legacy titles reached a playable desktop-browser state with simulated wagering, payline evaluation, payouts, and title-specific behavior. · My contribution
9 + 1
Reuse and extensibility demonstrated
Nine titles established the repeatable engine pattern, while the tenth proved the same architecture could support substantially deeper customization. · My contribution
8 months
Solo feasibility delivery
I moved from observation and architecture through ten playable demonstrations during the final NexGaming project. · My contribution
Leadership evidence
How I moved the people system
- — I independently carried an ambiguous prove-it-can-be-done request from feasibility question through a coherent multi-title demonstration.
- — I made the proof-of-concept boundary explicit, prioritizing the engine, game mathematics, and extensibility while deferring production-grade visual polish to the planned professional design phase.
- — I designed the work so the tenth title could add specialized behavior without discarding the foundation established by the first nine.
- — I balanced technical architecture, mathematical correctness, asset reconstruction, creative experimentation, and stakeholder demonstration as one end-to-end responsibility.
Technical evidence
How I moved the product system
- — A shared browser engine for reels, state, weighted outcomes, wager and credit flow, payline scaffolding, payout processing, loading, rendering, sound, and events.
- — Per-title JavaScript configuration and custom logic connected through standardized hooks for the behavior that legitimately differed between games.
- — Direct CreateJS customization across EaselJS, TweenJS, SoundJS, and PreloadJS rather than reliance on a rigid game framework.
- — A tenth customized title extending the underlying architecture with bonus mechanics, wilds, free spins, layered effects, specialized animation controllers, and additional UI flows.
- — Side-by-side behavioral validation against the running C++ originals while the browser architecture remained independently designed.
Technical footprint
Technologies and system areas
What I took from it
The lesson I carry forward
The owner passed away before the planned professional artwork, animation, and production phase could begin, bringing both the project and my time at NexGaming to an unexpected close. It was a bittersweet ending to one of the most creative and technically ambitious projects of my career, but the proof of concept had answered the question we set out to solve: the legacy games could be modernized through a reusable, extensible browser engine. The first nine proved repeatability. The tenth proved the architecture could bend without breaking.
Related work · Architecture