{"id":149,"date":"2015-01-26T13:17:07","date_gmt":"2015-01-26T13:17:07","guid":{"rendered":"http:\/\/smartfoxserver.com\/blog\/?p=149"},"modified":"2015-01-26T13:17:50","modified_gmt":"2015-01-26T13:17:50","slug":"maintaining-game-state-across-multiple-reloads","status":"publish","type":"post","link":"https:\/\/smartfoxserver.com\/blog\/maintaining-game-state-across-multiple-reloads\/","title":{"rendered":"Maintaining game state across multiple reloads"},"content":{"rendered":"

Continuing from a previous post about Singletons\u00a0<\/a>\u00a0we are going to discuss a simple strategy to maintain application state across multiple Extension reloads. Before delving into the details, let’s first analyze the reasons why this may help.<\/p>\n

The ability to update an Extension at runtime comes at the cost of destroying all of the data managed by the\u00a0Extension itself, which in some cases can be a pain. Whether the\u00a0Zone Extension is handling the global game state or multiple Room game states, it will loose all of the runtime data, which makes re-deployments a critical activity, requiring careful scheduling to avoid too much downtime for players.<\/p>\n

Using a\u00a0Singleton class as described in the previous article<\/a>\u00a0we can store all of the necessary game state in a safe memory space, that won’t be affected by a redeployment of our code.<\/p>\n

\u00bb How does this work?<\/h3>\n

In our documentation we have a section dedicated to how class loading works in the JVM<\/a>. The image below outlines the class loader hierarchy in SFS2X.<\/p>\n

\"class-loaders\"<\/a>What is important in this simple diagram is the Extension Global ClassLoader<\/strong>, which sits on top of all deployed Extensions and whose life cycle is independent from its children. We will therefore exploit this top class loader to maintain state across multiple re-deployments.<\/p>\n

As mentioned in the previous article this top class loader manages all jar files under the\u00a0extensions\/__lib__\/\u00a0<\/strong>folder, so we’ll deploy our singleton class and its dependencies\u00a0in a separate jar file to this folder.<\/p>\n

\u00bb An example<\/h3>\n

Here is a simple pseudo-code of a singleton game model:<\/p>\n

\r\npublic class GameSingleton\r\n{\r\n\tprivate static final GameSingleton INSTANCE = new GameSingleton();\r\n\r\n\t\/\/ Here we keep the state for each game in the Zone\r\n\tprivate Map<String, GameState> gamesTable = new ConcurrentHashMap<>();\r\n\r\n\tprivate GameSingleton() {}\r\n\r\n\tpublic static GameSingleton getInstance()\r\n\t{\r\n\t\treturn INSTANCE;\r\n\t}\r\n}\r\n\r\npublic class GameState\r\n{\r\n\tprivate HighScoreTable hsTable;\r\n\tprivate List<Player> players;\r\n\r\n\t\/\/ ... more game data ...\r\n}\r\n\r\npublic class HighScoreTable\r\n{\r\n\t...\r\n}\r\n\r\npublic class Player\r\n{\r\n\t...\r\n}\r\n<\/pre>\n
The main singleton class keeps a map of GameState<\/em> objects, one for each game running in the Zone. Each instance will in turn describe all of the runtime data for the game, such as high scores, the players properties and whatever other information is needed.<\/p>\n
NOTE:\u00a0<\/strong>When deploying the code we will make sure that the main singleton object and all the related game state classes are packed in the same jar file and exported to the extensions\/__lib__\/<\/strong> folder.<\/div>\n
 <\/p>\n
In our main Extension init()<\/strong> method we will just need to access the Singleton class, which in turn will either get initialized, if it’s the very first time this class is loaded, or we’ll get\u00a0a reference to object already in memory.<\/p>\n
\r\npublic class MyGameExtension extends SFSExtension\r\n{\r\n\tprivate GameSingleton gameSingleton;\r\n\r\n\t@Override\r\n\tpublic void init()\r\n\t{\r\n\t\tgameSingleton = GameSingleton.getInstance();\r\n\r\n\t\t\/\/ etc...\r\n\t}\r\n}\r\n<\/pre>\n
As a final remark,\u00a0keep in mind that this approach will work\u00a0fine as long as you don’t need to re-deploy changes to the singleton or related model classes. In that particular case a server restart will be required.<\/p>\n
NOTE<\/strong>: If during the implementation of this solution you’re getting a ClassCastException when accessing the global game data, chances are you haven’t deployed your model classes correctly. In particular the class that has raised the Exception is likely to have been exported in the wrong jar, i.e. in the Extension jar vs the Singleton jar.<\/div>\n","protected":false},"excerpt":{"rendered":"
Continuing from a previous post about Singletons\u00a0\u00a0we are going to discuss a simple strategy to maintain application state across multiple Extension reloads. Before delving into the details, let’s first analyze the reasons why this may help.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[5],"tags":[31,7],"_links":{"self":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts\/149"}],"collection":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/comments?post=149"}],"version-history":[{"count":11,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts\/149\/revisions"}],"predecessor-version":[{"id":162,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts\/149\/revisions\/162"}],"wp:attachment":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/media?parent=149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/categories?post=149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/tags?post=149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}