What happened to Isaac?
The first part of a 3-part letter
In fall 2021, we observed that the blockchain programming environment presents unique affordances that were left unexplored. We have been dedicated to exploring new application paradigms around those affordances since the birth of the company.
But… whew! It was 30 weeks ago that we published our last letter. What happened? Let us go over briefly what happened and the key findings upfront.
Overview of what happened
Solve2Mint 2.0 (S2M2) presented 50 onchain puzzles to serve as the challenge to getting entry ticket for Isaac public alpha. All 50 puzzles were solved within 48 hours after launch.
Isaac alpha had 13 unique players actively playing in the two alpha rounds. Both round suffered lack of meaningful civilization progress - both ended in Ev, the planet, crashing into Boyuk, one of the three suns! - due to various factors: lack of coordination-assisting UI/mechanics, lack of more intuitive graphics, low TPS on testnet, lack of node robustness which leads to frontend-backend synchronization issues etc.
Isaac has been shelved after the two alpha rounds! We still love the three-body problem narrative but have moved on to smaller projects to allow for rapid iterations on core game loop.
Key findings
It is important to hit ground-zero and dogfood/playtest the core game loop with real players as soon as possible.
Effective iteration is equal to “number of iterations” times “progress made between iterations.” Isaac’s large complex and coupled codebase made iteration difficult.
Solve2Mint 2.0 (S2M2)
Before starting Isaac Alpha, we launched Solve2Mint 2.0 (S2M2), an onchain puzzle, where every solution submission is verified computationally against every rule of the puzzle on the blockchain, as a way to qualify players for participating in Alpha - see this tweet for details. Assuming no sybil, which may very well be an overly optimistic assumption, S2M2 qualified 50 unique players for Isaac. All 50 distinct puzzles were solved less than 48 hours after the announcement tweet - we were shocked by your appetite!
^this shows an invalid solution for puzzle #4 😃. To understand the rules of the puzzle, players needed to dive into contract source code and read about the rules in code comments (not necessarily understand the contract code). We believed this helped us attract onchain enthusiasts for Isaac play-testing.
Isaac Alpha
Then came Isaac Alpha. Two Alpha rounds happened, totaling around 13 unique players. Below are screenshots of Isaac UI during Alpha 1 and Alpha 2.
^UI for Alpha 1. Shades of green were used to visualize solar exposure value for each sides of Ev, the protagonist planet in Isaac trisolar system. Aquamarine-green paths are wires, which connect energy-generating devices to energy-consuming devices. Gray paths are belts, which connect resource-generating devices to resource-consuming devices. Large creamy-yellow squares are Factories, where players can deposit energy via wires and resource via belts, and craft the full spectrum of devices. Large purple squares are Engines, which provide a reverse momentum kick to Ev when launched.
^UI for Alpha 2. We did a color revamp to brighten up the entire UI - mostly relying on the artistic eyes of zink#4134 !
^Universe view of Isaac. Ev, the tiny cubic planet that self-spins and revolves around the three gigantic suns (Boyuk, Orta, Balaca), is the protagonist. The dotted line protruding from Ev helps players orient the faces of Ev (the thick/thin dotted lines were normal vectors of face0/face2 respectively). Face orientation is important for the purpose of aiming and launching Engines in order to influence the trajectory of Ev away from destruction.
^UI for Station view (where players queue up in lobby and get dispatched into the game). Station view includes past & current civilization replay. Due to lack of timely coordination (exacerbated by players playing from different time zones and utter lack of UI/mechanics assistance), all the civilizations in Alpha1 and Alpha2 ended in the same fate - Ev crashing into Boyuk at block height 574 after birth. Note that we turned off nondeterminism for Alpha, so given the lack of trajectory influence from player’s Engines (more precisely, all Engine launches exerted only negligible influences), all trajectories during Alpha looked the same.
Pain
Very quickly, players reported pain. The pain of UI not responsive enough to show pending builds across players and across browser tab reloads; the pain of built devices not showing up on the map potentially due to StarkNet full node unreliability and backend synchronization issue. Etc. More importantly, the game didn’t progress very meaningfully for both rounds. There was an utter lack of UI to assist player coordination, which is precisely the core of the game mechanics - for example, there was a lack of decision delegation, so in order to coordinate an Engine launch of all player-built Engines, their owners had to all connect to the game and launch their individual Engine; there was also a lack of in-client messaging tool, forcing players to discuss and coordinate on Discord and hop between windows. Players were anons that played from different time zones, worsening the problem.
Perhaps most crucially, we realized the core game mechanics were very inaccessible - for example, abstract colored shapes are not particularly resonating with most people!! - and simply not engaging. Isaac was fortunate to have onchain game enthusiasts believe in it and overcome the painful abstractions just to help test the water, yet if we were honest, the core loop was simply not engaging. It lacked iterations.
Here we provide a couple observations why the core loop was not engaging:
Linearity is predictable, and predictability is not engaging. The progression of devices was too linear - build harvester, then build refinery, then build more power generators, then build more engines. It is too predictable to sustain engagement.
Dependence of the TPS of underlying blockchain hurts engagement. Starknet testnet at its best had a block time of 2 minutes (recently its block time frequently surpasses 1 hour!). This makes the game not responsive at all - “Let me build device A and device B on the map. Hmm I need to wait for 3 minutes. I want to connect them via wires C. Hmm I need to wait for another 3 minutes. But I already had an entire design involving A+B+C+D+E+F+G+H in my mind! I need to spend 20 minutes in front of my screen to make this happen. Give me a break!” Granted, transaction cart could have alleviated this issue - the ability to queue up a list of actions and send them to StarkNet as one bundled transaction. We did not get to implement it because the frontend code base was too fragile and un-refactored to be mingled with in a timely manner as we were responding to faults happening at other places (e.g. backend instability).
Which brought us to the core insight we gained from the Isaac experiment: effective iteration is the key factor for us.
Effective iteration
= number of iterations x progress made between iterations Particularly, we need to maximize effective iteration with players. Isaac underwent 2 - only 2! - iterations with players before discovering the fatal weakness in its core loop. Why stopped there? Because:
Large un-refactored code base - particularly the backend & frontend - before Alpha began, which means the code base was fragile. It was difficult to add features.
Large coupled systems. Every change to the core mechanics had to go through changes in Cairo code base, testing of Cairo code base, updates in backend to communicate new information from StarkNet to frontend, and updates in frontend to reflect the new mechanics. This made iteration slow and painful.
Without iterations, Isaac was lacking in engaging elements. In short, Isaac was conceived in March 2021, built from garage in about 4 months, underwent two short-lived Alpha rounds, and encountered an impasse. It had to be halted before we lost too much morale.
We want to note that the pain was precisely the substance that pushed us forward. The pain was the signal that pointed towards the right direction when we listened to it carefully. The pain is the stressor - gg wrote more about this here.
Despite the pain, it was a wild run, inspiring to us, and heartwarming as we got help in development and play-testing! We are thankful for Ranyah Al-Gubani’s memorable design for Isaac cover art and various art assets. We want to thank Zink (Discord handle: zink#4134) for his unparalleled enthusiasm and devotion in getting Isaac’s frontend off the ground. And we want to thank the playtesters who entrusted us and endured the roughness of Isaac with us (in alphabetical order of Discord handle):
broody#5590
dobeck#8048
dham#4523
Dreamback#2095
just-fred#9182
Lime#5577
neoTINS#5121
script-money#7183
sortoel#1259
sortw#3186
tonz#2988
wontonbeing#3386
zink#4134