Welcome to the world of game network programming :) it's an exciting place!

Yes, you have to be more-or-less real time, so you must compensate for latency, unreliable/slow connections, jitter, etc. If you're used to the web and the request/response model, you have to throw all of this out the window. The 200ms delay "hack" is pretty much standard practice, the window will differ from game to game (smaller in FPS's), but it's usually there.

Most games use UDP, since transmission of any single package doesn't have to be reliable, and in case some packets are lost, it's cheaper to re-calculate the state diff and resend one slightly larger package instead of two (or more) standard-size packages. Sometimes this can result in a "blink".

With sending around seeds and other "secret" data, you have to make a trade-off, since sending too much allows for cheating (map hacks, wall hacks, etc), but sending too little will create unpleasant surprises (enemy "teleporting" from around the corner).

Also often it's cheaper to run most of the calculations on the client (even including the critical stuff like hit tests, damage calculation, etc), and only occasionally verify the results on the server - especially in MMO's. Clients that are found suspicious get verified more often, and eventually get penalized / kicked.

Source: never actually wrote a networked game, but love reading about this stuff.

Am network game developer for over a decade. Stuck in desync. Send packets.

> Source: never actually wrote a networked game, but love reading about this stuff.

Got any favourite sources where I can learn more? It sounds pretty interesting!

Sorry for a late reply! Some good starting pointers:

https://www.gamedev.net/ https://www.reddit.com/r/gamedev/ https://www.reddit.com/r/truegamedev/

Some interesting case studies are anything by Id Software (Quake etc), and Lineage (that's mostly tales of a friend who is a hardcore player and a developer; he'd have the relevant source code open in a separate window while playing).

Cool, thanks.

No, most games don't do it this way now. When I created this type of networking in 1994 it was to solve the particular problem of lots of units and low bandwidth. Now where bandwidth is much less consideration games typically use an authoritative server (even if that server is a 'headless' process that runs on a machine with a client). All clients send turns to the server and it sends out the authoritative results to all the clients. Unreal and Unity both have some documentation I believe on how their networking works at the high level - they are really adequate for most cases.

Some links:

https://news.ycombinator.com/item?id=2084276

Unreal Networking Architecture: http://unreal.epicgames.com/Network.htm

88 points by jbrennan on Jan 8, 2011 | 12 comments

--

Creating a simple multiplayer example: https://unity3d.com/es/learn/tutorials/s/multiplayer-network...

I need to start saving HN goldmine threads like that as well. Thanks

There are still limitations to this architecture and instances when you have to run something else. If I would be doing an RTS with thousands of units, I'd still prefer the lock-step version described above, for example. Or, for a more concrete example, right now I'm revamping multiplayer architecture for a game with a huge open world — and the only way to get it to work without paying for dedicated server farm is to run a distributed authority key-value storage.

It depends on the genre and the specific game. RTSs can do it this way and some fighting games do, although some fighting games use a variation that involves predicting player input and rewinding the game state on misprediction in order to reduce perceived latency. FPSs tend to use a totally different model that involves sending only the most recent relevant information to each player and trying to balance server authoritative cheat-prevention with allowing clients a little leeway in order to make the twitchy gameplay feel better. There's a great paper on Tribes' networking model that is still largely relevant for FPSs.

For reference:

https://archive.org/details/tribes-networking-model

I believe wow (and most MMO's) instead take input from each player and run the simulation completely on the server. Although often enemy and NPC positions aren't synchronized exactly between players. There's also much more tolerance for latency in crowded situations - it doesn't really matter if the ~30 other player characters lag behind their actual position in a town by even 5 or 10 seconds, you only need players in your party or who are fighting against you to be low latency.

This is essentially the way eve online does it (or did when I last played). The simulation is entirely server side, the client interpolates and every so often gets the authoritative version from the server. You always knew you’d dropped when your ship would still be flying around shooting at things but wouldn’t take any input.

They had another interesting wrinkle to make it handle huge populations. Having enough players in the same region would trigger “time dilation” and slow down the simulation. In a big fight (thousands of players), it could take 10 real minutes for one minute of game to pass. It made big battles a slog, but at least they were possible.

My understanding was that WoW would do essentially what's described here for the player's character and entities in the immediate area (simulate them for the next few frames), but the server also maintained a view of the world. The client would occasionally sync with the server, and that's when you would see the blinks.

If you're curious, this[0] is an actively maintained implementation of a WoW server.

[0] https://github.com/mangoszero/server

I worked on a big commercial MMO engine for about a decade.

In our implementation, the player runs ahead on the client (client autonomous) but server verified (actions replayed on the server). The new authoritative server position for the player is sent back to the client, and the client replays whatever player movements last made since the response to a movement is heard back from the server, with the player resynchronizing to that point in time where you moved against server objects and playing forward from that point transparently; the client (and server) maintain a short queue of movement history for each moving entity. Thus, if you ran into something on the server but it didn't obstruct your movement much, you would tend to blip much less. The physics framerate was very low compared to graphics framerate, and there would be some degradation in updates received on the client by distance as throttled by the server based on area of interest management. Position updates represented most of the bandwidth of the game. Everything is UDP based with different forms of reliability options on top.

NPCs were "server authoritative" and their actions are replayed on the client. Interpenetrations are resolved via rigid body physics resolution on the client if something blips, but the server is ultimately the source of truth (nothing can interpenetrate on the server), so if a rigid body resolution on the client doesn't resolve some condition, the eventual resynchronization of player position from the server would make it happen at some point.

It worked out pretty well most of the time; certainly you can construct many scenarios where it goes awfully bad from the perspective of a client (on the server everything is always fine), but we preferred the illusion of immediate feedback/low latency versus this queuing up everything to take place N milliseconds in the future, and we didn't need exact reproducibility between clients, just eventual (and hopefully pretty quick) consistency.

Were there collisions between players and players/NPCs? Or only on terrain.

It's mostly rts can afford that model due the relaxed requirements on input frequency.

Many other games require higher frequency such as driving, shooting and anything that has physical simulations.

They instead use prediction and reconciliation and aim for the highest update frequency

Counter strike has servers at 120hz iirc.

Here’s some pro/cons of the approach http://www.gabrielgambetta.com/client-side-prediction-server...

edit: try the live demo too http://www.gabrielgambetta.com/client-side-prediction-live-d...

Reminds me of this GDC talk:

http://schedule.gdconf.com/session/8-frames-in-16ms-rollback...

Similar approach, with some extra fanciness (you see the input at a fixed delay, always, and roll back if necessary to handle mispredict).