KISS

2024-06-26

Ignore w/e I said for this. I'mma KISS it and make the structure simple.

We've had since the start ScriptState and GameState: content that is not expected to be serializable (or even threadsafe), and data that should be serializable if not threadsafe. Because of this separation of properties, we could make the following guideline(s):

We then ran into the problem of storing turn order which:

From that, we found our little innocuous third struct: InputState. It was at first used to store the communication part of the game (what player ids are at what index, and channels that InputRequest can be sent into). After a bit of moving around ( reduce on ScriptState instead of GameState to make the fact that &mut ScriptState is required a bit more obvious), and now InputState stores the turn order, and makes it publically accessible (but not publically modifiable). This as the added benefit, of allowing us to statically ensure the size (which InputState is bounded on). This does mean that it is not possible to serialize just the GameState and call it a day, but the overhead is so minimal (you already had to make an InputState) that I though it best.

Now I'm up to writing a structure for abilities, effects, actions, and events. I'm thinking of having abilities and effects divided into their broad subtypes as traits and going from there.

EDIT (Dec 18, 2024): This post mentioned not just serializing GameState, which is wrong. GameState is the only part that requires serialization. The information of player IDs must be synced on all ends though (which is the exact same as ScriptState). Basically, ScriptState and InputState are to be designed so that the exact same structures can be used to represent the game at any valid state (or GameState). This means that the reduction operator is not allowed to change any of the data within. The only data that can (or should) change is in GameState.