Making Multiplayer Games Doesn’t Have to Be Difficult
In this article John Payne, one of our Technical Directors, explains some of the inner workings of how Crayta enables multiplayer game creation ‘out of the box’.
Whether it was on an early home computer, or just running around the garden, playing together with friends is often one of our favourite childhood memories. Multiplayer games have come a long way since I started playing them, 2-colour sprites turned into near photorealistic 3D, the multiplayer moved online, and everything got bigger, flashier and more immersive. But throughout, one thing has stayed exactly the same and is as true for me as an adult as it was as a child: the best videogame experiences come from playing with other people.
Whether it’s your first World of Warcraft raid boss with a team from around the world, flossing in a shark suit in Fortnite, or “accidentally” shooting the food your friend needs in Gauntlet (repeatedly), everyone has an anecdote to share that just wouldn’t be the same in a single player game.
But online multiplayer game development comes with a set of ‘hard’ problems that add up to a general view that making an online multiplayer game is difficult.
Why Multiplayer is Hard
One of the key differences between a multiplayer and single player game is that in a multiplayer experience the game exists independently of the player. This isn’t required in a single player experience, where the game and the player’s ‘view’ of the game are often the same thing. The only bits we care about in a single player game are the bits your player can see right now, the world only exists to serve that player’s needs.
“Instead of thinking about the game in terms of the player, now you’re thinking in terms of a world”
In most online games you’re no longer developing a single game application, you’re now dealing with the player’s own local view of the game (we call this a ‘client’, it’s what you run on your PC or console) and a central view of the game (the ‘server’, running in the cloud) which arbitrates, validates and runs all the game-specific logic.
As you can imagine, the objects (in Crayta we call these ‘entities’) in a game start up even before the first player arrives on the server, and their logic continues as players join, leave, and interact with them. Instead of thinking about the game always in terms of the player, now you’re thinking in terms of a world that exists, in which a number of players can play. It takes a bit of getting used to.
Programming
Some of the ‘hard’ problems are there at development time. For example, sending messages across the internet takes an amount of time, so you need to work out how to asynchronously communicate what is happening back and forth, and deal with any cases where your clients and servers get a bit out of sync with what is happening. Just the logistics of running a server on your development PC, running a local version of any other services you’re using (matchmaking, save data storage, etc) then running multiple clients to test a feature isn’t always easy or fun.
Infrastructure
When your game is ready you have a whole new series of problems when you come to try and get it into the hands of players. You need somewhere in the cloud to run your servers, and infrastructure to deal with starting up servers with the right version of the game logic, shutting down the server when its not needed any more, matchmaking clients to servers, updating the whole thing when you want to change the game, and a whole host of other services. And all of this needs to scale if your game takes off.
You also need to work out how and where to store a player’s game data between sessions. In a single player game you’d just stick this on the player’s local hard-drive.
There’s a lot of options for all these problems but each one takes work to integrate and can be expensive for even a moderately successful game.
The Crayta Experience
Here’s an example of how Crayta can make all this a lot easier.
Take Crayta’s ‘empty’ template, the simplest starting point we have for a game; it contains no game logic, no rules, no objects other than a flat floor and a start locator.
When you hit the preview button you see your character appear at the start locator. So far this seems pretty normal, much like any game engine’s default 3rd person setup.
But Crayta’s true power is shown if you invite a friend to come into the editor and preview with you, or publish your game and watch players coming and going, because all Crayta games are all multiplayer by default from the start.
“Even the development environment itself is in the cloud”
That preview of the empty template is running on a server in the cloud and all the server/client communication issues are dealt with for you pretty invisibly. Even the development environment itself is a server/client system running in the cloud, which is why you can have multiple people editing a game at once.
Almost all of the game logic you write in Crayta (or download in packages) is server logic and you can mostly write it without really thinking about that fact.
We deal with transmitting everything to all the connected clients. If you spawn a new object on the server, we propagate that to every client, without you really noticing it happening.
The player’s 3D character is updated on the client (to move around, jump, interact, etc). All this movement and control is fed back to the server which can validate, nudge players that collide, and deal with interacting with other objects. This means you can write server code which effects the players just as easily as you can anything else. For example, if you want an object to explode when players get too close, that’s easy to do because the server knows where they all are, and if you want to do something to the player (shoot them into the air for example) then we deal with propagating that back to the player’s client to update the controls.
Add some weapons from the package store, add a round structure, override the spawning logic so your players start all over the map, and you’ve got a pretty good online multiplayer shooter. (Better still, use one of our shooter templates as a starting point.) Or add some checkpoints and go mad with the voxel editor and you’ve got a multiplayer obstacle course. All of this logic is available in game templates and downloadable packages, and anything that isn’t can be written in Lua.
Occasionally in a multiplayer game you need to write ‘client’ logic. For example, if you want a 2D HUD showing the local player’s health bar, that logic needs to be running on each client separately to display just the local player’s own health on her own screen, otherwise you’d all see each other’s health and that would be weird (or great, I’m not judging your game design). We support this client side logic too within Lua scripts: you can sync variables from the server to the client automatically, or send messages back and forth. By selecting some good packages you never really need to worry about this, but it’s there if you want to dig in.
We deal with running servers for however many people want to play your game, storing save data, matchmaking and all the other services you might require.
That’s some of the hardest parts of making a multiplayer game covered, leaving you to just write the multiplayer experience you want to create without really thinking about all the things we’re doing behind the scenes.
And once you’ve made a game public, it’s there on the ‘Play’ page of Crayta’s navigation menu ready for a community of players to make their own favourite gaming memories.
John Payne is a Technical Director at Unit 2 Games. In between meetings he also develops and maintains the Crayta Lua API.
