edited by vera and Emerson, cover image by turbo

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