GAME DEVELOPMENT
Neon Chaser
A neon-noir drift racer where physics-based driving meets high-speed chases and vehicle combat.
- UNITY
- C#
- GAMEPLAY SYSTEMS
- QA
- PERSISTENCE
- AI
- DESIGN
- TECHNICAL DOCUMENTATION
- ROLE
- Game Developer
- TEAM
- 2 Developers
- ENGINE
- Unity
- LANGUAGE
- C#
- PLATFORM
- PC
- STATUS
- In Development
The Game
Neon Chaser is a neon-noir drift racing game built around physics-based driving, vehicle combat, and power-ups that can dramatically change the course of a race.
The gameplay combines vehicle handling and drifting with offensive, defensive, and disruptive abilities. A race can shift from a straight fight for position into a physics-driven encounter involving rockets, gunfire, oil-covered track surfaces, speed boosts, and stolen momentum.
See Neon Chaser in motion
My Contribution
My work on Neon Chaser has focused heavily on gameplay systems and persistence. I developed and evolved the game's power-up architecture and its current set of five abilities, worked extensively on save/load functionality, contributed to full level implementation, calibrated vehicle behavior, and worked on runtime AI calibration that allows computer-controlled racers to respond to changes in vehicle capability.
The sections below focus on the engineering systems rather than providing a complete feature-by-feature development log.
Five Power-Ups, One System
Very different mechanics needed to behave like parts of the same game system.
Speed / Mobility
NITRO
Temporarily gives the player's vehicle a significant burst of speed.
Combat / Debuff
MACHINE GUN TURRET
Fires at an opponent's vehicle and applies a slowdown effect.
Projectile / Physics
ROCKET LAUNCHER
Launches rockets at opponents, with successful hits physically lifting the affected vehicle into the air.
Track Hazard / Grip
OIL SPILL
Leaves a trail of oil behind the vehicle. Cars driving through it lose traction and begin to slide.
Disruption / Stat Transfer
OP HACK
Targets the vehicle ahead, steals speed from it, and transfers that advantage to the player.
ENGINEERING DEEP DIVE 01
Five abilities, one gameplay architecture
The challenge was not simply implementing five separate effects. Nitro modifies the player's own vehicle. The turret targets another racer and applies a temporary debuff. Rockets introduce projectiles and physics interaction. Oil creates hazards that remain on the track after deployment. OP Hack modifies both the user and another vehicle.
They still needed to participate in one consistent acquisition, activation, depletion, and removal system.
Architecture facts
- All five power-up behaviours inherit from an abstract MonoBehaviour.
- PowerupController manages the currently held power-up and works with PowerupBehaviour polymorphically.
- One power-up is held at a time, but some vehicles can have multiple physical mounts coordinated under the same power-up.
- The implementation uses serialized component data rather than a shared power-up-definition ScriptableObject.
Keeping the vehicle independent of individual abilities
PowerupController works with the shared PowerupBehaviour abstraction rather than containing a separate implementation branch for Nitro, Oil Spill, Rocket Launcher, and every other ability.
That keeps acquisition, charge management, activation, removal, and UI events separate from the mechanics of an individual power-up.
Stat-based effects use runtime modifiers that can be added and removed by source, allowing vehicle systems to consume the resulting values without needing to understand which power-up produced them.
This separation is deliberately practical rather than absolute. Some systems still require weapon-specific coordination, particularly when working with physical mounts and effects that interact directly with rigidbodies or wheel friction.
Shared lifecycle, effect-specific cleanup
One of the important design boundaries is cleanup.
A shared controller can decide that a power-up has been lost or exhausted, but it cannot know everything that a particular effect changed.
Nitro must remove its vehicle modifiers and stop its effects. OP Hack must clean up modifications on both the user and target. Weapon debuffs can expire independently. Oil stops spawning when the ability ends, while slicks already placed in the world continue through their own lifetime. Projectiles remove themselves after impact or expiry.
The shared architecture therefore owns the power-up lifecycle, while individual effects remain responsible for cleaning up the resources and state they create.
That balance keeps the common API useful without forcing five fundamentally different mechanics into one oversized implementation.
ENGINEERING DEEP DIVE 02
Persist the progression, not the simulation
A racing game contains a large amount of runtime state, but most of it should not survive after a race or application session ends.
Neon Chaser's persistence system focuses on the state that represents the player's longer-term progression and configuration.
Persist
- Owned / unlocked vehicles
- Selected vehicle
- Currency
- Completed-level progression
- Supported preferences
- Vehicle upgrades
- Equipped upgrade tiers
- Paints
- Visual customization
- Owned / enabled customization options
Runtime
- Live race position
- Velocity
- Checkpoints
- Held power-up
- Power-up ammunition
- Detailed live race state
ENGINEERING DEEP DIVE 03
A save system designed to fail safely
Saving progression creates a different engineering problem from saving it successfully once: what happens when something goes wrong during the write or the next time the game attempts to load?
Neon Chaser uses JSON files stored under Unity's persistent data path. The system maintains both a primary save and a backup and writes through a temporary file before moving the completed data into place.
Write
- 01Runtime State
- 02Serialize JSON
- 03Temporary File
- 04Backup Existing Save
- 05Replace Main Save
Load
- 01Primary Save
- 02Valid?
- 03Yes -> Load
- 04No -> Backup Save
- 05Backup valid?
- 06Yes -> Recover
- 07No -> Safe Defaults
If the primary file is missing, empty, or unreadable, the loader attempts the backup. A successful backup can be used to restore the main save. If neither can be loaded, the game continues using fresh-session defaults instead of preventing the player from starting.
Fallback behavior also handles cases such as missing vehicle builds or vehicle selections that no longer resolve cleanly against the available catalog.
Persistence is therefore treated as a recovery problem, not only a serialization problem.
ENGINEERING REFLECTION
Where the persistence system can evolve next
The current save schema contains a version field, but it does not yet have a generalized migration pipeline for older save structures. Compatibility is currently handled through defaults, null checking, fallbacks, and targeted filtering.
As the game and its persistent data continue to evolve, explicit version-based migrations would provide a stronger path for handling structural changes such as renamed identifiers, changing progression data, or evolving customization schemas.
This is an area where the current implementation is intentionally practical, but where the needs of a longer-lived production game could justify additional infrastructure.
See Neon Chaser in action
Neon Chaser continues to bring together physics-based racing, vehicle combat, gameplay systems, persistence, adaptive AI, and level development inside one evolving Unity project.