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):

• Anything operating out of ScriptState is agnostic of the progress of the game, or any of it's current properties.
• Everything in GameState is pub and should be Serialize and Deserialize.

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

• should be serialized, but
• should never be edited

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.