Notes

[Joelius300]

Collection of random thoughts about the project so I can write them down and move on to more pressing matters :)

[Joelius300]

The state doesn't necessarily need to be immutable at every step. During tagging, it might make more sense to allow it to be mutable. Since actions need to be logged somehow anyway, it's comprehensible. The big issue is that in C#, you can't just switch the same data structure from mutable to immutable like you can in Rust, so it's more prone to bugs and requires more rigid structures.

[Joelius300]

The base library is just a tool to traverse game states according to player actions. To figure out who died etc. those game states need to be compared. The logic for that can live outside the base library.

There's also a need for comprehensiveness and reproducibility so the actions of players need to be stored/logged. Not sure yet if this is something that should be part of the base library or done outside, before submitting them to the game for processing.

[Joelius300]

It would be nice to build it in such a way that you can represent the whole game as a graph where each node is a game state and each edge is a (nature) player action. This would be in line with the idea of $\text{state}_{i+1} = \text{fn}(\text{state}_i, \text{action}_i)$ with full immutability all the time (at least from this high level viewpoint) and simplify usage for things like $\text{UI} = \text{fn}(\text{state})$ as well as state traversal to understand what happened how and why during the game.
It would even allow rollback/undo and when the time for playing around with reinforcement learning comes, such a robust and easy to follow game tree would be a godsend.

[Joelius300]

Werwolf implementation ideas after discussion with S.

• not a fan of tags, instead have typed data containers
• roles have players, not players have roles. So there would be a Werewolf object in the game state, which contains which players are playing that role, who's the werewolf target, etc.
• instead of tag interactions and iterative reduction, it would just be one big function handling everything a the end of the night. It could access game.Werewolf.Target in a typed way, check the options the witch has in game.Witch.xyz, etc. <-- exactly what I'm trying to avoid with the tags
• with this it would be much harder to check that everything was accounted for because with the tags you can simply check if all tagsets were collapsed fully. This is very important for me because it makes sure that there are no role interactions that are undefined! Everything has to be accounted for or prevented entirely from outside and every violations is reported immediately. That's why I'll stick to the tags unless I find a good reason to try this approach.
• but would probably be easier to do custom stuff for crazy roles

[Joelius300]

Another hardcoded example: https://github.com/GreyWolfDev/Werewolf/blob/b984eca47cd507a04768ba0d4b250a64edcff644/Werewolf%20for%20Telegram/Werewolf%20Node/Werewolf.cs#L625

Not quite as hardcoded, but also not as extensible as the generic tag solution: https://github.com/chrisgillis/slackwolf/tree/master/src/Game

More similar to what I am imagining: https://github.com/lykoss/lykos