Friday Facts #83 - Hide the latency

[slpwnd]

Overview of how we try to hide the multiplayer latency: http://www.factorio.com/blog/post/fff-83

[ataaron]

Hello I have a question about how this will work:

What if someone places a wall right in front of where he can see you walk
will it look like you run through the wall to the other person
or will you be teleported back to where the wall should have stopped you ?

[provet]

Hello I have a question about how this will work:

What if someone places a wall right in front of where he can see you walk
will it look like you run through the wall to the other person
or will you be teleported back to where the wall should have stopped you ?

From Todays Friday facts:
(From Latency State)
"So what happens when there is user action collision? Let's say a player starts moving (in latency state) and then some other player builds an object in his way. Because of latency hiding the player starts running immediately. However when the tick, in which the object is built by other player, is processed, the player will seem to be "teleported" in front of the object and stay stuck there running into the object."

[Kikinaak]

It sounds to me like you need to narrow down what each client needs to know. My client doesnt really need to know the contents of a belt thats 5 chunks offscreen. If I zoom out or go to the map, I start losing detail the farther out I zoom. Maybe update the chunk directly around the player every tick, like if new items have come in on belts or a new biter has wandered in, but less frequently the farther out you go. Like that belt thats 5 chunks offscreen, if its updated at all, might only get an update once every 5 ticks. If I move over to it, then once I'm in its chunk let it update every tick.

Update interval based on distance will still let players have a vague idea whats going on in the world, without overwhelming the connection with non-critical info every tick. Damage alerts and player chat are high priority. building alerts for missing items, not so much.

[DaveMcW]

It sounds to me like you need to narrow down what each client needs to know. My client doesnt really need to know the contents of a belt thats 5 chunks offscreen.

When the boiler 5 chunks offscreen that powers your entire base gets destroyed by biters, you really need to know.

[provet]

It sounds to me like you need to narrow down what each client needs to know. My client doesnt really need to know the contents of a belt thats 5 chunks offscreen.

When the boiler 5 chunks offscreen that powers your entire base gets destroyed by biters, you really need to know.

might only get an update once every 5 ticks.

is less than a second as far as im concerned = Lots of time to react, delays may be more of a concern!
Also some thing could be flagged as important and ignore the low-prio-what-clients-need-to-know-mcthingy.

TL;DR I think this is a great idea for optimization!

[DaveMcW]

Also some thing could be flagged as important and ignore the low-prio-what-clients-need-to-know-mcthingy.

What if the belt 5 chunks offscreen was carrying ammo to defend the boiler? Everything is connected and important.

[Kikinaak]

Let me clarify here, what I'm saying is the CLIENT doesnt need to know whats happening 5 chunks away, just the server. I'm not saying the server shouldnt process the whole world. What I am suggesting is the server be a bit more selective in what it pushes to the client each update. As DaveMcW says, everything is connected. And to answer the question, that belt would still be moving ammo where it needs to be. Also please note the end of my first post. Damage alerts (and chat) should be high priority no matter how distant.

Now say you are on the edge of a huge sprawling factory, near a defensive line of turrets. That ammo belt starts a few chunks distant, and is carrying bullets to the turrets you are near. What would happen in the model I suggest is, the server keeps track of the whole belt (as well as the whole world) but your client only needs to see the bullets as they come into your visual range, not all the way back to the start of the belt. As far as the player would see, bullets are coming onscreen, moving to the turrets, and being inserted as normal. As far as the network sees, its taking much less traffic to put it on the players screen.

This has an added side effect of stopping a form of cheating once pvp really starts rolling. Your client wont have all the info on the enemy base, position, numbers, and resources where you can sniff it from memory. Factorio players are nothing if not creative with their solutions.

[Bedders]

I'm loving the sound of those dedicated servers Got a box all ready set up to load it onto!

Keep up the good work guys, I'm loving the progress that this game has made since I purchased it!

[Xeorm]

Let me clarify here, what I'm saying is the CLIENT doesnt need to know whats happening 5 chunks away, just the server. I'm not saying the server shouldnt process the whole world. What I am suggesting is the server be a bit more selective in what it pushes to the client each update. As DaveMcW says, everything is connected. And to answer the question, that belt would still be moving ammo where it needs to be. Also please note the end of my first post. Damage alerts (and chat) should be high priority no matter how distant.

Now say you are on the edge of a huge sprawling factory, near a defensive line of turrets. That ammo belt starts a few chunks distant, and is carrying bullets to the turrets you are near. What would happen in the model I suggest is, the server keeps track of the whole belt (as well as the whole world) but your client only needs to see the bullets as they come into your visual range, not all the way back to the start of the belt. As far as the player would see, bullets are coming onscreen, moving to the turrets, and being inserted as normal. As far as the network sees, its taking much less traffic to put it on the players screen.

This has an added side effect of stopping a form of cheating once pvp really starts rolling. Your client wont have all the info on the enemy base, position, numbers, and resources where you can sniff it from memory. Factorio players are nothing if not creative with their solutions.

Remember, they don't have a client-server model here, and instead are using a client-client system. In order for each client to update itself, it needs all the input information from the other clients so that it can then update the actual game state. Using this method, all any client gets information from is what the other players actually did, and no actual game state information is passed in.

Or, in other words, none of the info on ammo location or existence is transmitted. Instead, the other client sends the information that the player removed one belt piece, and your client can now process that because the belt has a hole, that the ammo isn't moving, same as it would if you yourself had removed the belt.

[Ailure]

Latency hiding is quite important in multiplayer, as i found that was the biggest annoyance with multiplayer. Playing with a latency of 200 ms was possible but every action felt sluggish, hiding that is really nice and i don't think people would mind the occasional teleport from minor conflicts such as a friend plopping a wall in front of you just at the right time.

People might be intrested to see how Valve shooters do lag compensation (technical article) as an aside, and why you don't miss targets in shooters even with higher latency. I don't think it would be easily applicable to Factorio battles, especially since it involves having the server keep the gamestate from a few "ticks" back (and factorio gamestate is huge).

OpenTTD actually works similar to Factorio in that the world state is only sent when you join the game (and when you need to resync I think?), but other than that the only thing sent between players are the player commands. I don't know many games that have similar model to Factorio/OpenTTD but I believe some traditional real time strategy game does.

[kovarex]

OpenTTD actually works similar to Factorio in that the world state is only sent when you join the game (and when you need to resync I think?), but other than that the only thing sent between players are the player commands. I don't know many games that have similar model to Factorio/OpenTTD but I believe some traditional real time strategy game does.

Yes, basically all rts games.

[Kikinaak]

Remember, they don't have a client-server model here, and instead are using a client-client system. In order for each client to update itself, it needs all the input information from the other clients so that it can then update the actual game state. Using this method, all any client gets information from is what the other players actually did, and no actual game state information is passed in.

Or, in other words, none of the info on ammo location or existence is transmitted. Instead, the other client sends the information that the player removed one belt piece, and your client can now process that because the belt has a hole, that the ammo isn't moving, same as it would if you yourself had removed the belt.

If this is correct, then my suggested model would be impossible to apply, and my wall O text should be ignored. My bad.

[nours77]

hello,

Funny, if i remeber the friday fact 76, when you announced the use of p2p, i was with some peoples worry about this... lags. Still good for P2P ?

I read in your futur plans, there is some thing i don t hunderstand, you would do like a multi in other game, one host, the others join... ok, it s lag when all players send to file to them, then it s better to sacrifice one as all, the poor who host gain all the lags... is your plan ?