Nov 15 — Nov 16, Istanbul

In games of all kinds, there has always been the question of authorship. Gaming is a collective media and not only that, it is a performative media. A game will not unfold without the active intervention of the player, making them not an audience but a co-creator. Not all games allow for this creative performative space, but all sports and many video games do. Competition is almost always the focus of these performances (as is the case with MOBAs, shooters, and speedruns). Still, the performances of gaming can also happen in free-creating worlds like Minecraft, whose livestreaming influencers often just explore the game for their audience. No matter the intention of the player, playing a game is (or can be) a creative act. While players have always been partial creators of the games they play, one way to understand the history of gaming is as a drama in which the boundaries of authorship are continually redrawn. The potentials of onchain games herald another significant chapter in this drama, but first, let us consider how we got here.

Gaming's means of production have evolved greatly since it became a "proper" industry over the course of the 1970s. At the outset of the industry, one game developer would manipulate hardware directly while single-handedly creating all the content: code, graphics, music, and gameplay."1 As time passed, more abstractions started to emerge allowing specialization within specific domains of a game. Musicians, graphic artists, and animators focused solely on executing their skillset, while engineers came to specialize in working specifically on animation tools, physics simulations, and rendering and lighting engines that allowed content creators to avoid the distraction of working with code.

Two aspects are fundamental when thinking about this evolution: ownership and complexity. As the market grew economically, big studios emerged to provide the necessary investment and retain legal ownership (both for financial liability and intellectual property) of the final product, allowing games to explode in terms of production complexity. Once these large studios started to churn out titles, it became logical to reuse large segments of code and sometimes even gameplay. Complexity could be hidden or abstracted away, making way for standardizations. The in-house game engine thus became the path to protect the studio's investment. Most companies protected their code as IP as it could be considered a solid asset to investors. Other companies, a few years later, took a different approach and allowed not only for their code to be cloned, but for users to build on top of their game. With these "open engines," the stage was set for players to express themselves on a level beyond (or above) the rules and aesthetics of the game.

The modding scene that emerged from this more open approach created some of the most important titles we have today: Dota 2 and League of Legends (both iterations of the original MOBA, DoTA), Counter-Strike (built on top of Half-Life's engine), and Fortnite (an iteration of PUBG, itself a mod based on ARMA 2). Ironically, these games are now protected (owned by Epic, Riot, Valve, and Tencent), and modding them is not the simplest endeavor. Of course, not all mods are as successful as League of Legends or PUBG, but the point stands: modding enabled players to express themselves within the rules of the engine rather than only within the rules of the game. The game became to create games.

Composability on the blockchain is, philosophically, a very open type of modding. Composability, as we are defining it, is a permissionless extension of software functionality. Simple functions exist on-chain and are accessible to any user. On top of those functions,"2 more software can be created that relies on them but simplifies, amalgamates, or increases their capabilities. These new contracts are deployed freely and their use of the preexisting functions is unrestricted save for the constraints built into the initial contracts. All the mods above were created on top of existing games by people who played the game, creatively asked "what if," and took the effort of creating a new product. Blockchain allows this activity to happen within the live game: instead of creating a semi-clone in a separate instance, code can be deployed on top of a running game. Once games are running fully onchain, they become fertile ground for experimentation. Anyone can deploy new features on top of a game. These changes and additions can happen within different layers of the game, from the most fundamental (concerning the location of entities, statistics, and abilities) to the highest level (concerning the user interface, buttons, and notifications). Freedom of manipulation depends entirely on the layer and the architecture of the original game.

Let's call the bottom layer of a game the sandbox. At this level, the rules are there only to enforce constraints, not goals. Constraints are fundamental to a game because they either simplify reality so it can be simulated or they create extra friction within reality which in turn creates challenges for performative play, as is the case with a game like football. With computer simulations, we are not simplifying an existing reality, but building one from scratch. One way to think about it is that we are not only defining how much oil can be found in the virtual lands of a given game, but also how much energy burning oil provides, how to refine oil into more efficient fuels, and how to create different engines powered by these fuels (assuming those are areas the devs would expect players to delve into). Some call this set of constraints digital physics.

On top of the sandbox we have the game rules, establishing goals, rewards, and unique variants. This is where the generic constraints of the sandbox are shaped into a game, with a defined quantity of players, a starting and end condition, clear goals, tasks to be achieved, and likely a score system. The sandbox rules are indifferent to the entities they govern as they simply react in a (mostly) predictable fashion to the inputs from the user. The game rules, on the other hand, concern goals, objectives, and rewards for the users. They establish winning conditions and penalties."3 This organization is more present in certain games (poker, sports, RPGs) and less in others (Lego or other toys). The harder the contention of these rules, the more specific skills will come out the other end. In that sense, for a skill to be measured carefully, some very tight constraints have to be put in place. Think of how enhancers are rigorously monitored in many sports.

Onchain games will necessarily abide by any rule stipulated. As with any game played on a server, those rules cannot be escaped by the players. With onchain games however, the developers cannot escape either. Once rules are set in motion, the player and the developer are on equal footing. When someone creates something new in the game, like a new weapon for a character, they have to adhere to the rules that are already in place. The new functionality can expand on top of the existing actions available, merge them, or synchronize them, but it cannot deny or undo them in any way. This inescapable constraint is the great equalizer between developers and players, giving them both a shared potential to move the game forward. New content can now be created and deployed by anyone and the authorship of a game can evolve over time as some deployments become more popular than others. The ultimate judge of the direction a game follows is the audience, voting through play.

The constraints with which a game is deployed onchain set the foundation for every development that follows. Given that players have the autonomy to expand the game and freely build on top of it, building solid sandboxes becomes the primary goal of those working on an onchain game pre-deployment. A carefully designed sandbox would engage a more creative type of player, one who would be enticed to create and continuously evolve a world on top of a set of rules, not only a player focused on perfecting a narrowly defined skillset.

What, then, should these rules look like? The flexible yet simple rules of Advanced Dungeons & Dragons allow for adoption across different contexts, creating a solid base for RPGs that could evolve into uncountable versions, derivations, and campaigns. While the core mechanics were fixed, space for creation in terms of setting and narrative allowed for different games to generate enough novelty so as not to feel like they were repetitions of a previous campaign. In terms of digital games, mods like Counter-Strike or DoTA built on top of the technology of their base engine (with its collision rules, camera movements, physics, predefined classes, entity spawning and management, netcode, session creation, and client/server definitions) to create the most popular games we have today. The creators of these popular games did not have to exhaust themselves with constructing a digital physics from scratch. Instead, they could experiment freely within a fixed set of constraints. As we have seen, abstraction allowed for more complex games through specialization. This standardization saved labor and made it easier to onboard developers, but more importantly, it accelerated the adoption of players who could experiment with the new game rules: as long as they had played the original game, players only had to learn what was different or new. It was both easy to introduce new game rules and easy for players to grasp them.

Onchain composability means that any game can be infinitely modded by anyone. With thoughtful design at the sandbox level, any team can introduce new functionality on top of an existing game, with the community being the final judge as to whether the functionality advances or detracts from the game. In an Autonomous World, there is no hard distinction between consumer and producer, audience and author, player and developer. Who creates the game is now truly open. Audiences can make a game their own, defying the developer's expectations. With this technology, they do not need to ask permission.

Acknowledgements

This text was originally published in Autonomous Worlds N1, 2023.