Shoshin

Origin

Shoshin came from a long winding road of soul searching and experimentations.

October 2021, we knew rich digital realities that are strongly decentralized will be the future, and we wanted to be the shepherd of that future. Our first foray into verifiable computation involved creating physics simulations, a Q-learning agent, and a tiny deep neural network all running in the CairoVM.

Spring of 2022, we conceived of Shoshin, an asynchronous 2-dimensional fighting game that runs in the CairoVM, where player plays by designing dynamic, situational behaviors that combat other player-created behaviors. It was incredibly exciting for us, but its prospect seemed so challenging and multi-faceted that we decided to put this project on the shelf and move on.

Summer of 2022, we made Isaac, a fully onchain game that is the combination of multiplayer factorio and a 3-body physics problem. Isaac suffered. It suffered in many ways - it wasn’t the right game design pattern for blockchain as medium, it has a game loop that requires successful coordination among strangers across timezones to be fun, and our team was inexperienced in the way we managed complexity and execution.

Fall of 2022, we made Mumu, a simulation game that is asynchronous, meaning you can experience the game loop without interacting with the blockchain at all, while the game loop runs verifiably in the CairoVM. It ran beautifully. Our ambitious grew.

We decided to pick up Shoshin. We decided that we want to knock Shoshin out of the park. Today we are extremely excited to be here and present you Shoshin.

What is Shoshin?

As a game, Shoshin resembles Street Fighter where 2 characters are put in a 2d box to fight each other. Unlike Street Fighter, Shoshin is primarily asynchronous: you play not by smashing your keyboard or console, but by designing your fighting strategy. What is a strategy? A strategy specifies dynamic, situational behavior: a strategy is what you would do in different situations.

As a pattern, Shoshin is asynchronous. The entire game loop of Shoshin is written in Cairo 0 and runs in CairoVM, which is emulated by lambdaclass’s cairo-rs and wasmified so that it runs in your browser. You can experience Shoshin, the exact faithful game loop, entirely in your browser without touching the blockchain.

As a architecture, Shoshin is a computer. Under the hood, the strategies created by players are represented as finite state machines, and the transition functions are represented by binary expression trees.

As a milestone of this ecosystem, Shoshin pushes what is possible with CairoVM. Because, we are obsessed with the future of verifiable computation. The making of Shoshin is how we express that obsession.

Finally, as a mission, Shoshin attacks the Photoshop of AI problem. We believed that if fully onchain game were to become a genre of great impact, it must tackle real hard problems in game design head-on. If blockchain were to prove itself as a fundamentally new medium for game design, we must not shy away from challenges. We decided to fight the Photoshop of AI problem, a problem formulated by Chris Hecker in his 2008 GDC talk. Game AI, or autonomous behaviors that are dynamic, situational, and interactive, make game worlds feel alive. But the designing of game AI has been the privilege of AI programmers. The problem is: how do we design an interface and a system of abstractions such that non programmers can create rich game AI, in a same way that people not trained in computer graphics and signal processing can use Photoshop to create amazing graphics?

Methodology

Photoshop of AI is a hard problem. Some projects tackle this problem by throwing machine learning at it. Yet, machine learning is statistical in nature, and a trained model is considered a black box, meaning player has no direct visibility nor edit-ability of the resulting behavior. Shoshin takes a different approach.

With Shoshin, we want to give player direct control of every bit of their fighting strategy. On top of that, we want Shoshin to be enjoyed by people who have never programmed a computer in their life. We need to give them a palatable language for describing rich dynamic situational behavior. There is a concept in theoretical computer science called Kolmogorov Complexity. The Kolmogorov complexity of an object, such as a piece of text, is the size of the shortest computer program in a predetermined computer language that produces that object as output. For example, the Kolmogorov complexity of a binary sort algorithm written in the BrainFuck language is sky high. With Javascript? The complexity becomes substantially lower. We borrow this concept and say: we want to design a language for player to create Shoshin strategies with Kolmogorov Complexity as low as possible.

We are also aware that we must not be tempted by the desire to faithfully replicate the mechanics of the popular fighting games. Street Fighter, Tekken, Guilty Gear, Dragon Ball FighterZ, and Super Smash Bros. However brilliant their game mechanics are, they were born from design paths that optimized for real time play. Shoshin is not real time play. It’s true that we started from the familiar fighting game mechanics, but we need to find our way.

We derived a methodology that guided our game design process. It is a seesaw between two polars: one polar is the reduction of Kolmogorov Complexity, and the other polar is increasing game depth. Two months ago we overhauled the Editor Interface, resulting in a massive reduction in K complexity. One month ago, we took pleasure in expanding the movesets of the characters and enabling air juggling, character specials, taunts, and more. There is a long long way to go, and we are thrilled to continue down this path.

Credits

This project would not have been possible without our amazing team and our collaborators. Thank you all, for the love and dedication you put into Shoshin.

Onward

If interested, join our Discord. Let’s evolve Shoshin together. Thank you!