Eriast Derby

About the Project

A simulator for a D&D module centered around vehicular racing with combat. It follows a custom ruleset inspired by D&D 5e, but rebuilt heavily around modular vehicles, crew-operated subsystems, lane-based movement, and abstract combat.

The main point of the project is scale. The long-term goal is a tournament with roughly 50 vehicles across 40 stages, all running custom mechanics that would be an absolute nightmare to track manually. This simulator automates NPC vehicle behaviour so the Dungeon Master can focus on running the session, while the system handles all the calculations, targeting, status effects, action flow, AI decisions, and race-state management behind the scenes.

Architecturally, the project is built to support an arbitrary amount of future content without rewriting core logic. Skills, conditions, vehicles, components, stages, event cards, and AI behaviour can all be authored directly in the Unity editor. The hard part was not just implementing individual systems, but getting the domain model right in the first place.

The biggest challenge is that this is not a normal RPG combat model where everything is just "an entity". Here a vehicle is made of multiple targetable components, some of those components are crew-operated, the crew themselves are not directly targetable entities, and effects can still semantically apply to a specific component, a specific character, or the vehicle as a whole. Getting attacks, effects, checks, saves, modifiers, and conditions to route correctly across those layers was the single most difficult part of the entire project.

Why this project stands out

• Automates large-scale NPC behaviour for a rules-heavy vehicular combat system that would be wildly impractical to run by hand at the intended campaign scale.
• Built around a data-driven architecture so new skills, conditions, vehicles, components, stages, event cards, and AI content can be created directly in the Unity editor.
• Solves an unusually awkward targeting problem involving vehicles, modular components, crew-operated subsystems, and vehicle-wide effects all coexisting in the same combat model.
• Designed with observability in mind through detailed logging, monitoring panels, and stat breakdowns, which makes both debugging and session-running far more manageable.
• Backed by 300+ automated tests so major refactors can happen without flying blind.

The Hardest Problem to Solve

The most technically difficult part of the simulator was not AI, logging, or even the skill system. It was the underlying domain model.

In most RPG combat systems, everything important can just be treated as an entity. Here, a vehicle is made of multiple targetable components, some of those components are operated by characters, those characters are not directly targetable entities themselves, and effects still need to apply cleanly at different semantic levels.

For example:

• a burning effect might apply to one specific weapon component
• an inspired effect might apply to one crew member operating a seat
• a slowed effect might apply to the vehicle as a whole
• a generic attack against the vehicle might route to the chassis rather than a specific subsystem

That means the simulator has to support entities, collections of entities, vehicle-wide abstractions, and seat-controlled systems all at once, while still letting skills, effects, conditions, checks, and saves target the correct thing in a way that feels natural. Getting that routing and ownership model right was the part that gave me the biggest headache. So far...

Core Design Priorities

Rules Context

Racing and Movement

The race track is composed of discrete stages. The objective is to reach the finish line first, but the way is perilous and filled with hazards, and other teams will happily use their weapons to stop you.

Vehicle Construction

Players build their vehicles from modular components (eg. chassis, power core, drive, weapons, utilities) that can be damaged and destroyed independently. Each component has its own stats and contributes to overall vehicle performance.

Resource Management

Vehicles are powered by a finite energy resource that must be managed carefully, lest you find yourself stranded in the middle of the track with no power to accelerate or fire your weapons.

Crew System

Characters with D&D 5e-style attributes, skills, and proficiencies sit in vehicle seats operating an arbitrary combination of components. Covers both players and NPCs piloting the vehicles.

Turn-Based Abstract Combat (D20)

Attack rolls, skill checks, and saving throws without gridmap or positional movement - JRPG-style.

Lane Tactics

Each stage has multiple lanes with different tradeoffs that vehicles can move between. Lane choice affects route, speed, and triggers different checks, saves, and effects, giving each stage its own distinct identity.

Event Cards

Semi-random occurrences within stages that add flavour and unpredictability. Narrative events requiring skill checks and presenting choices, penalties, and rewards.

Architecture

The game mechanics are complex by necessity as they are meant to simulate a D&D experience that in regular circumstances would be run by a human DM with no technical limitations. This includes many complex and interlocking behaviours like conditional effects, changing state of environment, multi-vehicle rolls, and more. As such, strong architectural discipline is not vanity, but a necessity.

The architecture is designed to separate calculation logic from data and state management, while ensuring that all game rules like damage or skill checks pass through a single entry point and code duplication is minimized or preferably completely eliminated.

All game content like skills, stages, status effects, vehicles and components can be created and configured directly from the Unity editor, without looking at a single line of code. The point is not just convenience. It is what makes the whole simulator extensible enough to support a campaign-sized amount of content without turning every new mechanic into a programming task.

Core Systems

The sections below are the main systems carrying that complexity.

Skill Execution, Effects & Targeting

System for evaluating and executing skills and abilities. This can include attacks, buffs, debuffs or any combination composed of effects. Also includes the logic of skill checks, saving throws, opposed checks, stat threshold checks, and attack rolls, with more possibilities in the future.

A unified way of handling all kinds of common actions that happen in a D&D setting such as dealing damage, applying buffs, draining resources, etc. This allows code reuse across multiple sources of such actions like player skills or environmental effects (e.g., from event cards). Each effect in a skill can specify targeting rules. Those include the source, a target entity, the enemy vehicle as a whole, multiple targets, and more. This allows for configuration of complex skills like "damage the enemy while also applying a status effect to self." The entire pipeline is unified through a flexible effect system that allows for fully modular and composable skills and events that can be created and configured in the editor.

This system has been created to be as flexible and robust as possible letting the designers create a wide variety of skills. To prove my point, below is an example of a completely overcomplicated skill that pushes the limits of this system.

Conditions

Used for handling buffs, debuffs, damage over time and other behaviours common in games of this genre. Fully composable and modular using the effect system. Implemented as a Flyweight pattern with a template and runtime instances. Three separate ownership tiers exist - vehicle-wide, per-component, and per-character - all sharing the same stacking and lifecycle logic.

Vehicles, Components & Crew

Vehicles are composed of modular components, each with their own stats, health and functionality. This allows for creating any sort of vehicle for different playstyles and tradeoffs by choosing the components to include. Gives interesting tactical depth for the players while also giving an identity to the NPC vehicles. Also allows for progression as the players find or create better and more powerful components in the parallel D&D campaign.

The vehicles are meant to support any sort of crew configuration, be it a 5 player team with their own specialisations, or a single driver controlling everything. The seat system controls how many characters a vehicle can support and which components they operate. It also controls which character will be responsible for which skill check and saving throw via a dedicated routing class.

Turn Management & Phase Control

A state machine that controls the flow of the game and progression of the race on a turn-by-turn basis. Determines which vehicle goes next, when event cards are drawn, when status effects tick, and so on. The phase handling is deliberately extensible, so new turn phases can be added without having to rewrite the rest of the turn engine.

NPC AI System

Every NPC vehicle already runs a full four-stage decision pipeline each turn. Perception and personality are strictly separated. All NPCs can evaluate the same game-state signal, but personality weights determine what they do with it. A Ruthless character and a Defensive one can share identical health and enemy counts and still choose completely different actions. The full decision loop and tuning framework are in place, which makes the behaviour architecture extensible without rewriting the logic every time a new AI profile is needed.

Track & Environment

DM Tooling, Observability, and Debugging

Event & Logging System

A complex logging system that allows for meticulous recording of everything that happens within a race, from attacks, damage, skill checks, to lane changes, event card triggers, and much more. Meant to be the ultimate monitoring tool for the DM to keep track of what's going on, while also offering excellent debugging capabilities during development. Also includes a full breakdown of all calculations with modifiers and their sources. In the future, this system could be used to generate a summary of the race and its key moments.

Monitoring & Statistics System

Note: the UI in its current state is mainly used for debugging so visuals were not the priority.

Additional Features

Tech Stack