Universal Laws of Game Design - Volume 3

(Continued from Volume 2)

So far, I have been suggesting a new way to search for an optimal method of designing a game by constructing a purely mathematical universe - a universe made out of abstract entities such as a single point in space representing a biological organism, its "region of influence", as well as energy particles of two opposing forces (positive and negative). The conception of such a hypothetical model, although its metaphysical nature prevents it from showcasing any specific example of game design right off the bat, has been intended to function as a gateway to the discovery of a set of "Universal Laws of Game Design" based upon its focus on our shared biological instincts as well as their generic applications.

The abstract world which I have been devising largely consists of elements which reflect the two mutually reinforcing aspects of game design - narratives and mechanics.

Since a game must begin with a narrative (otherwise it would be categorized as either "toy", "puzzle", or "simulation") and the root of it is the player's desire to become successful as a lifeform, it seems obvious that the most fundamental instincts of any biological being must also be the most fundamental building blocks of any narrative. And while it may appear as rather arbitrary, I have supposed the classification of our most archetypal desires into 3 types: Absorb, Expand, and Secure. These three indicate the topmost nodes of the player's goal tree, from which all other (i.e. subsidiary) goals originate in the form of subtrees. These are, within the context of the abstract gameplay model which I am proposing, the most atomic constituents of the game's narrative space.

In order to let the player traverse this vast tree of goals, however, a game must also involve a web of mechanics. Goals are nothing but a wishlist unless we have ways of achieving them, and such ways can be described as "interactive" only as long as the player is compelled to take actions to fulfill them. The presence of gameplay mechanics ensures the realization of such actions, due to their chains of causality which can either be invoked or not invoked depending on the player's choices. The easiest way to introduce such mechanics, at least from my perspective, is to come up with a few spatial entities which represent our real-life objects in the most generic fashion as possible (i.e. The protagonist, a region of influence, resources, and obstacles). Interactions among these indivisible objects are basically the game's mechanics which lead the player from one goal to another.

And the converse is also true. By observing a set of mechanics and their emergent behaviors, we can derive an assortment of brand new narratives. Placement of a treasure box behind a locked door, for instance, generates narratives which eventually lead the player to conceive the goal: "Find the key which unlocks the door".

The overall conceptualization of how narratives and mechanics form a cycle of mutual reinforcement, however, is not detailed enough to let the designer create anything substantial; it is more or less just a fuzzy overview of what is going on in a broad sense, which by no means delves into specifics that are crucial for the design process.

And because of this concern, I went through a quantitatively precise methodology of how the construction of a goal tree and its machine-level protocols of execution can be made possible by means of algebraic expansion. Each goal is essentially a formula whose terms can be substituted with their respective subgoal formulas, which means that the entire goal tree can be expanded into one large expression that is solely composed of the most atomic terms we can possibly think of. Such "atomic terms" are the computer's most primitive operations, which in our context are the movements of individual objects.

It is thus quite clear that we know how to design a detailed gameplay system based off of a set of narratives as well as a set of mechanics. We come up with goals, algebraically break them down all the way down to the most primitive level (e.g. discrete topological movements), and from the dynamics of their ensuing set of interactions, we allow ourselves to conceive yet another potential set of goals to solve, and so on.

The question is, will this cyclic methodology really lead us to the process of game design? After all, a game is more than just a stack of goals and actions. There are somewhat more qualitative aspects of designing a game such as thematic elements, storylines, hints, dialogues, contents, progression, levels, items, and myriads of other subtleties which are essential for rich gameplay experience. The purely abstract model which I have described so far does not directly suggest any method of implementing such features, so how an earth will anyone be foolish enough to expect a decent gameplay prototype out of it?

This kind of doubt is definitely valid on a perceptual level, yet it could also serve as a mental barrier which prevents the designer from seeing the essence of what is really going on behind the facade of worldly sensations. Anyone who is willing to design a game with efficiency in mind must build things from a carefully chosen backbone of abstraction, which does not necessarily embody any of the "features" that are directly visible to the player's eyes, yet has the capacity of giving birth to a number of functional elements that are highly modular and reusable. Once we have such elements, we will be able to come up with new gameplay features simply by assembling them together like Lego bricks.

Yet, it is also true that the theoretical model which has been outlined so far lacks a number of core elements which are vital for its practical applications. In order to create a commercially viable game out of it, for instance, one definitely needs to be able to answer the following 2 questions:

(Question 1) Most games should be able to involve not only the player character, but also other characters which exhibit their own behaviors in intelligent ways (i.e. behaviors that are somewhat more sophisticated than mere mechanical actions driven by mechanical laws). They may either be controlled by other humans such as those in a multiplayer RTS or MOBA game, or AI agents which imitate the way humans control their characters. How will the current abstract framework, which seems to only involve a single protagonist and a group of things which solely exist in relation to it, make it possible for us to come up with multi-agent gameplay?

(Question 2) The types of objects which have been specified so far are extremely generic. For example, anything which provides the player with energy is called a "resource", while anything which steals energy from the player is called an "obstacle". Most real games, however, contain multiple variants of resources and obstacles from which a wide spectrum of gameplay dynamics may arise. Such variants can hardly be designed within the context of mathematics, for they require thematic elements which cannot be fully analyzed in a purely logical manner. Hence, how on earth will a generic skeleton of a game be able to yield any chance of diversifying its gameplay ingredients, if the skeleton claims itself to be already functionally perfect in its own right?

Let me tackle the first question. It is, for sure, crucial to have multiple player-like agents within the gameplay system unless we only want to design static puzzles and nothing else. And this bit of necessity can immediately perplex the designer if we are to assign fixed labels to all things that are represented as objects in our hypothetical game world. The reason behind this is pretty easy to discern, as illustrated below.

Suppose that there is a human, a shark, and an ocean. Which ones should be considered "myself", "resource", and "obstacle" then, if we are to fit them into the context of the aforementioned mathematical model of the gameplay space?

Our intuition leads to the notion that the answer must be relative in nature. From the perspective of the human, the shark is an obstacle because it has the potential to attack him/her. The ocean, too, is an obstacle because it works as a spatial barrier which makes it harder for people to move from place to place. What about from the perspective of the shark? To the shark, a person is an obstacle because he/she is able to inflict damage upon its body by means of a spear or other equipment. The ocean, on the other hand, must be considered a resource because it allows the creature to move as well as maintain its biological function.

The presence of such relativity, which arises from the coexistence of multiple animate (i.e. motive-driven) agents, forces us to start representing the current model of the gameplay universe a bit differently from before. An object is described in terms of properties such as "myself", "resource", or "obstacle", not because they are intrinsic to the object itself, but because they are endowed upon the object by the observer's interpretation. Each property is more of a relation between a pair of objects than a constituent of a single object.

In general, we can define each of the objects as an "observer" because every one of them is the protagonist ("myself") from its own viewpoint. And the overall worldview can be summarized as follows:

A universe which comprises N observers can be considered an ensemble of N parallel universes, each of which is each observer's own set of interpretations regarding all of the N observers. For the sake of abstract reasoning, one could say that even a piece of rock is an "observer" in a sense that it does observe things that exist in its own parallel universe, yet possesses a tendency to not assign any motivational meaning to them.

Going back to the human/shark example above, we can fairly easily draw a conclusion that the human-observer belongs to a parallel universe in which both the ocean and the shark are interpreted as obstacles, whereas the shark-observer belongs to a parallel universe in which the human is interpreted as an obstacle but the ocean is interpreted as a resource. And the motive-driven behaviors of these two observers (human and shark) can be determined by algebraic patterns which originate from their respective parallel universes, just as shown below.

Representing the gameplay space as a collective sum of distinct observer-spaces can give us a strong temptation to indulge in the notion of synthesizing complex narratives that are more sophisticated than the three initial goals (i.e. Absorb, Expand, and Secure). The coexistence of different relations among different objects gives rise to a wide variety of implicit goals which may yield profound decision points (e.g. dilemma, prioritization, moral ambivalence, etc) and shift the gamer's stream of consciousness above and beyond that of a puzzle-solver, thereby opening up a gateway through which the game itself can narrate its own emotional stories as a collective lore. Examples of how complex relations might be able to emerge out of simpler ones are listed below.

If both objects are resources to each other, they are allies. If both of them are obstacles to each other, they are enemies. When only of them interprets the other as a resource and the other one doesn't care, that "resource" is just an ingredient (i.e. raw material) to be consumed, and so forth. Such descriptions are "derived relations" - ones that are derived from mutual arrangements of primary relations (e.g. "resource", "obstacle", etc). Given these additional factors, we can technically diversify the observing agent's behavioral pattern by endowing it with a bunch of conditional statements, each of which specifies how to react to the presence of each derived relation (illustrated below).

This sort of reasoning, however, raises two major concerns. One is that it complicates the algebra way too much, and the other one is that there is a great deal of ambiguity involved in the construction of derived relations and their ensuing goals/actions.

First of all, let us recall the elegance of the original formulas which were introduced in the previous volume: "absorb = decrease(d+)" and "secure = increase(d-)". They explained the agent's entire behavioral pattern by means of changes in its distance with respect to other objects. The purely geometric nature of this design, as well as its simplicity of computation, allowed us to easily come up with goals which could gracefully be broken down into sequences of primitive actions (i.e. spatial movements). Now with a bunch of derived relations which are not logically as straightforward as the original, we are heading toward a mudpool of vague design ideas made up of myriads of custom scenarios and potentially contradictory edge cases.

An even worse consequence of using derived relations is that they can be quite arbitrary in meaning. If Y is a resource of X and X is an obstacle of Y, for example, should it really mean that Y is X's prey and X is Y's predator? What if X is physically weaker than Y? If that is the case, shouldn't Y be called a "host" of X, and X a "parasite" of Y, since X won't be able to just catch and devour Y because does not possess enough strength to do so?

Also, what if there is a case in which an object can both be considered a resource AND an obstacle simultaneously, such as a radioactive material which can harm our bodies but can also be used as a source of power? What kind of derived relation should there be between this object and its observer? And if there is one, exactly how should the observer behave in order to satisfy both the "absorb" and "secure" goals at once, in regard to this "dangerous yet useful" object?

What if my own body is also my resource (supposing that I am a plant, capable of producing nutrients on my own)? Should I then "collect" myself and then use myself as a fuel? And if that's the route of my reasoning, hasn't such a goal already been fully achieved, since the distance between myself and the resource is already zero?

What if there is a resource which is also an obstacle of another resource? Shouldn't I take this complexity of relations into account and make sure that these two types of resources are segregated from each other as much as possible, while also making sure that I myself is as close to both of them as possible (which may introduce oscillatory behaviors due to perpetual recurrence of self-contradiction)? And what if there is a resource which is also a resource of my obstacle? Shouldn't I, then, be making sure to separate out my resource from my obstacle as much as possible, while also avoiding the obstacle and collecting the resource simultaneously? Should I avoid and then collect? Or collect and then avoid? Which heuristic should be used to determine the precedence between these two goals?

Etc...

And the list goes on and on, forcing us to consider every possible permutation of relations and manually design a separate behavioral algorithm for every one of them.

Such an exhaustive approach, for sure, is a terribly inefficient and error-prone method of developing the game's theoretical model. The main reason behind its exploding complexity is that thinking in terms of supersets of mutual relations creates a huge gap between the game's narratives and mechanics.

When I introduced a bunch of new relations such as "prey", "predator", "ally", and "enemy", what I did was come up with a number of semantic seeds for the game's advanced narratives. However, such derived relations were something conceived outside of the game's system of mechanics and thus turned out to be not quite translatable to a collection of executable actions. This made them stay as a vague cloud of mere wishes, hardly achievable in any specific way.

We may as well try the exact opposite method - that is, just come up with pure mechanics first and then build narratives on top of them. This too, however, leads to more or less the same level of unbearable complexity as more and more mechanics get introduced.

Let me take an example by supposing that a person starts to design the game's mechanics by devising generic components such as "signal emitter", "signal receiver", "signal filter", and so on. Since they are too abstract, one should be compelled to derive more specific types of components from them such as "ray signal emitter", "area signal emitter", "signal distance filter", "signal line-of-sight filter", and so on. A gun, for instance, can be considered an object which uses a "ray signal emitter" because it sends a signal called "bullet" by casting a ray through its calculated line of trajectory, and the target that is being hit by the bullet can be considered an object which uses a "signal receiver" because it receives the "bullet" signal from the gun and invokes an appropriate callback procedure (i.e. A function which plays a death animation and despawns the target, etc).

And we can definitely keep doing this for a while, inventing as many gameplay mechanics as possible by virtue of both inheritance and composition. If we have a timer and a bomb, for instance, we can combine them together to create a timebomb. If we have a lock and a door, we can combine them together to create a lockable door. And if we put a timebomb on the other side of a lockable door and then lock it up while there are enemies behind it, we can eliminate the enemies with an explosion without being hurt because the door will protect us. And so on.

However, it soon becomes quite clear that designing a game by simply coming up with a truckload of mechanical elements will hardly lead us anywhere beyond a mere assortment of emergent phenomena, since it is hard to decide exactly what sort of narrative sense we ought to make out of them. Suppose we have a game design template which is capable of generating an imaginary maze-like hallway (like the one in Wolfenstein 3D), filled with myriads of combinable/interactive elements such as locked doors, keys that can unlock those doors, buttons and switches which can trigger special events when activated, monsters with swords, monsters with guns, monsters with grenades, healing potions, invisibility potions, traps, explosive gas tanks, and so on. There are indeed many ways of arranging such elements, and one may be able to argue that even a random arrangement will be decent as long as the game is not primarily story-driven because the dynamics of their in-game interactions will naturally induce the player to make up his/her own set of narratives during the play. Delegating the production of narratives to the inner workings of the game's mechanics, however, makes it hard for us to come up with a game that is semantically rich in its own fictional context. A mere arrangement of mechanics may introduce an enormous set of clever goals such as killing an enemy by means of an unexpected chain reaction among a group of seemingly related objects and so forth, but it is hardly capable of giving birth to subtle narratives such as moral struggles, social bondage/conflicts, profound emotional revelation, jealousy, vengeance, betrayal, compassion, humor, etc.

And if we are to complete the full picture by trying to devise a whole separate list of narratives which is supposed to fit the complex web of mechanics explained above, we will be just as equally lost (if not more) as in the previous case in which we saw the difficulty of coming up with mechanics which fit the complex web of subtle narrative elements. Here is my conclusion regarding the requirements of a clean game design methodology, based off of the observations I have made so far.

A well-made game must consist of both narratives and mechanics; a "game" which lacks mechanics is a mere lore, and a "game" which lacks narratives is a mere sandbox.

And both the game's narratives and mechanics must be designed concurrently as parts of one shared system of logic, since either developing a system of narratives first and then trying to develop a system of mechanics on top of it, or developing a system of mechanics first and then trying to develop a system of narratives on top of it, will introduce too much complexity/ambiguity due to their lack of mutual compatibility. The question is, "How on earth will we be able to come up with a multidisciplinary prototype which is rich in both narratives and mechanics, despite the fact that these two areas of knowledge are drastically different from each other?"

In the next volume, I will answer this question by explaining how a minimally designed mathematical model can provide a "common ground of reasoning" for these two areas of knowledge.

(Will be continued in Volume 4)