Multiplayer is insanely abusable

[ravignir]

1) Player id can be easily changed, one player can just replace their id with an id of another player and play the multiplayer game as they were them. 2) Multiplayer save data is stored locally: that allows some manipulations with a save file which will give one player an advantage like if they were a spectator. 3) Because save game is only uploaded only when a player hits "end turn" button it allows infinite reloading, meaning they can get favarable rng rolls and scout much more efficiently. It also allows moving civilian units anywhere without taking much risk. 4) Modded multiplayer games: one player can just edit their mod locally so they get almost any advantage they want - like increasing tile yields, decreasing costs etc. 5) Different versions of the base game: it also provides some advantage to one of the players, especially when there were balance/mechanic changes between two versions of the game.

[xlenstra]

6. As multiplayer save data is stored locally, you can simply open the save file in a text editor and have perfect information of everything your opponents are building, researching, their exact troop placements, etc.

[ravignir]

that is what i covered in 2. as being a spectator.

[xlenstra]

I interpreted 2 more as actively changing things in the save game, and 6 more as only looking at information, but it is very closely related, I do agree

[yairm210]

As far as I'm concerned all of these are "wontfix". The multiplayer feature is intended for players who trust each other. I'm not going to expend frankly a huge amount of time and effort to solve this. I'm leaving this open in case other people are interested in dealing with these issues.

[ravignir]

1st one might be fixed by ading a password/key whatever that only a player knows. 2nd just do not store it locally or hash the file. 3rd upload the game whenever a player takes an action - probably problematic due to how dropbox works. 4th generate mod key based on mod properties like it size. Allow the player to upload their game if the key is the same for both players 5th just disallow cross version multiplayer.

[yairm210]

As said, I'm going to do none of these, but for potential others:

1. Possible.
2. Possible, but will change a lot of how multiplayer games currently work. This is a huge project.
3. Impossible. User actions are EVERYWHERE, I can't even map them all, and uploading takes a good couple of seconds.
4. Possible, but highly complex. A simpler phrasing of the same result would be 'once a game starts with a mod version, don't accept other versions of the mod'. You can see why they're logically identical, but I think this would provide a worse gameplay experience, especially since games can play out over long periods of time.
5. I can't disallow cross version, because then no one will be able to update. Remember, there's just one source of truth, and if anyone 'different' can't change the source of truth, then it won't change either.

[SomeTroglodyte]

who trust each other

:+1: Key words.

I could envision changing SG format to what clipboard copy uses (gzipped) + some salted hash to make SG manipulation just a little harder (e.g. we can always manipulate in the debugger) - for MP + SP games. Mod checks could go by the last-commit-id which AFAIK is a github-calculated hash (not sure you get this in the same search api we're already using, but even if not - small round-trip), but I'd warn only.

[avdstaaij]

3. Impossible. User actions are EVERYWHERE, I can't even map them all, and uploading takes a good couple of seconds.

There's no need to upload the game for every action, it would suffice to overwrite the local save data. You'd still have to identify all user actions though, and deal with problem 2.

There is a much more serious problem, though: using the Dropbox access token that can be found in the codebase, any user can overwrite or delete the save file of any other. Furthermore, since the game is open source and thus fully inspectable, this may even be an avenue to exploit the save file loading process for some malicious purpose. Currently, the game is small enough for these issues to not be too much of a problem, but they're certainly more pressing than the ones mentioned so far.

[AdityaMH]

This free? https://cloud.google.com/blog/products/open-source/open-match-flexible-and-extensible-matchmaking-for-games https://firebase.google.com/docs/database

[sockybob]

Maybe the way multiplayer works should be changed? I assume right now it just syncing the state of the game. Then instead it can sync the actions that players take. This will solve most of exploits since any client can just check the validity of those actions. Also it will lower the amount of data to transfer.

[ajustsomebody]

what about adding encryption for local game storage and overwrite certain data when a unit moves, something happens a queque changes etc? what if every player had every players encryption keys except theirs?

[sockybob]

meaning they can get favarable rng rolls

Actually they can't because random in this game is consistent. Tested it with ancient ruins, not sure about other stuff like damage, but it can be changed to use consistent random too.

Second problem can be partionally solved by saving data in any non-human readable format.

[ravignir]

meaning they can get favarable rng rolls

Actually they can't because random in this game is consistent. Tested it with ancient ruins, not sure about other stuff like damage, but it can be changed to use consistent random too.

Second problem can be partionally solved by saving data in any non-human readable format.

damage is random. Ruins are semi random that is the drop of ancient ruins changes each turn/when another unit enters them. So you can grab the ruins, get a map and reload so you can enter them next turn, most likely getting something better.

[sockybob]

damage is random. Ruins are semi random that is the drop of ancient ruins changes each turn/when another unit enters them. So you can grab the ruins, get a map and reload so you can enter them next turn, most likely getting something better.

Then maybe it can be solved by giving a separate rng seed which would be used for rolling ruins reward and increment it only after you go into ruins so the reward will be always the same. Or just simply by saving the game locally after each player's action.

[ravignir]

but that solves nothing. The important thing is the damage roll. Ruins roll is a minor issue imo. So the only solution is to disallow replaying a whole turn.

[yairm210]

The only situation where rng is relevant to combat is when the two combatants would like each other with a full attack. So, not a high percentage of combat uses it. And even when used the differences are statistically very minor.

[ravignir]

The only situation where rng is relevant to combat is when the two combatants would like each other with a full attack. So, not a high percentage of combat uses it. And even when used the differences are statistically very minor.

not when you have a couple of units attacking a single unit: you can reroll until it is killed.

[Caballero-Arepa]

What if the game could get Google Play Games thing to play multiplayer?

[Caballero-Arepa]

Let me frase it better. Most games can have an google play games account, with which, you can use to log in other games and having achievements. I don't know if you understand me...

[SomeTroglodyte]

The open source ideal and privacy concerns go hand in hand. And G Play Games is spyware at its best. My opinion. We'd at least either lose F-Droid or need very different builds for them.

[Caballero-Arepa]

Ah yes, I forgot about Fdroid

[ravignir]

And pc

[yairm210]

I'm closing this as wontfix. Unciv multiplayer requires that either you trust your fellow players, or you don't mind if they cheat. No simple solution exists that would get rid of these potential problems.

[ravignir]

Too bad, I think we had a todo list to fix these problems.

• add a "password" randomly generated with player id.
• Saves overwrite locally whenever an action is taken.
• Saves are hashed so they can't be easily manipulated.
• Disallow using different versions of a mod.