Gameplay System Designer
Rivertale is an XR co-op adventure game that plays with an arduino to provide custom controls. In the game you and your friends try to escape hell.
The game drives you in chaotic environments where communication is key (like Overcooked) and combines this with physical activity (like the Wii or a Kinect does).
XR
On this project I got the responsibilities of a Gameplay System Designer, being responsible for enemy behaviour and player comfort. This included:
Designing, implementing and balancing different AI types.
Took full ownership of all enemy variations.
Setting up behavior trees, with custom decorators and tasks.
Communicating with other departments to implement and optimize.
Testing & iterating on the enemies.
Designing gameplay systems to improve the experience.
Anchor feature, to stop momentum and create vulnerability.
Ship guidance feature, to help players maintain the right course.
Playtesting to ensure intuitive gameplay, making adjustments based on feedback.
Designed and balanced the 3C’s (Controls, Camera, and Character feel).
Worked closely with other developers to align AI behavior with the desired feeling.
Created the animation blueprint and implemented the enemy animations, with layered blending, to create immersive encounters.
University
Project info
10 weeks
Rivertale official Trailer
Personal Contribution
Personal showcase
Explanation: XR Stage
XR Demonstration
22 people
Overview
Ranged enemy (damage)
Role: Pressuring players to multitask (repair vs fight) and communicate within time limits.
What & Why
Behavior: Fires slow, damaging projectiles that intercept the players if they do not move from their trajectory.
Intent: Forces players to communicate or prioritize (“Do we dodge, shoot, or do we have to perform another action?”).
Technical implementation
Projectile Prediction: Uses a quadratic discriminant formula to calculate intercept trajectory (calculates player location in X seconds if they do not move).
Why? Ensures shots are dodgeable but threatening - players have to plan, not panic.
Uses player velocity & location, combined with projectile velocity & location to calculate the intercept location and converts this in a rotator to spawn the projectile in.
Visual clarity: Added a special animNotify in the animation to notify when it should spawn.
Iterations & Challenges
Issues:
Enemy felt unpredictable:
Problem: Enemy was moving.
Solution: Making enemy stationary.
Why: After many iterations players did not seem to get adjusted to a moving boat + moving enemy.
Enemy is hard to hit:
Problem: Hurtbox sizing felt too small.
Solution: Tweaked hurtbox + cannonball hitbox size to be bigger but still challenging.
Why? Created an easier hit & better game feel.
Enemy projectiles feel weird:
Problem: Fired at a relative location in front of player.
Solution: Calculates a future intercept point.
Why? After lots of tweaking there was no perfect solution since there are lots of turns. This required better logic.
Simple custom decorator;
random chance
Custom decorator in behavior tree
Anchor system
ship Guidance system
The XR stage has a lot of options, but we chose to use:
The size of the area
The big screen (8m x 3.5m)
Lighthouse tracking system
On top we built custom-controls based on an arduino kit. We used this to create cannons, an anchor, and a steering wheel.
Using any of these props will directly translate onto the big screen giving a sense of real immersion.
Core Loop Supports Communication:
Continuously moving forward creates inescapable tension, forcing players to:React quickly (no time for indecision).
Verbalize needs (“Turn to the left”).
Solve problems together (“I can … if you …”).
Design Challenges:
The desire to be challenged by something more technical that required extra design thought, like:Using Arduino controllers.
Required a new script to be written.
Creating short and clear encounters.
I see …, it does …, I should …
XR-Specific Challenges:
Physical Controls: Making actions feels intuitive.
Balancing safety and comfort (see design analysis below).
Safety & comfort design
XR Co-op Adventure
I want to keep this short and to the point because there is a lot of cool stuff to show, but in order to understand the scope I request you to briefly read about the play space below.
Overview
General Design
Boss enemy (final test)
Sketch on floor lay-out to measure safety
Discomfort ≠ immersion: Players can’t engage if they feel at risk. Ruining immersion and ultimately their experience.
Reducing risk at injury: By keeping the pilot stationary we created a more less chance of collision.
Enemy design
Goal: Creating distinct enemy types that create meaningful and clear encounters. Each enemy with its own goal to create an atmosphere that enforces communication.
Quick Navigation menu
Player Experience Goal: A tense, communication-driven co-op game where players have to work together under pressure.
Designed the core gameplay loop with a small team (of 4) and built on this to create an XR experience, focusing on:
Forced movement (ship is always moving, creating urgency).
Role division (pilot & crew, requiring constant communication).
Physical interactions (Arduino-driven features).
How
Prototyping: Started with a basic Arduino script to test features and the potential fun of the concept.
Inputs & Roles:
Pilot: Controls steering via rotary encoder.
Crew: Manage other features (e.g. cannons).
Tension via Constraints:
Players must communicate to overcome challenges.
Can not stop ship themselves (see Anchor system).
Can not turn the ship around (see Guidance system).
why the loop works
Playtest with an early prototype
2D visualization of interception
Clean and commented code in engine
Swimming Enemy (set-up)
Physical Interactions
The game uses Arduino controllers hidden in props. Performing actions in real-life, will translate to in-game. This made the experience more personal and created a more immersive loop.
Design pillars
Chaotic Coordination
The players will be moving at all times. There will be waves of obstacles to overcome. To reach the end players had to coordinate together. All features are designed to encourage communication.
Overview
Goal: Creating a immersive but physically safe experience where player focus on teamwork.
Iterated on physical setup, player movement, and feedback systems to minimize discomfort / collisions.
Improved based on shown behavior during playtests.
How: iterative solutions
Physical Space:
Early build: Used wired connections & cramped play space.
Problem: Tripping risk & collision risk.
Fix: Switching to WiFi receivers & spreading props.
Stationary Pilot Role:
Early build: Driver moving at elevation risked falling.
Fix: Anchored pilot in place, designing stationary challenges (e.g., steering challenges, dodging game objects).
Prop Interaction:
Issue: Players acted too rough with props because they thought it did not work.
Fix: Provided more visual feedback, and changed the condition for the prop to work (e.g. first you had to enter a trigger box a few times with the prop to repair, after you had to do this once and got a VFX + SFX cue).
Why these choices matter
Role: Disrupt momentum, set up combos with other enemies.
What & Why
Behavior: Moves along a spline path, triggered by player entering a trigger box.
Scalable Design: Level designers just place enemy and adjust the spline / trigger box.
Intent: Create “Oh no” moments where players quickly decide on what to do. Provide level designers with a tool to create more tension and stop the player.
implementation
Spline-Based Movement: Mesh follows predefined path while playing an animation started by a trigger box. Speed is consistent because I made a calculation to set speed at a constant rate over the entire spline path.
Why? Cheaper than AI, easier to tune for XR comfort, and consistent expectations from the enemy.
Spline-based movement was an easy alternative to provide level designers with control over the pathing to determine the pacing within the level.
Iterations & Challenges
Issues:
AI set up:
Problem: Enemies were unpredictable and chose pathing that made it hard to see them.
Solution: Turned this enemy in a tool with predefined but tweakable values.
Why? After lots of playtests it seemed that this enemy was too unpredictable in the current loop. To create management for level designers it was easier to change this feature’s functionality.
”Should I shoot the enemy?”:
Problem: Players tried to kill the enemy, while it was not meant to be.
Solution: Allowing this choice and playing into this.
Why? Players had fun with shooting this enemy, it created less down-time and a stronger immersion. It also required more communication from players.
Key Takeaway:
If players “break” your design, being flexible can create even more gameplay.
Role: Final test - combines all mechanics into a communication-heavy climax.
What & Why
Behavior:
Spawning: Ranged enemy + a hazard
Attacking: Launches a rock that pulls the anchor down and deals damage.
Intent: Tests everything the player has learned, with rising tension.
Technical implementation
Attack Flow: Mesh follows predefined path while playing an animation started by a trigger box. Speed is consistent because I made a calculation to set speed at a constant rate over the entire spline path.
Starts when player enters boss area trigger box (send interface communication to boss).
If distance >= minRockAttackRange (float for minimum attack range):
Throw a spline-based rock projectile
Anticipation signals:
Animation of boss.
Huge rock with fire (red color opposed to blue environment).
Water shader at impact zone.
Top screen flashes red, if player is within hit range.
If distance < minRockAttackRange:
Uses a weighted random selector (custom behavior tree decorator).
Summon hazard (statue that damages and slows the ship).
Summon ranged enemy.
Logic:
Rolls random float (0 - 1).
Compares against public var “Success Chance” that is set in BT.
If false and used in a sequence the next branch will be played.
Iterations & Challenges
Issues:
Encounter:
Problem: The boss feels insignificant in a short encounter.
Solution: Provided the boss with the ability to anchor the player + extending the boss arena to create more tension.
Why? Since the arena already contained swimming enemies, I provided the boss with the ability to stop the player herself.
Unclear feedback:
Problem: Players did not know when they could damage or actually damaged.
Solution: Created blend spaces in animation and used a VFX.
Why? With this extra layer of communication players could see a shield when the boss was hit and have a smooth layered animation between being hit and attacking. Providing feedback on what is going on.
Key Takeaway:
By providing better feedback the boss became more fun and strategic. Visual feedback creates understanding for players, which they use to create plans.
Playtest Findings:
Core loop of just shooting & steering was too repetitive → players stayed stationary.
Initially allowed players to use anchor to stop → led to self-sabotage and confusion.
Design goals:
Force physical relocation: Breaks static gameplay.
Create tension: Stopped ship = sitting duck scenario for players.
Enhance communication: Players have to delegate roles under pressure.
iterations & challenges
First Prototype (Button Press):
It did not feel intuitive for an anchor to hold a button.
Final Version (Rotary Encoder):
Satisfied player feedback immersion.
Gives physical feedback by using a motor with the anchor that would lower a prop when it was down in game.
Felt like a more fun task according to testers.
Key Challenges:
Creating satisfying interactions.
Balancing raise time.
Tweaking use of feature (players would just spin the wheel and run away).
Result
Increased player movement by double the amount of steps for the crew.
Stengthened core pillars (communication & physical interactions).
Core-loop feels like it is constructed in a better way (testers).
Overview
Goal: A mechanic triggered only by enemies that completely stops the ship.
Forces players to interact with a capstan prop to resume movement.
Designed to break momentum, create vulnerability, and enforce teamwork.
Implementation
Trigger:
Enemy drops anchor → ship instantly stops (overrides current speed).
Player Action:
Must run to physical capstan prop containing a rotary encoder.
Rotate the prop until they get feedback to raise anchor.
Technical Setup::
Arduino reads encoder input and sends data to engine. Twisting in the right direction increments the float value by X until max is reached - then bAnchorDown == false.
Why it was made
Problems Observed in QA:
Players fought the core loop (constant forward motion).
Level designer struggled with player wayfinding.
Design goals:
Preserve the illusion of freedom while preventing exploits.
Reduce cognitive load by prevention from getting lost.
Support level designers with reusable tool.
iterations & challenges
V1: Basic Spline Guidance
Only used the guidance spline + timer based correction.
Issues:
Players still found exploits to get out of bounds.
Felt like the invisible hand was too abrupt.
V2: Final Version
Added collision-triggered border splines for hard boundaries
Adjusted interpolation speed to feel natural + prevent motion sickness.
Tweaked the timer max seconds, to still provide the feeling of freedom.
Impact:
Players focused more on objectives instead of navigation.
Level design iteration time cut (pre-built system prevented ship to get out of bounds everywhere).
Overview
Goal: Creating a non-intrusive navigation guidance system that:
Prevents players from turning the ship around or getting lost.
Maintains player freedom experience while enforcing progression.
Uses guidance splines to auto-correct course deviation.
Implementation
Technical Setup:
Guidance Splines:
Placed along river’s center path (invisible to player).
Ship smoothly interpolates back if deviating for >= 4 seconds.
Direction Checks:
110° detection arc (55° left/right from ship’s nose)
Checks for spline presence:
Within arc: No correction.
Outside arc: Triggers auto-return.
Border splines (V2):
Added as collision-based backup for edge cases.
On contact: Instantly but smoothly reorients ship.
Design Logic:
4-second delay → to allow short exploration, making players feel free.
Smooth interpolation → to prevent motion sickness.
Spline-based → to assist level design with setting the edge of world.