Factorio Forums

I am interested, will now that the game needs to work in multiplayer make some features hard/impossible to implement that would otherwise in single player be possible/easy?

How much the multi will make new features harder to implement so they work and not make the game lag? Will there be some limit because of this? Or the way you are doing multiplayer will not have that big effect on it?

Mostly no effect.

You need to check every new feature for desync in multiplayer, but that is pretty easy. And they are adding new tools to make it even easier.

It's much harder to go the other way, and add multiplayer on top of 2 years of desync bugs. Which they are trying to do now.

DaveMcW wrote:Mostly no effect.

You need to check every new feature for desync in multiplayer, but that is pretty easy. And they are adding new tools to make it even easier.

It's much harder to go the other way, and add multiplayer on top of 2 years of desync bugs. Which they are trying to do now.

I guess you are not a dev?
But if new feature make game desync , it means it would not be implemented? Are there any features like that, or limitations? Maybe speed limit or number, and how fast biters can move, or AI limitation?
I am very scared that multiplayer focus will have some big negative impacts on things that could be no problem for a single player game

boki wrote:But if new feature make game desync , it means it would not be implemented?

No, the desync will be fixed, and then it will be implemented.

Multiplayer relies on every computer playing the game exactly the same. So the only thing that needs to be transmitted is player inputs.

I'm not an expert nor a programmer however I get the impression will make future features more robust and will force the devs to make a better game?

Thats just the way it seems to me reading the updates and stuff.

As a programmer I can at least try to give some indication of how their current multiplayer system works.

The whole "desync" issue that currently occurs in multiplayer is because each game client has its own copy of the game state and is running its own version of the game update loop. The only data that is shared between clients is purely input related - Character movement, placement of buildings, anything reactive to player input.

Compare this to how you'd imagine a standard multiplayer game like say... Counter-Strike. In CS there is usually a dedicated server that has a "definitive" version of the game state. It knows where all the pawns, actors and entities in the game world are. When you connect, your game gets a snapshot of the game state and then is sent any changes to it that happen. Minus latency compensation and movement prediction algorithms, your computer barely does any processing and is only responsible for telling the server that you've moved here or fired your gun while facing in X1,Y1,Z1 direction while stood at X2,Y2,Z2 coordinates.

The advantage is that there's basically no desync, or if there is it is actually possible to solve. The server has a definitive version of the game state, if your state differs then it'll send a full update to bring what you see up to what the server agrees with. The disadvantage is, naturally, latency and the amount of data that can be sent. The more data that must be sent, the higher the bandwidth requirements, or in worst-case scenarios the higher the latency will be.

It could take you 50ms to send "I'm moving forwards" to the server, 1ms for the server to update the game state and send you back a packet saying "I agree, you've moved forwards." and another 50ms to get that packet, so your game will forever be behind.

In Factorio, each game has its own version of the game state. The host isn't sending data to all the other clients about the fact that an Iron Plate has been smelted, nor is it sending data about each individual biter's position in the huge pack of biters. Each game is instead calculating that an Iron Plate has been smelted because every single client was told "Player 1 put in 1 coal at 3h, 1m, 1s, 1ms from the map being created" - And since each game is running identical code it'll all produce the same output. That's determinism - Because the inputs are IDENTICAL for all clients and the code is IDENTICAL for all clients, the outputs are also IDENTICAL for all clients.

By this logic, it's safe to say where new features would not be delayed or not implemented by a desync bug because they can be implemented with determinism in mind. That the same set of inputs will produce the same set of outputs on all computer systems playing the game is, providing the game engine is built around it, not hard to implement (Although it may be tricky, as with an example of a program compiled with Windows libararies having different rounding of numbers versus one compiled with Mac or Linux libraries - In this case the code is different enough that one game may round 1.5 to 2 and another may round it to 1 - Which is where your desyncs are introduced).

It's also nice to think that the game won't be limited by the client-server model in terms of bandwidth and latency. Because each game is running its own simulation - An attack by any n biters will cost the same bandwidth as an attack by 1 biter. This is because as long as all RNGs are seeded with the same values and have been called the same number of times between each client, all clients will independantly generate the SAME biter attack from the SAME location locally, without any notifications needing to be sent between game clients. Each biter in that army will act identically because basically all game clients are clones of eachother. Same inputs, same outputs. That's the true advantage of determinism and it means that complicated features are more likely to be implemented versus a standard client-server model because bandwidth and latency aren't an issue.

Well, that's how I see it anyway. I could be completely wrong. I'd like to believe I'm not too far off the mark, though.

Jetlaw wrote:As a programmer I can at least try to give some indication of how their current multiplayer system works.

The whole "desync" issue that currently occurs in multiplayer is because each game client has its own copy of the game state and is running its own version of the game update loop. The only data that is shared between clients is purely input related - Character movement, placement of buildings, anything reactive to player input.

Compare this to how you'd imagine a standard multiplayer game like say... Counter-Strike. In CS there is usually a dedicated server that has a "definitive" version of the game state. It knows where all the pawns, actors and entities in the game world are. When you connect, your game gets a snapshot of the game state and then is sent any changes to it that happen. Minus latency compensation and movement prediction algorithms, your computer barely does any processing and is only responsible for telling the server that you've moved here or fired your gun while facing in X1,Y1,Z1 direction while stood at X2,Y2,Z2 coordinates.

The advantage is that there's basically no desync, or if there is it is actually possible to solve. The server has a definitive version of the game state, if your state differs then it'll send a full update to bring what you see up to what the server agrees with. The disadvantage is, naturally, latency and the amount of data that can be sent. The more data that must be sent, the higher the bandwidth requirements, or in worst-case scenarios the higher the latency will be.

It could take you 50ms to send "I'm moving forwards" to the server, 1ms for the server to update the game state and send you back a packet saying "I agree, you've moved forwards." and another 50ms to get that packet, so your game will forever be behind.

In Factorio, each game has its own version of the game state. The host isn't sending data to all the other clients about the fact that an Iron Plate has been smelted, nor is it sending data about each individual biter's position in the huge pack of biters. Each game is instead calculating that an Iron Plate has been smelted because every single client was told "Player 1 put in 1 coal at 3h, 1m, 1s, 1ms from the map being created" - And since each game is running identical code it'll all produce the same output. That's determinism - Because the inputs are IDENTICAL for all clients and the code is IDENTICAL for all clients, the outputs are also IDENTICAL for all clients.

By this logic, it's safe to say where new features would not be delayed or not implemented by a desync bug because they can be implemented with determinism in mind. That the same set of inputs will produce the same set of outputs on all computer systems playing the game is, providing the game engine is built around it, not hard to implement (Although it may be tricky, as with an example of a program compiled with Windows libararies having different rounding of numbers versus one compiled with Mac or Linux libraries - In this case the code is different enough that one game may round 1.5 to 2 and another may round it to 1 - Which is where your desyncs are introduced).

It's also nice to think that the game won't be limited by the client-server model in terms of bandwidth and latency. Because each game is running its own simulation - An attack by any n biters will cost the same bandwidth as an attack by 1 biter. This is because as long as all RNGs are seeded with the same values and have been called the same number of times between each client, all clients will independantly generate the SAME biter attack from the SAME location locally, without any notifications needing to be sent between game clients. Each biter in that army will act identically because basically all game clients are clones of eachother. Same inputs, same outputs. That's the true advantage of determinism and it means that complicated features are more likely to be implemented versus a standard client-server model because bandwidth and latency aren't an issue.

Well, that's how I see it anyway. I could be completely wrong. I'd like to believe I'm not too far off the mark, though.

This is how it is. And yes, when there is desync, the desync player can download the state from other players as well, it just takes some time

Clear explanation Jetlaw, thank you. Although the different Friday Facts Posts had told us as much over the weeks, it's good to have it in one post, so everyone can understand

kovarex, does that mean if, in it's current state, you play over LAN and with only Windows computers, you won't get desyncs?

jeroon wrote:kovarex, does that mean if, in it's current state, you play over LAN and with only Windows computers, you won't get desyncs?

Playing over LAN or over the internet doesn't impact the determinism of the game. On the other hand when playing with Windows computers only there are sure less possible desync occurences, but it can still happen (uninitialized variable for instance).

So from this explanations i guess there will not be many problems from new features and mechanics

One question I have about the whole dysnc thing. As discussed in this thread, there seems to be an issue where biters attack more frequently where the player is. That means the biter AI must be at some level dependent on the player character location, which makes me wonder how multiple players would affect this if they were very far away from each other. I'm guessing that everyone can see the other players and their vision on the map the same way they can see their own, and biters will attack in every area a player character is in, so tell me if it works differently.

Actually it depends on how this is done.

More than likely 'biter activity' relies not on the player specifically (though in some cases it might seem to) but instead on an 'active area' with the active area based on the location of the player. Ideally your computer would not computer biters outside of your active area..and only ask for information on such things..when you enter someone elses already active area.

Alternatively your computer may instead be told 'and here is another whole active area to calculate'.

See https://forums.factorio.com/wiki/inde ... Debug_mode
Search for 'active', turn it on and watch.

xnmo wrote:One question I have about the whole dysnc thing. As discussed in this thread, there seems to be an issue where biters attack more frequently where the player is. That means the biter AI must be at some level dependent on the player character location, which makes me wonder how multiple players would affect this if they were very far away from each other. I'm guessing that everyone can see the other players and their vision on the map the same way they can see their own, and biters will attack in every area a player character is in, so tell me if it works differently.

There is no mechanism like that, at least not intentional.