net code

[bobingabout]

Your current net code leaves the game unplayable over most internet connections.

Take a look at the open source game engine Spring. I've been playing a lot of Zero-K recently, you can place real time battles with thousands of units, and you never seem to have any kind of sync issues.

[FishSandwich]

0.11 was designed to work on lan, not internet. Proper internet supported gameplay is planned for 0.12

[hoho]

Is it unplayable because of latency or bandwidth?

From what I've gathered so far, the players mostly just send each other actions over to the rest of the players and each instance runs the full simulation of the game. At some points the checksum of current state also gets sent to check for desyncs. I can see that high latency can cause problems that is true for pretty much all games.

[ssilk]

Sorry, but this is off-topic. This has already discussed in the news-forum and the general forum. The essence is, that it needs some code to predict actions of other players to run the simulation on the own side fluid. And code to predict the latency correctly. Maybe I forgot something.

Fact is, that this suggestion is not needed, cause already planned and in progress.

[bobingabout]

I guess you're right, but still, its free open source code, and having a look won't hurt, maybe the devs would get inspiration from reading it.

In any case, I think the biggest killer with the game being unplayable over the internet... is that it sends too many checksums too often.


I have no idea what it is actually doing, but to play on a very new map takes the entirity of my friends internet bandwidth to run the game at about 1 tick every 2 seconds.

[MalContentFL]

Hey. I bet the net code could be fixed like Dice did in Battlefield 4, oh wait...

[ssilk]

I guess you're right, but still, its free open source code, and having a look won't hurt, maybe the devs would get inspiration from reading it.

That's a good point and so I took this out of suggestions board.

[Rseding91]

... I have no idea what it is actually doing, but to play on a very new map takes the entirity of my friends internet bandwidth to run the game at about 1 tick every 2 seconds.

Just wondering, what is his upload/download bandwidth? Some games have a bandwidth requirement and simply can't be played unless it's met (not saying Factorio doesn't have room for optimization).

There's also the part where Factorio is in an alpha state and a lot of MP related stuff is still running in "check often" mode to catch issues/errors.

[SHiRKiT]

It all comes from the devs decision of the structure of the multiplayer. Here's why I don't understand: You don't need to sync player's position perfectly. Just interpolate between positions received and future movement. That doesn't need to be deterministic

[pyrolytic_tungsten]

It all comes from the devs decision of the structure of the multiplayer. Here's why I don't understand: You don't need to sync player's position perfectly. Just interpolate between positions received and future movement. That doesn't need to be deterministic

I think that's true perhaps 98% percent of the time. A small player position error in the vicinity of biters can cause the biters to behave differently. Such as biters pursuing the player when they wouldn't have otherwise leading to changes in laser turret activity leading to changes in power grid status which can lead to slower miners, etc... Deterministic gameplay allows not sending large amounts of data over the network to keep everything in sync but requires frequent updates and or good prediction of player actions. I'm sure multiplayer performance will improve with time.

[ssilk]

As I understood it: Let's assume the player runs right. The game then can predict without interaction, that he will continue to run right or he stops running. It simulates booth states. At the moment when the signals from the remote game are received, the game can decide which version it should take to continue.

It reminds me strongly to Schrödinger's cat. http://en.m.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat

[hoho]

Why do you assume there are only two possible scenarios? At any point the player can change their direction randomly

[ssilk]

But it is not likely.

The problem is: The simulation on your host doesn't know the exact position of your character any more, cause it waits for the information-packets of the other players host. In this case: Your simulation knows: It has pressed a key to run in that direction, but to know if it still is pressed, I need to wait some more milliseconds, cause I've not recieved the needed packet for that.

But as I understand it we can say "The character is running now, so in the next timeslot it is most probably there".

In other words: Your simulation can run further without violating the the determinism, cause there is on most cases no determinism affected, if we don't know the exact position of the character.

It would be affected, if the character is shooting or will be shooted, or have some other interaction with his surroundings, that are affected by the exact position of the character. But that is not likely. In most cases it is just nothing, which can break the determinism. It is ok to guess the position. The result is: the simulation can just go on. It displays the most propable position of the others character.

At any time in the future the exact position is then known, cause the other host sends "player has stopped now". What we know is: He has started to run in this tick and has stopped in this tick. It must be there. That is the moment, when the probable position of the character is again synchron.

[Cilya]

I'm not sure there exists out-of-the-box solutions for networking that are suitable for Factorio. Factorio has a strong peculiarity:

1. the number of objects which are updated frequently is huge,
2. there is no locality : local changes can spread very far, and
3. there is no big step simulation for the game state.

I believe, this reduces the networking design to only one possible choice : a synchronous network where each nodes fully replicates others. And of course, this design is not resilient at all when there are big latencies. The problem is not only to synchronize characters positions, which would be easy. But to compute accurately the player action consequences. If the player put or remove an inserter, it as a consequences on the elements of the belts next to it. The presence of these elements can change the behavior of inserters further on the belt and even change the results of complex structures. You may end up with a large desynchronization between network nodes. Whether it has a small probability or not is irrelevant : it's hard to estimate if you really need to resynchronize or not, and if you do, you have to resynchronize everything.

I see is at least two solutions to work with higher latencies.

1. Resynchronize on strategic locations. For instance, if you open a chest, it may be interesting to synchronize its contents. When a train arrives or leaves, the same thing can arise.
   
   This is probably not a good solution. First, it defeat the logic used in Factorio where you don't need (I believe) to specify what needs to be synchronized and when it needs to. This is a choice that reduces drastically the complexity of the code, the time needed to write it, and the probability of bugs. It wouldn't be very wise to change that.
2. Split the world in two components : the factory one, which need to be simulated completely synchronously, and the living objects one, which can be replicated like usual in video games. (unperfect synchronization with small differences in states, periodic resynchronization and correction) I'm not sure this is not already the case, as there are already two clocks, one for the network, another for the game. Then the communication between the two world must be handled case by case. For instance, activation of assemblers and inserters may be delayed. If you want to be able to resist a delay of 2s, you can choose that when you put a new object in your factory, it requires 2s to be activated. So, when it activates, you are sure that every node in the network has the information that the inserter is there. This is a change which integrates well in the gameplay, as the player may understand that the component need some time to activate. Removing components of the factory is a bit would probably be less easy to integrate. With the same logic, the components needs to be running 2 seconds after the action has been performed. Increasing the time needed to remove a component would be frustrating for the player. Perhaps a good way to do this is to display the component with transparency and actually move it from the map to inventory after two seconds. For items on belt, you can state that it is not allowed to pick up an item on a belt, so it wouldn't cause desynchronizations. (A first step toward automatic pickup of items on the floor, please, please, please) And so on.
   
   This solutions doesn't require additional synchronizations but requires changes in the gameplay which may not be easy to design. You have to examine every situation where there is a communication between the two world and find a good way to make this communication delay-friendly. It also requires that network messages contains "action" or "activation" timestamps" and that the times are synchronized. (Those two conditions already holds ?)

N.B. I believe the developers of Factorio have made an amazing work. I can't think of a single (programming) design choice that could be criticized. I am convinced that the game, despite being already great, will become even greater, and will eventually run flawlessly over an internet connection. And believe me when I say i'm not easily convinced. I am amazed by the work that has already been done, especially to make the game deterministic. (I would have thought noone would have chosen that solution before they did) I am eager to see how the network solution will be improved for internet play.

[SHiRKiT]

Minecraft kinda resembles this. A mod can pretty much do exactly the same decisions on the client and on the server, to avoid multiple sync messages. This all can be done based upon a single message that starts up the process. You're right, they are probably doing the best they can, but we can always come up with ideas. Maybe we end up helping them.