Start Building

I Built a Multiplayer Game in 72 Hours - Here's What I Learned

I gave myself three days to build a game that two people could play together over the internet. No prior multiplayer experience, no dedicated server, and a hard deadline. Here is what actually happened - the technical bets, the scope cuts, and the lessons that made the build playable instead of abandoned.

Why 72 Hours for Multiplayer?

Multiplayer adds a whole dimension of failure: latency, sync, and "it works on my machine" when the other machine is a friend's laptop. I chose 72 hours because it felt like the minimum window to get something that two players could run and enjoy without spending weeks on netcode. The goal was not a polished product but a proof that a small multiplayer loop could ship in a weekend.

The Setup - Before the Timer Started

I locked in a few decisions the night before:

  • Engine: Unity with Netcode for GameObjects (built-in, no third-party subscription).
  • Scope: Two players, one shared goal (e.g. collect X, survive Y waves), no matchmaking or lobby UI.
  • Art: Placeholder shapes and one free asset pack. No custom characters or levels.
  • Platform: PC build only; same build for host and client.

I did not set up relay servers, dedicated servers, or rollback netcode. The aim was authoritative host, simple RPCs, and one playable scenario.

Hours 0-24 - Getting Two Players in the Same Room

Goal: Host starts a game, client joins, both see each other and a shared world.

The first day was almost entirely "does the client see what the host sees?" I used Unity Netcode for GameObjects with a simple NetworkManager: host as server, client connects by IP. Spawning the player prefabs and a few networked objects (pickups, obstacles) took longer than expected because I had to mark the right things as NetworkObject and ensure spawn order did not break.

What worked: Sticking to the built-in Netcode package and its spawn/ownership model. Reading the official Unity netcode samples once and then not switching approaches mid-stream.

What did not: Trying to sync rigidbody physics directly. I switched to simple position/rotation sync for the two players and left physics local. That cut a lot of "why is my character flying?" debugging.

Lesson 1: Lock "who is in the game and where they are" in the first 24 hours. If you cannot get two clients in the same scene with visible avatars, the rest of the jam will not matter.

Hours 24-48 - Shared State and One Clear Win Condition

Goal: One objective both players care about, and a shared score or progress that updates for both.

I added a simple collectible that both players could pick up, with a shared counter. That meant one networked variable (or a small struct) that the host updated and the client could read. I avoided complex state at first - no inventories, no per-player objectives - just "get N things together."

What worked: Letting the host own the "truth" for the objective. The client saw updates via NetworkVariable or RPCs. One source of truth kept sync bugs manageable.

What did not: Adding a second objective type (e.g. "and also survive waves"). I cut it and kept a single win condition so I could polish one loop.

Lesson 2: One shared goal is enough for a 72-hour multiplayer prototype. Add variety in a sequel, not in the same build.

Hours 48-72 - Feel and Ship

Goal: The game feels responsive, the win/lose state is clear, and the build runs on another machine.

The last day was about input feedback, simple VFX for "player did thing," and a clear win/lose screen. I also fixed one nasty bug where the client's "collected" event did not always run - that came down to making sure the server (host) was the one updating the shared count and then notifying both clients.

What worked: Testing with a second PC and a friend. Localhost testing hid latency and ownership issues that showed up in a real two-machine session.

What did not: Adding "just one more" power-up. I dropped it and shipped the build as-is.

Lesson 3: Define "done" as "two people can play from two machines and see the same outcome." Everything else is optional.

What I Would Do Differently Next Time

  • Pick netcode on day zero and do not switch. I almost lost half a day considering a different solution. Commit to one approach and learn its limits.
  • Test two machines by hour 24. Do not assume "it works in editor" means it works over the network.
  • One shared objective, one shared "game over" state. Avoid branching win conditions or per-player goals in a 72-hour scope.
  • Buffer the last 12 hours for "someone else runs the build." Install, firewall, and "where do I enter the IP?" ate more time than expected.

Takeaways for Your Own Multiplayer Jam

  • Get two clients in the same world first. Do not add game design until both players see each other and the environment.
  • Host-authoritative keeps logic simple. Let the server update shared state; clients send input and receive results.
  • Cut features aggressively. One objective, two players, one build. Add matchmaking, lobbies, and extra modes later.
  • Test on real hardware early. Localhost masks latency and often hides ownership or spawn bugs.
  • Ship the build. A small, playable two-player game is a win. A big design doc with no working build is not.

Frequently Asked Questions

Can you really build a multiplayer game in 72 hours? Yes, if you keep scope tiny: two players, one shared objective, host-authoritative netcode, and no matchmaking. The goal is "two people can play together," not a full-featured online game.

Which engine or netcode did you use? Unity with Netcode for GameObjects. The built-in package was enough for a simple host-client setup. I did not use relay services or dedicated servers.

What was the hardest part? Getting the client to see the same game state as the host and testing on two real machines. Localhost testing hid latency and ownership bugs.

Should I add more players or objectives? Not in 72 hours. Lock two players and one win condition first. Add variety in a follow-up project.

What if my netcode feels laggy? For a weekend jam, host-authoritative with simple position/state sync is enough. Save rollback or prediction for a longer project.

If you run your own 72-hour (or 48-hour) multiplayer challenge, use this as a checklist when scope creeps. And when you ship, share the link - the best part of jams is seeing what other devs get running under the same constraints.

Found this useful? Share it with your team or your next game jam crew. For more on multiplayer and netcode, see our Rollback Netcode Explained post and our Game Networking guide.