Multiplayer Game Concepts

[StOneDOes]

Hi there, 

I'm hoping to start a bit of a conversation regarding multiplayer game concepts using LE. I have read a few threads regarding multiplayer but there are not that many going in to depth, but then I've also seen some videos of what some people have managed implement (such as synced vehicle physics). My game isn't quite at the multiplayer stage yet, but hopefully I'll have a lot of it planned by the time it comes around.

Firstly, I'd like to point out the fact that I like how LE uses a simple "do it yourself" messaging system, as oppose to having that extra layer on top that does the job for you. Not only the more you do yourself the more you learn, but the control over it so much better if your trying to create something like an information bubble.

Sending and receiving basic messages from connection, to chat, kicked, banned etc. are a simple case. But syncing other life in the world becomes more difficult. After working with the Half Life 1 engine for several years I've picked up a few ideal concepts. What I've gathered is, sending messages to update a player's coordinates every time they move is a lost cause. Sending a key press to the server and have the server simulate the player's movement appears like an optimal way to go. The player will press the forward key, and that key press would be sent to the server, and with the server knowing the player's spawn location, it would be able to simulate movement based on this key press. The only catch I've found so far, is when setting an entity to use CharacterPhysics, you use SetInput() to control them. Assuming this is the right way to go, how would you send a key press message to the server if the player input is controlled by the engine? Or is there a more effective way?

Then you also have vehicle physics. I don't have a lot of experience with LE yet, so I'll also put forward this question - does the physics engine have any randomisation in it? Or, if I crashed one vehicle into another, at the exact same spot, same angle, exact same force, will it result in the exact same physical reaction each time? This knowledge would also help fill the gap.

Please share any ideas that your happy to give away.

Thanks in advance.

[Einlander]

5 hours ago, St0nedas said:

The only catch I've found so far, is when setting an entity to use CharacterPhysics, you use SetInput() to control them. Assuming this is the right way to go, how would you send a key press message to the server if the player input is controlled by the engine?

You simply send the key input and mouse input  to the server as you were thinking. The server does the setinput, gets the new location of the player and sends it to the client.

[Crazycarpet]

14 hours ago, Einlander said:

You simply send the key input and mouse input  to the server as you were thinking. The server does the setinput, gets the new location of the player and sends it to the client.

That's not quite as simple as it is as this would cause a huge rubber banding effect due to the latency... this is where concepts such as client prediction, and server reconciliation come in. Essentially you make the client simulate his own movement as usual, and while the client receives movement "results" from the server (i.e: the end-position the server got after simulating the movement) you'd interpolate the client towards the servers result.

Valve has some awesome write-ups on how they handle reconciliation/prediction and interpolation I suggest giving them a read!

Another great article is http://www.gabrielgambetta.com/client-server-game-architecture.html

20 hours ago, St0nedas said:

Firstly, I'd like to point out the fact that I like how LE uses a simple "do it yourself" messaging system, as oppose to having that extra layer on top that does the job for you. Not only the more you do yourself the more you learn, but the control over it so much better if your trying to create something like an information bubble.

I'm going to have to disagree with you there, I think you'd find you have much more freedom using raw ENet and writing your own high level functions over it as lots of the necessary things you'll need are hidden behind tons of abstractions in the Leadwerks networking library (which is really just ENet hidden behind simple abstractions). ENet is well documented... the Leadwerks abstractions are not, you're going to have a hell of a time figuring things out.

IMO, most the features in Leadwerks were made with love & care, and well though-out... Networking in LE seems like it was mashed together over night with minimal thought put into it.

20 hours ago, St0nedas said:

Then you also have vehicle physics. I don't have a lot of experience with LE yet, so I'll also put forward this question - does the physics engine have any randomisation in it? Or, if I crashed one vehicle into another, at the exact same spot, same angle, exact same force, will it result in the exact same physical reaction each time? This knowledge would also help fill the gap.

Newton Dynamics is a quite physically accurate physics engine (as far as physics engines go) they rarely use made-up numbers, every number in their physics equations are there for a reason and originated from something "real".

However, like every other physics engine... Newton is non-deterministic... different FPUs handle the floating point numbers differently and can store them with different internal representations, leading to slightly off results. You can not rely on the fact that the outcome of this "crash" will be identical... however if the parameters that lead to the crash are as identical as they can be you can except a quite similar result which is where client prediction/reconciliation comes in. You know the result the client produces will be both smooth, and close to correct... so the reconciliation won't be very noticeable.

 

Honestly, these topics can range from very simple to extremely advanced depending on if you care about cheaters (if not, just spam unreliable messages updating the clients position w/ the position they say they're at!)... Only advice I can give is start simple and then read articles like the ones from Valve, and the one I linked above and try your best to come up with a nice solution to keep entities in the world in sync without getting visible banding from the latency!

I personally haven't been able to get smooth client prediction results with Leadwerks for some reason... most likely because I never understood how SetInputs worked correctly and gave up before learning more about the LE character controller. However I did come close! I think as of right now everyone is just using a unreliable channel to receive the position of players/vehicles from the client... and trusting that result. (This is dangerous however, because a client could make a teleport "hack" by sending a fake position to the server.)

The reason people tend not to go in depth about these topics is because there's no "global solution" that'll work nicely for everyone... you have to decide what kind of game you want to make, and come up with a solution that's best for you!

[aiaf]

Do it the simple way first, too see what problems come up.

 

From valve:

https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization