Ultimatum
A 3D party platformer with two ways to play together: Steam lobbies over the network, and up to four players on one screen.
- Client
- Fiverr (@ethanescamilla)
- Role
- Multiplayer Programmer
- Platforms
- PC
- Year
- 2025
Ultimatum is a competitive 3D platformer built for playing with other people. It ships two entirely separate multiplayer paths: an online mode built on Steam lobbies with host migration through the lobby list, and a local split-screen mode supporting up to four players on a single machine with gamepads.
The project started from an existing third-person controller asset, so the character movement and camera were not mine to write. What I built is everything that turns a single-player controller into a game two to four people can play at once: the networking layer, the lobby flow, the split-screen viewport handling, and the shared state that keeps everyone's client agreeing on who is who.
The awkward part of any networked character game is that animation state does not replicate for free. Position syncs cheaply; whether a player is grounded and how far through a blend they are does not. I keep an authoritative table of animation state keyed by peer, updated over RPC, so remote players animate correctly on every client instead of sliding around in a T-pose.
What I built
- Built the Steam multiplayer layer on GodotSteam: lobby creation with a configurable player cap, a refreshable lobby browser, join flow, and a waiting room that gates the start until players are ready
- Wrote the character selection sync: each peer registers its choice with the host over RPC, the host holds the authoritative map of peer to character, and every client spawns the correct mesh for everyone
- Replicated animation state across the network: a per-peer table of grounded flag and blend amount pushed over RPC, so remote characters animate rather than sliding
- Handled player spawning through a MultiplayerSpawner, with per-peer lifecycle as players join and leave mid-session
- Built the local split-screen mode independently of the network path: up to four viewports, per-player gamepad assignment through a controller manager, and its own character selection flow
- Implemented the surrounding game flow: 3D main menu, pause menu, in-lobby notifications, character selection screens for both modes, and end-of-level handling
Gallery
Breakdown
Character selection is host-authoritative. A peer announces its pick, the host records it in a peer-to-character map, and spawning reads from that map rather than from each client's local guess. Without a single owner of that state, two players picking at the same moment can end up as the same character on different machines.
Animation state is replicated explicitly. A per-peer table holds the grounded flag and blend amount, pushed over RPC as it changes, because position replication alone leaves remote players animating as though they were standing still.
Online and local are deliberately separate paths rather than one abstracted mode. Split-screen has no peers, no RPCs and no lobby: it has viewports and gamepad assignments. Forcing both through one code path would have meant carrying network concepts into a mode that has none.
Credits
- Multiplayer programming
- Bilal AhmadSteam networking, lobby flow, split-screen, character sync, and menus: the work described on this page.
- Third-person controller
- Jeh3noState-machine character controller and camera asset used as the movement base.
- Character model
- GtiboFrom the Godot Plush Character project, which the controller asset builds on.
- Steam integration
- GodotSteamSteamworks bindings for Godot.
- Input prompts and prototype textures
- Kenneykenney.nl, released under CC0.
Built with
- Godot 4.7
- GDScript
- GodotSteam
- High-level multiplayer RPC
- Split-screen viewports