Composability allows us to build significantly more with less.

While composability, modding, and extendability are often discussed as core reasons for building fully onchain games and worlds, there has been very little real-time experimentation around those properties.

Is fully onchain worth it? Do we need to architect games to be composable from the very start, or is pure emergence enough? Can we leverage composability to create compelling net new entertainment systems?

‘Modding worlds’ is a series dedicated to exploring this. For the first edition, we’ll be walking through our recent internal hackathon project: Hexcraft, a MOBA we attempted to build within Downstream – a fully onchain game created by Playmint.

What is Downstream and why is it special?

Downstream is a hex grid world with three key resources (red goo, blue goo, green goo) that represent the properties of attack, defense, and life. These atomic units make up everything else in the game and with these resources, you can construct buildings and craft items that carry over properties made up of their underlying ingredients. By breaking the game down into three core atomic units, we’re able to create a framework for gameplay that enables an infinite number of permutable lego building blocks to exist.

Rather than being opinionated from the start about what gameplay should look like, Playmint has built a composable system first, and only then after, have started to actively explore what experiences can be built around it – being incredibly cautious about how game design decisions such as global play objectives, economic design, and cartography implicate composability.

As such, Downstream, at the time of writing this post, did not yet have an overarching player objective nor hard rules around cartography or economic design. However, we did have a core set of physics to build around: player movement, properties system (attack, defense, life), combat system, and item/building construction system.

Ducks vs. Burgers

An example of a game the team had designed around these initial physics was Ducks vs. Burgers:  a team-based game focused on two sides constructing and attacking each other’s buildings. The team with the highest number of buildings remaining within a time limit would win. A video breakdown can be found below:

Based on what was available to us, we looked to build a minimally coherent game that strived to be as fun and entertaining as possible. Composability doesn’t matter if you’re not creating an experience that is compelling to a player audience. This is a consideration we took pretty seriously in our efforts to design something even, despite only having two days to work on something that we could ship. And as a result, Hexcraft was born.

Hexcraft v0.1

Hexcraft is a MOBA built on top of Downstream:

• Players register into two teams (red and blue)

• The first team to destroy the other team’s base wins

• Players have 5 different classes to pick from (trade-offs in attack, defense and life)

• Player movement speed across the map is dependent on destroying blockers that obstruct movement (the speed of destroying blockers are based on player stats)

Basics around gameplay

Hexcraft looked to iterate on Ducks vs. Burgers by instead focusing the game around the attacking, defending, and destruction of each respective base. We felt like this was a far more commonly understood player game loop. From playing Ducks vs. Burgers ourselves, we realized that building construction was potentially too complicated to base the game around. We’ve decided to let building and item construction emerge naturally as a meta within the game as players better understand the core mechanics of the world.

Team registration and base destruction win condition

Naturally, in the absence of a defined player objective and means of organizing players into teams, we built a system for doing so. We implemented a system of two buildings:

1. Team registration office: Allowed players to register themselves into two teams

2. Bases: Once destroyed, resets the teams assigned to players

This system forms the basis of Hexcraft but realistically could also be used as a building block for other games revolving around the same team and win conditions. In a future version of this system, ideally the win condition can be designed to be completely arbitrary to any other in-game event as players or a game maker desires.

Character class system

We felt like it would have been horribly boring if every player had the same attack, defense, and life! So, we built a character class system to allow players to pick a unique class which would give them specific trade-offs in each respective stat (attack, defense, life).

This system consisted of 5 buildings that allowed players to craft a corresponding item with goo that represented the stat bonuses of that class. We designed some game balancing restrictions by building smart contracts so that each player could only craft a class item if they didn’t have any other crafted item in their inventory (to enforce a single class per game).

Classes and their corresponding buildings/items (attack/defense/life):

• Fighter’s Arena produced: Greatsword of Dawn (35,10,10)

• Wizards Maze produced: Magical Glock 19 (50,0,0)

• Paladin’s Church produced: Strong Holy Kiteshield (10/40/40)

• Cleric’s Tent produced: Friendly Companion (0/100/50)

• Bard Concert Hall produced: Sharp Violin (25, 25, 50)

The goal of this class system was to introduce decision tree complexity and to generate a natural meta towards team coordination around classes. Each class naturally influences movement ability (based on player ability to destroy blockers on the map in order to move) and speed and resource availability for each team (different classes consume up more goo than others). A future version of this class system could naturally allow anyone to create any permutable class that can be played within the game as long as they’re able to craft it based on the initial starting resources available for each team.

An interesting idea is that even though this class system was built for a MOBA-like environment, you could take the system as a set of player constraints that can be played within a completely unregulated environment. This would become the equivalent of playing the game on “hard”, simulating a PvE situation, potentially with players who are opting into the system of constraints sharing a single shared cooperative goal and competing against other players outside of the system of constraints (think left for dead).

Map design and player movement

Due to the limitations in scope, we were not able to build any mods around player movement or spawning, which meant that we needed to add a spectator ring around the map to allow players to self-organize themselves into the right starting player positions. For now, players need to abide by socially enforced rules around when to start a game, splitting up into equal teams, and other aspects to ensure fairness in a game. You can think of this version of Hexcraft as a cardboard prototype equivalent that requires players to self-shuffle and deal cards to play.

Shelved ideas that we didn’t get to implement…

Sound packs

Within Downstream, we wanted to add a little juice to the micro-interactions of gameplay and designed a third-party sound pack system for the game. In order to activate the sound pack, a player would only just need to open up our soundpack webpage via another tab while playing the game. This was technically possible within the interface of Downstream via embedded javascript within the buildings, but these only ran periodically rather than in real time (an easy fix). This would be the first step towards an ecosystem of mods that revolves around sound:

1. Allow players to trade NFTs that represented rare, unique soundtracks (token-gated sound design)

2. Allow players or creators to create entire sound packs that are then unlocked by paying for them via ETH or in-game tokens

3. Allow players to host permissionless and uncensored voice channels during games

UGC does not necessarily need to exist fully onchain, and sound design is an area we feel that is heavily overlooked as a meaningful way to add texture and substance to a game.

XP system

Since there was no sense of narrative and player progression that existed, we wanted to build a way to generate lore and history for players. There were several ways to go about this:

1. Allow players to mint NFTs of the games that they played. Each mint would include generative lore and data influenced by the class the player played during the game, whether their team won, team size and battle history within the game, and more. Not only does this serve as a reward for playing the game, but it could also be onchain data that could interoperate with other games that could compose with –  similar to Loot, except rather than a predefined total supply, they are issued via gameplay. These could easily be visualized by an external third-party site as needed. These could also be issued into a player’s ERC-6551 token bound account.

2. Fair launch issuance of ERC-20 specific to just Hexcraft: a means of bootstrapping a microeconomy nested within the broader Downstream system. You can think of this as Roblox but without economic silos between games.

3. Create an external site that visualizes an RPG-like interface of your own hero/character whereby players can opt into a progression and XP system that is entirely third party.

Reflections and thoughts

Live Demo Gameplay Footage (No commentary/audio):

Designing around the open-endedness

When we initially sat down to design what we could build during the duration of the hackathon, it wasn’t immediately clear what we would build. The Ducks vs. Burgers example was immensely helpful as a starting point. Only after we started to design Hexcraft did we start to find the lack of strong, opinionated game design more of a blessing than a curse, as it allowed for significantly greater creative freedom to what could be built.

Downstream in its current state has intentionally taken an extreme position with regards to holding back on clear game design decisions for the time being. While there’s a clear need to balance immediate coherence while allowing an unrestricted field of possible gameplay comprehension, there’s clearly a sense of freedom afforded by optimizing for the latter.

Iteration speed

There was immense value in taking the burden of the front-end visual experience away from the design of Hexcraft, as it constrained our area of focus towards extending core mechanics of how our world systems worked. This was especially important being novice game designers as our efforts were allowed to be focused on game design and game mechanics.

Through the process of designing and building Hexcraft, it was apparent that Downstream, while not yet perfect, was on the path of lowering the barrier to entry for many potential new game designers. Creatives generally aren’t necessarily the best engineers themselves, and the majority will often opt for the path of least resistance to get their vision off the ground in the beginning. A key determining factor for how well a team can propagate UGC will entirely depend on the speed of iteration. An example of this can be seen within crypto with memecoins, nfts, liquidity pools, and DAOs – where 0 technical capabilities are required to leverage each respective set of building blocks to coordinate social and economic value. If such basic building blocks have already enabled such social and cultural impact, what could emerge once more sophisticated structures are able to be built and released in an equivalent manner?

While yes, “build worlds that have never existed before” should be the end vision for building fully onchain worlds, when building with Downstream, it was clearer that the more interim goal was to simply build games that had never existed within the context of crypto before. And if we’re able to make gradual ground on this more tangible objective, we might just end up achieving the former. And when you zoom out on this, Downstream starts to look more like a sandbox for economic value and incentive design where players navigate those rules through the controls of a traditional game. If Roblox allowed for rapid iteration of core 3D gameplay, then it's likely that Downstream is well positioned as a system that allows for rapid iteration of economic design.

Collaborate with us

We believe that there is a depth of open possibilities that are made possible by creating games that are deployed fully onchain, and we have never been more excited to contribute to this design space.

We are always looking to playtest new games and are actively investing in teams in this space, especially teams focused on pushing the boundaries of game design.

• Watch out for Hexcraft: we’ll be starting public playtest sessions

• If you are working on a project in the autonomous worlds design space, do not hesitate to reach out to us via twitter, seam or email.