Factorio Forums

I think this way it opens up also for multi-server.

Let's think to the simplest case: 2 "servers" share one world, but only parts of it. For example West and East. If the player is in the West part, he (his computer) simulates only that part of the world. This can be based on chunks. If he changes from east to west he needs to load the actual chunks from the "server" (which can if course be only a client).

And because that could make problems (loads of chunks, which takes a while to be transferred), we can define "transfer areas". That are chunks, which can be used to come from East to West Server. I think for areas, where I cannot interact. If I walk, drive, swim, fly into such a chunk, I need to continue, until I reached the other side. I think for long lakes, rivers, desserts, valleys etc. you cannot built in that zones (or only rails, belts etc) and the zone is used to synchronize both servers and avoid lags.

Another idea is to make it a bit like in minecraft, where only the chunks around a player are simulated. The server simulates the whole world (because he has enough CPU-power), but the client loads only the chunks around the player and simulates that. This means, that the player cannot directly influence something, which is too far away. Difficult when we are thinking to the networks (electric, circuit, pipes...).

Making it like that enables also to handle much, much larger worlds, because the client needs

SilverWarior wrote:

kovarex wrote:The only way we considered doable in Factorio is to have fully deterministic model simulated on all clients, where clients have the same starting conditions and just player actions are sent to all peers of the game, so the traffic is pretty low.

I can already see some potential problems. Cheating.
If you go this way then you need to make sure that all of the clients have exactly same game files (no changes in entity definitions, no memory hacking, etc.). And this can be realy hard to achieve.

Not really. This model is resistant to cheating by default. Once you have different game files, or change memory etc, you are desynchronised.

A third server can be used as "vote" then. When a desync is found (=wrong checksums), the chunk can be localized and the third voter decides over the right version of that chunk. This way the game can stuck for some seconds, but then it resumes.

ssilk wrote:A third server can be used as "vote" then. When a desync is found (=wrong checksums), the chunk can be localized and the third voter decides over the right version of that chunk. This way the game can stuck for some seconds, but then it resumes.

You don't need that, when checksums are wrong, the game is just closed, no need to continue.

If this is on some server where you want to count score/rank, there is much more simple solution.

As most of the people don't cheat, people just report the game result on the battle.net and it will match (the reported result for both players).
Once some player starts to cheat (desynchronisation, to avoid loosing in bad position for example), you can easily find him and ban his account.

There's no need for checksums / hashes. Every action will be checked from the server for plausibility. The player did build a laser turrent there? Not possible, he is 10 Chunks away and doesn't have the laser turret item.

The peer2peer system has some other problems: Using a hacked client to (as example) see the terrain he did not already scout. It's not possible to discover this cheat, because the client just sends "not discovered" for the terrain to the server. Only when the person tries to interact with the undiscovered area, the server can see the cheat.

Nova wrote:There's no need for checksums / hashes. Every action will be checked from the server for plausibility. The player did build a laser turrent there? Not possible, he is 10 Chunks away and doesn't have the laser turret item.

The peer2peer system has some other problems: Using a hacked client to (as example) see the terrain he did not already scout. It's not possible to discover this cheat, because the client just sends "not discovered" for the terrain to the server. Only when the person tries to interact with the undiscovered area, the server can see the cheat.

Yes, the maphack is the only real problem in this model.

Hm. It's possible to solve that: A new chunk can be generated only with two hashes: One from me and one from the other player. If the hash from the other player is wrong, the chunk looks "different". The hashes are generated by the secret key of the hash-generator and the public key of the requester.

- Player A wants to generate a new chunk.
- For that he needs a hash from Player B at position of the chunk. The request is sent to B.
- B computes:
: hash = generate_chunk_hash(position, PlayerBs_secret_key, PlayerAs_public_key) and sends this back to A
- A can now compute the chunk:
: chunk = new chunk(position, hashes(my_hash, player_Bs_hash, public_keys(PlayerA, PlayerB))
- This chunk is then just "shifted", depending on the decrypted hash-value (decrypted with the public-key). I think this sound much more complicated, as it is.
- Without the right parameter, the map will look differently, and logically the checksum is then different, too. Which reveals this cheat.

So, the hashes depend from the position and the secret_key. The algorithm itself is no big deal, but the optimizing, caching etc. in a way, that it keeps secure...

The problem would not be secretly generating some new chunk, the problem is, that the enemy base is simulated on your computer as well, so it is possible to have hacked client that shows you the info about the enemy.

Ah. Yes.
Thought a while now.

There is really no way around it, except if the hidden chunks are handled by "a third party in the middle". This does 2 things:
- First: he tells the player only his visible chunks. Only this server can compute it.
- Second: It simulates the unrevealed, or partly unrevealed map-parts and tells the players map, when new things (in this case the running biters) should appear on his map.

But I would say: Not important for v0.10.

Chrotesque wrote:Yeah Steam Early Access, I don't know what a game dev has to do to get into the program[...]

I dont know if you can just add a game to the early access section of steam, but i'm sure you can add it on Steam Greenlight. I just checked. You need 90 €,1 Video (Trailers is coming soon™),4 Screenshots, a description of the game and the system requirements. That's all. You can pay the fee like you buy a game on steam: http://store.steampowered.com/app/219820/. However, this doesn't let you sell the game. People have to vote for it and when there are enough votes the steam guy's get in contact with you to bring the game to the Early Access section if it's still in Alpha/Beta or on the normal Store when it's (mostly) finished.

The problem with this system: How can we use this with the map? A "random" influence on the chunk generation seems pretty weird for a "nice" map, because the chunks have to be dependend on each other, because the map will look like garbage with every chunk different from the other around it.
I have no idea how a "infinite" map works (or how to tear it apart into chunks), so maybe this is wrong. ^^

interesting discussion - use determinism - to create multiplayer
so as I understand it, in order to preserve full determinism, everyone in multiplayer session will receive messages about everyone else in the world.. so if 3 players are sharing map, but don't actually see each other, your client with still need to process their actions and actually fully simulate everything they are doing (performance hit x3 ? )
also what will happen when one client will crash ? everyone will be paused until crashed client reconnects ? (so same as in StarCraft - dialog with waiting for players)
in any case, other clients must be paused until crashed client will recover or receive savefile from other clients - btw. factorio savefiles are already huge - 8-19 MB ?

Well... nothing really prevents every client to store snapshots of the map + all the events that occurred since this snapshot.

Like this, when a client reconnects, it restores it's snapshot, plays forward all events and requests the events that occurred after in order to catch up.

problem: it other players continue playing, the client might end up with too much work to process all events in order to catch up

solution: if every player stores snapshots at the very same time (game frame number in order to keep determinism), then, when a client reconnects, it can send a request with the latest snapshot he has in order to receive only the *diff* that would allow him to have a game state up to date. From this game state, the client can resume processing events.

It has both advantages of low bandwidth, leveraging determinism, fast catch up and low CPU pressure since there is no "long event queue" to process a game state up to date.

this game can tack 1 to infinity h, so stopping and restarting most is going to be a big part (the map i am playing it up to 44h).

Nope, every multiplayer map has to be played from start to end in one session. Factorio Marathon for the win!

Oh Kovarex, I'm sure you already know this article, but in case you don't, or just for sharing purpose, here it is :
http://www.gamasutra.com/view/feature/3 ... twork_.php

I've only read 25% so far and it's already awesome !

See you soon for next Friday Facts <3

Gryzorz wrote:Oh Kovarex, I'm sure you already know this article, but in case you don't, or just for sharing purpose, here it is :
http://www.gamasutra.com/view/feature/3 ... twork_.php

I've only read 25% so far and it's already awesome !

See you soon for next Friday Facts <3

Hello, thank you for the link, as you would expect, I read it already

pretty much standard for that age rts. I know of little modern ones, but this:
http://springrts.com/

has a similar model (synchronised commands, deterministic simulation) AND it's open source

it already has solved all the issue of cross platform multiplayer synchronisation - there are some interesting quirks that shows up only when you start trying to keep the game state in sync between two platform

Gryzorz wrote:Oh Kovarex, I'm sure you already know this article, but in case you don't, or just for sharing purpose, here it is :
http://www.gamasutra.com/view/feature/3 ... twork_.php

I've only read 25% so far and it's already awesome !

See you soon for next Friday Facts <3

nise read thaks you.