Messages are live games are moved to the long-term storage as well, clearing out the Redis store on each sweep. When a user connects to the game it will load both the messages from the long-term storage as well as the live database.
The engine is event source based, so no "current" state is ever stored. This will need to be changed long-term if I wish to support longer games.
That said, there is a minimal state in the Redis DB that needs to be restored if the game has been completely purged (which happens infrequently). This is no more than the count of messages and total count of players.
Messages are live games are moved to the long-term storage as well, clearing out the Redis store on each sweep. When a user connects to the game it will load both the messages from the long-term storage as well as the live database.
The engine is event source based, so no "current" state is ever stored. This will need to be changed long-term if I wish to support longer games.
That said, there is a minimal state in the Redis DB that needs to be restored if the game has been completely purged (which happens infrequently). This is no more than the count of messages and total count of players.
Does that mean the game server collects/replays the existing messages when resuming a game to send the appropriate initial state to the client?
Yes. The client starts a "reset" state for the game and replays all the messages to get back to where it was.
Even for a 6-7 players over an hour or two this only adds up to 6-7k messages.