This is the third in a series of casual writings on web3 game design. In a former life, I was an academic in the field of game studies, today I help accelerate web3 companies. For shorter-form content, you can follow me on Twitter @DangerWillRobin 🧵.

Permissionless Play Automation

When you can play for external rewards, the normal incentive structures of games change. For example, if I play Chess against a friend, I will not us an AI tool to cheat. The fun of trying my best against a friend outweighs the benefits of a valueless win. On the other hand, if we are playing for a prize with important value, we are both incentivized to cheat. In fact, you can say that we are playing a new game called How Good Is Your Chess AI?, in which players compete to build better and better software to win at Chess. The scope of the game then is dramatically expanded to something akin to running a software company.

Playing permissionlessly in web3, looks a lot like the latter case. In this space, with real prizes, open-source code and a permissionless backend we call blockchain, you need to build to win. We are then presented with an enormously impactful constraint, which is that web3 games need to still be fun in this context. In this blog post, I explore how Dark Forest can remain an interesting game in this context.

Some of the Code is Law

It is May 2021, Dark Forest v0.6.1 has been released and Ansgar Dietrichs, a protocol researcher, decides to direct his knowledge of web3 and Dark Forest’s codebase towards winning the round. While he takes several steps to give himself an edge, perhaps the most shocking is that he alters the game client.

For those of you who aren’t familiar with what this means, allow me to expand. Online games can be thought of as having two parts, the client (where people craft their moves) and server (where moves are received and the game-state is changed). In web2, the client is always closed-source and permissioned to communicate to the server. By design, it should be impossible to alter it, as doing so would enable certain unfair moves. When web2 hackers succeed in undermining the integrity of a game, it is often because the client has been designed to do some of the rules policing and that policing has been circumvented. In Dark Forest, because the game-state is on a permissionless blockchain, the integrity of the the client cannot be enforced. In other words, anyone can communicate anything they like to the smart contracts on chain.

Ultimately, what Ansgar did was not rocket science. Once he noted that the game waited to finish making a move before communicating the next one, all he had to do was alter a few lines of code. All of a sudden, Ansgar was able to parallelize his moves and accomplish 10x what anyone else could. You do not need to be a brilliant general when you can issue 10x more instructions than your opponents. And in this case, because Ansgar was able to deploy a bunch of publicly released scripts (which he had admittedly also spruced up), he was able to automate his moves at about 50% the efficiency of a dedicated human pilot. Comparatively, Ansgar could be 5x more capable, while never worrying about sleep*.

I asked him if he thought this was cheating. He responded:

I 100% don't consider that cheating whatsoever. I think the beauty of an open-source game is that the base rules are on chain for everyone to see, and as long as you follow them, fair game. The vanilla interface is really just a "base suggestion" of how to interact with the game, and I think the Dark Forest team would agree that they very much hope more people will write their own custom clients in the future. They even actively help with that, by e.g. publishing npm packages one can use for building df tools…

Of course, cheating is a complicated concept, with a lot of grey area and social construction. Fun fact: one of my academic supervisors, Mia Consalvo, actually wrote the book on it. In some communities, what Ansgar did would have been reprehensible, but the web3 ethos here is pretty clearly on his side.

Sybil Attacks in the Absence of Official Clients

Sybil attacks are bad things hackers can do when they can pretend to be lots of different people. It is generally bad for a competitive online game when one player can pretend to be many players.

Because Dark Forest cannot enforce a specific client on its players, it cannot preventing Sybil attacks in the usual manner. Often, for online games, the client will check against a database to see that the player has a unique email address, or even cellphone number, on top of mitigating botting in a variety of ways. A permissionless game like Dark Forest cannot*. This is a property of blockchains where individuals can create unlimited numbers of accounts. In other words, one player can pretend to be 20 players.

Interestingly, Dark Forest does not have to work very hard to prevent Sybil Attacks because players grow exponentially in power. If you have the money, computational power and bandwidth to make 10,000 moves, you are probably better off spreading them across 5 accounts than 50. While this is more than piloting one account and thus not optimal from a web2 game design standard, the problem is at least bounded.

A good model for thinking about how this works is quadratic voting, but backwards. In quadratic voting, you vote with the Log() of your tokens. Having one person with 100 tokens is better than one person with 10, but much worse than 10 people with 10, despite both groups having the same number of tokens. The quadratic voting mechanism is designed to give more weight to people who hold more tokens, while still allowing the majority of people to have some power too. Quadratic voting is a mechanism which incentivizes Sybil attack. You would ideally take your 100 tokens and put each one in a unique address to maximize their value (Log(100) < 100⋅Log(1)). The converse then, which we find in Dark Forest, is exponential scoring, which disincentivizes Sybil attack (100^2 > 100⋅1^2). Pretty cool. In fact, as we discovered at dfdao, 7 people playing under one account is quite a good idea!

Incentivized Sharing

In order to disincentivize players from establishing permanently dominant positions, Dark Forest’s core team rewards players for open-sourcing their plug-ins and altered clients. Here the hacker’s dilemma is to either:

1. hide the code in hopes that it can confer an advantage across multiple future rounds to win several points,
2. or reveal the code and win immediately a prize for transparency.

While this might be a tough nut to crack, there is a meta-layer of incentives motivating the playerbase. Many players believe that revealing the code of their own plugins is good for the growth and future excitement around the game. If the game grows, then it is safe to assume value of the historic prizes will grow (as collectibles or maybe even as governance tokens).

Here then is a radically unexpected property of giving hackers ownership of their hacked objects. All of a sudden they want the game to stop being unfair. Their immediate incentive is to tell everyone how they hacked the game so that it can either be patched (or so everyone can use the hack equally). This in turn creates a virtuous cycle of players building tools to better play the game for other players to eventually use.

I think this is so neat that I want to say it a few times differently.

1. When you give hackers governance tokens, they are incentivized to remediate the situation.
2. If hackers can only steal governance tokens, then at a certain point they want to stop stealing and ensure that what they have stolen retains value.

Wow. I can’t even.

And I can speak from experience because in round v0.6.2, we, and everyone else who made it to the top of the leaderboard, used Ansgar’s client.

Additional Notes

1. Ansgar’s victory was not quite as easy as I made it out. You see, to broadcast a move to the blockchain, you need a node on the network that will listen. The public nodes for xDai were throttling everyone, so Ansgar also needed to spin up his own node to push his moves in without hindrance.
2. Dark Forest currently has a whitelist to limit players in order to prevent the xDAI chain from being overloaded. That said, one player can use many whitelisted keys as the keys are not strictly tied to specific people.