I know how building a solo game works, with models and interactions coded, but how are games made so that those interactions happen on many players screens with just tens of milliseconds of difference. Is it code or is it putting your game files (models + code + whatever else I am missing) on a server that can be accesed by peoples devices?
In: Technology
For slow games (turn-based or whatever) you can just run everything on a server and let the computers of the players know what happened as result of their actions. For faster games that doesn’t work. There the game runs both on the server and the computers of the players. Your local version will try to predict what happens as result of your input (e.g. you jump if you hit the jump key), and later check with the server if that was the right result. Usually that will agree with what your local game made. If not (let’s say another player prevented you from jumping in some way), you might suddenly find yourself at a different location in the world.
Generally the game client and assets are on your computer, and you are sending/receiving packets of data to a server, which handles getting them to the other players, that describe your actions.
For instance, if you turn your character to face north, it isn’t sending the whole model, it just sends some data that describes you/your state. IE. for some top down game like the original Zelda
{
player: “Charming_Possesion6”
, location_x: some number to show where you are left/right
, location_y: some number to show where you are up/down
, rotation: Up
, current_health: 10
, max_health: 10
, player_model: whatever avatar you choose
, etc..
}
and the game client on your computers knows how to take that sort of data and render each other player it has data for.
Essentially it’s like when you’re loading a movie on a streaming service: it buffers between you and the server. The servers are located depending on where the gaming company hosts them (typically several servers around the country), and you connect to the server that is closest to you geographically. When you’re in one area of the game, it loads the code/models for that area of the game in packages, which are temporarily downloaded to your PC/console. When you move to another area of the game, it downloads the packages again for that area and either deletes the previous area’s packages or keeps them on to reduce buffering/redownloading if you go back to that area (depending on how the game is coded).
It’s a constant connection between you and the server, that’s why when a lot of people are online and playing/connected to any one server, it may exceed the server bandwidth and cause lag in the game. You’ll be disconnected if the server is overloaded, and when you reconnect, the game may choose a different server location depending on the ping (server response time between you and it, with lower millisecond ping being favorable for a faster response) to reduce lag.
Start with a server/host and clients/players in mind.
Run everything that matters on the server in slow ticks. Run everything that doesn’t matter on the client, like particles.
The player, even in single player, sends it’s inputs to the server, the server does stuff, and sends back the result. The client interpolates between states for what it displays. Stuff that doesn’t matter, like walking forward, can be pre shown on the client, but if anything changed on the server you will rubber band back.
The client can run the same code as server for collision checks and stuff for movement, instead of purely waiting for the server to send back confirmation that you could walk forward. But the server state always overrides.
All that’s sent from client is what they are trying to do. Server sends back the effects, and other changes, like other player positions, bullet positions, placed blocks, etc. Generally you limit this to absolutely necessary information, like just enough to reconstruct on the client.
Maybe player pos, orientation, a list of actions
if you build your solo game correctly, everything in the world can be described by position and state. so a player might be at x,y,z, and 10 seconds in to doing animation 5.
that information is all that needs to be sent to the server, and thence the other players. They already have all the models, they just have to make a “player” with that state and it works.
A simple way to think of it is that the server is running the game too just like you’re running the game on your machine and other players are running the game on their own machines.
When you make your character jump on your machine, it sends data to the server to make your character on the server jump, and the server in turn sends data to the other players to make your character jump on their games.
Internet communication is very fast, even in the slowest conditions it will only take a few milliseconds to communicate between two computers at opposite ends of the world. And even when a fraction of a second is still too slow to make smooth gameplay, there are ways to hide the lag, such as predicting what happens before it actually happens on the server (for example, when you shoot a projectile it will look better if you shoot it immediately instead of telling the server to shoot and waiting for the server to tell your character to shoot. The trade-off is that your projectile might not follow the same flight trajectory as the actual projectile that was shot on the server, so it all depends whether you want more accurate results or smoother gameplay)
There is almost always one master copy of the game running on a server somewhere (or on player 1’s computer). That master copy will connect to all the players (clients) and ask what they want to do. At that point, it’s not that different from a local multiplayer game: player inputs command, master copy knows what that command does to the character they are in charge of, and everyone’s positions are updated. The main difference is that the master copy then tells the clients what it thinks the field looks like and their versions of the game are expected to check to make sure the world looks right.
Sometimes the clients think they did a thing, but the master copy believes otherwise (Player 2: I totally made that jump! Player 1: no I was dismantling the bridge at that time and you fell) and that can cause players to “rubberband” into the “correct” position when the clients have to correct themselves.
Games also can get clever with fixing discrepancies. I was watching a video a few years ago where a certain game had special logic for when a sniper believes they got a kill, but a defender dodged at the last second on their end. The game decides the sniper had the more accurate representation of how well their shot was aimed and gives them the kill, but it then plays a special death animation for the shot player to let them know their juke almost worked, but they didn’t start in time.
Latest Answers