Multiplayer in JOIN US!

I wanted to give a quick overview of our co-op multiplayer setup for Join Us.

We're huge fans of games like Valheim, State of Decay, Project Zomboid, and The Forest - so supporting multiplayer from day one was non-negotiable for us.

Steam post image Riding farm animals at sunset is better with friends.

You get those moments like splitting up with your friends, one building the base, another scavenging for resources, and the last one spending more time on the wiki than actually playing.

An interesting design opportunity is that, since our game puts followers at the forefront, they receive a lot of love and are smarter and much more useful than your average NPC (see our post showcasing their system here!). This ensures that solo play stays meaningful and doesn’t turn into a grind.

Behind The Scenes...

Here be dragons.

From a technical standpoint, adding multiplayer fundamentally increases the complexity of the game code. In practice, it easily doubles it.

Here's a quick example that happens in our game:

Let's say you want the player to interact with a fireplace to light it up.

Single Player...

1. The player walks near the fireplace.

2. The interaction system detects proximity.

3. A prompt appears: “E – Light Fire.”

4. The player presses E.

5. The fireplace sets its internal state to 'lit'.

6. The particle system plays.

7. The light component turns on.

8. The interaction is disabled.

Fairly straightforward!

Multiplayer...

.....Now look at Multiplayer with 2 players:

1. Player 2 connects to the server.

2. The server sends the current state of the fireplace.

3. Player 2 initializes the fireplace locally based on that state.

4. Player 2 approaches the fireplace.

5. The interaction system detects proximity locally.

6. The prompt appears locally.

7. Player 2 presses E.

8. The client performs a local check to see if the interaction is allowed.

9. The client sends a Remote Procedure Call (RPC) to the server requesting to light the fire.

10. The RPC arrives at the server after network latency.

11. The server validates the request:

• Is the fireplace still unlit?

• Is the player allowed to interact?

1. The server sets the authoritative fireplace state to lit.

2. The server marks the state for replication.

3. The replication system queues the update.

4. The server sends the updated state to all connected clients.

5. Player 1 receives the replicated update.

6. Player 2 receives the replicated update.

7. Both clients execute their replication logic.

8. Both clients spawn the particle effect.

9. Both clients enable the light component.

10. Both clients disable the interaction system on the fireplace.

...And that’s the ideal scenario.

Now add real-world conditions:

• What if both players press E at nearly the same time?

• What if a player joins while the fireplace is mid-transition?

• What if the RPC packet is dropped?

• What if the fireplace is destroyed while replication is in flight?

Testing and finding bugs can also become much more complex as you need at least two versions of the game running to test. Testing some timing dependent behaviors like blowing someone up while they are climbing into a vehicle might even require two or more humans.

Lighting up a local ranch can create friendships that last a lifetime.

Our Approach

To keep this manageable as a team of 10 crazy persons developers, we are launching with a listen server scheme. This essentially means 1 of the players will be the host. Their save file is authoritative, and they can start the session for others to join. Anyone in the game can do what they want and are part of the cult on the same level as the host. They can enact teachings, build, fight, control followers. Some mechanics do require all players to approve or be there for them to activate, depending on their impact. Players “profiles” are saved and their settings/last used follower/pinned missions/etc are restored when joining back a server.

What Comes Next?

Post-launch, one of our main priorities is completing our Dedicated Server implementation. This will allow players to host persistent worlds without needing a player actively running the game as host.

While this is already underway in parallel, we want to make sure it is stable, well-tested, and delivers the full benefits expected from a dedicated infrastructure. We are also working with external partners to support third-party hosting solutions for players who prefer that route.

It is also important for us to allow players to customize their experience, so a comprehensive server configuration system is something we keep in mind. We will absolutely enlist the community’s help in defining what is most important for everyone once we cross that road.

We’ve had an incredible time playing together internally, and we can’t wait to see the stories, chaos, and cult masterpieces everyone will be able to create once we launch.

Cheers, Pierre-Olivier