For today’s Devs on Devs, we sat down with opnpc and 5p0rt5BEArD of Downstream, “the world's first Post Singularity Civilisation Simulator.” In this chat, the two spoke about all kinds of origins, building in Downstream, and what we can learn from gaming’s past. You can play Downstream, check out their builder docs, and learn more about their Redstone Community Spotlight.

Naming Origins

opnpc: So, let’s deal with the elephant in the room! Why is your name 5p0rt5BEArD?

5p0rt5BEArD: Good question. It's a nickname my friends gave me. When we started Playmint I didn't really have a good online tag and since a lot of the space is pseudonymous I felt like I needed to pick a good one. The name 5p0rt5BEArD is funny because it's surprising that I like sports. I'm stereotypically geeky, and it's unusual for someone of my perceived level of geekiness to either play or watch sports. What about you?

opnpc: I had the same thought when we started; “I need a pseudonym for working in this space.” opnpc stands for Over Powered Non Player Character. It came from that meme about most people being NPCs; the idea that some people are main characters but most people are NPCs. And I remember thinking, firstly, that's a bit mean.

And then, okay, surely the extent to which you're a main character or an NPC is a matter of perspective, right? And if everyone else sees themselves as main characters, it might actually be smart to go undercover as an NPC, but an overpowered one. You need me around to progress your main quest line!

5p0rt5BEArD: I think this whole project was your naming responsibility as well. Why is our game called Downstream?

opnpc: There's two reasons. One is convenience. The repo was named “DS” because the game was originally called Dawnseekers. And the engineers told the creatives that they could pick any name they like as long as it abbreviates to “DS”.

The other reason is that Downstream is a post-singularity civilization simulator. It's about what happens downstream of a fast-takeoff AI scenario. We imagine a friendly, well-meaning, but somewhat misguided AI has destroyed everything, and is trying to rebuild society out of hexagonal tiles and goo. We thought that was a fun prompt for a game about building. If you have to rebuild society from scratch, what do you build first? Games of course!

So with that in mind, what can you actually build in Downstream right now?

What Can You Build in Downstream?

5p0rt5BEArD: Downstream is a multiplayer world. Your agent in the world is a kind of woodland creature who moves around blue hexagons and gets to do a certain number of things like build or knock down buildings, extract goo from the world, make items, or turn those items into other items. Downstream is about using those core systems, and providing tools for people to build experiences out of those.

Right now in Downstream you can create what we call a zone, and as owner of the zone you get to shape what that little part of the world is like. Then anyone can go and play in your zone. You set some rules as the creator, but then everyone plays under that same set of rules. You’re creating zones and experiences for other players, but then other players can permissionlessly build on top of them, with the potential for chaos to emerge.

It's early days in the civilization simulation. What can you make out of goo?

opnpc: Well, you can make an infinite amount of things out of goo.

5p0rt5BEArD: I think that's more of the problem. Anything and nothing is possible. It makes it hard to explain the game to other people. Do your kids know what we're making? How do you explain Downstream to your kids?

opnpc: I just tell them that we make games. At a stretch, maybe you can have a conversation about where games come from in a more general sense, like who makes games and who owns them. I don't think we’ve got as far as talking about decentralization, but one of the times they see me most frustrated is when I'm trying to deal with permissions for Minecraft servers. So they will grow up with an understanding of the evils of centralised control!

What about you? Not just kids, but with friends and ex-colleagues. What do they think about what we're doing?

5p0rt5BEArD: It’s interesting trying to explain it to ex-colleagues, partly because there's a lot of misconception about working with anything to do with blockchain in the games industry. I mean they're polite about it. I don't think I've got a reputation for scamming people, but they think maybe I've been misled by someone else. By an overpowered NPC.

If I’m talking to my kids, I tell them I'm making games. If I've got a bit of time, we usually go quite high level quite quickly and start talking about the benefits of decentralization and sort of dismantling the power of centralized corporate networks and maybe talking about social media networks, before then bringing that back into games.

You can usually bring people on a journey. So what if the place where I publish games isn't owned by anyone? Or maybe the Apple App Store exists in a format where it's not owned by Apple and they don't have the right to pull games that they don't like. And people start understanding it from a high level and then understand what we're building with Downstream and sort of emergent composable worlds. It's still quite abstract though. I'm looking forward to being able to show more of them Downstream in practice.

Genuine Freedom in Games

opnpc: I think game developers are often in the place where they're super focused on trying to make and ship their games. And so if you're working on something that doesn't immediately help them make and ship their current game, it can seem just a bit bizarre.

5p0rt5BEArD: The normal mode of operation in game development is moment to moment, getting the next game done, getting it shipped. So while I've kind of gotten used to it now, I find it really refreshing that we're more future-thinking in what we're building. That is odd to most game development life.

And what about you? You're quite good at describing what we're doing at a high level.

opnpc: We're fascinated with the idea of giving people genuine creative freedom in games as something beyond just user-generated content. We want to give people the opportunity to make completely new things together. We heard someone in the scene call it wizard powers in reference to early MUD games — multi-user dungeon games rather than Lattice's MUD. We're imagining the feeling as something more like jamming with your friends or doing improv comedy.

It's that feeling of creating something meaningful together in that moment. So one of the thoughts we're chasing is: can we make everyone into a creator, give everyone the experience of making something genuinely new and cool, and the opportunity to show it off? I think the Autonomous Worlds thesis kind of gestures at this, but a lot of people have imagined AWs as these big monolithic spaces.

The problem with big shared social spaces is that they're really hard to manage. The main issues are actually social rather than technical. So in Downstream, we're giving everyone the power to make much smaller things at the beginning called zones. Everyone gets the chance to make a zone and you can go into someone's zone and help them build something new. Perhaps some of these zones will grow to be independent nation states and others might just stay as a little chill out area for you and your friends.

Blockchain is hard, so we do have technical issues too. We limit each zone to 20 concurrent users right now. But that will get better over time, whereas the social issues of having lots of people in one area will remain.

Since we’re talking about Autonomous Worlds, what do you think of when you use the phrase?

5p0rt5BEArD: My thinking evolves a lot. Many of us who've been thinking about it for the last year or so might have different answers. But the main thing for me is it's a godless world. A digital world that doesn't need anyone or any company in particular to keep it running. So if Playmint were to make an autonomous world, it's important that if we disappear, that world keeps going.

That's the essential bit of an autonomous world. But then what makes that interesting is everyone's experience and interaction with that world, I believe, will change when they trust that it's autonomous and doesn't rely on Playmint. So all of these creators creating in that world are creating on a consistent, solid bedrock — what we term digital physics. The set of rules that don't change in that world.

I don't think anything's really got there quite yet, but we're definitely on that path and we're trying to build Downstream to demonstrate the interesting bits that will be possible when it is autonomous. And I think it's a big step coming up with our first mainnet release of Downstream. That's a big part of credibly living forever.

So yeah, that’s why we took part in the race to mainnet. It's exciting to be on Lattice's Redstone in particular. Maybe opnpc, you can talk about why we're happy to be on Redstone.

What Can We Learn From Minecraft?

opnpc: This is still very early days for Downstream. We keep saying that we're like Pre-Alpha, like not even Alpha. But we want people to have that experience of building on something that feels independent of us as Playmint, like you say. So launching even a pre-alpha on mainnet is important step for us. And to do that with friends as part of a wider community effort makes it super fun. Seeing all the different projects coming together at the same time is really exciting.

5p0rt5BEArD: Yeah, definitely on-chain indie vibes. That feels like where we're at. It's fun, experimental stuff at this stage. We’re not at final solutions.

opnpc: Right, and Downstream is the way for like other people to get a piece of the action. We started off saying this as a joke, but we think Downstream might be the easiest and fastest place to make on-chain games right now. Partly just because a whole bunch of the work is done for you, so you can turn up and use our assets and infrastructure, and make your own little game in a zone.

We also love the story about Redstone in Minecraft. It might be apocryphal but it’s too perfect. In the original Java edition, Redstone was full of bugs. Things like quasi-connectivity and zero-tick piston retraction are unintentional features of how Redstone was implemented. But people have gone on to build these incredible machines on top of it. So at this point, nobody wants it fixed.

So when Microsoft came and rebuilt Minecraft in C++ for consoles, what they’ve called Bedrock Edition, they ‘fixed’ some of these bugs. This broke a whole bunch of the most useful farms and tutorials. And we think that's a pretty beautiful metaphor for a bunch of people working on something really early. The correct implementation is less important than capturing the imagination of builders and letting them cook.

5p0rt5BEArD: The important thing is that the physics of a world are fixed and reliable. People get annoyed if it's changed, but they don't get annoyed if it's somehow broken or not quite what the creator intended. They’ll work around the broken parts because that's the way the world is. That stability is important for people to build on top of it. It's definitely a good metaphor for what we think is cool about autonomous worlds.

For this installment of Devs on Devs, we sat down with ARB and Alex Declino of Moving Castles, the team behind This Cursed Machine (TCM). TCM is “a scifi horror warehouse management RPG” where you, a stump, fulfill orders from the game’s eponymous company, and earn $BUGS as a reward. In this chat, the team discussed their inspirations, designing a game with emergent gameplay, and much more. Play This Cursed Machine here. 

Reinforcement Learning as a Game

ARB: What could be a well articulated description of This Cursed Machine? It’s a tendency when you're in the middle of developing to say that the project is about only the specific thing you're fixating on right now.

Alex: Maybe we can start from some of the inspirations of the game, and we can then walk our way to what the game actually has become. I remember some of the first inspirations were the infamous Amazon worker cage patent and the Skinner Box Experiment. For those unfamiliar, the Skinner Box Experiment marked an early exploration into psychological conditioning. It involved placing rats or pigeons or other animals (someone even say kids) into controlled environments, known as Skinner Boxes, and through reinforcement learning, observing their responses to stimuli.

One notable application of this experiment was during wartime, where attempts were made to train pigeons to drop bombs. This experimentation highlighted the power of conditioning through consistent tasks and rewards. Interestingly, the Skinner Box concept is widely recognized in game design theory, where developers craft positive reinforcement loops by rewarding players with loot boxes, in-game items, and other incentives.

ARB: It's become a negatively associated term for a specific type of game, no? A game that traps people in these kinds of loops.

Alex: I guess in the case of the latest Diablo game, it’s an example of that kind of dynamic going being pushed to its extremes. I think there’s also a nice use of it though, in games like Super Mario Odyssey. I played it and found it really interesting. Whenever there's a new, unclear mechanic introduced, the developers strategically placed coins around it. This incentivizes you to explore and engage with the mechanic, as they know collecting coins feeds into that rewarding loop, leading to the discovery of something new. It’s great game design in my opinion, because this goes mostly unnoticed and the players think they did it alone.

…but of course, in perfect Moving Castles style, we took the worst case of the Skinner Box mechanic, and made a whole game out of it.

ARB: In the end TCM is very much a Skinner Box Game, set within an Amazon warehouse cage.

Alex: Yeah totally

ARB: For the ones that don’t know this obscure meme, the worker’s cage is a patent claimed by Amazon that represents a vision of the future workstation - a protective structure allowing workers to navigate automated warehouses safely, shielded from the moving machinery surrounding them. Artist Simon Denny explored this concept too, creating a large-scale interpretation patent.

Bringing these elements together, TCM embodies the essence of a Skinner Box Game, played within the confines of an Amazon warehouse cage.

Alex: In the game you play as a Stump, a new employee of a warehouse operated by a company called This Cursed Machine (TCM). Your primary objective is to compulsively fulfill orders from both TCM and other Ghost Companies. As you accomplish these orders, you earn a reward in the form of an erc20 token called $BUGS. These tokens can be utilized to progress further in the game, fulfill more orders, or alternatively, hoard them for other in-game purposes. We often describe TCM as a scifi horror warehouse management RPG.

ARB: The core mechanics of the game revolve basically around constructing machines and interconnecting them to fulfill the orders you receive. You must connect these machines to your own body to facilitate the conversion of materials. Orders may entail producing items such as steroids, mucus, or insulin, and other 150 materials, starting from your bodily fluids and $BUGS alone. Gradually, you unlock access to additional materials as you progress through the gameplay.

Plugins for the Stumps

Alex: We’ve kind of already seen people interested in building on top of TCM. We saw some people like, actually, maybe, Arthur, you can talk about it, because it's all stuff that came from the AA Worlds event in Lisbon, which I unfortunately missed.

ARB: Sure, I’ve seen a lot of potential for further development and expansion within TCM. There are several paths to explore, including leveraging the $BUGS tokens for various activities like gambling or creating pastime activities for Stumps. Additionally, enabling players to create orders for other players could open up ways for trading meme tokens and fostering a unique economy within the game.

That is something that currently does not have an interface but potentially has the most fun possibility where people can use the Stumps and TCM as a way to trade meme tokens, because you can now order a material, set a material order, and you will pay in $BUGS. And in return, you get specific materials as a ERC20 token from the game out to you. So that might be, again, like nicotine, cigarette juice, or grown parasites. People will be playing as Stumps first and then potentially advancing to being evil corporations in the game. I think there's also a lot that has happened with identity-building around meme tokens that could be interesting here.

And then we know that there are people building things like employee of the month leaderboards. There is one team doing factory analytics for the whole machine and seeing what happens, and individual stump performance analytics. There is currently not a prescribed goal other than to earn bugs, and we don't have a leaderboard integrated. We want to see those things emerge outside. And those are also things we would like to see, like is there a way for people to build custom interfaces that are directed towards specific goals? Or custom sites that represent fake companies, or bug gambling sites and all of the above?

Composability on Redstone

Alex: We've been like mad early adopters. So there was only one way forward, which was Redstone.

ARB: Yeah, it's going to be interesting. I feel like the possibility with Redstone is that there are many games on it at the same time. There have been some explorations with cross-functionality between the games, and that will be interesting to see more of that. This is what’s unlocked by being on the same chain. At the same time, it feels like the most interesting things that emerge from that are based on player activity or mechanics itself.

Most of the things I've seen so far are more like simple token swap functionality, which is natural because it's kind of the established way of thinking about interoperability or composability within blockchains. But it's maybe not the most interesting or novel way. And I hope to see more stuff in that direction. And I think that can happen first after people actually understand the hope for something to emerge from Redstone mechanics and are poking around with it in a deeper way.

So that would be one of the reasons. But the main reason being that it was great timing for us. And Lattice has been a good partner on the engine side with MUD, and it felt like a good next step for us to release on Redstone.

Understanding What Works Onchain

Alex: I think we're facing two primary categories of challenges. The first involves understanding how to effectively leverage onchain mechanics, how to make a smooth UX onchain and keep players in the flow of the game considering the “clunkiness” of this world computer. The second is more of a conceptual shift in game design principles and world-building strategies.

One major aspect of this shift is determining the balance between what you develop as the game creators and what you leave for the community to build upon. It's essential to understand how much autonomy and creative control you want to give the community while ensuring that you don't outpace their contributions. This requires a delicate balance and a willingness to embrace emergent gameplay and community-driven content creation, or what I called “The Squish”.

In autonomous worlds, it's crucial for game designers to adopt a philosophy of facilitation. They should not only design and implement features but also aid the community in the direction they embrace. Unlike traditional games where players are pushed along a predefined path, in autonomous worlds, designers should empower the community to shape the experience according to their desires.

MMOs already embody expansive systems, but in autonomous worlds, this concept should be pushed to its limits. Designers must embrace an open-minded approach, understanding that the game's evolution is driven by the community's contributions. Detailed central planning becomes impractical in this context, as the game's direction is determined by the collective creativity and engagement of its participants.

I think, navigating these challenges requires a combination of technical expertise, community engagement, and a willingness to embrace a new paradigm of game development where the community plays a central role in shaping the virtual world. It's an exciting but complex journey, and I'm eager to see how we’ll overcome these challenges and innovate.

ARB: The added complexity of having a new space, building onchain, which kind of challenges a lot of the established ways to think about games, is really challenging. We've built for a while now, but it's always a continuous learning experience. You have an idea, and then you adapt based on what you're learning, and then you have a new thing you have to build, and that constantly changes.

We put a significant amount of effort and time into adapting and refining the game's goals based on ongoing learnings and experimentation. Our devs efforts in learning and navigating MUD, as well as understanding how to represent transaction states, have been incredible to be honest. We are super happy with the sense of tightness and coherence within the game mechanics that we achieved, but there have been persistent difficulties in achieving the same level of polish typically associated with traditional games due to the complexities of managing blockchain transaction states.

Alex: It should be easy to play your game right? Players should be able to dive into the game with minimal barriers to entry. Onboarding should be seamless, providing players with a straightforward introduction to the world and its mechanics. As players progress, they can gradually uncover deeper layers of detail and complexity, allowing for a more immersive experience. This gradual unfolding of details prevents overwhelming players with an excessive amount of information from the beginning and enables them to explore and engage with the game at their own pace.

ARB: But luckily for us we are making a game about a broken machine, so we can keep any issues with the chain diegetically.

Behavior Before Tech

ARB: We've been talking about the Unix design philosophy a bunch when it comes to composability. I came up with a much more complicated way to approach things and Rasmus and Alex have both hit me over the head many times throughout this process and forced me to simplify. We've embraced a sort of Unix philosophy, focusing on the principle of simplicity and modularity. Each component of our games should excel at performing a single function, with clear input and output mechanisms. Instead of complex interwoven composability, the emphasis is on creating discrete, standalone elements that are self-contained and capable of functioning independently. This approach promotes clarity, efficiency, and versatility within the system.

These are things I've learned through the process. And I think that's where we are building from now. You arrive at composable, autonomous worlds, not by creating a perfect rule set and like pre-designing and letting people populate it, but by creating Lego pieces that people then can build stuff with. It's more emergent, but each Lego piece should be well-articulated and simple standing by itself and hopefully memetic or sticky enough that people actually use it.

Alex:  A key design principle to consider is that people are drawn to and build upon worlds or games not solely because they are well-built or easily composable, but often because they resonate with them emotionally, intellectually, or humorously. These elements may possess a certain charm, quirkiness, or memorability that makes them stick in people's minds and encourages reuse and reinterpretation. In the context of games and cultural phenomena, people often engage with and reuse elements as a form of expression, identity, or social interaction, rather than solely based on their mechanical properties.

We should not over-fixate on the technical aspects of the game, but rather on what these new types of games give to people. Human behaviors before tech and infrastructure.

Importance of Prototyping

ARB: I mean, we have an interesting anecdote where Agnes built a terminal interface for testing the game. And then we were like, OK, we should just use the terminal as the interface for the game. That was a fun, surprising breakthrough in the interfaciality.

Alex: Yeah, in the early stages of TCM, we had a vastly different vision of how the game should function and feel. The specifics of the UI were unclear, until Agnes, one of our developers and collaborators, created a simple prototype overnight. It was a game-changer.

Agnes' prototype was a simple text-based input interface, and when I saw it, I immediately knew it was the right direction for the game. Despite any prior conceptions or discussions, seeing the prototype in action clarified our vision and solidified our approach. It was a breakthrough moment that highlighted the importance of hands-on experimentation and iteration in game development.

ARB: We're now launching multiplayer, so that's a big change. We started with a single-player game only, and once that was validated by people's reaction, we built out multiplayer. And that's what we're launching on May 4th, which turns the single player goal game into a competitive or somewhat competitive multiplayer game where people compete around fulfilling the orders.

It's a significant change, and the prospect of testing it is exciting. One aspect that I’m curious about is the extent to which players will collaborate in solving challenges versus pursuing individual growth. Observing this dynamic will be very fun I think. Will there be instances of solidarity among players, where they join forces to overcome obstacles collectively? Or have we effectively incentivized individualistic behavior, prompting players to prioritize their own interests above all else? We’ll see.

Dhrumil Shah and Dhvani Patel are the team behind Biomes, an onchain, Minecraft-like sandbox where you can explore, mine, craft, attack, and compete in user-generated experiences. We’ve known the team for almost a year, back when Biomes was known as Tenet, and the team was building a multi-layer, multidimensional physics simulation engine. Now, Biomes is in full swing on Redstone, as a fully-realized Minecraft-esque game, with docs for users to build plugins and games on top of it. Today, May 3rd, Biomes is being featured for our Redstone Community Spotlight initiatives, and you can learn more about how to participate here.

Building Onchain Minecraft

Dhrumil: Our guiding principles are very simple. The question we ask ourselves is “Can we make the least shitty minecraft possible?” Biomes is onchain so it's going to be worse than normal, off-chain Minecraft because you have transactions. You can't move in real time. If we could literally port Minecraft directly, we would 100% do that and call it a day. The guiding philosophy behind our project is not so much about the game mechanics. Neither of us come from a game background.

Dhvani: And neither of us really care that much about innovating on game mechanics.

**Dhrumil:**We believe that If you put anything onchain, you can now write a bunch of smart contracts on top of it to coordinate over whatever you put onchain. We wanted to go in the direction of doing something that's a sandbox open world where the game is just a bunch of resources in space with physics that guide how these resources interact, but nothing else beyond that.

And that's exactly what Minecraft is. Minecraft is really like toy physics for a bunch of blocks in space. And if you just have that, then things become really interesting because now you can deploy smart contracts to make everything in that world something people can coordinate around.

Dhvani: What is this coordination? What are they doing? What exactly is this behavior? What is this coordination going to do?

Dhrumil: I think one thing that's interesting, if we actually think about where we started from, we started this from a very weird set of digital physics.

Dhvani: Not even that, like a real-world sci-fi thing.

Dhrumil: Imagine you could write smart contracts all over the world.I can write a smart contract that tries to incentivize people around the world to grow corn. And if they grow corn, then they're all rewarded.

Dhvani: I remember the one I really liked. You write a smart contract that, if you take the bus instead of taking a car or if you bike, gives you a rewards. Something that aligns with the green movement..

Dhrumil: Exactly.

Dhvani: And because it's verifiable, somebody else could use that to gate, and say “To enter this club, you have to be part of the green movement.”

Dhrumil: 10, 15 years ago, when AI was still a meme, people would say, “Okay, imagine AI will solve your homework for you.” And it sounds like a meme, but at least people knew what it was capable of and then it got figured out.

And then I saw other people imagining DAO controlled drones that both deliver burritos to your home and like defend your borders from armies.

And this sounds like a meme, but this is literally why we got into crypto. DAO-controlled drones. Write a smart contract, incentivize corn growth, green movement, drones. But all of these things are obviously really, really difficult to do because it's hard to write a smart contract that can autonomously verify physical actions. The physical world isn't verifiable. This seems like a long way out.

So then we said, okay, if you can't do that, then it would just be interesting if you have that experience, but you can do that over like a sandbox virtual world. That'd be great. But building a sandbox world from scratch is really, really hard. Because, that's a lot of simulation. It's a physics engine. Yeah, but if you look at Minecraft, it's like a really playful toy version of that in a way. It's really dumbed down. It's not nearly as deep as our world. But it's a good step in the right direction.

We would love to just port Minecraft and then deploy a bunch of smart contracts over it to do crazy things. For example, have players go around building Optimism statues and submitting that they built it, and if they actually built it, then they get these coupons that they can use to force other Optimism players to drop items from their inventory. Or maybe a thing where I grow food and I'll give a ration of that food to you and in return you're responsible for protecting my village from being attacked.

But if it does get attacked, then you lose some stake. Stuff like that.

Dhvani: Could you do a thing where if there's Base and Base wants to incentivize people to break down those statues, could they deploy that in the same world? Because it's a smart contract, you can't go against the first one.

Dhrumil: For the sake of example, maybe not Base, how about Arbitrum? Arbitrum comes along and puts up a smart contract that says “If there are any Optimism statues and you break them then you guys can get diamond axes from the Arbitrum people.” All of these are just smart contracts trying to get all sorts of different things to happen in the same world. Kind of like what we have in our world where you have a bunch of like competing ideologies. It’s just minecraft but let's make it less shitty and then put smart contracts over it.

This is basically the philosophy.

Dhvani: What would you say so far, out of all the things we've done porting Minecraft, has been the most challenging part? In terms of porting.

Dhrumil: The on-chain positions.

Dhvani: Because people don't like that. Yeah, I think the biggest feedback is that the avatar versus player distinction has just been really hard.

Dhrumil: It's not as rapid as Minecraft. The UX is going to be shittier than Minecraft but because of the smart contract stuff, you get a new type of experience that you just can't have anywhere else. There are early adopters for whom that’s really interesting and then over time we can make the UX less bad but. The smart contract stuff opens up a huge new area, and it becomes okay.

Dhvani: The smart contracts are the game. If you want to play Minecraft, you can just go play Minecraft.

Dhrumil: We believe that maybe you don't have to actually create a new fun game. Smart contracts themselves are the game. So as long as you put anything over and have a base layer of the game that's really susceptible to smart contracts, you'll see something very special.

Why Redstone and What We Want to See on Biomes

Dhrumil: We picked Redstone because we needed a really cheap Layer 2. Redstone is the really cheap layer 2.

Dhvani: We're also building on top of MUD and Redstone is going to integrate nicely with MUD because of the gas tank stuff where you can just deposit to a gas tank and then use that gas across any MUD app across Redstone. That's pretty cool. It's sort of just an integration ease. And because we're such a small team, the more we get out of the box from infra, the better. That's also why we're using MUD, for that matter. We get to do a lot less work on client state sync and like on-chain storage optimizations. You get that out of the box if you use a framework.

Dhrumil: We want to see people using smart contracts to do a bunch of Mr. Beast type stuff onchain. I was talking to Proof of Jake who wants to deploy this experience where teams try to build the largest glass cube they can in an hour or in a day. And whoever builds the largest glass cube, they get the reward pool. Peter Pan wants to do this game called Make It Rain, where he showers ETH on a part of the map, and then everybody frenzies to get there first, and you have to prevent others from getting there, and it's a race. There's a bunch of these Mr.

Beast-type things that happen inside of Minecraft that you can't do on normal Minecraft because it's not verifiable.

Dhvani: Yeah, exactly.

Dhrumil: If you look at existing games, the surface area for economic activity in those games is limited to whatever was programmed by the game dev. So if they added in a way for you to buy in-game resources or if they added a trade system that’s the only economic activity you can have. And sometimes you have third-party markets, where there are trust issues. But that's about it.

But over here the economic activity you can have will increase by 100x because every single possible action that can happen in the world is open to economic activity. It’s just not an experience we gamers can have anywhere else.

A longer term thing that will be interesting to see is if we’re able to port over an existing game and make it less shitty, and make every single action in that world turn into economic activity.

We can take a very, very small fee of that economic activity and redistribute it to grow the ecosystem. By growing the size of the world, it could be an alternative form of a game studio. That'll also be interesting.

Let A Thousand Biomes Bloom

Dhvani: Why is the initial launch called Biomes 1? Does that mean there's supposed to be many of these Biomes, you know, Biomes 2, Biomes 3? Are we going to build 100 Biomes. It's like Nouns.

Dhrumil: There's Nouns 1, Nouns 2, Nouns 1,000. Hopefully there's 1,000 Biomes where anyone could have made the Biome and the Biome that someone made is just as credible as the Biome we made.

Dhvani: I can't imagine our team solely making a hundred different Biomes. It would be good to get an ecosystem of Biomes because there's no distinction between the ones we make and the ones other developers built. That is by default possible, first party versus third party.

Dhrumil: And I think one of the good things about this Minecraft direction is like this already exists in Minecraft. Minecraft mods are a big thing. People are totally down to make Minecraft mods, because there's already distribution. We don't have the distribution of Minecraft. But if we have much stronger economics, then it's possible for modders to actually do a much better job that way.

I think when people think about crypto games, they still primarily think crypto games are about making virtual resources economically valuable. Whether that's like, you have fungible resources everywhere, or you have NFTs everywhere.

Our team actually doesn't think of crypto games in that way at all. We view crypto games as like sandbox environments where you can use smart contracts to have a lot of coordination and generate a lot of drama inside of that sandbox environment. This is a side of crypto games that I think is totally not the dominant meta of what people think it's about. So we hope to push on that as well.

Dhvani: Yeah, it’ll be interesting if more of the games have the same hooks and delegations support.

Dhrumil: The North Star outcome of this project is people changing their idea of crypto games.

And even beyond that, in a small way, make people understand that this is what crypto can be used for. And obviously you can hear about it, but now you see it. You can participate. Even just for games, not for real stuff. It is a small push towards it.

That's what it's for. It'd be very great if in these next couple years, sort of the frame begins to change from crypto as solely being a way to create virtual scarcity. And into the idea that crypto crypto is a way to drive collective action.

We're at the center of the collective action as a computer program. And perhaps people can really experience that viscerally in these game worlds, which are specifically designed for that. If that takes off, then maybe in 10 years, we can have DAO controlled drones.

Dhvani: Yeah, that'd be cool.

For our latest installment of Devs on Devs, which we’re releasing for the Redstone Race to Mainnet, we sat down with Cherry Blue and 9STX6 of the Dark Forest Archon team. The team is building Dark Forest Ares, a community-run deployment of Dark Forest on Redstone. In this interview, the two devs discussed the glory of Dark Forest plugins, their approach to breathing new life into the classic Dark Forest game, and their experiences with Redstone (and plans to port Dark Forest to MUD!).

Redstone launches to users on May 1st! Get ready to play DF Ares and other Redstone games, and don’t forget to check out the Redstone Community page.

Augmenting the Plugin System

Cherry Blue:  Dark Forest Ares is a series of Dark Forest community rounds. Our goal is to introduce a fresh game design while integrating exciting new ideas, all while preserving the classic essence of Dark Forest, including its plug-in system and command-line interface.

For the classic Dark Forest game, I believe there are three key elements. Firstly, it operates as a ZK (Zero Knowledge) game, utilizing ZK circuits to establish a fog of war on the public blockchain. Secondly, Dark Forest is a fully onchain game, with all game logic stored directly on the blockchain. This allows players to interact with the smart contracts using various methods. Within the Dark Forest community, a plethora of modified clients and plugins have emerged. Additionally, community members develop smart contracts that directly interact with Dark Forest contracts to introduce various functionalities. This integration of newly developed smart contract systems with the original game contracts enhances the player experience, a concept we refer to as permissionless interoperability.

Thirdly, it is a real-time strategy game, with players from around the globe actively participating in the ever-open universe. Social interaction among players is a fundamental aspect of the gameplay experience.

Certainly, there are numerous aspects that demand careful consideration and trade-offs. For instance, due to the limitations of smart contracts in performing complex computations, the move operation essential for energy transfer between planets in the game cannot be triggered by other smart contracts, thereby somewhat constraining permissionless interoperability. Another instance is the emergence of large-scale automated plugin systems and GPU map mining tools, exacerbating the disparity among players and detracting from efforts to entice more individuals into the community. Our objective is to strike a balance amidst these trade-offs, where we can uphold the distinctive features and advantages of Dark Forest while also drawing in more participants, thereby fostering a thriving community.

9STX6: I think I will speak a little bit from the game mechanics side, not so much from the technical point of view. We’ve kept all of the mechanics from the original Dark Forest. That means players have some energy spawned on their planets, and they’re trying to conquer the most planets against the other players. And of course, they’re trying to establish some strategy for conquering the empires. We have specific types of planets, and some can boost your targets well.

For example, if you want to defend a certain area, you can choose a planet with a defense boost. There are planets in different biomes that change their beautiful appearance and stats. We have different variables inside the game. We’ve been optimizing the time frame of each round; it’s very important to understand how addictive this round can be. If you start playing and the round is for two days, the activity is a little bit different than if you play for 14 days. If you can control an area the size of an empire then you need to start thinking about automation.

The plugins are crucial for that. That's my inspiration behind this, looking at the limit where humans start to be ineffective against semi-automation. I'm not a big fan of the full bots. I think that the basic mechanics is that you're growing your empire, and behind it are a lot of secrets in ZK. We have circuits, we have the fog of war, we have many, many techniques inside the game that we can still reuse.

Cherry Blue: Plug-ins are a fascinating subject. Many community members can craft their own plug-ins to cater to their specific needs. The classic Dark Forest client boasts valuable underlying APIs, which developers leverage to create plug-ins. I've witnessed hardcore gamers devise semi-automated systems to navigate Dark Forest, requiring only simple configurations for plug-ins to execute various in-game tasks. Personally, I've ventured into developing an extensive plug-in designed to autonomously conquer planetary regions, employing recursive algorithms to address similar game scenarios. In my experience, the exceptional design of Dark Forest may render automated plug-ins unable to outperform seasoned human players. I'm eager to share this insight with everyone! I'm aware that this level of programmability often catches players unfamiliar with coding off guard, and they may subjectively perceive it as an added challenge.

From my perspective, programming offers a solution to handling repetitive tasks, empowering players to exercise their subjective initiative. This allows players to focus on more significant matters rather than getting bogged down in trivial operations. As a collective effort, our team aims to release additional open-source tools and comprehensive guides to familiarize players with plug-ins and streamline their interaction with the game.

One crucial point to highlight is that the blockchain platform operates on principles of openness and freedom, and the cost of maintaining such freedom is eternal vigilance. As game developers, we prioritize offering players a wide range of choices rather than imposing restrictions upon them.

Different Kinds of Plugins

9STX6: Basically the plugins are one of the components of automation, but of course plugins can do a lot of different things. In our last game we had this experiment with the Minimap plugin where we let players have some decision as to where they spawned into the game. In the original Dark Forest, this is completely random. We did an experiment to basically switch the random spawning to specific zone spawning using part of Minimap source code. This meant a new member of the community had some kind of decision at the start of the round about where they can spawn.

There are also some plugins we’re building that we want to eventually integrate into the default functionality of the client, like a more high-fidelity map visualizer. Together with the plugins, we also want to do things like marketplaces in the game contracts, where we can start to introduce a native economy into the game. In our round, we're starting to play with artifacts, and basically open the market between the players. Then we can have some other stuff inside the game that can introduce an alternative strategic goal, like how you can lead your empire to be profitable.

We're looking forward to adding more lore-specific content too. With that we could reach more players, and widen the scope of the game. You won’t just play to be a big emperor of everything, you’ll also have other things in the game to achieve. Of course, we like the conquering part of Dark Forest too. But still, there are players who like to just explore. To be honest, my first experience with the game was just rough exploring. And I love it!

Cherry Blue: Fully onchain games resemble protocols, meaning they're just a set of rules, and players can operate freely within those rules. Besides the client and smart contracts, I know players who even run blockchain nodes to gain more stable RPC for certain operations.

I understand the importance of attracting new players. Improving the user-friendliness of the client is crucial. However, we also believe it's essential to educate people about this new gaming concept. They need to become familiar with the fully onchain gaming paradigm.

Here is an analogy: Typically, players navigate the game using their own two feet. But with plugins, they can drive a car, which is faster. However, they must learn how to drive. Once they master driving, they can make more decisions and have more fun. This also explains why hardcore players of Dark Forest are so passionate about the game.

Why Redstone (and wen MUD?)

Cherry Blue: I’ve been familiar with the Lattice team for a long time, because we played Dark Forest and we loved to watch videos from 0xPARC. I heard about MUD in the summer of 2022. I saw ludens’ demo at D.E.F.C.O.N on YouTube, and I said “Wow, that's the future of blockchains.” And in the last year, we learned that Redstone would be released. So we chose to develop Dark Forest Ares on Redstone. Actually, we did a wide-range survey among all the EVM compatible blockchains. Among all the choices, Redstone is very fast and the gas price is very low. So it's very fit for the ambitious applications. That's why we picked Redstone.

We're also planning to port Dark Forest to MUD, and our team is currently discussing and formulating specific development plans internally.. We’re still using the Diamond Standard (ERC 2535). The reason for porting Dark Forest to MUD is because the classic Dark Forest codebase and development stack are somewhat outdated. For new developers, grasping the code structure is quite challenging due to the multitude of layers to consider. Developers need to understand ZK circuits, develop the game's smart contracts, and write scripts to deploy and test these contracts. On the client side, developers need to know how to interact with the smart contracts, maintain and update game states, and understand how to utilize WebGL for rendering in the presentation layer.

Additionally, there are numerous fine-grained details to handle. Developers need to grasp many aspects before effectively participating in development. I believe we should attempt to utilize MUD to streamline all of this, enabling us to concentrate on designing and developing the core logic of the game.

During the porting process, we may explore breaking down Dark Forest Ares into various modules tailored to MUD. These modules could also serve for the development of other games, thereby enhancing code reusability.

9STX6: I’ve known about MUD for about 1.5-2 years. After that I opened my console, installed it, and I started with the increment template. I think after three and a half months, four months, I had my first demo game written in MUD; it was a turn-based contract where I started playing with entities. It was very fast. And you can build on top of it. And there’s a great symbiosis between MUD and Redstone.

We were very surprised with the stability of RPCs on Redstone during the first playtest and also tested traffic by making a couple accounts constantly generate ingame transactions during a recent playtest and everything was fine.

Cherry Blue: Porting Dark Forest to MUD will be a massive undertaking. So, perhaps we can start small. Let's think about the key components of Dark Forest. For instance, we could begin by directly porting planets—without levels, just the planets themselves capable of attacking each other. This way, we'd start with a very basic game and a simple structure. Then, we can gradually expand. We might introduce artifacts and develop the client-side API system. It'll be a step-by-step process.

The Biggest Challenges

9STX6: The biggest challenge for us, I think, is the time zone alignment between the team and the different languages we all speak. To be sure, that's something that everybody needs to accept if they start contributing worldwide. On the other hand, it's very funny.

The second challenge, I think, is all of the computational complexity of Dark Forest. If you do one thing, you need to verify it. And again, coming back to the plugins, if you develop one bot, and it works well for one round, you never know if the same bot will work for the next round. This is something that a mentor of mine says: if you make a program, you need to also maintain your program.

Cherry Blue: For me, the biggest challenge isn't development, but rather how to promote and shape public perception of blockchain games. From what I know, many people entering Web3 prefer more direct, financially closer applications. As for those in Web2, they simply don't understand what blockchain is; they might have heard of Bitcoin, but see it as distant from their lives. So, a new player might need to understand a lot before they can truly enjoy it. I see this process in three steps. Firstly, understanding Bitcoin. They need to grasp the basics of blockchain, agree with some fundamental philosophical ideas, and have a favorable view of narratives like decentralization based on their values. Secondly, they need to understand Loot, which defines a new paradigm for NFTs. The third step is understanding fully onchain games. Only then can they start thinking, "Wow, Dark Forest is really cool.”

Game Design Philosophy

Cherry Blue: By periodically hosting Dark Forest Ares rounds, we aim to attract more players, allowing more people to understand the charm of fully onchain games.

For the philosophy of our application design, I believe there are three very important aspects.

The first point is that we aim to encourage players to engage in deeper strategic thinking. Rather than simply redeploying the code from the previous Dark Forest, we strive to introduce new game concepts and designs in every community round we host. For example, we've introduced artifacts with different functionalities, creating a dynamic strategic environment for players to explore through their interactions. We've also experimented with different ranking rules to assess their impact on player behavior and psychology. Additionally, we've implemented a Bounty Hunter platform, allowing players to issue bounty missions to other players, with assassin players earning rewards by attacking target planets. There will also be several other features introduced in the upcoming Dark Forest Ares v0.1 Round 3 on Redstone mainnet.

The second point is that we encourage players to create. We engage closely with players on Discord, discussing new ideas and providing timely assistance and advice to players developing new plugins and tools.

The third part  is that we want to build in a communal way. In 2022, the Dark Forest community saw the emergence of many diverse guilds, some of which remain active in various onchain games today. We hope to foster constructive player groups in the community rounds we advance. We will operate and advance our projects in a community-oriented manner, and actively seek feedback from community members in a timely manner.

9STX6: I think that was a great overview of our philosophy. From my point of view, the biggest change and breakthrough for us should be guild wars. It's something everybody wants to see, to fight a big alliance, each other, with diplomacy, with spying, with that kind of stuff.

I think it's something we've been dreaming about for a lot of years. It's been something that is maybe our biggest dream, but yeah, we need to follow our dreams.

The Autonomous Worlds Thesis

Autonomous worlds are digital ecosystems governed by their own set of rules and entities. These worlds, much like physical or conceptual spaces we inhabit, operate under a unique “diegesis” or the set of conditions that define what exists within their boundaries. Examples range from elaborate fictional universes like Lord of the Rings to real-world economic systems like the US dollar. Three core concepts critical to Autonomous Worlds are:

A Blockchain state root. The definition and compression of all diegetic entities, which compose our world’s state.

A Blockchain state transition function. The definition and execution of rules, which govern how we introduce and change diegetic entities.

A Blockchain consensus mechanism. The agreement between a world’s stakeholders that a state transition is valid. This makes everyone a participant and a decision maker.

With these mechanisms, there exists a potential for worlds governed by unambiguous, diegetic boundaries, enforced through state and consensus, and designed to function autonomously. Enforcement does not cannibalize objectivity. “Nobody can unplug Autonomous worlds.”

Usable Infrastructure with ZK

Overhead induced by blockchains largely boils down to performance and cost. In fullstack environments, both users and developers are subject to high, often compounded gas costs and consensus-driven delays. The existing paradigm is often binary between on-chain and off-chain games.

We believe the compromise between these paradigms is verifiable off-chain computations with on-chain state management. In practice, this is made possible by specialized blockchain solutions like ZK, and more specifically ZKML — infrastructure that optimizes for the complex operations required by high quality gaming experiences.

ZK leverages a neat feature of many blockchain implementations (notably the EVM): precompiles. Precompiles are gas-efficient functions encoded into an underlying VM, which enables support for commonly required but highly complex and expensive operations. Examples include the KECCAK256 hash, ECDSA verify, or BN128 pairing precompiles.

There are various working demonstrations of generalized ZK applied to gaming. Dark Forest and ZK Hunt have been pioneers in using the privacy affordances of zero-knowledge proofs to create games with fog-of-war or hidden information mechanics. The verifiability of computation is an under-explored set of tools for on-chain game developers, and we’ve seen an increasing amount of developer and player energy invested in this vision. Beyond generalized ZK gaming applications, we also believe there are emergent designs around strategy and agents facilitated specifically by ML. We explore three principal methods for ZKML game-design that have inklings of popularity with both game designers and players: (1) the model is the game, (2) ZKML as digital physics, and (3) ZKML for narrative and lore.

The Model is the Game

The earliest explorations that we’ve seen in the merger of on-chain games and ZKML are ones where the ZKML model IS the game. Here, players interact directly with the ZKML model, and this interaction constitutes the entirety of the game dynamics. A representative example of this is the cryptoidol game that we developed internally. Here players vie to be canonized as the best singer in an eternally running singing contest. They sing into the browser and generate a proof that they were correctly judged by a public judging model. They can then submit their score and associated proof on-chain to be inserted into a running leaderboard.

ZKML as Digital Physics

We’ve also designed a simple onchain-tictactoe library, where a neural network is trained on tictactoe telemetry data to recognize valid or invalid game patterns, such that games can be played off-chain and then submitted and settled on-chain in their final state. We have two tutorials that showcase how to do this here and here. This pattern, of a neural network encoding the “rules” of the game, bridges into the next design paradigm where ZKML helps create “on-chain physics” for a world. Though the tictactoe model leverages a neural network, this design pattern requires a slight shift in thinking about what ZKML enables. In some sense, when ZKML is focused on neural network “inference” (i.e post training predictions), there is nothing that constrains the computations that are “ZK’ed” to be exclusive to ML.

ZKML for Narrative and Lore

The third pattern, and perhaps the most ambitious, is one where ZKML is leveraged to build a world’s lore and narrative. ML models can be used to create sophisticated agents / NPCs and concurrent storylines that are nuanced elements of a larger whole.

This could for instance be an a language model writing a world’s narrative as the game progresses, or writing storylines for individual NPCs. As a first exploration in this we created our own on-chain NPC (fully fleshed out demo pending), which we call the “worm”. We implemented a generative model, described here, which models the voltage activations (given sensory inputs) of the C. Elegans nervous system. We could generate sensory inputs for the worm using an on-chain game engine such as MUD, and then generate proofs that update the worm’s brain activity given the on-chain sensory environment. Anyone can run these proofs and keep the worm “alive” on-chain, effectively creating an autonomous agent that other games and interfaces can leverage within their own games. Reusable and permisionless NPCs that are shared across games and worlds then become possible 🥳.

The Gaming Stack

Though still in its infancy, on-chain game development, offers game users and designers unprecedented new affordances. We credit various on-chain game development frameworks, particularly those developed by our friends at Lattice and 0xPARC, with lowering the barrier to entry for the creation of autonomous worlds. Recognizing the challenges in traditional smart contract development — such as the coupling of state and logic, and synchrony issues between the chain and client — frameworks like MUD streamline the game development process. Observing the limitations of underlying blockchain implementations — particularly around L1 data fees and data availability — rollups like Redstone (built on an OP stack) serve as game-optimized state.

The missing piece, we believe, is a general purpose compute engine. As we’ve discussed previously, the stack inherits both the security and the computational limitations of the underlying blockchain (whether EVM or any other system). Consequentially, it is important to pre-process heavy compute features (anything from ML agents to strategy models to embedded graphics) in a verifiable manner. This allows for the bundling of compute to pass more succinctly through gaming engines and blockchain layers.

The underlying hardware behind the general purpose compute engine is left to discretion of the user. Via the EZKL backend, it’s possible to use our private cluster (achieving economies of scale from contained jobs) or ZK accelerated hardware. There’s more to come on the hardware integration front. This flexibility implies that the proving engine can run on both clients (WASM for example) and servers — and both systems are capable of deploying a verifier to the blockchain stack.

We’ve designed EZKL with this vision in mind, and believe these simple ZKML libraries may neatly complement MUD, Redstone, and beyond — a gaming stack that materializes innovative dynamics with performant infrastructure and supports brilliant autonomous worlds.

To learn more about Lattice and MUD, visit our website, read our documentation, or join our Discord server

For reasons that will soon become clear to you, at Lattice we’ve been discussing the well-known Alan Kay quote: “People who are really serious about software should make their own hardware.”

The quote, which has gained notoriety (to the point of being self-evident) in the post-iOS, Tesla, Bitcoin ASICs, NVIDIA AI GPU, era we live in, has origins that are actually quite difficult to trace. After some searching, I found this blogpost from early Apple employee Andy Hertzfeld, with notes on a talk Alan Kay delivered at the 1982 Creative Think conference. From what I can tell, there are no records of the full talk, but the quote is in Hertzfeld’s notes, along with other well-known Alan Kay quips like “the best way to predict the future is to invent it” and lesser-known ones like “the whole notion of 'programming language' is wrong.”

Back to the original quote: “People who are really serious about software should make their own hardware.” What would make Kay assert this, in 1982 — two years before MacOS was released, and decades before companies like Tesla and NVIDIA were founded? There were no clear winners in software or hardware at the time: personal computing was still a dream held only by the most ardent technologists, and computing itself was largely relegated to mainframes. It’s worth looking at what Kay was building around the same time that he made this observation — and what might have informed this now-famous claim.

In the years leading up to (and following) his Creative Think talk, Kay worked on the “Dynabook”, a proto-laptop that never quite made its way into production. The Dynabook was meant to be “a personal computer for children of all ages” — a tool to make the power of the PC accessible to anyone. It was the first piece of hardware to run Smalltalk, a programming language and IDE whose object-oriented programming paradigm was a break from the imperative styles that were more popular at the time. In the words of Kay, Smalltalk was “more more powerful and easier to use for the naive programmer than the more conventional ‘noun/verb structure/function’ primitive ideas of most current programming systems.”

These were not empty words. In the 1970’s, Kay and other researchers at his Xerox PARC Lab developed the “Interim Dynabook” — a larger and less portable version of the original Dynabook design. They gave children access to the computer, and found that in very little time, kids as young as 5 were able to make drawing games, flight simulators, and a space war game. The IDE provided by Smalltalk had a native GUI to render simulations, and the Dynabook hardware itself had user-friendly attributes like a mouse (which was less popular on hardware at the time that only permitted interaction via CLI). This new combination of hardware (the Interim Dynabook) and software (Smalltalk) had enabled new applications, which would have been unfeasible to create in more challenging programming environments.

Anyone who interacted with the Interim Dynabook was temporarily living in the future: the user-centric combination of hardware and software embodied by the Dynabook went on to influence laptops, the iPhone and iPad, and other modern technology. The big lesson from the Dynabook is that when you combine hardware and software that are uniquely tailor-made for one another, you can unlock breakthroughs that are decades ahead of their time.

But how does this apply to the EVM, onchain applications, or anything we’re doing at Lattice?

Some people might think of blockchain “hardware” as the physical nodes that runs consensus or execution clients, or even hardware to accelerate advanced cryptography found in zero-knowledge proofs. Our angle is slightly different: blockchains — which are computers — are hardware themselves.

For almost two years, Lattice has been building MUD, an engine to make developing ambitious applications (or “software”) on the EVM easier and more intuitive. Like the people lucky enough to use the Interim Dynabook in the 1970’s, we have been finding ways to live in the future: an era when onchain applications aren’t constrained by the hardware on which they run.

While it took several decades for the Dynabook prototype to lead to technology like the iPhone, the feedback loops between design, iteration, user-testing, and implementation are fortunately much shorter today. In less than two years, MUD has evolved from an in-house engine born from our personal struggles building onchain games, to open-source software powering games like Sky Strife, OPCraft, Words3, Primodium, draw.tech, Gaul, THIS CURSED MACHINE, and many more applications. Along the way, we’ve played with the hardware running some of these applications: we’ve deployed local nodes with gas limits of up to 1 billion, launched OP Craft last year on the one of the first Optimism Bedrock testnets, and run a custom testnet used by Sky Strife, Primodium, Small Brain Games, and other MUD builders.

For Season Two of The New World, we will be exploring Hardware. Over the past two years, we’ve gone from playing with hardware, to developing strong opinions informed by serious experimentation around what ideal hardware for autonomous worlds might look like. Now, it’s time to share our findings, and hear from you about your own. Let’s all live in the future.

If this sounds interesting to you, stay tuned and subscribe to our Mirror. If you’d like to contribute, email me at vera@lattice.xyz – we’ll be accepting submissions from developers and researchers who are interested in these questions. To get you started, we’ve brainstormed a list of words and concepts that might be helpful as you explore.

Hardware: ZKML Games, Ethereum Infrastructure Costs Are a Lie, Human-Machine Interaction, Everything is an Interface, Indexing Costs Are a Lie, Your Favorite Abandonware, WE NEED MORE OPCODES, Parallelizing the EVM (with Hardware, not Digital Physics), ZK Coprocessors, Scaling in All Directions, ethOS, Alignment Is a Lie (or is it?), MUD-Native Block Explorers

To learn more about Lattice and MUD, visit our website, read our documentation, or join our Discord server

Autonomy & Automation

You need to be world maxxing. You need to be automating your autonomy. Developing emergence. Creating emergencies. NPCs. AI. You need to be mocking those with the sight of what they might have known. You need to build a big bonfire, each player a hot coal.

At the altar of autonomy, the crystal sword plunges towards a sacrifice, then—stops. Quivering, the dagger suspended millimeters above. Cut to black. It is you, waking up in your bed, you have been working on a game for two decades. It will be released tomorrow. There was no stone temple, dagger, or victim. The autonomous altar was inside of a dream, inside the dream of automation. Autonomy and automation.

“[Playing a game is] the voluntary attempt to overcome unnecessary obstacles"

-Bernard Suits, The Grasshopper

BUT

Children recognize early on that play is an opportunity for pure enjoyment, whereas games may involve considerable stress.

-Bruno Bettelheim, March 1987 Issue of The Atlantic

THEN

"As a prefix, auto- not only means ‘self’ as individual and independent, but it describes directives, decisions, and motives, by way of reason and power, as emerging from within."

-Stephanie Sherman, The Autocene

Fortnite and Roblox are two game stacks that are automating their players (by having their players create games within a game). This is good, inasmuch as games were always devices that turn its players into automatons. But what kind of automation? The mind conjures the negative definition, an image of players as humdrum factory workers, dolefully grinding away in their worlds, continuously fed a drip. Sadly we concede this is partially the case. However, the positive definition would see players have productively traded away some of their autonomy into the rules, a playful automation. And, rather than feel constricted by rules, players are then instead free to act out a previously unattainable autonomy.

Autonomy and automation are in a productive tension, neither one good nor bad, one not desirable over the other. Players are always delegating, trading, deferring,  discovering, and rediscovering their autonomous selves inside automation. Consider that, through marketing, a game might lure prospective players by promising them the utmost freedom to do as they wish in the game world. And furthermore, that their choices will have consequences. The paradox being that they are only free to do what the designer has designed for them. This is of course, not the tyranny of games, but the beauty of games.

AND SO

To agree to the rules of a game is to agree to become a playful automaton, and in exchange, to be led into a new experience of yourself, of your autonomy. Players of games accept the contradiction that they are free to be, or do, anything inside the game—but only as long as they are in accordance with it. A high level player might be said to be machine-like, but, the best players are in a class-of-their-own. They might have a signature movement or style, new elements of their autonomy discovered through their automation. The game is a mechanism for self-discovery through self-mastery.

AUTOMATION & AUTONOMY

Autonomy, the inalienable parts of the self, but also, the internal rules the self creates and follows. Automation, the productive force that occurs when deferring internal rules to external rules. Your game releases in an hour, you wait for your players. For two decades you have worked on a device, a technology designed to let your players do lots of things, but also not do certain things. Soon, by automating their self, they will be able to explore themself. The crystal dagger plunges into your chest. You relax.

Part 2

“If the ideologues of contemporary society actually exist somewhere, we may imagine them laughing gleefully, while donning their goofy teenage caps and logging into their Animal Crossing account on the way to a board meeting.”

-Federico Campagna, A Room With a Door

Reframing the definition of video games as a productive exchange between autonomy and automation is helpful for a few reasons. First, because the cultural experience of video games feels to have outsized “the voluntary attempt to overcome unnecessary obstacles”. So it is time to reach for a larger definition. But, what happens next is usually an attempt to elevate the video game to the status of real life, something that is always unsatisfying. Mostly because we will never know what is meant by real or life. To make the point from the opposite direction, the dullest observation one can make is that markets, politics, love, and liberty are games—in actuality it is through the language of play that we arrive at that thought. We start to see the world through the lens of games. That is why we cannot implode so-called real life into games, they are a media about how to live.

“I reject the notion of football as warfare. Warfare is warfare. We don’t need substitutes because we’ve got the real thing”

-Don DeLillo, End Zone

What automation and autonomy lets us talk about is the experience of playing games, or rather, the feeling that we ourselves are the ones being played. Some days in life we are the NPC, and others, the main character. And, inside the worlds, billions of players amass inside massive virtual geometries. Impressive virtually and spatially, but also a vast temporal dimension of ever evolving narrative and content. The game marks itself on our calendars and things get confusing. After millions of combined years playing games, the crowd asks in unison “I am spending so much time here, don’t I have any control over this?”. The player traded their autonomy at the door when they entered, but now they want it back, are they asking to be let out of the game? No, they want a new one.

Autonomous Worlds

The new game is the autonomous world, the concept this essay responds to. An innovative piece of media that could encode within itself the conditions through which it exists and extends itself. It is, at its heart, a computational project to redirect automated players back onto their worlds. This is borne by asking designers to embrace worlds that are permissionless and composable, worlds in which players would put down the controller and turn designer. To cut off the head of the snake so that ten heads can grow back in its place. If playing a RollerCoaster Tycoon game is to automate yourself into an amusement park planner, then an autonomous RollerCoaster Tycoon is the automation of simulators for amusement park planners.To flywheel the flywheel.

"Civilization advances by extending the number of operations we can perform without thinking about them.”

-Alfred North Whitehead

Back to Fortnite and Roblox. Players are becoming designers, creating new rules for the game, automating new players, creating new autonomies—a process of positive feedback. Can this perpetual motion machine of the player-designer exist? Yes, with the support of massive live operations teams continually injecting novelty into the world. But, how do designers make themselves obsolete to the autonomous world? There are games in which players play at design while still remaining firmly inside the game, RollerCoaster Tycoon and Fortnite are somewhat like this. That is ok. However, when a player is fully able to change the rules of a game, they are no longer inside it. That is also ok. To truly make players into designers is to upend the game entirely.

“Making a game combines everything that’s hard about building a bridge with everything that’s hard about composing an opera. Games are basically operas made out of bridges.”

-Frank Lantz, The Beauty of Games

Video games are a departure point for autonomous worlds, not the destination. Imagine for a second, a new medium that succeeds the video game. What qualities might it have? A protocol for the creation of rules and diegesis↱. Different vehicles for storytelling and world creation↱ that trade ordered plots for horizontal wikis. Character and environment creation with natural language. A device or piece of hardware like the GPU, but for facilitating a different facet than graphics, accelerating some different interface. Authorial seeds encoded into the piece of the media itself, that maximize sharing and extending, or secrets↱. Experiences that productively play with the autonomy and automation of its participants. To be constantly delegating between NPCdom and playerhood. A medium that encapsulates how we play with worlds, and how worlds play with us.

Neilson is a designer currently developing a new game at @engine_study.

Thank you to Nicole and Vera for helping develop this essay. The piece originated from many discussions inside the Autonomous Worlds community—I would like to especially thank ARB, GVN, Lermchair, 0xHank, and Small Brain Games.

For this installment of Devs on Devs, we sat down with alvarius, one of the core developers of MUD, and Dhvani, an engineer on the Tenet team. Tenet is developing an onchain multiplayer simulation environment, loosely based off of OPCraft, which alvarius and other members of the Lattice team released last year. This conversation took place this past summer, when Tenet was experimenting with a multiscale, multiphysics simulator. While the concept has evolved since this conversation was recorded, the ideas around motivations for building an onchain simulation, and anecdotes around the early development of MUD still give deep insights into what will become possible to build onchain.

Early Beginnings

ALVARIUS: Did you do any Blockchain development before this or was this your first onchain project?

DHVANI: This was the first one.

ALVARIUS: So you learned Solidity with the MUD patterns?

DHVANI: Exactly. We've never stored state in the contract. That's not normal to us. Like, we need a Store and table, because we never used the patterns where you store state in a contract.

ALVARIUS: That's cool. How did you get into programming in the first place?

DHVANI: I started programming, quite early in grade seven or eight using Codecademy. It's a place to learn to code. From there, I was like, “damn, I feel like a wizard. I can do this stuff.” And then, high school was when I really formalized it. I took AP Computer Science, and then I started in Java and then, by grade twelve, I knew I wanted to get a degree that would be coding related, either Computer Science or Engineering. And then ended up picking Engineering.

ALVARIUS: For me, it was later, maybe age 14 or 15. I started with web development, actually. So the reason is a fun side story. I had a crush on a girl. She had her own blog and was doing web design with HTML and CSS. And essentially to impress her I also did web design. And then she ended up with one of my good friends at the time who was a better web designer than me. So that must have been the reason.

DHVANI: How did you get into onchain stuff?

ALVARIUS: That was a long journey. Through very simple app development, this world of programming opened up to me, and then I had a very similar journey as as you just explained, with this feeling of, “well, this is actually the closest thing we have to a superpower.” It does feel kind of like wizardry in a sense. That fascinated me a lot. During high school, I did a bunch of random side projects with friends. We just came up with some random idea, and we just were able to implement it. It was still very web app-focused. The main reason I like the web is because you can build something and then it runs on any device. You can just have this large reach.

Infinite Reach

DHVANI: Infinite distribution, but, the cost of distribution is almost zero.

ALVARIUS: Exactly. I started studying computer science, and then I started a job as a web developer at a big tech company. I worked there for a year approximately and then decided to go back to university to do a Master's, which is free in Germany. So the main reason I went back to school was because I just didn't wanna go into a corporate job. At that point, I wanted to explore more. I was studying a little bit on the side, but mostly just exploring. And then one of the things that I ended up exploring was ZK Dungeon with ludens. That just was very fascinating to me, and it got me into crypto.

DHVANI: And were you also the game designer?

ALVARIUS: I'm way less of a gamer or game designer. The only two games that I actively played were Minecraft and Battlefield 3. When we were building that first game, the most fascinating thing for me was solving all of those lower level technical problems because it felt like I could basically finally flex my algorithms skills. In web development, you don't really get to do that. So that low level technical stuff was exciting for me, which is then what became MUD basically. The games that I’ve found most interesting are less games and more low level primitives that other people can do stuff with, like Minecraft.

DHVANI: Minecraft is a game engine and a game.

ALVARIUS: I think what I find most interesting is basically emergence. In OPCraft, the little primitives were super simple, the most basic it can get basically. What I've found most exciting was the whole thing that happened on top of it, like the Supreme Leader.

DHVANI: And emergence seems native to this technology.

Why We Need the EVM

ALVARIUS: I fully agree. That's the main reason why I find, onchain games and onchain apps exciting. It's this world computer where people can just deploy stuff. People keep asking me why are you building onchain games? Why do you use the blockchain for this? And then if you think about it from first principles, what we actually want to do is build this game or this reality where you have some base physics primitives and then people can interact with them and build stuff on top so we can have emergence. If you want to do that then it needs to run somewhere. So you could put it on the server, but then if you want people to extend it, then you need some kind of environment where people can deploy additional logic to your server. Then you have all these problems with things like permissioning. How do you make sure that the stuff people deploy doesn't write to other areas where they're not supposed to write? And then you have other questions. How do you make sure that there's some form of spam protection? How's the ordering happening? And after solving all those issues you end up with something that's probably very close to a blockchain.

DHVANI: You could just put the EVM on a server. But if somebody owns the server, there's a bound on the people who will participate. And so I think it needs to be neutral. It has to be neutral if you want unbounded participation in the world, and for serious things.

ALVARIUS: Totally agree. Actually, it feels way different when it runs on this neutral distributed network that will be there hopefully forever or at least for a very long time.

DHVANI: I just really like MUD as well because we've had Ethereum for a while. Already have this thing where anyone can deploy anything and anyone can call other contracts. But then if you start adding abstraction on top of it, You add structure that makes it easy for people to write to it.

ALVARIUS: And I mean it's always funny when people ask “what is possible with MUD that wasn't possible before?” MUD is built on the primitives that existed. Everything was possible, but it's just way too low level. And there's way too little abstractions to actually enable scaling.

DHVANI: With normal programming, we aren’t going to write in Assembly. If it's a program where you're thinking about storage slots, you're not gonna be thinking about your app then.

Physics Simulators

ALVARIUS: And it's great to see the first generation of native MUD development. What are you doing right now?

DHVANI: Tenet is working on this multiscale, multi-physics simulator that anyone can write to and read from. So that’s a lot of words. I’m gonna break it down a bit to give more context. Multiscale: this means that you can have different scales of zooming in and zooming out. Think of the Powers of 10 video, where you start in Chicago and then zoom out to the solar system and then zoom in on a cellular level. In the case of Tenet, you can have electrons on a low level, or you can have something higher up, like circuits, and even higher up, like a machine. Multi-physics just means you can have different properties of physics in the simulation. If you have one set of physics that deals with heat, I can add a different set of physics that deals with fluids and then they both can interact with each other.

What's the point of having a simulator? To speed up the evolution of ideas by letting you figure things out in a virtual world before trying them in the real one. Today on Ethereum, you can really only simulate money. We want to make it possible to simulate anything. And the difference from traditional simulations is that if you create something, you'll know it can be used anywhere. It has the same interface, and we have privacy. So you can have true secrets around inventions, basically.

ALVARIUS: How would you do that? Would it involve ZK?

DHVANI: I think you need ZK for the privacy, because I'm not sure how else you get verifiable computation that's also secret. So you have to use ZK or you might need multi-party computation if you wanna have interesting creations, where if you make something and I make something, we can combine it together.

ALVARIUS: It's very interesting what you said about how we only have the smallest possible programs, basically financial applications. Because it seems like ludens and I started with a similar angle. One of our first principles was to just ignore gas costs. We created a local chain with a one hundred-million gas limit. Which back then was insane because it was way more than any production chain. And removing that limit freed our minds from thinking in those limited terms.

DHVANI: And you also don't get skeuomorphic ideas. Because you'll think of ideas that aren't possible now. That's really cool.

ALVARIUS: Multiscale is the thing I want to ask about. Very interesting. So you zoom in and on the lowest level, it's basically electrons. What can you do on the low level? And then when you zoom out, how is it using the lower level?

DHVANI: Well, if you don't want people to break stuff, what we can have is different scales vertically and and then different scales horizontally. So with the scales, at the electron level, you can define your own behavior at the very bottom of what the electron should do. When you increase the scale, what it means is that you're not defining a new voxel. When you inherit that voxel, it's your child voxel, and now you inherit all of its behavior. And now as a parent, you can make your own behavior, by reading your child voxel, but also by defining your own behavior on how you should move or how you should change types. There are different implementations, but they have a common interface in the sense that (at least in our current design) everything is structured as a cellular automata.

Just to give a quick background, cellular automata have these simple rules around how different grids should respond to each other. You might have heard of Conway’s Game of Life. The ones above are made up of the ones below. So you can read any component or table value on the ones below.

ALVARIUS: So are these electrons the lowest level you can go in in your current version?

DHVANI: We picked electrons because in reality, the lowest level is electrons, roughly speaking.

Defining Rules and Objectives

ALVARIUS: Do I change how an electron works to get different kinds of behavior in the simulation? Or do I just arrange these electrons that are those building blocks basically in different ways and then that changes things?

DHVANI: So if you're not adding new physics and you're just using existing physics, you just need to place electrons down. They would just move based on however the physics are defined. But if you're actually coding the physics, or adding the physics, then you're defining two things. One is, what types am I dealing with? And then defining, every time an event happens, given the current state, what should the new state be?

ALVARIUS: So basically, when you define the physics, you define rules of this cellular automata?

DHVANI: Exactly. And it is stored as a grid with a position table and a type table. And that would tell the client where everything is.

ALVARIUS: In your client, you have a certain number of scales that you can display?

DHVANI: There's no limit on the scales. So if you're at the electrons, you wouldn't be placing 32 by 32 blocks, but something smaller. And if you're at the city level, you're not just in blocks for cities, you just place down cities. And so the client could be improved, but right now, it's just, like, the same grid for all of them and so there's no limit on the number of scales.

ALVARIUS: What's your what's your plan with this?

DHVANI: It's almost been this evolution. We were working on different ideas and then evolved into this one. We want to figure out some sort of content because it's an open world and so it's also a creative world. So what's the incentive to create stuff? We'll need some objective, and we'll test out different ones because in the same sims, we can test out different content and objectives quickly. The second thing is we need this to run on the world computer, some sort of chain. Right now it runs on our anvil node. We also customized gas up to a billion. So we do need to solve that. Those are the things that will be the next area of focus: content and scaling.

ALVARIUS: Do you have ideas for objectives?

DHVANI: With objectives, it seems like we can either go with mini games or an interesting survival world, where there's some sort of limit. You don't have a player position, because if we try to take their position, it gets janky. And so you have to be creative. So we have this one idea of stamina, which solves the problem of not having player position, and creates a form of limit.

ALVARIUS: Yeah. Enforcing position on chain is also something we thought about with an OPCraft back then. Because it was just intended as a simple tech demo, we just decided to not have it at all. Of course, that basically immediately broke the game in the sense that people figured out that they can just mine the diamonds. They knew the exact positions of diamonds because diamond positions were deterministic. It broke the game in some sense, but it also created some interesting dynamics, like the Supreme Leader.

DHVANI: It had all these properties of social emergence. I was talking to GVN yesterday, and he liked the idea of breaking things. Why don't we just take that as a hardcore narrative of the game: things can be broken. The players have the agency to say, “okay let's change the world to a different world.” If a certain scale breaks the game for a certain block, you make it easy for players to fork, and give them the tools to fix it.

To learn more about Lattice and MUD, visit our website, read our documentation, or join our Discord server

For our next installment of Devs on Devs, we spoke to the Primodium team about their adventures building onchain games — and the wisdom they picked up from the hackathons, personal projects, and startups they worked on beforehand.

Emerson and Morris are brothers who started out building web2 projects from mobile games to social apps. After selling their first company (a YC-backed LLM company focused on predictive maintenance in the rail industry called Palifer) in 2022, the brothers turned their attention to web3 gaming. Their first gambit, Critterz, was a play-to-earn Minecraft server. Emerson and Morris were one of the first teams to introduce NFTs to Minecraft, but after Microsoft clamped down on crypto, they decided to venture into the fully onchain gaming space. They founded Primodium in late 2022.

0xHank took a different route into crypto. After graduating from college and eschewing the traditional FAANG path, he joined his friends at ETHDenver in 2022, where he quickly joined a Dark Forest guild. There, he enjoyed a trial-by-fire immersion into onchain gaming and began launching small projects built on MUD, like Dark Seas. Earlier this summer, he officially joined the Primodium team.

Trodden Terrain vs The Frontier

MORRIS: Emerson and I began our careers building your typical B2B SaaS startup in web2. One of the biggest lessons that we learned is that if you want to build a product that people will end up using, the market in general is so efficient that low-hanging fruits are already taken. The only spaces where startups could thrive are those where there's a new piece of technology that solves an existing problem or builds something that couldn't have been built before, or if there was some sort of social change that induced new problems. However, that was not a train we immediately jumped on.

A couple of years of building enterprise software led us to realize that big companies are pretty competent at solving problems and buying solutions, contrary to common perceptions of organizational inertia. Crypto to us was a new platform shift that we wanted to explore, so when we sold our previous company, we created Critterz. We were first inspired by Nouns DAO, which pioneered the model where if you gave everybody within your community a token, then basically you’re giving everybody equity. When community members own equity, everybody will work together in some unified way to evangelize the product.

That was the idea behind Critterz, which was centered around a Minecraft server. We gave out tokens for free to players who were building on and contributing to our Minecraft server. There, they can spend tokens on pieces of land so they can own the server that they're a part of, resulting in a much more beautiful world that everybody's trying to craft together.

While the project was successful in generating revenue from royalties and garnering attention, the initial hypothesis that we wanted to test did not come about. Players only cared about earning $200 worth of ERC20s after playing Minecraft for three hours and play-to-earn became the entire discourse for Critterz. A couple of months later, Microsoft took action for all NFTs and crypto projects built on top of Minecraft.

After Critterz, we chatted with engineers working with fully onchain games who seemed to understand pieces of what I mentioned earlier about a new technology that solves problems that were previously unsolvable, thereby having room for startups. That was something that fit our previous thesis about running companies, so we found the onchain gaming space to be a field worth digging more into.

Our views on exactly what fully onchain gaming enables have changed over time. Many of us start with composability as an enabler for a type of gameplay that is much more different from web2 games. However, we've come to slowly realize that players don't want to write scripts and add new features just so that they can unlock a certain part of the game for themselves. While there's more to it, this is a preamble to how we got into fully onchain games in the first place and building Primodium.

0xHANK: My story has a lot of similarities. I was at a place where I just graduated with a technical degree and I was like, “Alright, I can either go down the path of FAANG or corporate software.” It all felt stale to me because everything was very entrenched and there wasn't a lot of excitement going on with what my friends were working on.

I randomly stumbled into Dark Forest which segued me into onchain gaming. What I like about blockchain gaming is that, as Morris said, it's a new, relatively unexplored space outside of pure finance that could shape the perception of what a decentralized app can be. We are entering an inflection point where people are starting to think harder about what a blockchain is, how we can modify blockchains, and how we can make them useful for more complicated, interesting, and diverse applications.

Apps and gaming are generally frontier spaces for exploration, which is one of the reasons I've enjoyed them. I think that's why there's such a strong community in autonomous worlds and onchain gaming. I don't know how you guys feel about this: the whole community just feels like frontiersmen exploring and researching.

EMERSON: I can relate to Hank. I learned to code back in 2011 by making iPhone games with various scripting languages at the time. This was before Swift, when the App Store was only a few years old and there was a variety of indie games and experiments out there for iOS users to download and play.

I was active in a specific period when there were new sets of APIs for both the touch screen and accelerometer that made me want to try and see what was possible. I also participated in various developer forums that are no longer available because of shifts in the mobile app market.

In a new field, if you come up with an idea, chances are no one would have ever thought of it before. I published several top-ranked games on the App Stores of many countries because I was consistently putting my games and creations out there, which led to my career of building startups. At the end of my first company with Morris, we stumbled upon crypto because of…

MORRIS: Boffee?

EMERSON: Yes. We had a very smart friend named Boffee who introduced Morris and me to crypto, trading, and NFT projects. This was in 2021 when we saw demand for new types of projects that were coming out, specifically with new types of NFT applications.

MORRIS: I want to give an aside to Boffee. Boffee is a true maverick type of founder who always wants to explore the most novel things possible.

EMERSON: At the time, prevailing NFTs were community-based collections whose contents were links to external images. Others experimented with onchain NFTs, including Nouns and Anonymice, whose token artworks were natively stored and referenced. We wanted to create our own onchain NFT that recorded all aspects of the token content directly onto smart contracts.

On top of Morris' idea of tokenizing Minecraft, Boffee and I encoded Minecraft skins natively onchain. We had to invent a new tech stack with custom plugins on our Minecraft server to log player activity. We also had a separate Node and Postgres backend for caching onchain trading history from Layer 1 Ethereum. Then, we created a website for players to claim tokens and trade in-game items.

Besides having to learn the community-supported Java APIs for Minecraft and the rest of the stack, this was my first time learning Solidity. I was excited because this experience reminded me of when I learned how to program for the first time by making iPhone games.

Being in an entirely new field and experimenting with what's possible in the frontier of gaming intrigues me because I get to see what kind of potential technology can be unlocked. We learned about emergent behavior that came about from Critterz, and now we're taking those learnings forward to build an onchain game that we would be proud of as a team.

Plugins For Dark Forest

0xHANK: I got into Dark Forest pretty late in its life cycle. At ETHDenver, I showed up and participated in the last round. I got invited on the back of my friend Cha0sG0d having done work with dfdao and knowing Gubsheep and Ivan. They told me, “We're hacking Dark Forest and a bunch of 0xPARC people are here. You should fly out, experience it, and get introduced to everybody.”

For the first half of the round, we watched the devs build — no life — for two straight days. Then we didn't leave our hotel room for the last three days of ETHDenver. We were trying to understand the new rules of the round and what our competitive advantage would be. There was another gaming guild that had won all the previous rounds and we wanted to beat them for the first time. We got a guild together of ten coders and hackers from the Ethereum community. We also recruited a couple of gamers who piloted our empire. It felt like a large-scale battle that we were waging with these guys across the world in the context of this smaller map.

The feeling that I remember is seeing everybody building their empires in a shared space and having neighbors who were up to something. Like, “Oh, this neighbor is getting powerful, we need to watch out for them. They might try to steal some of our planets.” When we needed to retain our power and move across the map, we also annihilated a bunch of smaller empires. We were like, “Sorry guys, we have to do this. Our bad.” We took the blockchain and turned it on its head. Now the blockchain feels like a platform for really exciting interactions.

It’s a feeling that we want to evoke in Primodium as well. We want to have stimulating interactions by having a vibrant economy in a shared world alongside a vibrant combat structure. That’s something I'm very excited to explore.

MORRIS: When you were trying to build on Dark Forest, did you primarily do it out of a desire to win?

0xHANK: Yeah, it was fully out of a desire to win.

MORRIS: Like that motivates you to just go fully “no life” and code?

0xHANK: Here, I can give you an example. In the last round, Dark Forest introduced a mechanic called capture zones. Every couple of hours, a new capture zone would randomly appear on the map. If you captured the planets in that capture zone within 20 minutes, you would get points for every planet you captured.

MORRIS: Within the capture zone?

0xHANK: Yeah. What players would do is they would see a capture zone appear and immediately start moving all their troops to capture the planets. Alright, we could do that. Or, we could write a plugin that queries all planets in the capture zone, calculates exactly how much energy it would require to capture those planets, and then sends all the energy in a microsecond to all the planets and captures all of them instantly.

But then, we realized we couldn’t do so because there's a limit to the number of total planets your empire could control due to the space junk mechanic. We were running out of planets that we could capture, so now we needed to write a plugin that automatically looks at all of our planets and automatically ejects them from our empire.

We got into this progression of needing a plugin, which needed another plugin, which needed another plugin. We ended up running nine or ten plugins and thousands of transactions to pull this off. We probably spent a few hundred dollars in gas fees just to keep everything going.

EMERSON: Did you end up winning?

0xHANK: Yeah, we ended up winning. I wrote this whole blog post about it that you should read because it was a funny story. What you guys have talked about is that no one cares about composability until they care about the game itself. I think that's true — what made composability work in Dark Forest was the fact that automation became a necessity to win. The first plugins that were written weren't even intentional. It was just some hackers who realized that they could win a round if they stole the client and made it better for themselves, as an emergent property of the game design.

We’re going to see behavior like that in Primodium where players are going to realize, “Alright, I could set up all these mines and upgrade them or I could just write a script that will do it for me.”

Adding Complexity to Primodium

MORRIS: That’s a behavior we're thinking about quite often for Primodium. At some point, if automation is the only way to win, then normal players who aren't otherwise able to do so would be discouraged from playing because they know they can't win unless they know how to write in Solidity.

In web3 games, there is some criticism that all games will be botted to hell. I don't think bots are nearly as big a concern — while it's not going to kill the industry, it’s a concern that we need to be pretty cognizant of within the game design. There are different ways of fighting bots such as adding a stake for a player to join the game in the first place or VRGDAs.

If you’re so confident in the bots that you make that you want to leave the chances of your stakes to them, then all the more power to you. In that case, as game designers, we have to make the game complex enough such that writing an automated script isn't all that’s required to win.

0xHANK: You want every decision to be complex so that the order of committing transactions requires a certain degree of thinking. For example, you don’t want a gameplay loop where you have some amount of iron being mined in a game, and whenever you have a thousand iron, you’re always going to claim it. Good onchain game design requires players to understand the complex interactions that are occurring to make difficult decisions.

MORRIS: Currently, Primodium’s game loop is designed such that you start by building a main base, then miners, then factories that you connect to miners so you can get more complex resources, after which you can unlock more factories. It's very similar to the game loop of Factorio.

What makes Factorio fun is solving the puzzle of making the most efficient factory in a small space. That only requires cheap compute on a normal computer, but it is very expensive onchain, so unfortunately we can't replicate exactly that. In our efforts to find a different sort of objective for players, our game was deliberately built with a multiplayer game loop in mind, considering that onchain games are also already fundamentally multiplayer.

EMERSON: When we wrote the initial set of contracts with MUD, everything was already multiplayer.

MORRIS: Which is awesome! That's different from Factorio, which doesn’t primarily leverage multiplayer sessions.

The fact that we have onchain design constraints led us to think about different ways for our players to have an objective. We’re also experimenting with other game loops. In our next update, instead of everybody playing within the same world map, players own their little asteroid on which they can build their factories, and if they want rarer resources, then they need to go beyond the initial canvas that they have.

Beyond a player’s initial asteroid, we’ll spawn motherlodes that contain different types of resources. Players have to send units and miners to capture a motherload, and if one contains a particularly desired resource, then someone else could do it too, which is where combat starts to happen. We were also inspired by Dark Forest mechanics, which is an interesting convergence of ideas.

0xHANK: There was always a dream for Dark Forest players to have something to do on the planets they captured, and I think our newest update is a great fit for that. For Primodium, you’ll have a planet, and you could go in and extract the resources of the planet to build your empire. In Dark Forest, it was just a ticker, where energy increases by so much every second.

MORRIS: From this, we have a gameplay loop where the objectives are primarily created from other players' interaction with Primodium. Instead of thinking, “I want to get my factory to a certain level,” the player’s concern becomes, “Some guy is trying to attack me, and I gotta do something about it right now.”

0xHANK: It’s going to involve tough decision-making. For smaller onchain games, the decision space is clear with a well-defined magic equilibrium. What we’re thinking about is how we can make a decision space with large degrees of freedom, especially considering that you can’t have hidden information onchain, until at least Lyron [a developer at the Lattice Autonomous Worlds week] builds a complete framework with circuits and ZK magic.

Hypothetical Technology and Real Users

MORRIS: At some point in our game design, we questioned whether complex onchain game loops are only possible until we have a higher degree of hidden information. And the answer is no. This segues into a point that I want to make.

There are quite a few teams in the space today that are trying to build onchain games with hypothetical technology. What I mean is that when a typical builder tries to build a full-fledged game and sees the limitations of the blockchain, they assume that in a couple of years, those limitations would not be a problem anymore and go in directions that aren’t productive to shipping products. What we want is to get our product into the hands of users right now, which means that we can't afford to work on tech that doesn’t currently exist or tech that we assume will exist in the future.

This came about when I was chatting with another gaming founder pretty recently who asked why Primodium is only on a web browser and not natively mobile like other games. The reason is that today’s crypto users are signing their transactions on Metamask in the browser. After that, the question became, “Well why not custody their assets for them by introducing email sign-in on mobile?” At some point, you end up shifting back towards a web2 game, which means that you’ll be competing for player attention from existing games, which erodes the market of crypto-native users that onchain developers and studios should be capturing.

0xHANK: Yeah.

MORRIS: It’s painfully clear to me that we need to build Primodium as a web game because that's where people's wallets are. We can't custody our players’ assets, because there would be regulatory concerns if we did so. Going back, we're designing a game specifically based on crypto constraints today rather than just ignoring them and hoping some future bit of technology will come by.

0xHANK: There's something to be said for builders on the frontline of shipping products who make clear to infrastructure people what needs to be built. In my experience, others in onchain gaming have a preconceived vision of how a piece of software is going to behave; therefore, building out that vision is what they want to focus on. The space that Primodium fills instead is having a goal of shipping a production-level piece of software and fixing problems that come up along the way to achieve our goal.

MORRIS: There's also the common meme of saying that there’s too much infrastructure and not enough apps at all. Although the people saying it feel like they're being contrarian, I think it's pretty mainstream to be saying that these days.

EMERSON: That's what we tried to do with our previous companies as well, which is to invent entire technology stacks based on known constraints and to build products that implement the newest ideas we could find.

MORRIS: Our philosophy for designing products is to relentlessly prioritize getting prototypes into the hands of users and getting them to truly enjoy themselves for the product rather than satisfying intellectual needs.

There’s this question that Peter Thiel asks: Is the future determinate or indeterminate? The indeterminate future is one that founders around us are taught to believe. At the beginning of our careers as startup founders, we were taught to do things that don't scale, launch quickly, and get prototypes in front of an audience. Then, they will tell you what they like and you'll slowly figure out exactly what your product is and where it fits in the market.

What we're doing is launching features and seeing what retains users, which is a tried-and-true method. We do have a very specific vision of where the game is going, but I don’t think about it as much as planning out concrete features and gameplay loops that we can experiment with since there are still a lot of unanswered questions about how onchain games should look.

EMERSON: Our first company went through Y Combinator in 2019, where we built predictive maintenance software powered by transformer models for rail and heavy industry operators. Compared to the large language models of today, back then our system used smaller transformer models to parse historical maintenance records and to predict which components break over time, which we later exited to one of our commercial partners.

When we were doing enterprise sales and building features, we learned about the tried-and-true methods of putting our product out there and iterating based on user retention, as Morris mentioned. On top of the lessons we learned from Critterz, we’re applying our past experiences to build Primodium in a way such that we’re at the forefront of building onchain games. We're excited to see that happen.

Making an Early Impact

MORRIS: You read a bunch of articles about startups as a teenager, so what advice would you give your past self?

EMERSON: My advice to kids who want to make an impact on the world is to find ways to contribute to fields that interest them. My earliest open-source experience was with the Ubuntu Linux open-source project back in 2012. I didn't know a single line of C or anything about the Linux kernel, but I just wanted to give back in any way that I could.

MORRIS: Points on Stack Overflow. The original play-to-earn.

EMERSON: My brother and I moved from Taiwan to Vancouver when I was 11. I didn't speak much English, so my first task was translating documentation into Chinese on launchpad.net, which was what Ubuntu developers used instead of GitHub. I was also active on Ask Ubuntu, their sister site on the Stack Overflow network.

If you find methods of contributing to fast-growing fields, all the way from transformer model applications to new NFT mechanics and onchain games, it's easier to make a significant impact. In these new emerging areas, you’ll find early adopters looking for ideas to play around with, so you can get very far by building at the forefront.

MORRIS: When we were in Y Combinator as college kids in 2019, there was a meme that first startup ideas are either some social app to get their friends together, a different form of social media, or a payment app to split expenses between friends. That is exactly what happened to us too.

0xHANK: You made a payment app?

EMERSON: No, we made a social app.

MORRIS: We made many social apps. It’s another long story. One of them was a version of Instagram where you could also tip money, which was common among us younger founders. There’s a situation called “pivot hell” that's now a commonly used lingo, where everywhere you turn, that's a problem that someone else has already solved. You can sit through a hundred user interviews and ask, “What's your hair on fire problem?” Pretty much everyone would say, “My life is pretty good. I don’t have any problems that need solving.”

Things are different when you go into a new piece of technology. If you look around within onchain games, there are a ton of problems that need to be solved. For Primodium, we have to design around blockchain constraints that prevent the game from being fun.

We have to think about generating fun differently while still having a low number of transactions and gas fees. Another problem is the fact that we can't hide information from other players onchain. Although there isn’t a market for solving these problems now, because there are no production-ready onchain games yet, the point I want to drive is the difference in feeling that we've had compared to before we entered this field.

I still try to tell our startup friends who are going through pivot hell right now, “Look at crypto.” They’re like, “I don't know, I don't like crypto, man.” And I'm like, “Okay, that’s fine.”

0xHANK: That's also why crypto is so good, because everyone thinks it’s so bad.

EMERSON: I think it's very good.

Committing to Projects

0xHANK: Something that I've struggled with is knowing when to commit to a project. Over the past year and a half, I've done numerous projects that have all petered out for one reason or another. You guys have had some of the same experiences, but today you don't have qualms anymore about fully committing to an idea. I'm curious to hear about the philosophy behind that.

MORRIS: We struggled with that before when we were in pivot hell. When you’re in that experience, you have this opportunity cost train-of-thought where you think, “What if I don’t commit for a little longer and maybe land on a better idea?”

We learned two lessons from our experiences. The first is that an idea isn't going to be that good until you stick to it and try to refine it. The second is that going from one project to another and trying to piece it all together was a very bad feeling. It’s the queasy feeling of, “I don't know what I'm doing. I have investors that believed in me, but my original startup idea isn't good enough. What do I do now?” As founders, we had immense pressure to immediately pick something to work on.

What we've realized in the last couple of years is that eventually, you'll always find something meaningful. I'll give a concrete example: after Microsoft banned Critterz, we bounced around a couple of crypto ideas before learning that we shouldn’t feel compelled to jump onto a new product just because we feel so terrible about not having something to work on.

A friend of ours pivoted around a lot of products within productivity software, which as you might know is extremely crowded. While he worked on many ideas, he always built upon the lessons that he’s learned within the same space, and now his company has thirty employees with significant revenue. He gave us the same advice to build upon the lessons from our experience as founders.

EMERSON: The point is to always build upon past lessons that you've learned.

MORRIS: We weren’t doing so when we started our careers and found ourselves in pivot hell. With Primodium, all our features were built on top of the crypto gaming experiences that we've had with Critterz and other experiments we built along the way. This has also allowed us to refine our hypotheses further to where we are now.

EMERSON: To add to what Morris said, I've never found it difficult to commit myself to learning a new library or language because I find learning new technologies interesting. I'm also very fortunate to be able to have a career in doing so and helping to support others along the way.

Since I started programming, I've always had to pick up new technologies and build my projects from scratch. It became easier over time as I got used to building and launching products as a way of learning. An example of that would be learning MUD.

MORRIS: You learned it in like a month.

EMERSON: We were introduced to ludens and invited to visit the Lattice Autonomous Worlds residency back in 2022. I started working on Primodium around February 2023; two months later, we launched the first public prototype on the Lattice testnet and got featured on WIRED with them. Over time, we’ve also developed an intuition for which products would be better received than others. Morris, do you have anything more to say about intuition?

MORRIS: Better intuition just comes from a lot of failures.

EMERSON: It comes from experience. Those around my age who pursued traditional paths often ask me what made me want to take risks and have conviction in my own life decisions. Having conviction just makes for an interesting journey. Since the prototype in April, Primodium has always been publicly playable and gathering feedback from our players. Not only are we not afraid to put ourselves out there, but also that's what we strive to do.

There's a bit of fear in launching products for real-world users, probably because builders prefer refining their existing codebases. We certainly had those biases too, but we've learned to place negative weight on those feelings whenever they arise. If you feel that way, even a little bit, just know that things will be okay.

MORRIS: We have people that are helping us along the way as well. We have a great team. Earlier today, I talked to one of our supporters about how I feel like we're in a pretty good place now because we have a great team. We have a great amount of resources to support us for quite a while. I’m happy with the pacing that we're building as well. Primodium is going pretty well!

EMERSON: Also thanks to the Lattice team for organizing all of this!

MORRIS: They're very helpful. As an organization, we'd also love to give back.

EMERSON: We will be contributing to MUD v2.

0xHANK: Hey, I got a pull request open last week.

EMERSON: Congratulations.

0xHANK: We'll see if it goes anywhere.

MORRIS: That's our role as a team building applications on top of open-source software.

To learn more about Lattice and MUD, visit our website, read our documentation, or join our Discord server

For this installment of Devs on Devs, GVN of Moving Castles sat down with Neilson of the Gaul team and lermchair of Emergence. GVN is (as noted in the conversation below) a jester or gadfly of the AW space – playfully pushing people to refine their definition of autonomous worlds, and using his own experimentation onchain and online to seek truth and explore the terrain. With Moving Castles and Trust Support, he has worked on projects like Mascot Stream 3D, an interactive Twitch gameplay channel, Eat Drain Arson, an onchain game built on MUD, Network States, an onchain game co-built with Small Brain and 0xHank, as well as numerous essays, like The Three Eras of World Generation. Neilson and lermchair are the minds behind the MUD template for Unity, a plugin for MUD and the Unity game engine, as well as projects like Engine Study, Gaul, and Emergence. Gaul will have playtests soon, on the Small Brain Games Discord channel.

In the conversation, the three go deep on the philosophical and social considerations of games and autonomous worlds: whether it makes sense to design with accessibility and references in mind, or whether an autonomous worlds demand interactions that are as novel as the new medium itself. They also discuss the relationship between autonomy and automation, historical precursors to autonomous worlds, and explore the idea of onchain consequences.

Games and Inspiration

NEILSON: I think a nice place to start would be with inspiration and what each of us wants to build and what you look to when you're building that thing. This is how a lot of games are pitched: “I'm doing…Super Auto Pets plus League of Legends.” So you're always thinking in a very game-genre-istic style, if I do “this” plus “this.”

GVN: That's a good point. It was a struggle for us for a long time because we are doing something that's never been done before. On one hand, I believe that you should not always be able to explain in just words what you're doing. But at the same time, I think as a game design lesson (that we learned the hard way at Moving Castles) is that it is actually good to start from something that players are already familiar with just because it cuts the learning curve.

NEILSON: Exactly, expectations. And that helps prompt the player into a certain mind space.

GVN: Right. I was watching this GDC talk by one of the Magic the Gathering lead designers. And one thing he mentioned is piggybacking. So it’s this idea that you can only introduce so much new information at once. He uses an example of aTrojan Horse card that they renamed the Akroan Horse to embed it in their world building. And players understood it because it still represented the idea of the horse. But then, the developers changed the name of the card. They called it the Crown Bear or something. It was the exact same card. And people were like, “I don't understand how to play this card.” And so I like this idea of piggybacking familiar terms because people get it immediately. It's an interesting question: even if you're building something new, how much do you want to piggyback on top of familiar game genres just to make life easier for your players?

NEILSON: Blockchain or not, you want to also have something that you're setting up for the player and for yourself as what you're building on the top or extending or remixing. The blockchain almost brings us back to first principles.

GVN: Yeah. But, more practically about inspiration, what's your inspiration?

NEILSON: I don't know. I don't know if I have a genre. I'm making, like, a Sokoban-style game. I play way too much Super Auto Pets now. I'm throwing this one to you. It's gonna be a Super Auto Pets conversation otherwise.

GVN: I downloaded it. And I must say, I’m not hooked. It doesn't suck me in. I don't know why, but I would play more just to understand it. So maybe I am addicted.

NEILSON: Do you play any Vampire Survivors?

GVN: Yeah. Somebody told me that the designer used to design slot machines before. What about you [Lermchair]? What, what's your inspiration in gaming, or in general?

LERMCHAIR: The classic answer to the question is: “everything's inspiring.” You constantly collect thoughts and then once in a while your ideas bump into each other and you get a new insight. I've been looking at things outside of games. For example, complex adaptive systems and concepts of emergence, self-organization, and co-evolving processes in general.

GVN: I think it's a very good point also. I think a lot of the onchain games/autonomous world world discussion right now is people thinking through the lens of games specifically. And sometimes I'm like, “actually we can go beyond that.” I think autonomous worlds take inspiration from social media and the idea of worlds that are interconnected, that are bridges. They're not just entities, but they're also bridges between different types of worlds.Twitter is a world, and Discord is a world. Imagine building the bridges together between these two environments, opening it up and then creating a larger world around them. Maybe we're not just building the future of games, but we are also building a new medium altogether.

Onchain Emergence

NEILSON: I think emergence for me is still a goal. That's where you always want to be headed to, where you’re finding complex behavior by designing simple rules, and you eventually arrive at very complex patterns. Which is a lot of what I have been trying to do: don’t anticipate what's going to happen next optimistically before the chain even resolves, because the chain has all these emergent, complex behaviors that can happen when things are interacting. I want to try to find that space of designing rules, pulling things from all these other games, designing a lot of simple things together, and then hopefully unleashing them into a shared space where they can start behaving in more mature ways or complex ways. So emergence, for me, is a big inspiration.

LERMCHAIR: Do you think emergence is something you can actually design for?

GVN: Yeah I was going to ask that.

NEILSON: I think it's a target you aim for.

GVN: I liked what the EVE Online people have said about not protecting players from other players as a sort of way to foster emergent behavior. You don't design for emergence, but you design a sort of frustration that has to be directed towards someone. It's not directed to the developers, but it's directed towards another player. So you want to do something about the frustration, and then you have the tools to do something about it. And that's where emergence…emerges. You're just indirectly giving people the tools to fix something that has been done to them. And then you have the type of frustration when people nerf your warlock, and if there's nothing you can do about it, that generates frustration towards some sort of authority. And then you end up spinning up a completely new world out of it.

NEILSON: But I'd love for worlds to start at a place of surplus. And I feel a lot of what's being built is a very, very immediate economic tradeoff in gameplay. How can a world when it spawns and players enter into it not be immediately confronted with all these economic realities that a lot of onchain games have? And instead be at least unleashed into a space where they can not just gather for the sake of gathering,  spending, and building, but actually feel there’s like a surplus of activities they can do that aren't just in service of achieving higher levels of either crafting. It takes longer development times and more cycles to find enough activities and items in the world so that it doesn't feel so progressive and linear, and to get to a place where it feels like there's actually a range of options.

GVN: So do you use would you, like, means or, surplus in opposition to scarcity or…

LERMCHAIR: Or do you just mean, like, there are a lot of things to do inside the game?

NEILSON: Yeah. I think it's both. Literally in the amount of items that are present. You're not burdened with an economic choice the moment you start playing the game of either the gas or the resource or some other token. These aren't the conditions through which you start playing because you won't want to experiment or play because you're already feeling the weight of that scarcity. And so surplus could take both that form, but it can also take the form of a surplus of decisions you can make inside game, but that aren't, “I play this one move immediately and I already see my doom portended in my first move as, like, my numbers dwindle and I kind of go down the funnel.” Right? Hopefully it's a widening of options and decisions instead of a foreclosing or limiting of decisions you can make.

LERMCHAIR: What about decisions that have been outside the game? For example, some of the most interesting behavior that happened in Dark Forest wasn't actually in the game, but outside of it – people forming DAOs and these DAOs having wars with each other – creating bots to automate gameplay.

NEILSON: That is the kind of emergence that can arise when a game like Dark Forest gets large enough. It does allow for those meta-games or social structures. You already have something clearly in the game that's strong enough to support these things that build and scaffold themselves around the game. So I think Dark Forest set a very high bar for many other projects.

GVN: Maybe that's actually what really turns a world from the simulation of a world to a world that is alive. Fan fiction, like Star Wars, Harry Potter, Lord of the Ring, whatever, you name it. Traditionally, they are so popular because of fan fiction—because there’s an outside component or a part of the world that exists outside of the world itself. What autonomous worlds habilitate is the capacity for the “outside” to enter and be part of the world itself.

Roguelikes and Autonomous Worlds

NEILSON: Since we have a mascot of autonomous worlds – the jester, the conjurer himself – I feel like I want to use this as a small opportunity to define what autonomous worlds means to you. I think I look to you more when it comes to what this means in design and art and culture, instead of through the lens of onchain game development.

GVN: In 2008, a lot of people met in Berlin to talk about roguelikes. The “Berlin Interpretation” is a series of rules of what roguelikes are. And they made the “temple of roguelike”. It was just a bunch of people that were dedicated to defining what a roguelike is. And it's funny to read because I think there's a lot of things that we are going through in the defining of autonomous worlds. An interesting outcome of it was that they wrote “We can’t define roguelike, but we can build a spectrum, to understand how roguelike a game is.” So I think, first of all, it's interesting that we don’t need to say “This is an autonomous world. This is not an autonomous world” but it's a spectrum. And I’m not sure if it’s possible to build an autonomous world outright.

NEILSON: Mhm.

GVN: Based on our practical experience in development at Moving Castles, I think that large autonomous worlds are only a series of standalone onchain games that have bridges between them, rather than a single game that is developed by a studio.

NEILSON: Which is why we need a Berlin School of Autonomous Worlds, a San Francisco School of Autonomous Worlds, and we need some schools of thought to just start creating different interconnected versions that talk to each other.

GVN: Is Dark Forest an autonomous world? I don't know. I think it's on the scale for sure. And I think it's also, there's so much that can be implemented, to make it a larger environment that also embeds different types of gameplay.

Automation vs Autonomy

NEILSON: Well, I think following what your line of thought and into, and maybe to connective where I've been kind of thinking about it is this maximizing of autonomy. You also brought another figure into the room which is automation, which is what you can do without thinking about something. Autonomy is very much a freedom or individuality or release from constraints. Autonomy is the ability to either make decisions, or be an individual that can make decisions on another’s behalf or to be free of other constraints for lack of a better word. But automation feels like the opposite of that. Promodium is about automating things, right? Like, trading an automated devices in the game that, that, that builds into, like, larger structures, which is what a lot of, autonomous worlds would be: all these different fingerprinted pieces being able to automate each other and do all these things to create large, vast worlds that that can basically exist independently of each parts.

GVN: Can you say more about the relation between automation and autonomy?

NEILSON: The shift that I've imagined is when you play a game in a sense, you become an automated subject that follows the rules of a game. So actually you as a player are playing a game and are somewhat automated. You lose autonomy because actually you're deciding to agree to the rules of a game. So in in that sense –

GVN: In a sense you hope you're starting to obey, exactly. It's something to sacrifice your agency or your vision of what that thing can be to obey a certain vision of the game creator.

NEILSON: Yeah. You sacrifice ever so slight amounts of autonomy in your life just to follow a few rules. And you're free now within that structure to be automated, but also then to explore your remaining autonomy within those rules, because really what games are is still expression. It's not like because you've lost some autonomy you’ve lost expression. You actually gained expression because you're in a similarly constrained environment with a bunch of other automated things. So I think that this is where I'm really trying to tease out: how automation and the ways that games automate your autonomy. I think a big one is, like, I think a lot of people love watching, for example, Twitch streamers or parasocial relationships where you're watching someone. And you're automating your sociality off to some other thing that plays games for you. You watch people do things for you. You watch these autonomous individuals do things for you. So I think it's all this relationship between where you automate parts of your life out to other individuals or or games or things and order to either, probably gain some autonomy or lose some autonomy productively.

GVN: Yeah. I have to figure out automation, the world automation and autonomy are political.

NEILSON: So like some Italian Futurist stuff.

GVN: In Italy, in the seventies there was a very very strong, like leftist, autonomist, or workerism movement.

NEILSON: It would be a dark rabbit hole.

GVN: I think that what we're going to see in gaming is this idea of games that play themselves. Which is a tricky subject in an environment that has no ticks or has no self-execution. But something that I experienced recently is I was playing Zelda after a day of work and I was, like, super tired. You know, I was just like, “I want to space out. I wanna play this game on my console.” I order food, and then I start playing, And when the food arrives I still don't wanna think about anything. I want to watch something that plays itself, like a movie, but I also don't want to leave the world of Zelda because I was immersed in it. I don't have the energy to step out and immerse myself in a completely different  world. I just wish that I could put Zelda on autoplay or that I can have someone share my account and play for me while I eat. It would be very cool if you have a Zelda multisig. Me and my partner, we play Zelda like that because sometimes I'm away and I have specific things that I want from the game, and she has other things that she wants in the game. And when I'm away, she goes around and collects stuff, takes photographs, cooks, and makes potions. And then I come back and I have all this new stuff, and I'm like, it's so nice to share an account with a person that fills the gap of the game, or all these things in the game that I missed because I'm not necessarily invested in it.

NEILSON: I think it's so beautiful to imagine that, both in the world of Zelda, but not necessarily competing. And I think that goes back to how we get worlds that just feel like you're adding value. There's not this oppressive feeling of necessarily having to deal with competition, but you being able to cooperate in a single player world that you share, which is an awesome moment.

GVN: Another important question is: how open is your world? And in the case of Zelda, you have a very safe environment. You can't actually share the account. But it still works because me and my partner live in the same place. That's a very safe experience — trusting the people that you let into your world. And then on the other spectrum. You have a fully open autonomous world where everybody should be able to change it at any time. Do we actually want the world to be that open? Are we ready to come up with design solutions that don’t allow one miserable person to destroy the experience of everyone? I mean, that's what games had. EVE Online had to deal with this. Going back to autonomous worlds on a spectrum there's so many points in the spectrum where you can develop worlds. And I think the interesting thing is how all of these pieces in the spectrum get connected together to form the whole.

LERMCHAIR: It's easy to think of Zelda as being a world that could have either a multiplayer component or a single player. That could almost be a mistake, though, to try and think like that. Worlds are very slippery things such that the worlds of video games really aren't separate from the rules and design of the game itself. If you're able to actually create blurry world borders by objectively defining concepts that are inside and outside the world, which is one of the goals of autonomous worlds, then interoperability becomes easy.

GVN: I think a big question still is what the players want from autonomous worlds. Like, we kind of started to know what we as designers might want from it, but is it the same thing the players want?

NEILSON: And it's worth noting I'm speaking both from a game design background, and how I might pitch a game. You pitch a fantasy, a dream, or the peak player experience, and really that's it. The first thing you pitch is what the game world's about and why people will play it and want to continue playing. I think that comes first. For me, at least one design is an image in my head of the player doing a series of things that they would enjoy doing, and starting from there.

Precursors to Autonomous Worlds

LERMCHAIR: What do you guys think are precursors to autonomous worlds we've seen throughout history?

GVN: Nice question. What do you think?

LERMCHAIR: Have you read Tools for Conviviality? It’s a small book by Ivan Illich. And Illich describes radio as a convivial tool. After radio was introduced in communities in Central America, there weren’t always manuals or blueprints available to fix it if it was broken. However, because the technology of the radio was accessible and “convivial” enough such that people are able to naturally play and interact with it, these Central American communities were able to and grow a tradition around maintaining these radios. The technology formed a community around it to keep it alive. And you can see this pop up multiple times throughout history. For example, in the 1980’s, there's a project in Berkeley called Community Memory, which was a mainframe in a warehouse. It was the first version of something like Reddit. And the project would put terminals out on the street that anyone could use to read and post to a message board. And then the problem became “Okay. We have these really expensive electronics out on the street in public spaces that can be very easy to break. How do you make sure people don't just wreck them?” And the answer that the creators arrived at was that it is necessary  to form a club or organization around this computer in order to maintain it, keep it alive. And this eventually led to the Homebrew Computer Club, which is how Apple got its start as well. So there's always examples of people coming together to maintain something and keep it alive as long as possible.

NEILSON: That'd be a good definition of an autonomous world. A fire you have to keep alive. Everyone's just pitching him. I think that at the end of the day, the only autonomous world that's worth building is something like that. I think people worry too much about keeping things alive for too long. I think that's the feeling every game should try and strive for—this idea of everyone in the community keeping the game alive and feeding things into it and building more things.

LERMCHAIR: Open-source software can be like this as well.

GVN: I think it's such a nice example of how game design should work in autonomous worlds. I feel there's still a sort of eagerness in giving people solutions. It's like, yeah, this is the game. This is how we play it. But I think my approach would be to design autonomous worlds through giving people something to care for. And the first thing to understand is, do they care about it? Dark Forest was so successful because they gave people something they cared for and therefore had to come up with a solution to keep their idea of the world alive. In the series Lost, in the second or third season, the characters discover an underground bunker with a computer that has a countdown, and then they have to type a passcode and then press enter, and then the counter resets. And the characters are told that the world will end if they don’t do this. And I think that's an interesting beginning for an autonomous world because the game is not about putting the code in, but the real game happens when the characters start having contradictory or different opinions about it. “Is this real?” “Should we actually keep doing what we're told?” Then they formed factions and those factions tried to decide whether or not to continue or interrupt this process. And that is where the world actually comes alive. So you have this game loop that doesn't really matter, but then there is our mission that the world is going to end if  we stop doing this. This is where players can create this emergent world around the mission.

Real-World Consequences

LERMCHAIR: Maybe the nice thing about putting something on a blockchain is you have actual consequences. On Ethereum, we could have a million dollars in some contract in your game somewhere and say in the lore that if the world ends, the contract loses all your money. If you die in Ethereum, you lose all your money.

GVN: That could be such a fun thing. You could pretend to be a hacker group, but you're like, “if you guys don't do this every day, all the day, we’ll steal all the crypto in the world” and then see what people do.

LERMCHAIR: It’s like that meme, if you die in the metaverse, you die in real life.

GVN: I like this point also about real consequences because one thing that I hope to see in autonomous worlds is the end of the conception that games are separated from reality. The metaverse kind of tries to forget there is a reality, and instead reconstruct reality in a sort of perverted, boomer idea of what the world is. I think an autonomous world, actually, is the power to just connect games to a world outside games. Maybe EVE has that: you can actually invest real money and you can actually lose money in your ship. What I think is very interesting is this interconnectedness of information.

NEILSON: How do you know when you're doing something that feels good? Losing real money doesn’t feel good. How do you know what intuitions to follow?

GVN: So I think that's an important discussion to have because I feel that we are all experimenting. I think most people have failed in building something. How do you deal with that? And how do you make something good out of it? Because I feel, personally, we at Moving Castles, made a lot of prototypes which we sometimes don't even publish, but we learned so much from. And also we just learn that some directions are actually not the way to go. When we talk about games we can have a lot of interesting technical ideas to experiment with, but they are not guaranteed to be fun.

NEILSON: It is good to definitely try and make as many prototypes and go as fast as you can and just figure out what is fun. Then, the even harder step is to make sure that your projects don’t die on your hard drive, and that you make the effort to really hit the publish button one day and get it out there. I think there's a lot of amazing projects and software that only go 80% of the way. Hopefully a lot of people in the next year who are finding this and starting to build, actually go all the way to the finish line, really push it out there. I think it's really important to train yourself as a developer and a designer to figure out what it takes to finish something. Get all the junk and prototypes out the way as fast as possible but then also finish something. It's very, very different from starting a project. It's an entirely different world that I think people don't realize until they get there. So, yeah, hopefully, we have people entering the space and finishing things, which is to say, starting things.

To learn more about Lattice and MUD, visit our website, read our documentation, or join our Discord server

When an onchain game (dare I say autonomous world?) reaches maturity, the core developers transition from building contracts and client code to building tooling for third-party developers to create plugins and bots. It’s a sign that the game mechanics are ossifying, the emergent behavior has surfaced, and the real fun can now begin.

Words3, the madcap onchain iteration of Scrabble (if Scrabble were built by a futures trader with a sweet spot for VRGDAs) has reached the botkit stage. The game was developed last November, using MUD v1, and has since undergone a port to MUD v2 and various quality-of-life upgrades in preparation for its mainnet launch this past week. In a catch up with Small Brain this Wednesday, we discussed what’s next for the game, which recently had a 4-day run on Base, with over 120 wallets participating, a ~$22,000 prize pool, with more games planned in the future.

For those who didn’t get the chance to play Words3, a brief recap of the rules: you connect your wallet to the client and immediately access an infinite board, along with all twenty-six letters of the alphabet, each of which are priced based on demand. The prices of letters increase (or decrease) according to an exponential function benchmarked against an expected future price, which means at any given point in time, a letter may be more or less expensive. Like Scrabble, you place your letters on tiles to create words; unlike Scrabble, anyone can play a word at any time (and of course, instead of drawing letters randomly, you purchase them directly). You get points for your words, plus additional 2-5x letter multipliers for playing on certain squares. At the end of the match, whether you win an allocation from the prize pool is determined by the number of points you’ve earned, adjusted by the total profitability of the words you’ve played.

In the most recent match, we saw some primitive bots and plugins begin to emerge. Yonada built a Words3 stats client that showcases the most played letters, best plays, points distribution across players, and the MUD tables configured by Small Brain. Saucepoint (who reached the top of the Words3 leaderboard) built a point multiplier calculator using the game dictionary and a custom python script, which advised him on the best words to play. At one point, saucepoint reflected, “If I knew how to read MUD contracts, it would’ve been possible to construct perfect sequences. Maybe even bot the game with auto submissions.” This is where Smallbrain’s upcoming botkit will likely come in.

To understand the power of the botkit, we first need to understand how the Words3 contracts work, and how they interact with the Words3 client. The logic for playing a word on the Words3 board is handled by the PlaySystem. When you call the “play” function from the client, various inputs are submitted: the letters you played, a client-side Merkle proof that checks that the word you played is in the English dictionary, the coordinates of where the word starts and ends, the direction you played the letters (left to right), and bounds (a struct) that check other letters above and below the word you played to see if other words can be formed around it. Bounds also have a provision for client-side Merkle proofs, because they need to check for valid words as well.

For someone trying to create a bot or custom client for Words3, this kind of client-side complexity can be daunting. It’s labor intensive to make moves, because you need to determine the words you're playing, and then create word proofs and bound objects for every word from the client itself. To alleviate this complexity, the botkit will allow users to provide just their word, and letter coordinates and direction, and it will fill in the Merkle proofs and bounds for you. Because MUD automatically gives you state syncing from the client, players can use the botkit to deploy more complex logic, with no knowledge of lower level MUD details (like the MUD config) required. In future rounds we might see saucepoint (who fessed up to being a MUD novice) launch an auto-submission bot using Small Brain’s botkit. We might see bots that simply evaluate the board and harvest high scoring words with minimal expense, just by playing the letter “S” on words that can be plural. Or we might see entirely new, more professionalized clients begin to emerge.

When implemented, the botkit will essentially be the MUD minimal package, with the Words3 contracts plugged in. It will show you how to set up a basic MUD project and will deal with all the idiosyncrasies of the Words3 smart contracts. The botkit is essentially a way to abstract away needing to know MUD, or the way that Words3 handles logic across the client and smart contracts. It’s a layer on top of MUD that converts state updates into a more readable format for a developer.

In a world where Words3 clients proliferate (one dream Small Brain has is to see a Bloomberg Terminal for Words3 built by an ardent fan of the game), clients themselves will be able to monetize. This is one possible endgame for the botkit: it’s not just a way for you to optimize winning strategy for yourself, but a way to get your custom client into the hands of many users who are willing to pay for an upgrade (some of whom may choose to further optimize the client for their own use).

In addition to the botkit, Small Brain is looking at other improvements to Words3 gameplay. This past round was the first time players could use point multipliers. Upon reflection, Small Brain thinks the liberalness with which multipliers were spread across tiles may have been a mistake; it was simply too easy for players to get massive point multipliers, and quickly climb up the leaderboard (so perhaps without multipliers, saucepoint will need to find a new winning strategy). Letter pricing with VRGDA mechanics may also need to be tweaked: the constant Small Brain used for the target price of letters was likely too small, which led to surging letter prices on day two of the game. Small Brain is also considering an extension of the length of round gameplay, or multiple rounds where each game impacts the next one in unexpected ways.

Still, the botkit remains the key focus for Small Brain. And for us, it’s an exciting new possibility for what MUD can enable – and a new layer of digital physics that can be unleashed. In addition to providing software to users to easily deploy complicated onchain applications, MUD can also provide the rails for botkits that yield new and unexpected forms of onchain play. For every MUD app, let a thousand clients bloom.

To learn more about Lattice and MUD, visit our website, read our documentation, or join our Discord server

Thank you to ludens, biscaryn, and Small Brain for feedback on this piece

From July 31st to August 4th 2023, Lattice hosted a small summit for onchain application developers building on MUD. The week illuminated just how far MUD and the teams using it have come in a short amount of time. Our previous summit, in Fall 2022, was a residency where teams tested out MUD v1 and built hackathon-style games. This time around, almost everyone present was iterating on long-term projects (on MUD v2!) that are preparing to launch beyond a testnet.

Mastery of MUD unlocks more options in the tech tree: do you want your World to be session-based and small or a persistent MMO? Who can write to or modify the Systems in your World? How can we encourage user-built plugins? During this week, we recorded several conversations between developers in the autonomous world ecosystem who are exploring these questions in depth. Our first interview is between Kooshaba, a developer building Sky Strife and an early collaborator on Dark Forest, and Small Brain, the crafter of Words3 (which launches this week on Base) and Network States. This interview kicks off Devs on Devs, an ongoing series published by The New World, which will feature in-depth discussions between developers in the AW universe, exploring their origin stories, interests and biggest challenges.

The conversation between Kooshaba and Small Brain is far-reaching, spanning everything from the demands and upsides of session-based gameplay, to the motivations behind building onchain, to the developers’ sources of inspiration.

SESSION-BASED GAMEPLAY AND PLAYER EXPERIENCE

SMALL BRAIN: So, why was it called Sky Strife?

KOOSHABA: This is the worst answer ever. You know Hans? Yeah, Hans came in and before Sky Strife, it was just MUD War. It was just like generic MUD RTS.

SMALL BRAIN: That's like a little too gross.

KOOSHABA: Yeah, it was gross. And yeah, we just all had the basic RTS systems in place. We were like, we have no idea what this is going to become or what the theme is. But we just had the idea of islands because islands were like a nice way to fit a shit ton of people on a map.

SMALL BRAIN: Yeah.

KOOSHABA: Without actually shoving them all next to each other. Like you'd hop from island to island. So it was supposed to be like a large infinite game. It was initially supposed to be large, Dark Forest style. A little less than Dark Forest, like 8 to 10 hours was our goal.That was supposed to last with hundreds of people. Anyway, so that's where the island idea came from. You'd start on a small island and get to bigger and bigger islands to fight more people. And islands are backtracking kind of. Like they just let you split things up.

SMALL BRAIN: Exactly. And code somehow?

KOOSHABA: Well, not necessarily code, but just gameplay. You don't want to spawn next to 60 other people.

SMALL BRAIN: Oh, interesting.

KOOSHABA: That's just insane, right? You can't even socially interact with that many people and form alliances.

SMALL BRAIN: Oh, cool. I was thinking it was a ZK thing or something like that. You know, you can get away with this if it's part of the grid, but can't do it for an infinite grid.

KOOSHABA: Yeah, no, we were just thinking because Dark Forest was incredibly overwhelming because the player experience was you spawn in and there's just hundreds of addresses all having huge planets around you and there was just no chance you were going to get anything done.

SMALL BRAIN: Yeah. Actually, this is something I really want to ask you about. Which is, how do you think about session-based gameplay?

KOOSHABA: Yeah, yeah.

SMALL BRAIN: I spent the first three months of the year working on Ape's Gambit, which was session-based, and I kind of realized all the problems with that. Okay, there's obviously the onchain problems with that. You know, we took down the last testnet, like 13 people making transactions at once. There's go-to-market problems with that, but how do you get everybody in the room at the same time to play this? How do you grow this thing? So I kind of see that you figured out the first part, but can you talk more about both the engineering part of it and also how are you even thinking of launching this and getting people to play the session-based thing?

KOOSHABA: So, I mean, to start, I was not a fan of session-based for a really long time. Like I thought it was just a bad fit for blockchain, and we know the technical reasons for that. We're basically storing state onchain that's supposed to last forever. And it's in a match, right? Like the match can literally get thrown away afterwards. No one fucking cares. So that just fundamentally doesn't make any sense, especially since we don't have transient storage opcodes yet. But we're going to have that soon. That's going to be incredibly exciting. It's going to change everything.

SMALL BRAIN: I didn't even think about how like that was for something that people who weren't L2s could use. Like we can just put shit in transient storage.

KOOSHABA: So the way I think about it now, though, is session-based gameplay is there for a reason in traditional gaming because you don't want the effect of: you join a game, then another person shows up, then your friends show up, then their friends show up, and suddenly there's a thousand people fighting over something that was supposed to be like a casual four-player match. And we see this in literally every MMO has this problem. Like World of Warcraft open-world PvP is supposed to be this fun, casual thing. But the second there are any stakes, it turns into a 200-on-200 battle where you can't make any decisions that affect the outcome of that. And it becomes like it's only giant guild versus giant guild. And that's what Dark Forest was. It was just DAOs fighting it out. Individuals were just swept aside completely. So session-based gameplay is a way to keep it somewhat fair for an individual player to come in and have fun and have a good initial player experience. And we're basically sacrificing a ton of technical problems. Like this is just not a good fit for blockchain, but I think the player experience is worth it.

SMALL BRAIN: Okay, interesting because I feel like I think similarly to you, but I also immediately react badly to session-based stuff. Especially like, you know, that was really rubbed in my face while I was building session-based stuff. I was like, this just feels wrong.

KOOSHABA: No, we're fighting uphill the entire time, honestly.

SMALL BRAIN: But on your point about player experience, like I totally feel that because like I think like some things that I keep in mind for asking myself: is this worth going forward with or not? Okay, so I guess this is different than session-based. One is, does it let players come in at any time and play? Two is like, does it let players play for like five seconds individually and have fun? But also let players play with a bunch of people for long periods of time and have fun? Can you fit both of those player behaviors and then both need to be positive? Like if it works for you, this is just you can come in and play like a clever letter and be a little profitable [in Words3].

KOOSHABA: Yeah, that's beautiful. For our next project, we're going towards that for sure. You should be able to play single player for hours and contribute to this grander world and come back and see the effects of what you've done. But you shouldn't have to wait for three other people to play with you.

SMALL BRAIN: Yeah, it should be totally timed. Yeah, I mean, I think that time...I was gonna say time agnostic, but that's…time doesn't matter. I can jump in whenever. Just nice also for growth, which I guess is the second part of this. How are you thinking of growing session-based stuff? Because I bet there's a lot of produced events you can do around that. But I just wondered if you had a plan around this.

KOOSHABA: Right. I mean, so the most basic thing we're doing is like we linked all the sessions together with the overworld that we're calling Amalgema. And there is a resource that is used to spawn the matches. And I think we already see it kind of working where matches are now scarce. Like you need to win to create more matches. And suddenly it's like an exclusive thing. And people are like going into Discord saying like, “hey, anyone got some orbs? Like I want to fucking play right now, but I can't.” And that to me was perfect. And that automatically creates that reason for you to all be online at once. Like I just spent the money. Everyone gets in here and they can self-coordinate.

SMALL BRAIN: Yeah, that's so good. Especially because the value is fun. Like the value in, value out. People want to play the game. I feel like I would struggle with that. Whenever I think value in, value out, I just assume that what I built is not fun and still needs to meet the criteria. It's not by itself.

WHO’S PLAYING ONCHAIN GAMES?

KOOSHABA: If it's fun, people will want to play. But I agree with you. Like if you really do the math on let's say you have a game where four people need to be online all the time. I think it's like over 12K monthly active users to have four people on at any given moment during the day. Which let's be real, that's bigger than the entirety of the AW [Autonomous World] ecosystem. I mean we're in the hundreds and the retention is very low. So we can't hit that physically.

SMALL BRAIN: I don't think it's an unreasonable number.

KOOSHABA: Right. Yeah. If we go like one circle out, we hit that immediately.

SMALL BRAIN: What do you think that circle is? I mean actually who do you think the people who play now are? What do you think the circle is?

KOOSHABA: I mean let's be real. It's like mostly engineers. People working on their own games themselves. Which is good and bad. Because engineers are actually very accepting of horribly broken games. Which is nice, but to get to that next level, it's just all about polish. And I think it's something we're struggling with. It's just baseline boring engineering work of UI, UX. You know this. You're doing this with Words3. Just getting people in the door and keeping them there. Because everything just feels smooth. So our next target audience is much bigger. Which is like people who know how to use Metamask.

SMALL BRAIN: Okay, Cool. Interesting.

KOOSHABA: You should not have to be an engineer. If you know how to send a transaction, you should be able to play the game. And then honestly kind of forget that transactions exist at some point.

SMALL BRAIN: Okay. Yeah. I like that as the next circle. Because I think a lot about the next circle of people. I guess for me it's a little more stratified. It's like, is the next circle of people…degen is not a good word. But people who are interested in financial-y stuff. People who are going to put whale amounts of money in, to focus on them. Or to focus on making it accessible. Keeping prices low. People who can just send a transaction and engage with this thing onchain and have fun. I lean hard toward the second one. But also what I lean hard toward doesn't really matter. There's probably some correct answer.

KOOSHABA: But yeah, this is why I said people who know how to use Metamask. Because that encompasses all crypto users. There's people who love NFT for the art. People who love NFTs because they're rich. People who are Bitcoin maximalists and have guns. You know, whatever. All those people should be able to enjoy a game together regardless of their theories. But this really does feel like the the early days of when universities were getting their first networked mainframes and the first thing people did was make multiplayer traditional MUDs. And the professors were like, “What the fuck? Who's using all my resources? Who's wasting all my resources? Why would you even put a game on a computer? This is a work machine. You're being ridiculous.” And here we are.

WHY DO ANYTHING ONCHAIN?

SMALL BRAIN: Oh my God. Let's do that question. Let's do the question that everybody and their mom asks when you tell them what you do, which is like, why the hell are you putting it on a chain? How's your reaction to this?

KOOSHABA: I mean, it's a totally normal and acceptable question. I don't want to insult it or anything. But really, the true answer is that it's really fun. And I think that's okay. That to me is justifiable.

SMALL BRAIN: It's fun for…?

KOOSHABA: For me.

SMALL BRAIN: Okay.

KOOSHABA: I don't have a choice. I'm doing everything that I'm doing. I find it incredibly interesting and mentally stimulating. And the second order effect of that is it goes towards a future that I can believe in. I started in crypto as a Bitcoin maximalist in like 2011. I just read the white paper. That's the world I want to live in And that has just fueled everything I do in crypto. It's not been about what I can gain from it. It's like, what future do I want my kids to live in? And I also love games. So the games I want to see in the future are these huge, open, accessible worlds that are not gated by weird financial incentives.

SMALL BRAIN: Yeah. That's a great answer. I'm kind of aligning with you. I, yeah, it's probably the most fair question. I probably honestly have the same answer as you do, which is, I just find this fun and my brain is making shit up on top. That's also probably how everything works. Anyways, back to the stuff you can use, which is it? Like, I feel like there's two things. One, there's a bunch of people. I think there's a couple of people in this room, not like this room, like this larger room who feel like they need really consistent and defensible reasons why things are onchain. Like you need a clear argument why this game could only be built on a blockchain and could not exist without it. And yeah, I think that's kind of how it used to be. Like maybe a year ago, like when I was in London [for the first Autonomous Worlds residency] I was like, “Oh wait, why are we doing this? Let me think really clearly about it.” Now it's less “so like we need a defensible reason why this can only exist on a blockchain” and more so “this is just a computing platform that's going to be out there.” If you're making a thing that fits its standards more than it does, like than it does like a server, then you should just do it on it. Like if your thing is about persistence, like Network States is about your states lasting forever and you feeling ownership over them, but your feeling of ownership doesn't translate into money. It translates into you caring about a story. Like that's the take there that it should just be on chain. Like if you have a thing that is supposed to last forever and that you want people to build their own things then you should put it onchain, right? Like maybe you could build a server and build an API to it and document it very well and make it open, but it's just much harder. You're fighting against the grain when you could just do it on the platform that gives you that, right? Like there are plenty of things that thematically should be on a blockchain that you should just put there because they're just, just they fit the platform better and you don't need a reason why they need to be there.

KOOSHABA: I have like a long, long, far future vision that I'm working towards and it's like, it's always been my personal goal before I die. I need to make an MMO. If I die, and if I do not make an MMO that supports millions of concurrent players before I die, I'm going to be very, very upset.

SMALL BRAIN: I just like the recording to know that was a riveting delivery. That was Oscar-winning fucking delivery.

KOOSHABA: I'm very sorry about this. This has been my dream for a very long time. And to me, that is everything in my life has been building up to that. To launching this, this game, like the final game that I launched and then I die with it. And like, I want to have a Dwarf Fortress. I want to be a lunatic who has devoted his life to this, this one project. Anyway, we don't have the technology to create that right now. It just doesn't exist. All of the current day MMOs are like little sandboxes. Like, okay. World of Warcraft. How many concurrent players do you have on the server? They don't even announce that because it's really low. Like you're never playing with that many people concurrently at once. New World, the Amazon MMO that recently launched. It was okay-ish. I played it for a bit. Multi-billion dollar company, 2,000 concurrent players at a time on a server. That's nothing. That is not a massive world. That's not an autonomous world.

SMALL BRAIN: Yeah.

KOOSHABA: Right? We finally have the technology with these god computers to create truly massive autonomous worlds. And we're going to get there. And even if the baby steps we're making today don't make any sense, we are going towards this world where we have these massive digital worlds that people can't even comprehend right now. And literally, I feel like I've known this my whole life. When I was playing World of Warcraft and adults would be like, “oh, what are you doing? You're wasting your time. Get a life.” And I'm like, honestly, my life is more interesting than yours in World of Warcraft. I was saying that the entire time. “What do you do? You just go to work? You go home and cook dinner? Fuck you. I'm raiding 40 man raids three times a week and challenging myself.”

SMALL BRAIN: Yeah.

KOOSHABA: So it really is a technology to create an infinitely more interesting world.

SMALL BRAIN: God, that was beautiful. It's so nice to hear this. I just do not think this long term.

KOOSHABA: Really?

SMALL BRAIN: I think two years out long term. And mostly I'm thinking about “how can I get people playing tomorrow?”

KOOSHABA: To me, it's like you need that ultra long crazy vision. And then you need the: “what do I do tomorrow?” And then everything in between will sort itself out. That's my belief. But you can't not have either of those, because if you don't have the super long vision, you get spiritually upset.

SMALL BRAIN: Let me contextualize this question. I feel like in London I came and saw that there was MUD. And I was like, great, there's MUD. I can build a game on a grid very simply on my laptop without running a server. Which would have made it too depressing to put the game up. And so now the depressing threshold was low enough. Low expectations. Easy enough to have experience. And obviously that was MUD v1 when it was not documented. And it ended up taking time to figure out how to, but it was very possible. When it worked, you get a lot of things for free and that lets people in this room build the type of stuff they're building. The type of stuff we're building is still turn based. Not a lot of people can do things at once. Obviously there's transaction times. If you look at, yeah, you see the similarities between all the games we're building. And the friction with them. I wonder what you think will come up in the next five or six months. What will become easier? And how that will make all our games look different.

KOOSHABA: Well, okay. We're finally getting to the point where we're nailing indexing. And client state sync. And it doesn't sound sexy. It's just normal. But no 30 second load times. Which is huge. And Sky Strife right now, that world that we just played in has been running since Thursday.

SMALL BRAIN: Like last Thursday? No way.

KOOSHABA: Yeah. Yeah, it's just been running.

SMALL BRAIN: Dude, I'm jealous, man. Give me that index.

KOOSHABA: And sure, we had problems today with load times. It wasn't great. But it was loadable. And people played six matches no problem. That was unheard of six months ago. There was no possible way. And I didn't even optimize the Sky Strife client to consider the fact that you're loading way too much state. It just kind of handles it. So, it's a really native development experience.

SMALL BRAIN: Are you loading all the state from every game since Thursday?

KOOSHABA: Yeah. But it still works with that. And then the next step on top of that is like querying the indexers. Just say, give me a subset of states. And just using whatever SQLite stuff you've built. And then we just have horizontal scalability for your games. I mean, that'd be super nice if you want to have matches. You just query it. Your client only gets to say relevant to the match. Or even a giant open world game. Like, give me all the state between 0, 0, 100, 1000. And then as you walk, it's querying ahead of you. Yeah, you totally can do that. Like a traditional MMO. So I think with just the boring infrastructure unlocks, it really, really opens up what we can do. I also am really curious what we're going to see. I'm doing analytics.

ANALYTICS

SMALL BRAIN: You're doing analytics? It would be cool to see where people are dropping off, when users come in.

KOOSHABA: I think we'll literally finally have not what we feel pain with, but have some data on how people, where they don't convert, and what we can make better. Because I guess they don't care about load times. Seriously, maybe the people who play are willing to sit around for a minute, but they don't want to connect at all. Who knows?

SMALL BRAIN: Yeah.

KOOSHABA: No, but I think the reality is the feedback for our games is getting polluted by all these problems. I've run certain playtests where there were just fundamental issues. And I'm glad that people surfaced them. But that means they were not giving feedback on the gameplay changes I wanted to test that week, because their transactions just wouldn't go through or something. The closer we get to stability, the better games we'll be able to make, just because of throughput of feedback.

SMALL BRAIN: Yeah. I find it really hard to run play tests remotely. I tried dropping as many analytics into the client as I could, key maps, and even recordings. Words3 today is recording your screen. I'll turn it off before a live launch. It really helps during play tests. But it's very different when you're sitting in a room and you can just watch people play.

KOOSHABA: Yeah. What do you do post-play tests? So actually just, oh my gosh, I should not close my laptop, I just realized. Because I was running my analytics server in the background.

SMALL BRAIN: Tough.

KOOSHABA: I forgot that's why I had it open. So yeah, we built, this is something that Nagual is super serious about because he comes from traditional game dev. You just break down every single player action into an event. And I'm not relying on client analytics, because it's pretty unreliable. Let's be real, so many people block them. So I'm creating user analytics from pure chain state.

SMALL BRAIN: OK, cool.

KOOSHABA: Meta events are getting created just from the contract.

SMALL BRAIN: Oh, interesting.

KOOSHABA: Because I know when you build a unit, because certain tables were set. There's no unit built event.

SMALL BRAIN: So you didn't use the ephemeral tables, you do something on top that's just happening.

KOOSHABA: Exactly. I'm just smashing a bunch of tables together and figuring out what's happening. And then we turn that into CSVs, and that gets uploaded into a Google Drive somewhere and spit into some traditional dashboard with a bunch of tables everywhere. So at this point, from play tests, we just pour through the numbers and we know exactly what units were overpowered. We know how much gold people spent at what times. And it's very, very numbers based at this point. Because the first nine months of Sky Strife, I basically made and destroyed six different games. You know how this goes. And it was just all gut based.

SMALL BRAIN:  You can't get anywhere with that, right?

KOOSHABA: Yeah, it's like you wake up two weeks later, and you're like, ah, this feels wrong.

I'm taking it home. And you just start spinning your wheels. You start re-implementing everything. And yeah, we've got to get out of that zone.

SMALL BRAIN: Yeah. Yeah, I feel this a lot. This one annoyed me, nothing shipped the first half of the year. It's like, I only learn things when people play them. And I feel like you don't actually get a good play tested until the thing is live.

KOOSHABA: Yeah. Yeah. No, that's true.

WORDS3 ON BASE

SMALL BRAIN: I'm so, so excited for Base launch.

KOOSHABA: Can you talk more about that? You are literally the first MUD project to go onchain [not on a testnet].

SMALL BRAIN: Base mainnet launch should be good. Like, I am worried about a couple of things. The largest worries are, one, people only play Words3 because of novelty initially, and it's not actually fun. But retention was OK for the first round. Like, it dropped off after the first day quite a bit. But then those people stuck around and played. But there's a core group of people who understand it, who liked it, and came back every day. We'll see if that sticks around. Yeah, so that's the biggest thing I'm worried about. Is this a novelty thing, or is this an actual game? I don't know. And then, yeah, they've been good partners. They've helped with having an archive node and have a ton of stuff planned that they're plugging me into. The only thing I'm worried about is liquidity. We'll see. I don't know if people will, like, everybody will have to bridge to play. There were people who, I think, had ETH on Optimism that were just like, cool, try it out and buy a word. I think if you want to play, you need to look at the game, understand it, want to play enough, and then bridge your ETH over.

KOOSHABA: But there's some subset of users that are just going to bridge immediately on Base because they're like, oh, a new playground.

SMALL BRAIN: Yeah, right? And then they'll play. And I think when people play their first Word, then they're more likely to come play again. But I think that initial hump of playing your first Word is pretty large. And also, because it's like $5, $6 per Word, I can't fund users, which would be the way to do it, which would be like, find your first Word, but I don't have the war chest for that. So yeah, that's the one thing I'm worried about. I think they make it pretty easy for Coinbase users. The nice thing will be, if you have a Coinbase account, you'll instantly be able to transfer ETH over.

KOOSHABA: Oh, Ok, yeah.

SMALL BRAIN:  Yeah, so that's kind of sick. But you still need to know what this is. A big problem I had with the first version was people would message me, like, what is a seed phrase? Because they were making a metamask to play. And I was like, OK, I can explain to you what Metamask is, and then I need to explain to them what Optimism was. And it's an L2, and you need to bridge your ETH over. It takes 15 minutes. It takes two days to get it back. It's just way too much for somebody who does not have a Metamask, you know what I mean? Yeah, so that's what I'm worried about. In general, I'm very excited, because I think it's a risk, but it could get a lot of eyes on it. And they're value aligned and have been really good partners.

KOOSHABA: Nice. And you're the only onchain game launching with them, right?

SMALL BRAIN: Yeah.

KOOSHABA: Hell, yeah.

SMALL BRAIN: Yeah, yeah.

BOTS AND CLIENTS

KOOSHABA: Yeah, and you said you're going to have a bot kit, too?

SMALL BRAIN: Yeah. We'll be shipping with it. We'll make some Words3 Bots. That's what I'm most excited about.

KOOSHABA: Yeah, it should be fun.

SMALL BRAIN: Yeah, I just want to see, there are all the things that we talk about that I feel like I just want to take the extra step to make more accessible. The bot kit will help people make their own clients as well. It is deceptively hard to make a MUD client, I think, if you haven't done it before. It makes things so much easier, but it does take mental effort to wrap your head around. I think if you're building a client, I think the difference between building a client for Words3 and having to be able to generate Merkle proofs, and take in chain state, and decode it, and turn it into mod. Versus like here is a function that gets me a word and here is like a mapping with all of my letters.

KOOSHABA: Right, yeah that makes sense. And yeah I think if I were to make a client just for myself though it might be easy.

SMALL BRAIN: Yeah. Like it doesn't need to be juicy.

KOOSHABA: Yeah. Like I know what's going on in the background like I know it'll eventually happen I don't need optimistic updates.

SMALL BRAIN: Yeah. So that's the cool aspect where maybe onchain games are everyone has their own personal client. I mean that's why I love the idea of monetizing only off of your client as well. It's like you build the game but the value you're providing is just the UX. Yeah. And it's like that also kind of puts it in people's heads that they can build their own clients for this game and charge for them. Like it's like please make a better client than me and charge more for it.

KOOSHABA: Unreal Engine 5.

SMALL BRAIN:  Literally. I'll make one that shows all the word stats and like historical letter prices like charge power users like a thousand months to play. The Bloomberg Terminal for Words3. That's extremely useful stuff but one I can't put in the client because like now there's a ratio there and it's confusing.

THE DIFFERENT KINDS OF GAMES

KOOSHABA: What games are you looking for for inspiration?

SMALL BRAIN: I don't play games. That's my secret. Yeah it's actually my secret. I never played games growing up. Actually I did. I never played video games growing up. Okay sorry I always associate games with video games. I only played…so I loved riddles growing up. If you ask me a riddle I'd probably know it. This makes trading interviews extremely fun except for the part where you actually have to trade in the final round. The rest of it is just math riddles which I've heard before. At first I would be like “no I know it I'm sorry.” Until they would give me one which I didn't know. It was a variation of something I knew. It was like, you just pretend you've never heard of it. That's what I did eventually. That's what they want. I was just stoked that we were going to talk about riddles for an hour. I was like this is sick. I majored in math. I went through a bunch of interview processes and had a fun time and had a couple of offers and then decided to build a fully onchain game. That's part of why I'm here. Actually during the pandemic I worked at a crypto trading firm. I used to turn my brain off whenever people said “decentralized”. I'd be like “I don't want to talk to you, here we go again” and then I met a couple of people who worked at a HFT and they were founding their own crypto trading firm and it kind of became clear that I should step on as the first engineer. So it was my job to just build all the infrastructure the trading firm needs. One place to monitor orders and get real-time price data and save it in a database you can query easily. It's a bunch of centralized exchanges, they all throw in APIs and you just want one API to place orders across all of them. I was building all of this stuff so just grinding all that out. And that was when I read the Uniswap white paper and I was like “oh sick an order book replaced with math, very cool.” It was just very cool to me that you could use math to mess with money and play all these behavioral games and then I was thinking like “you should just do what a psych professor does en-masse onchain like we should just like figure out how greedy people are by running experiments.” And so I built a financial auction-based game where it's pretty much an in-person prisoner's dilemma that did not launch which took like almost a year to build. After that I was kind of thinking “what did I just do?” First of all I realized that game theory isn't fun. It's a cool mechanic, it's an interesting narrative but you need to build the reason why people engage with it. I was very technically savvy but I think naive about who would be on the other end of this and the more and more I learned about what those dynamics were like the less and less I wanted to do it. So that's kind of where I was left thinking I was thinking two things at the end of that like one “I'm not spending a year building a thing in this space again, I'll launch things more quickly” and two like “is this world computer useful for anything else?” and that was like literally when I found the London residency and the 0xPARC stuff online.

KOOSHABA: I think that you just like cold applied.

SMALL BRAIN: Right because I was like “this is exactly where my brain is, yeah it seems like these people are thinking in a similar direction.” So that's part of why I'm here. Anyways how did we get to trading?

KOOSHABA: I mean I guess you answered the question which is like trading is a game

SMALL BRAIN: I just want to make things I would engage with. And the bar is very weird for what I would engage with.I think that's why it needs to be hyper-simple, because my brain turns off to games so easily.

KOOSHABA: I think that's your superpower, because…well, me and my brother play a shit ton of games, and at this point, the type of games we like are very, very niche. And if we made a game that only we like, that appealed to us, the target market is very tiny.

SMALL BRAIN: I don't know if that's true. That's huge for a different type of person.

KOOSHABA: Yeah, but I don't know about huge, though. But, like, it's a different type of gamer that is hard to reach, I think. And probably the type of gamer that's far more suited towards AW. The type of gamer that's willing to wait for a thing to load.

SMALL BRAIN: Yeah, that's fair. That's fair. I'll click out of a game. I'll click out of a thing if it doesn't instantly show me what it's doing and tell me why it's interesting in the first ten seconds. I'm out of there, you know?

KOOSHABA: Yeah, actually, I'm at the point where I'll play any game. Shitty game, broken game, whatever. Because even a shitty, broken game, you can learn something from and exploit it. Like, oh, do they have this classic bug? Yeah, they do. Okay, I can use that to win.

SMALL BRAIN: Yeah. Oh, I love clicker games. Those just fit that bar. You just, like, do one thing and it tries building, you know? It's, like, built into the format.

KOOSHABA: Like, paperclip maximizing?

SMALL BRAIN: Yeah, yeah. Cookie clicker.

KOOSHABA: I play a lot of games.

SMALL BRAIN: What are your titles?

KOOSHABA: Lately, I've been playing a bunch of Company of Heroes. Which, yeah, I'm going to say a bunch of names that you probably don't know. But yeah, it's an RTS game. Historically accurate World War II RTS game. Which is, like, very, very inspiring for the RTS genre. Where it's actually a first-person shooter engine, but you're playing an RTS game. So each individual model has health, they hide behind cover, they have a real gun, the bullets hit cover, and the environments are destructible. But you're just commanding these squads at a high level. But it turns into a very, very cinematic experience. So it's a really rewarding RTS experience where there's not a lot of agility requirements. It's just all high-level tactics. What inspires me for AW is just every MMO that I've played throughout my life. RuneScape is probably the closest thing to an AW that I've played. I have, I don't know, 8,000 hours in RuneScape, or whatever. World of Warcraft, yeah, every Blizzard title, Warcraft, Starcraft, Overwatch, whatever.

SMALL BRAIN: Do you make any mods?

KOOSHABA: I made custom maps in Starcraft 2, which was, yeah, I guess they're mods. It's more of a separate game engine, really. And I made a couple little arena games where you'd spawn, you'd pick a loadout of spells and then battle your friends. And that actually transitioned into a game that I built during the pandemic, which is what led to me getting a job at Dark Forest, which was a 2020 hit. I was just inside all day, and I was sitting around thinking, and I hadn't done game dev since making my custom maps, but it was always in the back of my mind, this is actually what I want to do. I had been programming for a really long time, but just web 2 shit. So I was like, fuck it, this whole year I'm just making the game. And from first principles, I figured out multiplayer, real-time networking. And I was like, “I'm not looking anything up, I'm not reading any books, I'm not watching any videos, I'm just going to do it and see how far I can get.” And it was like a ton of trial and error, but by the end I had working network code that kind of mimicked what people had landed on generally. Yeah, very cool. Sick, I figured it out. But I could have just read a paper and skipped all of that.

SMALL BRAIN: You're like the fine-minted multiplayer guy.

KOOSHABA: Well, because I hate… I know that the most productive thing is to go read a research paper and then you solve it and you move on to bigger problems, but it's like you're stealing all the discovery from me. That's the fun of it. I want to have that moment where I, on my own, figured it out. But yeah, at work I should probably build on the shoulders of giants sometimes.

SMALL BRAIN: I feel that. I'm like the John Carmack of DIVs. The DIVs disappear when you scroll, appear.

KOOSHABA: That's huge. But that's what it was. That game that I built during 2020 I just started showing people and I showed my friend Sina, who was just an old friend, but it turned out he worked at the Ethereum Foundation. And I showed him and he was like, oh sick, you should meet the Dark Forest people. And I just looked it up and was like, oh my god, this is the coolest thing I've ever seen. And I just met Ivan and he looked at my game and he was like, dude, do you realize you use the same tech stack as Dark Forest by accident? I was like, no. And we just randomly lined up that I'd made a full TypeScript game. And he just, yeah, within three days I was working for Dark Forest. I just quit my job and started working on it.

REPRESENTING TRANSACTION STATE

SMALL BRAIN: That's dope. That's amazing. This is related to modding, actually. Two things I find interesting. One is like UI for transactions, making people feel visually that they understand what's happening at the state of the transaction. The second thing is general UI and UX for modding.

KOOSHABA: Yeah.

SMALL BRAIN: What do you feel about that?

KOOSHABA: I'll answer the first one, the transaction states. In the beginning we had really generic transaction states on all entities [in Sky Strife]. And it turned out it was still confusing because pending states mean different things for different actions. When you're moving, you would expect your unit to move really slowly while it's pending or something. But it still indicated that I'm attempting to move. Whereas when you're attacking, you can't have that. You're not moving. You're preparing to attack. So maybe your sword is waving behind you.

SMALL BRAIN: You talk about the action queue, or whatever it was.

KOOSHABA: Yeah, that was what the action queue was attempting to do. What we ended up doing in Sky Strife is every single interaction is its own system. We are handling pending states in a completely different way everywhere. This is what traditional networking code is in traditional games. There's no one-size-fits-all solution. Every single action in one of your games is a totally different networking pipeline. It's not sexy. It's really hard. It takes forever. But that's what gamers expect at this point. They want to be diegetic. They don't want this general transaction queue. They should forget what a transaction is. Have you watched the Halo Reach network netcode video? Dude, I'll send it to you. This is insane. They got to the point where they knew the latency of every single player playing the game. This is kind of like trusted information. You can lie about your latency all day. You're supposed to be on your side. You can mod your client and do whatever. But they were also on consoles, so it's harder to do that. They knew the latency. Let's say you activated an ability that took time to charge up. After the charging time, you were invulnerable for a couple seconds. Based on the amount of latency the player had, they actually changed the charging time of the spell server side. Every single person had a completely consistent experience with the facility. The game felt amazing. You ask anyone, you feel the difference. Halo Reach feels perfect. It feels like you're sitting in the same room as people. That's the level of granularity you need with netcode. I think a lot of onchain game developers should implement regular netcode and realize how bonkers it is.

SMALL BRAIN: This is related, but tangential. Verifying that a client is running code that you think it is a problem that every mining pool has to deal with.

KOOSHABA: Really?

SMALL BRAIN:  If you're running a mining pool and I'm mining for you and Vera’s running a mining pool, what I should do is pretend to mine for both of you.

KOOSHABA: I never thought of this.

SMALL BRAIN: You split the rewards among everybody, so I should lie, etc. Each mining pool operator needs to know that the people running their software is only running their code and not running a modded version of it. They do all this crazy shit like push updates randomly and make sure that...

KOOSHABA: Wow.

SMALL BRAIN:  It's like a constant battle. The people are incentivized to make money.

ACCESSIBILITY FOR MODDERS

KOOSHABA: That's very interesting. Oh, but you also asked about modding. And, I don't know, I'm not crazy about the in-game modding. I feel like you need to build the entire game around that. If you're supplying a visual editor and a custom programming language within your game. The thing I run into with the visual editor is that you're managing the experience. Can you make a visual editor that's as open? Even 80% as open as code. It's not 2% as open as being able to write code. People have done it. Unreal Engine is leaning really far into visual programming right now. Actually, they are all in on it. They recommend you do most things in visual programming.

SMALL BRAIN: Like a node editor or something.

KOOSHABA:  Yeah. And you eject into C++ in the worst case scenario. Okay. But they put so much effort into making this usable. But the API of code is so good. It's so malleable. There's a reason everyone keeps doing it. But I really love the way that Dark Forest did it.

SMALL BRAIN: Plugins? Yeah. Did you make any Dark Forest plugins?

KOOSHABA: No, I don't exist at this point in time. I mean, it was just a text box. You throw some JavaScript in it. You hit register. And then it pops up with a DIV that was supplied for you.

And you just put whatever you want in that DIV.

SMALL BRAIN: That's crazy.

KOOSHABA: And drag it around your screen. And just from that small primitive, people created massive, massive infrastructure. Because, yeah, you just make network requests. I now have a server with a Postgres database on it. It's aggregating information from all my clan members. Very, very easily if you just knew a little bit of JavaScript. So that's kind of where I land on composability. This is another side benefit of blockchain that I feel like people don't think about. But we agreed on a programming language and an API. Yeah. Forget about decentralization. That's incredible. That we all kind of know Solidity. We know the EVM and RPCs. No other game does this because no one can agree. Every traditional game has a bonkers wacky custom API that you need to interact with. No one's going to learn that. And that just made me realize that a huge win for Interop is that we agree on when your game's shit is ordered compared to mine's. That's huge. Can you imagine two games that are running on their own systems trying to agree on when things are ordered? We just have that. I know exactly that two of my events happened and one of yours did. And the only cost is no performance. You don't need performance to make fun things. I'm super, super excited. I want to ship SkyStrife with, like you were saying, a bot kit. The last couple features I make in SkyStrife are going to be mods. That come packaged with the game.

SMALL BRAIN: Nice

KOOSHABA: I think that's a good model where it's like, oh, you've already been using this feature by playing the game. Now go inspect how it was written, and that's just your tutorial on how to write mods.

SMALL BRAIN: Yeah. Nice. What do you feel about only-client monetization?

KOOSHABA: I like it. I mean, we're not going for it, but I think it makes total sense. And it also encourages other people to join the ecosystem and make their own premium clients. I think the only monetization strategy that I've heard that is antithetical to AW is taking fees. Like in the core game.

SMALL BRAIN: Yeah.

KOOSHABA: This just doesn't make any sense, especially because we're going to be open source and someone will fork you immediately and steal all your users. I mean, maybe there's network effects, but...

SMALL BRAIN: Yeah.

KOOSHABA: So… Yeah, that I'm not a fan of. But no, this makes total sense to me. Or just even… It's like a traditional business model, like Century, the error aggregator. Dude, they make a lot of money, and it's fully open source. You could run it tomorrow. But they should run the server. Yeah, I'd pay $10 a month for them to run it, because I don't want to bother with that.

SMALL BRAIN: Dude, but I'm just really excited for Words3 to be live. And then, dude, we should do a hackathon, where we get all the AW people together for three days, and we build shit on top of it. That'd be hella fun.

To learn more about Lattice and MUD, visit our website, read our documentation, or join our Discord server

As creators of virtual worlds, our goal is to create environments that are engaging and interesting for users. This means finding a balance between designing a digital physics that allows for complex and unexpected behaviors to emerge, and ensuring that the available infrastructure can support these behaviors. To do this, we must consider three main dimensions of digital physics: time, the form of its laws, and the scope within which these laws apply.

Time

We refer to the passing of time in a virtual world as the iterative application of the world's laws upon itself. Each discrete application is an “instant” within the world's flow of time. One way to design in-world time is to have it progress continuously alongside external time. In a virtual world implemented on a blockchain, each block corresponds to a certain number of instants passing within the world, regardless of the transactions contained in the block. This is known as synced time, or “ticking”. This approach can make the world more interesting for users as it allows them to see the consequences of their actions unfold in real time. Additionally, it leads to more time passing within the world, with the world continuously updating, which in turn facilitates the emergence of interesting behaviors.

However, there are drawbacks to this approach. A larger expanse of time generally requires more computational resources, which can quickly surpass the capacity of a chain or server. It can also be difficult to implement this system on a regular blockchain, as all onchain changes must be initiated by transactions from external users.

This difficulty becomes clear when you imagine something that seems simple on the surface: an onchain game with NPCs. On mainnet Ethereum, you could define an update function that sets the position of every NPC on the game map and have an external account call it periodically to update their location. But this would be unreliable as you have no guarantee that the external account won’t be outbid for gas at a block where it’s meant to call the update. The structure of time in your game would drift as a result (see the original CryptoKitties giveBirth() function as an example of this; amid increasing gas prices onchain, Axiom Zen actually had to increase the reward given to callers of the giveBirth function to ensure that the transaction to birth a new NFT was called 256 blocks after a Kitty was bred by a user). We’ll refer to this approach using external accounts as manual ticking.

Custom rollups give us more flexibility to add the ticking functionality onchain, without the need for external accounts, and where the progression of synced time is guaranteed by the protocol. We’ll refer to this approach as automatic ticking. Automatic ticking can be implemented by writing a “tick contract” which is called by the protocol itself, rather than by an external account.

As an example, bytes worked on a proof-of-concept ticking chain built on the OP Stack which runs an automatically ticking implementation of Conway’s Game of Life (you can find a video presentation of this here). Bytes used a modified system transaction to automatically call the contract that ticks the cellular automata simulation. To fully test the limits of the chain itself, he implemented the game in two ways: as a Solidity smart contract running onchain, and as a precompile in the chain itself. The Solidity implementation maxed out the CPU after reaching a 70x70 grid at two updates per block (1 block/second, or ~10k cells/second), while the chain with a custom precompile engine maxed out at a 256x256 grid at the same rate using ~6% of the CPU (~130k cells/second).

The key phrase in the last paragraph’s final sentence is “maxed out.”  A ticking chain adds an additional layer of complexity: with each block, an increasing amount of state needs to be touched by the transaction that ticks the game of simulation. The rollup node is eventually bottlenecked by raw compute (CPU, disk IO etc.). The only solution here is higher-capacity nodes.

The alternative to synced time is unsynced time. Under this scheme, the passage of time in the world does not necessarily advance when external time does. Instead, time moves forward in response to certain events, usually user actions. Traditional board games that don't involve a timer would fall into a similar category. Unsynced time is easier to implement onchain, as it fits the model that blockchains were designed to support. However, it also sacrifices some of the features that could make the world more interesting (like automatically-moving NPCs).

An early version of WildWood, a proof-of-concept game from David Huang and cha0sg0d, illuminates this sacrifice. In this game, two players must defend their base from a siege of aggressive NPCs. In an early version of the game, NPC movements were only triggered when players themselves moved – an implementation of unsynced time which was not very realistic. After adding ticking, NPCs moved – but another issue still remained. The chain ticked once per second, which meant the game had to use optimistic updates to broadcast a player’s position on the map if they moved more than once per second. However, your teammate would not have an automatic view of your client, which meant there was a lag in player position updates. To overcome this, the team made use of MUD’s relay service, a peer-to-peer network for broadcasting a local client to the entire board. And voila, the transition from unsynced to synced time was achieved.

Closed and Open-Form Laws

Worldbuilders must also decide whether the mathematical laws governing their virtual world will follow open- or closed-form expressions. Closed-form expressions have a fixed number of operations. With open-form (or recursive) expressions, however, the number of operations grows depending on a given variable. Under open-form expressions, the future state of the world can only be calculated by repeatedly applying the laws of the world to a known state. Complex, live environments, such as Dwarf Fortress, usually fall into this category. Closed-form expressions, on the other hand, allow for any future state in a constant amount of time to be calculated from a past state and the time that has elapsed between them (assuming no future user actions alter the state), like the rate of resource extraction in Age of Empires II.

Open-form expressions can make a virtual world more interesting because, like the real world, they are not predictable. It takes increasing amounts of time and computational resources to predict the future state of the world (Conway's Game of Life implemented onchain is a good example of this: you can't compute an arbitrary state in the future because you need to run the game in time). Furthermore, unexpected macroscopic behaviors can emerge from simple microscopic interactions. In a world governed by closed-form expressions, these emergent behaviors generally occur only externally, through the actions of users (who themselves behave like open-form expressions), rather than within the physics of the world itself.

This trade-off between open- and closed-form expressions involves a similar balance as time. Closed-form expressions may decrease the potential interestingness of the world, but they also make it more computationally efficient. Closed-form expressions can be used with either synced or unsynced time. When implemented on a blockchain, they have a significant advantage over open-form expressions when time is synced. Because the cost of any length of time is constant, the world can be designed so that the onchain state is only updated when a user sends a transaction, but it is set to the state it would have been in after the time since the last update had elapsed.

The Scope of Time and Form

Consider the current standard for on-chain dynamism, a method known as a lazy update. In a lazy update, the player initiates the beginning and end of an action, but time in between is simulated instead of calculated directly. For example, a player plants an apple tree at block 1 and then later harvests the apples at block 10. Lazy update logic could be written such that the player can harvest one apple for each time unit, a total of 9 apples. This is fine for updating logic that has a closed-form function (like one apple per block), but if the farming logic changes based on inputs in between the player’s actions, this method breaks down. If at block 5, a rainstorm arrived and increased the apple growth rate, and at block 7, a plague of locusts nearly decimated the crop, it is no longer possible to calculate how many apples the player can harvest at block 10 in an efficient way without actually applying all of the events that have occurred (you wouldn’t have the computational power to catch up to the new state). Lazy updates are still very useful for cheap calculation of certain living things, such as plants with a fixed growth rate, but they fall short of a complete toolkit for a dynamic world.

In the real world, time passes everywhere, all at once, in a potentially infinite universe (with some relativistic intricacies). In virtual worlds, this is not necessarily the case.

First, the virtual world may be noticeably finite. The potential for interestingness tends to increase with size—more happens in a world made of two billion galaxies than in a world made of two atoms—but so does the computational cost. Both of these relationships are closely tied to the two trade-offs previously mentioned: the passage of time and the form of physics.

Second, time does not have to pass everywhere within the virtual world. The world can be divided into discrete regions where time passes differently, in order to reduce the computational burden of the world. For example, more sophisticated and expensive physics can be used in regions where there is user activity, while simpler physics can be used in areas where there is no activity. The downside of this approach is twofold: it can make the world seem inconsistent and lacking integrity, which limits the design space for the laws of the world and puts a burden on worldbuilders to avoid confusing users; and it also puts limits on how causality can travel within a world, as actions in one area cannot have consequences in a distant area if the space between them is frozen in time. The size of the regions where the physics apply is a major design consideration that will impact the resources needed for the world and the level of interestingness it can achieve.

To create an interesting and engaging virtual world, it is necessary to carefully balance computational efficiency with interestingness. This includes deciding on the type of time to use (synced or unsynced) and evaluating the form of the physics laws that will govern the world. The size of the regions wherein the physics apply is another important decision. By making these choices carefully, not only can worldbuilders achieve interestingness while keeping the computational burden of the world manageable, they can also create a highly fertile creative substrate for other developers to build on top of.

A version of this piece, with collaboration from cha0sg0d, originally appeared in the Autonomous Worlds book, published by 0xPARC

To learn more about Lattice and MUD, visit our website, read our documentation, or join our Discord server

Thank you to vera, ludens, biscaryn, kooshaba, and kooshaza for edits and feedback on this piece.

A few months ago, before joining Lattice, I joked to ludens that the team should publish an article called Why Your Protocol Needs Physics. Part philosophical treatise, part sales-pitch (and perhaps, part-shitpost) the piece would espouse why automated market-makers, decentralized lending markets, and L1’s and L2’s should make their protocols physics-aware by implementing notions of spatial coordinates, the speed of light, energy conservation, and other tenets of physics into their base smart contracts and architecture.

The comment was inspired by a remark ludens made to me (and has also expressed on podcasts and in talks) about the computational limits of blockchains today, and their irreconcilability with universal physics. Ethereum has a single dimension: time, and as a result, EVM-compatible chains process transactions sequentially. The universe has four dimensions: three-dimensional Euclidean space (x,y,z), and time, which means events happen in parallel. Blockchains events are ordered, and the rate of information propagation is determined by the rate at which validators agree on ordering. Universe events are subject to relativity and the rate of information propagation is bounded only by the speed of light.

Could we emulate this phenomenon of universal physics and relativity by “giving” contracts coordinates onchain, and limiting interaction with specific contracts to conscribed locations? This would eliminate notions of global state (because information travels at the speed of light), and essentially parallelize the EVM by cheating how state propagates in the network. If Alice trades with Bob in one region of the universe, it has no impact on whether Charlie can trade with Dave a million miles away. The vanilla EVM needs to order this transaction regardless, but physics-enforced smart contracts would not, because they would have a notion of spatial coordinates. At the network level, you’d no longer need global block producers, just local ones that eventually reconcile transactions on a global scale.

Other phenomena could be unlocked by spatial coordinates as well – not just hacky implementations of EVM parallelization. Such an example can be found in designs for zkDungeon, the game that predated MUD, Lattice’s operating system for onchain applications (as well as OPCraft and Sky Strife, our first two games built on MUD). zkDungeon was a cross between a board game and an onchain battle royale, where players could build on and mine territory on a map, summon creatures, and trade resources like gold and souls.

Like the hypothetical EVM described above, contracts had a defined coordinate on the map. Unlike the hypothetical EVM, the coordinates weren’t enforced for parallelization – they were there to encourage emergent behavior, like players building trade routes, maritime republics, and special economic zones, all of which would emerge from the 'physical', locational constraints of AMMs. With contract-locality, we could insert market inefficiencies into the game, and incentivize new enterprising player behavior to overcome them.

Something simple – like defining contract coordinates in metric space – can have dramatic consequences, impacting everything from creating new kinds of mercenary player behavior, to helping the EVM transition from the serial computer it is today, to a more performant machine. We’ll call these simple stipulations “digital physics.” I like to think of digital physics as fundamental laws of an onchain system that have the potential for resonance across the entire stack – from the application layer to the infrastructure layer.

There are other examples of digital physics in well-known onchain games. In Dark Forest, players had options for how to uncover the game’s fog-of-war map. They could use Dark Forest’s standard in-browser single-threaded Javascript miner to compute hashes that would reveal the map. Or they could devote more CPU cores to the effort, by using a simple drop-down module. There were also custom miners written in Rust which could uncover the map even faster, or if players wanted to outsource the mining effort entirely, they could use a remote miner that operated on a server or Raspberry Pi. One player drew attention for implementing this on a 96-core AWS instance (which probably cost somewhere in the range of $3.00 an hour).

Such behavior might seem irrational if you forget about other plugins that players built for Dark Forest. As a game that hosted dozens of permissionless plugins, there were also markets where players could buy and sell artifacts, planets, or even coordinates of the planets themselves (in a fog-of-war world with incomplete information, the information itself can become the most valuable commodity). Suddenly, mining the Dark Forest universe is perfectly rational economic behavior – akin to mining for any kind of valuable resource in the physical world.

What you choose to accept as a valid input has dramatic impacts, and directly guides a system’s digital physics. Imagine Dark Forest with a static rate of map exploration, with no way for players to customize how quickly they wanted to uncover the map. This would make the total universe size in Dark Forest a function of cumulative player count and time spent playing, rather than a function of those two factors, plus cumulative resources expended mining. The game between players would be simpler: the strongest players would be ones that spent more time in-game, or spent more real-world money to buy map coordinates. The version of Dark Forest that actually exists permits for a third variable, based on the compute resources a player is willing to expend to uncover the universe. In other words, by having hash rate as an input, users were given more control over how large they wanted the universe to become, and increased the likelihood for more dynamic behavior down the line.

Autonomous worlds are the ideal petri dishes for digital physics, because they allow players to create consequences and points of absorption for a game’s emergent systems. There are no guidelines on what “strong” digital physics looks like – this will depend on the onchain world you are devising. Not every world needs a limit on the actions that can be performed within the confines of a grid, or a universe that expands at the same pace as your hashrate. What matters the most with digital physics is the resonance it can create.

At Lattice, we’ve been exploring these concepts, and want to share what we’ve discovered. Today, we’re announcing the launch of The New World, a series on Mirror that we’ll be using to probe into onchain life. For the next few weeks, during Season One, we’ll be exploring Digital Physics in all of its forms. We’ll study tick rates and the notion of onchain time. We will investigate anthropocentric digital physics, and the kind of digital physics that might be more hospitable to AI’s and aliens. We will itemize current EVM-compatible verbs (spoiler: there’s only one), and propose ways for Ethereum to support more verbs (spoiler: we can do this using MUD). Along the way, we hope to finesse our understanding of digital physics, and how to build autonomous worlds with the same degree of resilient, enduring, immutable physics that exists in the universe.

We believe that autonomous worlds are emerging from primordial state. And like the universe we inhabit, they will require a deep investigation that’s complementary to product-level experimentation and technical documentation. We would like to catalog the thoughts, intuitions, mistakes, and wisdom we’ve acquired while building autonomous worlds, to make the terrain more accessible for anyone exploring the space with us.

If this sounds interesting to you, stay tuned and subscribe to our Mirror. If you’d like to contribute, email me at vera@lattice.xyz – we’ll be accepting submissions from developers and researchers who are interested in these questions. To get you started, we’ve brainstormed a list of words and concepts that might be helpful as you explore.

Digital Physics: Conservation Of Energy, Lindy, Modifying The Execution Layer, Stephen Wolfram’s A New Kind of Science, Jump Crypto Is Battling The Speed Of Light, Hidden Information Games, Onchain Cellular Automata, Entropy vs Persistence, The Anthropic Principle, MEV Is Digital Physics, Quantum Mechanics, Things That Should Never Be Rewritten In Rust, Concrete, Your Blockchain’s State Transition Function Is Its Original Sin, Giving Ethereum Eyes, Smart Contracts Are Fascist

To learn more about Lattice and MUD, visit our website, read our documentation, or join our Discord server. *

*Thank you to ludens and biscaryn for feedback and edits on this post