Blockchain game table stakes and the tracing paper model

The trace is matched to the map to prove the game

Before diving down the rabbit hole of map secrecy and turn validation on a public blockchain, I’ll sketch out the properties I think can work for a public blockchain re-interpretation of Deathtrap Dungeon, a seminal piece of interactive fiction introduced last time, and deal with some table stakes issues:

• It seems workable as a turn-based / round-based multi-party/player experience.
• It could be casually paced. Due to its narrative form, response times in the order of small seconds should be fine.
• A collecting motivation for records of victory and rare items looks possible.
• A creator's motivation for producing and dressing interesting dungeons looks likely.
• The possibility of rewards, honors and forfeits that would benefit from the transparency and autonomy (in the autonomous worlds sense) offered by decentralised ledgers. Your keys, your digital property — and your on-chain peril.
• Can be incentivized by fun, agency, and a sense of creativity, rather than shallow speculation or sweatshop-creating grind.

Table stakes

For me, the table stakes issues for games in a distributed setting are deployment, authentication, and payment. Opinions will vary :-)

As a developer, once the smart contracts are deployed (the Optimism docs are great for this, as are those for foundry and hardhat), I can be done with backend servers, databases and data redundancy.

Even if I put a fancy WebGL front end on it, that can all be provisioned via something like vercel straight from my free GitHub account. No T&Cs to sign. No IP rights to assign. No filter, I can ship what I build.

Of course, I can choose to also have all the usual infrastructure for a multi-player eco-system and just use the ledger tooling to make the rules of the game and its ecosystem transparent and autonomous, but I don’t have to do it that way.

But just because I built it, there is no reason to assume that they will come. Without some significant effort in marketing, they almost certainly are not coming. But there is nothing specific about blockchain in that, though there may be new tools to apply.

For authentication, I can use web3auth to make these annoying web3 wallets look like just a normal 2FA login flow. Again no real hosting pain or user management pain if I don’t want it. Once I get my head around OAuth2 and OpenID Connect (regular open standards), I am mostly good to go without a fancy big platform. And web3auth is genuinely self-custodial. Here are the 300 or so lines of javascript that we used to get self-custodial wallets for any chain (including our own custom one) going. Check out Fortanix, Fireblocks and Imutable for some other choices in this space if web3auth doesn’t suite you.

For payments, we have that built-in sort of. Unlike the early internet era which essentially forgot (or naively denied) that nothing is free, payment is an essential component of every request on blockchain (ok, not all of them, but certainly Ethereum compatible ones). It has become a fundamental part of the security model in proof of stake.

We know very well, paying for every request is an enormous over correction but that problem is being addressed. There are plenty of blockchain gaming dreamers on medium writing about how ;-).

I get access to that, stepping carefully around the specter of Gary Gensler, without signing over 90% or 70% or 30% or 15% of my revenue. And remember that when I do sign those T&Cs on other platforms, they are only there for the benefit of the platform. If I think I am not getting my due from those terms, as an individual player creator, or semi-professional developer, I can’t afford the legal representation to fight my corner if I think I am getting short-changed. And I have a very disadvantaged view of the data I would need to prove my case.

But we do still have the FIAT on/off problem. Again, I would be looking to web3auth here in the first instance. There is no shortage however of solutions now in this space — wallets, nft listings, and payments are the toothbrush test-passing problems that a lot of games and blockchain ventures seem focused on. Increasingly, you will get to choose something that is a good fit for your stack. To be fair, I think it has to be said that this toothbrush problem is essentially created by the solution of blockchain — but tomato / tomato.

The tl;dr of the table stakes situation is simply that the things you need are pretty much there now. IF your expectations are suitably constrained. There is nothing in the space to compete with the surface area of the Steam or EPIC developer platforms. If you can’t live without all of that, or you are not allowed to include blockchain elements whilst staying there, you may want to check back again in a year or so. But if you are lean and hungry, and have a game design that can benefit from some form of neutral and trustworthy governance or reward system, the time is now IMO.

The first time around some time will go on choosing and integrating a bunch of new tooling. Over time better things will come along and you will need to re-tool a bit, but from a certain perspective, this is just development business as usual with some of the words being a bit new.

Everyone I ever worked with in games is super smart, and I can’t imagine they would find this hard IF they decided there is utility here.

Enough about those prima dona devs,

What does the player get?

As a player, more than anything else, I can choose whether I care about the blockchain bit. It's a game. It is fun or it is not. I don’t have to notice the blockchain any more than I have to notice what kind of GPU my PC is packing. As pointed out by Sam Peurifoy recently, blockchain is a technology, like https, not a product.

If the game is fun then I will spend time in it and I will probably get quite attached to my experiences in it. Then I might care about some of the utility properties that come with the blockchain baggage.

Playing is creating. And I own what I create. It might be a very simple thing I own, but it is mine and, subject to buggy software, our ability to generate electricity and the second law of thermodynamics, it is mine for practically as long as I could care.

I can tell if the game is fair. And I can tell if other players are playing fair, Or at least the game can be made so I can tell, and I can choose not to play if I don’t like its rules.

If the game is made a certain way (and I can establish this directly), I can mod the game and compose the game to my heart's content and know that the fruits of my labor aren’t going to get rugged on me by the next client update. And this need not hinder the ability of the content producer to be properly compensated for their creation.

There are loads of posts out there now writing about this sort of thing. Plenty with more care and attention than I have spent above.

What I want to do with the rest of this story is get into the specifics of how we approached “the fog of war problem” in our re-interpretation of Deathtrap Dungeon and provide links to actual code so you can decide for yourselves if my assertions above are just more words on another pro blockchain gaming medium post or if they are supported by the results of genuine endeavor.

Breadcrumbs seeking forest

Putting any game on a public blockchain which depends on secrecy for its suspense and entertainment value requires a fair amount of mental judo before things seem tractable.

Most people doing a first pass research on games on blockchain will quickly uncover the commit/reveal pattern, and usually by way of the battleships example.

The first approach we tried I call the ‘tracing paper’ and ‘bread crumbs’ model, and it is arguably just an extension of the battleships model. It was a not very good solution for chaintrap in a number of ways. But the ways in which it wasn’t good served our purpose at the time quite well. It was great at being GAS profligate and contract code size profligate. And this was what we wanted when we were focused on our “Robust Round Robin” consensus implementation

The core idea was to record a trace of player choices on the chain. These are the bread crumbs. Think of them as suspended in space with no ground or forest for reference.

For each bread crumb declared (committed) by the player, the dungeon guardian then must declare whether the choice was valid. And also declare the outcomes of each move — just like a D&D dungeon master. The dungeon guardian would declare the completion of the game and, to avoid a forfeit, would load the map onto chain and call the contract method to play back the transcript against the encoded map data. If the transcript is verified, the outcomes endorsed by the guardian during play would be honored by the contracts. In other words, the map is drawn on ‘tracing paper’, and at the end of the game, it is ‘fitted’ over the trace of bread crumbs on-chain to verify the outcome.

It breaks down like this (with references to the implementation):

• Each game is created and setup by a dungeon master. Creating a game records a commitment to the map on-chain without revealing anything about it. See _init.
• players register for the game by calling a smart contract method joinGame.
• The guardian commits to player start locations by calling setStartLocation. All locations are tokenized (in the hashed and salted sense, not the nft sense), and a player has a current location number but the on-chain representation is opaque and unique for that player. The dungeon master knows the token to location mapping.
• The guardian dresses the dungeon by committing to furniture placements (traps and treats) placeFurniture
• The guardian starts the game when they have sufficient players registered by calling start.
• To use an exit and move to another location, a player calls commitExitUse
• OR to use a furnishing, a player calls commitFurnitureUse
• The dungeon guardian declares the outcome, which may be to *reject* the move, by calling allowExitUse or allowFurnitureUse as appropriate.
• Players are prevented from committing to a new action until the dungeon guardian has resolved their previous action.

This process repeats until the guardian decides the game is complete by calling complete.

Now we get to the verification. And it should be clear that up until this point, there is nothing on-chain that lets the players confirm the guardian is acting honestly and isn’t just griefing them. Also, this model requires a very explicit on-chain representation of the dungeons and play mechanics. This library contract defines the format for the locations that must be loaded after the game completes in order to verify the transcript. This is not very composable.

As the transcripts can have arbitrary length we have to use an iterator model, which implies multiple and unbounded transactions are required to verify a single game. The mechanics of playing back and verifying the transcripts can be seen in the playTranscript method.

A sense of the cost of loading the maps can be seen in the foundry-rs based unit tests for transcript playback, particularly the loadDefaultMap helper.

Also, a significant cost factor for the guardian is how the choices are communicated to the players. With each allow method, the guardian includes a blob of bytes revealing the next location, essentially this is the ‘next page/location’ in the book. It looks something like this once the CALLDATA is decoded:

{
 "corridors": [[], [{x:124.02, y:567.03}, {x:124.02, y:367.03}], [], []],
 "inter": false,
 "w": 1200.0,
 "l": 1800.0,
}

Which represents a four-sided room with two doors on the west side, and none on any other sides. All rooms have 4 sides.

"inter": true

would indicate a cross roads junction in a corridor. The geometry like data is used by the player client to render a room and place the exits, and we haven’t even included the narrative text yet.

Now, especially on an L2, and especially without the short lived blobs of EIP-4844, declaring the pages as play progresses, then loading the map, and then verifying the transcript is a really expensive way to do things! I’m not going to do the usual GAS break downs for these methods — I don’t really want to know :-)

Cliffhanger — I think we can do better!