Tezos Integration SDK: Suggestions for Further Use
Possible Extensions to the Tutorial Scenes (reusing our contract & Unity code)
The SDK tutorial scenes focus on in-game item NFTs (e.g. minting, displaying, buying, selling, gifting these) since this is a fairly obvious intersection of traditional gaming dynamics and the Web3 world of NFT display and trading. Of course an even more widely understood use case for blockchain technology is cryptocurrency itself, i.e. on-chain fungible tokens of a certain established value, and the built-in contract (as an FA2-compliant contract) supports transactions of fungible tokens as well for use cases such as an in-game currency. Our on-chain transactions charge appropriate gas & storage fees in Tez; and in fact our Unity-side and contract code is largely plumbed to support buy/sell transactions in Tez as well. Certainly, the underlying SDK would support whatever Tez transactions might be implemented in the Unity code on this side of the API, and in the underlying contracts.
Non-Random Minting, and Changes to the Item Data Model
You can use code from the ContractAndMinting tutorial scene for your modern machine gun, grenade launcher, assault vehicle, Star Wars blaster, zombie-killiing sharpened shovel, etc. substantially as-is (though obviously with your own item assets and whatever other graphical elements). The most immediate constraint would likely involve the minting code, which currently sets the quantity and metadata values of the new token randomly. Of course, once enough players of your zombie-apocalypse game had put up their unneeded items for sale in the market, in theory another player could acquire anything they needed that existed within that game universe. But if the automatic grenade launcher or the corn-powered Abrams tank were simply too rare and valuable for any player to part with, you might well want to write a modified mint entrypoint, say mint_specific_item, which had item type and stat parameters passed in rather than generated randomly; then set up a different kind of in-game store where users purchased specific items from a full inventory. As long as this new mint function did not violate our basic item data model at the contract level, the remainder of our contract functionality should be happy with it, and our Unity-side code should be fine with it as well.
Non-random minting aside, one could certainly imagine game-items with other properties: your machine-gun clip holds x number of rounds; your Abrams tank can hold y gallons of corn-based ethanol. But, of course, these are also variable properties with values changing in-game from moment to moment, so it would make no sense to store these as item data on the blockchain; instead they would simply be defined as part of your machine-gun or Abrams prefab and their values would be managed in-game during combat, by whatever combat manager you had (since our example has no combat or other kinetic game dynamics at all, you'd need to implement those whatever your chosen game genre). But what about a walkie-talkie with communication range of n kilometers? This should (or at least could) rightfully be stored and handled as an item statistic, yet it's outside our current item data model. Or what if you were crafting a racing game, and your race cars' core statistics had very little overlap at all with our item data model? At some point you would need to evaluate whether our current item data model could usefully accommodate your game, and beyond that point you'd need to extend or modify the item data model on both the Unity game side and the smart-contract side accordingly.
Display of Items, and 2D vs 3D
Short of such changes that would force the modification (however minor) of our contract code, there are much more trivial code re-use questions involving our particular method of displaying the personal inventory and marketplace offerings. We're using 2D UI panels for both of these, and the easiest thing would simply be to incorporate these directly into your own 2D or 3D "outfitting" scene (whether or not you chose to use our Medieval graphics elements). Even most 3D action games typically display personal item inventories on some kind of 2D panel, to minimize screen space if you need to access these items during combat. In a 3D game, the marketplace could instead be a 3D table or stall, or even a Mad-Maxified Walmart; the basic mechanics of populating these spaces could still be the same (PopulateMadMaxWalmartInventory() in the presentation tier would become the familar FetchMarketItems in the ExampleManager class). And of course, once a user owned a particular item, like an assault rifle, it could be displayed one way in an inventory panel (e.g. as a 2D sprite) and quite differently (an animated or otherwise complex 3D prefab) in actual combat, while still being essentially the same data object in contract storage.
Further Extensions: Beyond Our Use Cases
Display of High Scores
The tutorial scenes merely mint the tokens; none of the latter game dynamics are included. This is why there is no concept of a player score here, which would only be earned through actual gameplay. As far as the Tezos contract back-end is concerned, users exist purely as wallet addresses, with which whatever items or currency tokens are associated. This is very much by design. Just as it would be incredibly expensive in contract calls, and very high-latency, to use the Tezos back-end to manage a highly dynamic value like RemainingAmmo for your assault rife during a firefight, it would be an equally bad idea to manage on-chain other transitory values like a user's current health points, or their current score. All such kinetic game-dynamic data should be managed on the Unity side, in-session, as it would be for a traditional Unity game (exceptions to this would fall far outside the live-action game type, such as turn-based strategy, card or casino games that might be managed entirely on-chain; these will be discussed below).
But what if a user, in a particular session, has attained an unusually high score--maybe their highest, or anyone's highest in some particular scenario? Perhaps they've been awarded a badge or medal to commemorate this feat. You could enable a feature such that these high scores or badges could also be placed on-chain, at the player's discretion. Of course, in nearly all large multiplayer gaming titles, such high scores are already accessible within the game and/or via external websites. And this is fine until the game is retired or goes bankrupt and its servers shut down, doing your best-ever score in that one event suddenly disappear without trace. The whole point of blockchain data is that it is transparent, or inherently public, immutable and decentralized -- no single person could decide to pull a switch and make that data disappear. For that matter, no hacker could hack a single data store and appropriate your high score or mastery badge to a paying client, or artificially boost their own score: that data is publicly and permanently associated with your wallet account, in identical data blocks stored on every computer, globally, that is running a node of the Tezos chain.
The great thing about this particular Display-of-High-Scores/Badges use case is that it wouldn't even require a modification of our own contract code-set --- because again, our contract is all about token ownership, not user scores. This could instead be done with a separate High-Scores/Merit Badge contract, with a separate contract id--though it could certainly still be called through our SDK. Or it could be instead integrated into our current contract-set: user id would be the same in both cases, a wallet account address. One would need to determine whether there was a real advantage to storing such high-score information within our own storage dictionaries, which are optimized for different data, as opposed to keeping it separate.
The Pentathlon Scenario
One definite advantage of keeping such score/achievement data in a separate contract, optimized for such data, would be the ease of retrieving it if, for example, some player or third party were to set a multi-game challenge: earn the highest score (or top mastery badge) this month in each of the following five games. Obviously, this use case falls outside the purview of anyone game's data universe--it would simply require that each of these five games did publish a highest-score contract which could be publicly perused, using one of the existing public chain-explorer websites or another custom-made for this purpose. These games wouldn't even need to exist on the same blockchain! Of course here we are getting into meta-game (or if you want, meta-verse) design and not intra-game design, but it seems worth mentioning as an extension or consequence of a high-score display use case.
Tracking Certain Scarce Reward Items On-Chain
Adding the ability for the game to mint certain items on-demand (as proposed above) opens up many possibilities beyond just allowing players to shop for specific game items as they equip themselves. One obvious use case would be the minting of reward items that a user could either find hidden somewhere in the game terrain or earn through some gaming exploit. In many games, reward items confer not only prestige but also extra capabilities, making them especially desirable. It is therefore usually necessary for the game economy that these items be rare -- if any and every player can find or earn them, they stop being special and would simply contribute to the 'power creep' that afflicts many conventional AAA games.
But if a game really wanted to make a reward item rare, it could declare that there were only a specific, finite number of these items to be found by the entire player base. For example, your medieval action game might announce that it has just minted a new magic sword NFT which will make its owners enormously powerful in combat -- and it has minted exactly 20 of these, for the entire user base to try to find or earn through some challenging mission. Traditional AAA titles will almost never do this, for a number of reasons, one of them being that players may simply not trust the game to be transparent about the actual number of such items and/or who has acquired them. But the beauty of these items being NFTs is that no such trust is required: since they are NFTs, anyone with an appropriate blockchain browser could determine a) exactly how many there are to begin with, and b) exactly who owns them at any given time. A third-party browser or marketplace could indicate, for example, that of the 20 magic swords minted by your game, 15 remain unclaimed (and so are still owned by the game itself) while the other 5 now belong to players A, B, C, D and E. Of course, if these acquired swords were displayed in a public NFT market, they could also be offered for sale to others. This kind of sale of rare/valuable reward items happens often enough in traditional AAA games, but there it's considered cheating and is often a bannable offense. In Web3-enabled gaming, it would simply be an up front part of the gaming economy.
In terms of mechanics, any new earning or claiming of a sword would trigger a call from the game to the magic-sword contract ledger, shifting ownership of that token. Obviously, you would need to implement such a magic-sword ledger, or more likely a rare-item ownership ledger that could be reused for any number of different item types. You would also need to implement a provision allowing the game itself to own NFTs, which is not built in but would be necessary for this and other related use cases.
User-Created Content as NFTs: Skins, Weapons, Vehicles, Architecture
To this point we have discussed only game-item NFTs that are in some way predefined by the game itself. But in the wider Web3 world, NFTs are much more commonly associated with unique artistic creations, especially 2D and 3D graphic art and music, which creators want to market outside the traditional means of creative-content distribution. At the same time, one of the most compelling and fastest-growing genres in the traditional gaming world is 'builder' games, such as Minecraft and Roblox (and there are dozens of more niche examples involving architecture, vehicle design, etc.), or games such as Fortnite, Ark and Rust where building is essential to survival in the game dynamics. So it would seem inevitable that the builder or user-composition idea and the creative-NFT idea be combined, and in fact this has already begun to happen in Web3 gaming. There is no reason why a sufficiently ambitious Unity game developer could not leverage this combination through our integration SDK.
To start with perhaps the simplest example, many traditional RPG games allow for the creation of custom 'skins' for their players' avatar (or in some cases vehicle). In a Web3-enabled game, a particularly compelling and original skin could be minted as an NFT, so that at a minimum it could be publicly displayed to others as a 3D graphic, and potentially it could even be sold and reused within the same game. This idea could then be extended to include user-crafted weapons, vehicles, even fortresses. Of course, simply displaying any such user-crafted NFTs would entail one set of technical challenges: your game would need to be able to render user-composed assemblages within the game space into some kind of common 3D graphics standard so that the resulting asset could be uploaded to a site such as IPFS (where NFT visual assets commonly live) and thereby displayed in a public NFT market. With that challenge met, a second set of challenges would involve buyers of such NFT items being able to actually use these for themselves within the game: for example, in the case of a user-created weapon or vehicle, the token representing that item in the blockchain would need to store enough "statistics" type data to allow the game to correctly interpret the capabilities of that custom item. But in principle this would be no different from the statistics of predefined game items, as we've discussed these above. One's data (or more likely metadata) model would just need to be capacious enough to handle whatever game-object performance characteristics you were allowing your users to create. And of course, if you wanted to extend this to user-composed architectural structures, your game would need to have a concept of real estate ownership, since you typically can't pack your fortress around with you on a generic battle map. But again, these are more challenges of game design than of Web3 integration. If your game allows users to compose and situate their own unique Crystal Palace, and is able to render that as a publicly displayable 3D graphic, our SDK would allow even such a complex NFT as this to be minted, bought and sold.
Creator Commissions on Resale of NFTs
In the current NFT art and music market, there are often rules written into the contracts defining the NFTs themselves which allow for what are essentially creator royalties or residuals. That is, when the creator first sells their artwork on a public NFT market, they receive the full purchase price (less some fee or commission charged by the marketplace) from the buyer. But if that buyer then turns around and resells the NFT, the original creator might receive, by contract rules, a commission worth perhaps 3-5% of the new sales price; and so on for any subsequent resales as well. This could be quite a meaningful arrangement for the creator if, say, they had marketed their artwork NFT for a modest $200, but in the crazed world of art-NFT speculation that work was eventually resold for $200,000, or $2 million.
So you could certainly implement a similar commission mechanism in your own NFT sales contract. Currently, the NFT-ownership ledger supporting our example contract only stores the current owner, but it could easily store the original owner as well. In fact, you could even do this kind of commission for sellers of hard-won magic swords or similar game-item rarities from that earlier use case, even though this was game-created rather than user-created content. The seller still earned their ownership. Perhaps in year 1 of your game's release, that magic sword might be worth $20 to some offhand buyer. But in year 10, when your game has achieved legendary cultural status, this same sword might be worth a million to a collector or super-wealthy game player, so why shouldn't the original owner profit?
But then, why shouldn't you as the original game developer profit as well? Owner commission aside, you could take your own 3% commission on any and all NFT sales from your game, since--user-created or no--without your game there would be no NFT. Presumably as a successful game developer, your primary income streams would be ad revenue and in-game hard-currency sales, but this could be a secondary income stream (which could, indeed, conceivably continue for years after your game was no longer active).
Games Hosted Fully On-Chain
To this point, we have largely discussed live-action games, and their potential for leveraging blockchain integration. But we have also tried to indicate the limitations of this general use case. It is not currently feasible to 'host' an entire live-action game fully on the blockchain, because as we've explained, every blockchain transaction entails gas fees (whether the player or the game itself pays them), and there is also, always, some degree of latency involved. It would therefore be entirely impossible to register, on-chain, the hundreds or thousands of events per second that would be entailed in managing even a relatively simple live-action battle, race or other kinetic scene. This is why all of our Web3-integration use cases involve discrete and periodic transactions, like NFT minting and ownership transfers, or perhaps posting a high score after a game.
But as of this writing, the majority of existing Web3-enabled gaming is not live-action. To be sure, Web3 integration with live-action games is rapidly growing, especially with larger studio games. Consider this list of the top 100 Web3-enabled games for 2022: https://blockchaingames.fun/blockchain-games-list/ : quite a few of these are live-action shooters, RPGs, racing games, platformers and other kinetic games, and if you dig into the details you will find that in all cases the Web3 part involves use cases of the kinds we've discussed. But the majority of games on this list are still not live action: they are Trading Card Games, or turn-based strategy or RPG games, or mining or farming games, or some other genre where the gaming dynamic itself is episodic.
In any kind of turn-based game, whether it be chess, old-school card games, or strategy games, each player is making one or a set of tactical/strategic decisions and then submitting this 'play' to the opposing player, or to a game manager to decide the outcome of that particular confrontation; a series of such discrete confrontations will then decide the winner. This kind of game dynamic is entirely manageable via smart-contract calls, as long as the supporting contracts know the rules of the game and can apply them to any submitted 'play', applying some kind of randomizer ('dice') where that's appropriate to help decide the outcome. In other words, a game like this would require a client app that was simply capable of marshaling the player's particular choice or choices in a given turn, and then submitting this play to the contract -- either the client or the contract could keep track of the sequential turn outcomes and determine the ultimate winner. Essentially, then, whether some or all of the game dynamics would be hosted on the blockchain, and no other 'server' would be necessary.
Really, the question with such turn-based games would be the degree to which a gaming engine like Unity really contributes to developing them, since it is first and foremost a spatial and physics engine designed for real-time action simulations in 3D or 2D environments. On the other hand, if you consider the card-based games featured in that blockchain games list linked above, you'll see that many of them feature some quite fancy and animated client action to set up each 'play', so Unity might prove to be at least as good an authoring (and game management) platform as any other. And, of course, the whole point of this documentation is that a Unity client is now able to communicate directly with the Tezos blockchain, courtesy of our SDK.
High-stakes wagering games
The value of hosting a multiplayer, turn-based game fully on-chain is not just that you don't need a separate game server. Or that it's essentially impossible to turn such a game "off", if for example the original publisher lost interest but the player base didn't (because the supporting game contracts will be around as long as the underlying blockchain is). Another potentially critical value here would be transparency: in theory, all the specifics of a given turn/confrontation, both the inputs and the outcome, are available for public inspection on the chain, in real time and at any point in the future. This might not be especially important for casual gameplay, but it could be extremely important if there were high stakes wagering on the outcome of a game. On-chain turn-based games might still not be 100% protected against cheating (for example, I could find a way to hack my opponent's game client and learn what their poker hand is), but they are vastly more transparent than most online casino games currently are, and indeed more transparent than many real-life casinos are.