How to Understand Game Design. A Systematic Perspective.
- Vlad "DBuilD" Nizhutin
- Jun 2
- 12 min read
Have you ever noticed that seemingly different things often follow similar fundamental structures when broken down into simple rules and components? If so, you’ve likely observed that well-designed systems—whether in nature, technology, or art—share underlying patterns, even when their details appear vastly different. But why does this happen?
In this article, we’ll explore the systematic perspective of game design—a way of thinking that frames game design as a structured system rather than a collection of isolated mechanics. Instead of focusing on hidden patterns, we’ll discuss how adopting this perspective can help you analyze and create games more effectively by understanding their underlying logic and structure.
We’ll be discussing systems through a mathematical lens, but to keep things accessible, we’ll avoid excessive rigor and use more intuitive language. This means some mathematical inaccuracies are inevitable, so to all the mathematicians out there—consider this your friendly disclaimer.
Our goal isn’t to prove a hypothesis through strict mathematical logic but to shift our perspective on game design. By simplifying concepts, we can better understand how systematic thinking applies to game creation.
We begin with a black space—a void with nothing in it. No expectations about the game, no theme, no mechanics, no market, no visuals. Just emptiness.
Now, let’s introduce a set of “anything,” which we’ll call 𝔸. Not bad, but it’s too abstract. To refine it, we define our set 𝔸 as having n_a elements. Still a bit vague—so let’s specify that n_a = 2.
Why 2? Because we are starting from an absolute blank state. This is crucial in understanding the perspective of designing systems without relying on external references like graphics or pre-existing gameplay mechanics.
Thus, we now have:𝔸 = {A1, A2}
To expand on this, let’s define another set:𝔹 = {B1, B2}
For now, the specific size of these sets doesn’t matter—we simply chose n_b = 2 for convenience. In practice, it could be any number.
Now that we’ve created something, we face a new problem—there’s no change. Our sets exist, but nothing interacts or transforms. To introduce change, we need functions.
At a basic level, a function takes an input and produces an output. In the set notation we introduced earlier, we can express this as:f: 𝔸 → 𝔹
This means that function f takes elements from set 𝔸 and maps them to set 𝔹. But that’s just one function. Do we need to define every function individually? That sounds tedious.
The answer is—no! Instead of defining each function separately, we can define entire sets of functions and assign different names to them.
For example, let’s define:
𝔽 : 𝔸 → 𝔹 (a set of functions mapping elements from 𝔸 to 𝔹)
𝔾 : 𝔸 → 𝔸 (a set of functions mapping elements from 𝔸 back to itself)
Wait—𝔸 to 𝔸? What does that mean?
It simply means that the function transforms elements within the same set rather than mapping them to a different set. A basic example would be:
f(x) : ℕ → ℕ, f(x) = x * 2
This function takes a natural number as input and returns twice its value. If you input 5, the function outputs 10. If you input 7, it returns 14, and so on.
I know, I know—this already feels like a lot, but we’re almost there. The only missing piece? The player.
Let’s define a set of players:ℙ = {P1, P2}
This allows us to assign indexes to our sets, letting us specify whether certain objects:
Belong to a specific player
Are shared among all players
Exist independently (like market forces or environmental changes)
For simplicity, let’s assume that both our object sets and function sets can be owned and applied by all players, making the game symmetrical. This means:
Each player has their own object sets: 𝔸_p1, 𝔸_p2, 𝔹_p1, 𝔹_p2
However, functions remain the same for everyone—since actions are identical across players.
This ensures that no player has an inherent advantage due to asymmetrical mechanics—at least in this basic framework.
An attentive reader might ask—wait, didn’t we skip defining our functions? We mentioned function sets, but we haven’t clearly established what they do. And my answer is—yes! That’s exactly what we’ll tackle next.
We’re now going to limit our function set by defining:𝔾 = {𝔾1, 𝔾2, 𝔾3, 𝔾4}
Wait, a set of sets? Yes! That’s intentional, and it’s not as complicated as it sounds. Here’s what each function group does:
𝔾1: {𝔸_p1 + k, 𝔸_p2 + k}A set of functions that increases or decreases any object in 𝔸 (A1 or A2) by k for one player, while applying the same change to the other player’s 𝔸.
𝔾2: {𝔸_p1 m, 𝔸_p2 m}Similar to 𝔾1, but instead of addition, this multiplies any object in 𝔸 by m, applying the same effect to both players.
𝔾3: {A1_p1 → +A2_p1 * n, A1_p1 → 0}Transfers the value of A1 into A2, applying a coefficient n, and sets A1 to zero.
𝔾4: {A2_p1 → +A1_p1 * n, A2_p1 → 0}The reverse of 𝔾3—A2 is transferred into A1, applying n, and setting A2 to zero.
Now, we finally define our core functions as something simple:
𝔽: {A1 → B1, A1 → 0; A2 → B2, A2 → 0}
A set of two functions that either transfers A1 to B1 or A2 to B2, and in doing so, sets the original A values to zero.
That was a lot! Let’s take a step back and look at what we’ve actually done—without all the symbols.
We’ve defined a set of objects A1, A2, B1, B2 and created rules that govern how they interact. In simpler terms:
Players can increase or decrease the values of A (affecting both their own resources and their opponent’s).
The main structural rule we introduced is a one-way transaction that moves A values into B values.
If we generalize this, our system behaves like:
“Players are competing for resources (A), affecting each other’s supply, and then settling their resources into a separate, untouchable pool (B).”
The Purpose Behind These Rules
Before moving forward, it’s important to recognize what we’re doing from a systematic perspective. Our goal is to force players to make meaningful decisions—actions that can be either good or bad depending on circumstances.
One of the biggest challenges in game design is avoiding dominant strategies—actions that are always the best choice, regardless of the situation. Our function set 𝔾 was built specifically to prevent this.
Notice that none of our functions provide a guaranteed benefit to a single player without consequences. There is no function in 𝔾 that would always be beneficial to one player without some form of trade-off.
Introducing Game Theory Concepts
This ties into an important game design principle: sum dynamics in decision-making.
Zero-total decision: A rule where one player’s gain is exactly equal to the other player’s loss, meaning the total effect of an action is zero.
Example: If you increase your A1 by 5, your opponent’s A1 also decreases by 5.
Zero-sum systems generally lead to the most complex decision-making, since every gain has an equivalent cost.
Positive-total decision: A rule where both players gain something, but one player might benefit more.
Example: Both players gain resources, but one gains +10 while the other gains +5.
Positive-sum rules create a pleasant experience but can lead to balance issues (inflation).
**Negative-total Decision: A rule where the total benefit is negative, meaning one player suffers more than the other.
Example: One player gains +10 health, but their opponent loses -70 health, making the total outcome -60.
Negative-sum rules can be punishing and, if overused, may make the game feel unfair or frustrating.
How This Affects System Behavior
By combining our function set 𝔾, we’ve created a framework where players can manipulate resources (A) in non-trivial ways—meaning there is no obvious dominant strategy at first glance. This naturally leads to complex system behavior, where strategy emerges based on how players interact with the mechanics rather than just number values.
Introducing a goal
But wait—we forgot the most important part of any game. The goal.
It’s almost obvious that 𝔹 should be involved in determining victory, since so far, all it does is collect resources in an untouchable pool. That sounds like a good candidate for a win condition, doesn’t it?
Let’s define a winning function:W : B1 * B2
This function calculates a winning score by multiplying the values of B1 and B2.
Now, we know how players can win and can visualize how they might achieve the highest score. We see why players are competing, how they affect each other, and why each function in the system plays a critical role in achieving the goal.
Final Step: Refining Content
So far, we’ve structured 𝔾, but we haven’t fully defined the values of k, m, n. To finalize our systematic approach, we define them as sets:
𝕂 = {-10, -9, … 0, 1, 2, 3 … 10}
A range of integers from -10 to 10 (both positive and negative adjustments).
𝕄 ∈ {0, 0.25, 0.5, … , 4}
A set of values from 0 to 4, increasing in 0.25 steps (for multiplication-based transformations).
ℕ ∈ {0.5, 0.6, 0.7, … 1.5}
A set of values from 0.5 to 1.5, increasing in 0.1 steps. (Note: This isn’t the traditional ℕ notation for natural numbers, but for this system, we’re using it to define a specific set of values.)
The Bigger Picture
At the start, we had infinite possibilities for transforming 𝔸 to 𝔸.Then, we limited those possibilities with specific rules: addition, multiplication, and transfer.But even then, we still had infinite options, so we narrowed it down further to predefined values, selected using specific methods.
The final missing piece is how functions are executed—
Turn-based: Players take actions one at a time.
Card-based: Players receive function-linked objects that they can use based on a distribution rule.
If we choose a card-based system, we would need to define another set of objects, link them to functions, and determine how they are distributed to players—whether they play them one by one or all at once.
At this point, we could keep complicating the system indefinitely. But we won’t do that here. Hopefully, by now, you see the point:
A systematic approach not only allows us to build complex game structures step by step, but more importantly, it helps us recognize these underlying structures in different games, allowing us to analyze and design more effectively by using this perspective as a powerful lens.
But Why?
Finally, we’ve reached the point—why is this perspective useful? Because it provides another way to look at games.
1. Designing Non-Contradictory Systems
This perspective helps prevent contradictions and obvious flaws in game design. It ensures that objects exist to be interconnected, helps narrow functionality to a necessary set, and removes excess elements that don’t serve a purpose.
For example, if we define a new entity, a set of functions ℍ, which performs the exact same operations as 𝔾, we should remove it. Systematically, it serves no function. You might think, “That’s obvious,” but in real-world game development, redundancy is often overlooked.
Consider a game where cards and trinkets both increase the character’s HP. If trinkets provide no unique interaction beyond what cards already do, they should either be removed or redesigned to serve a completely different purpose. However, redundancy isn’t always a flaw—sometimes, it exists to enhance accessibility, create multiple progression paths, or reinforce thematic elements. The key is ensuring that every system serves a meaningful function.
2. Analyzing and Evolving Game Genres
This perspective is useful for analyzing genres and understanding their evolution. When you break a game down into its internal mechanics, it becomes easier to see what can be added, removed, or refined to improve the system.
By applying this way of thinking, you gain insight into why games are grouped into genres and why different audiences don’t always connect. You’ll also see how genres evolve—not in a strictly linear way, but as mechanics influence each other.
For instance, mil-sims and survival shooters introduced high-stakes engagements and large-scale maps, which later contributed to the rise of battle royales. Meanwhile, The Finals incorporates extraction-style elements but leans into fast-paced arcade mechanics rather than military simulation. This perspective allows you to analyze these transitions more systematically, rather than seeing genre shifts as arbitrary.
3. Improving Production Efficiency
Although this approach is complex and difficult to apply directly, understanding its principles helps shape your vision of system dynamics. It refines your focus on a game’s internal structure, leading to more efficient production. You’ll develop an instinct for when removing a feature is more beneficial than adding one—an essential skill for avoiding feature creep.
However, knowing when to remove mechanics requires context. Some features may seem redundant at first glance but serve a secondary purpose, such as accessibility, replayability, or immersion. A purely systemic approach should be balanced with playtesting and player feedback.
4. Combining Different Game Systems
This perspective also simplifies the process of merging different game systems or subsystems. When you understand how objects and rules interact, combining genres becomes much easier.
For example, integrating survival and RPG elements becomes more intuitive when you recognize the necessary connections. You’ll understand which mechanics need to be linked, which require restructuring, and how these adjustments impact the overall system. This prevents the creation of disjointed or inconsistent gameplay.
A well-structured system makes hybrid games more cohesive. If permadeath is a core feature in your survival mechanics, it should connect logically to RPG progression—perhaps through a soft-death system that allows some progression retention. Understanding these internal connections helps prevent mechanics from clashing.
Existing Video Game Examples
To help bridge the gap between highly theoretical system analysis and real-world game design, let’s break down how these principles apply to well-known games.
Chess: The Perfect Example of a Structured System
The game of Chess can be easily understood using the systematic perspective we developed.
At its core, Chess operates on:
A structured game space → The 8×8 board, which we can define as a set of squares:
𝕊 = { (x, y) | x ∈ {1,2,3,4,5,6,7,8}, y ∈ {1,2,3,4,5,6,7,8} }
This is a precise way of defining 64 squares mathematically.
A set of objects (chess pieces) → Each piece belongs to a category:
𝕆 = { 𝕆1, 𝕆2, … }, where:
𝕆1 = pawns, 𝕆2 = knights, 𝕆3 = bishops, etc.
A set of movement rules (functions) → Each piece follows specific movement constraints:
𝔽 = {𝔽1, 𝔽2, 𝔽3, … }, where:
Each 𝔽 defines how a given piece moves.
A function takes (𝕊, 𝕆) as input and returns a new position (𝕊, 𝕆).
Example: The Knight’s Movement
The Knight’s function applies coordinate transformations (+2, +1), (+2, -1), (-2, +1), (-2, -1), etc.
Since a knight always has 8 possible moves, this forms 8 legal functions for it.
Chess looks simple when broken down this way, but its depth comes from the vast number of possibilities and emergent complexity. The system is too vast for perfect computation, which is why humans continue playing and improving at it.
Civilization: A System of Resource Management
We won’t break down all of Civilization, but let’s focus on one fundamental system—resources.
At a high level, Civilization has:
A resource set:
ℝ = { R1, R2, R3 … Rn }, where n represents the number of available resources.
However, n is dynamic, meaning it changes over time:
n(t) is a function that outputs the number of available resource types at a given stage of the game.
For example, coal, iron, uranium don’t exist at the start of the game—they are introduced later.
A set of transformation functions:
These determine how resources convert into each other.
Example: A function F1 takes a resource R1 and converts it into another R2:
F1: R1 → R2
Example: Uranium → Nuclear Power → Increased Production.
Why This Matters in Game Design
The game connects resource systems to military, economy, and science using well-structured functions.
This allows developers to balance interactions without hardcoding every single relationship.
Essentially, the resource system acts as a self-contained “black box” that takes inputs, processes them, and outputs new possibilities.
MOBA Games (League of Legends): A Complex Interwoven System
Unlike Chess or Civilization, MOBAs are too complex to break down fully in pure mathematical terms, but we can still analyze how their systemic structure emerges.
Core Characteristics and Systematic Rules
Set of Character Attributes:
Each champion has a set of stats (ℂ), regulated by a set of functions (𝔽_c).
Example: Health, Armor, and Attack Damage (AD) interact via damage reduction formulas:
f(Armor, AD) = AD * (1 - Armor / (100 + Armor))
This function systematically regulates how tanky vs. damage-heavy characters interact.
Emergent Class Identities from Systemic Trade-offs:
If a champion has high damage, it must have a weakness (e.g., low survivability or range).
If it keeps its range, it must trade something else (e.g., mobility or burst).
By binary combining possible strengths & weaknesses, we get:
High Damage + Low Survivability + Low Range → Assassin
High Damage + High Range + Low Survivability → ADC
High Damage + High Survivability + Low Mobility → Bruiser
This is why League’s classes feel natural—their archetypes emerge from systemic constraints, not arbitrary labels.
Set of Ability Interactions (𝔸):
Every champion ability belongs to a function set 𝔸 = { A1, A2, … }, defining how abilities interact:
Point-click targeting (A1)
Skillshots (A2)
Area-of-effect damage (A3)
Parries & counter mechanics (A4)
This function set expands possible interactions, allowing designers to create familiar-yet-unique gameplay mechanics.
Based on these examples, we’ve learned, that:
Chess shows how structured systems emerge from simple function sets.
Civilization shows how structured functions allow for deep, interconnected mechanics.
League of Legends shows how structured stats, trade-offs, and interactions create emergent balance.
Conclusion
This is just another way to approach game design—not the only correct way, but a valuable tool to add to your arsenal. By applying this perspective, you gain a deeper understanding of how games function, evolve, and engage players, ultimately leading to more deliberate and effective design choices.
Commentaires