Optimization, player quantity and lag reduction

Lag and performance issues are totally expected at this phase in development. So I am not knocking it.

Lag is the worst aspect of MC. I am wondering how much of an issue it will be at release. Oort is already better and doing more than MC.

How many concurrent players will be the targeted goal?

4 Likes

There are two subtly different questions here:

For me, this (lag) can be split into 4 different areas:

  1. Efficiency of the transport protocol: At the moment the game uses TCP. We’ve discussed internally exploring using UDP for some data packages. But the trade off isn’t a trivial selection. If there is time later in development we’ll look at UDP as an optimisation step for some data.

  2. Overhead of the client and server dispatch and receiving services: There isn’t much we can do about the OS network stacks (beyond server configuration) but there are likely opportunities for making the client and server handle networking more efficiently. (Speed up SSL, compression, reduce bundling of data, synchronise more intelligently during the frame, etc) Often with online games simply getting networking working is the priority. But I think we have some decent head room to improve this area.

  3. Physical distance between client and server: Sorry, we can’t do anything about the speed of light. :sunny: + :hankey: = :fist: + :sob:

  4. Mechanism for hiding latency: This is our biggest opportunity. As we’ve discussed in other threads the client does extensive prediction to try and hide the latency. Hopefully the client predicts correctly and when the server finally responds with the actual outcome, no correction is required. If the server responds with a different outcome, the client again does its best to hide the correction. Sometimes the correction is hard to spot, for example, a creature’s position is gradually corrected over subsequent frames. Sometimes the correction is binary, you either did or didn’t die, whoopsie the client got it wrong and snap you’re dead.

Interestingly the client is often able to work with the server and make predictive predictions about entities. The following configurations exist:

  1. Unknown simulation of another player: the client doesn’t know anything about what another player will do. It only knows what it did in the past. So the client can only extrapolate their future position based on their recent movement. A running player is likely to continue running. But the client can’t predict when they’ll stop, or jump, or shoot. (This is why player-player grappling hooks, player-player collision, etc, are latency bound.)

  2. Local simulation: the client can also run a simulation of the entities locally. If the simulation is deterministic, than the client can predict what an entity will do next by duplicating the servers simulation locally. This gives the client a good prediction. But other players can introduce noise into the system that will alter the entities actions on the server. (See #1). But in general if the player is roughly alone, the prediction hides the latency. Blocks will appear in your inventory before the server allows them. Creatures will die before they’re dead. Etc.

  3. Temporal Announcements: the most stable prediction is when the server actually tells the client in advance what will happen. This is a special case where we can (kindof) run the simulation ahead on the server. The server then communicates to the client, the future movement + actions of the entity. This means that when the client is making predictions it already knows that will happen on the server. We can do this for certain larger entities that the players can’t really effect. (Go ahead and read between the lines here - @tahru :wink: cough :dragon: )

In short - we’ve made a big effort on hiding the lag - explicitly because the game is played online. Servers all around the world wouldn’t be possible without attempting to hide the latency. Whilst we know there are still some issues (rubber banding reported by players) - if we were ever to turn off the prediction you would instantly notice the difference, especially on remote servers.

Concurrent players is mainly limited by the simulation cost of the players and the entities surrounding them, and the CPU performance of the server. (So nothing really to do with latency.) Interestingly there is a trade off here, because we want the creatures to do cool things, but this often means more expensive entity code.

However, we’ve designed the game to mainly scale by having more worlds (ie. more servers), rather than by having (fewer) more powerful servers. This is an extremely common model for large scalability online.

At the moment, it’s hard to predict the # of concurrent players because 1. we’re still making the game, 2. we’ve not defined what hardware we’re benchmarking against. I’ve set the team an initial target of having over 100 players per core. Later in development, we’ll share some more metrics about server performance because this will be important for modders and hosts.


UPDATE: Additional important point here. When players (and potential players) beat the development progress of the game up as being too slow - it’s often stuff like this that they don’t see. It would have been waaaaay quicker to not include any prediction. All the combat, ranged combat, block damage + placement, (basically everything) would have been much simpler to implement. But then the game wouldn’t have been scalable to play around the world. You’d not be able to seamlessly walk between servers in EU, NA and Aus. Lots of stuff is going on under the covers.

And yes, that was “way” with 5 a’s.

7 Likes

Thanks for the thorough answer! I realize I snuck in many questions on that one. 100 users per server is more than respectable. Plus, you are deploying on AWS, which can scale geographically as well as in several hardware and network ways.

I can only imagine the technical challenges as lag is not something I have had to deal with beyond slow consumer issues.

2 Likes

That’s how it should be xD

1 Like

@Tahru - that’s an initial goal of 100 users PER CORE. That might be 400 users per world if they achieve that. I’m assuming these worlds will be running on multi-core systems.

1 Like

I guess this is a good a time as any to ask whether the immense lag is exclusive to me. I may have a 1mbps connection, but it still functions in most games. But I’ve literally not been able to play Oort due to lag.

I switch to an item in my hotbar and it goes back to the previous one, I open my inventory and it instantly closes or I try to close my inventory and it opens back up again, I try to build and everything disappears, or I may try to walk but I get stuck/get put back.

Is it just a problem with network optimization, or is it my location? (Arizona, USA)

2 Likes

If the server doesn’t respond to the client within 500ms (0.5 seconds) then the client assumes the response isn’t coming and reverts the prediction. (Placing blocks, switching item, movement - are all predicted.)

As many players can play without this issue (and given the information above explaining that the game is still in development) - I would initially suspect your connection.

Firstly, try playing on the servers closest to you. (Sorry - obvious I know.)

Are you playing via Wireless? This will add latency.

1 Like

Well I seem to be experiencing the issues on all servers, including ones closest to me. I haven’t tested it lately, but maybe I do get less lag on servers closer to me. Unfortunately, I can’t test the game as I don’t have a PSU for my PC, but my computer was previously wired into a router, so I guess you could say I’m not playing wireless.

I’ll conduct some more tests when I have my computer back, so I’ll see to informing you whenever that happens.