This PR changes part of the data flow between RoomLive and RoomServer.
Previously, RoomServer was used somewhat rigorously as a manager for game room events and state. One example this was the managing of transient state such as solving status and time entry method. RoomLive would notify RoomServer directly of the change, and then RoomServer would broadcast an event to all RoomLives to tell them what happened (in this case, it actually just told them to re-fetch participant_data).
There were some problems with this, namely a necessity for a distinction between events that both RoomServer and RoomLive were subscribed to (presence events) and events that only RoomLive was subscribed to (game events broadcasted by RoomServer).
Now, RoomServer can simply act as a cache for the room's transient state. Events can be directly broadcasted from RoomLive, and both other RoomLives and the RoomServer receive these all the same and update their own state. This allows new RoomLives to grab the current state from RoomServer, and removes the distinction between presence and game events.
Next: There is some additional work to consider more of the data flow handled by RoomServer. Things like create round and send message are done through the server, but probably should not be, as all the logic comes from context functions. However, this might not be a cut-and-dry case, because things like create solve do need the room server to update state.
This PR changes part of the data flow between RoomLive and RoomServer.
Previously, RoomServer was used somewhat rigorously as a manager for game room events and state. One example this was the managing of transient state such as solving status and time entry method. RoomLive would notify RoomServer directly of the change, and then RoomServer would broadcast an event to all RoomLives to tell them what happened (in this case, it actually just told them to re-fetch participant_data).
There were some problems with this, namely a necessity for a distinction between events that both RoomServer and RoomLive were subscribed to (presence events) and events that only RoomLive was subscribed to (game events broadcasted by RoomServer).
Now, RoomServer can simply act as a cache for the room's transient state. Events can be directly broadcasted from RoomLive, and both other RoomLives and the RoomServer receive these all the same and update their own state. This allows new RoomLives to grab the current state from RoomServer, and removes the distinction between presence and game events.
Next: There is some additional work to consider more of the data flow handled by RoomServer. Things like create round and send message are done through the server, but probably should not be, as all the logic comes from context functions. However, this might not be a cut-and-dry case, because things like create solve do need the room server to update state.