DIY vs Spidermonkey

[Darkchaos]

Hello Monkeys
I recently thought a lot about network programming and how an protocol could look like.

I started off with java’s default serialization and then dropped it quickly again as it had a huuge overhead.
I came up with the following: Each Paket has a paket_header, which is something like:

class header {
        public BYTE msg_id; // 0..255 -> 256 different Messages, instead of using .hashCode() which is unreliable and too long!
        public int paket_length;
        public BYTE compression_type; // RLE, Huffman, etc.
 }

I clearly see why it’s hard to have such highly compressed headers in general purpose (on the other hand I read that spiderMonkey only needs 2 Byte for the Classname? )

So Question Number One: Is spidermonkey roughly comparable with such a manually developped protocol or is it rather for games to provide “something” where speed is not that a matter?

Furthermore I’d also include something to only send the differences between the Class-Instances (When a Player moves, there is no need to re-broadcast it’s hp, level, name, …)
I could use Spindermonkey for it, in a way I just define several messages. Is there something premade in Spidermonkey already?

What do you think? (In General, I’d go for the own protocol, to know what’s happening and for the fun of programming. On the other hand I really like things like the already implemented voice chat and streaming files etc.)

And the last Question is about the movement and anti-cheating-mechanisms:
In general I see two options:
a) The client sends the sort of key presses and the server calculates the reaction and simply set’s the Players translation (That could get highly laggy but work)
b) The client sends the new position and the server compares it to the old position and the time between the last update. I would need raytracing and collission. If he’s gone too far, he speedhacks. This would have a really smooth movement and the server would only send new positions if the player got teleported and kick him if he’s gone too far.

Do I maybe simply care way to much about cheaters? I mean it’ll be some kind of racing game and if someone throws on CheatEngine, the Fun is gone.

[pspeed]

Use SpiderMonkey. You can heavily customize how your messages are sent but 99% of the time you won’t need to. Networking is hard to get right… the previous version of SpiderMonkey (before I rewrote it) didn’t even get it right. Better to leverage someone else’s work really. NIO selectors and threading is extremely fragile.

You can send just changes. To do so you’d have to send change messages… but then I’d argue that you really want an Entity System because that’s pretty much what it deals with… changes. (See: Zay-ES)

You shouldn’t send player position to the server. The server should be authoritative. It’s really the easiest way.

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

And you can see the end of this thread which has devolved into a similar discussion:

Zay-es network update time

It’s… complicated. I may have described it before. At some point I’m going to attempt to make an open source project out of some of the networking but time keeps getting away from me and it may turn out that the compression I use is Mythruna case-specific. Or rather, it may turn out to be difficult to have different zone sizes than what I’ve picked. But beyond the compression stuff, on the server I collect position (including rotation) updates for moving objects every frame. Every 200 ms or…

[Darkchaos]

I already saw your reply on the other (ES related) topic and read through valve’s article (the first one at least).

The Server is authorative but he “only” verifies the calculations done by the client using the average speed and a Line of Sight check. That way the server has less physics (Like all the vehicle related stuff).
The Main Reason for doing it that way is yet another: Compare WoW to any Source Engine Game in case of a heavy lag. The Source Engine prevents your from walking around, you rather lag around. In WoW you can move freely but simply get no confirmation for your spell calls.

That way, there is no delay in the players movement (whereas valve’s way includes three packets being sent and waited on).

I am just wondering whether that leads to some problems regarding the Interpolation. If I got it right, the client interpolates the movement of other players according to their velocity and then “sets” the position once he got the right one? Doesn’t that lead to a stuttering (In case the interpolation is not right, e.g. when the player stops to move right after the server broadcasted the packet?)

And another thought: You wrote, that what one does see in Valve’s approach is a ~ 100ms delayed render of what is happening? How could I ensure a FPS to still work (e.g. when the interpolation is wrong and the bullet is acctually missing the target as it has moved?)

Or do I care too much about that, as nobody would notice it? (Actually when running at “tickrate 66” I have twice the rate of my physics engine and maybe my draw loop. That being said I only use half the data that comes in over the network, so the bottleneck is somewhere other?)

[pspeed]

You should read both articles as they cover a lot of this.

WoW is not really real time. They don’t even use UDP. Any “shooting” is done at a target and not “in the wind” so real time feedback is not necessary, ie: it’s not like “shoot in this direction and calculate hits” it’s “shoot at this mob” and so it matters less that the mob may have moved.

You should decide what real time requirements you actually have before deciding on a specific solution, I guess, as it makes a pretty huge difference.

[Darkchaos]

Sorry for the late reply, I am in the studying phase and only Monkey when I have the time to
At the moment it’s just some general thinking but in general I like it when you can move whilst experiencing lag.

I currently have a project in the works which might get Multiplayer Support. It is basically a racing game, so it would need the FPS-ish Solution (with UDP and all), I guess?

What would happen if I don’t delay the rendering by 100ms? Would I be “out-of-synch” like shooting were nobody is standing? And that thing with updaterate to estaminate Clients Connection, do I really need such stuff or is that only for perfection?

[pspeed]

@Darkchaos

What would happen if I don’t delay the rendering by 100ms? Would I be “out-of-synch” like shooting were nobody is standing? And that thing with updaterate to estaminate Clients Connection, do I really need such stuff or is that only for perfection?

If you don’t delay then you have to predict… and that’s in general way more complicated than simply interpolating known values. I’m pretty sure that was discussed in those articles, though.

You have to delay or predict because if you don’t delay then you will be working on old information and so must guess where the other players might be.

Especially for a racing game where the chain between action and noticeable result is so long, you could get away with even larger delays than 100 ms. It’s not as much of a twitch game as an FPS.