Multiplayer Network Communication (CS-Source, HL2)

[stoneCold]

Hi there,
Today I read an interesting article about the Source Engine (Half Life 2, CS-Source, ...)'s multiplayer network communication which I found by chance with google.

the links to the article...
English / German

In special, this part of the article sounded really interesting to me (maybe because I don't really have a good knowledge of the today's standard network communication of games )

......
A client receives the current world state from the server and generates video and audio output based on these updates The client also samples data from input devices (keyboard, mouse, microphone, etc.) and sends these input samples back to the server for further processing.
......

these few simple lines confused me a little bit because I always imagined this to work a bit different ,
here comes my "imagination" of network communication and the way like it really works (...maybe just in the Source Engine??)

here the two diagrams...

I hope this will cause a litte discussion, because in the next days I'll start to write the net code of my project. So some ideas, pro's and con's of these two methods are very welcome...

Thx and greetz
stoneCold

[regress]

The problem I see with your thoughts is you're trusting the client to authenticate its moves, which is a huge no-no in online games. When people write bots or compromise the clients, then the client will simply send in arbitrary movement commands, and in effect the player can transport, run super fast, or whatever else they might like to do.

Source's way is tough on the server, and probably tough on lag as well, but the clients are only allowed to send in their relevant movement since the last update, which the server will check to be within the realms of feasibility (no can move 100 units in one update when they should normally move 2).

Anyway, just dropping a few thoughts...

[johnhpus]

I'm not sure that's correct. You run into people using speed hacks on CS fairly often. To me the question is why -isn't- the speed the player is moving at and other such factors checked by the server. I also think that the actual loss of accuracy due to recoil could be done on the server instead of the client to eliminate those types of hacks.

I know I'm probably missing something, because the guys who made HL2 certainly know what they're doing, but I'd pay almost any cost in lag or lack of servers to help cut down on Counter Strike cheaters. God how I hate them!

[stoneCold]

The problem I see with your thoughts is you're trusting the client to authenticate its moves,...

I never said that, my idea for this problem is to simply subtract the two last player positons... then you get the actual speed of the player

Code: Select all

speed = currentPosition - formerPosition

and if this speed is higher than the desired speed, you could send an error to the client ("You are cheating" or something like that ;-D) or you could reduce the player's speed to regulate it. (Just an idea, maybe this is not good enough for games which require exact movement like CS, but I think it might fit the needs for a RPG or something similar).

Source's way is tough on the server, and probably tough on lag as well...

...now a question comes to my mind...
Is it necessary to do all player interactions with the world over the server, or ... what could be (safely) done on the clients side, where is the border between safety and *insane* safety

Is it necessary to do every physic calculation on the server..? What would be if I want to collapse a whole house with my physics engine,which is absolutely no problem on the client, but when such huge data masses are sent via the network, the whole feeling of the game would get laggy..!?!

---> I for example, recognise such *laggyness* in CS Source, always when I run against a barrel or shoot it, there's a little delay before it even begins to move, but then it quickly falls down.
This really looks weird, for me...

*please, criticize me and my thoughts, I can handle it *

[edit]:
Just a little thought again, how will I have to program a throw of a grenade:

Code: Select all

a) [User mouse klick] ---> [message: "User klicked mouse"] ---> [Network] ---> [Server receives message] ---> [Server decides to do a throw, calculates it and sends back data to client]

that's how I understood it from the article of Valve,
or

Code: Select all

b)[User mouse klick, client decides to do a throw] ---> [message: "User wants to throw grenade"] ---> [Network] ---> [Server receives message] ---> [Server calculates throw and sends back data to client]

The idea behind this question is, if just the *real* input of the user (such as keyboad, mouse, joystick, ...) is sent to the server (then almost every decission would be made on the server ), or could I send a request for the effect which will result from that input?

stoneCold

[Chris Jones]

Source's way is tough on the server, and probably tough on lag as well, but the clients are only allowed to send in their relevant movement since the last update, which the server will check to be within the realms of feasibility (no can move 100 units in one update when they should normally move 2).

Source's way cant b too harsh on the server/lag because my connection isnt that great but i can still play CS:Source perfectly online. and im not always nessessarily playing on a powerfull server with a very fast connection. Even playing with 64 players on the 1 server runs well.

the way i would have thought to do it, would be to be able to move your player around like you would in a single player game, and upload your position to the server and retrieve updates on everything elses position. otherwise (like in some games) you end up jerking backwards and forwards

[stoneCold]

@ Chris Jones: that's exactly my idea how it would work (I'm glad I'm not alone with this one )

stoneCold

[Chris Jones]

if i were you, try out your method, if it doesnt work that well, try it the way Source does it, and see which is better

[Praetor]

Cheating is always a big deal, but I think the latest trend is less runtime checking on the server-side and more anti-cheating devices like punkbuster. Often your copy of the game is authenticated on connection, then once authenticated you can play as normal. This means less slag on the server.

I'm looking at networking for my game and I chose ICE. The idea is RMI, so you treat networked players like local players. So that stuff you practically just call as normal (like updates and such). The second idea that I think follows closely with your view of how things are working is "ghosting."

Somewhere you have a game-state. Mine is located around something called an Area (which contains references to other state like things). So, once you have this state, you can "ghost" it across the network to its counterpart on the other machine. You can even do this over multiple updates. The client machine keeps chugging, updating graphics/sounds to match whatever state it finds. It doesn't need to care that some network code and not local logic is responsible for the updates. voila!

[DrEvil]

Halflife 1,2, quake3, enemy territory, work this way. The client streams input data structures to the server at 20 or so updates per second, the input data contains the clients view angles, a bit field of button presses, the game time the update was from, and various other information. It's a pretty small data structure. The server uses it to update that players character. Client side prediction allows the clients to move themselves in advance to eliminate the feeling of input lag, but ultimately the server is still authority. With all client input in mind, the server will send world state information to clients only for entities in their PVS(potential visibility set).

These games don't let the client tell the server where they are. speed hacks are done differently.

Propogating data for physics isn't and bandwidth intensive as one might think. I believe nearly every physically heavy game relies on their physics system being deterministic, meaning that given the same input, the same output will be produced. At that point it's just a matter of giving the client the same input and letting each client locally simulate physics. It's probably not perfect, just good enough.

[Praetor]

Yes all this sounds about what I was thinking, and well within reach when I'm armed with ICE. The thing I'm wondering about is the PVS. I figure its easy to stream any world state info back and forth, but somewhere I'd want to only give the client what it needs. Previously I just figured, heck give them the whole state, but I eventually want to have a pretty interactive, large, and evolving game world (ok not too large, but...) so I'm wondering how one usually determines the PVS server-side.

[Chris Jones]

im not sure how its actually done, but would it be possible to somehow have some kind of quadtree or other way of knowing what objects etc are in what areas of the map. the information about those objects are sent if you are within a certain distance from that area?

im not sure how well that would work, or if it would work at all tho

[DrEvil]

It would probably depend on the structure your world in stored in. With BSP and portals and such you can pretty efficiently test different areas for visibility.

Alternately you could precompute the pvs for various areas of the map, possibly into a bit field where you can just examine the players section and the each element of the bitfield set to 1 has potential visibility with other map sections, where the bit could correspond with the index of the area. I use this type of approach with boost::dynamic_bitset to pre-calculate waypint visibility for my bot.

[Praetor]

See the problem I see is there would be extremely heavy pre-computation, or else you need a hook into Ogre's culling method. That would be the best actually. If you could Ogre to do the visibility testing for you...

You see it just seems outrageous to have to do visibility culling twice or three times (one for graphics, networking, physics)...Do it once and nab it for the other modules. Hey Sinbad, any way to easily and unobtrusively get Ogre to tell me which things are visible?

[makeshiftwings]

A lot of physics is done client side in these games; especially physics that has no real game effect. For instance, ragdoll physics on corpses that go sailing through the air: it doesn't matter if the limbs move differently through the air on every client, as long as the final position at rest of the body is the same on all of them (and even that doesn't matter in many games). Similarly, since most of these games have their physics just for prettiness with little actual use (I'm looking at you, Doom3), they can do all the in-depth physics client-side, and the server can just do a broad, less accurate physics calculation to determine where an object ends up when it stops bouncing around.