Doorcrash!

I implemented the bike as a physics vehicle on top of Unreal Engine’s Chaos vehicle plugin:

• letting Chaos handle wheel simulation, traction and basic steering/braking

• while my code coordinates behaviour from game logic.

Player inputs are bound through Enhanced Input and forwarded into the Chaos movement component (steer, throttle, brake):

• then shaped further using custom steering/throttle/brake input curves defined in the vehicle’s Blueprint movement component

• so responsiveness can be tuned without touching C++.

On top of that, I layer control logic that, per-frame:

• reads the current velocity, angular velocity and wheel contact

• and uses that to drive systems like a roll controller (different max roll angles when grounded vs airborne allow the bike to lean)

• and a post-physics follow camera.

The camera:

• uses the final simulated transform of the bike

• supports free-look yaw/pitch with clamped offsets and deadzones

• and smoothly recenters and adjusts pitch/boom height based on slope and air state

• so the high-frequency physics motion stays readable and cinematic.

On top of the raw Chaos behaviour I built the high-level driving mechanics: drifting and air control.

Drifting

• For drifting, I modify per-wheel friction multipliers on the rear and front tyres, apply a small sideways impulse and yaw torque when the player hits drift, then every frame compute the slip angle between the bike’s forward/right vectors and its actual velocity.

• That slip angle, combined with steering input and yaw rate, feeds into forces and torques that try to hold a target slip angle, add stabilising counter-torque, and apply a controllable forward boost, all scaled with a frame-rate compensation factor so tuning is stable across different FPS.

Air control

• For air control, I use downward traces from helper “wheel probe” components to measure ground distance and local slope; once both wheels have been above a threshold distance for a short unlock time, I treat the vehicle as airborne and repurpose the same throttle/brake/steer inputs to add extra forward/lateral forces and pitch/yaw torques around a stored “center” heading, allowing the player to subtly adjust attitude mid-air while Chaos continues to simulate the rigid body underneath.

Tuning & design

• All of these systems expose their key parameters (forces, friction scales, thresholds, timing, camera behaviour) as editable properties, so designers can iterate on handling and feel directly in Blueprint without needing code changes.

I built a data-driven quest system around a world subsystem that owns all the logic for offering, starting and completing “restaurant delivery” quests:

• Quest definitions live in DataTables referenced by a registry asset that maps each restaurant tag to its table, so designers author quests as rows instead of code: each row defines the restaurant, difficulty, time limit, reward, allowed delivery zones, special rules and the UI text/images to show.

• At startup the subsystem loads these tables into a cache, scans the level for quest node actors (pickup and delivery points with sphere triggers, tags and row IDs), and builds lookup maps from restaurant to pickup node and from zone to delivery nodes.

• Each node can be activated or deactivated centrally by the subsystem, which flips collision and visibility and also pushes difficulty or “role” information to Blueprints so they can react visually.

The runtime flow is handled by a small state machine that moves between three phases: an idle phase (no active quest), an offer phase (showing available quests), and a delivery phase (one quest in progress).

• When entering the offer phase, the subsystem filters quest rows against a cooldown history, validates that each candidate has a usable pickup node and at least one valid delivery location, then groups and samples them so only a limited number of restaurants are “on offer” at once; only those pickup nodes are activated in the world.

• It exposes helpers to sort or step through the current offers by distance, construct lightweight “offer views” and “active quest views” for UI (name, distance, reward, time limit, difficulty, images), and continuously update them via multicast delegates and a ticking timer so widgets can stay in sync.

• When the player overlaps a pickup node, the subsystem resolves the matching row, selects an appropriate delivery node (using allowed zones or explicit links), transitions into the delivery phase, activates only that delivery, and starts a countdown.

• Reaching the delivery completes the quest with a “delivered” reason; expiring the timer completes it with a “failed” reason.

• In both cases it broadcasts a structured summary of what happened and records the quest on a rolling cooldown so the same content doesn’t immediately reappear.

I integrated Unreal Engine’s Mass-based traffic and crowd systems into the project by first reverse-engineering how they’re set up in Epic’s Matrix City tech demo:

• I went through the Mass traffic and crowd configurations, data assets and processors to understand how cars and pedestrians are spawned, updated and culled around the player.

• I then recreated a stripped-down version tailored to our world layout and performance budget.

• That includes setting up traffic paths and spawn areas, configuring crowd/vehicle archetypes, and wiring them into our game’s level so they appear only where and when we need them.

In practice this gives us large numbers of lightweight AI vehicles and pedestrians driven by Mass instead of traditional per-actor AI:

• Traffic density, speed ranges and lane usage, as well as how busy different areas feel, are all controlled through data and editor settings so designers can tune the simulation without touching code.

• The result is a scalable background simulation that makes the city feel alive around the player’s bike and quest systems, while remaining cheap enough to coexist with our physics-heavy gameplay.