Want to know how to make a multiplayer game your friends can actually play together? Good news first: you can. Bad news: it's a different kind of hard from making a single-player game, and the sooner you know why, the fewer weekends you lose.
The short version: if you're new, build inside a platform that already runs the networking (Roblox Studio, Fortnite's UEFN, a Luanti or Minecraft server). If you want your own standalone game, pick an engine with netcode built in (Godot, Unity, Unreal, GameMaker) and plan for multiplayer from day one.
Is it hard to make a multiplayer game?
Yes. Harder than single-player, and not just by a little. Unreal's docs say it plainly: communicating game state between machines "makes creating multiplayer experiences inherently more complex than single-player experiences." The reasons are pretty concrete:
- Everyone's machine disagrees. Players have different connection speeds, input can get lost, and at any given moment one player's version of the game is probably slightly different from everyone else's. Roblox's docs say most of its players sit at 100–300 ms of network latency, which is a lot when you're trying to land a jump.
- You can't trust the players' computers. Godot's docs warn that networking done wrong "may lead to cheats or exploits." Their advice is to treat all client input as untrusted, and never let clients decide their own position, combat results or inventory.
- Somebody has to run the thing. A game that other people join needs a machine that stays on. Unity's docs call a dedicated game server "typically an expensive option" because of the hardware and running costs. If that's your worry, my breakdown of what a Minecraft server costs shows what hosting looks like in practice.
- You can't bolt it on later. Unreal's docs say retrofitting a game that wasn't built for networking means combing through the whole project and rewriting large parts of the gameplay. Gameplay written for multiplayer still works fine in single-player, so build it that way first.
None of that means don't. It means pick the route that hides the most of it from you while you learn.
Route 1: build inside a platform that handles the networking
This is where I'd send anybody starting out, including teenagers building something for their friend group. The platform runs the servers and the sync. You write the game.
Roblox Studio
Per Roblox's docs, "Roblox games are multiplayer by default and run in a client-server model." Roblox's server is the authority, and it replicates the world, physics and chat out to every player. Your scripts run on the server and on the client and talk across that line. Studio runs on Windows and Mac. Roblox handles the servers, so you never rent one. The catch is that your game lives on Roblox, on Roblox's terms. If you're exploring that world from the player side, my list of free games like Roblox is a good detour.
Fortnite's UEFN
Epic describes Unreal Editor for Fortnite as a way to make Fortnite games with multiplayer, hosting and backend services built in. You script in Verse, Epic's language "designed for online games." It supports multiplayer playtesting with a pile of test players, which saves you from needing eleven friends on a Saturday. Same trade-off as Roblox: easy because it's their platform, and your game lives there.
Scratch cloud variables
For the very young or the very new to code, Scratch has cloud variables. Going by the Scratch Wiki (a community-run wiki), they store numbers on Scratch's servers, shared by everyone running the project, and the wiki says online multiplayer with them is possible "although not easy." The limits are tight: 10 cloud variables per project, numbers only, up to 256 digits each, and at most 10 updates per second. New Scratchers can't use them at all, and cloud chat where people type free text is forbidden (premade phrases or emojis are fine). Think turn-based games, high-score boards and simple shared state, not a twitchy shooter.
Luanti and Minecraft servers
Luanti (formerly Minetest) describes itself as a platform for creating and sharing games, mods and texture packs, with a Lua API and a content database. Its main menu has a Host Server option that suits a temporary server for a couple of friends. My Minecraft vs Luanti comparison covers how it differs from Minecraft.
Minecraft works the same way in spirit. You don't write netcode; you run a server and add plugins or mods that change how the game plays. Start with how to make a Minecraft server, then pick your software with the server software comparison. If you want to try it without spending anything, there's a guide to free Minecraft server hosting.
Route 2: engines with netcode built in
Want a standalone game that isn't tied to someone else's platform? Then you want an engine. All of these give you the plumbing; none of them give you the design decisions.
Godot
Godot's high-level multiplayer API sits on the scene tree and a lower-level MultiplayerPeer object, with implementations for ENet (the default in the docs' examples), WebRTC and WebSocket. You create a server or client with ENetMultiplayerPeer; the server is always peer ID 1. Functions talk to each other with the @rpc annotation. It supports exporting for dedicated servers, and the web export lacks some higher-level features and raw TCP/UDP. It's a friendly place to learn what an RPC is.
Unity Netcode for GameObjects
Unity describes Netcode for GameObjects as a high-level networking library built for Unity. It supports client-server (dedicated or listen server) and distributed authority, and runs on desktop, mobile, XR, most consoles and WebGL. Search for Unity multiplayer and you'll hit the old UNet manual pages; UNet is legacy, and Unity's docs have a page for migrating from it. Start with the current docs and the Boss Room sample project.
Unreal Engine
Unreal is client-server all the way down: the server holds what its docs call "the one, true, authoritative game state," and clients send RPCs for actions while the server replicates state back. It has Standalone, Dedicated Server, Listen Server and Client network modes, and three replication systems (the generic default, Replication Graph for huge numbers of actors, and Iris, the newest). Its tips are good habits anywhere: prefer RepNotify properties over RPCs where you can, use multicast sparingly, and mark frequent RPCs unreliable. Powerful, but it's the steepest of the four for a first project.
GameMaker rollback
As of 2026, GameMaker's rollback multiplayer is built for the GX.games target. GX servers connect players and sync their input, "so no server set-up is required." Online play only works on GX.games, and the tutorial notes a four-player limit at the time of writing (that's from the beta manual, so check the current one). Good fit for small fighting-game or arcade-style projects.
Networking models, in plain words
You'll trip over these terms in every tutorial. Here's what they mean.
| Term | What it means |
|---|---|
| Client / server | Players (clients) send their inputs; one server holds the real game and sends back the result. Quake moved to this in 1996, and it's why your lag depends on your own connection, not the slowest player's. |
| Authoritative server | The server's version of the game is the truth. Clients can ask; the server decides. |
| Listen server | One player is both host and player. Easy to set up and fine for casual co-op with a few friends, but the host gets an advantage over everyone else and carries an extra processing load. |
| Dedicated server | A server with no local player. Harder and pricier to set up, and the right call for big player counts or competitive games. |
| Relay | Traffic passes through a middleman server instead of players connecting directly. Steam's relay network, for example, hides players' IP addresses and often improves ping. |
| Client-side prediction | Your game moves your character immediately instead of waiting for the server. If the server disagrees, your client rewinds and replays your recent inputs from the corrected state. |
| Lockstep | Every machine runs the same commands on the same turns from the same start. Great for strategy games where the state is too big to send, but the game must be fully deterministic and everyone waits for the most-lagged player. |
| Rollback | The game predicts other players' inputs, and if a prediction was wrong it rolls back and corrects. Big moments like winning a level should wait until players are in sync. |
| Distributed authority | Players share ownership of game state while a small central service routes traffic. Cheaper and avoids many prediction headaches, but easier to cheat. Unity says to choose client-server if you need prediction with rollback. |
| TCP vs UDP | TCP is reliable and ordered but slower. UDP is fast but packets can be lost or arrive out of order, so engines rebuild the reliability they need on top of it. Godot's high-level API uses UDP only. |
| Desync | Two players' games no longer agree on what's happening. The thing you're always fighting. |
| RPC | A remote procedure call: a function one machine triggers on another. |
Hosting: where the game actually runs
- Let the platform do it. Roblox, UEFN, GX.games and Scratch all run the servers. Nothing to set up.
- Steam networking. Steamworks' newer networking APIs relay packets through the Valve network by default, and P2P connections are relayed automatically when appropriate. The old
ISteamNetworkingis deprecated, so don't follow tutorials that use it. - Epic Online Services. Epic describes it as free, cross-platform services for multiplayer games, and it has a Unity integration guide.
- Rent a VPS. A rented server online is the usual answer for a public game. Luanti's docs recommend a VPS or dedicated server for public servers, since home connections are less reliable, and warn that unprotected public servers attract griefing and spam. For about 10 players on a non-demanding game plus mods, its sizing is 2+ CPU cores, 4 GB RAM, 30 GB storage and 20 Mbps.
- Host from home. Fine for a few friends. You'll usually need to forward the UDP port on your router, and behind CGNAT you can't host a public server from home at all. The Minecraft guide above walks through port forwarding step by step, and the idea is the same for any game.
A realistic first project
Don't start with an MMO. A gamedev.net answer I like says to start by just transferring some data over a network to see how it works, then build up to a game server. Here's how I'd do that:
- Make two copies of a game talk to each other and show each other's cursor. That's it.
- Turn it into a tiny game: two players, one shared arena, collect-the-coins.
- Make the server the boss. Clients send input; the server decides who got the coin.
- Test with fake lag. Roblox's docs suggest simulating a 50–150 ms delay in each direction, because Studio playtests default to none.
- Only then add a menu, a lobby or cosmetics.
Want it the lazy way instead? Build the same coin game in Roblox Studio, where every game is multiplayer by default and the server's already there.
Hosting and creating, somewhere new
Folly is a standalone multiplayer voxel game for PC, free with no purchases required. Player-hosted servers and creator tools are planned to roll out during early access, founding creators first. They're plans, not something you can use today. The details and the creator waitlist are on the hosting and creators page.