Online Co-op From Day One: How Philadelphia Fiefdom Plays Together

Philadelphia Fiefdom was built for online co-op from the start, because adding it later means rebuilding everything. The whole game runs as one simulation that ticks 60 times a second, holds no scene nodes, and treats players as a list. The host runs it, a friend joins and gets a stream of what's around them, and their own character answers their stick at once, whatever the ping.

This post is about the rules that make that work, and what happens when someone joins.

Why build it in from day one?

Because co-op touches everything. If a system somewhere asks "where's the player?", there's only one answer, and the second player breaks it. If the traffic spawns around the camera, the other player's street is empty. If a punch's timing comes from the frame rate, two machines disagree about whether it landed.

So the game has a short list of rules, and every system follows them:

One clock. The simulation moves forward only in whole ticks, 60 a second. No game logic reads the frame time or the wall clock. A timer is "until tick N".
Players are a list. There's never "the player". Money, wanted stars and a taxi ride belong to a player's slot.
Commands in. A character only acts on commands. The gamepad, a test bot, a replay and a player across the network all produce the same commands.
State is data, and views read it. Everything the world keeps is plain data in the simulation, not stored on scene nodes. The nodes that draw a person or a car are never the truth; they draw what the simulation says.
Everything near any player. Spawning people and traffic, streaming the city in, deciding what gets simulated in detail: it's all done around every player, never around the camera or the screen.

None of these are new ideas, but holding to them from the first line meant co-op was never a port. A new system works in co-op the day it lands.

How does the network work?

The host runs the only simulation. A guest sends its command every tick, and the host sends each guest a snapshot 20 times a second of everything within 60 meters of them, most important first, inside a fixed size budget. The guest's world is exactly what's in those snapshots.

Anything that happens once, like a hit, a sound or a door, goes as a reliable event. Commands and snapshots go unreliable, so a late one is simply replaced by the next. Voice has its own channel.

The same ten seconds on the host's screen and on the guest's. Each screen follows its own player, and the guest pops into a shop and back out.

Why doesn't the guest feel the lag?

If the guest waited for the host to move their character, every step would arrive a round trip late. So the guest predicts their own body: the same walking code and the same collision, run on their own machine against their own copy of the nearby city. Each snapshot says where the host had them as of the last command it heard, and the guest replays its newer commands from there. Their steps answer at once, and they're only corrected when the host saw something different. Driving and your own punches are predicted the same way.

Everyone else is drawn about 100 ms behind, eased smoothly between snapshots.

What happens when someone joins?

A friend can join a game that's already going. They get a catch-up of the world first: the cars as they are, the scorch marks fires have left, a wall someone broke down earlier, with its rubble lying where it fell. Then the city streams in around them, both the parts they see and the collision and walkways their own prediction needs.

The guest heading off up the street on their own, away from the host.

Before any of that, the host checks that the guest is running the same game: the same network protocol, the same level and the same build of the city. A mismatch is turned away with a reason. If the host leaves, guests go back to the menu and are told why.

Everything that decides what happens is the same on every machine: how many people are out, how much traffic, what's simulated. Only the drawing has quality settings, so a Steam Deck player and a PC player share the same city.

How do you play with a friend?

On the same network, the host's game announces itself, and the Join screen lists it by name. Nothing to type.
Over the internet, hosting asks your router to open the game's port and shows the address a friend can join.
Steam invites are next. Joining from your friends list, with no ports or addresses, is planned but not built yet.

The game is built for two players first. Nothing in the code assumes two, and the host currently takes up to four.

Can you talk?

Yes. Voice chat comes from where the speaker stands: clear up close, fading out by about 30 meters. Or call the other player on your phone in the game. Once they answer, the call stays open and you hear each other from anywhere, through a phone's tinny band, until one of you hangs up. Voice is sent only while you're talking, or you can switch to push-to-talk.

Quick answers

Is there split screen? Not yet. Co-op is online: each player plays on their own machine.

Does everything work in co-op? Everything in the game so far: walking, driving, fights, the police, fires and their crews, the weather, breaking walls and fishing. Each system is built to work in co-op when it lands.

Do both players need a fast connection? The guest's own movement doesn't wait on the network, so a so-so connection mostly shows as other things being drawn a little behind.

Follow along

Philadelphia Fiefdom is an online sandbox set in Philadelphia. Last time was making it run on Steam Deck. The fire crews, the traffic and the fights from the posts before that all run on this, in co-op. Join the playtest list to play it early, or come say hi on Discord (opens in a new tab).