database persistence of room variables - its storage and the subsequent recovery

[theworldinunion]

Hi,

I have some questions on database persistence of room variables - its storage and the subsequent recovery.

I have a board game, any pair of users will be able to start an instance of the board game, thus there will be many instances of such game by different users.
A pair of users will be able to suspend their board game (i.e. both log out of ES), and then resume again say the next week if they ever do come back.

I have thought of making persistent rooms for these. But only a portion of the board games will ever be resumed.

My questions are :
- I assume that persistent rooms will take up memory, if I have hosted 2 million board games in the past ES will have 2 million zones. So is my line of thinking right that I should forget about persistent rooms, and persist the zone (and its rooms) to DB, then restoring the zone when they log in again?

- As the users log in again to resume the game, all the room variable restores from DB will generate an immense amount of "new room variables" from a client perspective. I have read from the forums that if a Flash client gets too much more than 20 socket messages a second, it will crash. So will this DB restoration of ES room variables overwhelm the flash client?

- Do you have any code samples of persisting an ESObject to DB and restoring it back to an ESObject?

Thanks.

[tcarr]

We don't usually store a raw EsObject into a database; we store the info that is inside the esob into the database.

Room variables for games are not recommended. A better design is to add a plugin to the room, and have the information in the plugin. If the users leave the room before the game finishes, the plugin can store the game state before it destroys itself. When a user wants to resume a saved game, a plugin message could be sent to restore the game state. There are lots of ways that the game state could be stored. Some of these examples are for ES4 but should work with ES5 after you fix the imports.

1. Have the plugin store the info into a database. See ES5's examples DatabaseWithJDBC and DatabaseWithJDBI. An EsObject probably can't be stored directly into the database. If ES5 is restarted, info is not lost.
2. Have the plugin store the info to a file on the hard drive using the FileSystemApi. See ES4's example SaveAndLoadImagesFromServer. This stores an EsObject directly into a file. If ES is restarted, info is not lost.
3. Have the information stored in a ManagedObject on the server, similar to the way that ES5's DatabaseWithJDBI does it but without the database. This info can be packaged as an EsObject or any Java class. If ES is restarted, the info is lost. You can add a timestamp to the stored games, and periodically remove games that are too old; for example, you might tell users that games have to be resumed within 3 days or they are lost, and once a day drop any stored games that are more than 3 days old.

[tcarr]

A further note: when it is a plugin that restores the game state, that game state could be sent as a single plugin message (an EsObject array if there are multiple EsObjects stored), so that there is no problem with Flash's limitation.