Question about 24.5-multiplayer-isometric-mouse (interpolation/prediction)

[eldad87]

Hi, I'm investigating the '24.5-multiplayer-isometric-mouse' example.

The game engine aimed to support interpolation, prediction and lag compensation. In this example, there is no prediction (and interpolation), the client requests (I.e move to tile) are sent to the server, and then the server moves the player.

This example will not work in the real world over WAN. so I wonder if you can advise on how change it to support prediction/interpolation and lag compensation?

Thanks!

[Irrelon]

client requests (I.e move to tile) are sent to the server, and then the server moves the player.

Yup that is correct. The server's movement data IS then streamed to each client and interpolation and lag compensation IS used... is there some part of the code that made you think otherwise?

[Irrelon]

This example will not work in the real world over WAN

Did you have issues running over WAN? The example is using the engine's stream system for interpolation and lag compensation. Can you point to a test you did that failed?

[eldad87]

You're missing the prediction.

This is how the flow should be:

1. Browser: The user 'tells' an entity to move to point (x, y).
2. Client: the REQUEST (1#) is sent to the SERVER.
3. Client: The Engine calculate the Entity's path and start moving it locally. <-- You're missing this one
4. Server: Receive the request (2#).
5. Server: The Engine calculate the Entity's path (take lag compensation into account) and start moving it locally.
6. Server: The PATH is sent to the client CLIENT.
7. Client: Receive the path and interpolate the entity's path/position (take lag compensation into account).

Based on: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

Can you imagine what will happen if a user will have 2 sec latency? I know... you can't play with 2 sec latency... but if you had 3#, the game was less jerky...

Suggestion: I dunno if that's the right approach, but you can add the path-finding to the client as well.

In: 
https://github.com/coolbloke1324/ige/blob/master/examples/24.5-multiplayer-isometric-mouse/gameClasses/PlayerComponent.js

    if (!ige.isServer) {
        // Listen for mouse events on the texture map
        ige.client.textureMap1.mouseUp(function (tileX, tileY, event) {

            var currentPosition = playerEntity._translat
                startTile = entity._parent.pointToTile(currentPosition.toIso()),
                endTile = new IgePoint(parseInt(tileX), parseInt(tileY, 0);

            // Create a path from the current position to the target tile
            var newPath = ige.client.pathFinder.aStar(ige.$$('tileMap1'), startTile, endTile function (tileData, tileX, tileY) {
                    // If the map tile data is set to 1, don't allow a path along it
                    return tileData !== 1;
            }, true, true, true);

            // Start movement along the new path
            entity
                .path.clear()
                .path.add(newPath)
                .path.start();

            // Send a message to the server asking to path to this tile
            ige.network.send('playerControlToTile', [tileX, tileY]);
        });
    }

Eldad.

[Irrelon]

The engine does not include movement prediction, it's not actually missing, I deliberately didn't implement it. The reason is that each game will want to do this their own way. If you're using paths, you'll want to predict that movement via a path instead of a simple direction, if you're using physics it will be force or impulse based, if you're using basic velocity then it will be via a constant speed.

Basically you get to do what you think is best for your game. When the engine receives new data from the server it will take the current entity location and interpolate to the new data destination.

But I would ask again, have you actually tested over WAN? I have tested 10 players from 4 different countries (UK, US, Mexico, Canada) all playing the same twitch-based game without issue. The server was in the UK. The input lag was not noticeable.

From the prediction and lag compensation side of things you are also going to experience very complex issues like, "you shot be but I was already behind a wall" if you use prediction.

I'm not sure how to create a one-size-fits-all solution to this issue.

[eldad87]

But I would ask again, have you actually ...

Yes, a bit jerky.

From the prediction and lag compensation...

Prediction is just prediction, nothing more. The issue "you shot be but I was already behind a wall" - should handle in the following manner: If EntityA shot EntityB, the server need to check how the world looked like in the eyes of EntityA, taking latency and prediction into account. If the server determent that the event actually happened, the server will inform everyone involves that EntityB is dead.

In other words, in many FPS games, any action that involves 2 unrelated entities (I.e controlled by 2 different players) - the results of those actions are always checked && sent by the server and not implemented as part of prediction (I.e hitting a unit and the HP decrease, Killing an enemy etc).

try to imagine how an RTS, that involves 8 players with 100 entities would look like without prediction...

[Irrelon]

I have obviously read all the stuff regarding how FPS games handle these issues, but handling the sort of issue you are raising above is outside of the scope of the engine.

99% of the people using the engine are going to see no benefit to implementing the system and they will all see a performance decrease and memory usage increase. Just imagine a box2d simulation, you would need to "rewind" every action the player took between point A and point B and then apply the physics changes in reverse for each action, then replay everything after applying the change that happened in the past. You'd have to record the position, velocity (and I guess a bunch of other stuff) for every entity in the simulation for each tick to do that, along with every control change such as "user pressed fire" and "user jumped". The engine doesn't know anything about those actions anyway since they are all custom network events. The work involved to implement such a system is staggeringly complex.

I guess what I'm trying to say is that I'm trying to look at the big picture and what 99% of the users will want to do with the engine. The work involved to implement this to satisfy the 1% would be a major cost/benefit fail.

[Irrelon]

Closed due to inactivity.