Hello Michal Kovarik, Tomas Kozelek, Jakub Marek (AKA Kuba). I feel I must also recognize Albert Bertolin, Bertran Escola, Jayant Mall, Daniel James Taylor, Dušan Doskočil (AKA Sepromatiq), and the great Hedgehog for their contributions as well. All of your collective efforts have come forth to produce an amazing, addictive, yet entertaining game that fits in an micro management/RTS style that has never been truly explored before the existence of Factorio. This is a brilliant work and paves new pathways in gaming itself. I thank you all for your efforts and I am glad to have contributed to your works with my very small investment. Even though Factoria is technically/classicly in Alpha, this is one of the most enjoyable, addictive, and playable games I have ever encountered for being in the state it is currently in. You have nowhere to go from here but to the top. I'm honestly humbled at the amount of money you made during your Indiegogo times and I'm shocked that your project had not garnered more attention and funding during its time. You have executed brilliantly and immensely far better than some other projects (that I will not mention by name out of kindness).
I must say however, that I have serious concerns regarding your approach to multiplayer support. It would seem from "Friday Facts #53 - Multikulti Multiplayer", "Friday Facts #51 - First MP Game", and "Friday Facts #47 - CRC fun" that you're implementing multiplayer with a multiple server/client architecture. Every 'user' is its own server AND client. This is a VERY risky approach and is the primary reason you are having to resort to your desynchronization detection through the process of CRC'ing the entire map per tick as discussed at "https://www.factorio.com/blog/post/fff-47". Furthermore, this is the reason why you're running into the issue of having to add simulation of multiple game steps per tick in order to accomadate varying FPS of clients in a given multiple user online game session as mentioned in "https://www.factorio.com/blog/post/fff-53" and "https://www.factorio.com/blog/post/fff-51".
From what I can see, you're taking the hard road to solving this problem. Making it difficult not only for every single client of a given multiplayer game but also from a programming perspective on your end. You have a multiple server/client pairs that all connect together and attempt to run their own active simulation of the world. This requires that everything be deterministic and that each server/client be in sync, take the same input, and end up with the same results all while the others are as well. A serious problem with this is that we live in a world that is (unfortunately) limited by the latency that is a result of the speed of light or lesser depending on the data transfer medium. Ultimately, from the worst possible Earthbound connection you're looking at a 1,000–1,400 ms round trip time from packet send to packet received. A multiple server/client system would never function acceptably in an environment such as this. Even in lesser latency scenarios, you're going to run into some severe synchronization issues. Please do not fear, as there is hope however!
You can absolve yourself from nearly all of these issues if you switch to a single server multiple client architecture. That way, all processing of events and their given reactions are handled on one computer while the results of those events are sent out to all of the clients. Every client sends their inputs into the world to the server and the server ultimately decides what had happened as a result of these inputs. As a result you free the clients of much of the processing and simulation and offload the burden onto a potentially much more powerful central server. Ultimately, with an architecture such as this you do not even need absolute determinism in your code as you seem to be seeking now. A single server 'entity' owns all the data about the current world and is acting on that world alone. So there is no opportunity for multiple world 'runners' to come to multiple conclusions about what had happened in the world as a result of bad determinism.
Obviously this has some consequences from the perspective of who owns the data of a given world. Basically, the owner of a world has to run a server and that same user has to log in to that server as a client of it. (Even though from the old single player concept, they had been the owner of that world.) Ideally, you'd move singleplayer from what it is now to actually comprehending a server/client structure so you can keep your codebase unified. In a system such as this, a singleplayer session becomes nothing more than running a server and connecting to it as a client on the local 127.0.0.1 loopback. At that point, every world is essentially able to be brought 'online'.
Beyond all of this, I will admit that I am making assumptions here. So please answer me, if you have time and care to do so, the following questions...
- Why have you chosen the multiplayer architecture you're working with now?
- Was this game designed as a multiplayer game from the ground up or is this a recent addition?
- What is the primary need for absolute determinism in all your game code?
- Given that your game sometimes seems to need 'random' events, does your decision to enforce absolute determinism affect your vision for the game?
- How many players do you hope to support at a given time?
- Would you like to avoid having a given client being forced to simulate all steps up to the latest update-step it had received? Rather, why not have it request to be sent the latest update step?
- What benefit do you gain from having all your game code being absolutely deterministic?
Multiplayer Architectural Concerns
Moderator: ickputzdirwech
Re: Multiplayer Architectural Concerns
adressed many times before
Just to mention a handful
) said server blasting-off an event for every damn piece of coal on conveyers would need humongous uplink,
which would grow with active factory area. Austrailan ISPs were said not to be able to handle much bandwidth.
) latency might actually get worse. It's two trips in your scenario (Cx->S->C) v.s. one trip implemented (Cx->C)
) decoupling rendering from simulation is inevitable anyway. And it's the rendering that slows games down,
not state computation.
Just to mention a handful
) said server blasting-off an event for every damn piece of coal on conveyers would need humongous uplink,
which would grow with active factory area. Austrailan ISPs were said not to be able to handle much bandwidth.
) latency might actually get worse. It's two trips in your scenario (Cx->S->C) v.s. one trip implemented (Cx->C)
) decoupling rendering from simulation is inevitable anyway. And it's the rendering that slows games down,
not state computation.
Re: Multiplayer Architectural Concerns
Ah, understood. You have definitely taken the correct approach.
Thank you for the quick response.
Thank you for the quick response.