In multiplayer, seed all players scroll names the same

[seiyria]

Recently, we were playing through a multiplayer run and someone asked me what my scroll of charging was, so I said READ ME. They then wrote a READ ME and it came out to be a scroll of fire. It looks like scroll names are not seeded per game, but rather per player? Having this be more consistent would be great.

[katastic]

That's not a bad idea, but it is game mechanic choice. Having it random means everyone has to learn on their own and you cannot share experience to reduce the total risk in the game. You all have individually commit to risk (drinking something random, casting something random) on your own and pay the penalty. Otherwise, the risk per person drops with player count.

So if this is added, it should be a option, not a permanent BUGFIX kind of change.

[seiyria]

As an option, I suppose shared knowledge would make sense, sure. But I don't find this to be a compelling game mechanic. These games are so short, and oftentimes you rarely see the same scroll twice. Additionally, I find it strange that if a scroll says READ ME for you, and READ ME for me, they do different things. It really just doesn't make sense.

[katastic]

As for implementation, it could be as simple as making sure all clients have the same random seed for scrolls. It looks like they have a fixed list of all scroll names, then make a shuffled list here (enchantedFeatherScrollsShuffled):

Barony/src/game.cpp

Lines 5112 to 5115 in c67c01d

	enchantedFeatherScrollSeed.seed(uniqueGameKey);
	enchantedFeatherScrollsShuffled.clear();
	enchantedFeatherScrollsShuffled = enchantedFeatherScrollsFixedList;
	std::shuffle(enchantedFeatherScrollsShuffled.begin(), enchantedFeatherScrollsShuffled.end(), enchantedFeatherScrollSeed);

So looking at the code, it mostly looks like a BUG/oversight that they aren't synced as I see no obvious indication they wanted it randomized across clients as opposed to overlooking the seeds desyncing.

They seed the random number generator with uniqueGameKey which is generated (and appears to be sent to networked clients). So why this key ends up different per client is interesting. It could be the clients are synced initially, but calling non-identical amounts random() usage and the random number generators become desynced. And that could affect other things as well that depend on random being synced.

One possible solution would be simply: when the random seed is sent to all clients, have every client immediately generate the shuffled set. That way if they become desynced later, it doesn't matter.

[edit] Actually, the more I think of it, the scrolls have their own seed and their own generator. So how that becomes desynced when it should be decoupled from any other thing (like particle generation) is curious. But the fact they spend this effort to keep and send this seed implies it's a bug that they become desynced.

[edit] I'm wondering if enchantedFeatherScrollSeed is even shuffled properly on clients and maybe it's a distinction between server and clients [which may all be the same vs the server]

[WALLOFJUSTICE]

The intention was that everyone has the same shuffled list, I don't know how it gets desynced..

Tested new multiplayer lobby and it appears to be the same order using the same uniqueGameKey. Repeating the same seed gives me consistent shuffled orders. I'm working on the new feather GUI for the update so will make sure to try get it working and synced.

[WALLOFJUSTICE]

Turns out std::shuffle isn't cross platform, despite passing in the same rng generator (which is cross platform). Made my own shuffle and seems reliable.

So between Windows/Linux multiplayer will be desynced, but otherwise Windows/Windows should have been working fine.

Interesting read: https://anadoxin.org/blog/c-shooting-yourself-in-the-foot-4.html/