Oscar Clark explores the world of tokens.
One of the most intriguing game design challenges I have been involved with over the last few years came with my work on Reality Clash – an ICO funded location-based AR Shooter due for test release later this year.
The mission was to create a way to allow players to own a digital weapon on the blockchain in such a way where it would securely store meaningful information which would allow players “at a glance” to understand the value of that item in gameplay. Coming up with Stats for fictional guns is fairly normal, but the unprecedented part comes when you think about how digital assets can work in a world where there don’t have to be listed on a trusted server.
This has wider consequences than it may at first appear including:
- The game is not yet live. This means the actual gameplay stats for each weapon haven’t been stress tested or optimised and thus are likely to change.
- We want players (and speculators) to be able to freely trade these weapons between themselves in a secure and controlled way without risks of piracy or fraud
- We want to support other games creators who want to use our weapon tokens and use them in their game, independently of us.
- We wanted our digital goods to have an inherent unique value by being able to incorporate the playing history (i.e. game stats for kills, headshots, etc) for each individual weapon.
Developing the token – step one
The first consideration we had to tackle was the data points we wanted to share. Whilst we had a lot of detailed statistics defined for our weapons as they would function in Reality Clash – the damage, range, accuracy, reload rate etc – we decided that, for public use, we would simplify the publicly shared data for each weapon into a set of six attributes. Each attribute would be measured in bands of 20% increments, rather than specific numerical values.
The data embedded in the token can’t ever change once set, so, by opting for divisional bands, we also retained the ability to fine-tweak weapon stats in the core game in response to live ops gameplay, without having to modify the token data.
However, this did create another problem for us. If you rank all weapons on just one simple scale with set bands, it becomes messy when you try to compare say the damage of a Pistol with a Rocket Launcher.
In that scenario it’s likely that all pistols (indeed most guns) would fall into the lowest band whilst the Launcher would all be in the top band. It is impossible to differentiate between them sensibly.
To resolve this, we decided that all weapon stats would be shown as relative to their Class, such a Sidearm, Shotgun or Sub-Machine Gun. Allowing players to see how each compare in their class rather than against all weapons.
Step two
Next, we needed to make sure we had a way to uniquely identify a specific unique weapon (and who owns it) so we can validate them when they want to bring it into the game.
We did this by adding a unique serial number, and the OwnerID (based on their PublicID,) as metadata items.
These are created at the point of transaction and we need to incorporate the inclusion of those metadata items in the smart contract also, so that we correctly identify the owner and ensure that we don’t accidentally create multiple versions with the same serial number.
After all, if you buy the 007 serial number of a pistol you don’t want anyone else to claim ownership of that item!
One of the advantages of Blockchain is the ability to create a ‘trustless’, distributable token, that could be used by other developers.
However, for that to be a real possibility and to ensure we didn’t create problems later down the line we wanted to add in a mechanism which would futureproof the design.
That meant finding a way to enable 3rd party developers who might want to access more detailed information about the weapons on those tokens. This could include images and in-game stats that we would be refining during play.
So, in order to have the potential to offer these kinds of updates we decided to put an ‘API call’ into the token itself, listing the weaponID, any weapon skins and any accessories built into that bundle.
This future-proof approach means that later down the line we can choose to release more detailed data for that specific weapon type or even that specific weapon.
This may seem counter to the distributed principles but this will only be used for additional data that supplements the publicly shared bands; which as we have said will never change.
That idea of future-proofing has also been built into the smart contract, as we want to be able to include a weapon’s gameplay history into its data, allowing players to see a weapon’s lifetime history, for example, showing “How many hits”, “how many kills”, “how many headshots”.
We have designed the assets so that for each uniquely certified weapon can have this data appended each time a transaction is applied to that token. We are even considering how we might be able to support 3rd party data in that process too.
We decided to use a JSON format text file to store the data. But there was another consideration to factor in. Each time there is a change to the token – e.g. we update some history or who owns that item, we have to rerun the blockchain cryptography process.
That process takes time and costs more the more data points you have and/or the more complex that calculation. Originally, we had around 20 different fields, each of which would be treated separately. However, by adjusting the data structure, we were able to have the exact same information present, but compressed into just three strings.
We learned it’s not just important to think about what information you collect but also how it’s laid out so you don’t incur unnecessary costs later. We had many iterations between the Game Dev lead and Blockchain Lead before we were all happy with the final structure.
The final steps
The final step in the design process was to consider the specific use-cases for tokens. This is a necessary part of building the Smart Contract – that is, the rules which govern how new information is added to the Blockchain.
In the case of Reality Clash, we went one stage further, by looking at how new weapons would be delivered though live operations post-release.
This helped tremendously as it meant that we could ensure that the process – from concept art to implementation to release – could be as efficient as possible and allow us to add new variations and options later.
Once we had agreed on the JSON structure the Online-Retail team had to set about finding ways to automate the production of the certificates with the retail process.
The release of the secured JSON data and art assets with a digital certificate of ownership has to happen only after the transaction has completed in order to make sure that the serial number is issued to the right weapon at the right time; we don’t want orphan serial numbered weapons resulting from failed transactions.
Retaining the value of weapons post-release is critical for us. Players will be trading their weapons as digital assets, and at least initially, we want and expect speculators to invest in them, in order to gain the opportunity for an increase in value over time.
At the same time, we consciously decided that we had to ensure that buying guns wouldn’t break the game’s internal economy or change the game’s fundamental design dynamic so much that it became Pay To Win!
To help sustain the economy, and to ensure the value of our weapons, we quickly decided that we would limit the numbers of each weapon/skin combination released.
Once a batch is released, we won’t release anymore. We also decided to implement a tiering system into the game, which enables us to categorize each weapon in terms of its quality or effectiveness in combat situations.
That allows us to set prices for higher quality, more impactful weapons based on their tier, and to reflect this we made those higher tiers even rarer.
This introduction of Tiers has some interesting consequences for balancing gameplay, in particular, to help where we have mismatched players of different skill or experience levels.
The obvious option is that we can offer specific missions where players can only use weapons of a specific Tier; but we can also use the choice of weapon (and Tier) to adjust what rewards and XP those players gain.
This makes the choice of weapon more meaningful and encourages people to look at owning multiple weapons of each tier making more use of their collections. We also think this will help us ensure that more players can compete on a level playing field… and given this is about a location-based game we could be talking literally!
What’s still to be explored is what other designers can do with our weapon tokens. Our buoyant and sustained sales of tokenized weapons indicate that there is an audience out there who are excited by the possibilities offered by this technology I can’t wait to see what people come up with.
And continue the discussion in our Telegram group and don’t forget to follow BlockchainGamer.biz on Twitter, Facebook, and YouTube.