{"id":522,"date":"2016-07-22T15:35:30","date_gmt":"2016-07-22T15:35:30","guid":{"rendered":"http:\/\/smartfoxserver.com\/blog\/?p=522"},"modified":"2016-07-22T15:37:15","modified_gmt":"2016-07-22T15:37:15","slug":"serialization-strategies","status":"publish","type":"post","link":"https:\/\/smartfoxserver.com\/blog\/serialization-strategies\/","title":{"rendered":"Game state serialization strategies"},"content":{"rendered":"

In this article we’re going to analyze a few strategies to serialize game state data between client and server, and discuss the pros and cons of each approach.<\/p>\n

\u00bb Serialization basics<\/h2>\n

In computer terms data serialization is the process of converting data structures into a format that can be stored or transmitted over the network.\u00a0SmartFoxServer 2X abstracts this process via two main objects, SFSObject<\/a> and SFSArray<\/a>, which are used pervasively throughout the server and client API.<\/p>\n

These objects\u00a0abstract the data transport between client and server and\u00a0provide fine-grained control of\u00a0the\u00a0data sent over the network, handled by the SFS2X binary protocol.<\/p>\n

This is an example of a custom message sent from client to server:<\/p>\n

\r\nISFSObject item = new SFSObject();\r\nitem.putUtfString("name", "Golden Sword");\r\nitem.putInt("damagePoints", 120);\r\nitem.putInt("durability", 40);\r\nitem.putBool("isMagic", true);\r\n\r\nsend(item, user);\r\n<\/pre>\n
SFSObjects and SFSArrays support 20 basic types, including \u00a0typed collections, and deal with the low level details of serialization to binary data. This is what we usually call low level serialization<\/strong>: in other words the process of turning object data to a binary format.<\/p>\n
In this article, however, we’ll focus on and discuss\u00a0high level serialization<\/strong> which is the process of converting your game data to and from SFSObjects.<\/p>\n
\u00bb Serializing custom objects<\/h2>\n
Since every game keeps state (be it a simple high score list or a complex inventory with hundreds of items) there will be custom objects in our\u00a0game modeling such data. Serialization comes into play when we\u00a0need to transmit\u00a0game state updates to clients when changes occur.<\/p>\n
We need to take custom data\u00a0from\u00a0our server Java Extension and send them to clients which may be even running on an entirely different language and platform, such as Unity, HTML 5, Flash\u00a0etc…<\/p>\n
For the sake of simplicity let’s say we have this Java class describing an element of \u00a0game state:<\/p>\n
\r\npublic class SpaceShip\r\n{\r\n  byte type; \r\n\r\n  short x;\r\n  short y;\r\n\r\n  int shieldPoints;\r\n  int damagePoints;\r\n}\r\n\r\nSpaceShip ships[]\u00a0= new SpaceShip[10];\r\n<\/pre>\n
Let’s say we want to update clients about the spaceships contained in the array. We have essentially three options.<\/p>\n
#1 Inline serialization<\/h3>\n
We can build a series of SFSObject, one per spaceship instance, inline in our code, add them to an SFSArray and finally send the whole thing:<\/p>\n
\r\nISFSArray shipArray = new SFSArray();\r\n\r\nfor (SpaceShip ship : spaceShips)\r\n{\r\n\tISFSObject shipObj = new SFSObject();\r\n\r\n\tshipObj.putByte("t", ship.type);\r\n\tshipObj.putShort("x", ship.x);\r\n\tshipObj.putShort("y", ship.y);\r\n\tshipObj.putInt("sp", ship.shieldPoints);\r\n\tshipObj.putInt("dp", ship.damagePoints);\r\n\r\n\tshipArray.addSFSObject(shipObj);\r\n}\r\n\r\nISFSObject packet = new SFSObject();\r\npacket.putSFSArray("ships", shipArray);\r\n\r\nsend("cmd", packet, someUser);\r\n<\/pre>\n
While this approach is essentially correct and works fine,\u00a0it could quickly pollute your code with large blocks of Class\u00a0<–> SFSObject inter-conversions, causing also a lot of code repetition and general untidiness. A far better approach to this type of conversion would be\u00a0to retrofit our\u00a0game classes with a couple of useful methods.<\/p>\n
#2 Encapsulated\u00a0serialization<\/h3>\n
Keeping the same idea of approach #1, we’re going to refactor our initial SpaceShip class\u00a0adding a toSFSObject<\/strong>() and fromSFSObject<\/strong>() methods and replacing string literals with constants, to avoid duplication.<\/p>\n
\r\npublic class SpaceShip\r\n{\r\n\tstatic final String KEY_TYPE = "t";\r\n\tstatic final String KEY_X = "x";\r\n\tstatic final String KEY_Y = "y";\r\n\tstatic final String KEY_SHIELD = "sp";\r\n\tstatic final String KEY_DAMAGE = "dp";\r\n\r\n\t\/\/ ...\r\n\r\n\tbyte type; \r\n\r\n\tshort x;\r\n\tshort y;\r\n\r\n\tint shieldPoints;\r\n\tint damagePoints;\r\n\r\n\t\/\/ ...\r\n\r\n\tpublic static SpaceShip fromSFSObject(ISFSObject shipObj)\r\n\t{\r\n\t\tSpaceShip ship = new SpaceShip();\r\n\r\n\t\tship.type = shipObj.getByte(KEY_TYPE);\r\n\t\tship.x = shipObj.getShort(KEY_X);\r\n\t\tship.y = shipObj.getShort(KEY_Y);\r\n\t\tship.sp = shipObj.getInt(KEY_SHIELD);\r\n\t\tship.dp = shipObj.getInt(KEY_DAMAGE);\r\n\r\n\t\treturn ship;\r\n\t}\r\n\r\n\tpublic ISFSObject toSFSObject()\r\n\t{\r\n\t\tISFSObject shipObj = new SFSObject();\r\n\r\n\t\tshipObj.putByte("t", KEY_TYPE);\r\n\t\tshipObj.putShort("x", KEY_X);\r\n\t\tshipObj.putShort("y", KEY_Y);\r\n\t\tshipObj.putInt("sp", KEY_SHIELD);\r\n\t\tshipObj.putInt("dp", KEY_DAMAGE);\r\n\r\n\t\treturn shipObj;\r\n\t}\r\n}\r\n<\/pre>\n
Notice how the fromSFSObject()<\/strong> method is marked as static<\/strong> since it acts as an alternate constructor, where we pass the SFSObject representing the data obtained from the other end of the communication (in this case it is the client, but it could be also the server).<\/p>\n
Our code for sending the array of SpaceShip items\u00a0becomes much cleaner now:<\/p>\n
\r\nISFSArray shipArray = new SFSArray();\r\n\r\nfor (SpaceShip ship : spaceShips)\r\n{\r\n\tshipArray.addSFSObject(ship.toSFSObject());\r\n}\r\n\r\nISFSObject packet = new SFSObject();\r\npacket.putSFSArray("ships", shipArray);\r\n\r\nsend("cmd", packet, someUser);\r\n<\/pre>\n
Also every time we need to send an instance of a SpaceShip object we can directly invoke the toSFSObject()<\/strong> method, without resorting to more inline serialization code.<\/p>\n
NOTE<\/strong>: on the client side we will need to create a specular version of the same SpaceShip class so\u00a0we can exchange the same data in both ways, which is usually needed.<\/div>\n
#3 Reflection based serialization<\/h3>\n
SFSObject and SFSArray allow to serialize custom classes\u00a0provided that they implement the SerializableSFSType<\/strong>. This in turn allow for a selection of native types to be automagically serialized via reflection<\/a>.<\/p>\n
Here is how the SpaceShip class would look like in this case:<\/p>\n
\r\npublic class SpaceShip implements SerializableSFSType\r\n{\r\n\tbyte type; \r\n\r\n\tshort x;\r\n\tshort y;\r\n\r\n\tint shieldPoints;\r\n\tint damagePoints;\r\n}\r\n<\/pre>\n
Pretty straightforward. We don’t need any manual serialization method, just marking the class as SerializableSFSType. The interface doesn’t require any method to be implemented but allows the internal serializer to manage\u00a0types via reflection.<\/p>\n
The code to serialize the SpaceShip array looks like this:<\/p>\n
\r\nISFSArray shipArray = new SFSArray();\r\n\r\nfor (SpaceShip ship : spaceShips)\r\n{\r\n\tshipArray.addClass(ship);\r\n}\r\n\r\nISFSObject packet = new SFSObject();\r\npacket.putSFSArray("ships", shipArray);\r\n\r\nsend("cmd", packet, someUser);\r\n<\/pre>\n
This looks very similar to what we have done in the previous example with the notable difference that we’re using the SFSArray’s addClass()<\/strong> instead of addSFSObject()<\/strong>.<\/p>\n
On the client side we need to create a specular class that must:<\/p>\n