What happened after-after Isaac?
The final part of a 3-part letter
What happened after we shelved Shoshin temporarily?
We have been iterating on MuMu!
Overview of what happened
MuMu started with direct inspiration from Opus Magnum (Zachtronics), engaged in playtests in its first week, and have undergone two iterations publicly at the time of writing.
Esotere, a proposal for an onchain operating system, was conceptualized to provide further abstractions (indefinite program via process; file system; drivers to mount external chains; self-hosted frontend etc) and integrations for blockchain programming environment, but was deprioritized at the moment.
Key findings
Tackle both depth and accessibility. A world without depth is not worth staying and exploring. A world without accessibility will have few visitors and leave itself much unexplored.
MuMu seems to represent a structure that is one dimension higher than Loot, making it a robust and fertile ground for worlding!
MuMu
From the get-go, we wanted MuMu (changed from MovyMovy at the suggestion of Loaf from Realms) to be the minimal game loop that allows rapid effective iterations. It needs to be interesting to watch. It needs to pique curiosity. It needs to hit the ground running with real players as fast as possible. And, it needs to be susceptible to becoming deep.
MuMu, in its current presentation, is a puzzle game. It is rooted in a world where substances can transform, like alchemy, into other substances when the condition is right. The conditions are described by the formulas:
^There are 8 formulas in MuMu Season 2 (the most recent season).
The goal of the puzzle is to take wood and produce as much fire as possible. Player is given a blank 10-by-10 grid-based canvas. Formulas can be placed on the canvas. And little “robots” (called “mechs”; later we changed it to “spirits”) can be placed and programmed on the canvas to serve as little workers - they can pick substance up, move around, and put substance down. And when the correct substances are placed at the input grids of a formula, the formula is activated automatically, transforming those substances into the formula’s product substance! With clever placement of formulas, and clever programming for the robots, player can transform wood into fire!
^Players can add robots (”mechs”) and program them with the available instructions.
Note that to place a new formula on the canvas has a cost. To place a new robot on the canvas also has a cost. Finally, each instruction, when executed by a robot, also incurs cost dynamically. The player is thus tasked with an optimization problem: to transform wood into fire, maximize the throughput, and minimize the cost.
^A snapshot of a top-ranking solution on the second day of Season 2 from just-fred#9182. UI allows playback of fully simulated frames (150 frames in Season 2) that visualize where the robots and substances are at any frame. Information panels on the right display statistics of the solution.
^At the time of writing, the top-ranking solution for Season 2 from CometShock#4420 leverages the newly introduced formulas to build a well-timed production line that produces 39 🔥 in 150 frames.
To see current and past seasons in action:
Season 2: https://mu-mu.netlify.app
Season 1: https://mu-mu-s1.netlify.app
Season 0: https://mu-mu-s0.netlify.app
Depth and Accessibility
In the process of building MuMu, we identified two complementary factors to focus on:
Depth
Accessibility
Depth can be understood as the size of the strategy space to solve increasingly difficult problems. For example, the number of formulas went from 4 to 8 in MuMu Season 2, allowing more approaches to problem-solving.
Accessibility means how relatable the mechanics are and how friendly the game UI is for engaging those mechanics. For MuMu, the UI layout went from top-down to panelized in Season 2 so that players do not need to scroll up and down the page between editor and simulation. There is still enormous room for improvement on the accessibility front!
We realize that we must bounce back and forth between depth and accessibility. Deep mechanics with low accessibility brings high frustration and friction, preventing many potential players from even attempting to play. Great accessibility without depth means the engagement is short-lived. We must balance both. In this lens, the change from MuMu Season 0 to Season 1 (Cairo-side optimization allowing for much more complex solutions to be simulated) is depth improvement. Season 1 to Season 2 (new formulas, new instruction, and new UI) is 90% depth improvement and 10% accessibility improvement. We are prioritizing accessibility improvement now.
Why we are excited about MuMu
There is a lot of excitement between the lines here! We must explain why we are uniquely excited about MuMu:
Worlding: It serves as a fertile ground for worlding (Emissary's Guide To Worlding by Ian Cheng), because MuMu formulas are the chemistry of a world to be imagined. To use the word of Justin Glibert: MuMu is artificial chemistry!
Structure: MuMu provides more structure than Loot - MuMu is one dimension higher. If Loot presents an universe of nouns (scalars!), MuMu sprouts an universe of verbs (vectors!) - both in terms of the direct relation between substances (via formulas) and the indirect relation between substances (via player solutions that transform wood into fire utilizing multiple formulas, for example). Having more structure means a more robust foundation for worlds to be built on top of it.
Visual programming: MuMu provides visual programming. Every instruction has clear visual implication (how the mech visually behaves on the grids), unlike the abstract “let z = x * 2” in symbolic programming. Visual programming is potentially much more intuitive and relatable to most players compared to symbolic programming.
Decoupled codebase: MuMu has well-decoupled architecture between frontend, backend, and onchain simulator logic. This leads to relatively robust codebase that allows rapid iterations.
Player Commentary
Finally, we want to share the commentary from MuMu’s most dedicated players: just-fred#9182 & CometShock#4420:
Clearly, MuMu is already a pretty engaging engineering experience for players with engineering background and interest. As stated above, our focus in the short term is to prioritize accessibility improvement so that we spread the joy of MuMu to many more people! Starting next January, we will also be hosting Twitter Spaces to openly discuss progress and ideas for MuMu.
For now, join MuMu’s Discord channel to jam with us. See you there!
Esotere
We observe the space and see many bright teams tackling infrastructure-level problems, yet relatively rare effort is dedicated to exploring genuinely new application paradigms. Our dedication is toward that exploration. Despite the focus on the application side, we want to be conscious of the limitation imposed by existing platforms and tooling, and always be entertaining the thought “what tools can we build to boost productivity both internally and externally?” Note: internal productivity means the velocity of shipping for individual teams; external productivity means enabling the connection (thus emergent utility) among applications shipped by multiple teams.
Throughout our experience in Isaac and Shoshin, we noticed that blockchain programmers have been working on the world computer as a bare metal CPU, which leads to many issues:
abstraction leaks (being taken for granted!)
lacking additional structure, such as the ability to run compute across blocks, instead of being limited by single-block atomicity
lacking visual representation (blockchain explorers seem like tools for system admins, not the windows through which regular programmers should be interacting with a computer)
lacking reuse of programs already onchain (state bloat at exorbitant level but is externality to most devs so very few ever cares; lacking reuse also means productivity lost and losing the ability to retroactive distribute credit and value)
For details, you can review our talk at STARKVietnam 2022:
Side note: we want to applaud Lattice, whose work on mud.dev has provided additional structure for both building scalable game systems and synchronizing data across the chain-client boundary!
We think the world computer needs an operating system. This operating system would introduce more structure while wrapping those structure inside accessible abstractions, boosting programmer relatability and productivity. Furthermore, this operating system should be strongly decentralized - via users self-hosting the frontend at the very least.
Similar to how most mobile applications are built either on Android or iOS (no mobile app is announced being shipped with a particular VM architecture or CPU standard), we think the world computer deserves its own operating system.
We hastily named our concept Esotere, coming from the word esoteric - it is an esoteric concept even for us!
Here is a brief summary of the 4 core components of Esotere that we imagined:
Native file system (FS) + version control system (VCS)
process+ asynchronous programming e.g.await()Inter-chain mounting to FS and subject to
await()Indexer &/ light client + GUI as Client running on local machine boot from the rollup
Here is a brief overview diagram of the Esotere concept:
And here is the link to Esotere’s notion doc for those who want to dig deeper: https://strong-beluga-f0d.notion.site/Esotere-e3608430d3db48d18e2d4ca6e79cf57b
As always, we welcome any critique and discussion. And as a final emphasis, we are dedicated to leading with application. We build tools insofar as they help us build better experiences that are genuinely exciting and native to the blockchain computing environment. For this reason, we deprioritized Esotere, but instinct tells us part of the concept - particularly allowing process to sustain compute across time (blocks), and file system considerations - will be uniquely useful for MuMu. Hence, MuMu serves as the concrete context for us to reason about these infrastructure-level problems.