Flagship case study
Open1320 Legends: Rebuilding a Dead Platform
Open1320 Legends — a ground-up remake of the Nitto 1320 Legends racing game. It isn't a product we sell. It's the largest working example of the kind of technical rebuild we take on.
The situation
A dead platform holding a live community
The original game ran on Flash. When browser support ended, the game went with it: the client was unplayable, the logic lived inside compiled SWF files, and most of the rules that defined the game were undocumented. Everything that mattered — car data, parts, tuning behaviour, race outcomes — had to be recovered before anything could be rebuilt.
The rebuild moved gameplay authority to the server, rebuilt content as structured data, and replaced client trust with validation. That's the same work an old business system needs: understand it, extract it, rebuild it on something that will still run in five years.
Timeline
How the rebuild happened
From a dead runtime to a live, operated platform — in the order the work actually landed.
Phase 00
The platform goes dark
Browser Flash support ends and the original game becomes unplayable overnight. The rules, formulas, and content only exist inside compiled SWF files, with a live community and no working client.
Phase 01
Decompilation and protocol recovery
SWF assets and ActionScript are decompiled and read line by line. Live traffic is captured and decoded until the undocumented client/server protocol is reconstructed and written down for the first time.
Phase 02
First authoritative server
A Node.js server takes over accounts, sessions, and gameplay authority. The client stops being trusted: every meaningful action is validated server-side before it counts.
Phase 03
Data rebuild and migration
Cars, parts, tunes, and compatibility rules are normalized into a real schema with validation and duplicate detection, and legacy player data is migrated with verification passes on both sides.
Phase 04
First live races
Lobby, rooms, staging, launch, and run scoring come online together. Deterministic race simulation means the same inputs produce the same result and every outcome can be audited from logs.
Phase 05
Tooling and telemetry
Dyno and tuning surfaces, run telemetry, packet inspection, admin panels, and regression harnesses ship so the system can be tuned and debugged with data instead of guesswork.
Phase 06
Live operation
The platform runs in production: Ubuntu VPS, reverse proxy, SSL, backups, supervision, monitoring, and a release process with a test pass in front of every build.
Deliverables
What was actually built
The shipped work, grouped by the layer of the system it belongs to.
Client
- Rebuilt client architecture on a modern runtime
- Lobby, garage, shop, and race HUD interfaces
- Re-packed and cleaned legacy art assets
- Input, timing, and shift handling
Backend
- Authoritative Node.js game server
- Accounts, sessions, and authentication
- Matchmaking, race results, and persistence
- Economy: currency sinks, sources, and pricing
Networking
- Reconstructed client/server protocol
- TCP socket framing and message versioning
- Reconnect and disconnect handling
- State synchronization and reconciliation
Tooling
- Live packet capture and decoding
- Run telemetry and timing splits
- Dyno and tuning validation surfaces
- Admin panels and regression harnesses
Modernization
- SWF decompilation and AS2/AS3 analysis
- Recovered game rules and physics behavior
- Legacy data migration into a normalized schema
- Protocol and system documentation written from scratch
Screens
Inside the rebuild
A few screens from the running system — lobby, staging, race HUD, parts economy, and dyno.
Head-to-head lobby with team/individual brackets and live chat.
Pre-stage tree, dial-ins, and staged state driven by server-authoritative race logic.
In-race HUD: tachometer, gear, boost, and traction control instrumentation.
Structured parts catalog with pricing, power, torque, and weight validation.
Deterministic dyno output — same tune, same curve, every run.
What it proves
Capabilities demonstrated
Each of these is a service we offer, applied at scale on one project.
Legacy systems
Decoded and catalogued Flash-era SWF content, mapped undocumented game rules, and rebuilt them on a maintainable stack.
Backend & Node.js
Accounts, sessions, matchmaking, race results, and persistence handled server-side with a normalized database behind it.
Deterministic simulation
Race physics run server-authoritative and reproducible, so the same inputs always produce the same result and outcomes can be audited.
Game economy
Currency sinks and sources, part pricing, rewards, and progression tuned with data instead of guesswork.
Content databases
Cars, parts, tunes, and compatibility rules stored as structured data with validation and duplicate detection.
Admin & CMS tools
Internal panels for editing content, inspecting players, correcting data, and shipping changes without a deploy.
Graphics pipeline
Old raster and vector assets extracted, cleaned, upscaled, and re-packed into a consistent modern render pipeline.
AI-assisted content
AI used in the asset and copy pipeline where it saves real hours, with human review before anything ships.
Server operations
Ubuntu VPS, reverse proxy, SSL, process supervision, backups, log access, and restart-on-crash.
Security hardening
Server-side validation of every gameplay action, rate limiting, and closing the trust gaps a client-driven original left open.
Transferable
Same work, different industry
Swap cars for products and race results for orders, and it's the system your business runs on.
Item database
Product or parts catalog with validation
Economy logic
Pricing, credits, and billing rules
Admin tooling
Staff panels for non-technical users
Server ops
Deployment, backups, and monitoring