Friday Facts #43

[devedse]

Spoiler added by FreeER for length

You mention player D being a relay for player A who disconnected. There is another method of handling this.

A Host.

In fact any serious multipler game would not be peer to peer as the way you described it is now, you'd have a dedicated server instances, either with player A on it, or no actual players at all. (Which is what I'd hope to see eventually, because I run instances of Minecraft and Terraria using a dedicated server on a nettop computer sat next to my router.)

Lets say in your example, player B is the host. in this case, A talks to B, and B alone, B talks to all 3 of the other players. Still assuming player D is 1 tick ahead, the "Tree was cut down in tick 101" would not be an issue, because B is still in tick 100, and the tree is not cut down, and therefore D never gets the "Tree is cut down" command in the first place.

But then you might end up with other problems, which would be real issues even in your existing setup. Internet lag, expect latencies as high as 2 seconds, I'm not kidding, I game with a guy in oz, and I'm in england, literally oposite ends of the earth, and it is impossible to get a ping to him below 400, pings as high as 650 are common, and 1000 isn't unheard of.

That's 60 ticks behind. So, what would happen if one player was in tick 260, and the other was still in tick 200, and sent a command saying "I mined a tree in tick 200", what'd happen then?

I'm a developer that also has quite some experience in network programming. From my experience the guy I quoted is right. Some really strange things will start happening when you keep sending everything p2p if everyone is at different latencies (since there is not one true state in the game). Just one of the many examples could be that player A and B place a building on the same location on tick 101. Now player C receives the information from A first while player D receives the information from B first. Now both states are equally likely to be "the true state".
When you would use a Host instead this is what would happen: Player A and B build a building at the same location at tick 101. They both send their message to the server. Now whoever's package is received first (based on ping or just random luck) will have the building placed. Next the server will broadcast to all Players that a building has been build on position ... by player ..., when the messages send by player B is then received afterwards the servers can easily check if the building can actually be build on this place or not (in this case not, so this request will be ignored). This way you can also quite easily wait with substracting a guys items from the inventory untill the server actually tells the building has been build (or even just let the resources per player just be handles by the server completely)
(Also imagine problems related to taking resources out of a chest when doing P2P, you will also run into desync issues).

I know it will be quite a hassle to rebuild all the networking you've already been working on, but hell, it will save you so much time in the future (mainly because the concept of a "host" means that the game can't desync by design (if implemented correctly ofcourse)).
What you could still do for example is keep the players moving locally so you don't have problems with pressing the "Left" key and having to wait 500ms before you start walking. If you want you can do some verification on the server to see wether the player can actually move to this position at this specific time but I would not concern too much about this, if people want to abuse it, they will.

So summarizing, using the concept of a "HOST" the host would basically handle all commands of the players while the clients only "view" and send "requests" to the server instead of sending "actions" (Requests as in, "Place a building if possible" instead of "Place a building")

As far as my experience goes is that the only way I can see p2p networking work is in a LAN environment where you can literally keep all ticks going at the same speed (maybe a few ticks apart but you can then re-iterate through the information you received and rebuild the current state). Though even in this scenario a "host" would be much easier since he determines the true state of the game.


Looking forward to seeing multiplayer released so much, can't wait to play this with a few friends of mine.

The problems you present would only occur in some very naive implementation of the p2p. In our implementation, the true state exists and is very well defined. If A and B order to build the building on the same location in tick 101, the tick is executed in 101+latency (lets say latency is 5), so in tick 106 it is executed, but every player executes tick 106 only when it has inputs from tick 101 from all players confirmed. In that moment, it executes the actions of all players in well defined order.

The host models doesn't avoid desynchronisation by design, still the input actions have to lead to the same game state, and the main problem with host model is, that it doubles the latency, as the message has to go to the host and back to the players.

So basically only the ticks from which information has been received from all clients determine the "true" gamestate while ticks from the current client only determine what he sees and is not guaranteed to be correct? (Just verifying)

[rsdworker]

nice - so i have suggestion - when player A is on one area - so player B could ask for permit to build in player A zone or area and allowing connection for example railways

[cube]

Is latency a (possibly dynamic) value, or does it rely on confirmation from all clients that they've completed every tick?

Currently it is fixed to 100ms (AFAIK, this part changes a lot now )

So basically only the ticks from which information has been received from all clients determine the "true" gamestate while ticks from the current client only determine what he sees and is not guaranteed to be correct? (Just verifying)

That is how we imagine it WILL work. In 0.11.0 only the true gamestate will ever be visible.

nice - so i have suggestion - when player A is on one area - so player B could ask for permit to build in player A zone or area and allowing connection for example railways

That's a thing we will be solving later. For now we will have only co-op game -- every player can build everywhere and they share the defences, research ....

[Pontiac]

It's GREAT that MP is coming out, but, I have my reservations about performance. From the description of what the communication is going to be between clients, why are you going a token-ring kind of network communication topology? The more people you throw into the mix, the worse latency is going get for EVERYONE. Imagine 26 people sitting on the network, waiting for information to get from person A to person Z. Playing 2 player MP is one thing, but when you get up to 20, from a players perspective you're looking at the sum of all latency for all players, not your single latency to a server. Sure the communication back and forth between the server and a single client will double, but it'd still be the latency between the server and the client, not client A + client B + client c + so on and so on. It'd get worse just watching a remote player just MOVE with that kind of waiting.

This also slams the door shut on having any kind of server going in that the 'host' has to be online 100% of the time. I don't know how the communication topology worked, but, if you look at what was going on with Space Engineers, when they built in the MP aspect of the game, it was set up that someone had to be online to host, and that someone would always have the world stored on their drive. Lag was also an issue until they went to a dedicated server setup. Myself, and many others I'm sure, have a lower powered machine compared to their primary gaming rig that is sitting around that hosts a server or 3. I'd rather offload the performance of "serving software" to a machine that isn't going to impact my game performance.

[Rakshasa]

There's no token ring involved in P2P.

The latency would, assuming proper implementation, be limited to that between the pair with the largest delay in transmission.

[Laturine]

what happens when a client gets too far away from the gamestate tick? ie. player 1 is on tick 160 and the gamestate tick is on 101. is this what lag is?

[slpwnd]

The latency would, assuming proper implementation, be limited to that between the pair with the largest delay in transmission.

This is correct. In theory.

what happens when a client gets too far away from the gamestate tick? ie. player 1 is on tick 160 and the gamestate tick is on 101. is this what lag is?

The solution we have devised is such that the players can't get too far away.

Very simply put:

You need tick closures from all the peers for tick 95 (example) to finish tick 100. Until you get it your map is stopped at tick 100. This also implies that no other peer can get further than tick 105 (because they are waiting for you).

[ataaron]

F5

[Voqar]

We're far more interested in co-op than pvp. All cool survival/builder type games should be made co-op to begin with.

Lantern Forge is another game we play that doesn't have co-op and it's the same thing for us, we say, this is a really cool game...BUT it doesn't have co-op. And the co-op factor just ramps up the goodness so much that it's hard to not dwell on it (or lack of it, that is).

[MF-]

@ vanishing players.

I thought you had perfect replays.
When a player drops, can't remaining players vote what was the last input they got from him....
... and have everyone revert to that tick and recompute without his input?

Not saying how the impact on latency would be.
But it definitely sounds easier..

+ I'm sure you've considered this. I'd like to know your reasons

[MF-]

right... noone is going to read a remark on 14+ days old fff. Tab closed.

[maysjw]

right... noone is going to read a remark on 14+ days old fff. Tab closed.

I'm quite sure that others "DO" read them as noted by an unread post when we login to the forums. Don't be so daft.

[MF-]

I'm quite sure that others "DO" read them as noted by an unread post when we login to the forums. Don't be so daft.

You proved me wrong
It just not those who the comment was aimed at.

BTW: I do read all comments in the news section via the RSS feed.
And you remined me that I might register a feed for the updates=fff section as well.

I just figured out I might be able to get a topic-headline feed for subforums (general, support, factorio direction, contributions)
But unless i want to cut the whole contributions subforum to stop mod-related topics from reaching me, there's no way.
EDIT: nope, mode=topics always fetches new topics from the entire forum, option f=123 gets ignored

[maysjw]

I'm quite sure that others "DO" read them as noted by an unread post when we login to the forums. Don't be so daft.

You proved me wrong
It just not those who the comment was aimed at.

BTW: I do read all comments in the news section via the RSS feed.
And you remined me that I might register a feed for the updates=fff section as well.

I just figured out I might be able to get a topic-headline feed for subforums (general, support, factorio direction, contributions)
But unless i want to cut the whole contributions subforum to stop mod-related topics from reaching me, there's no way.
EDIT: nope, mode=topics always fetches new topics from the entire forum, option f=123 gets ignored

It's too bad the PHPBB forums API isn't a bit more, how shall we say, modern Maybe with enough playing around you might be able to find a way to do what you are looking for, but probably not without using a very smart RSS reader.

[ssilk]

You know, there is the news section in the wiki, which we (wiki-users) try to keep uptodate.

https://forums.factorio.com/wiki/inde ... =Main_Page
which includes
https://forums.factorio.com/wiki/index.php?title=News

... sometimes with two or three days delay due to weekend or other things, nevertheless useful I think...