Once a blockchain game is running, it's effectively unstoppable. However, updating game logic is a normal part of game development, otherwise games run the risk of becoming stagnant or boring.

To update your game, you must be able to update your game's name, e.g. "g/mv", "g/helloworld", "g/tftr", etc. Your game's name can contain update information.

Inside your game, you should have some update logic. e.g. "if the game version is lower than the minimum game version contained in the latest game name update, then display an update notice," or "if there are new property values for items, use those going forward."

Updates have 2 distinct natures:

1. Parameter updates that do not fundamentally change the game logic, such as item prices or item property values, e.g. the damage a special sword does, spawn rates for monsters in a particular area, etc.
2. Hard forks where fundamental game logic is updated

Here we are mainly considering the first nature where new items may be introduced, or item properties are updated. A common example of this kind of update is for balancing the game to ensure fair and fun gameplay. There are of course other update methods, and here we outline one convenient option for you to consider.

libxayagame has parameter update functionality already built in through the cmd command that you receive inside of the blockData parameter in the various callbacks, e.g. the forward callback where you write game logic.

To use the cmd command inside of blockData, you simply send a name_update to the blockchain with arbitrary JSON that you determine similar to the following:

name_update "g/mygamename" "{\"cmd\":{\"type\":\"setparam\",\"name\":\"goldprice\",\"value\":\"100\"},\"other stuff\":\"this is all ignored for cmd\"}"

The JSON for that is:

{
  "cmd":
    {
      "type": "setparam",
      "name": "goldprice",
      "value": 100
    },
  "other stuff": "ignored"
}

Inside of your forward callback with your game logic, you'll then receive a cmd parameter with the JSON that you updated your game name with. The cmd parameter is inside of the blockData parameter similar to the following.

{
  "block": {
	"hash": "dda7eccde4857742e5000bd66cf72154ce26c22876582654bc8b8d78dadbce8c",
	"height": 558369,
	"parent": "18f72c91c7b9223e9c7d0525216277e4016d748a2c81be4ba9d4a2b30eaed92d",
	"rngseed": "b36747498ce183b9da32b3ab6e0d72f2a17aa06859c08cf1d1e91907cb09dddc",
	"timestamp": 1549056526
  },
  "moves": [
	{
	  "move": {
		"m": "Hello world!"
	  },
	  "name": "ALICE",
	  "out": {
		"CMBPmRos5QADg2T8kvkQhMaMV5WzpzfedR": 3443.7832612
	  },
	  "txid": "edd0d7a7662a1b5f8ded16e333f114eb5bea343a432e6c72dfdbdcfef6bf4d44"
	}
  ],
  "reqtoken": "1fba0f4f9e76a65b1f09f3ea40a59af8",
  "cmd":
    {
      "type": "setparam",
      "name": "goldprice",
      "value": 100
    }
}

Remember, that JSON is arbitrary and can hold any value that you wish, such as an array of values or whatever best fits your needs.

For example, you may wish to send individual parameter changes inside of an array, or you may wish to send a list of URLs such as follows.

{
  "cmd": {
    "minimumversion": "1.2.3",
    "newestversion": "2.3.4",
    "newestrelease": "https://example.com/mygame.zip",
    "economy": {
    "pricesheet": "https://example.com/prices.xml",
    "itemsheet": "https://example.com/items.xml",
    "deprecatedorobsoletedata": "https://example.com/deprecated.xml"
   }
  }
}

A better way to do that is to hard code the URLs into your game and in the JSON value publish a checksum or hash of the file, e.g. a SHA-256 hash. So, for example, the above may instead look similar to this:

{
  "cmd": {
    "minimumversion": "1.2.3",
    "newestversion": "2.3.4",
    "newestrelease": "DEB00FD27B22B8DF141BAA66FF2DD748E6F2CBF8E0B4934E78E4809E6DF898D5",
    "economy": {
    "pricesheet": "AFA06B55D961084F66C8572E1BB6B661979446D8D671FE9C02B750488ADFF168",
    "itemsheet": "8510B849BB22CD7B063B465DF80AAE0194D25DDAB68D3735896FD53057220987",
    "deprecatedorobsoletedata": "653B267B9891D367C1659ADE0531B75EAF75806A1BEECF34DCDD9F8BC6ED4FA3"
   }
  }
}

With those URLs hard coded inside of your game, you can then download those files and hash them to verify that they are correct.

Once you have whatever data you've sent to yourself, you can then process that inside of the game logic.

For example, inside your game you could decide whether or not to force an update, e.g. to fix a UI bug. You could also update the prices of items inside of your store or change the values associated with specific items.

While it may seem that this isn't truly decentralised (because you as the developer aren't really "decentralised"), in one sense that's true because the game isn't entirely autonomous and relies on you as the developer to "feed & nurture" it for updates and the like.

However, in a more practical sense, if we know the rules of the game, then this is certainly an acceptable method to keep games fresh and up-to-date with new content so that games are still engaging and fun for people to play.