Primitive
Atomic Object Systems
A Self-balancing Mechanic for Composable Object Crafting
Authors:
opnpc
Published:
May 14, 2024
Collaborators:
Paul Woodbridge, Chris Farmiloe, and the Playmint team

The Atomic Object System is a design pattern that allows for the creation of novel and composable objects while preserving the overall balance of a world. Each object in the world is made up of a small set of fundamental particles, with its qualities or stats inherited from these constituent atoms. In contrast to conventional game worlds where objects are prescribed by designers, inhabitants of these worlds can create completely new objects with novel properties.

Motivation

A prescribed set of objects is common in game worlds because designers need to prioritise player enjoyment over player autonomy. Providing a reliably fun experience for players requires balancing various systems to ensure they have access to the right objects at the right time. Powerful or valuable objects are often made costly to attain or gated behind tech trees and upgrade paths to prevent unbalanced gameplay. Game designers painstakingly tune these systems to optimise the player experience and maintain a sense of challenge and reward.

This is particularly difficult in multiplayer games. A single-player game can calibrate to the player's individual progress and skill, quietly bending the laws of that world, but a multiplayer game cannot easily bend reality for one player without frustrating another. A shared space where players interact across power levels needs something closer to a functioning economy, and this has historically been very difficult to achieve. Giving players the ability to create new objects without the right constraints could result in a flood of items that "break" the game for others, if not themselves.

Part of the appeal of Autonomous Worlds is that inhabitants can freely design, build, and engineer completely new things together. To make this possible, we cannot rely on game designers to carefully refine mechanics as new objects are added to the world. Manually balancing systems is expensive, and the cost of testing interactions between objects increases exponentially as new objects are added to a world. Instead, Autonomous Worlds lean on clear diegetic rules, or digital physics, that constrain what is physically possible within a world and define the conditions under which it can expand. A good digital physics approach should be able to offer a wide range of possible objects without each object needing to be manually balanced by game designers.

The "Atomic Object System" is such a form of digital physics that provides an approachable and self-balancing composability mechanic. Players are free to invent new objects of whatever power level they desire, but they must first acquire the requisite atoms from the destruction of existing objects. By treating fundamental atoms as building blocks, players can invent objects beyond the constraints of a hard-coded crafting tree. At the same time, the effort required to obtain these atoms within the game world preserves balance by imposing a cost proportional to the complexity of the created object.

Mechanics

We conceived of the Atomic Object System while working on Downstream. The game consists of player-controlled units living on a hexagonally tiled map where each state change is an onchain transaction. Units use buildings to craft items, and each item is composed of a specific set of fundamental particles, represented by different colours of goo. Players start by collecting goo, use buildings to craft new items from that goo, and then use those items to strengthen their units, trade with others, and devise new gameplay patterns.

The basic crafting flow involves:

  • Collecting goo from extractors.
  • Using buildings to craft items.
  • Adding the items to the player's inventory.

Extractors function as faucets for goo. They dispense base items: droplets made up entirely of pure red, blue, or green goo.

Buildings permit crafting, taking multiple items as inputs in order to output new items made up of the constituent goo. Different types of buildings are associated with different crafting recipes and output items. Some goo is burned in the crafting process as a kind of sink.

The most common use of items is to boost a unit's stats, with the amount of goo atoms in an object dictating the type and quantity of the stat boost. Red goo increases strength, blue goo increases defence, and green goo increases life. A good weapon, for example, would have a lot of red atoms. A good shield needs a lot of blue. A balanced item can have all three, as long as units have the required resources.

Players can also use the "Building Fabricator" to produce new buildings which in turn produce new items:

  • Designing a buildingKind with new crafting recipes.
  • Deploying a buildingKind as a smart contract.
  • Building instances of that buildingKind on the map.
  • Using their new buildings to craft completely new items.

Items do not need a unique atomic makeup. Perhaps your friend already has a building that creates Thor's Hammer from 100 units of red goo. There is nothing to stop you creating a new building that outputs a new item, Excalibur, also made from 100 units of red goo. These items will function identically in combat.

Crafting recipes can also take any player-made object as an ingredient. This allows for extensive tech trees to develop. If you have 10 Thor's Hammers and 10 Excaliburs, you could create a new buildingKind that takes those as inputs and spits out an extra powerful HammerSword.

Contracts

Downstream uses a node graph architecture, representing all entities (players, buildings, etc.) as contracts with their own address and items as ERC-1155s with a name and balance that can be assigned to those entity addresses. The fundamental atomic makeup for each object is encoded as metadata, allowing the crafting contract to check for the requisite constituent materials.

When creating a new buildingKind, with its accompanying crafting recipe and output item, the Building Fabricator generates three files:

  • NewBuilding.yaml: The Manifest – containing the parameters for the building and item.
  • NewBuilding.js: The Building UI – called when an instance of the building is clicked on in game, controlling the html and buttons displayed.
  • NewBuilding.sol: Onchain Logic – A solidity contract implementing the BuildingKind interface, which can dispatch actions on behalf of the Building.

The Basic Factory and Cocktail Hut are probably the most readable examples within Downstream.

Applications

The broadest application for an in-world composability system right now is crafting mechanics in games. Autonomous Worlds range in the degree to which they are game-like, and it is possible to imagine worlds without the fixed objectives of a game where inhabitants would still benefit from a system that allows the creation of new kinds of objects. Noticeably, however, many of the games that do feature crafting mechanics already play with the distinction between a game-to-be-played and a world-to-live-in.

Prominent examples of game genres that offer something like this include:

  • Survival sandbox games like Minecraft and Terraria
  • Farming-themed life sims like Animal Crossing and Stardew Valley
  • Factory or colony management sims like Factorio and RimWorld
  • MMORPGs like World of Warcraft and EVE Online

Many other games include crafting as part of a specific subsystem, like weapon crafting in Fallout or Dragon Age, and cooking mechanics in Breath of the Wild or Eastward.

Alternatives

There are a number of alternatives to this design pattern, differing primarily in their approach to digital physics. The designer of a world has to consider what complexity of digital physics they need. Deeper, low-level, or "fine-grained" digital physics are more world-like, sacrificing usability and immediacy in order to prioritise variety and complexity in what can be built on top. Shallower, high-level, or "coarse-grained" digital physics are more game-like, sacrificing variety and complexity in order to prioritise usability and immediacy in what can be built.

On one hand, a world could have more low-level or fine-grained digital physics, leaning towards simulation and emergence. Tenet's Zuse "world computer", for example, gives objects locality and thus can introduce a system for propagating causality. This kind of system is more complex and less accessible, but enables richer simulation and deeper engineering opportunities.

On the other hand, a world could have more high-level or coarse-grained digital physics, leaning towards liveness and immersion. Moving Castle's This Cursed Machine, for example, has the concept of components with inputs and outputs, which can then be constructed into "composable circuits" and used as building blocks for larger worlds. This kind of system is more opinionated and potentially less flexible, but enables richer worldbuilding and a deeper focus on gameplay.

Extensions and future work

One way of extending the system is to have a wider variety of atom types. The Atomic Object System in Downstream currently has three types of atoms, but we plan to add at least two or three more. John Carmack talks about the ongoing popularity of modding in games like Doom and Minecraft coming from a sufficient "Turing-completeness level of design freedom." We do not yet know what number of atoms is required to achieve that "Turing-complete design space." It is tempting to imagine a whole periodic table with many more types, but we suspect a system of that complexity would be unwieldy in practice.

Another possibility is for the atoms to impact more than just combat stats. This is already theoretically possible, since players can create buildings and components with custom logic that make use of the atomic values in different ways. A building could require players to be carrying items with >100 red atoms to even see its crafting recipe. But this seems of limited interest without adding additional player actions and traits that can actually hook into the atomic system. Perhaps there will be more exciting interactions to consider once we have digital physics for controlling movement speed or RPG-style skill acquisition.


Primitives
Pixel-Based Digital Physics
Player-Scripted NPCs
Rule Production as Gameplay
Local-First Game Loops
Collaborative Prompt-Based Narrative Systems