Games are synonymous with their rules. Indeed, what many games are is simply their rules of play. A game that is played by changing the rules might seem ripe with contradiction, but it is exactly this tension that makes for an intriguing and potentially engaging gameplay mechanic. Here we will explore this primitive of rule production as gameplay, highlighting design principles unique to this pattern and how we are exploring it using our game, Gnomik.

Motivation

Gnomik takes direct inspiration from Nomic, a game created by philosopher Peter Suber in 1982 in which players propose and vote on rules and rule modifications of their own design.

Suber intended Nomic to be a toy model of the “paradox of self-amendment,” or the issues that arise when rules are set up to allow for their own change. He was interested primarily in what this paradox meant for constitutional law, but his practical thought experiment is as applicable to the challenges posed by composable Autonomous Worlds to game design principles typically guided by fixed, discrete rulesets.

Autonomous Worlds allow for the open interoperability of game worlds. This means that any particular game has the potential to connect to a new set of rules. Rule production as gameplay is a well-suited mechanic to experiment with this affordance as it encourages players to devise ways for the rules of a game to expand such that they continue to provide the tension and novelty necessary to invite continued participation. A composable world with an open ruleset can easily become unpredictable and frustrating to its inhabitants. Making rule production a core part of a world’s game loop guards against this by making rule changes less arbitrary and more aligned with player interest. To experiment with this primitive is in effect to experiment with what kind of design conditions allow for the maintenance of a minimum viable game world, or a sufficient excuse to continue play.

Mechanics

Such a viable rule-production system requires both a simple base game that invites players to experiment with new rules and a pace of rule addition that preserves player enjoyment. The mechanics of Gnomik were developed with these tensions in mind.

By starting from a minimum viable game world comprised of a simple matrix of rules, Gnomik can accommodate players modifying and adding rules both within its initial limited ruleset and towards paths of play which may be wholly unrecognisable from the game as it is initially deployed.

A Gnomik world instance is deployed as a clicker game in which users press buttons to acquire resources which can then be spent as costs to acquire other resources. Because the template for producing and consuming resources is self-similar, it is controlled by a single system, the "Action System".

Rules are modified or added through the use of two special resources: the "Lesser Rule Spark" resource, which gives the player the ability to modify the internal mechanics of resource production according to the templated structure of the Action System, and the "Greater Rule Spark", which gives the player the ability to add an external smart contract system to the world.

Contracts

The Action System processes well-formed local rules, which all abide by the following form:

• Name: Unique name of the function.
• Cost1: Value of the first resource cost.
• Cost2: Value of the second resource cost. Set to zero if no second resource cost.
• Target: True if the target of the function is the caller, false if the target is input upon call.
• ResultAmount: Amount of resource to change.
• CostResource1: Type of resource needed for Cost1.
• CostResource2: Type of resource needed for Cost2, empty string if absent.
• CostFunction: Name of the function with which to apply the cost calculations. Currently supports: “add”, “sub”, “mul”, and “div”.
• ResultResource: Name of the affected resource upon which to apply the ResultFunction with ResultAmount.
• ResultFunction: Name of the function with which to apply the cost calculations. Currently supports: “add”, “sub”, “mul”, and “div”.
• ResultType: Type of the affected resource to change. Currently supports “resource” and “rate”.

Every resource has a static resource amount and a constantly updating rate. Rates on a player’s resources are lazily updated every time that resource is referenced in a contract call. Consider the following two rules:

The Gather function costs nothing except clicking the button and produces one mushroom resource. The Eat function costs the user 10 mushrooms and in turn increases their mushroom rate by one. Resources are added to the game by referencing them in rules. A new reference in the single resource table is automatically created for any previously unregistered resource referenced in the addition of a new rule, allowing Gnomik to dynamically create and handle both new functions and new resource types within this well-defined resource economy.

Applications

The simple architecture of Gnomik — arguably closer to a game engine than an actual game — encourages players to instantiate new instances of a world with different rule configurations. Its primary application is to serve as a catalyst for player experimentation. Many of the rulesets they arrive at through play could form the basis of future design primitives similar to the one we outline here. Iterations of Gnomik could also serve as a foundation for more elaborate governance simulators — a common theme amongst existing blockchain experiments centred on rule addition—that echo the spirit of Suber’s original game.

Extensions

While MUD supports the addition of new systems and tables at the chain layer, work remains to create a seamless integration of them post-deployment in the middleware and UI/UX layer. This could involve rule creators integrating their own visualisation and interaction components with the rules they add.

Adding hooks to Lesser Rule Sparks is another way to extend Gnomik's diegetic structure while respecting its initial ruleset. This would allow rules to be added in the initial structure with additional pre- and post-conditions for the execution of those rules — for example, needing to own an external NFT in order to acquire a particular resource or the execution of an action resulting in the mining of an NFT.

The Action System can be further abstracted to support more possible configurations of actions — for example, increasing the number of cost resources, and opening up the cost functions to accommodate arbitrary calculations of resource manipulation.

Acknowledgements

The text was first written by MemeConscious and subsequently revised by Guy Mackinnon-Little. The GitHub links to the original project developed during the Autonomous Worlds Weekend in 2023.