Ancient Olympics (2025)
Party
Minigames
Online
2-4 Players
Casual
Action
Under Development
Game Trailer
Role:
| Gameplay Programmer
| Designer
Team Size:
| 1 (Solo Developer)
Time Spent:
| 4 Weeks
Engine:
| Unity
A
N
C
I
E
N
T
O
L
Y
M
P
I
C
S
Overview
Ancient Olympics is a 2-4 player online party game that allows friends to compete in a plethora of minigames. The
minigames include Jousting, Assassinations, Javelin Throwing, and Sword Fighting. I wanted to design each game to
be quick and engaging, minigames should feel like they happen in rapid succession.
This project is fully networked using Unity's Netcode for Gameobjects and Unity services for relay, authentication,
etc.
The art assets used in this project are all from Kenney assets (kenny.nl), I wanted to ensure that the art was consistent
so I only selected pieces from that artist (Also the designs are fantastic!).
This project is inspired by party games like Unspottable, Gang Beasts, Mario Party, and others! I suddenly got the urge one
day to develop a party game of my own to have fun playing with friends and.. suddenly this was the product!
State-Driven Character Controller
In developing the player character, I needed a system that would be able to seemlessly manage multiple states at any given moment. From previous projects, I've grown fond of the statemachine architecture, so it was no issue deciding this approach for this problem.
I designed a custom statemachine to handle all player states (For a controller as simple as this I didn't feel any need to design
a hierarchical state machine).
The player has 12 states:
Core states: Idle, Move, Dodge, Hit, Death, Frozen
Gameplay-specific states: Catch, (Javelin) Throw, Swing, Melee1, Melee2, Melee3
The gameplay-specific states are only available within certain minigames, while the core states remain accessible throughout the entire session.
This state machine is built with polymorphism. Every state is its own class derived from a
BaseState. This base state defines the SwitchState method that
controls transitions from one state to another and declares methods like Enter,
Update, and Exit, to ensure each state include the basic methods.
The Player class instantiates the initial state (Idle) and updates the active state's Update method (though
the implementation are handled in its respective class).
Online Lobby System
Before every game, players are held in an open environment where they are able to freely move around while waiting for the host to start. There is no ready-up system, but the host is unable to start until atleast one other client has connected. Players can start as a host by simply clicking the button and others can connect to that host through a lobby join code.
No code is the same! Codes are allocated and parsed through Unity's Relay service.
The process begins by having players sign in to Unity's Authentication service for verification.
When a player creates a host, Unity allocates a relay and provides a code to their client. The allocation data is passed to Unity Transport
via DTLS, and the host is started.
When a player joins a host, their client retrieves that same allocation data and sends it to their own transport layer to complete the
connection, the client is then started.
On a successful connection event, a new player object is instantiated and spawned across the network. Players are given the ability to move
around as they wait for the game to begin!
Client-Hosted Interactions
The game uses a Client-Hosted Server Model, chosen for its simplicity and alignment with the project’s small-scale, friend-focused multiplayer design. In this setup, the host validates all client actions through RPCs and keeps the session consistent using RPCs or Networked Variables. This approach avoids the complexity of dedicated server management while still providing reliable and efficient multiplayer interactions.
Client-Hosted Server Model is the network architecture that the game is designed around. This is for its
simplicity and suitability to the project's scale. I designed this game with the idea of friends playing together, focusing solely
on that idea. This allowed me to avoid issues like cheating, passing authority, and dedicated server management. The trade off is that
players are limited to peer-hosted sessions.
Though, for the scale and vision of the game I found that completely fine with me!
Client-Hosted Servers requires client players to talk to the host client for validation of their actions. This is typically handled
through Remote Procedure Calls (RPCs), and the server can effectively communicate back to all clients
through RPCs or Networked Variables.
That short description of clients messaging accurately sums up the design of interactions in this game. An interaction at its simplest
implementation may look like this:
Attacking Interaction:
• Client A sends a message to the Host requesting to process the attack.
• The Host validates the hit:
· On Failure: The action is rejected, which may result in the interaction from Client A's perspective to · look like lag if somehow the Host never received that message or such.
This interaction design is a perfect balance between the functional multiplayer systems and ease of implementation. As the goal of this project was more or less designing this game with ease and efficiency, I found this approach to work exceptionally well.
What I've Learned
I'm not perfect at designing multiplayer systems or even gameplay systems, but its incredibly fun!
It can be hard to create a design that stays within bounds of your project goal and doesn't build complexity as the project develops.
I struggled early with network designs growing too rapidly and was in a constant balance struggle to create a structure that flows well.
Building structure was hard but ultimately very rewarding.
Managing gameplay across a network is especially difficult if you don't properly utilize the right tools and take many... many precautions
(repositories are a must). I found it more difficult to control interactions than to implement
them.
I love this project and I am very proud to show this off to you!