JRR III

Solo project / Technical design & programming

Olympus’ Chosen.

Olympus’ Chosen is a solo multiplayer action-adventure prototype I built in Unity. The core of the project was a custom system for keeping root-motion combat animations synchronized across the network, backed by dedicated-server networking, prediction and reconciliation, interpolation, and a data-driven combo system.

Role
Solo developer
Engine
Unity
Focus
Multiplayer combat systems

Selected work

What I built

A solo project centered on networked animation, with supporting combat and server systems.

Prototype gameplay / Unity

01 / Solo prototype

The project

Olympus’ Chosen is a multiplayer action-adventure prototype set in a world inspired by Greek mythology.

I built it as a solo project and used it to work through both sides of online melee combat: how a fight should feel and how the client and server should keep that fight in sync. The concept had players exploring an open world and fighting mythological creatures alongside other players.

Project details

  • Solo design and implementation in Unity
  • Dedicated-server networking built with the Riptide networking library
  • Prototype focused on custom networked animation and melee combat
  • Unity
  • C#
  • Multiplayer
  • Technical Design
DeltaPositionsRecorder / capture and playback testing
Animation Info editor / action timeline

02 / Custom networked animation

Custom networked animation system

The core technical work was a custom system that synchronized root-motion combat animations across the network and could recover after server reconciliation.

Unity’s standard animation system was not built to stop an animation, return it to an earlier point, and replay it—including an animation that had already finished. That made it a poor fit for server corrections during root-motion attacks, where animation playback and character position had to stay together.

I used Animancer to control visual playback, then built the synchronization system around it. An AnimationInfo ScriptableObject stored the clip, recorded root-motion deltas, timing settings, and a list of AnimationAction events. Those actions replaced Unity’s built-in animation events so gameplay commands could fire at the same point when an animation was replayed.

When a time-sensitive animation started, remote clients used the current tick and ping to advance to the server’s point in the animation instead of beginning at frame zero. This kept attack timing and root motion closer to the server state and reduced mispredictions against moving characters.

System pieces

  • AnimationInfo assets combined the clip, root-motion deltas, timing settings, and gameplay actions.
  • The custom inspector displayed an animation timeline for adding and reviewing actions.
  • AnimationAction replaced Unity animation events in the networked playback path.
  • A dedicated testing scene and DeltaPositionsRecorder captured and replayed movement deltas.
  • Networked Animation
  • C#
  • Animancer
  • ScriptableObjects
  • Editor Tools
  • Lag Compensation
Unity Attack ScriptableObject showing damage, stamina, animation, hit reaction, and combo follow-up fields
Attack ScriptableObject / combat data and combo branches
Light attack → light attack
Light attack → charge attack

03 / Combat systems & design

Data-driven attacks & combos

I made attacks data-driven so combat could branch from light, heavy, and charge inputs without hardcoding every sequence.

Each Attack ScriptableObject stored its damage, stamina cost, animation, damage type, hit reaction, and attack type. It also referenced the attacks that could follow a light, heavy, or charge input. That made the combo structure readable in the inspector and let me change a chain by editing data instead of changing code.

Combat goal

I wanted players to read an opponent, find an opening, commit to a short exchange, and create space again. The basic inputs stayed approachable, while learning animation timing and combo options gave players room to improve.

What the attack data controlled

  • Damage, stamina cost, damage type, and hit reaction
  • The animation data used by the networked animation system
  • Separate light, heavy, and charge follow-ups for branching combos
  • Combat Design
  • Systems Design
  • ScriptableObjects
  • Gameplay Programming
Two characters fighting in the Olympus’ Chosen multiplayer prototype

04 / Supporting multiplayer systems

Prediction, reconciliation & interpolation

I implemented the client and server systems that kept local input responsive and remote game state up to date.

A custom tick system gave the client and server a shared timeline for processing network state. Client-side prediction let the local player act without waiting for a round trip to the server. When the server returned its state, the base Player class used the stored tick data to reconcile any difference.

Interpolation handled a separate problem. Remote characters received snapshots rather than local input, so CharacterInterpolator and PlayerInterpolator smoothed those states independently of the prediction and reconciliation path.

I also split network messaging into client send, client handle, server send, and server handle classes so outgoing requests and incoming state updates had clear routes through the code.

System structure

  • The base Player class handled prediction and reconciliation against ticked server state.
  • Separate interpolators smoothed remote player and character snapshots.
  • Client and server messaging classes separated outgoing requests from incoming updates.
  • Riptide provided the dedicated-server networking layer.
  • C#
  • Dedicated Server
  • Client Prediction
  • Server Reconciliation
  • Interpolation