Preparation involved splitting the original movie clip into 12 separate reference shots, producing storyboard sketches, and creating a detailed shoot log covering pre-production, production, and post-production stages. While the storyboard was less useful, the reference clips and shoot log proved essential for efficient shooting and organisation.
University – Third Year
This project was made in my third year of university.
-
Data Cleanup in Shogun Post
Captured data was imported into Shogun Post for systematic cleanup of rigid bodies, focusing on jitter and marker swaps, especially in the hands. Solving issues were addressed by re-adjusting markers and re-solving skeletons. While major problems were fixed, more time could have been spent refining hand data for a stronger base going into Motion Builder.
-
Retargeting and Motion Editing
Using Motion Builder, mocap skeletons were retargeted to MetaHuman characters. Problems such as bent spines and gaps during contact animations were solved by manual corrections and animation layers with blended keyframes. However, mistakes in workflow, such as not using namespaces, led to extra work during export to Unreal Engine.
-
Final Scene Assembly
The cleaned and retargeted data was imported into Unreal Engine’s sequencer, where camera movements, lighting, and a background environment were added. Time constraints prevented the integration of face capture data, though the workflow for this was understood. Despite this, the scene successfully recreated the dramatic sequence and demonstrated a complete end-to-end mocap pipeline.
-
Grid System and Expansion
The grid system formed the foundation of the placement mechanics. Players can adjust grid sizes for both small and large-scale builds, with objects snapping precisely to grid lines rather than cell centres for improved accuracy. Progression is built into the grid itself: much of the space is locked at the start, requiring players to unlock additional areas as they expand their park. This prevents overwhelming the player early on while encouraging steady growth.
-
Multi-Layer Building
To increase creative possibilities, a multi-layer grid system was implemented. Players can build on different vertical levels, from ground-level tracks to elevated structures. Floors load and unload dynamically, showing only the active layer to reduce clutter and improve performance. While players cannot freely set floor heights, developers can tweak the pre-set distances and number of levels for balance. This design opens up complex, three-dimensional track building and park layouts.
-
Track Placement and Connectivity
Tracks can be freely placed in the world, starting from any orientation. Regular track pieces, however, must snap onto existing pieces, ensuring closed circuits and maintaining valid paths for AI-controlled racers. A connection node system prevents invalid overlaps by checking whether nodes are already in use, guaranteeing seamless and functional tracks. This approach allows creative freedom while enforcing rules that keep tracks playable.
-
Object Placement and Validation
Beyond tracks, all buildable items snap neatly to the grid for consistency and clean layouts. Players can rotate objects within the grid to customise their designs. Validators were added to prevent floating or overlapping objects, preserving polish and avoiding visual glitches.
-
Saving and Loading Systems
Using a method of saving metadata to a json file, the system supports saving every detail of the player’s park, including track positions, orientations, and structures. This ensures long-term progression, allowing players to experiment with multiple plots without losing work. The system compressed all important factors of the park into minimal metadata, upon loading a park the loading system would reconstruct the whole park from this metadata. Each park had its own json file which made the system very modular.
-
Design Influences and Research
The team researched existing track-building systems to refine their design. Neo Sprint (Atari) was considered too restrictive due to its top-down view and limited space, while TrackMania (Ubisoft) was seen as overly complex and racing-focused. Planet Coaster 2 (Frontier) offered the closest inspiration, but the aim was to create a more intuitive and accessible system suited to a tycoon-style game. The final design balanced accessibility with creative freedom, setting it apart from existing titles.
-
Planned Unit Variety
The original design aimed for four distinct unit types (Gunner, Shield-Bearer, Swordsman, and Healer), each reacting differently in battle. While only the Gunner was implemented, the modular AI structure means the framework is ready to expand with new unit classes in future versions.
-
Custom Edge Avoidance Mechanic
An early problem was that agents ignored the boundaries of the map and wandered out of the area. Standard wall avoidance behaviours failed to work correctly, so I developed a custom “edge avoidance” mechanic. This checked the plane’s bounds and applied steering forces when agents approached the edges, successfully keeping them inside the play area.
-
Combat Scenarios with Emergent Outcomes
Although only one unit type (the Gunner) was completed, the system still produced varied and unpredictable battles. Each encounter played out differently depending on health levels, distance to enemies, and steering responses. This emergent gameplay demonstrated the adaptability of the combined behaviour tree and steering system.
-
Steering Behaviours for Realistic Movement
Movement was handled through steering behaviours, enabling agents to wander, pursue targets, and avoid obstacles in a natural way. These behaviours were attached and detached as needed by the behaviour tree, making motion more fluid and responsive compared to rigid pathfinding systems like A*.
-
Behaviour Trees for Decision Making
To control agent decisions, I implemented behaviour trees instead of simpler finite state machines or overly complex neural networks. Behaviour trees allowed me to build modular and reusable logic, such as choosing when to attack, retreat, or wander. Their hierarchical design made the AI adaptable while leaving room for future expansion with new unit types.
-
Debugging Steering and Behaviour Conflicts
At first, agents would freeze because the wander node repeatedly removed and reattached behaviours, cancelling out movement. Careful debugging revealed the issue, and by restructuring how behaviours were applied, I ensured agents could combine multiple steering forces smoothly without stalling.
