edited by vera

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. 

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.

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?

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.

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.

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.

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.

edited by vera

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. 

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.

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?

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.

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.

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.

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.