Forem: Nicolaos Tsitsonis

The BIG History of Game Design Documentation (1/2)

Nicolaos Tsitsonis — Sat, 17 Jan 2026 13:05:38 +0000

I. Preface: “The Unsent Letter”

Have you ever wondered where a great game truly begins? Not with the first line of code. Not with the first polygon of a model. Not even with concept art. It begins with a thought that was caught and pinned to paper.

In this industry, it is customary to talk a lot about the advancement of technology. We know everything about the evolution of engines, the console wars, and how, in a matter of decades, pixels turned into photorealistic landscapes. But we have a massive blind spot. We know almost nothing about the evolution of thought. About how the very method of extracting an abstract idea from one’s head and turning it into a system — one that can be not only felt but built — has developed. We learned to build logical bridges between our “I want the player to feel this” and the technical “the system must work like this,” turning ephemeral dreams into clear instructions for other people.

Today, we call this tool by a name that is simple and almost yawningly boring — Game Design Documents. In the mass consciousness, this is just a stack of papers or an endless page in documentation apps, a byproduct of development. But in reality, hidden behind this bureaucratic name is the only method to keep a project from decaying. It is the DNA of the game, captured in text; an attempt to synchronize the vision of dozens, and sometimes hundreds of people, so that in the end, they build the same castle, and not a hundred different huts.

And the paradox is that most modern designers, when answering the question “how do I do this?”, rely only on their own (often painful) experience or on the blind copying of templates, without even suspecting whose shoulders they are standing on.

The conversation about how to write GDDs in this day and age, how to distinguish working tools from cargo cults, and why the modern approach often fails — that is the topic of my next, separate article. But to critique the present with any authority, one must understand the past. You cannot fix a mechanism if you don’t know who invented it and why.

And right here, on the path to this essence, I must make a confession. To confess my love. A love for these very, seemingly boring, “documents.”

This is not a blind, enthusiastic infatuation. Oh, no. Rather, it is the most complex, exhausting, sometimes white-hot frustrating, yet most sincere connection I have ever had. I hate GDDs for their ability to turn into dead weight, into a bureaucratic formality, into a graveyard of ideas and prototypes. But I adore them for what they can be in the hands of a master: For being the architectural blueprint of thought, for being an X-ray of creative intent, for being the most honest artifact that captures the vision of the game and its author.

Over the last five years, I have tried, in one way or another, to understand this profession, to understand what truly hides behind the title “Game Designer.” And again and again, my search led me to these documents, to these imprints of history. And so, what you are about to read is not just a historical reference. Consider it my personal love letter, suffered for and forged over these years.

A letter to the history of Game Design thought, frozen on paper.

To truly understand the modern GDD in all its complexity and contradiction, we must trace its evolution. Therefore, our journey will resemble the work of a historian and an archaeologist simultaneously. We will start long before the first pixel appeared on a screen, looking into the world of tabletop games and wargames, where the first principles of formalizing rules were born. Then we will proceed through the dawn of arcade machines, the golden age of 8-bit consoles, the birth of 3D graphics, and finally, we will reach our days with their “live” documents. At each stage, we will uncover the context, study the artifacts, and ask questions — answering them as we go.

However, any love letter risks becoming too sentimental if feelings aren’t backed by facts. I have tried to assemble not just a chronology, but a logical chain: how one discovery in documentation led to the next, how limitations birthed new formats, and how the desire to make a better game forced people to reinvent the wheel again and again. We will walk this path, following in the footsteps of the pioneers, so that by the end, we arrive in the present not as stumbling blind wanderers, but as people who understand the foundation we stand upon.

But for now, I want to say a huge thank you to everyone who inspired, criticized, supported, and loves my wordiness. I hope you find digging through this as interesting as I did.

Enjoy the read!

P.S. This research was originally authored and published in Russian by me. While this translation has been adapted for an international audience, the source text remains the primary reference. The publication can be accessed here: LINK. I have made every effort to ensure accuracy, but feel free to point out any inaccuracies you might find!

II. 177 BC — 1958: “The First Manuscripts”

Looking at dates labeled “BC,” one can’t help but stifle a yawn. I get it. It sounds like the start of a stuffy lecture where a gray-haired professor is about to blow the dust off some pottery shards.

“Ooooh, antiquity, mysticism, sacred meanings…”

But here’s the thing: people have always played. Always. Play as a phenomenon is older than culture itself. And if there were games, that means there were rules. And if there were rules, then someone must have invented them, right? That means our work existed long before electricity. And the question that shifts the perspective sounds obvious:

“How did they even manage to survive to this day?”

And since you clicked on an article with the word “Documentation,” the answer is even more obvious: they were simply written down. Yes, you can create something eternal and distinct to a people, like chess or football, where rules are passed from father to son, but for everything else, you need a medium. Otherwise, any rule dies along with its creator exactly one minute after their heart stops.

And there is a grim yet mesmerizing beauty in this. As long as the rules remain in the head, the game is mortal. But the moment you fix them in place, you effectively separate the creation from the creator, making it independent. The author departs, eras change, but the logic continues to work, forcing people millennia later to experience exactly the emotions that were written down.

So, let us sit at the same table with our ancient colleagues.

177 BC — The Oldest Game Rules (Royal Game of Ur)

Essentially, there are two types of games in the world: physical and mental. The former, such as footraces or hide-and-seek, managed to survive thanks to simple, intuitively understandable rules and the power of oral tradition. But the latter — games built on complex, non-obvious systems — are far more fragile. I am certain that countless brilliant, abstract games were irretrievably lost, dissolving in time along with their creators. And it is all the more striking that a complex, quote:

“Race game with betting elements”

Which the “Royal Game of Ur” is, not only reached us but retained its playability. Largely thanks to a single clay tablet.

This artifact, dated to approximately 177 BC, is a cuneiform text meticulously compiled by a Babylonian astronomer-scribe. Instead of relying on memory, he performed the same fundamental task that we do today: he fixed the structure and explained the game rules for future generations.

Carved into the clay are:

A diagram of the game board, serving as a visual aid.
Rules for movement and betting, constituting the core of the gameplay.
Descriptions of special squares that added a layer of uncertainty to the game and were even used for fortune-telling.

The history of this tablet itself is a separate detective story that I won’t dive into here. For the most curious, there are excellent articles (straight out of LiveJournal, no less… «Sumerian Game of Ur») and also, separately, the video «Tom Scott vs Irving Finkel: The Royal Game of Ur») on this topic. For us, the outcome is what matters: Irving Finkel, a curator at the British Museum, having deciphered this ancient text, was able to fully reconstruct the mechanics and play the game in our time.

Just think about it! A game created in Mesopotamia survived millennia not thanks to oral tradition, but because someone deemed its rules important enough to carve them into clay. And it works. More than two thousand years later, when only ruins remain of Babylon itself, and the language of its creators has become dead, we can still sit at a table and experience the same thrill as they did.

1824 — The First Wargame Manual (Kriegsspiel)

You have surely seen this scene in movies or series about great commanders: a huge table, on it a map with detailed terrain. Generals, furrowing their brows, move wooden tokens across it, designating regiments and divisions, planning the next brilliant offensive. But what if I told you that this isn’t just planning? That this is a game? And that Napoleon himself had a hand in its popularization?

Surprisingly, the strategy genre was born long before computers and even before many board games we are used to. There is an excellent breakdown on this topic which I VERY STRONGLY recommend watching, titled «Kriegsspiel! How Napoleon Accidentally Invented Strategy Games», which proves that the roots of our beloved RTS and turn-based strategies go back to 19th-century military headquarters. Or maybe this was the first “real” board game in the modern sense, the first D&D without dragons and heroes? (Spoiler — not exactly, but indirectly it will become so)

About Kriegsspiel

Let’s move to 1824! Prussian officer Georg Heinrich von Reisswitz Jr. publishes a detailed manual for his military simulation game — Kriegsspiel (War Game). Its goal was extremely pragmatic: to serve as a simulator for training officers, teaching them tactics and strategy in maximum realistic conditions. For this complex system to work without its creator, an exhaustive document was needed. And it was created.

The manual, titled «Anleitung zur Darstellung militärischer Manöver mit dem Apparat des Kriegsspiels» (Instruction for the Representation of Military Maneuvers with the Apparatus of the Kriegsspiel), was, in essence, the first “prototype” of a GDD in history. Its nearly 100 pages contained everything needed to reproduce the game:

Rules for creating the game board (map scale).
Description of units and their characteristics (troop types).
Detailed rules for troop movement.
System tables for resolving combat outcomes.
Procedures for the judge-arbiter, who processed hidden actions and introduced the element of chance.

This document was so precise and self-sufficient that after a demonstration to the King of Prussia, the game received official approval as a mandatory training tool. The manual was printed and distributed throughout the army. At this moment, a significant shift occurred: “design” ceased to be tied to its creator. The game turned into a reproducible system that could be run by anyone holding this instruction.

The seriousness of this approach is underscored by the words of General von Müffling, who, after the game’s demonstration, declared:

“This is not mere amusement”

Reisswitz achieved his goal — maximum realism, and this was fixed in his rules. And most importantly for our history: Thanks to this elaborated “design doc,” Kriegsspiel quickly spread through the armies of other countries, where it was adapted and local versions were created, and people still play it or its digital versions to this day.

1904 — The Board Game Patent (The Landlord’s Game)

It probably won’t come as a surprise if I say that the Industrial Revolution couldn’t help but leave its mark on the world of games. The second half of the 19th and the beginning of the 20th century were not just the time of factories and steam engines, but also the first real boom of mass leisure. And while some placed bets at the races or spent time in saloons playing poker, others were creating the first commercial board games. And one of them, perhaps the most iconic for our history, was The Landlord’s Game — the direct ancestor of the hotly loved (and equally hated) “Monopoly.”

About The Landlord’s Game

In the early 20th century, game documentation took the next logical step: It moved from the military and academic plane into the legal one — through patents. In January 1904, inventor and designer Elizabeth J. Magie received a patent for her real estate trading game. Her goal, besides entertainment, was a visual demonstration of the economic principles of Georgism — essentially, a critique of land monopolies (which would turn out to be a very ironic twist of fate).

To protect and distribute her idea, Magie filed an official US patent. This document became, in essence, a formalized GDD. It laid out everything needed to reproduce the game:

A clearly formulated goal (accumulating the most wealth).
Core mechanics (rent, taxes, buying property).
A visual scheme of the game board, surprisingly similar to what we know today.

Moreover, Magie, like a true Game Designer, added variability to the rules: She proposed two sets of rules — anti-monopolist and monopolist, to visually demonstrate different economic outcomes to the players. This is one of the earliest examples of system design where rules are used to convey the author’s message.

Here history takes a dramatic and, perhaps, very instructive turn. Magie’s patent, conceived as a legal shield, ironically turned into a blueprint that preserved her ideas for someone else’s triumph.

Three decades later, while the game “circulated among the people,” gathering house rules, it fell into the hands of Charles Darrow. He and Parker Brothers effectively appropriated Magie’s key design elements (naturally, without her knowledge), but they did something terrible to the original. They cut the second, “fair” part of the rules from the game, leaving only the mode of predatory accumulation. Thus The Landlord’s Game, created as a warning against the evil of monopolies, was repackaged into the commercial superhit “Monopoly” — a game that literally celebrated this in its name.

This made Charles Darrow the first “Game Designer” in history to become an official millionaire. Was this fame deserved? Well, while Darrow swam in money, telling the press a beautiful legend about how he allegedly invented the game alone, the real inventor Elizabeth Magie received only $500 from Parker Brothers and a categorical refusal of royalties.

Her name was erased from history for decades, and the patent was bought only to remove a competitor from the market. However, even half a century later, the truth could not be hidden, and the real history of authorship turned out to be far more fascinating than the official legend. (More about this relationship triangle between Magie, Charles, and Parker Brothers in the video «The Strange Truth Behind the Success of Monopoly» and «Who Really Invented Monopoly?»)

Magie’s patent itself (US №748,626) is not such a dry legal text after all. It is, albeit very short, a “full-fledged” design document for that era. But most strikingly, besides mechanics, it also contained ideology. Magie strove to show how landlords enrich themselves at the expense of tenants.

This strongly reminds one of modern GDDs, which have a “Design Pillars” or “Vision Statement” section describing the main goal and idea of the project. She was ahead of her time, fixing not just “how to play,” but “why to play.”

1913 — H.G. Well’s Tin Soldiers (Little Wars)

In childhood, while visiting my best friend, I often saw these whimsical but very beautiful tin soldier figures on the shelves in his father’s room. Back then, I thought it was just some “adult quirk” — statues for beauty, just another trinket that adults, for some reason, do NOT play with. It turned out the apple doesn’t fall far from the tree.

Today, hundreds of thousands of people collect detailed miniatures from the Warhammer universe and spend hours playing out full-scale battles on tabletops. But surprisingly, the root of both these hobbies is the same, and it’s not even the Kriegsspiel mentioned earlier (although it was partly the inspiration!). It is something far more personal and accessible, born of the imagination of a great writer.

About Little Wars

English writer H.G. Wells, the very author of The War of the Worlds, did something revolutionary for his time in 1913. He published the book «Little Wars», which is, in essence, the first mass-market manual for a military tactical game with miniatures (about this, but slightly deeper, is told in the video «The First Ever Wargame… sort of.»). Wells, being a passionate gaming enthusiast, systematized what people did spontaneously before him. He developed and, more importantly, wrote down simple and clear rules for playing with tin soldiers on the living room floor:

Movement rules for infantry and cavalry, measuring distance with a ruler.
Shooting rules using toy cannons (which actually fired projectiles!).
Conditions for resolving melee attacks.

It was a full-fledged, (turn-based!), combat simulation, but its goal was no longer officer training, but pure entertainment. This time, for the first time, game rules born in the head finally became not a tool for a narrow circle of specialists, but a full-fledged consumer product. The book became incredibly popular, was reprinted many times, and set the standard for documenting rules for an entire hobby.

The full title of Well’s book is an artifact of the era in itself:

“Little Wars: a game for boys from twelve years of age to one hundred and fifty and for that more intelligent sort of girl who likes boy’s games and books.”

Being a convinced pacifist, Wells even added a section to the rules with philosophical reflections on the futility of war.

But most important for us is the story of the birth of the idea itself. Wells recalled how one afternoon, after lunch, he and his friends started shooting a toy cannon at soldiers. At some point, he exclaimed that to turn this messing around into a real game, only one thing was missing — written rules. Soon, he created them.

This book became the spark that ignited a flame in a whole generation of future Game Designers. And one of them, Gary Gygax, one of the future creators of Dungeons & Dragons, not only drew inspiration from Little Wars but also wrote the foreword to its 2004 republication. Thus, the thread from Wells’ tin soldiers stretched directly to the birth of tabletop role-playing games (which we will talk about later!).

1938–1958 — Fundamental Works on Play (Huizinga, Caillois, Jünger)

I simply could not leave out this final segment of the chapter. It’s personal. I am madly in love with this trio of thinkers and have already devoted a separate, short piece to them and their works: «Why is everyone but Game Designers writing about games?»

What relation do their works have to the history of game design documentation? Directly, almost none. But to the formation of game design as a meaningful discipline, and not just abstract “entertainment” — the most direct one. I won’t go deep into their theories here, but I am obliged to close the period of “first manuscripts” beautifully.

Because long before the first pixels lit up on screens, scholars and philosophers were already investigating play as a fundamental human phenomenon. Their works, written decades before the birth of our industry, created that very theoretical framework upon which we, consciously or not, rely to this day.

Johan Huizinga, in his seminal work «Homo Ludens» (Man the Player, 1938), postulated that play is a primary and necessary condition for the emergence of all human culture. It was his famous thesis:

“Play is older than culture”

That turned everything upside down: play is not part of culture; rather, culture grows out of play.

A generation later, French sociologist Roger Caillois developed Huizinga’s ideas in the book «Man, Play and Games» (1958). He did what every system designer must do: he classified the unclassified. Caillois proposed an elegant system, highlighting four basic game patterns: Competition (agon), Chance (alea), Simulation/Role (mimicry), and Vertigo/Ecstasy (ilinx). He also introduced a scale ranging from free, spontaneous play (paîdia) to play with rigid, formal rules (ludus), essentially describing the entire spectrum of gaming experience.

And finally, standing apart, German philosopher Friedrich Georg Jünger, in his essay «Games: Key to Their Meaning», 1953, offered perhaps the most prophetic view. For him, play was:

“The only truly natural phenomenon in the world”

And he, as if looking into the future, predicted the appearance of our profession and, I am not afraid of the word, science:

“All this together would constitute the subject of a new science, the emergence of which today can only be dimly foreseen — a science that would consist not of mechanical inventions, but of the discovery of new rules of the game.”

With this thought, we will conclude our dive into antiquity. Ahead lie electricity, screens, and the first attempts to create those very “new rules of the game” for a completely new world.

III. 1966–1989: “The Birth of the Draft”

1966 — Meeting the Father of Video Games (Ralph Baer)

And so, in the mid-60s, in a world that knew neither arcade machines nor home computers, a man appears who turns this philosophy into an electrical circuit.

I am sure 99% of people don’t even know this name. And yet, while the fame of Nolan Bushnell (creator of Atari), William Higinbotham (creator of Tennis for Two), or Alexey Pajitnov (creator of Tetris) resounds in the gamedev pantheon, the figure of this man — Ralph Baer, undeservingly fades with every passing year.

But if we look at these four as real people, we get a rather strange “family.” Higinbotham is the forgotten physicist uncle who accidentally invented electronic tennis and went back to doing science. Baer is the meticulous father who writes everything down, patents everything, and eventually drags the entire, newly formed industry to court. Bushnell is the rebellious son who saw Baer’s ideas, made an arcade out of them, and turned video games into a more successful business. And Pajitnov is the grandson from another country and another era, who would later bring Tetris into this family album.

And yet, it is Baer who should rightfully be considered the father, or even the grandfather (although this is debatable given the figure of Higinbotham), of all video games or, at the very least, of game design documentation.

Why? Because on September 1, 1966, while his colleagues at Sanders Associates were racking their brains over improving the quality of black-and-white TV, Baer was thinking about something slightly different. Sitting on the steps of a bus terminal in New York, waiting for a colleague, he sketched out an idea in a notebook that would subsequently become the patent: «Appliance for Playing Games on Ordinary TV Set». And all this on 4 pages of a worn-out notebook in his spare time.

Before we continue our conversation about the documents that started it all, I must make a remark. One can and should read about Ralph Baer, his patents, and his legacy in detail on his official website —ralphbaer.com. There you can also buy his book «Videogames: In the Beginning» (based on which this chapter is written) or, since it is an old and valuable read, access it for free on the Internet Archive. And if you want to meet him, so to speak, in the flesh (these videos were filmed shortly before his death more than 10 years ago), then be sure to watch the documentary videos «Meet Ralph Baer, the Father of Video Games» or the more modern version «Father of Video Gaming — Life and Times of Ralph Baer».

About Ralph Baer

So, what matters is not that he proposed playing on a TV screen, but how systematically he approached the matter. Baer immediately described a whole platform with several classes of games in his four pages:

Action and Chase (two dots chasing each other).
Sports Games (the prototype of Pong and tennis).
Board and Card Games.
Artistic Applications (creating patterns).
Educational Games (arithmetic, geometry).
Chance Games.
And also a Game Monitoring system.

He also thought through the commercial side of the issue: The device, according to his preliminary estimates, was supposed to cost about $24.99 and connect to the TV via a separate channel (he called it Channel LP — “Let’s Play!”). Besides game concepts, Baer immediately proposed technical details for implementation on 60s electronics: signal generation, color effects, noise patterns, etc. He both invented the game and laid the architectural foundation for an entire spectrum of interactive scenarios.

The document initially had a rather strict legal form: Each of the four pages was dated and witnessed by engineer Bob to secure the priority of the invention. Even then, Baer understood: properly executed documentation is a powerful weapon for the future.

(By the way, later this “weapon” would fire at full blast in the Magnavox vs. Atari case. If you want to read how Baer’s neat signatures turned into the basis of the first major legal scandal in the video game industry, check out the breakdown on r/HobbyDrama — Video Games: Atari vs. Magnavox and the origins of videogame licensing)

Further development quickly went beyond the scope of a single document: Over the next few years, Baer, together with colleagues Bill Harrison and Bill Rusch, created a series of prototypes TVG #1–8.

TVG#1 (vacuum tubes) — just moving two dots.
TVG#3 — color mask, first experiments with “feedback noise.”
TVG#4 — “ball,” an idea by engineer Bill Rusch: a dot controlled by the circuit — and immediately Ping-Pong and Handball are born.
TVG#7 “Brown Box” — wooden case, switch cards, two gamepads, and a light gun. You can already play Soccer, Volleyball, Target Shooting, Golf, and even “draw” patterns in artistic mode.

This “Brown Box” was the first full-fledged gaming system that included not only switchable modes (ping-pong, hockey, golf, target shooting with a light gun) but also a mechanical game selector via interchangeable switch cards — effectively the prototype of modern cartridges.

Baer literally lived by the principle:

“From day one — take notes. Even if they are just scribbles. Everything must be saved, signed, and dated.”

And it was this meticulous approach that allowed him not only to create the first home game console (literally more on that in a moment) but also to successfully defend his patents, earning millions of dollars in numerous legal battles with other gaming giants, starting with Atari and continuing with Nintendo and Sega.

It is impossible to overestimate the legacy of the four-page document of 1966. Baer himself considered it so significant that he later donated the original, along with the first prototypes of the console, to the Smithsonian Institution, calling it:

“The document that started the history of video games.”

It’s funny that if you ask an average person “where did video games begin” (and yes, besides my text, the answer to this question is in the beautiful and interesting video «The First Video Game»), they will likely mention Spacewar, Pong, or in the extreme case — Tetris. But outside of mass memory, history looks much stranger. The real starting point for lawyers, historians, and museums (and in this case, for us) is the neat dates and signatures under Baer’s patent. And if you trace step by step how these four keep circling each other, a series of scenes with a touch of absurdity emerges.

In the first one, Baer and Bushnell shake hands on the courthouse steps during the proceedings between Magnavox and Atari over Pong (which I mentioned just above); around them are folders with patents, lawyers, and references to that very 1966 notebook intended to secure priority for television games.

Meanwhile, lawyers deepen the excavations and pull Tennis for Two out of the archives: physicist William Higinbotham is invited to court as a witness, and his oscilloscope tennis, once made to liven up a boring exhibition, turns into an argument in the dispute of big companies and an important marker of the “zero point” of video games.

Then Baer tries to turn a rival into a colleague: sends a fax in 1977, comes to the Classic Gaming Expo in the late nineties, prepares for a symbolic match in Pong, which never happens, and in the mid-2000s neatly describes this whole series of unfulfilled meetings in letters.

Later, Bushnell calmly recounts in an interview that he saw Baer’s Odyssey and that his arcade tennis resonated with the early experiments of other engineers.

And parallel to this runs the Pajitnov branch: Tetris appears in a Soviet research institute, goes through a chain of licensing wars, turns into a global symbol, and in 2024 the game’s fortieth anniversary is celebrated in Los Angeles at the World Tetris Day party, where Bushnell sits in the hall among the guests.

At some point, if you imagine how a single line runs through all these dots — the court, the oscilloscope, the arcade hall, the programmer’s office in Moscow, the anniversary party with tetrominoes on the screen, then… It becomes a bit unsettling: you realize you are holding in your hands a history that started with a couple of pages in a notebook and gradually populated the entire world with games.

And this is, on the whole, not an exaggeration: It contained almost all key elements — from gameplay and genre variety to the idea of peripheral devices. This is far more than needed and, of course, not exactly what is needed for a GDD, but what do you expect from the first console and an attempt to form entire genres?

However, designing such a platform is only half the battle. Explaining to millions of people who have never encountered anything like it exactly how to play is a completely different task. That is how the need to create new documentation for a mass audience arose.

1972 — Rules for the First Video Games (Odyssey)

Whatever your first console was in your memories, be it Atari, NES, Sega Mega Drive, or the more modern PlayStation and XBOX, your idea of it boils down to a simple principle: insert cartridge or disc, turn on — play.

But the world’s first home game console, Magnavox Odyssey (that very “Brown Box” by Ralph Baer), was… something completely different. All games, in essence, existed not inside the console, but… outside?! The console itself was just a generator of moving dots. And the entire gaming experience, the whole meaning of what was happening on the TV, was created with the help of transparent plastic overlays on the screen, tokens, dice, and, most importantly for us, in the rule book.

Imagine this design task. How to introduce the user to this box, full of whimsical gadgets, and a couple of squares moving on the screen, when they have absolutely no experience interacting with anything like this? The concept of “Video games” simply did not exist.

It was here, analyzing this part of this period, that I honestly experienced my biggest cultural shock. I am talking about the so-called «Odyssey Installation and Game Rules» (no, really, open this link right now!) — essentially, a collection of 34 rules for different games. And while up to this moment, I confess, I often stretched the definition with patents and clay tablets, calling them proto-GDDs, this document… this is truly a real, full-fledged monumental document! The first step from an engineering blueprint to a player manual, but how did it happen?

About Magnavox Odyssey

So, it is 1972, and Baer’s engineering ideas, meticulously recorded in his notes, finally take commercial form — the first home game console, Magnavox Odyssey. If the previous chapter was about creating the platform and its prototypes, now it is high time to understand how to explain to millions of ordinary people what to do with a box that outputs only a few moving dots.

It is important to clarify immediately: Odyssey had no processor or programmable logic. It was an entirely analog construction consisting of discrete transistors, diodes, and resistors. That is why the box, besides the console itself and two controllers, was literally stuffed with various physical things and printed materials intended to compensate for hardware limitations:

Six game “cartridges” (not to be confused with familiar ROM cartridges, these were just switch circuits that changed the logic of dots on the screen).
Ten vinyl overlays attached to the screen via static charge, adding “graphics” for each game.
Cards, dice, poker chips, and even paper money.
And, most importantly — the 36-page manual «Game Rules». (that very «Odyssey Installation and Game Rules»)

It is this manual that deserves our close attention. It can safely be considered the first mass-market GDD that fell directly into the hands of end players. Each of the twelve game scenarios included in the base set was described in the form of step-by-step instructions containing:

Specific goal of the game.
Detailed setup (choosing the switch card, applying the overlay to the screen).
Scoring rules (yes, players had to count points manually).
Fully written turn structure.

For example, the famous “Table Tennis” was represented on the screen by just two dot-paddles and a line-net. All the rest of the logic — service rules, counting points up to 15 — was entirely left to the players and the manual. The score had to be marked independently, on paper or using special chips.

An even more striking example was the game “Haunted House.” It was supplemented by a paper maze map and a deck of cards with text tasks. One player controlled the “ghost” dot, and the second — the “detective,” who moved across the paper map, following instructions from the manual.

By the way, Ralph Baer himself noted in his book that for early demonstrations, he even recorded an audio cassette with voice instructions, understanding how important it was to clearly convey to the user the rules of this new, unseen entertainment.

With this approach, Odyssey demonstrated how closely documentation can be integrated into the gameplay when the hardware is not yet capable of independently implementing all game logic.

And this, perhaps, is the whole magic of that moment. We, modern designers, write documents in the hope that they will one day be embodied in code. We create a blueprint for the internal logic of the game, which is reproduced by a computer. But Ralph Baer and his team wrote a document that became a game with the help of the player themselves. Their game engine was not silicon, but paper, and the main processor executing the rules was the human being.

In 1972, the manual, the design document, was not an instruction for the game. It was the game.

1970–1974 — The Birth of RPGs and DIY GDDs (Chainmail, Blackmoor, Dungeons & Dragons)

When talking about Dungeons & Dragons, it is impossible not to mention Chainmail and Blackmoor — in essence, these are all iterations of the same game, the same design document (rulebook), which ultimately crystallized into the first “full-fledged” edition of D&D. And as I promised, that very thread, stretched from H.G. Wells’ tin soldiers, will now lead us to the goal.

By the 1960s, a whole subculture of “wargamers” was flourishing in the USA. It was fertile soil: Magazines were published, conventions were held, and enthusiasts constantly exchanged their own “house rules.” For Gary Gygax, one of the most active participants in this community, Wells’ book was a true revelation. It legitimized “playing soldiers” for adults and, among other things, showed that rules could and should be written down, creating self-sufficient systems for entertainment that could be shared.

It was in this vibrant environment, where anyone could become a designer by writing their own rules, that the first official step toward D&D was born — a rulebook called Chainmail.

About Chainmail

Initially, in 1971, it was an ordinary medieval wargame with miniatures. Gary Gygax, together with Jeff Perren, developed a set of rules for battles of knightly armies, relying on amateur developments and popular scenarios of that time. Guidon Games published Chainmail as a small booklet «Chainmail — rules for medieval miniatures», and it quickly became a hit within a narrow fan circle.

However, the main feature, the very element that changed everything, was the section — «Fantasy Supplement». As Gygax himself recalled, he grew bored with strictly historical battles. Influenced by the works of J.R.R. Tolkien and Robert Howard, he decided to enliven the battles with wizards and monsters. For the first time in a commercially available wargame, dragons, elves, hobbits appeared, as well as heroes and wizards capable of casting lightning and fireballs.

It was the first attempt to systematically document and, more importantly, balance fantasy elements. The rules clearly stated that a “Hero” is equal to four ordinary fighters and requires four simultaneous hits to die, and the “Fireball” spell has a specific blast radius in inches on the game board.

From a documentation standpoint, Chainmail was a product of its era: typewritten text, amateur illustrations, cheap paper. In retrospect, its significance is important merely as part of an iteration. It is the first documented iteration of the combat system that would lay the foundation for D&D. (For those who want to hear this story from the lips of the participants themselves, there is a video «Chainmail 50th Anniversary», where they share their memories).

But any rulebook, even the most brilliant one, is just a tool. The real magic here happens when it falls into the hands of another creator who sees in it not just a way to enact battles, but something much greater. And while Gygax and Perren were standardizing the rules of fantasy warfare, in another state, a young enthusiast named Dave Arneson was asking a completely different question:

“What if these rules are not for armies, but for a single hero?”

About Blackmoor

The entire complete, tangled, and incredibly fascinating story of what happened next is brilliantly told in the documentary mini-series «Secrets of Blackmoor — The True History of Dungeons & Dragons». This is gripping and interesting material for anyone who wants to understand where D&D truly originates.

But for our purposes, for the history of GDD, the key moment is this: Arneson, tired of the strict rules of his “Napoleonic” campaigns, unknowingly committed a revolution. He lowered the action underground, shifted the focus from a massive battlefield to the cramped corridors of a castle with dungeons. From an entire army to a single character.

And before we continue, let me ask a question. Does this sound familiar?

A constantly evolving world with its own history and rumors.
Individual characters with classes, characteristics, and levels.
Gaining experience and treasures for exploring dungeons.
Using graph paper to draw maps.

Everything we love today in games from Skyrim, Diablo, and Baldur’s Gate to Civilization and modern MMOs — someone already did. Not on a computer, but on paper, in a basement in Minnesota.

To realize this idea, insane for those times, Arneson took Chainmail as a basis, adapting its rules for one-on-one combat. But everything else — the core and DNA of the entire RPG genre — he invented and “documented” himself:

Personal characteristics and classes (fighter, magic-user, and others).
Health points (full-fledged HP — Hit Points!).
Both experience (XP) and levels for progression.

Initially, the Blackmoor campaign rules were not formalized as a single code. Arneson ran the game relying on his own handwritten notes and masterly improvisation. He even released an amateur bulletin for players, the «Blackmoor Gazette & Rumor Monger» — essentially, the first form of “patch notes” in history describing events in the game world. But a full-fledged “rulebook” that could be passed to another person did not exist.

And therein lies, perhaps, an amusing irony. The greatest role-playing campaign, which launched an entire genre, was born not from a clear, structured document. It was born from 18 pages of creative chaos, seemingly understandable only to the author himself. These were just personal notes, which, however, turned out to be enough to trigger a dramatic chain of events.

Gary Gygax, having learned about Arneson’s successes, did what any Game Designer should do upon hearing about a revolutionary idea: he invited him over to see everything with his own eyes. In late 1971, Arneson arrived in Lake Geneva and ran a game session for Gygax.

(A curious detail: in Lake Geneva, where this first meeting unfolded, today you can see a memorial plaque engraved with a D20 and a dragon. In the town where D&D took its first real step, this plaque looks surprisingly appropriate. A modest shot that could open a documentary film.)

For a man accustomed to large-scale battles on open terrain, this experience — exploring cramped dungeons in the role of a single hero — was a revelation. He saw the heart of a completely new gaming experience in Arneson’s chaos. Gygax understood: this could be turned into something special.

Thus began their legendary collaboration. The mechanism fell into place naturally: Arneson was the generator of ideas, and Gygax was the editor who gave these ideas form. Arneson sent Gygax that very draft, 18 pages of scattered, xeroxed notes.

And the saddest part of the story of these “18 pages” is that, honestly, no one has ever seen them. Not a single confirmed scan, not a single photocopy: historians like Dan Boggs write directly that we have neither the original nor copies, only scattered testimonies of Gygax, Kuntz, and other participants in early events. Boggs, in his breakdown article «The Mystery of the 18 Pages of Notes», carefully records how even the number of pages changes in different sources, and Jon Peterson in «Playing at the World» fits this mythical package into the chronology: somewhere at the end of 1971, Gygax receives “18 pages of rules and additions to Chainmail” and sits down to work on his version.

However, these pages themselves have not survived, like a lost piece of a mosaic, the shape of which we can only guess because the other fragments join in a strange way.

And yet Gygax, upon receiving them back then, admitted that he could decipher literally nothing in them. And here a fundamental conflict of two design philosophies manifested itself, which remains relevant to this day.

Arneson was a proponent of improvisation and imagination. He believed that it is impossible and unnecessary to create a rule for every case.
Gygax, on the contrary, was a pedant and a systematizer. He believed that to create an understandable and, importantly, sellable product, a clear, exhaustive structure was needed.

This is how Arneson jokingly explained Gygax’s decisive role as an editor:

“He could type, and I couldn’t.”

Behind this joke lies the essence: While Arneson generated revolutionary concepts, Gygax, communicating with him by phone (the phone bills, according to Arneson, were impressive), pedantically reworked them into coherent, structured text.

It was Gygax who added to the game what made it a finished system:

Clearly defined character classes.
Expanded lists of weapons, equipment, and spells.
Tables for generating characteristics using different types of dice.

By mid-1973, the co-authors had a manuscript ready. Legends have it that the final title “Dungeons & Dragons” was born when Gygax’s four-year-old daughter, hearing it, exclaimed:

“Dad, I like ‘Dungeons & Dragons’ best!”

But several drafts from those years have also reached us, for example, the «Dalluhn manuscript» — a text considered the earliest surviving compilation of rules. These artifacts show that by the end of 1973, the core of D&D was formed. The last, most important step remained — to publish this new type of game and bring it to the world.

About Dungeon & Dragons.

“We can sell 50,000 copies”

Lacking confidence that major publishers would understand their concept, Gygax and Arneson first tried offering D&D to third-party companies. Gygax even presented the game to the industry giant — Avalon Hill. With “honed” commercial enthusiasm, he assured them. However, Avalon Hill was merely bewildered.

“They couldn’t understand a game where there are no winners or losers, which just keeps going,”

Arneson recounted.

Faced with rejection, in October 1973, Gygax decided on a desperate step: to publish the game himself. Together with a friend, he founded his own firm — Tactical Studies Rules (TSR).

The first “headquarters” of TSR sounds grand only in retrospect. In reality, it was the basement of Gygax’s house at 330 Center Street, Lake Geneva. A small room cluttered with boxes of miniatures, drafts, and papers. A couple of tables, shelves, and a typewriter — that was the entire “office” from which the first rules were sent to print. A simple, cramped workspace that perfectly reflected how the company began.

In January 1974, the first thousand copies of Dungeons & Dragons were printed. The game came in a boxed set format, inside of which lay three rule booklets:

«Men & Magic» — character creation and magic rules.
«Monsters & Treasure» — bestiary and description of valuables.
«The Underworld & Wilderness Adventures» — guide for the Master.

These three thin booklets, printed on cheap paper, with typos and amateur illustrations, became that very first “GDD” for the newly emerged genre. But the most important thing was hidden in the details; the title page read:

“Rules for Fantastic Medieval Wargames…”

And in the preface, the authors directly recommended that players have the Chainmail rules on hand to resolve complex battles and even a map from another board game (Outdoor Survival) for world travel.

And herein lies an unusual difference. If Ralph Baer created a finished, self-sufficient product, then Gygax and Arneson released an open platform for creativity. Their “design doc” was not a strict instruction, but essentially a mod, an add-on over already familiar games, inviting players to think further, experiment, and create their own worlds.

The initial print run sold slowly but surely. And then, thanks to word of mouth, interest began to grow. Players across the country discussed the outlandish game, asked questions, and offered their own rule variants and new monsters.

It was then that the second revolutionary feature of D&D documentation appeared: It was living and iterative. To answer hundreds of questions, in 1975 TSR began publishing the magazine «The Strategic Review», where Gygax personally clarified controversial points and, in essence, “patched” the game by publishing system updates.

Thus, by 1974, Dungeons & Dragons had turned from an author’s draft into a cultural phenomenon. Its first three booklets, though they looked modest, set a standard that is alive to this day: “Player’s Handbook,” “Dungeon Master’s Guide,” “Monster Manual.”

By the way, while forming this whole thought and piecing the history together, two videos from the channel DM It All helped me greatly. The first, «The History of Original Dungeons & Dragons» tells precisely about the period we just analyzed. The second, «The History of Advanced Dungeons & Dragons», narrates the next stage of the company’s development, and although I couldn’t note anything particularly important there specifically for the history of GDD, I nevertheless strongly recommend watching both — they brilliantly convey the spirit of that era.

1978–1984 — The Golden Age of Arcade Games (Space Invaders)

Despite the loud title “The Golden Age of Arcade Games,” for the history of game design documentation, this period remains surprisingly modest. No matter how much I searched (and believe me, I dug through a hundred different sites and videos), there was essentially nothing particularly significant that could be called a “full-fledged GDD” during this time.

Okay, I’m fibbing a bit. After all, one figure and one game still shine to this day, remaining one of the most cited phenomena in media — Tomohiro Nishikado and his Space Invaders.

But before we talk about the “Invaders,” we need to answer the main question:

“Why was no one documenting game design at this time?”

And the answer is both simple and complex. First, and this is obvious, arcade games were mechanically simple. Often it was one key mechanic and a maximum of five minutes of truly interesting, engaging gameplay (which was extremely addictive, by the way), designed to eat your coin.

Second, I do think “design documents” existed. They just didn’t have a formal, archivable form. Industry giants like Atari, Namco, Midway, or Taito and their talented programmers couldn’t just be shooting in the dark, making interesting games. It seems to me (and these are admittedly guesses with a dash of observation) that everything we might call a design document was kept in offices on whiteboards, on sticky notes attached to monitors, or in verbal speech between colleagues.

And there wasn’t much need for it if the idea is so simple that it can be described in one sentence:

“A ship shoots at aliens that are descending lower and lower.”

Game design was certainly forming, and many brilliant decisions were made in this era. But the text is dedicated specifically to documentation. Technical documentation (board schematics, device patents) certainly exists. But is it worth our attention in the context of design? I believe not.

But if you are still interested in this short but significant period in general, there are several excellent videos to help you immerse yourself: «Video Game development throughout the 80s», «The Golden Age of Arcade Games» and «What Happened to Arcade Games?».

And now to that very shining exception. To the game and to the man who, unlike many, left traces behind.

About Space Invaders

Space Invaders stands out against its contemporaries for several reasons, and each of them is, in essence, a lesson in game design and its documentation.

First is the conceptual design. Knowing about the existence of Breakout from Atari, Tomohiro Nishikado wanted to create a game that gave the player more control. A picture was immediately born in his head: An enemy army is advancing from the top of the screen, which must be fought off. Thinking through the images, he went through options: planes, tanks, soldiers. But planes and tanks looked ridiculous in pixels, and shooting at little people would have been too cruel for the Japanese audience of those years.

And here history makes another circle. Learning about the release of Star Wars and remembering a book with interesting “marine alien creatures,” he turns again… to H.G. Wells’ “The War of the Worlds”! And so, the thread stretched from tin soldiers has reached all the way to Japanese arcades.

As a result, Nishikado made the first sketches of the future enemies. And these first, now cult, sketches of pixel aliens — in theory, can be considered the first concept document of this era. It is the fixation of visual design born of meaningful choice.

Second is the system design and its fixation. While most arcade machines had static or linearly increasing difficulty, Space Invaders gave us one of the most famous and elegant difficulty curves, which was born… from limitations.

The fact is that hardware back then was limited in sprite rendering speed. When a whole army of aliens was on the screen, the game ran slowly. But as the player destroyed enemies, the load on the processor dropped, and the remaining aliens began to move faster.

Nishikado could have “fixed” this by normalizing the speed. But he acted like a true Game Designer — he turned the limitation into a mechanic. This decision was not accidental. To check the logic of the behavior of this complicating system, he kept flowcharts.

And although even with the help of neural networks I couldn’t squeeze any intelligible information out of these papers (but we will trust the sources!), the very fact of their existence is a breakthrough. It doesn’t matter if they described the logic of the code or the gameplay. A flowchart is a tool for visualizing a system used by hundreds of thousands of Game Designers today. And this is, perhaps, the very first of the known flowcharts used as a game design tool.

Space Invaders shows that even in an extremely simple arcade game, design decisions can be deep and systemic, and their fixation, be it concept art or a logical diagram, helps turn an idea into a legend.

But the golden age of arcades was short-lived. Technology did not stand still. And while coins were pouring into machines, a new revolution was already brewing in homes and universities, which would require far more complex and detailed documents from designers.

1985 — Three Geniuses, Two Brothers (Donkey Kong, Super Mario Bros)

Ahem, apologies for the lyrical digression, but I simply must address this MASSIVE point. If I tried to list all the videos worth watching and articles worth reading to realize the greatness of Shigeru Miyamoto and Takashi Tezuka, it would take several pages.

Here is just a small part (and only videos):

I will tell you the gist of everything right here, specifically about documentation. But it is simply impossible not to note how strongly Miyamoto and his colleague, and concurrently best friend, Tezuka, influenced the gaming industry and, in our case, game design documentation. Therefore, I will merely note that even in such a large text, I will miss a lot, and I advise those particularly interested to catch up using the videos above.

And now — to business. To how these two geniuses designed some of the most important games in history.

About Donkey Kong

To begin with, we should dot all the “i”s and cross all the “t”s, pointing out the unique role of Shigeru Miyamoto. As he himself recalls and admits:

“In the beginning, the people who made video games were technologists, they were programmers, they were hardware developers. But I was not. I was a designer, I studied industrial design, I was an artist, I drew pictures.”

And therein, perhaps, lies the key. His thinking was not burdened by the weight of technical limitations. In his head was not a line of code, but a picture. Not a function, but an emotion. He designed not a program, but an experience he wanted to convey to the player. An experience he himself had felt in his childhood.

And the first such documented sketch of this experience turned out not to be Super Mario Bros, but Donkey Kong. And yes, I know that chronologically this game should have been in the chapter about the golden age of arcades. But precisely here, in the context of Miyamoto’s thinking, this artifact looks most logical and correct. After all, it was almost the only arcade hit that had such a history and such an approach to design.

It all started with a simple one-page document — a game concept for an arcade machine. And who do you think Miyamoto saw in the main roles? Mario?

Not at all.

Initially, and this is even stated in the document, the main characters were supposed to be from the cartoon “Popeye”: Popeye himself as the savior, his sworn enemy Bluto as the kidnapper, and Olive Oyl as the damsel in distress.

But Nintendo never received permission to use these characters in a separate full-fledged game (although Nintendo, together with the creators of Popeye, had made games before this). This is one of the most fortunate “no’s” in the history of the industry. Because it was this refusal that forced Miyamoto to create two of his own, now legendary characters — Mario and Donkey Kong.

This early concept document is important to us not only as a historical curiosity. It shows the principle of Miyamoto’s thinking: He put the interaction system — the game loop — at the forefront.

“Climbing ladders and dodging (obstacles), rescue Olive (Olive Oyl)”

This skeleton was so strong and understandable that any skin could be “put” on it, be it a sailor or a plumber. And it was this approach to design, focused on intuitively understandable gameplay, that formed the basis of the next, truly great design document.

About Super Mario Bros

As Miyamoto made games for Nintendo, he met two figures critically important to our history. The first was Takashi Tezuka — another Game Designer who, in tandem with Miyamoto, would create not only Mario but also The Legend of Zelda. The second figure, who became their hands and heart, was programmer Toshihiko Nakago. (And here I cannot help but make a personal remark: Game Designers, never forget your programmers or anyone from your team! If you are reading this — you are the best!) It was Nakago who joined the team to embody the ideas of the two geniuses in code.

And right here, in the process of the birth of the idea for a new Mario game, something happens that forever changes the approach to development and, as a consequence, to its documentation. For the first time in our history, pre-production and prototyping appear so clearly as a conscious stage.

Miyamoto, thinking about how the game should feel, about the character’s size and jump height, drew several dozen sprites. And then he asked Nakago to make a small prototype that was supposed to answer the main questions about the core of the entire game — about the jumping mechanic.

As a result, a couple of days later, Nakago showed a prototype: There was no Mario, no enemies, no mushrooms on the screen. There was only a red dot jumping and running across the screen. And most importantly — its parameters could be easily changed to achieve the desired response, the desired feel of the game.

This prototype was not a game build in our usual sense, but a tool for calibrating feelings. It was created to answer the most fundamental questions:

How high should Mario jump?
How fast should he accelerate and stop?
What should the jump timing be to feel responsive and pleasant?

And all this was subordinate to one single, but most important question, which formed the basis of the entire future philosophy of Nintendo:

“Is this fun to PLAY?”

Precisely “play,” and not “story,” “graphics,” or anything else, is the pillar of game design for 90% of all Nintendo games to this day.

They didn’t test the level. They didn’t test the graphics. They tested the core of interaction itself, the most basic gameplay loop: Pressed a button — received a pleasant, responsive emotion. And only when the answer to this question was:

“Yes, it’s damn fun!”

Did they move on to the next stage — designing the world in which this mechanic would live.

Now that the gameplay core was found and calibrated, a new, much larger task stood before this trio: To build a whole world around this delightful, perfected jump.

And here Miyamoto and Tezuka, as Game Designers, for the first time in our history, begin to think in entire systems of game experience. They drew levels, they designed an adventure. And the tool for this became those very, now legendary, planning sheets on graph paper.

These were thoroughly elaborated technical design documents, real engineering blueprints created taking into account all the limitations of the Famicom console.

Each square on the sheet corresponded to an 8x8 pixel screen tile.
Each block, be it a brick, an enemy, or a “?”, was not only drawn — it was supplied with a color code or annotation understandable to the programmer.
The sheets even had structured fields for the date, author’s name, and comments, which reflects an almost “assembly line” approach to level design.

The goal was not just to draw a beautiful level, but to plan it within the rigid limits of the hardware. The designers thought in advance where objects could be reused to save precious memory, and how to distribute enemies so the game wouldn’t lag.

But despite this engineering precision, it was an incredibly creative process. Miyamoto and Tezuka placed translucent tracing paper over the original drawings to experiment with changes, try new ideas, move enemies and blocks without destroying the original plan. In essence, this was the first analog form of version control in game design documentation.

Moreover, in this creative cauldron, ideas were not rigidly tied to one game. It is important to remember that Super Mario Bros and The Legend of Zelda were developed almost in parallel. They created mechanics and ideas that, as drafts and sticky notes show, freely migrated between projects. The idea of a secret passage or unusual enemy behavior, invented for Mario, could eventually find its place in the dungeons of Hyrule, and vice versa.

Miyamoto and Tezuka, like architects, designed entire emotional journeys on paper. And then they handed these blueprints to Nakago, their “builder,” and his crew, who were already sure that by the time of programming, the level was thought out, technically feasible, and, more importantly, fun to play.

These planning sheets are a real GDD in the form of an engineering blueprint, which combined creative vision, system design, and low-level technical requirements.

And even though I am missing many small but brilliant Game Design decisions made during iterations of both the documents themselves and the game, the success speaks for itself.

Such an approach, where design went hand in hand with the entire team from the very beginning to the very end (literally, since Miyamoto himself drew the final cover for the release in the last days), allowed creating such a verified and polished game that all fears related to console limits turned into a triumph. The game was so optimized that in the end, it took up only 32 kilobytes! (For the particularly meticulous, I advise a thread on Reddit where there are short explanations and links to interesting videos: «Super Mario Bros. game was just 31 Kilobytes. How’s that possible?») This even allowed Miyamoto to joke that they needed to “fill it up” to the standard 40 kilobytes, suggesting to the team:

“Well… Let’s add more blocks there?”

The approach of the three genius Japanese men showed the whole world that a well-thought-out game can not just sell well. It can immortalize itself, becoming a symbol of an entire generation.

And if there is a starting point for the modern game design document in that embryonic form in which we now know it, then this is the moment. It was the moment when the GDD ceased to be a concept, a set of rules, a technical assignment, or a piece of bureaucratic paper. It became a true tool of creation: Precise as an engineer’s blueprint, and inspiring as an artist’s sketch.

But we were still far from the era of true “Bibles.”

1987 — Treasure Maps of the GDD (Maniac Mansion)

What unites such modern games as Until Dawn, Life is Strange, Detroit: Become Human, and, for example, Road 96? Roughly speaking — variability. The illusion of choice. Non-linearity. A branching narrative, like a circulatory system, where every decision you make seems to matter. Today, as players, we take this for granted, but as Game Designers, we know that a monster hides behind every such fork in the road.

Because as soon as you give the player freedom of choice, your design task begins to grow exponentially. Every new decision, every dialogue, every possible interaction is a new head growing on the hydra of narrative design. And the more choices there are, the harder it is to keep track of this beast so it doesn’t get tangled in its own tentacles and devour itself.

But to understand how we even learned to tame this beast, we need to go back to 1987. To where four bold, delightfully naive dreamers from Lucasfilm Games decided to create not just a game, but a whole world living by its own non-linear laws. They didn’t just reinvent the adventure genre; they faced the same fundamental problems that trouble writers and designers of non-linear narratives to this day, and found an elegant solution for them.

This is an incredibly significant milestone in our history. A milestone about freedom, about Lucasfilm, about creative audacity, about SCUMM, about a hamster exploding in a microwave, and about how simple papers help unload our perpetually overloaded brains when we try to keep not one, not two, but dozens and hundreds of interactions, stories, and events in our heads.

About Maniac Mansion

And again, first of all, I must scratch a massive itch and lay my cards on the table. This part of our history is largely based on materials that I strongly recommend everyone watch to feel the spirit of that era:

And now to the point.

One can relate differently to George Lucas, his franchise, and his early business decisions, but denying his genius as an investor in talent is pure disingenuousness. After all, there is no better investment than investing in people, in their minds and their creative potential.

That is why the team creating Maniac Mansion was in completely unique, almost laboratory conditions. They were given a budget. They were allocated a separate house, given complete creative freedom, provided with food and everything necessary for life and work, essentially being told:

“Create. We believe that in the future this will recoup all invested funds.”

And just imagine this picture: Four (actually, a few more) young, ambitious people full of ideas and rebellious spirit — Ron Gilbert, Gary Winnick, David Fox, and Carl Mey — find themselves in this creative sandbox under the wing of the most influential and intelligent man in the entertainment industry at that moment. This meant only one thing — it was time to do something great.

But even here, Lucas showed his foresight. He forbade his internal studio from making games based on his own franchises. This didn’t mean he didn’t want Star Wars games — other companies made them under license. It meant something far deeper. He didn’t want his game studio to turn into a soulless merchandise production line. He wanted them to create new worlds, not exploit old ones. He gave them something more important than money; he gave them the most valuable thing a producer can give — the right to their own vision.

And so, without access to Jedi and lightsabers, but possessing boundless creative potential and full support, this team began pondering their first, truly own idea for a game. And it was in these conditions, free from the dictates of a franchise and commercial pressure, that those revolutionary approaches to design and its documentation, which we will now discuss, were born.

What immediately distinguished the process of creating Maniac Mansion from everything we had seen before was the culture of open creativity. Inside the team, anyone could suggest an idea, and if it resonated, it was immediately documented and put into circulation. Thus, pitch documents quickly began to circulate around their “office” — and these were some of the earliest examples of those very “pitches” we are used to seeing today.

On a few pages was everything needed to infect with an idea:

A bright logo.
Title page.
A brief description of the game, its goal, and how it should feel.
Interface sketches, concept art of characters, villains, and locations conveying the spirit of the future game.

One such pitch, «Maniac Mansion Design Doc», dedicated to the idea of a B-horror movie parody, was created in just a week, but the whole team and their manager liked it so much that it was decided — we’re doing it.

But despite the fact that the pitch document existed, the fundamental questions of “why?” and, far more importantly in their case, “how?” had yet to be answered. After all, for now, according to Ron Gilbert’s recollections, this game was merely a vague concept about “walking around a mansion and gradually uncovering the story.” And here we approach the second important fact of this history.

Adventure games existed before Maniac Mansion. But they were quite unfriendly toys. Imagine a game where you see a static picture, and all your actions boil down to typing verbs into a command line, trying to guess exactly which word the Game Designer intended: “TAKE LAMP,” “OPEN DOOR,” “TALK TO TENTACLE.” Guess the wrong verb — the game doesn’t understand you. It was a constant, exhausting duel not with the mysteries of the world, but with the syntax of the Game Designer.

It was this design horror that Ron felt. He essentially reassembled the adventure concept, adding innovations that lay on the surface but which no one before him had dared to implement.

The transition from text adventures to Maniac Mansion can be compared to the transition from the MS-DOS command line to the Apple/Windows graphical interface. It felt literally the same. Instead of forcing the player to guess verbs, Gilbert brought them onto the screen: “OPEN,” “CLOSE,” “USE,” “TALK TO” — all these became buttons. The player could simply hover the cursor over an object and choose how to interact with it. Thus, essentially, the point-and-click genre was born.

But this wasn’t the only innovation. By removing one headache, Gilbert created two others for himself. He conceived a game with multiple playable characters (initially up to 20! characters were planned), each with their own unique “abilities” and, consequently, their own unique ways of solving puzzles. He conceived a game with multiple endings. He conceived a world that shouldn’t break from the player’s actions.

The narrative design of this game was an order of magnitude more complex than anything done before. And to cope with this complexity, the team needed a new tool. A tool that would help them see this entire web of interconnections as a whole.

And so, after some time, when the initial excitement of creative freedom had subsided, that very monster they had spawned stood before the team in all its glory. To create a non-linear story with three playable characters that can be freely switched between. With multiple endings depending on who survived and what they did. With dozens of unique interactions for each item… This was a task that NO ONE had faced on such a scale before them.

The team was tormented by many doubts. But solutions came with them. And right here, studying the artifacts remaining from that time, for the first time in our entire history, we see the birth of narrative design as a separate, conscious discipline.

Looking at these documents, one must understand: What is now standard practice for us was a breakthrough for them.

Screen connection maps showing how locations are connected to each other.
Character-object interaction diagrams describing what will happen if a specific character uses a specific item.
Room flowcharts describing all puzzles, triggers, and object states in each location.
And, of course, branching plot diagrams in the form of lines and dots, showing how player actions lead to different consequences.

All this appeared here for the first time. They realized that to keep such a complex system in their heads, it needed to be taken out of the head and fixed on paper.

But when a problem is elegantly solved on paper, when all the logic is written out and the connections are drawn, the next, now technical question inevitably arises:

“And how do we program all this now without going crazy?”

And here we approach another brilliant innovation born of necessity. To SCUMM.

No, no one was getting “scammed.” SCUMM is a scripting language that literally stands for “Script Creation Utility for Maniac Mansion”. It was invented by Ron Gilbert and Aric Wilmunder precisely as a result of working on this game.

And the most telling moment, when design documents and a technical solution finally hit the same point, happened as follows:

After many months of development, the team was on the verge of frustration. The number of features, characters, and narrative branches they wanted to add to the game was rapidly shrinking under the pressure of harsh reality: Implementing all this on existing tools was almost impossible.

And on one such day, David Fox approaches a dejected, tired Ron Gilbert and says, “Come with me.” Ron, thinking he’s about to be shown another bug, reluctantly follows him to the console. David, controlling a character in the game, walks into the kitchen, points to a hamster in the inventory and to the microwave, and then says: “Go on, try it, Ron.”

Ron clicks on the hamster. Clicks on the verb “Put.” Points to the microwave. The hamster ends up in the microwave. Then he chooses the verb “Use” and points to the microwave again.

The door closes. The microwave starts humming. And a couple of seconds later, an explosion is heard. The screen goes “dark” for a moment, and when the light returns, only a red splat remains where the microwave was.

After which laughter rings out in the room. Long-awaited, liberating laughter.

What was actually important in this seemingly cruel scene? That the SCUMM system finally worked. And it worked so well that this entire sequence of actions with the hamster was “programmed” by David in less than ten minutes, without writing a single line of complex code.

From that moment on, creating complex game logic and non-linear interactions became incredibly simplified. SCUMM as a “programming language” for designers existed for decades more, and its logic and principles live on in the engines of modern AAA projects to this day.

And all because someone was “free” enough to dream of a complex, non-linear story, and smart enough to first write it down on paper, and then create a tool that would allow this dream to be realized.

Despite the uniqueness of the circumstances in which the Maniac Mansion team found themselves, their approach to documentation and understanding how to combine it with development remains relevant today. This story highlights a crucial principle: Competent documentation in the hands of competent people and an open team can not only crystallize an idea but also become a common language for the entire team, turning creative chaos into a working system that frees you from burnout.

This solid foundation — a combination of detailed paper planning and powerful tools in the form of SCUMM — allowed LucasArts to release a whole galaxy of legendary adventure games in subsequent years, which still play freshly and interestingly today.

But while a whole team was building complex narrative labyrinths, elsewhere one man alone was trying to document and recreate something entirely different — the perfect, realistic animation of movement.

1989 — Above the Director’s Chair (Prince of Persia)

Modern platformers, be it Celeste, Hollow Knight, Cuphead, or even Tomb Raider with Uncharted, were most strongly influenced by just two games. We’ve already analyzed the first one — Super Mario Bros. And the second… well, the title speaks for itself. It is Prince of Persia.

This story will beautifully close our period of “drafts.” So, meet another legend whose name you might not have heard — Jordan Mechner.

It is important to note: everything I will tell you next is not conjecture or a compilation of Wikipedia articles. My main source was the book «The Making of Prince of Persia». To get to the truth, I had to order the printed version of this edition, as only it contains the full, uncut journal entries of that period. It is this unique inside look that will allow us to understand how the masterpiece was created.

And now it’s time to drink a potion, rewind time, and see how one man practically single-handedly documented a revolution in game animation. Saddle up! Or, in our case, rather, onto the ledges and slabs.

About Jordan Mechner

To understand how and, most importantly, why Prince of Persia was created, one must first understand the man standing behind it. Jordan Mechner, above all, saw himself as a director. And this passion for cinema, this desire to tell stories through a camera lens rather than lines of code, was his guiding star. But the harsh truth of life, as often happens, had its own plans for him.

And these plans were stunning. While still a student at Yale University, Mechner single-handedly creates the game Karateka, which blows up the market and becomes the number one bestseller in the catalog of publisher Brøderbund Software. It would seem, here it is — success, the dream of any aspiring developer. But for a creative soul whose dreams lay in another plane, this success became more of a gilded cage. His journals of that period exude an almost existential weariness. After graduating from college and a not-so-profitable deal on Karateka, he feels emptiness:

“I don’t want to spend another three years moving pixels, even if it’s fun. I want to make movies.”

So, having finished college, with a small but sufficient reserve of money for a couple of years of quiet life, Mechner faced a choice: what to do next? Chase the dream of Hollywood or continue to strike while the iron is hot? By a lucky coincidence, the answer came by itself, assembling from three seemingly unrelated parts. First, fresh impressions from watching Indiana Jones: Raiders of the Lost Ark. Second, a fascination with the platformers of that time. And third, knowledge of rotoscoping — an animation technique that giants like Disney were using extensively at that moment.

All this came together in his head into one simple but fundamental question:

“Why has no one yet made a game where the character’s movement felt real?”

Even his own Karateka, with its very high-quality animation for its time, seemed to him insufficiently… alive. And other games on the market did not give this feeling. This was that very challenge that could reconcile the artist, the director, and the programmer within him.

A narrative challenge was added to this technical one. Inspired by the classic stories from One Thousand and One Nights and the movie The Thief of Bagdad, Mechner found the ideal wrapper for his idea. Thus began the development of a game that was supposed to bring “life” to the industry. In both the literal and figurative sense.

About Prince of Persia

To be honest, going into a detailed chronology of the creation of Prince of Persia is a thankless task. Even from Mechner’s own book, it is evident that the process was quite chaotic (if you want to dive a tad deeper but not drown in the book like I did… Then watch this video: «How Prince of Persia Defeated Apple II’s Memory Limitations»). Therefore, so as not to drown in this creative mess, let’s break everything down into three key components. And let’s start with the one that dictated the rules of the game — with limitations.

At the start of development, Mechner, having successful experience with Karateka under his belt, logically chose the Apple II as the target platform. In the mid-80s, it was still a popular home computer for which he already knew how to write code. The problem was that at this exact moment, tech giants started that very “megahertz race” (which in itself is an interesting topic for study, which I only mention in passing here), and it was changing the industry before everyone’s eyes.

Looking ahead, this decision came back to haunt him twice. First, by the end of development, the Apple II’s power became catastrophically insufficient to realize all of Mechner’s ambitions and his incredibly detailed animation. Second, both Jordan and the publisher had serious fears that the game, even if it turned out good, would be released on a dying platform and simply wouldn’t find its buyer.

“The Apple market is dying. … No matter how hard I try to convince people that there will be an IBM version, they act like it doesn’t exist.”

Did these fears come true? This rhetorical question is the ideal bridge to the most interesting part of this story.

After all, it was the limitations of the Apple II that forced Mechner to invent. The platform could not adequately play video, and in general, there was no accepted pipeline in the industry at that time for creating realistic animation. Now we have Motion Capture, procedural animation, and a dozen specialized programs. But back then, Mechner was helped by… a camera! And a brother. And a karate teacher? And MOVIES???

Well, jokes aside. It was this set of strange findings that formed the basis of animation that still looks incredibly smooth today. The technique that Mechner essentially invented for himself consisted of several stages. The first and main one was to find a reference and record it. The movements of the future Prince are the movements of his younger brother David, whom he filmed running and jumping around a parking lot. Some combat and falling animations were spied in classic adventure films. Watching the storyboards of this archival footage today is a separate pleasure.

But what is especially important for us as Game Designers is that the blind creation of animations in the “might come in handy” category did not happen. Mechner kept journals in which he described ideas, but also made sketches of specific character interactions with the environment. He thought through and documented on paper in advance exactly how the Prince would step on pressure plates, climb ledges, fall, and die from traps.

Having this well-thought-out plan on hand, he purposefully filmed the movements he needed. And then the magic of turning VHS tape into pixels happened. I will omit exactly how he did it. For us, the fact itself is important: every smooth and lively animation in the game was not born by chance. It was first documented as an idea, then fixed on film as a reference, and only then, frame by frame, transferred into the game with a specific destination.

And before we move on to documentation as an artifact, we need to understand the vice grip Mechner was in. As I already said, the limitations of the Apple II were brutal, especially for the growing ambitions of the game. Initially, he designed the game without combat, a pure puzzle-platformer where you had to find a way to save the princess. But everyone who played the early prototypes said the same thing:

“I like games where you can shoot things. In your game, there are no rewards other than moving to the next level… Pure survival without triumph.” — Tomi

And also:

“It’s still not enough. … We need rewards in the game — like, for example, defeating the guard in Karateka. What makes a game engaging? Tension/release, tension/release. Prince of Persia has neither.”

At first, Mechner resisted desperately. He complicated the level design, added new traps, made the acrobatics even more sophisticated, trying to prove that the game was self-sufficient without fighting. But the “player’s” request remained unchanged. The verdict was in: without sword fights, the game wouldn’t be as exciting.

“Conclusion: my next step is to add combat.”

And here Mechner hit a wall. Given all the already created animations, the considerable number of levels, and other elements eating up precious memory, adding another full-fledged enemy character with his own set of movements was simply impossible. There was stupidly no memory for it. Either cut something out or invent.

And here, at the junction of despair and genius, a solution is born that should give any Game Designer goosebumps to this day. Mechner takes the sprites of the Prince himself, inverts the colors on them, writes the simplest behavior logic, and… gets an enemy. The Shadow. His own dark reflection.

Think about it. A technical limitation born of a lack of memory turns into a powerful metaphor. It adds to the game that very combat the testers lacked so much; it creates tension, drama, and mesmerizing action of fighting with oneself. And all this reaches its peak in the finale. To defeat your main enemy, you don’t need to fight him. You need to lower your weapon. Sheathe the sword and take a step forward, allowing the shadow to become part of you.

This was a catharsis born of a bug, which became a feature, which became a philosophy. This is that very moment when the game design sparkled, immortalizing itself as a piece of art. And it was especially touching for me to read this in the journals:

“Hundreds of thousands of kids who I hope will play this game will meet the Shadow exactly as I programmed him today. I hope he blows them away. I’m too involved to look at it impartially. If not — well, then I blew it.”

At the same time, in the future, this limitation would lead Mechner to study the Apple II documentation even more thoroughly, allowing him to win enough memory to shove in two additional opponents. And yet, if not for the limitation at that moment in time, this story would be far less exciting, and Prince of Persia would have lost its depth.

And now, when we see how such elegant solutions were born from chaos and limitations, we can summarize regarding the design document. Because so far, I have rather burdened you with the history of development. But without it, it would be impossible to emphasize the importance of… journals!

Having read the entire book “The Making of Prince of Persia” from cover to cover, I realized that I wasn’t reading a book at all. These were developer’s notes. In the most literal sense — a journal. A word that has already appeared more than once in the paragraphs above. And it’s true. It is this format of documentation that closes the last important gap in the history of GDD that we haven’t touched on before.

This area — personal journals — is well known to us, modern developers. Today we have a ton of convenient tools for version control, note-taking, task commenting, and so on. But I dare say that Mechner was one of the first to turn this into his systemic, conscious process. Yes, others took notes too, but more often out of necessity: to explain a thought to the team, patent an idea, fix a set of rules. Here, however, and this is fundamentally important, Mechner held a dialogue with himself. And this dialogue not only allowed him to leave behind a whole book. It became his main game design tool, helping to polish, discard, and improve ideas in real-time.

This deeply personal approach had quite practical consequences as well. Journal entries became the basis for more formal documents, such as the CWP (Creative Work Plan), which the publisher required. Without this habit of taking thoughts out of his head onto paper, the entire project risked dragging on, breaking under the weight of problems, or simply losing that very vision the author sought. I am 100% sure that thanks to these documents, containing every particle of the game, albeit bit by bit, it eventually came together into that masterpiece of its time. And all this exhausting, doubt-filled work found its highest justification in a simple but incredibly touching realization recorded in one of the journal entries:

“This is the one area in my life where I’m sure my efforts are doing good, not harm. It’s good, it’s mine, and thousands of people will be glad it exists. Of how many things in life can the same be said?”

Thus, Prince of Persia and the personal journal of its creator close the period of “drafts.” This entire era, from arcade machines to the first home consoles, was a time of small teams and lone geniuses. Their main tool was vision, and design documents, in their striking variety, served merely as a way to make this vision tangible and transferable. Whether it was Miyamoto’s engineering blueprints of levels, Gilbert’s narrative spider-web diagrams, or Mechner’s frame-by-frame storyboards of movements — all these artifacts performed the same fundamental task. They helped translate brilliant but ephemeral intuition, that very question “what if?”, into a clear, working, and reproducible system “this works like this.”

But the industry did not stand still, and the success of these games only added fuel to the fire of its growth. Lone enthusiasts turned into teams, teams into full-fledged studios. Development tools became more accessible, technologies more powerful, and games, as a consequence, more complex, higher quality, and more ambitious. In these new conditions, a personal draft understandable to one or two people and kept in a desk drawer ceased to work. When not three people, but thirty are working on a project, you need not a stack of personal notes, but a single source of truth accessible to everyone. The author’s sketch had to be replaced by something far more monumental and structured.

The time had come to write “Bibles.”

To Be Continued…

At this moment, I am forced to put not a period, but perhaps the boldest semicolon of my life.

I originally planned to release this material as one giant long-read. But when the word count exceeded all reasonable limits, and the number of open tabs and purchased books surpassed all health and safety standards, I realized: trying to squeeze the history of an entire industry into one article means showing disrespect to history itself.

I have been working on this material since the beginning of the summer of 2025. And what you read above is only the first half of the journey. My perfectionism, demanding not just a Wikipedia rehash but deep fact-checking, ordering rare print editions (as in Mechner’s case), and handling design and layout, dictates its own rules.

The second part, work on which is already in full swing, will be even harder. The most saturated and controversial eras await us:

IV. 1990–1999: “Time to Write the Bible” — about the monumental tomes upon which Doom, Deus Ex, and Half-Life were built.
V. 2000–2010: “Red Pen Manifestos” — about corporate culture and standardization.
VI. 2010 — Present Days: “The Death of the Author?” — about Wiki, Confluence, Notion, and how documentation became a “living organism.”
VII. Conclusion: “The Skeleton in the Closet” — summarizing the entire evolution.

Why did I have to split it? Because my approach to quality became a sort of trap for myself. I don’t want to just retell well-known facts. I want to dig deep. And that means: buying and reading literature, endless fact-checking, working on design, and, the hardest part of the second section — direct inquiries to publishers and attempts to reach out to the developers of that era themselves.

I do this in my spare time, investing my own energy and funds, with one simple goal: to create that very material that I myself desperately lacked five years ago when I was just trying to find solid ground under my feet, and thereby raise the bar of discussion in our community, proving that we are capable of serious, thoughtful analysis that goes beyond superficial retellings and hype.

I won’t lie: I have no idea how long this final sprint will take. Given the scale of the remaining work and the reliance on other people’s responses, the second part could come out in a few months or closer to the end of 2026 (I have several other articles in the works besides this one!). Let’s not make predictions. One thing I can say for sure: the second part will be released exactly when it is 100% ready.

Ultimately, my dream is to collect all this into a single, cohesive work. Perhaps into a conditional “Definitive Edition” — with final edits, additions, and a unified structure, which one could not just scroll through, but put on a shelf like a book. I hope the first half convinced you that this story is worth it.

Thank you for walking this path to the origins with me. On this note, I do not say goodbye. The history of game design documentation is just gathering momentum.

Vivat gamedev! And see you where the secrets are even deeper → t.me/slepokNTe 👀

How a Game Designer and a Programmer сan build what can’t be done alone?

Nicolaos Tsitsonis — Sat, 25 Oct 2025 11:08:31 +0000

Ready to admit you can’t do everything alone? 👀

«Momentum» — is an original column from my Telegram channel. What you’re reading is an English translation of the piece I first published in Russian, so some turns of phrase may feel a little rough. Btw, it is just a way of structuring my own thoughts aloud, putting them in order and searching for a live dialogue. Enjoy the read! ;)

Preface.

I hate the idea of solo development. Not just “don’t like” — I despise it as a phenomenon that, for some reason, people love to romanticize. Not the games themselves, because I, like you, genuinely admire cases like Animal Well, Stardew Valley, Papers, Please, and many others. We all need a guiding star. But I hate how this path of the "suffering loner" gets normalized and even standardized, turning an exception to the rule into some supposedly attainable ideal.

And here’s what’s strange: no matter how many stories of these very “lone wolves” I read, there’s always a clear thread of gratitude to friends, family, early testers — the people they turned to for help. Yet when we turn the page, we somehow remember only that a single person, it turns out, suffered.

Consciously choosing the path of total isolation is the most thankless, destructive, and simply wrong thing you can do to your creative potential. You’ll ask:

«And what’s the alternative?»

Don’t be afraid to open your mouth and say a simple word: “help”! Don’t be afraid to admit your incompetence. Don’t be afraid to develop your communication skills and build new connections. I want this to be crystal clear — here’s the core meaning of this entire momentum in one sentence: I BEG YOU, stop thinking that asking for help is weakness, that a team is a crutch, and that a true creator must suffer alone. THIS IS A LIE!

(And a quick note for those who think I’m about to spend fifteen hundred words chewing on this one thought: NO. What follows will be entirely practical takeaways, which I want to validate together with you.)

Accepting the fact that people are different and that you physically cannot understand something as well as a person who has devoted their entire life to it — that’s not defeat, it’s a huge step toward maturity. Because you’ll only build the skill of seeing the world from every angle after decades of experience (and don’t get me wrong, I’m still on that road myself, but I know for sure from which point you must not start it).

And you’ll either walk that road by making the same mistake hundreds of thousands of times alone, or you’ll find people who will help you notice those mistakes — while you do the same for them. By trying to become a master of everything, you are guaranteed to become a master of nothing. You’ll simply scatter yourself across dozens of domains without ever going deep into the one you love most.

«Mastery is not at all a derivative of genius or talent. It is a derivative of time and effort applied to a given field of knowledge»

— Robert Greene, Mastery (c)

It is precisely from this desire to create, to delve deeper, and to grow together that this momentum was born. So this time, it won’t be just another monologue of mine. It’s our joint experiment with my friend and the programmer on our project, Eugene — a person whose mindset is the complete opposite of mine, and who will join this text a little later.

Together, we’ll try to answer honestly: how do you accept the fact that you may be an excellent game designer but a terrible programmer (and vice versa)? How do you turn your weakness not into a complex, but into a point of connection for another person? And how is it that social intelligence — not technical skills — becomes the force that allows two different views of the world to be assembled into one working project?

What’s behind the door?

So that our dialogue doesn’t turn into abstract philosophy, let’s agree on terms right away. Any game, from an indie gem to an AAA blockbuster, rests on two absolutely equal pillars: Concept (what and, most importantly, why we are making) and Execution (how exactly we are making it and for whom). Remove even one, and the whole structure will inevitably collapse.

And when one of these parts is missing, we get two classic types of failed projects.

The first — Concept without Execution. Let’s call it a "theoretical game".
The second — Execution without Concept. That’s a "technical demo".

A “theoretical game” can be brilliant. It can be laid out in a design doc, a pitch deck, or a presentation, with perfect loops and deep meaning. But for the player, it doesn’t exist. Its value is zero. It’s a dead project that never managed to be born.

A “technical demo,” in turn, can be impeccable. Working mechanics, optimized code, stable performance. But it’s… not fun to play. There is no purpose, no engaging experience, no soul. This is also a dead project; it was simply born a zombie: it moves, but it isn’t alive.

And before you decide that one of these failures is somehow “more noble” than the other, let’s face the truth. In the real world, with almost equal probability, people will think you’re out of your mind in both cases — whether you show an investor a brilliant idea in a presentation or a working gray box with a couple of mechanics. In response, you’ll most likely hear:

«Sounds interesting / looks cool. Come back when you have a game».

Both paths lead to the same dead end — a project that never became something cohesive. And if we dissect these failures, their key mistakes can be formulated as follows:

The “theoretical game” mistake — ignoring technical constraints, overcomplicating systems on paper, and a complete lack of a feedback loop.
The “technical demo” mistake — the absence of a clear gameplay loop, ignoring player motivation, and a fundamental misunderstanding of the project’s overall purpose.

Arguing over which failure is worse or whose contribution is more important is stupidly pointless and counterproductive. Both outcomes are failures. The problem lies in the mindset that pits them against each other. Real development begins when the team sits not opposite each other, but shoulder to shoulder, to look together at a shared goal.

This dichotomy of “Concept” and “Execution” runs through the entire industry. Behind the first stand game designers, artists, writers. Behind the second stand programmers, marketers, QA engineers. Every time these two camps stop talking, the game starts rotting from within.

Now that we agree on the rules of the game, it’s time to see what this very handshake between a game designer and a programmer looks like in practice.

The Game Designer’s View

If you ask ten game designers to define their profession, you’ll get eleven different answers, and each will be correct in its own way. Game design is not an exact science; it’s where psychology, mathematics, storytelling, and other no-less-important disciplines intersect (and we have to account for all of this, which is exactly what I try to cover in my blog!).

That’s why a rigid definition will always feel incomplete. But in day-to-day work, in conversations with the team, and in attempts to explain to yourself “what on earth are you even doing?”, you need some footing. A formulation that helps you feel the ground under your feet each day sounds roughly like this:

«Game design is the process of engineering a system of interconnected rules and mechanics that creates a space of meaningful choice for the player and, as a result, a unique interactive experience.»

Offering such definitions is a thankless and even tacky task. Any definition inevitably narrows and simplifies. But to understand how a game designer looks at a game — and how that view differs from a programmer’s — we need this starting point.

Let’s run a thought experiment. Imagine that, as a game designer, I don’t need to think about how the game will look, how it will sound, or whether it will be optimized at all (by no means do this in real life; it’s bad for the project’s health!). What remains in the end? What is the skeleton I’m designing?

At the core, there’s a continuous dialogue between the Player and the System. This is my starting point. I don’t think of them separately. When I form a mental image of the game, I must imagine how these two entities will interact, respond to each other, and change each other in the process. Who is the person on the other side of the screen? Why did they launch our game at all, and what goal are they pursuing? And how will our system of rules and mechanics respond to each of their actions to nudge them forward?

There’s a useful practice for storytellers and speakers. To stay on track and hold attention, you mark out key points of your story in your head beforehand. Then, as you speak, you pull a narrative thread from one point to the next, trying not to drop it and to keep the whole intact.

In essence, my job is the same, but at an interactive scale. I set up the same kind of “points” for the player: goals, rules, mechanics, challenges. But unlike a story, this “thread” is pulled by the player themselves, through their own actions and decisions. My task is to design that space with clear rules that lets them find and draw their own unique path.

Now to the point. Eugene and I will take turns answering three questions that lie at the core of how we work together.

What “truth” do I defend in the project?

My truth is the player.

My task is to give the player not what they ask for, but what they truly want, even if they can’t yet formulate it. Being the defender of the player means being the chief advocate for their experience within our project. I’m the one on the team who keeps asking the uncomfortable questions: «Will this be clear to the player?», «Why should they do this?», «What’s the actual joy in it for them?»

From here comes the “player experience” as a concept that, by the way, can be broken down into three components:

Readability. The player must understand the rules of the world they’re in. They shouldn’t need to read a design doc to know that lava burns and a tall wall is impassable. My job is to ensure that my work, through the prism of the whole team’s work — from artists to programmers — forms a single, comprehensible feedback system for the player.
Meaningfulness. Every player action should matter. A choice becomes meaningful only when it has a cost and consequences. Hold a card for a key combo or play it now? Upgrade current gear or save resources for something fundamentally new? Each such choice is a small brick from which the player builds their unique story.
Value. The system must respond fairly to the player’s actions. If they make a smart decision, they should feel smart. If they make a mistake, they should understand why they failed. This is the core mechanism I’m watching over.

My “truth” is an attempt to create a common language for the whole team. When we all understand the specific experience we want to give the player, implementation debates become constructive. Instead of “like / don’t like,” we start speaking the language of “helps / hinders” in achieving our shared goal. Defending this principle is my main function. This clarity of purpose is the primary way I can help my colleagues avoid wasting effort. But how does that work in practice? That's what's next.

How does my work make the rest of the team’s life easier?

Given the context above, my main task here is to eliminate ambiguity and prevent work that will be thrown away. I must create such clear frameworks and such an understandable vision that everyone on the team can freely create and dive deep into solving problems in their domain, without wasting time guessing what others were thinking.

For this, we have a tool called documentation.

And let’s lock in a simple truth that somehow still needs explaining. Documentation is NOT optional. I don’t give a damn whether you work solo, in an indie team, or at a big studio. The process can and should differ, but its existence is mandatory. Refusing to maintain documentation is an admission of your own incompetence and a demonstrative disrespect for the work of others, and first and foremost, for your own.

Every time key decisions are made verbally and recorded nowhere, you plant a time bomb that will inevitably explode into arguments about “who said what,” or you’ll simply forget what you intended to do and where the problem is buried.

Maintaining documentation in any form. From a high-level vision/master doc to a detailed description of all mechanics in a design doc — is the absolute professional minimum. If your idea cannot survive being transferred from your head to paper in a way another person can understand, it is most likely a raw and half-baked idea.

Moreover, having a document protects the project from me. It forces me to carry a thought to its logical conclusion. If I can’t clearly describe a mechanic, it means I haven’t thought it through. It forces me to make decisions and record them instead of changing the concept on the fly five times a day and injecting chaos into the workflow.

Inextricably linked to this is providing context. We need to translate a design idea into our teammates’ language. So a task in the documentation never looks like “make mechanic X.” For a programmer, it will be supplemented with a description of the necessary logic; for an artist, with its functional and visual purpose. When the team understands not only what needs to be done and why it matters to the player, but also sees the task framed with their expertise in mind, they can propose more elegant and efficient solutions than I could have ever imagined.

Of course, this isn’t a call for mindless bureaucracy where form trumps substance. The “workflow” and depth of documentation are things the team should build for themselves. What’s obvious to one person can be utterly incomprehensible to another. Creating such a shared space where ideas aren’t lost and are always accessible — that is the result of competent game design work.

In short: I take full responsibility for the “what” and the “why” to completely free up the team to search for solutions in the “how.”

Where does my expertise end and another’s responsibility begin?

I bear full responsibility for ensuring the game’s rules are understandable, the player’s choices meaningful, and the systems interconnected. That’s the territory where my word is final. If a technical solution, an art asset, or a plot turn fundamentally breaks the core gameplay loop or misleads the player, it’s my direct duty to veto it and explain why it harms the project.

At the same time, the specifics of gamedev force each of us to have basic competencies in adjacent areas. We create a single, cohesive product, working on one “canvas.” My past experience in code, art, or audio exists to help me better understand the big picture and build a shared language with the team. This is a normal part of professional fitness: not mandatory, but desirable. It’s just important to remember that mastery can be achieved only by fully immersing yourself in one discipline.

My expertise finds concrete expression in the game design document. It’s the recorded vision of the concept. When implementation diverges from that vision, I come forward with the phrase, “we have a problem.” That’s the point where my solo work ends and a dialogue begins. We sit down and together look for a solution to this shared problem, which has no single culprit, only a misunderstanding or a technical constraint.

In this dialogue, I won’t crawl into the code or tell anyone how to write it. My questions are always aimed at the result: how does the implemented mechanic feel; does it solve the given task; is it clear to the player? Likewise, I expect the programmer to question my design: is the logic described clearly enough; have all edge cases been considered? Each of our gazes should be fixed on the final result, not on defending our own turf.

That concludes my part. I’ve tried to outline my position and my view of the process as honestly as possible. And now I hand the floor to my friend Eugene. He may speak with less refined phrasing, but he’ll give an honest, straightforward answer to the same three questions from the vantage point of “Execution.”

The Programmer’s View

A bit about myself. I’m Eugene. And I’m the guy who gets a hand on his shoulder and a quiet whisper in his ear:

«We want this mechanic!»

That’s where my work begins: deconstructing the task, estimating its complexity, finding its place in the project’s existing architecture, and spotting potential problems. Simply put, I pour some two-day-old, sludgy coffee into the game designer’s standard-issue mug and start thinking.

What does “thinking” mean for a programmer? First and foremost, it means translating the team’s “wish list” into the language of the engine and logic. In my case, this whole process rests on three simple, unbreakable rules.

Here they are:

The text is the single source of truth.
If you feel a mechanic will take half a year — discuss it.
If you built it differently than intended — listen up.

What “truth” do I defend in the project?

My truth is the long-term health of the project. I’m the person who fights technical debt before it starts devouring time and sanity.

That means thinking through an architecture that won’t crack at the seams when someone comes up with a new mechanic, a character, redraws an asset, or adds a new line of dialogue. Keeping the code as clean as possible and maintaining the integrity of the whole system. I alone am responsible for the cleanliness and formation of logic, systems, and stability. I try to make sure things work, not on a “wing and a prayer.” The player doesn’t care how elegant my code is, but they sure as hell care when the game crashes.

All this engineering honesty isn’t some lofty philosophy; it’s blunt pragmatism. The ultimate goal is one thing: iteration speed. When the foundation is solid, the team can say “hey, let’s try it this way,” and we try it, instead of burying the idea because “the code won’t allow it.” No one but me is going to dig through this code, so it’s on me to keep it from turning into a dumpster fire.

The cause-and-effect is simple. Clean, predictable code means fast, cheap iterations. Tangled code means wasted time, blown deadlines, and buried ideas. My choice is obvious.

How does my work make the rest of the team’s life easier?

In any team, all roads lead to the programmer. Every idea, every asset, every sound eventually passes through code. I have to translate ideas into working code, but in a way that doesn’t require my constant presence later. If the team is waiting for me to make the simplest tweak, we are not making a game.

The practice is simple: anything that isn’t core logic should be configurable without a programmer. Damage, health, speed, colors, sounds — all of it should live in tables or components where anyone but me can change it. If you have to ping me to change damage from 3 to 4, I consider my job a failure. It means I didn't build a flexible architecture; I built a dependency on myself. I build an environment where everyone can fulfill their role as effectively as possible.

For example: “How do we integrate a card system?” We add a card class, its parameters, and it’s done. “We need more flexibility.” No problem, we do another iteration of rework, add dynamic parameters. “WE’RE GOING TO HAVE N EFFECTS AND 400 CARDS.” No-prob-lem. We align on all the effects, their interactions, and parameters. A new iteration of the task, we break it down into more components and expand the mechanic again. And so on. We repeat this process until we're satisfied with the result.

I provide the team with confidence. When something works stably, predictably, and transparently, it lowers stress, makes planning realistic, and gives the work meaning. Reliable code is like a solid floor under your feet: you don’t think about it every second, but it’s what allows you to move forward with confidence.

When they can assemble and tune content themselves, without me, they work faster. And I can focus on complex and interesting problems instead of being tech support for code tweaks.

Where does my expertise end and another’s responsibility begin?

My expertise is turning text into working code. Someone else’s responsibility begins when the text (the spec) is shit. I have three red flags for that.

Something is unclear. If I read a task and don’t understand how it’s supposed to work, I stop. I don’t fill in the blanks. Even a tiny detail, be it a movement speed variable or a stat counter, can later interact with another mechanic, which in turn interacts with another, and so on, to infinity squared. In that case, you have to pause the task and go discuss the little question that popped up. It’s faster and cheaper than rewriting everything later.
I can do it, but it’ll take six months. If six months is an acceptable timeframe for you, I have no questions. But if time has value, we need to talk. Not right away, though. First, I need to break it down into components and try to figure out the main bottleneck so the discussion can be more productive. At moments like these, I ask the main question every programmer should ask: "Is what we'll get in the end really worth the cost?". Sometimes the answer is “yes.” More often, we find a solution that's ten times simpler.
You asked, I delivered. I followed the spec to the letter. I show the result. A colleague says, “something’s off.” And that “something’s off” can let rot spread through the whole project. My expertise is making the system work. Theirs is making it feel right. I don’t argue with “feelings.” I ask them to show me what’s wrong, and together we find which “knob” in the code needs to be tweaked to fix it. Because in the end, they are the only one holding this entire infernal machine in their head.

Bottom line: discuss. It’s the only thing that works. And don’t delude yourselves: cool games aren’t made by lone geniuses, but by teams where people know how to talk to each other.

There are many repetitions about discussion in this text, but that is the main idea I wanted to share. Listen to your team, and before long you might just find yourselves at The Game Awards, standing next to your game designer who’s crying with joy!

Conclusion: Games aren’t built alone, but together.

First of all, I want to thank our programmer — Eugene. For agreeing to this experiment, spending the time, and stating his position honestly. And yes, to be fully transparent: I helped him tidy up his thoughts, but every word and every idea in his section is his own, which he personally approved. It's important for me to say it as it is.

Originally, this momentum was conceived as a text about social intelligence in a game designer’s work — about how vital it is for us to develop empathy and learn to see the world through the eyes of the player, the programmer, the artist. But in the process, I realized that locking myself within my own profession is, once again, building a wall. Because “social intelligence” isn’t a game designer’s skill. It’s the glue of all gamedev of any complex collective creation, really.

I read a lot: Books, audiobooks, articles, postmortems — everything related to our industry. And I, like you, have heard the well-worn phrases about the importance of the team hundreds of times. But sometimes a cliché is just a truth confirmed so many times that it's become grating. Valve builds teams of “T-shaped” people on this principle. Hideo Kojima says this when he talks about creating games not with “his vision,” but with “our vision” — the vision of the team. And Sid Meier, in my view, formulated this idea best:

«The dichotomy between someone else’s talent and your own is a cause for celebration, because the further apart you are, the more you can offer each other.»

For God’s sake, step outside of gamedev and you’ll hear the same thing. Steve Jobs said:

«Great things in business are never done by one person. They are done by a team of people.»

And John D. Rockefeller went so far as to say:

«The ability to deal with people is as purchasable a commodity as sugar or coffee and I will pay more for that ability than for any other under the sun.»

EVERYONE tells us this.

So what do we do? I sincerely admire anyone who managed to carry their burden from idea to release alone. But I will never trade the experience of shared victories and failures, arguments and insights within a team for the silence and illusory freedom of solo development. And I wouldn’t recommend it to you, either.

If, having read this far, you burn with the dream of making your own game or simply want to become part of gamedev, you’ll have to be honest with yourself. Ask yourself the question:

What, in all of this, is yours?

Designing a game on paper? Writing code? Creating art, audio, a story? What exactly are you willing to study and do for years to become a master at it? Now ask the second, even harder question:

And what isn’t yours?

Where are you objectively weak? Where are you uninterested? Where will you spend ten times the effort to get a result ten times worse than a specialist would? Admitting this isn’t weakness. It’s the starting point of professional growth.

And this advice is especially important if you’re at the very beginning of your journey. Look for people. Those you can learn from. You’ll be surprised how many experienced developers are willing to share their knowledge if they see genuine interest. And those who, like you, don’t know much of anything yet — so you can build something together, even the most useless thing on earth. That experience of shared failures and small victories will give you far more than years spent in solitude.

Because social intelligence is precisely this process of shedding a naive worldview and developing another, more realistic one — of the world, of people, and of yourself. And no, I am by no means urging you to lock yourself away in your own field. When necessary and when you're interested, grow into adjacent ones. It won’t make you a master of everything, but it will teach you to speak with other masters in a common language.

Don’t be afraid to look for others. Right now, as you read these lines, hundreds of people just like you are burning with the same dream and are just as desperately afraid to take the first step. They think no one needs them, that their ideas are stupid, that their skills aren’t enough. Make that contact possible. Write, show, propose. In the worst case, you’ll get a “no.” But the price of such a mistake is merely experience. And the price of inaction is a dream, buried in loneliness.

And see you where the secrets are hidden → t.me/slepokNTe 👀

We’ve made a game, General!

Nicolaos Tsitsonis — Fri, 03 Oct 2025 16:04:16 +0000

We've made a game that we're finally proud to show, and we're inviting you to the alpha playtest of Space Is Limited to help us make it even better!

The critic's chair is a temptingly comfortable perch. Over the past year, while analyzing other people's games, I often caught myself wondering: am I building too cozy a nest of theories for myself? It's easy to discuss game design when you're analyzing a finished product. It's easy to talk about the importance of bad decisions when your own project is safely hidden from prying eyes.

I've always been afraid of this. Afraid of turning into a theorist who knows how it should be done but never actually does it.

Today, I want to offer this critic's chair to you.

For the last year, my team and I have been working on a game. All the articles you've read here weren't just abstract musings — they were my way of thinking. A way to process the challenges we faced and to formulate the principles upon which we are building our project. This process has always remained behind the scenes. Until now.

We've reached the stage commonly known as "alpha testing." In game design terms, this means the skeleton has grown muscles, and the system has started to breathe. But it's not yet a complete organism. It's a prototype, full of rough edges, imbalances, and questionable decisions. And it turns out that theorizing about trusting a hypothetical "smart player" in an article is one thing. It's quite another to open up your raw project and prepare to hear why your systems, so elegant on paper, don't actually work.

Who are we? — Literally The Team

We are a team of five. For an indie team, that might not sound small, but the reality is that none of us can afford the luxury of working on the game full-time. And more importantly — besides the five of us, the project has no one else. No publisher, no marketing department, no community managers.

So when we say your feedback is important, it's not a figure of speech. It's a description of our workflow. There are no filters between you and us.

This means that when you say a system's design is bad, I'll be rewriting the design document and tweaking the balance that very evening. A critical bug will have Eugeny preparing a new build. A tile that renders incorrectly will be sent to Vasilii to be redrawn. A lore inconsistency will land on Dmitriy desk, and an annoying sound will have Egor searching for a replacement.

We will see it. And we will figure out how to fix it. The same day.

This is our side of the bargain: We are responsible for the quality of the product and for living up to your expectations. But we have expectations of you, too, and we see no reason to hide them. We expect you to criticize us. We want you to talk about us, helping the game find its audience. This isn't flattery or pretense. It's the only model that works for us, because we simply have no other channel to the world besides you.

We are ready for your most honest and brutal feedback. The real question is — are you?

What have we created? — Space Is Limited

Space Is Limited is our answer to the question, "what could a battle of wits look like?" In short, it's a competitive turn-based strategy game for four players.

Imagine crossing the tactical struggle for territory from Civilization with the tile-laying mechanics of Carcassonne, and seasoning it all with smart deck-building in the vein of Hearthstone. And all of this in multiplayer, against real people.

Each match is an expedition to colonize a new planet. You choose one of four factions, get a unique general, and begin the battle for influence. By laying down tiles, you and your opponents shape the world map together. By capturing and completing objectives, you earn points. And with cards, you disrupt your opponents' strategies and execute your own.

This is a game where victory depends not on reaction speed, but on your ability to adapt, plan several moves ahead, and discover non-obvious synergies. Each match becomes an arena not just for cold tactics, but also for fun, sometimes absurd chaos, where a single well-played card can turn everything upside down.

If these words mean something to you — you're our kind of person.

Instructions.

I hate the phrase "call to action," and yet, here we are.

1. Follow the link.

Space Is Limited (Alpha) • Private Playtest

https://forms.gle/LLLcJM16YLnh85rX8

2. Read everything carefully, including the NDA (or at least know what one is!).

3. Fill out the form.

4. Wait for an email.

Honestly? Hitting the "publish" button on this post is a little scary for all of us. For almost a year, this game has been our private secret, our outlet. Now, we're bringing it out to you. We don't know what will come of it, but we believe this is the only right way forward.

Thank you for your attention and, we hope, for your future participation. It truly means a lot to us

About the blog.

"Slepok" has always been, and will always be, a place for my personal thoughts on game design. It just so happens that our team's project became the catalyst that pushed me to structure and publish those thoughts. Therefore, the blog will continue to live its own life. Today, it simply has a chance to help its "inspiration."

Soon, you can even expect to see some dev-logs, if not from me and my account, then from our entire team. :)

See you where the secrets are even deeper → t.me/slepokNTe 👀

The Case of the Murdered Memories, or Why Your Game Design Became a Crime Scene

Nicolaos Tsitsonis — Sun, 21 Sep 2025 15:02:00 +0000

I. Preface: Grand Hotel «Memory»

I have a funny professional reflex I’ve developed over a few years. As someone standing in both trenches of the games industry — in the dev foxhole and in the designer’s chair — I respond to the word “memory” with a clarifying question:

«Which memory are we talking about, exactly?»

Most of the time we mean the usual suspect — computer memory. RAM, gigabytes, load times, polygon streaming, and all that technical splendor that makes our games look and run the way they do. It’s a tangible, measurable, perfectly concrete resource we developers wrestle with, trying to stuff the un-stuffable and optimize the un-optimizable.

But there’s another kind of memory. The one that hides behind the dry stat of “concurrent players.” Behind every powerful PC, behind every gigahertz and teraflop, there isn’t just hardware. There’s a person. And this article is about that person. About a human whose memory, unlike a computer’s, behaves a little less predictably. It’s moody, selective, emotion-driven — and it can “freeze” under overload. And yet, believe it or not… it’s still predictable enough!

Understanding the rules of this memory — the human kind — is what separates a good developer from a true architect of play. So let’s start with a tiny game. Ready? What word did I use to describe my reaction to the word “memory”? Hint: it starts with “re” and ends with “flex.” Remembered it? Great. Didn’t? Even better!

Now a quest for the whole article: remember these three words — marshmallow, gravity, Sisyphus. I’ll check at the end!

In many psychology textbooks (and, to my surprise, in game design!) you’ll find mention of a “multi-store model of memory.” Don’t be alarmed — its actual name is «Atkinson — Shiffrin Model», a name mainly for the especially erudite. For simplicity and a touch of elegance, let’s imagine our player’s memory as a grand, slightly enigmatic, three-story hotel.

Grand Hotel «Memory»!

Allow me — your doorman for today — to give you a brief tour. Guests arrive constantly. Any piece of information, whether a screen flash, a line of dialogue, or the rule of a new mechanic, is a guest trying to check in. Our tour includes:

First floor — the spacious, perpetually bustling lobby. Here, guests crowd the entrance, lingering for mere fractions of a second. At the front desk stands a stern but fair concierge named “Attention”. It’s their job to decide which of the hundreds arriving are worthy of passing deeper, and which remain a fleeting impression, lost behind the revolving door.
Second floor — the lively lounge. Think of it as the hotel’s working office. Only selected guests who passed “Attention’s” face control get here, and they’re now handled by the Bartender and the bouncer “Stress”. They can stay for a bit, mingle with others — and, crucially, residents from the upper floor come down here to discuss pressing matters. Information is actively processed here, but capacity is strictly limited. If the lounge gets too crowded, some guests are politely — and sometimes not so politely — shown the door.
Third floor — the rooms. Endless corridors with countless doors. If a guest reaches this level and checks into a room, they become a resident. They might stay for days, years, or a lifetime. The catch? Finding the right room and coaxing that resident back down to the lounge for a chat is no small feat.

Sounds secure and well-guarded, doesn’t it? There’s a twist. In our Grand Hotel «Memory», murders happen all the time — quiet, invisible ones. Guests vanish without a trace. Critical details you were just holding evaporate. Our job as Game Designers is to identify the killers, learn the hotel’s internal bureaucracy, and escort our most important guest — the player’s core experience — safely to the most reliable room upstairs without losing them on the way. Paradoxically, HOWEVER:

We need to remember what must be remembered!

Alright, enough formalities. May I take your coat? Let’s head to the first floor, the lobby. The investigation begins!

II. First Floor: The Lobby.

Welcome to the lobby! Don’t mind the hustle — it’s always like this here. This floor, a.k.a. “Sensory Memory,” is arguably the most straightforward and least mysterious part of the whole hotel, yet it’s also fascinating!

Guests don’t linger here. They pour through the revolving door in a stream of hundreds of images, sounds, and sensations, spend sometimes less than a second, and immediately spill back onto the street. This isn’t storage — it’s a passageway, a primary filter. But don’t let that fleetingness fool you. Right here, in this chaos, the hotel’s fastest employee is on duty — the concierge named “Attention”. And he is damn good at his job!

There’s a legend that one day a very important guest tried to slip into our hotel incognito — information about an airplane model (you can read about this “incident” here: «How many frames per second can the human eye see?»). He was camouflaged in a crowd of 220 other frames and flashed at the door for just a fraction of a second. And yet our concierge, Attention, not only spotted this “guest,” but instantly read the baggage tag: model, class, even the tiny details.

What does that mean for us? Simply that the brain — our player’s brain — is an incredibly powerful scanner, capable of parsing a continuous stream of information at lightning speed. A player might not consciously know why they hit the parry button in Sekiro at the one correct instant, but their sensory memory did. It picked up that glint on the enemy blade, that single frame that screamed: “NOW!” Its job is to deliver raw, unprocessed data about the world — instantly.

But wait a second, you might say. Isn’t the juicy headshot sound in Counter-Strike, or the bright flash from a successful parry — the end result of our actions — also just sensory input? And I’ll say yes! Here lies the elegant duality of our lobby. It runs both ways. First, like a sentry, it registers a threat or an opportunity (a spawning enemy, a wind-up for a strike). Then, milliseconds later, it also registers the outcome of your action (the hit sound, the block VFX). This lightning-fast loop worth remembering:

«Signal → reaction → feedback»

Played entirely on the first floor, this is what we Game Designers call “responsiveness,” “impact,” or that elusive “game feel.” The lobby isn’t just an entrance — it’s also a counter of instantaneous feedback, where the game answers the player right away, without bothering to climb up to the second floor.

You’d think that with such a powerful scanner at the door, what problems could there be? If the player reads everything this fast, surely they remember everything? Oh, if only.

And here, in this bright, ever-humming lobby, the oddities begin. Guests don’t exactly die. They… just vanish. They fall right through the floor! You saw them at the entrance a second ago; glance away for a fraction and there’s only emptiness. The thing is, our lobby is excellent at seeing but terribly bad at remembering without orders from above — without sending the guest up to the second floor, to the lounge of short-term memory.

The first culprit behind these disappearances is a classy yet devious trick called “Flicker Paradigm” (a profile of this “devious” trick can be found here: «Change Blindness Flicker Paradigm»).

Imagine: a guest in a top hat enters the lobby. Suddenly, the lights go out across the hotel for a split second. When they come back on, the guest is now wearing a bowler hat. Will you notice the difference? With 99% probability — no. That tiny blackout fully resets the lobby’s state. As far as it’s concerned — nothing happened! Small, sometimes medium, and only rarely BIG changes just get ignored by our brain under such conditions. We are literally blind to momentary changes if there’s even the tiniest gap between them. And yes — this is exploited!

An old mobile-game trick: you’re shown a bright pop-up “BUY CRYSTALS!”. You get distracted; it consumes most of your attention for that second, and then you close it. Are you sure nothing changed on the main screen while you were away? The “deal of the day” icon could easily have swapped — and you wouldn’t notice!

Think you’re safe if the lights never go out? Not quite. There’s an even subtler way to outsmart our concierge. Picture this: while Attention is focused on the front door — on that most intense stream — another guest starts moving a huge palm tree very, very slowly, inch by inch, from one corner of the lobby to the other. No one notices. The change is so smooth and gradual that the brain refuses to register it as an event.

This phenomenon is called “gradual change blindness”, (don’t take my word for it — try it yourself here: «Gradual Change Observation | Witness Change Blindness Test» and a more overused classic in «Selective Attention Test») — and it’s the best friend of racing-game developers.

They figured this out long ago: during a race at 200 km/h, your concierge Attention looks EXCLUSIVELY and ONLY at the center of the screen — the road, the rivals. He couldn’t care less about the edges. Designers shamelessly exploit this to save resources! They don’t even need to “hide” anything or move it inch by inch. While you’re locked onto the track, the trees on the periphery can be flat 2D textures — you’ll never notice. Your sensory memory, concierge Attention, won’t bat an eye as a grand piano is carried right under his nose!

Dossier: Concierge «Attention»

Ladies and gentlemen, let’s recap to lock a few things in. The lobby — Sensory Memory — is an executive mechanism. And we, Game Designers, are the ones issuing the orders. Our key job is to be a competent manager for concierge Attention, clearly explaining how to handle each type of arriving guest.

All our work on this floor boils down to three kinds of directives:

1. «HANDLE IT ON THE SPOT!» — Our most frequent order here. It covers everything foundational to the core gameplay loop — footstep sounds, a parry flash, the feel of a jump. We literally train the lobby to process these “regulars” instantly and autonomously, without distracting the managers upstairs. This is the realm of reflexes, “muscle memory,” and pure game feel.

2. «IGNORE IT!» — The order for our small, criminal sleights of hand. This is where we work magic by using perceptual blind spots. We distract the concierge with a bright flash at screen center while our accomplice programmers carry a grand piano out the back — i.e., stream assets or swap models to cheaper ones. This is a directive for smart optimization and seamless experience.

3. «SEND IT UPSTAIRS!» — The most important and delicate order. It concerns all new, critical guests — a hint about a new mechanic, a key environmental detail, an important line of dialogue. These are guests the concierge should pass through almost without looking, issuing an immediate pass to the second floor. We must prime him for them — just like with the airplane model example above! If he starts scrutinizing and trying to “handle it on the spot,” he may misclassify them as “background noise” and throw them out. Our task is to highlight these guests so they bypass the primary filter and reliably reach the lounge for further check-in.

If we condense our observations into a short staff memo for the hotel (and for us) it would read like this:

RELY on sensory memory for instant feedback. It’s the foundation of your game feel.
USE its blind spots for smart optimization. Players won’t notice what they aren’t looking at.
DO NOT TRY to convey complex information through it. A tutorial text in a skippable pop-up that disappears in half a second is a guaranteed ghost.
DO NOT ASSUME the player will notice two quick but unrelated changes. Their lobby won’t have time to process and connect them.

And what happens to the lucky few who receive a pass upstairs… we’ll discuss that as we climb the stairs.

III. Second Floor: The Lounge Bar.

Alright, this way please. Let’s leave the lobby’s hustle behind — the vibe here is different. Quieter, but I’d say far more tense. This is the lounge bar or — in the language of our investigation — Short-Term Memory.

The Lounge: Short-Term Memory.

Only those guests whom concierge Attention deemed worthy get upstairs. But here’s the twist: under the lounge sign, our hotel hides two establishments at once. The first is the hall itself — a place for guests to stay briefly (that very Short-Term Memory). The second is the bar where the real work happens: idea-cocktails are mixed, negotiations happen between new guests and long-term residents, and decisions are made. That’s Working (or Operational) Memory.

Behind the counter rules our prime suspect: the Bartender. Perpetually fidgety, with tired eyes and a nervously twitching mustache, he juggles a shaker, an order pad, and an old rotary phone that never stops ringing. He looks like someone who hasn’t had a vacation in ten years and is desperately trying to hold a thousand details in his head at once so the whole hotel doesn’t fall apart. Don’t let the shabby vest and sour face fool you. This man is the most important big shot in the entire hotel. More on that later.

Right now we care about his workstation, because that’s where this floor’s main oddity hides. Look closely. 1, 2, 3, 4, 5… 6, 7! 8? Oh, 9! Yes — the counter has only 7±2 stools. Sometimes, if luck is on our side, the Bartender pulls out a couple more from storage; on a truly hectic day, two might be removed altogether “for sanitation.”

Why so cramped? Sadly, it’s not our quirk. They say the secret of the stools was first cracked by a meticulous detective named Miller (you can skim his case here: «The Magical Number Seven, Plus or Minus Two 1956»). He found that our Bartender, no matter how hard he tries, simply cannot hold and properly serve more than 7±2 guests at once.

Think the manager is just lazy? Then allow me, your doorman, a small investigative experiment. I’ll ask you to read the next paragraph carefully — but only once. Try to remember as many digits and first letters of key words as you can. After reading, don’t peek — jump right to the question below. Play fair!

Cat ate 8 blue Fish and 2 Meatballs. Train number 74 rushed north at 9 miles per hour. Zebra bought 5 Watermelons and 16 Mandarins.

Now, please — without peeking — try to write down or just say all the numbers and first letters you remember. Take a minute.

Done? Counted? Unless you’re a photographic-memory genius (or cheated), your list will have about 7±2 correct items. You can check. Such is the harsh truth of our hotel: the bar counter in your player’s head is tiny. And our poor Bartender proves it daily. Anything beyond those seven stools gets dropped, mixed up, or flat-out refused.

But don’t write the Bartender off yet. He has a few crafty tricks tucked into that frayed vest — enough to do real magic with just seven stools. For instance, I’m sure you’ll struggle to remember this number:

1–7–7–6–3–1–4–1–6–0–9–2–5

«Ugh, why would I? It’s meaningless gibberish! My Wi-Fi router password looked like that — I changed it!»

You’d be right! Seen this way, those thirteen lonely guests have ZERO chance of befriending our serious friend. He’ll just shrug and point to the door.

But magic begins when we, the architects, give those nameless guests a shared story — we group them. When we turn nonsense into meaningful “chunks.” Look again:

1776 — Declaration of Independence.

3.1416 — the pi number.

09/25 — the month and year of this article’s publication.

This trick is called “chunking” (grouping).

(For returning readers: don’t confuse this with affordances. An affordance is a property of an object that “suggests” how to interact with it — say, a button that screams “PRESS ME!”. Chunking is a purely cognitive trick — binding disparate elements into a single meaningful group to cheat the memory limit. Those same buttons might become a tab in Settings!)

And this trick is one of the more interesting tools in our kit!

How do you remember the pickaxe recipe in Minecraft? You don’t memorize “one plank top-left, one plank top-center”… and so on. No! You retain a single image — one chunk — the silhouette of the pickaxe (with a dash of affordance here — heh). Nine crafting-grid cells collapse into one gestalt.
How do you navigate hundreds of spells in Baldur’s Gate 3? You don’t keep them all in your head. You think in chunks: Evocation school, level-1 spells, ritual spells. The UI itself helps you group information so our poor Bartender doesn’t explode.

Now he has a chance not only to serve everyone but to give each guest proper attention — maybe even befriend someone and escort them to the third floor. But let’s not get ahead of ourselves. Even with these tricks, second-floor service is never guaranteed.

Imagine you load our Bartender with a complex task — mixing an exotic cocktail from a convoluted recipe. While he’s sweating bullets to solve it, one guest gets up and leaves, and another takes the seat. Our Bartender, fully absorbed in the work, doesn’t even notice the switch and serves the drink to the newcomer! (Here’s the CCTV footage of the phenomenon known as «The “Door” Study»)!

Brazen? Yes. But that’s reality. If some guests demand too much attention, others will get up and leave.

Think chess! While you’re engrossed in calculating a tricky knight fork three moves deep, you completely miss that an enemy bishop on the far side is already eyeing your queen.
Or in an RTS: while micro-managing in the heat of battle, you might totally miss that you’ve run out of a crucial resource. The guest “Watch your gold” was shoved aside by the louder “SAVE THE ARMY!”.

And right here, in the bustle at the counter, is where that nasty feeling is born — the player thinks the game tricked them. And who will they blame? Not their exhausted Bartender. Oh no. They’ll blame the hotel — poor service, unclear rules, hidden small print, chaotic guests! Players rarely admit their own inattention. Our advice to staff: don’t let it come to this. Unless, of course, paranoia and a sense of “I’m missing something” is your venue’s intended signature.

So how do these disappearances differ from those in the lobby? The first-floor ghosts are guests the concierge never even noticed. Here, in the lounge, the guest was sitting on a stool — they WERE being processed! — but got pushed out by a louder, needier one.

Ah, and one more staffer I almost forgot. See that bruiser in the corner pretending to read a newspaper? That’s our head of security — Stress. Many Game Designers fear him and keep their distance, thinking he’s a source of frustration. In truth, he’s a great guy.

He just takes the boss’s failures too much to heart. To him there are no shades of gray — only triumph or disaster. When he senses the Bartender is about to panic, he “rescues” him the only way he knows — by tossing everyone out. He literally forms a wall at the counter, barring new guests from even approaching the stools to give his boss a second to breathe. That’s the exam moment when you stare at the ticket and your head goes blank — Stress simply won’t let anyone near the Bartender.

But when they sync up… oh, it’s pure art! Think of that clutch round in a competitive game — one versus five. Heart pounding, palms sweating. Stress steps up to the counter. He glares at the freeloaders — “thoughts about the score,” “fear of losing,” “what chat will say” — and they go silent or leave. He imposes order in front of the bar so the Bartender can focus on the essentials: “Aim,” “Listen,” “Move.” And then… the last enemy falls. Victory. The team screams in voice chat. Euphoria floods you.

And Stress? No handshakes. No thanks. He quietly retreats to his corner, straightens his tie, and lifts the newspaper again. His job is done. He doesn’t join celebrations — that’s not his place. His only reward is your elation — that brief flash of pure triumph. As for the cocktail of adrenaline and dopamine now coursing through your veins… consider it his parting gift, a drink he leaves on the counter before anyone starts fearing him again.

Okay — I nudged the narrative a bit to make him look like an underrated outsider! In game design he’s actually well-loved, just under a different name — “tension.” The whole drama is the classic “tension → release” cycle, one of the strongest tools for engagement.

(There are tons of great videos on this, for example «Tension vs Stress in Game Design», and these two are like twin brothers covering it from different angles: «How Games Create Tension» and «How Do Video Games Create Tension?»)

As one quote from those videos puts it:

«Tension is created when the players have enough information to formulate questions but not enough to fully answer them, resulting in a situation where the player is left anticipation of a resolution to those questions».

Drop the metaphors and the whole stools-and-bouncer saga boils down to this:

Short-term memory is the bottleneck — the player’s key cognitive constraint. Our job as designers isn’t to break it, but to guide information through it wisely.

We must respect the 7±2 limit and structure data whenever possible using every trick we have (including “chunking”!) — via UI, grouping abilities, and clear patterns. We must understand that any new, high-priority task will inevitably evict older, low-priority info from this buffer and design feedback accordingly to avoid frustration. It’s a temporary store, nothing more. And for active work with it…

… we need a backstage pass.

Allow me to take you behind the counter — into the “kitchen” where he preps sly mnemonic “snacks” to keep the most important patrons from leaving, and from where he dials up long-term residents on the third floor using that old rotary phone. Because right here, in this tight little nook, is his actual office.

Behind the Bar: Working Memory

Working — or operational — memory isn’t just another label. It’s the elite subspecies of short-term memory that lets us not only store things briefly, but actively process them. And now I’m taking you where ordinary guests aren’t allowed. Peek behind the counter, into the inner sanctum. See our Bartender? Quick as he seems, he’s got, like the rest of us, only two hands, two feet, and one head on his shoulders.

Let’s watch him at work. I’ll ask you to add two numbers in your head: 2953 and 569. No rush — we’ve got time.

…

Well then, if nothing distracted you, during this seemingly simple action your own Bartender pulled off a full operation. You had to keep the original numbers “on the desk” while performing arithmetic on them. The thought process might have sounded like this:

— «Okay, 2953 plus 569…»

— «Ones first: 3 plus 9 makes 12. Keep the 2, carry the ten.»

— «Next: 50 plus 60 makes 110 — don’t forget that carry. Total 120. Great, we’ve got… 22.»

— «Now the hundreds: 900 plus 500 makes 1400 — plus the hundred from the previous step. 1500.»

— «And the remaining 2000. Put it together… 3522. Done!»

If I now ask you for the original numbers or the final result, you’ll likely recall them easily. But here’s the question: what was the sum of the hundreds before you added the carry from the tens? You’ll probably stall. That’s normal! Intermediate results get wiped the moment they’re no longer needed.

It’s always like this. We remember the beginnings and endings of trailers, films, and books better than the middle. That holds for an entire work — and for a level, a quest, even a single dialogue. This quirk of our Bartender is both his greatest strength and his curse.

As you can see, space behind the counter — in this “kitchen” — is tight. If the bar stools can seat up to seven guests, the Bartender can actively juggle only three or four tasks at once. While he’s dialing a third-floor resident on the phone, pouring whiskey for a new guest so they don’t leave, and trying to introduce two others — he’s already at the limit. Add one more task and something will go wrong: the drink spills, the phone message garbles, the guests start bickering.

This memory type is the organizer — it handles complex cognitive tasks and plays a key role in controlled attention and logical reasoning. Which is why we must understand its limits. To fully grasp them, we have to open one more nesting doll.

Because we only have two tools at our disposal — two stores for different kinds of information. First, his visuospatial notepad, where he sketches everything he sees: maps, guests, furniture layout. Second, the old rotary phonological loop phone, through which he receives and subvocally repeats all auditory information: names, dialogues, melodies.

Give him a literal notebook and phone, or treat them as his eyes and ears — same idea. He has only two hands, and he CANNOT use both tools equally well at the same time if both demand complex work.

Now, let’s see what happens when a professional con artist drops by. He shows our Bartender one thing, but whispers something different in his ear — the whole system freezes for a heartbeat. They say this trickster who loves stumping staff is named Stroop. (You can read the dossier on this swindler here: «Stroop Test»).

Let’s torment our manager — and you — once more. Below is an image with a pile of color words. Your task is to not read them, but as fast as possible say aloud the COLOR they’re printed in. Ready?

Feel that… grind in your head? The gears catching for a split second? That’s the conflict. Your phonological “phone” reflexively reads the word “purple”. But your visual “notepad” simultaneously sees it’s written in red. Your poor Bartender receives two contradictory commands at once and stalls for a moment, trying to decide which to trust.

This little experiment shows what happens when two processing channels come into direct conflict. But that’s not always the case, right?

Julius Caesar bragged about doing two things at once. Many still do. Truth is, we’re all roughly the same here. If I turn on your favorite song and you start singing along (loading your “phone”), you can still draw, wash dishes, or drive a familiar route (using the “notepad”) without much trouble.

But as the task gets harder, the system starts to fail. If you’re driving on an unfamiliar road, your “notepad” overloads and you’ll instinctively lower the music to free resources. If your boss calls with an important task mid-drive, your “phone” is busy and you’ll slow down to avoid overloading the “notepad.” And if I ask you to sing along and read a different text aloud at the same time, either the song becomes mumbling or the text turns into word salad. One phone, two lines — that’s not how it works.

What’s happening in our hotel then? When the Bartender is overloaded with “notepad” work, he simply stops picking up the “phone.” Important guests can’t even get through. And vice versa.

Crucially: these aren’t the lobby’s ghosts — the ones never noticed. Nor the guests who got pushed off a stool. These are guests the Bartender consciously ignored because he was up to his eyeballs in something else.

Think Red Dead Redemption 2. You’re riding through the woods, admiring the scenery, tracking the mini-map, trying not to hit a tree — all loading the “notepad.” Meanwhile, characters deliver a sprawling conversation about their plans. If you’re not near-native in English, your “phone” can’t keep up. You either miss half the dialogue or you hit that tree.
Or — heaven help us — Overcooked. Your “notepad” is panicking, trying to track three ticking stovetop timers, two new tickets at the top, and the treacherous absence of clean plates. Right then your “phone” explodes with your teammate yelling: “NEED A PLATE! CHOP TOMATO! MEAT’S BURNING!” Your poor Bartender drops EVERYTHING. He cannot watch the fire and follow commands at once. Guests blush, tremble with rage, and storm out! The timer TICKS, tomatoes DROP, meat BURNS, plates are GONE, your partner YELLS… AAAAAAA!

Oh! My apologies, monsieur. Seems we caught the staff in the midst of, uh… an operational crisis. Let’s leave our Bartender to his… duties. This way — we’ll step into a quieter corner of the floor. We could all use a breather.

Because beneath all this clatter — the shouting and charred steaks — lies a simple, inexorable truth. Bottom line: true multitasking is hard for us, and we’re bad at realizing just how hard. The Bartender’s attentional resources — his workspace, the stools, and the man himself — are finite, which is critical for working memory. And that directly affects how well a guest will be remembered — whether they’ll get a pass to the third floor at all.

From a memory-formation standpoint, only one thing matters: the more actively and diligently our Bartender works a guest’s “order” in his kitchen — the more transformations he performs — the higher the chance that guest will not merely leave, but become an honored resident.

That’s why learning by doing is more effective than memorizing a handout. When a player performs a real action — jumps a gap, combines items, uses an ability — their working memory, our Bartender, is firing on all cylinders. He pulls out the notepad, picks up the phone, cross-checks the data.

And what happens when we just show a wall of rules text? The player’s task is to press Y to acknowledge. That requires no deliberate impulse. For our Bartender it’s a trivial job. Accordingly, that guest’s priority is zero. He’ll nod, let it pass by his ears, and forget it immediately. Why did that guest even show up? Who was he again? Huh? What? Where were we?

I’m sure you feel it too: we’re much more willing to spend time on an energetic, charismatic guest with a gripping story or… ooooo… (mysterious music should play here) a cloaked stranger speaking in riddles — than on a dreary door-to-door salesman with a manual under his arm. Our Bartender is no different. He remembers the one who made him work, think, be surprised — the one who was interesting.

Dossier: The Bartender’s Notes

So, monsieur, we’ve inspected the second floor. And as you’ve noticed, it’s the narrowest and most important choke point in the whole hotel. Here, in the hands of our weary yet vital Bartender, the fate of every guest is decided: will they become a fleeting memory, or earn a chance at eternal life on the third floor? Our job as Game Designers is not to be yet another irritant, but a competent, empathetic manager.

All our work with him boils down to a few simple, ironclad directives:

1. «DO NOT OVERLOAD THE BAR!» — This is the prime rule. Our Bartender has only 7±2 stools. Anything beyond that — UI elements, active quests, win conditions — will either be ignored or will shove something else off a seat. Our job is to clear his counter. Push information outside his head: into readable icons, a quest log, a mini-map. Don’t make the player carry what can and should be displayed on screen.

And here I’ll add a personal, purely practical observation I stumbled into — my ”two-thirds rule”. In short: regardless of how many stools are occupied, whether three or all nine, no more than two thirds of them are ever in our Bartender’s immediate, active focus. The rest sit in an attentional “blind spot,” and switching to them takes deliberate effort. You won’t find hard science for this beyond my experience. But since you’re reading this article, feel free to adopt it — or better yet, challenge it in practice and tell me in the comments!

2. «GROUP THE GUESTS!» — Lonely, unconnected guests are the Bartender’s worst nightmare. He confuses and forgets them fast. Our task is to meet them at the door and form meaningful parties right away. That’s “chunking.” Don’t hand the player 20 separate spells — give them 4 magic schools with 5 spells each. Don’t dump 50 crafting components — sort them by category in the inventory. It’s the best help you can give your overworked staffer, freeing precious mental resources.

3. «DON’T OCCUPY BOTH HANDS!» — Our Bartender has only two tools: a visual “notepad” and an auditory “phone.” Don’t force him to sketch a complex blueprint and hold a crucial call at the same time. Separate critical information. If a tense fight demands full visual focus, don’t deliver key plot beats via dialogue. And vice versa. Let him focus on one channel, or he’ll drop either the notepad or the phone. At any given moment, you as the designer must decide clearly which channel — visual or auditory — has priority.

4. «GIVE AN INTERESTING ORDER!» — And finally, the most important thing. The Bartender remembers not what he was told, but what he worked on. A simple instruction read and dismissed with a button press is a dull order he’ll forget in a second. Don’t expect players to retain a rule from a passive tutorial. Make them apply it, fail, try again, and finally succeed. That’s the most reliable way to turn a temporary guest into a resident.

Once again, if we compress our observations into a short staff memo, it reads like this:

SIMPLIFY the interface and information flow — don’t force the player to juggle more than 5–7 active elements at once.
GROUP related items (in inventory, skill trees, quest logs) so the player can process them as a single whole.
SEPARATE channels of perception — don’t make critical audio and visual cues compete for attention.
ENGAGE the player through doing — the best tutorial is an interesting problem to solve.

And what happens when our Bartender likes a guest so much that he decides not just to serve them, but to issue a permanent pass? Well, for that we’ll have to climb to our hotel’s final, most mysterious floor.

IV. Third Floor: The Rooms.

There’s only one elevator up here — very quiet. Our investigation is essentially nearing its end, because all the important guests, including you, have made it here — to Long-Term Memory. The information has settled. But… remember I mentioned murders? Real murders. The ghosts and the guests pushed off their stools were minor offenses. The real tragedy unfolds right here. It’s time to learn who our Bartender keeps calling so desperately — and why those calls so often go unanswered.

There’s no staff on this floor. No concierges, no bouncers. Only endless corridors and countless rooms. The Bartender’s calls from the second floor go straight into these rooms.

Our long-term memory is a system storing all kinds of information: from the sequence of moves for driving a car to the name of your first pet. And whereas sensory and working memory are bound by strict limits, long-term memory has, so far, shown no hard limits of time or capacity. In other words, potentially we can keep an unlimited number of guests for an unlimited time!

Whoa… do we really have that many rooms? But let me repeat and emphasize — potentially! Before we talk about how to keep our guests safe and sound, I need to tell you about two kinds of rooms in this maze.

In the Archive Wing (Explicit Memory), the guests who can be described in words take up residence. This is memory for facts and events. It includes the names of characters from your favorite RPG, Elden Ring’s tangled lore, your Path of Exile build, plot twists of the last game you finished, and that moment you beat a tough boss for the first time. In essence, that’s memory for facts (semantic) and for events (episodic).

In the Procedural Wing (Implicit Memory) live the guests that can’t be put into words — only shown. This is memory for actions, which doesn’t require conscious recall. The muscle memory for perfect parries in Sekiro, the key combos for calling stratagems in Helldivers 2, the skill of driving, or the instinct to reload after a short burst in a shooter.

So, super briefly so we don’t drown in terms:

Explicit memory is what you “know.”
Implicit memory is what you “can do.”

And we’ll go through them quickly now.

Left Wing: Implicit Memory

Let’s start with the wing most interesting to us as architects of hotels and game worlds — the Procedural (Implicit) one. Here our residents don’t just sit in their rooms; they constantly interact, forming invisible connections and habits. And there are two tricks we can and will use all the time: so-called “priming” and “implicit learning.”

The first trick — priming — is as simple as two plus two. Speaking of simple: the moment you read “as simple as…”, your brain was ready for the rest. Let’s test that again. Here are a few phrases — finish them yourself (and if you’re not a native English reader, feel free to recall the equivalent “winged phrases” from your own language — the point stands):

No pain, no…
The early bird catches the…
May the Force be…

Notice it? You didn’t even think — your brain filled in the missing word. This mechanism is similar to old T9 on phones and to what modern AI does so well — we’re great at predicting the next word in a familiar context. Hear “bread,” and your brain readies “butter.” If you played word associations as a kid, you know exactly what I mean. And it’s incredibly useful in game design.

Think of the hit marker the Call of Duty series popularized. Today, booting up almost any new shooter, you subconsciously expect that visual and audio feedback. Your brain is primed by years of play. Same with controls: seeing W move you forward, your fingers instinctively find A, S, D; to crouch you’ll hunt for CTRL or C. We don’t need a tutorial for the basics because the industry has been priming us for these standards for years.
Throughout a level you fight small spider-bots. Before attacking, they emit a distinctive chirp, and their mandibles flash red. You learn to react to this dual signal. Then you meet a giant boss and, mid-fight, it emits that same chirp, its massive claws flash red. You don’t need a tutorial. Your brain, primed by earlier skirmishes, instantly puts two and two together: the attack pattern will be the same — just scaled up.

Honestly, even I — telling you all this — keep priming you by bolding key terms so your brain subconsciously tags them as important. But there’s a darker, deeper trick — the one that turns simple associations into reinforced reflexes. Its name is “implicit learning”.

Behind that odd label hides something painfully familiar. You know how associations work. In the morning you reach for coffee to finally wake up. A bakery smell on your commute briefly throws you back to childhood. Sitting at your desk, you reflexively put your phone on charge and turn on music.

All of these are little bells that trigger our residents in the Procedural Wing. For them, they’re calls to action. The coffee ritual calms and sets your mood. Scents evoke memories. Pre-work actions prep you for upcoming tasks. It’s the power of habit — and if harnessed carefully, it’s magic.

Many know Pavlov’s experiment: the dog salivating at a bell, anticipating food. That bell rings in your player’s head constantly. And using this essentially manipulative method… Game Designers can find it scary.

Here I must pause, as your doorman, and point to the moral dilemma. Using such powerful psychological tools — and design in general — places huge responsibility not only on the player but on us. A true doorman uses knowledge of guests’ habits to make their stay richer and kinder. He doesn’t slip them drugs or run cons.

But some cross to the dark side. They use this knowledge to build a casino disguised as a hotel. That’s the fundamental difference between Balatro, where the joy of building hands is the reward, and a real casino, where the same dopamine loop exists only to drain your wallet. This step over the line is what enraged many developers (even more than players!) during EA’s lootbox scandal. Half the mobile market runs on these tricks pushed to the extreme.

So before we go on, I’ll simply say — please be careful with this knowledge.

Alright — the essence is simple! The difference between priming and implicit learning is fundamental, even if not obvious. Priming is a contextual cue. It tunes the player, creates expectations based on prior experience, but it doesn’t forge new automatic behavior. Implicit learning, on the other hand, is conditioning at the reflex level. It’s the process of building a strong, unconscious link between a specific stimulus (a sound, a color, an animation) and an immediate outcome (danger, reward, failure).

Priming whispers:

«Be ready — a boss might be near.»

Implicit learning yells:

«ALERT! TAKE COVER RIGHT NOW!»

Accordingly, these reflexes let us do things like:

Think Metal Gear Solid. That alert sound when you’re spotted. The first time it’s just a sound. By the fifth, it’s a panic trigger. Your heart speeds up, your fingers reach for “prone,” your eyes hunt for cover. No text taught you this. The game simply paired that sound with negative consequences over and over.
Or the opposite — the coin pickup chime in Super Mario. That short, cheerful “ding!” isn’t just feedback. It’s a micro-dose of dopamine tied directly to the action. The game doesn’t say “collect coins, that’s good.” It trains you to enjoy it at the most basic, reflexive level.

To cement it: these residents are the ones who stay with us the longest. As they say, “once you learn to ride a bike, you don’t forget.” But this is delicate stuff — working with this memory type carelessly yields nothing. You can’t build a complex RPG system or a branching narrative on reflexes alone. This tool suits fundamental, constantly repeated actions.

So, please, remember one thing:

Implicit memory isn’t about the player knowing what to do. It’s about them feeling what to do.

On that note, we can leave the Procedural Wing in peace. Of course, there are many more tricks and habits there, but we care about the big picture. And as you’ve noticed, almost no one dies here. Residents either live forever or simply move next door — to the Archive Wing (Explicit Memory). And here, paradoxically — in the literal final part of our journey — we’ll have to talk not about clever tricks, but about… inevitable losses.

Right Wing: Explicit Memory

As you’ll remember, this wing houses knowledge. Facts, events, names, rules. To summon a resident from a room, you have to dial the full number, wait for them to pick up, and politely ask them to come down. And here, if we don’t want to doom our residents, we have just a couple of ways to avoid a tragic end.

See… another detective was here before us. A dour German named Hermann Ebbinghaus. And, as the dusty reports on the desks show, he uncovered a terrifying regularity in this wing. He called it the «Forgetting Curve». This — I don’t fear the word — catastrophic graph is one of the most important pieces of evidence in our entire case.

And I assure you: depending on how long you’ve been reading, you’ve already forgotten at least some of the words I asked you to remember at the very beginning. The text is roughly a half-hour read, but I know many of you are reading in chunks. And in truth… I! just now, with my own hands, killed those three guests in your head — unless you save them. You have…

5…

4..

Time is running out!

1!!!

DONE.

Congratulations. You just freed up a couple of rooms — if you didn’t recall that I meant marshmallow, gravity, and Sisyphus. But I don’t blame you! And please don’t blame me. Frankly, those residents… just stopped being useful to you.

Time is relentless, and our brain never stops working — which means it never stops forgetting. We simply cannot keep our focus on one object for too long. So that graph tells us the following.

Within 20 minutes of checking into the Archive Wing, about 40% of guests vanish without a trace. After one day, that figure exceeds 70%!!! SEVENTY PERCENT!

It’s worth noting, though, that this “forgetting curve” looks so scary mostly when we talk about meaningless information learned without purpose. In a well-designed game (which is what we’re building) it will look different. If the material evokes emotion, demands deep processing, and repeats across contexts, the odds of forgetting drop dramatically. But — and this is important — even in ideal conditions, pushing long-term retention above 50% is a titanic task.

Moreover, some information types stick more naturally than others. New material embeds better if it’s associated with something already known. Simple is easier than complex. Organized is easier than chaotic. These are simple truths we, ladies and gentlemen, should already have absorbed!

We’ll apply all of this with one last piece of knowledge — the tool that puts a final period in our investigation: the spacing effect in design (or, the polar opposite of the “Forgetting Curve,” our good friend the “Learning Curve”).

There’s a problem: our guests disappear from their rooms. How do we fix it? DON’T LET THEM DISAPPEAR! Yes — it’s that simple. We’ll design service such that residents have neither the chance nor the desire to leave our hotel. Everything we’ve learned boils down to one thing: to check in, check out, and summon the right guests and residents to the lounge at the right times.

A sense of measure and tact matters — it’s… good doorman manners. No matter how hungry you are, you wouldn’t swallow a whole burger in one bite. Zero pleasure. The “fill the stomach” function might be met, but the process — the experience — is gone. Books? Have you ever tried to gulp down a dense treatise in one evening? I have. Know what I got from it? Exactly — nothing.

Likewise, as architects, we must NEVER put the player in a situation where all information is dumped at once, never reinforced, never sorted, violating every rule of our hotel. True masters know WHY the player needs information, WHEN to present it, HOW to present it, and WHAT to accompany it with.

For instance, many Nintendo games teach extremely well. Take any classic The Legend of Zelda:

First you learn to swing a sword (A). The game feeds you bushes to cut for rupees (A1), then a simple, sluggish enemy you can just click down (A2). Mechanic A is reinforced in two contexts: exploration and attack.
Later you get a shield and learn to block (B). An enemy appears who shoots at you; you reflect their projectiles while standing still (B1).
You use the sword again to hit a wall crystal switch (A3).
Then the game throws in a shielded enemy. You can’t just hit (A). You must wait for their windup, block with your shield (B), and then, in the brief vulnerability window, strike with the sword (A).
Thus the game makes you combine two learned mechanics into a new tactical sequence (BA1).

Together, this forms an ideal learning curve: steady reminders via practice, at tuned intervals, that not only reinforce, but engrave the mechanic into memory.

But here’s the snag: your player still has a dozen unplayed games in Steam; friends are dragging them into a new co-op; tomorrow is Monday and there’s work; the boss has an urgent task — and… the stomach growls; dinner won’t cook itself!

Reality always wins. Our job is to figure out the ideal session length during onboarding and design — whether 20 minutes or a couple of hours — and build around it. Sure, these bounds can blur in development, but by mapping the route early you can pre-plan convenient stopping points.

I love quoting Huizinga, so I won’t resist now. The “magic circle” that games create is powerful yet fragile. It’s a circle — it has boundaries. Thoughts from the outside world seep in less often, but the circle itself won’t keep tapping your shoulder amid real-life bustle. So never blur that boundary into haze or wall it off entirely. Our goal is a comfortable setup where the player isn’t afraid to step out — and, crucially, wants to and can easily step back in.

The player’s session will end sooner or later. Better that you choose where it’s comfortable to pause — with save points and clear chapters — than drain their memory resources by making every moment critical.

Also, controls are even more prone to being forgotten. After your strategy game, the player might hop to a shooter, then switch from PC to console. So as odd as it sounds — however “standard” your layout — keep gentle reminders of key actions close at hand.

Everything in moderation. Don’t cram a thousand pop-ups — but don’t abandon the player either. Care for them the way you’d want to be cared for. Beyond that line is no longer care, but overprotection — the very “design out of fear” we’re not fond of here!

These “ifs” and “buts” aren’t to leave you hanging. On your project, you’ll face these dilemmas — and you’ll have to decide. There’s no universal recipe. But remembering two things is vital: your tools, and the dilemmas your player faces. How well you understand both determines the quality of your game’s designed experience.

Everyone chooses the weapons they can afford. Some track how long a player’s been away and choose which hints to show. Others temporarily make enemies a bit weaker so the player can get back in shape. I’m sure you’ll invent a couple of mechanics tailored to your game to help players not forget something very, very important! In any case, I want to end on a line I adore:

All of this is UX in service of the player.

And with that… we close our final case file.

Dossier: The Clockwork Killer

So, monsieur, the case is closed. We’ve found our killer. He’s elusive, invisible, utterly merciless. His name — Time. His weapon — Forgetting. He doesn’t storm the hotel with a gun. He simply waits. Waits for us to look away, for our Bartender to be busy, for the player to quit the game. Then, quietly, one by one, he leads our Guests out of their rooms and erases any mention of them from the register. To resist this silent horror — and strengthen our security department — the hotel staff has only three directives:

«MAKE THE GUESTS INTERESTING!» — We can’t just check a Guest into a room and hope for the best. We must turn them into a welcome Resident. Link new information to what’s already known. Wrap complex rules in simple images. Turn facts into feelings. And above all — reinforce what the player knows (Archive Wing) with what they can do (Procedural Wing). Don’t let a rule live only in a manual — make it part of action.
«REMIND THE GUESTS!» — This is the very “spacing effect.” You can’t introduce a mechanic in Act I and expect the player to recall it in Act III. We must periodically, at well-tuned intervals, summon our Residents to the lounge bar. Bring back old mechanics in new contexts. Set tasks that require combining old and new knowledge. Don’t let the player forget what you’ve already taught them.
«DON’T LOCK THE HOTEL DOORS!» — This is respect for reality. The player will always leave our hotel. Our job isn’t to stop them — it’s to make their return as comfortable as possible. Design clear save points, keep a quest log, create gentle reminder systems. Don’t punish players for taking a break. The scariest enemy of memory isn’t time inside the game — it’s time spent away from it. Convenient saves, concise catch-up summaries, subtle control reminders — all of it tells the player: «We remember you and we’re waiting. Your room is ready.»

We’ve reached the final chapter of our staff memo. It’s the most important one — because it’s not about greeting a Guest, but about making them love our hotel and stay forever.

LINK new knowledge to existing experience. Information without a memory “hook” is the first candidate for oblivion.
STRENGTHEN learned material through spaced repetition across contexts. A mechanic shown once is a mechanic forgotten.
TURN passive knowledge into active skill. A rule applied in practice is remembered an order of magnitude better than a line in a tutorial.
DESIGN for returning, not just first-time play. Remember: the chief enemy of memory isn’t difficulty — it’s the break between sessions.

With that, our long — and hopefully not too tiring — investigation comes to an end. But before I leave you, allow me a few parting words.

V. Conclusion: Handing Back the Room Key.

Phew, that’s it… I’m taking off this stuffy tailcoat, tossing the monocle, and dropping the manners that aren’t really mine. Time to lay the cards on the table — but first, allow me a bow for making it this far! Huge thanks!

With all these metaphors, I — your humble servant… ugh, there I go again…

Anyway: Slepok, the author of this blog — I’ve been trying the whole time to prevent you from forgetting this piece and what’s inside it. This hotel, the doorman’s silly outfit, the detective story — all of it serves one purpose: to help YOU remember how memory works, just a little better.

I know some will find this text childish or convoluted; I’m sure a few will throw a stone at Ai, saying most of it reads this way because I shamelessly kept smashing “send” in a chat. But that’s far from the truth — and the truth is simpler: I just wanted at least one out of ten readers to be able, someday, to tell someone about memory as if it were a fun detective story.

Game design is like that. Or at least, that’s how I want to see it.

Now a peek backstage. Most of this text was rewritten… countless times! Since this was more of a “breather” from other, more “serious” pieces, it’s probably the most tortured material of them all.

And, to be honest — albeit post factum — a lot draws on Celia Hodent’s «The Gamer’s Brain: How Neuroscience and UX Impact Game Design». In places I didn’t hesitate to paraphrase whole paragraphs. Still, there’s a big share of my own reflections and field notes — for two reasons.

First, I wanted to structure this knowledge for myself, so I can explain it better later — to my team, and to myself.

Second, to write something both USEFUL and INTERESTING.

I still feel the whole hotel-and-staff story is a bit ornate, BUT. I couldn’t not try! I often memorize things as logical images. For instance, when explaining to my parents what a Game Designer does, I always reach for a playing-cards metaphor:

If the developer is the printing press that produces 52 physical cards, and the artist is the one who draws the patterns on them, then the game designer invents the rules for “poker” or “war” — or maybe for a brand-new game no one’s seen yet!

They say a person dies twice: first when the heart stops, and second when their name is spoken for the last time. So let me end with something slightly counterintuitive:

I genuinely feel for the developers of Concorde, for the team behind Anthem, and even more for the lone indies whose games were never noticed among the thousands released on Steam every day. I feel for the old games that each year get harder to emulate or find in working shape.

Don’t get me wrong — a commercial flop is often deserved. But I’m sure no artist, no programmer, no designer ever woke up thinking:

«How about I make something today that everyone forgets in a week?»

The tragedy in these projects isn’t just the money lost. It’s the thousands of hours poured into crafting an experience that never spawned valid, valuable memories. When a game is forgotten, the work poured into it is, in effect, erased from cultural memory.

And that’s the point. The only medium we truly record our game onto is the human mind. All our work — the sleepless nights, the fights, the strokes of genius — exist in one place: the player’s head. The moment they turn the game off, all that remains is a memory. Good, bad — or worst of all, none.

We don’t design for computers. We design for people. And people… people forget.

See you where the secrets are even deeper → t.me/slepokNTe 👀

— The End —

There is (no) problem with Ai.

Nicolaos Tsitsonis — Fri, 15 Aug 2025 08:55:47 +0000

Let’s be honest. There’s a fear hanging in the air — not just in the game dev community, but everywhere. A thick, almost tangible fear, the kind you feel you could spread on bread instead of butter. It seeps through every other thread on X (formerly Twitter), in hushed Discord debates, and in the headlines of the less-than-brilliant press. And this fear has a name — Artificial Intelligence.

And you know what? Talking about it feels absurd to me. Not because I don’t see the problem, but because we’re discussing the wrong thing entirely. There’s nothing inherently wrong with AI — just as there’s nothing wrong with a hammer, electricity, or code itself. The problem is not in the tool. The problem is in the hand that’s afraid to pick it up, and in the eyes that are afraid to see what the tool might reveal.

That’s why I want to take this discussion out of its usual frame and approach it from my own perspective. And yes, I know how it sounds coming from someone who calls themselves a Game Designer.

«Why are you even getting into this topic? Isn’t it more about artists and programmers?»

The answer is painfully simple: Because game design is, first and foremost, the craft of working with systems — with rules, loops, interactions, with that invisible glue that turns a bunch of assets and lines of code into an experience. And when a new, fundamental system appears on the horizon, one that can change the very rules of the game, my professional duty is not to hide from it in fear, but to dismantle it piece by piece and understand how it works. And, more importantly, how to make it work for me.

That’s the reason behind this little rant. This is not yet another attempt to whitewash AI, nor to pelt it with stones — there are already plenty of those articles. This is an attempt to reflect and, perhaps more than that, to simply look at it through the only lens that matters to me: the lens of systemic design and the creator’s responsibility. We won’t be discussing whether AI is good or bad. We’ll be talking about why a panicked rejection of it is not a sign of high moral ground, but of creative stagnation.

System. Wires. Systems.

Let’s forget the phrase “Artificial Intelligence” for a moment. It’s overloaded with Hollywood imagery, fears of Skynet, and pseudo-philosophical debates about “consciousness.” All of that is just noise — informational clutter that prevents us, as designers, from seeing the essence. Let’s look at this phenomenon the way we (game designers) are used to looking at any game: as a system.

Because what is any game, really? It’s a set of rules, mechanics, and feedback loops. And “AI” in this context is no exception. In game development, we’ve been working with its ancestors (algorithms!) for decades — we just called them by different names. The “Director” in Left 4 Dead, which analyzes the players’ state and spawns zombie hordes along their path — that’s systemic “AI.” The procedural level generation in Spelunky or the story generator in RimWorld, which follow strict sets of rules and constraints to create unique yet playable experiences — that’s also systemic “AI.” Procedural generation, algorithms, enemy logic — all of this could, with some stretch, have been called “AI” back then. We never feared these systems, because we understood their purpose and their limits. We knew this wasn’t “creativity,” but a complex — yet predictable — algorithm.

And modern Large Language Models (LLMs) — the very thing causing all this panic — are simply the next, exponentially more complex iteration of the same idea. I’m not saying anything groundbreaking here, merely echoing what’s already been written: AI is not a mind. It’s an incredibly powerful probability-matching engine. It doesn’t “understand” your request. It has analyzed trillions of texts and learned, with astonishing precision, to predict which word should come next so the result looks like it was written by a human.

If we look at it as a system (because metaphors make thinking easier, and I still want to tie this back to game design), we can break it down into familiar mechanics:

The Prompt (our controller). This is our way of interacting with the system. And just like in any good game, the outcome depends directly on the quality of our input. Asking a vague, sloppy question is like mashing every button on the gamepad and then wondering why the character isn’t doing what we want. Crafting a precise, multi-layered, contextual request — specifying role, goal, and constraints — is like pulling off a complex combo. Responsibility for the result lies not with the system, but with the operator.
The Model (the rule set). This is essentially the “physics” of our new tool. We don’t need to know how every transistor inside works — just as we don’t have to understand the code of the Havok physics engine to use it. But we do have to know its properties: its strengths (structuring, brainstorming, finding non-obvious connections), its weaknesses (hallucinations, lack of real understanding, factual errors), and its built-in “biases” based on the data it was trained on. Ignoring this is like designing a platformer without understanding how gravity works in your engine.
The Output (the feedback loop). And here’s the key point: what AI produces is not the final product. It’s the first iteration. It’s a “procedurally generated” draft that we, as designers, must analyze, critique, refine, or discard entirely — keeping only a single useful grain if needed. Working with AI is not delegation — it’s the start of a new game loop: “Prompt → analyze output → refine prompt → analyze again.”

When we break AI down into these parts — “controller,” “rules,” and “feedback” — all the mystical fog disappears. It stops being a threat and becomes what it should be: just another tool in our arsenal, like Unreal Engine, Figma, Notion, and so on. And the value of any tool is defined not by its complexity, but by a clear understanding of which tasks it can solve better, faster, or deeper than anything we’ve had before.

The question finally shifts from:

«What is this?»

To the only one that matters:

«What do I need this for?»

The Most Widespread Tool.

And here we arrive at the most dangerous illusion that has trapped the majority. Because the entry barrier to AI feels deceptively low — open a chat, type a question, get an answer — many have fallen into the fatal delusion that this is all there is to learn. That it’s not a tool to be mastered, but simply a talking box.

That’s nonsense. Absolute nonsense.

No one in their right mind opens Blender, creates the default cube, and decides they’ve mastered 3D modeling. No one launches FL Studio, drops a few notes from a preset library, and calls themselves a composer. We understand that behind the apparent simplicity of these tools lie years of practice, study, workflow building, and the shaping of one’s own style. So why do we deny that same depth to the newest — and potentially the most powerful — tool of them all?

The immediate answer: because this depth looks like nothing we’ve seen before. AI is not primitive. On the contrary — beneath its simple interface lies a complexity of a kind we, as mass users, have never encountered. This is the paradox: staggering complexity wrapped in the simplest possible interface, creating the illusion of complete understanding. In just a few years, we’ve evolved from simple chatbots to “agents” — systems that can independently use other tools to solve tasks. Yet most people still don’t understand how to use them, and continue to approach AI with requests like “write a birthday greeting for my friend.”

And even then, for anything more complex than that, AI will not give you a finished result. Never. You will still need to research and verify on your own. Texts — you’ll have to fully rewrite them to give them style and meaning. Images — you’ll spend a long, painstaking time refining them to get the right composition and emotion. Code — you’ll have to refactor it, because it’s often inefficient and poorly scalable.

So what, then, is its primary purpose, if it doesn’t do the final work for us?

People try to make it an executor, but its main function is to take on all the “dirty” cognitive work that slows down the creative process. Routine information gathering, structuring messy notes, sifting through hundreds of dull options to find the one worth keeping — AI does all this faster and more efficiently. It frees up our own “processor” for the most important part: generating unique ideas, making strategic decisions, and — most importantly — exercising taste. Mastery of this tool means knowing how to delegate every bit of routine to the machine, so you can keep for yourself everything that is art. It is the art of designing a dialogue that expands the boundaries of your own thinking.

«First we build the tools, then the tools build us»

(с) Marshall McLuhan

Whenever a powerful new tool enters any ecosystem — be it an online game, a social network, or now AI — we see the same predictable pattern of behavior. It’s the unspoken “1-9-90” rule: in any community, 1% of people create content, 9% comment on and modify it, and 90% simply consume it. Simplified for AI, the breakdown looks like this:

90% — Consumers. These are the people who see AI as the final product. Their interaction model is simple: Prompt = Result. They treat it like a search engine or a vending machine. Their disappointment is genuine, because the tool fails to meet their expectations — it doesn’t produce a masterpiece on demand. They’re not bad people; they simply use the tool without understanding its true nature. From that ignorance, fear can grow — because if you don’t know how it works, how can you know how it might be used?
9% — Operators. This group has mastered the basic loop. They know how to generate content in large volumes and they do it. Their focus is on quantity and speed, not on quality or meaning. Not out of malice — that’s just their strategy. Their activity creates the “informational noise” and tons of repetitive content that frighten the first group.
1% — Designers. The only ones who have understood the core truth: AI is not a source of final answers, but a testing ground for questions. Their model of interaction is dialogue, iteration, experiment. They don’t ask “do it for me,” they say “help me do it.” They use AI to generate hundreds of variations, see non-obvious connections, and test their boldest ideas — only to then apply their own will, taste, and experience to extract the single grain of gold and refine it to perfection. They do not delegate creativity. They design it.

The truth is, we (not “me and my generation” — I wasn’t even born then, but rather “we” as people) have been here before. With the internet. It was feared too, predicted to destroy social bonds and replace real life. And where did we end up? For 90% of society, it remained a consumption tool — an endless feed of social networks and entertainment. For 9%, it became a digital wasteland to exploit — meaningless videos, dead-end websites, spam, clickbait, and scams. And for that 1% (which, over time, grows but never surpasses 9%) of truly curious people, it became vital — a platform on which they built new economies, created new art forms, and gained access to the sum of human knowledge to make things once thought impossible.

So it would seem we have our answer: simply strive to be in that one percent. To seek not answers, but better questions. But what happens when that very 1% — the few who have understood the rules of the game — are forced to operate in the eye of the storm?

Because that’s exactly where we are right now. This is a real gold rush, where everyone is scrambling to stake their claim. The technology is being shoved into every possible corner — from your smart fridge to your text editor — often without the slightest understanding of what real problem it solves. The line between meaningful integration and mindless marketing hype is vanishing before our eyes.

And in this chaos, the most unfair and counterproductive reaction emerges — blanket condemnation. When LITERALLY EVERYONE and EVERYTHING ends up in the same pot, the torch-bearing crowd stops caring who’s who. It just wants to burn everything connected to the new, the unfamiliar, and the frightening.

And that’s where we come to the hard part.

The Coin’s Side Edge.

…

I could skip this part. Honestly. Having laid out all the systemic arguments, I could jump straight to the conclusion. But that’s the catch. My goal is not to convert anyone, nor to drag people from one camp to another. That would be foolish. And I’m not about to wag my tail trying to please everyone. So that means I have to take a side, right?

I completely understand everyone who sees AI as a problem — who looks at the Steam front page with frustration and sees the flood of shameless junk, cobbled together by “vibe coders” from generated assets and soulless images. I share that pain, because it strikes at what matters most — the value of invested work and talent.

But I also understand those for whom ChatGPT has become the new Google. Those who ask it what movie to watch tonight, to fix a sentence, to solve a problem for them, to help finish a dry work email to their boss. They’re not committing evil. They’re simply using a convenient new tool that saves them five minutes of their life.

Both sides are part of the same picture.

Everything is understood in comparison. That wonderful, thrilling feeling from your very first prompt will never come back — it’s gone. Just like the magic our parents or older colleagues once felt from their first search query in a browser. It’s become mundane.

And if there’s any side worth taking today, I’ll take the side of those who don’t try to deny the obvious. We can dig endlessly into the details — and this whole rant is about them — but the bigger picture is simple: AI is not going to disappear from our lives. It will become as much of a background presence as electricity or the internet.

And here, on the ashes of old arguments, each of us faces the real choice. Not what to do with AI, but who to be in the age of AI. Whether to see this era as the end of something old and familiar, or as a chaotic — but full of incredible potential — beginning of something entirely new.

Conclusion: Intent > Generation.

«We were born too late to explore the Earth, and too early to explore space»

The quote above is perhaps the most convenient self-deception in history. People simply don’t look at their own feet. We are not living on the sidelines — we are in the epicenter of a creative explosion, in the most avant-garde stretch of history, a moment when the majority of ALL the art we know and love is being created. And so, the art is a discovery of our self.

And right in this very moment, we are handed a new, untamed, fundamental tool. And what do we hear? “It will kill the soul”, “It’s not real”.

Denying AI today is not just conservatism. It’s as if the first filmmakers had rejected editing because it “kills the soul of a single theatrical take”. As if musicians had refused electric guitars because they “distort the pure sound of acoustics”. Yes, AI can generate an endless stream of brain-rot animals and other noise. But a hammer can drive a nail, or it can shatter a sculptor’s masterpiece. The tool does not define the outcome — the creator’s intent does. The difference between meaningless generation and a work of art is the will, taste, and vision of the person behind the process.

The fear many have is that AI will make creativity unnecessary. But the reality is the opposite. When generating “anything at all” becomes trivial, the value of something deliberate, refined, and deeply felt skyrockets.

Now that means only one thing — there are no more excuses. You can’t just sit this out. Don’t fear that AI will kill creativity. Fear a world where the rules for using it — and the ethics that govern it — are written by people who understand nothing about creativity, while you stood on the sidelines. In the past, you could say — “I don’t have the means to bring my idea to life”. Now the only honest answer is — “I don’t have an idea worth bringing to life”.

When magic became available to everyone, the true magic turned out to be having a dream — and the will to make it real.

And see you where the secrets are hidden → t.me/slepokNTe 👀

How does Game Design decide what goes on this card?

Nicolaos Tsitsonis — Thu, 17 Jul 2025 21:31:30 +0000

“What-How-Why” or “Why-How-What”?

Anyone who has ever tried to design a game knows the sacred trio of questions: “What?”, “How?”, and “Why?”. In theory, it’s simple: first, define the goal (Why?), then work out the mechanics (How?), and finally wrap them in content (What?). That’s in a perfect world. In reality, on the battlefield, our poor question “Why?” is the most cowardly soldier. It’s the first to flee under the siren call of a “cool idea,” hypnotized by the final image in the team’s imagination, or crushed by that inner dreamer who drowns out the voice of reason. Add deadlines, team dynamics, or, conversely, the echo chamber of solo development — and there it is, our fundamental question, collecting dust on the farthest shelf, right next to those first napkin sketches.

I’ve always known this. But knowing it is one thing — running head-first into it is another. Recently, while working on a game with my team, our stack of interconnected mechanics finally brought us to the card system — a core part of the gameplay. And I was, to put it mildly… Surprised!

Not because I had imagined it “wrong.” Far from it. The surprise came when I went looking for references, trying to understand: “How do people even build card systems?” And then I drowned in a swamp of “what” and “how.” Dozens of articles dissected individual card balance. Hundreds of videos showed how to make flashy effects. But nowhere (well, almost nowhere) did I find a clear answer to the main question:

«How do you design a card system for your own game? What questions should i ask myself?»

Left alone with a pantheon of industry icons — from Hearthstone and Slay the Spire to good old poker and Durak — I realized something. The complexity of these brilliant systems doesn’t rest on hundreds of rules but on a single question, the one that takes us back to the beginning. It’s both a framework and an answer, and the harshest filter of all.

So no, I’m not about to reinvent the wheel. I’m just here to remind you why the question “Why?” should hang in the most visible spot on your desk. Because it became my mantra. I started asking it of myself, my team, and every little detail in the project — and for good reason! I’d catch myself pacing the room, muttering something like:

«Why… why… why did I even come up with this?…»

From the outside, it probably looked like a designer driven mad by his own question! But oddly enough, this little philosophical torture was the best thing that happened to the project. By forcing myself to answer endless “Whys,” I started cutting the fat, strengthening what mattered, and deliberately building design around clear goals. In essence, I gave the project an exam in meaning — and while it frayed my nerves, the end result was far more cohesive and intentional than I could have hoped. Yes, a simple question nearly drove me insane, but it made our game (and me as a designer) better. And this piece — well, it’s the aftermath of that sprint: a revelation and a small framework for my fellow Game Designers!

Why is the question “why” the most important in design?

The world of game design is full of important questions:

«What are we creating?»

«How will it work?»

«Who is our user?»

You get the idea! All of them matter; they’re all part of the process. Yet standing apart from the rest, like a granite monolith, must be the question “Why?” It is fundamental. It is the root. Why? Because it uncovers the meaning and purpose of everything we do. If a designer can’t clearly, without hesitation, explain why a particular card, system, mechanic, or feature is needed, chances are it isn’t needed at all — neither by the designer nor, more importantly, by the player.

There’s a famous phrase coined in the early 20th century by architect Louis Sullivan:

«Form follows function»

Simply put, design (form) should arise from its purpose (function), not from arbitrary aesthetic whims. Every detail must have intent — utilitarian, emotional, systemic, but consciously chosen. The entire 20th century carved this principle into stone — from architecture and industrial design to UX/UI. Naturally, it holds just as true for game design. No game mechanism should exist because “other games do it,” but because it answers a specific design need, conveys a particular idea.

When a designer trains his mind to ask “Why?” automatically, he builds a presumption of purpose into his work (in other words, you assume everything has a reason, not just “I felt like it, leave me alone”). Such a designer can justify any decision: Why does this card cost 3 mana instead of 4? Why does that enemy use this attack pattern? Why is this gameplay loop structured this way and not another? It’s more than a self-check tool. It’s armor — armor that protects both you and your project.

Sooner or later someone — a producer, a lead developer, a teammate, or, worst of all, a sharp-eyed player on a forum — will inevitably ask:

«So why did you do it that way?»

That’s the stress test. If the answer is an uncertain mumble or, heaven forbid, “uh… I thought it looked cool”, trust in the design — and its author — collapses. (Sure, there are exceptions; no one accuses the creator of ULTRAKILL of starting purely from “what’s the coolest thing,” but even there the question “why” mattered — don’t let appearances fool you.) Yet when you have a clear, hard-won “why”, even the most contentious decision feels measured, logical, and justified.

This works on the macro level, too. In his “Golden Circle” concept, Simon Sinek (see “Simon Sinek — The Golden Circle — TEDTalks 2009”) convincingly shows that the most successful companies and leaders build everything around answering “Why?” Of course, we’re not selling iPhones here, but the principle is the same: players instinctively gravitate toward games where they can feel intent, purpose, an author’s vision. If a design is stitched together without a clear sense of why, players detect it instantly. A game can look pretty and even function, but it won’t resonate. It’s hollow — because the creator never defined its essence.

So the question “why?” is the very foundation beneath the building — if not of your entire game, then at least of every system or mechanic. Without it you can slap something together, throw in lovely assets and “cool” features. But that structure won’t stand for long; it collapses under its own weight of meaninglessness. With a solid foundation of answers to “why,” even the boldest, riskiest design decisions gain granite-like stability — because they rest on tested purpose.

Practices that help you find your “why”.

All right, we’ve established that thinking about WHY is essential. But how do you put this philosophy into practice? Understanding the value of the question is one thing; learning to apply it constantly — without falling into endless self-analysis — is another. Below are a few techniques that help me stay focused on the core, especially when dealing with complex, multi-layered systems.

1. The “5 Whys” Method (or “Switch On Your Inner Child”).

You’ve probably heard, at least in passing, about the Japanese “Five Whys” technique (here’s a quick video: «Clarifying the “5 Whys” Problem-Solving Method»). The idea is simple: when you face a problem or a design choice, ask “Why?” repeatedly until you reach the root cause, the true goal — or hit a dead end. For me, it works like a scalpel, cutting through superficial answers:

«Why do we need this card?» ➔ «To deal damage» ➔ «Why is it important for the player to deal damage this way?» ➔ «So they have a tool against swarms of weak units» ➔ «And why do they need that tool?» ➔ «So a control strategy is viable, not just a cool idea»

See? At every step we discard the obvious and dig deeper. It doesn’t have to be exactly five steps; the key is not to stop at the first answer. Sometimes you have to channel that persistent child inside who keeps asking “Why?” to grasp the true nature of things.

2. User stories as a stress test.

Another practical tool: write user stories for new features (yes, another video: «Crafting Effective Agile User Stories: A Guide»). The classic Agile format is:

«As , I wan so that »

That last part is our “why,” framed from the player’s perspective.

«As a player, I want cards with a Stun effect so that I can temporarily disable key threats and create an opening for my combo»

If I can meaningfully complete the phrase after “so that” — great, the goal is clear. If I stumble and can’t explain why the player needs the hassle, that’s a red flag. This approach forces you to think from player needs and motivation, not from “the feature is cool!”

3. “Less is more,” but about meaningfulness.

Many of us love to quote principles like K.I.S.S. (Keep It Simple, Stupid) or Dieter Rams’ dictum:

«Good design is as little design as possible»

In the context of complex systems (like my card game) this can sound like a call to oversimplify. In game design, though, I’d rephrase it:

«Good game design isn’t fewer features, but more connections between them»

The point isn’t to remove everything extra; it’s to ensure that every new element (card, ability, rule) doesn’t just land in the pile but amplifies the depth of existing systems. Before adding a new card, I circle back to “Why?” — Does it create new synergy? Counter a popular strategy? Unlock an entirely new deck archetype? If yes, it’s needed. If it’s merely “another strong card” duplicating an existing function, it has no place in the game. This isn’t minimalism; it’s focused complexity with purpose.

4. “Just talk!”.

I almost skipped this point — but, ironically, was talked out of skipping it. There’s an obvious problem: sooner or later your eye becomes desensitized. A creator can fall in love with his own baby, get lost in the woods, and lose critical perspective. The question “why” is a powerful antidote, but sometimes you ask it half-heartedly, afraid of the unpleasant answer.

Two tricks help me. First, take the judgment outside (talk!). I explain my decision — and its “why” — to a colleague or friend. Even saying it aloud can expose weak spots: if I don’t believe my own explanation, that’s a signal. If the listener starts firing extra “whys,” even better — I get an express session of Five Whys from the outside.

Second, user testing (or at least feedback from friends not immersed in the project). I let them play the prototype or review the design and ask them everything as peers. If real users don’t understand why something exists, maybe it truly shouldn’t. Just remember that QA is its own science — you’ll need many additional skills there…

5. The project’s big “WHY” as a compass.

And finally, the most crucial point: beyond the “why” of a specific card, item, or mechanic (yes, whatever it is!) there’s always the overarching goal of the entire game. In the whirlwind of iterations, it’s easy to forget it. My project’s “Big WHY” at this stage looks roughly like this:

«Create a tense, cerebral yet fun competitive experience where victory depends on the player’s ability to adapt and outplay the opponent, not on grind or luck» (Still greatly simplified!)

When I keep that crystal-clear, every small decision faces a test: Does this new card support “intellectual confrontation”? Does it add too much randomness, killing strategy? This global compass mercilessly cuts away anything that doesn’t lead to the main goal. As Friedrich Nietzsche once wrote:

«He who has a why to live can bear almost any how»

Paraphrased for design: if a project (or its designer) has a compelling “why,” tackling the “how” (finding solutions and overcoming implementation hurdles) becomes far easier. Understanding the purpose of your work boosts motivation, perseverance, and flexibility — qualities that are never in excess.

Conclusion: The Game Designer and the Player

Yes, I fully realize that by saying all this I didn’t reinvent the wheel. For many experienced game designers, nothing here sounds revolutionary or even new — and that was never my goal.

My aim is much humbler: simply to remind us of a fundamental truth that, amid daily grind, deadline pressure, and the sparkle of “cool” ideas, tends to gather dust. If this text makes even one designer or developer pause for a moment and ask themselves the honest, uncomfortable question “Why?”, improving their project by even a jot — then it was all worth it.

In the end, were it not for other people’s articles, research, forums, and scattered thoughts I stumbled upon while crafting the “skeleton” of my own card system, this piece wouldn’t exist. We all stand on the shoulders of giants, and sometimes our task is merely to shine a light on ideas that deserve attention here and now.

Whenever I sit down to write, I try to bring something from outside into our world of game design — ideas from architecture, philosophy, business. Not to appear smarter, but because I believe game design, as a discipline, desperately needs fresh air, new thoughts, and open discussion of fundamental questions. This text isn’t only about card games or complex systems; it’s another invitation to dialogue. A dialogue about how we think when we create games.

Returning to the question in the title — how does Game Design decide what goes on this card? Nothing less than an answer. An answer found in an ongoing dialogue with the game itself. I never decide in a vacuum. I look at the system I’ve built and ask, “What do you need right now?” I look at the intended player experience and ask, “Which tool will make your choices more interesting?” I look at the project’s main goal and ask, “What brings us closer to it?” What appears on the map is the result of that dialogue.

The player doesn’t read my design doc. They don’t see my mind maps. But they sense falsehood with surprising accuracy — when an element exists without purpose, when a mechanic is added “just because.” It feels like an empty promise, a designer’s deceit. And every time my team and I painfully search for the answer to “why,” we’re really just trying to be honest with the player — honest in answering their unspoken question:

«Why should I spend my time on this?»

There is no greater professional bankruptcy than being caught in that lie.

And see you where the secrets are hidden → t.me/slepokNTe 👀

«Is life still a game if the dice are loaded?» • An essay on replayability in game design

Nicolaos Tsitsonis — Fri, 27 Jun 2025 13:04:56 +0000

Just a quick note: the original version of this text was written by me in Russian, and you’re currently reading its English translation. Because of that, a few phrases or ideas might s ound a bit awkward or unusual here and there. If you’re curious, you can find the Russian version here, and as always, I’ve done my best to preserve the original intent and tone.

— Enjoy the read! ;)

Reflections on chance, context, and controlled chaos.

You know, there’s an old joke about a mathematician who refuses to fly because he’s calculated the odds of a terrorist attack. His friends try to reassure him:

«Come on, the odds are practically zero!»

He replies,

«Yes, but the odds that there will be **two* bombs on board are orders of magnitude smaller. That’s why I always bring one myself!»*

Absurd as it is, that joke has always struck me as an uncanny reflection of the way we, as Game Designers, often handle randomness. We fear “bad” RNG, dread the possibility that a player might face something truly unforeseen, and so we lug around an entire arsenal of “bombs” — pity timers, smoothed drop tables, hidden chance tweaks. We try to tame chaos, to make it safe.

Before I continue, a funny aside: this text has already been through several reincarnations. It began as a much smaller fragment of another, heftier article, nearly morphed into an off-the-cuff rant, but that didn’t pan out either. Now, while squeezing these thoughts into a so-called “warm-up,” I suddenly find myself with a piece as long as my very first article. Yet I still can’t manage to pin down one central question around which to build a neat dialogue.

Even so, the urge to explore this topic — to articulate the concepts that land me in certain mental cul-de-sacs — hasn’t gone anywhere. That’s precisely why this material is, quite literally, an “essay”: you’ll find a fair amount of analysis and references to some not-so-obvious things, but also plenty of pure reflection and, perhaps, outright rhetoric.

So, fair warning: what follows may seem dense, maybe even overloaded or confusing — and that’s partly deliberate. These musings lie in the domain of specialised reading, and I understand many points might fly past or remain unclear at first, or even turn out to be wrong. But I have no wish to turn an already hefty text into a textbook that spoon-feeds every term — this isn’t a lecture. I’ll be more than happy, though, to dig into the details and debate them in the comments. If something strikes a chord or raises questions, you’re warmly invited to join the discussion there.

Now, to business. In my attempts to grasp exactly what we lose when we try to “defuse” randomness and bring chaos to heel, I keep stumbling over three fundamental pillars — three “whales” that, to my mind, hold up the entire issue. First, there’s Context — the way the player’s accumulated history of decisions shapes each subsequent event. Second, there’s Game Theory (and its close cousin, probability theory) as a tool for analysing strategic behaviour under uncertainty. And third is what I’d borrow from physicists as an Entropic Budget — a finite supply of “true” randomness every game possesses. All three pillars are inseparably tied together through the figure of the player and how he interacts with randomness, how his choices infuse the game with meaning, and how our designer “crutches” disturb that fragile balance. Let’s try turning each one over in our hands.

Context: decision density and the richness of experience

At the heart of replayability lies the idea that a game remains engaging on subsequent play-throughs. How can we achieve that? Years ago Sid Meier famously remarked:

«A game — is a series of interesting decisions»

Every decision a player makes adds a new brushstroke to the game state, creating fresh context for whatever comes next. The more of these meaningful branches appear, the richer the experience becomes: past choices reshape the current situation, and no session is ever an exact copy of the last.

Put simply, we can measure context by the density and depth of decisions. If a game keeps throwing the player into different circumstances, forcing adaptation — it provides a rich context, and therefore a reason to replay. Strategy titles and sandboxes excel at this: their abundance of possible states and outcomes ensures that two play-throughs are never identical. The player gains confidence that each new run will offer fresh impressions, because the space of potential situations is vast and every game ends unpredictably, just like the first time. That is what fuels replayability.

For clarity, let me introduce a little character of mine. Imagine our Slepok decides to bake a pie. The first time he follows the recipe to the letter — that’s his baseline behaviour, his “first play-through.” But then he bakes a second pie. If he enjoys freedom of choice (a different flour, berries instead of apples, a tweak to the baking time), each such decision creates new context. The pie may come out slightly different, perhaps better, perhaps worse, but it will be his pie, the result of his decisions. The more of these small yet meaningful choices Slepok can make, the more eager he is to experiment again and again, even though the tools (the core game mechanics) remain unchanged.

Randomness, however, is a double-edged way to create diverse context. RNG spawns unique situations, but if it dictates events too strongly it nullifies the weight of decisions. Ideally, player choices and chance complement one another: the game tosses up an unexpected scenario, and the player, drawing on experience and context, responds. That is how interesting decisions arise — the clearest, simplest example of this perfect balance is chess (and yes, within the frame of “context,” randomness is agent-driven, i.e. enacted by the players themselves). But let chaos slip its leash — and intrigue turns into frustration. This is precisely where the second pillar steps onto the stage.

Game probabilities: meddling with randomness

When we add random elements to a game, we are in fact letting chaos into the system. Game theory and its sibling, probability theory, remind us that probability distributions have an annoying habit — every so often they spit out extreme values.

For example, in purely theoretical terms a player can fail to obtain a rare drop ten times in a row even though the chance is high. The system considers that normal, while a human suspects foul play. Our brains do not get along with statistics: if a fair coin lands heads ten times straight, we start believing the coin is crazy-biased or that the next flip simply has to be tails. This well-known “gambler’s fallacy” makes us see patterns that are not there and feel cheated even when randomness is formally fair. Designers — myself included — therefore compromise. We meddle with the probabilities to tame the variance of outcomes.

Beyond distributions, game theory teaches us to analyse how players adapt their strategies in response to the situation, in our case to random elements. A player does not just passively accept good or bad luck; he shapes his behaviour around expectations, odds and potential gains, which becomes especially clear in competitive or asymmetric games. Thus, tinkering with chaos changes not only the math of drops but the very nature of the player’s choices.

Pity systems are a textbook illustration: after a set number of failures the success chance rises, or a guaranteed prize appears. Mathematically we trim the tail of the distribution — we chop off the extremely unlucky streaks. Diablo III, for instance, runs a hidden timer that gradually increases the legendary-drop chance if the player has gone too long without one. This safety net keeps RNG from drifting too far into the red: after roughly 90 minutes without a legendary the game starts tilting the odds toward the player. Designers say openly that the aim is to prevent randomness from ever becoming too negative. In effect we are doing exactly what gamblers are criticised for: after a string of losses we raise the stakes on luck, turning the illusion of a pattern into an actual rule.

That is why both theories matter here: probability explains why cold streaks occur, and game theory explains why players respond by reshaping their behaviour. For a Game Designer this is crucial, because one theory rolls the dice, while the other decides when and why to roll them.

Back to Slepok and his pie. The recipe calls for “a pinch of salt.” But what is “a pinch”? That is our randomness. Slepok may accidentally sprinkle a little too much or too little. If he oversalts several times in succession and the pie becomes inedible (an extremely negative outcome), he might get upset and stop baking. To prevent that, we — the recipe designers — can add a pity system: give him a special measuring spoon that makes it impossible to over-salt, or quietly swap his shaker for one that dispenses salt very slowly. We control the chaos of the pinch so he does not spoil the whole experience.

Pity timers are not the only “bombs against chaos.” In many single-player games randomness secretly backs the player up. XCOM, for example, is notorious for an optional hidden RNG compensator: if a soldier misses several shots in a row, the chance to hit the next one invisibly rises. The code embeds the unspoken principle “You can’t be that unlucky forever!”

Resident Evil offers a different case: resource positions are fixed, but the items themselves are dealt out randomly with a bias toward the player’s needs — the game is slightly more likely to spawn ammo when you are running low. All of this is game theory in service of UX. We meddle with randomness to balance pleasure and unpredictability.

RNG thus becomes controlled chaos: the player may flirt with risk, yet we almost never let him tumble into an abyss of bad luck. If you picture the spread of possible outcomes, our intervention compresses it. Players encounter truly awful (or absurdly good) rolls far less often — everything gravitates toward a pre-arranged experience curve. That solves the fairness issue: even the unluckiest protagonist, subjectively, will not walk away empty-handed. Yet for this predictability we pay by constricting the third pillar — the entropic budget.

Entropic budget: the limits of chaos for UX

By entropic budget I mean the notional amount of unpredictability a game can afford without shattering the user experience.

Every genre, every audience — has its own tolerance threshold for chaos. A pinch of randomness adds variety; too much — steals the player’s sense of control. Our task is to find the balance point.

Clumsy though it is, we can compare it to seasoning once again: a pinch of randomness adds flavour and makes each play-through special, but oversalting ruins the dish instantly. When we design a system, we literally allocate the entropic budget — deciding where the player may encounter the unexpected and where the experience must stay stable.

In an RPG, for instance, you might randomise loot stats but not the number of grind mobs. In a card game — shuffle the hand yet give everyone the same number of cards. We sprinkle chaos where it heightens intrigue and trim it where it wrecks the player’s plans without recourse.

If Slepok ends up with an identical pie every time thanks to our “controlled pinch of salt” and the “smart oven” that auto-adjusts the temperature, then yes, he will avoid disappointment. But he will also never learn that a touch more salt can offset the sweetness in an interesting way, or that a slightly charred crust adds zest. His entropic budget for culinary experiments will be exhausted not because he has tried everything, but because we pre-limited the range of outcomes. He will get a “safe” but perhaps less varied experience.

Intuitively, the goal is to stay in a zone where the game still challenges and surprises, yet never feels like a pure lottery. A good game always offers a solid core and clear rules, against which measured RNG creates controlled disorder. The player needs to understand the bounds of possibility: in XCOM we don’t know whether a shot will hit, but we know its percentage and damage; in Balatro we hope to assemble a flush, but can’t know exactly which suit cards will drop, though we can inspect how many of each suit remain. Such transparency sets the boundaries of the entropic budget — the player sees the range within which luck can swing.

As long as events stay within that declared range, the user experience holds. But if chaos bursts beyond those limits (say, a string of defeats with no apparent way to intervene) — the budget is spent, the player feels powerless, intrigue turns to frustration, and the game is abandoned.

Where are the dice?

So, we’ve walked the length of our three pillars — Context, Game Theory, and the Entropic Budget. What, then, do we conclude? On the one hand, we Game Designers must intervene. If we leave our Slepok completely unsupervised, he’ll botch things so badly the pie will turn into a weapon of mass destruction. After all, nobody likes to feel like a victim.

«When we choose our problems we feel empowered. When problems choose us against our will, we feel like miserable victims»
— Mark Manson, The Subtle Art of Not Giving a F#ck

Players want challenges, want surprises, but they want to opt into them voluntarily — which is exactly why we measure out this “chaos on demand” so carefully.

Yet a quiet voice in me pulls the other way: if we do decide to use randomness, even in small doses, is it really worth spending so much effort on meticulous control? The player’s decision-space is finite anyway, always bounded by our own vision, by a pre-set arsenal of mechanics and scenarios. And if we’ve already sprinkled in these spices, might we let them bloom a bit more freely?

I’m not saying we should turn a game into real life — that’s both absurd and unnecessary. Rather, I’m wondering how we might calculate that reserve of context. Can we transplant game theory, probability, equilibria, and variance onto pre-built game graphs to gauge, even roughly, how much more “chaos” a given mechanic can afford before it starts eroding context?

Pursuing such questions, I find that the “replayability ceiling” stops being an abstract notion and becomes a tangible metric — one we could not only monitor but extend through honest randomness that adds depth instead of merely sanding off edges.

Thus, at this crossroads I see no binary “control or not” dilemma (control is axiomatic) but a task: to learn to measure and dose randomness across an entire game as deliberately as we now manage economy or balance.

That is exactly what I want to discuss next: not so much the ethics of interference as the potential of chaos itself, treated as a resource we can quantify, budget, and apply consciously. I crave a clearer sense of freedom for unexplored branches, for rare stories that would feed the community. Hence I propose we move past “control / no control” toward the tougher question: How do we calculate how many unique situations a game offers, and how that reserve of “chaos energy” is spent within its genre?

Honestly, the idea of “counting chaos” and setting a “replayability cap” has been rattling in my head for years. Like many of you, I’ve abandoned games not because they were bad or I had “finished everything” in the traditional sense, but because a slow realisation crept in:

«That’s it. It can’t surprise me anymore»

Whether at the fifth hour, the tenth, or the two-hundred-and-fiftieth, once the internal counter of potential surprises hits zero, interest dies. It feels as though I’ve explored every combo, seen every “random” event, and what awaits me now is only a retread of familiar patterns, however freshly wrapped. That sense of exhaustion stems not just from the amount of content but from the quality of the randomness that was supposed to keep each run unique.

Trying to systematise that feeling led me to the notion of a provisional formula. A bid to decompose the ephemeral “wow factor” into components, to grasp what drives it and how our design choices, conscious or otherwise, drain it. This isn’t a quest for an “ideal game” with infinite replayability (though who among us hasn’t dreamed of that?) but an attempt to locate the levers that let us steward the resource more knowingly. If we can see precisely how a “tuned” RNG or a narrowed context affects the surprise reserve, perhaps we can craft games that astonish longer, deeper, and more meaningfully.

Before we dive into the formalisation attempt, one disclaimer. The next section, where I sketch this “replayability formula,” was developed with help from AI. Casting gut feelings into strict mathematical terms is no small feat. To avoid reinventing the wheel — or drowning in my own wording, which might prove still more mistaken — I used AI as a tool to structure thoughts into a formula, to hunt for suitable “calculations,” and to lend the passage below a touch of that “mathematical elegance” I may lack.

The entire concept, all variables and their relationships, stem from my own reflections. The AI merely helped package those ideas into a more formal shell. I employed it deliberately as an assistant to set boundaries and find direction. So if anything feels overly “academic-artificial,” know that it is a joint product of human intuition and machine logic — under my careful editorial eye.

A 5-minute “how-to” for the replayability formula

To keep our musings from floating off into abstraction, let’s package them in a simple mathematical model. This formula is not the last word on the subject — think of it as a sketch, a starting point for reflection and (with luck) future iterations. Its purpose is to estimate a game’s notional replayability ceiling R, factoring in both deterministic and stochastic influences on how unique each run feels.

At the core of our hybrid formula sit four key variables, each rated — for convenience — on a scale from 0 to 1 (0 = minimal presence, 1 = maximal):

C — Contextual Density. Reflects the depth and richness of meaningful decisions the player can make, and how those decisions shape subsequent game states. A high C means past choices weave a branching history full of unique situations.

Example: Chess scores extremely high — every move radically alters the board and available plans. A linear visual novel with one predetermined ending nears zero, because the player’s “decisions” (if any) create no new context for later events.

A — Player Agency. Measures how strongly the player’s own actions and skill generate unique situations and sway outcomes. A high A makes the player an active author of experience; mastery, tactics, or even random experiments lead to diverse results.

Example: Competitive titles like Dota 2 or arena shooters boast very high A, as live opponents spawn endless tactical permutations. Roguelikes such as Slay the Spire or Hades also rank high: constant build and combat choices heavily colour each run. A tightly scripted story game with little player influence scores low.

RNG — “True” Randomness. Captures the share and impact of pure, un-tamed chance inside core mechanics — how much the game relies on random outcomes for variety.

Example: A card game with a well-shuffled deck has a high RNG. A title where every event and reward is hard-scripted clocks in at zero.

I — Intervention (Control Tools). Indicates how aggressively the designer steps in to smooth RNG spikes and valleys, making the experience more predictable and less frustrating — and how many levers the player gets to observe or tweak that RNG. A high I means the system actively “helps,” suppressing extreme luck swings.

Example: Pity timers, “smart loot,” or hidden chance buffs (as in XCOM or Diablo III) push I upward. A game that leaves RNG untouched keeps I near zero.

With these variables in place, the hybrid formula for the replayability ceiling R looks like this:

R = C × A + (1 − C × A) × (RNG × (1 − I))

Let’s unpack it:

C × A — replayability driven by deterministic factors: the depth of context plus the player’s agency. The higher this product, the more unique situations players forge without raw randomness. If C × A = 1 (max context and max agency — imagine a perfect sandbox with live players), the game already sits at peak replayability through emergent play alone.
(1 − C × A) — the share of replayability not yet covered by deterministic factors. If C × A hits 1, this multiplier falls to zero, so randomness contributes nothing (logical: when players themselves supply endless variety, RNG matters less). If C × A hovers near zero — say, a very linear game — the whole replayability burden shifts to chance.
RNG × (1 − I) — the contribution of pure randomness, tempered by designer control.
- When I = 0 (no control), the formula taps the full RNG potential.
- When I = 1 (complete control), the term vanishes — “rigged” randomness adds no true unpredictability.

How it plays out (roughly):

High C and A — complex multiplayer strategies or deep sandbox RPGs: the first term dominates. RNG’s slice can be small, yet players still enjoy vast novelty.
Roguelikes — Slay the Spire, Hades: balanced mix. C and A are solid, and RNG × (1 − I) remains hefty, since random drops, foes, and layouts define the genre while control tools stay moderate.
Linear narrative games: C and A approach zero. Replayability (if any) relies on RNG × (1 − I). Should RNG be low or I high, R trends toward zero.

Again, this sketch makes no claim to scientific precision; it simply frames the slippery notion of replayability in a way that highlights which levers we, as designers, can pull.

The fun part is to try it yourself! I’ve set up a small interactive Google Sheet. All you need to do is follow the link:

🔗 Link: REPLAYABILITY CALCULATOR

Make a personal copy, then drop your own 0–10 ratings (0 = absent, 10 = max) for C, A, RNG, and I for any game you fancy. The sheet rescales the inputs to 0–1 and spits out the resulting R ceiling.

Most importantly, you can interpret R as the percentage likelihood that a player will:

finish the game
fire it up again
decide to replay the story, or
queue up “just one more round”

Compare different titles, tweak parameters, and you may spot surprising patterns. The score is still a rough approximation, of course, but I hope it nudges us to think harder about what sustains long-term interest.

Critique and common sense

Well, here it is — our attempt to measure the unmeasurable. And, to be frank, the moment the formula is born it already feels… shall we say, lifeless. Don’t get me wrong: I’m glad I managed to structure my thoughts at all. But let’s stay realistic. For all its tidy symmetry, the model comes with a laundry list of flaws. One of them, in the context of game-design-as-process, is especially glaring — but we’ll save that for last. First, the more obvious aches.

First, it is painfully linear. Games are living, breathing organisms that keep changing: patches, expansions, new seasons, shifting metas, evolving communities. Trying to squash that ocean of shifts into four static coefficients is like describing the sea with a single drop of water.

Second, scoring the coefficients themselves (C, A, RNG, I) is pure subjectivity, even when we lean on “objective” cues. Where’s the line between a moderate and a high context rating? How do you pin “player agency” to a number when it hinges on a million factors, mood and skill included? Deep down, each variable deserves its own nested formulas and subsystems. For now, the fairest R for any title would be an average of a dozen designers’ gut ratings.

Third, it almost entirely ignores the human factor. Emotion, social play, modding scenes, aesthetic pleasure, narrative immersion, personal taste, even plain fatigue — all of that sits outside the brackets. Yet those very things often decide whether someone comes back, even if every “mathematical” replayability index reads zero.

Fourth, the puzzle of pure randomness. While shaping the formula I hit a contradiction. Logic says chance without meaningful choice (that is, agency) is shallow variety and shouldn’t fuel lasting replayability. ***Yet millions keep returning to slot machines, lotteries, and the like precisely *because** of pure luck. The AI and I toyed with ways to “crop” RNG’s impact when agency is low, but every mathematical trick broke something else or opened new conceptual holes. In the end I left the simplest version, admitting: yes, unfiltered randomness can sustain replayability, even if it’s a different species from that born of deliberate decisions. Who are we to forbid the joy of watching unpredictable outcomes? It may not be the flavour of replayability we designers wish to cultivate, but it plainly exists.

Yet the flaw that, for me as someone who also makes games, outweighs all others is this: the formula — like any of its kin — is a tool of retrospective analysis. We stare at a finished product, at what has already happened, and ask “why does it work like that?” We’re judging from the end, already knowing its guts and the experience it yields.

But what about the development stage? These musings on replayability, on balancing chaos and control, bite hardest when you’re knee-deep in a prototype or a design doc, before anything is playable. How do you evaluate future “agency”? How do you predict “contextual density” when you only have two core mechanics? How do you tune “RNG control tools” when you have no idea how players will react to RNG? You could wield the formula during early iterations and milestones, but only with wild assumptions and hand-waving, which guts its practical value. We’re still checking the rear-view mirror while guessing the road ahead.

So was it all for nothing? Did we just play at mathematics and craft a pretty yet useless toy? Not quite. The act of formulating — of breaking the complex into parts — is valuable in itself. It forces us to think harder about what shapes game experience, which factors matter, and where hidden connections lurk. Even if the formula never becomes an everyday tool, it offers a shared language, a coordinate system for discussing these slippery matters.

And since the exercise has at least brought us somewhere —since we now possess an imperfect yard-stick — why not use it for illustration? Armed with the formula and a dash of designer instinct, let’s walk through a handful of landmark projects across genres. Not to deliver a final verdict on their “replayability,” but to see how the abstract variables surface in real games and what insights (or fresh questions) that sparks. Before we move to the final takeaways, then, I propose a small practical exercise.

Single-player: the art of a controlled symphony

Before she slices into individual titles, let’s pause and ask what single-player actually means in the context of randomness, context, and replayability. Solo games — especially those built around story and atmosphere — are, at heart, carefully staged performances, full-blown symphonies. Here the Game Designer acts not just as world architect but as director, leading the player along a deliberate emotional arc. The chief goal is rarely endless variety; it is the creation of one (or a few) powerful, memorable play-throughs.

In such games Context (C) comes less from procedural generation than from the interweaving of storylines, character growth, world-building, and the (often illusory yet emotionally weighty) choices the player makes along the way. Agency (A) is peculiar, too: it may be high within specific gameplay slices (combat, puzzles), yet globally submits to the narrative vector. RNG is a guest, not a host. Its job is to add a pinch of spice, to enliven the world and keep routine actions from feeling mechanical — never to wreck the main design. Intervention (I), meanwhile, usually hums at full power behind the curtain, smoothing everything into that coveted just-right experience.

The trouble, of course, is that any move to “disarm” randomness inevitably nibbles away at the entropic budget we discussed. Single-player titles often do this knowingly, preferring a guaranteed high-quality couple of runs to a potentially messy infinity.

The Witcher 3: Wild Hunt

A monumental work and a benchmark narrative RPG. The world is vast, the quests meticulously written, the characters alive. Yet let’s press our little formula against it:

Context (C) – 4 / 10

The Witcher’s world is drenched in detail, branching dialogue, quest consequences. Each major decision really does shift the state of the world and people’s attitudes. That’s strong context. Still, the overarching plot rails are quite firm; truly game-changing branches are limited.

Player Agency (A) – 4 / 10

Geralt is Geralt. You may flavour his dialogue, choose combat styles, but he remains a witcher with a set skill-tree and a moral compass. You wield agency in tactics, quest order, a handful of narrative forks, yet the game leads you down a well-paved road. You are more leading actor than true co-author.

RNG (Randomness) – 2 / 10

Where is raw, untamed randomness? Loot exists, sure, but the drop tables are tuned. Combat crits add flair, not wholesale swings against equal foes. Random encounters form set dressing, not a systemic pillar. Globally, the game is highly deterministic.

Intervention (I) – 8 / 10

Here The Witcher shines. Hidden crutches abound: loot systems (quietly massaged), dynamic difficulty tweaks (though unadvertised), scripted events masquerading as chance. All serve the epic yet non-frustrating adventure. The developers clearly refused to let “bad RNG” brick a player’s journey.

R = 0.19 (~ 19 %)

What does that tell her? The replayability of The Witcher 3 hinges first on a wish to witness alternate narrative outcomes (C × A), to replay with another build or a harsher difficulty. Pure randomness contributes almost nothing. Once you have seen the key branches, the game delivers essentially the same, exquisitely staged experience — an intentional trade-off favouring narrative quality over endless novelty.

Disco Elysium

A very different beast: dialogue-driven, skill-check-laden, and steeped in the protagonist’s inner monologue.

Context (C) – 6 / 10

The main murder plot is linear at a glance, yet every dialogue choice, thought upgrade, success or failure on a skill roll nudges the next interaction into its own contour. The world flexibly reacts to which Harry you become. Those micro-shifts matter more than they first appear.

Player Agency (A) – 6 / 10

Agency lies in deciding what kind of Harry you’ll be: communist, fascist, moralist, drunk, super-cop, amorphous… Each stance unlocks or bars dialogue, alters NPC perception, even spawns new thoughts. High narrative agency, indeed.

RNG (Randomness) – 4 / 10

Virtual dice govern every skill check, seemingly central. Yet you influence odds via clothing, thoughts, substances, prior actions. It isn’t bare RNG.

Intervention (I) – 6 / 10

The game won’t hesitate to punish failed rolls. Consequences can sting. On the other hand, you can “re-roll” some checks (after rest or new context), equip thoughts that boost stats, and certain actions are gated until the plot is ready. Chaos is allowed, but not entirely unchecked; failures often become story rather than simple dead ends.

R = 0.46 (~ 46 %)

A noticeably higher score, and it feels right. Disco Elysium invites replays to explore radically different Harry builds, dialogues, and narrative layers. Deterministic factors still weigh heavy, yet semi-controlled randomness meaningfully colours each run; botched rolls are narrative fuel, not mere bad luck.

So, what about single-player?

These two titans reveal that solo games always juggle the safety of a scripted journey against the intrigue of unpredictability (thank you, Captain Obvious!). The stronger the desire to tell a specific story and shepherd the player along it, the more we tighten, tune, and trim randomness.

That doesn’t make such games non-replayable. Their replay value more often lies in exploring alternate narrative branches or play styles, not in hoping that “pure RNG” will spin a wholly fresh tale. The entropic budget is spent sparingly, usually just enough to make the first — or second — run rich and unforgettable.

And, she repeats, this is not a flaw. It is a feature of a genre that prizes the quality of a single deep dive over a theoretically infinite, but rarely achievable, variety. Sometimes a story simply has to end.

Roguelike: chaos in the service of eternal life

If single-player titles resemble a flawlessly performed symphony, with every note in its place, roguelikes (and their lighter cousins, roguelites) are more like unbridled jazz improvisations. There is a core theme (the basic mechanics) and a set of instruments (characters, items, enemies), but the melody of each “jam session” (run) depends on the virtuosity of the performer (the player) and the random chords the universe decides to throw in. Here randomness (RNG) is not mere background noise; it is an active member of the ensemble, setting the rhythm and tossing out surprising harmonies. Context (C) may reset at the start of every set, yet it snowballs inside a single composition: every random element, every item drop, every chosen talent radically shifts the sound and direction of the improvisation. Agency (A) is the player’s ability to pick up those motifs, weave them into her solo, make bold on-the-fly decisions, and sculpt a unique piece from chaos. Intervention (I) over that RNG is usually minimal or so delicately woven into the structure that it feels more like choosing a key signature than obeying strict sheet music.

Roguelikes all but shout at the player:

«The world is unfair, full of chance, and luck will abandon you often. Get used to it and learn to survive!»

The famous motto “Losing is fun” is not bravado; it is the genre’s philosophy. Every defeat is a lesson — new knowledge about mechanics, foes, and items. Yet even in this realm of chaos there are limits: if a game devolves into a pure lottery where the player’s input means nothing, interest fades fast. The best roguelikes therefore hand the player levers to engage randomness, to manipulate or cleverly exploit it, if not outright control it. Let’s see how that plays out in two standout examples.

Hades

Supergiant’s masterpiece made the roguelike approachable to a broad audience without sacrificing depth.

Context (C) – 7 / 10

Each run starts from zero, but new weapon aspects, god boons, and story lines unlock as you progress. Within a run, context builds rapidly — which god appears first, which boon is offered, how it meshes with your weapon and prior upgrades or narrative choices — all of it creates a unique situation. Still, after enough hours the main combinations and patterns become familiar.

Player Agency (A) – 7 / 10

Zagreus handles responsively; combat demands skill. Choosing room paths, boons, and weapon upgrades are player decisions that directly affect success. You are no mere victim of RNG; you actively craft your build and tactics.

RNG – 6 / 10

Boons, rooms, enemies, Daedalus upgrades — all are heavily RNG-driven. Each escape attempt feels genuinely distinct. But—

Intervention (I) – 6 / 10

Here Hades shows its “lite” side. First, there is meta-progression (the Mirror of Night, resources for unlocks). Second, you can influence which gods appear more often via keepsakes. Third, the boon menu typically offers three choices, granting real control. Add second chances from Patroclus or healing from Eurydice, and the game never lets sheer bad luck bury you.

Calculated R ≈ 0.61 (~ 61 %)

A high score, mirroring Hades’ deserved popularity. Strong agency, sizeable yet not feral RNG, and smart control tools (plus narrative momentum) keep the game engaging for dozens — even hundreds — of hours. Still, as with any roguelite that relies on meta-progression, the entropic budget eventually drains: once you unlock everything and see most combos, the adventure ends and you log out for good.

Balatro

A card-based roguelike that rocked the indie scene with deceptive simplicity and staggering depth; poker hands are just the tip of the iceberg.

Context (C) – 8 / 10

A single Joker, a Tarot or Planet card, a shop voucher — any of these can overhaul your strategy and deck potential. Context snowballs with every ante, every new blind modifier. You continually adapt to what the game deals, striving to build a scoring “engine.”

Player Agency (A) – 8 / 10

Although draws are random, your decisions — what to buy, what to skip, which combo to play, when to risk a Tarot — matter enormously. Spotting synergies, gauging risk, and pivoting strategy at the right moment are all-important. Agency is sky-high within deck-building.

RNG – 9 / 10

Card draws, Joker rolls in the shop, some Joker effects — almost unfiltered randomness. The tension never eases because you can’t predict the next turn.

Intervention (I) – 4 / 10

Very little. Yes, you can skip blinds for cash, and certain Jokers let you tinker with the deck or shop, plus you may inspect remaining deck cards. But largely Balatro is about embracing and outplaying brutal, often “unfair” RNG. If luck deserts you, it really deserts you.

Calculated R ≈ 0.83 (~ 83 %)

Balatro’s sky-high replayability shows in practice. Nearly wild RNG, colossal synergy space, and high build-crafting agency lure players back run after run. Each game is a fresh puzzle, a new challenge. The entropic budget feels inexhaustible: the number of possible situations is astronomical, and safety nets are scarce. The game does not “protect” you — it hurls you into chaos and watches to see if you swim.

So, what about roguelikes?

Roguelikes live and breathe randomness; their entropic budget starts enormous. Yet even here we find a spectrum. Games like Hades nod to a wider audience, weaving in control elements and meta-progression. This tempers pure chaos, making long-term play more comfortable and predictable.

Titles such as Balatro rely almost wholly on raw — and often ruthless — RNG, offering near-endless replayability for those ready to accept its terms and unafraid to lose to misfortune. The trade-off flips: the less control and “help” the designer provides, the higher the potential for unique, unpredictable stories — and the longer the game can surprise. But the entry bar and the player’s resilience must rise as well. The replayability ceiling soars, yet it is not accessible to everyone.

Multiplayer: people as engines of unpredictability

If single-player is a meticulously scored symphony and the roguelike a burst of jazz improvisation, then multiplayer titles are, without doubt, a never-ending, swirling carnival. Here every participant is performer, spectator, and conductor at once. Music blares from every side, the costumes dazzle, and no one can tell which act will erupt around the next corner. The prime source of this festive chaos and boundless variety is the players themselves. A live opponent, an unpredictable ally, an entire feuding guild — they can spin stories and craft unique situations that no procedural generator could dream up.

In multiplayer, Context (C) is not only the current state of a match but the ever-shifting meta-game: player knowledge, accumulated experience, trending tactics, psychological mind-games, even the reputations of individual personalities or teams. Agency (A) hits its peak — every move, every decision, every shot or well-timed call can turn the tide not just for you but for dozens, even hundreds, of carnival-goers. RNG in its pure, algorithmic form often retreats to the background or is carefully calibrated, because the chief generator of unpredictability is the human mind. Designer Intervention (I), meanwhile, aims more at enforcing fair rules and preventing abuse than at “smoothing” the personal experience.

Developers of multiplayer titles tacitly strike a deal with their audience:

«We give you the stage, the props, and the ground rules. What kind of performance you put on is up to you. Astonish one another!»

Any randomness that grants an undeserved edge or wrecks competitive spirit usually sparks uproar. Hence in esports disciplines designers strive to minimise the die-roll’s sway over a match. Does that mean the entropic budget ceases to matter? Hardly — it is simply replenished from another source: the inexhaustible ingenuity, folly, brilliance, and unpredictability of people. Let’s examine two very different yet iconic entries in this “carnival” genre.

Counter-Strike (2 / Global Offensive / etc)

The legendary tactical shooter that has sat atop the esports Olympus for decades.

Context (C) — 9 / 10

Each map, every round’s economy, previous plays by both teams — all combine to shape a unique decision space. Maps and modes stay constant, yet the micro-context mutates from round to round.

Player Agency (A) — 9 / 10

Personal skill (aim, movement, grenade line-ups), tactical insight, communication, opponent reads — all directly affect victory. Yes, you’re bound to a role and a weapon pool, but within those limits your impact is enormous. She shaves off one point only because there’s virtually no “character play” — actions decide everything.

RNG — 1 / 10

Competitive CS chases maximal determinism. Bullet spread exists, but follows learnable patterns. Spawn points vary slightly — nothing drastic. No random events flip a round. The chief “randomness” is the enemy’s choices.

Intervention (I) — 1 / 10

Essentially none. The game sets its bounds; within them there’s no dynamic handicap. Weapon and map balance come from long tuning, not real-time adjustments. With near-zero RNG, there is little to control.

Calculated R ≈ 0.83 (≈ 83 %)

Despite minimal RNG, Counter-Strike boasts huge replayability. Its entire entropic budget flows from live player interaction. Each match is a fresh chess game where the pieces are people, complete with weaknesses, strengths, and unpredictable tactics. The formula shows that even with vanishing randomness, soaring agency and deep context sustain long-term interest.

World of Warcraft

A monumental MMORPG that has weathered many eras and still gathers millions. She admits her own hands-on time was long ago, so details may have shifted, yet the broad principles stand.

Context (C) — 8 / 10

Azeroth is vast. Your character’s story, faction, profession, guild, world events, reputation grinds, cleared dungeons and raids — all weave a dense, ever-changing context.

Player Agency (A) — 7 / 10 (heavily aspect-dependent)

During levelling or questing, agency may feel modest (often you follow set routes). But in PvP, high-end raiding, the economy, and social life, your decisions matter enormously. You might become a raid leader, a market mogul, a famed duelist, or simply the guild clown. Not every slice offers equal freedom, yet the ceiling is high.

RNG — 8 / 10

Boss loot, craft procs, rare mobs or herbs — chance is everywhere. Some legendary drops come at vanishing odds, pulling players into month-long farms.

Intervention (I) — 6 / 10

Blizzard has long tamed extremes: bad-luck protection on certain drops, tokens convertible to gear, mechanisms curbing too-rapid or too-slow progress. PvP uses rating queues. Chaos exists, but under watch to keep the economy and power curve intact.

Calculated R ≈ 0.68 (≈ 68 %)

WoW shows high replay potential. As in CS, human factors (social ties, guilds, shared hurdles) carry huge weight — our formula folds them indirectly into Context and Agency. The living world, its lore, and constant updates further contribute. Randomness is important, yet only one pillar of engagement.

So, what about multiplayer?

Multiplayer games are a special case where the entropic budget practically self-replenishes through human unpredictability. Designers often needn’t craft intricate RNG systems — providing a compelling playground and clear rules suffices; players will fill it with unique events and plot twists. The replayability ceiling can be the highest of all genres because the carnival of interaction never stops.

Yet nuances remain: if rules grow too rigid or the meta settles too fast, freshness evaporates. Thus developers keep stoking the carnival — patches, new content, events — injecting their own “controlled chaos” at the meta level. The trick is ensuring the carnival stays fair and thrilling for everyone beneath the masks.

When does the compass lose its bearing?

Our formula, as we’ve seen, copes nicely with typical representatives of each genre. Yet the gamescape is far more diverse, and some projects either break the logic outright or expose its limits. Let’s glance at a few such extremes — some real, some hypothetical — to understand where our tool begins to fray.

Outer Wilds – The formula might hand it a rather high R (≈ 41 %), which feels odd for a game you “can’t really replay.” If, however, we treat replayability as the urge to keep exploring until the finale, the number starts to make sense: the game keeps surprising you for the duration of that one, singular journey. It’s all about interpretation. Personally, I suspect this is more of a modelling error than a feature.
Dwarf Fortress / RimWorld – Here the formula cheers, spitting out an off-the-charts R (≈ 93 %), and deservedly so. Sky-high Context and Agency plus nearly feral RNG create an inexhaustible well of unique stories. These titles are living proof that well-tuned chaos breeds depth.
A linear visual novel – Fairly earns an R close to zero (≈ 3 %). Minimal Context, almost no Agency, and zero RNG leave little reason to return after one read-through. The formula nails this case.
“The perfect casino” (hypothetical) – Minimal Context and Agency, but maximum “honest” RNG with no control tools. The formula spits out R = 100 %. Absurd? Undeniably — yet, as noted earlier, that may not be a bug. Plenty of people roll the dice for the tenth, the hundredth time; addiction is powerful.
“One-button sandbox” (hypothetical) – Maximal Context, almost no Agency, zero RNG. Result: a very low R (≈ 10 %). A deep world is useless if you can’t interact with it and it never surprises you.
“Procedural forest walking sim” (hypothetical) – Endlessly, beautifully generated landscapes. High Context (every corner unique) and maximal RNG (constant generation), but minuscule Agency (you only walk and look). The formula may grant it a healthy R (≈ 10 %), yet in practice the game grows dull fast for lack of meaningful interaction — a clear mismatch.

These examples remind us that every model simplifies reality. Our formula is just one lens through which to view the thorny problem of replayability. It can be a helpful thinking tool, but it will never replace a designer’s intuition — or her sense of what truly hooks players.

Instead of a conclusion — an honest question

So here we are, at the finish line of this — let me risk the word — marathon of thought. I know perfectly well how much has been thrown on the table, how many concepts have intertwined, how many questions remain not merely unanswered but barely articulated. That, I confess, is not an accident. Had this been a classic article I would probably feel obliged to deliver neat take-aways, offer solutions, dot every “i”. Yet the point of this text — its long-suffering history of multiple iterations and ever-growing layers — is the process of searching, of asking questions of myself.

The longer she works in game design, the more a certain feeling hardens inside her, one that might be phrased — Socrates-style, but twisted for a designer’s tongue as:

«All I truly know is that I know nothing about this bottomless well we call player experience»

Not out of false modesty; rather a sober appraisal of the task’s scale. All around are people who claim they can teach you “how to make games that sell” or “how to keep players hooked,” building courses and careers on that certainty. She, by contrast, is certain only of her uncertainty. The deeper she digs, the clearer it becomes how provisional everything is — how every “success story” is a unique confluence of circumstance, talent, luck, and that unruly chaos we can never cage.

«Most revolutionary game designs are not created deliberately; they’re discovered by accident.»
— Tynan Sylvester, Designing Games

Remember the mathematician from the opening joke, the one who carried a bomb onto the plane? At first he was just a vivid symbol of our designerly fear of “bad RNG,” our urge to tame chaos. But the more I mused, the more layered that image became. He stopped being a mere metaphor for control and turned into the embodiment of conscious bias in the systems we craft.

The mathematician was not merely scared of randomness — he tried to game it, injecting his own, absurd yet deterministic, variable into the probability equation. He refused to leave matters to chance, actively shaping them according to his risk logic. He believed in his method even when it mocked common sense.

That’s when it struck me: how many such “bombs,” such deeply rooted yet dubious notions of “the right way,” do we lug around in our profession? How often do we make design choices not on data or deep player psychology but on ossified “best practices,” personal prejudices, or fear of doing things differently? Like that mathematician, we create our own local “truths,” our own “loaded dice,” and live by them.

Why, then, spill so many words and so much effort if there are no ready answers or universal fixes? Perhaps because the very act of untangling, of trying to understand, is the point. It’s my way of thinking aloud. Maybe, for some of you, this stream of consciousness — this attempt to stretch a mathematical owl over the globe of game design — will spark your own reflections. Perhaps you’ll find something that resonates, or you’ll want to argue, brandish your own “bomb,” your own formula, your own angle. Wonderful! Game design is not frozen dogma; it thrives on inquiry, dialogue, doubt, discovery.

If this text has nudged even a few of your neurons, made you ponder how the worlds we play in are built and how we, their makers, try (or refuse) to balance order and chaos, then none of it was in vain. Take it simply as an invitation to ask a timeless, slightly unsettling, yet crucial question for anyone who shapes interactive worlds:

«Is life still a game if the dice are loaded?»

See you where the secrets are hidden → t.me/slepokNTe 👀

Where does the Sisyphus stone of gamedev roll?

Nicolaos Tsitsonis — Sat, 21 Jun 2025 23:05:33 +0000

«Momentum» — is an original column from my Telegram channel. What you’re reading is an English translation of the piece I first published in Russian, so some turns of phrase may feel a little rough. Btw, it is just a way of structuring my own thoughts aloud, putting them in order and searching for a live dialogue. Enjoy the read!

You know, there’s this funny yet strikingly illustrative phenomenon called the “clean glass effect”. I’ll explain what I mean and why this seemingly everyday thing has lodged itself so firmly in my mind in the context of our beloved gamedev. This will be a bit… Encyclopaedic to start with.

Why did glass swallow the landscape?

Imagine ancient times. Houses had no double-glazed units, nor even glass in the usual sense. At best the wealthy might have oiled hides or mica in their windows, while most people had simple holes in the wall, plugged at night with whatever was at hand (if windows existed at all). Understandably, this caused a host of problems: it was dark, uncomfortable, security was mediocre, and the world beyond the wall remained one big unknown until you stepped outside.

Then, centuries later, it appeared — glass. The first experiments were, to put it mildly, far from ideal: thick, cloudy, bubbled and distorted, “fat” and unwieldy, functionally awkward panes. Through such glass you could hardly examine the street, catching only blurred silhouettes and a general sense of whether it was day or if night had already fallen. Yet even that was a breakthrough! Light could enter while weather stayed out, and there was at least some connection with the outside world.

Years, decades, centuries passed. The technology of glass-making improved: it grew thinner, clearer, more transparent. At some point we reached near-perfect clarity. Glass became… just glass — an invisible barrier. It seemed the summit had been conquered. In its fundamental purpose — letting light through and offering an unobstructed view — the technology called “glass” had exhausted itself. Nothing more could be improved in that specific aspect.

But no! Human ingenuity never stands still. Double-glazed units for thermal and acoustic insulation appeared, tempered glass, bullet-resistant glass, panes with UV filters, with heating, self-cleaning surfaces… A slew of undeniably useful upgrades — yet, fundamentally, transparency had already been achieved.

As a “window onto the world”, glass had in essence completed its evolution. From here on, it is all service functions, which will certainly continue to improve, but the core breakthrough — perfect transparency — is behind us.

The Sisyphus stone of gamedev?

Why this sprawling lecture on materials science, you may ask — especially inside a “Momentum”? Because the other day a video on TT crossed my feed. I’ll attach it ri-i-ight here:

And that short clip, that tiny spark, landed straight in the long-smoldering bonfire of thoughts in my head about graphics in games. After all, most of my dearest, most defining gaming experiences came from titles you could never call graphical masterpieces or pinnacles of realism.

Don’t get me wrong: like many of you I’m eagerly awaiting GTA 6 and savoring the promised level of detail. Yet this almost religious, unhealthy (in my view) devotion to photorealism — the race for “even more realistic arm-hair” and “even wetter asphalt” — starts to remind me of our glass story: the pane is already transparent, but we keep perfecting it ad infinitum, forgetting why we needed it in the first place.

Which is why, I think, players (and yes, developers too) periodically need a kind of slap — a sobering flick on the forehead that reminds us: beautiful, realistic graphics are often just wrapping paper. Sometimes the wrapper is masterful and enriches the experience (in my TG channel’s previous post I mused on how the cinematics in ARC Raiders can serve the intended vibe — that’s a fact, and that’s systemic experience design).

The telling brawl at the last TGA over Astro Bot’s (arguably — fight me, I’ll be happy!) well-earned win against the other games (though I personally voted for Balatro!) only cemented my sense that we’re on the second loop of that spiral where players once again demand the triumph of “graphics” and “cinema”.

But far too often that wrapper hides emptiness or, worse, tries to swap deep gameplay for a tech demo. And the funniest part? This “graphics vs gameplay” debate flares up with enviable regularity every few years, like a seasonal fever. People foam at the mouth arguing, then settle down — until the next tech leap, and off we go again. Granted, these aren’t the golden days of the PS5 and Xbox SX launches with their talk of “teraflops”.

Nevertheless, it seems this time it’s my turn to be the catalyst of a storm in a teacup within a Momentum. I’m even ready to catch a splash of backlash in the comments. Because it’s so much more interesting when your mind gets “fooled” (in the best sense!) by stylised graphics that serve atmosphere, concept, a unique visual language — rather than trying to cosplay reality.

Smaller games are more grown-up than blockbusters

Now let’s get serious: how much do we really need this chase for absolute photorealism? Especially when we possess such a powerful tool as stylisation — when graphics can be not merely “like real life” but artistic, metaphorical, able to set a mood with nothing more than a chosen palette or the shape of an object. And, more importantly, when it can be wise to leave deliberate “blank spots”, a touch of the unspoken in the visuals so that the player’s imagination can finish the picture.

Think of the games — Minecraft springs to mind, but I’d even highlight the PS1-style graphics many indie titles now use — where the visuals were, to put it mildly, schematic, yet gripping gameplay, an intriguing world and strong mechanics conjured images in your head far brighter, more vivid and, crucially, more emotional than the gleaming models in an AAA blockbuster ever could.

That elusive “fun” everyone talks about is born not from polygons per square centimetre but from the interplay of systems, from an engaging challenge, from the sense of discovery and, vitally, from interaction with the player. And that “fun” is the best artist: it will paint the most incredible vistas and the tensest scenes in your mind, even if all you see on-screen are pixel people, schematic icons, contour maps, cubes or little tokens.

Speaking of “small games” and concentrated experiences, I want to share an observation that will likely become the topic of my next, more detailed article. Over the past six to twelve months I’ve noticed I’m spending far more money and, just as important, time on smaller, often indie projects that some might call “childish” or “simple.”

Games like White Knuckle, Animal Well, COCOON, Old School Rally, Book of Travels, Keep Driving, Arco, Tiny Terry’s Turbo Trip — or even the slightly paradoxical LEGO Star Wars: The Skywalker Saga, into which I’ve somehow poured 200 hours. Yes, I realise this is pure subjectivity at times: art (games) is always about freedom of interpretation and personal taste. Moreover, I’m doing this not only and not simply for fun — but that’s another story. Still, what hooks me in these projects is the concentrated, distilled gameplay, the sharply targeted mechanics and that immersion which doesn’t demand hundreds of hours to unfold. As a rule, they state honestly:

«I’m here to entertain you for 10–20 hours, to give you a pure emotion without overloading you.»

And, you know, sometimes — as maximalist and, perhaps, a bit childishly cheeky as it may sound — I’d love to send many people into a sort of “gaming quarantine” filled with titles that offer so little graphics and so much gameplay. So that our lovely better half can step away from their gacha games for a while, and we, the lads, stop, forgive me, masturbating over every new glint on a beer bottle in a trailer. Just to remember that games are first and foremost about interactive experience, not about the quantity or quality of the rendered picture. Of course, I’m well aware: progress in simulation and graphics is unstoppable, and it will inevitably find its symbiosis in games — where else but in them should we test-drive new technologies?

A window onto a grey wall?

And here we reach, you know, a slightly philosophical crossroads I’ve been sketching out. So where exactly is this Sisyphus-“graph-maniac” stone rolling? Will it ever make it to the mountain-top, or will the chase for the perfect picture remain an eternal, exhausting and, perhaps, not always meaningful labour?

Because it isn’t only about the glass being perfectly transparent. What also matters is the landscape we see through that glass. If behind the crystal-clear visuals lurks a dull, empty, derivative or simply poorly designed game system, that transparency is worthless. It’s like owning the most advanced window only to look out on the blank wall of the house next door: top-tier tech, zero joy.

A good game can live on without good graphics, but a bad game with good graphics will always sink into oblivion. I know this thought — gameplay first, graphics second — is hackneyed to death. People have said it, say it and will keep saying it. Yet I couldn’t help voicing it through my own prism, my fresh (or, if you like, “green”) perception.

Sometimes you gaze at this industry and see how that collective Sisyphus-“graph-maniac”, with stubbornness worthy of a better cause, drags his boulder of photorealism up the peak of a technological Tower of Babel.

And there he is, seemingly almost at the goal. The tower is complete, glittering with its polygons, puddle reflections and wind-tousled hair. Our Sisyphus-architect finally steps onto the topmost balcony of his Babylonian edifice to survey the brilliant, technologically flawless world he has created — and beholds… an empty landscape.

And staring at this “achievement”, this gleaming “nothing” that consumed millions of person-hours and dollars, you can’t help asking one simple question:

That very “king of progress” for whom we have so long and diligently sewn garments of the purest polygons — is he, by any chance, naked?

See you where the secrets are hidden → t.me/slepokNTe 👀

The Design of Trust, or How a Game Designer Manipulates .

Nicolaos Tsitsonis — Sun, 11 May 2025 18:41:57 +0000

I. Preface: «Guiding the blind (or pretending to be one?)»

Do you enjoy being mistrusted? Think back to that feeling when you tackle a new, intriguing task — whether it’s assembling a complex model, solving a puzzle, or finding your way along an unfamiliar route—and someone hovers over your shoulder. They prompt every step, point out the obvious, never give you a chance to trip, to ponder, to find the solution on your own. Annoying, isn’t it? It feels as though they take you for a fool who can’t put two and two together without outside help.

Perhaps I don’t understand something about life. Maybe today’s world really does demand maximum safety and the minimization of any effort or risk. But when I look at the game industry — especially its mainstream sector — I see a trend I’d call design born of fear: fear of losing the player, fear of seeming too difficult, fear of being rated poorly for “obscurity.” And that fear breeds a monster: hyper-protection. Games that should be spaces for exploration, experimentation, and triumph become interactive manuals where every step is predetermined, every puzzle comes with an obvious answer, and any hint of autonomy is immediately stifled by a pop-up hint or a bold map marker.

Here begins my personal designer’s irony — almost a tragedy. We, the creators of games, tirelessly declare at conferences, in interviews, and in books that games are a unique form of interactive art. We speak of deep dialogue with the player, of crafting a one-of-a-kind personal experience through interaction. Then we return to our design docs and, with our own hands, strangle that very artistic potential. Exploration, interpretation, self-reflection — the very essence of interactivity and art — are sacrificed to mechanical instruction-following. We turn the player from an explorer into a courier chasing GPS markers.

Imagine a director who, before a film screening, hands every viewer a detailed synopsis explaining every metaphor and even allows the audience to ignore theater etiquette and chatter loudly throughout… It’s as if we panic that the player “won’t get it,” so we drape the interactive canvas with layers of hints, killing mystery, intrigue, and — most importantly — the thrill of personal discovery.

I’m far from suggesting that this entire “design born of fear” stems from malice or rank incompetence. Of course, market realities exist: the massive budgets of AAA projects require the widest possible audience, hence a low entry threshold. Retention metrics loom, where any player hesitation can be read as a potential churn point. Striving for “accessibility” all too often gets confused with dumbing-down the experience. All of that is understandable; I won’t argue with it.

(A good, very brief framework article on this topic and key D1/D7/D30 metrics, etc: «Retention framework: Keep your players forever»)

Yet my game-designer’s skepticism whispers: have we chosen the most straightforward, but not the most elegant path? Isn’t this obsession with player “safety” a symptom of our own insecurity — our lack of faith in the worlds we create, the elegance of our systems, the fear that without hint-crutches the player simply won’t find the “fun”?

Such an approach, in my view, doesn’t merely simplify the game — it risks devaluing the player’s agency, their capacity to think, analyze, and decide. It turns exploration from an exhilarating adventure into routine icon-clearing on a map.

Reflecting on this design born of fear, I can’t shake a thought: are we overlooking the most obvious and powerful tool? That innate force that urges a child to dismantle a toy just to see how it works; that spark that drives a scientist to new discoveries, an explorer to uncharted lands. It is the fundamental engine of cognition — a basic need of the mind — to seek novelty, fill gaps in knowledge, solve riddles. Without that internal motor, without this unquenchable ▇▇▇▇, there would be no science, no art, no progress. It is ▇▇▇▇ that makes us ask “why?” and “how?”, that turns passive observation into active pursuit. So why don’t we, designers of interactive systems, place a bolder bet on that very ▇▇▇▇?

Feel your brain trying to slot a word into those blanks? Even this simple guessing game — this tiny gap in the text — prompts you to tense up, analyze context, float hypotheses. Why? Because your brain can’t stand uncertainty. It was… curious. Exactly — curiosity. This small demonstration within a single paragraph shows how even a minimal mystery — a light stimulus to curiosity — instantly sparks our thought process, driving us to seek an answer. Isn’t a design that deliberately harnesses and rewards this innate pull toward discovery more elegant and, perhaps, more sustainable — a path to deep, meaningful engagement that arises from within rather than being imposed by external signposts?

This article is no manifesto against the AAA industry, nor a paean to “hard-core” or indie game dev. Instead, it’s my analytical dissection of an alternative approach I’ll call “Designing Trust.” It’s a cool-headed attempt, using a game designer’s toolkit, to understand a philosophy that consciously rejects hyper-protection — a philosophy that stakes everything on the player’s intelligence, observation, and tenacity; that turns ignorance, uncertainty, and the need for exploration not into barriers but into core mechanics.

To keep this discussion from remaining purely theoretical, we’ll dissect three notable specimens of this Design of Trust. We’ll peek under the hood of:

Animal Well — a labyrinthine game where self-learning is woven into the world’s fabric.
The Witness — a language-game proving that even the most complex rules can be taught without a single word.
Outer Wilds — a mechanism-game where knowledge is the only key and curiosity the fuel.

My aim isn’t to turn the industry upside-down, but to offer another lens for analysis and design — to show that trusting the player isn’t just a pretty slogan, but a working design tool capable of producing unique and truly memorable game experiences. Let’s see how it works.

II. Part 1: Animal Well — “I See No Evil” 🙈

We have postulated that curiosity is a powerful, yet often overlooked, tool in the game designer’s arsenal. It sounds elegant, almost axiomatic. But here is the snag: the moment we shift from theory to practice, from general musings to concrete analysis, we collide with a fundamental problem. Curiosity is elusive. Everyone has heard of it, everyone has felt it, but no one can point and say, “Here you go — one hundred grams of curiosity.”

This feeling is deeply subjective. What ignites a spark of interest in one player — a strange symbol on a wall, unusual enemy behavior, a hint of a hidden passage — may leave another completely indifferent or even frustrated. Curiosity is born at the intersection of design and personal experience, of a player’s knowledge and expectations. That makes it devilishly hard to dissect in a static article.

Had I the time to expand this idea in video form, I could at least show gameplay: highlight exact moments, player reactions, the subtle visual or audio cues that nudge exploration. But text and still images are something else; in this article they are largely decorative. Trying to prove the presence of “well-engineered curiosity” with a screenshot, a GIF, or prose is like explaining the taste of a dish from its photo and recipe. You can list the ingredients and the cooking method, yet the sensation itself — flavour, aroma, texture — cannot be conveyed. (For those reading my second piece in a row: yes, I adore food metaphors in game-design talk!)

So I have chosen another route. Instead of chasing the feeling itself, we will focus on the engineering-philosophical side. We will dissect game systems, level design, and item design as though a design doc lay before us. Throughout the analysis you will see notes marked “[✎]” — our anchor points.

We will explore which decisions — and, just as crucially, which developer mind-sets — create conditions in which the player’s curiosity not only becomes possible but serves as a necessary tool for progress. The pictures you encounter are meant to illustrate the concepts, not to prove curiosity. Our goal is to grasp the architecture of a design that trusts the player and bets on their inner exploratory drive. And our first “patient” on the table is Animal Well.

The Philosophy of Animal Well.

Why this title? The metroidvania market is, to put it mildly, saturated. Yet Animal Well stands out not just for its visual style or atmosphere. It landed under my analytical scalpel because of creator Billy Basso’s deliberate — almost fanatical — commitment to deep, multilayered secrecy. This is not simply a game with secrets; it is a game built around them, where probing the unknown is not an optional pastime for completionists, but the core of the experience.

Watch the documentary «The Making of Animal Well» — highly recommended — and you will see more than a seven-year solo development saga. You will witness a philosophy. From the start, Basso bet not on action or punishing platforming, but on crafting a world that actively invites players to dig deeper, question the obvious, and experiment. He did not merely feed curiosity; he stoked it long before release.

Remember the very first teaser trailer: it hid a puzzle for a community that didn’t yet exist, something Basso himself teased out. That wasn’t marketing in the usual sense. It was a proclamation:

“This game is about searching for the hidden. Start right now.”

That approach — the developer’s faith in players’ intelligence and willingness to hunt — convinced me not only to buy the game but to plunge into it with the investigative thrill I’m describing. And the documentary’s closing scene, where asks:

“Are there still secrets in this game?”

and Basso, smiling and shaking his head, replies:

“I don’t know”

Is such a cherry on top. It is the perfect embodiment of Designing Trust: a world so deep and full of mysteries that even its creator cannot be sure the community has found them all.

Some may find these contextual paragraphs over-long. Yet they are essential. To understand why certain game-design choices work, you must grasp the philosophy behind them. Similar brief excursions will precede each of our “patients.” Forgive the necessary verbosity — it serves our chief aim: a thorough, meaningful analysis.

Level 1: The Map

In most metroidvanias, the map is your faithful companion — it clearly shows the zones you have explored, the links between them, highlights points of interest, and sometimes even hints at secrets. In Animal Well the map… exists. It records the screens you have visited, yet its informational value is deliberately reduced. Connections between rooms are often unclear, transitions may be hidden, and key forks or secret passages are not marked at all. The map captures your past, but it helps almost not at all in planning the future. Why?

[✎] — ❝The goal of the map is not to guide the player, but to serve as a basic visual log of visited areas. The main burden of navigation and path-finding must rest on observing the world and building a mental model.❞

This treatment of the map is the first step in shifting the player’s focus. The game is essentially saying:

“Stop staring at the UI, look at the world around you.”

And that world is designed to reward exactly that attitude. Animal Well’s level design is highly non-linear, especially in the early stages. Unlike many metroidvanias where the way forward is dictated by the most recent upgrade, here you have access to several directions from the very beginning. There are no “wrong” paths — only different vectors of exploration. You might run into a dead end on one side, backtrack, and find an entirely different branch that leads to a key item or a new area.

[✎] — ❝The world structure should give the player multiple valid exploration routes at every stage. Dead ends and obstacles must feel not like player errors, but like temporary boundaries of current abilities or knowledge, stimulating a return and a search for alternative routes.❞

This freedom of route choice, combined with a minimally informative map, forces the player to engage a different navigation mechanism — constructing a mental map. You begin to remember not icons in the UI but visual landmarks in the world itself: a strange statue, an unusual mechanism, the wall color, distinctive enemies in a particular zone. Links between sections are often non-obvious and demand active memorization:

“Sooo ok, that bubble lift leads to the ghost area, and that dark burrow drops me by the waterfall! Aha!”

The game makes your brain work, actively process and, more importantly, structure spatial information yourself.

[✎] — ❝Connections between key zones should be logical within the world, yet not always obvious on the map. Hidden passages, one-way routes, and locations that look similar yet differ in layout push the player to memorize routes and pay close attention to environmental details.❞

Ultimately, this approach to level design and mapping achieves its primary goal: it returns the player to the game world itself. Instead of playing by the map, you start playing by the world. You study wall textures for hints of secret passages, you listen for audio cues, you remember where enemies and traps sit. The map becomes a mere rough-scale tool — a sketch of scope or a direction pointer — rather than a step-by-step instruction sheet. In that space, free of interface diktat, genuine, self-propelled curiosity blossoms. You explore not because a marker screams “GO HERE,” but because “what if I squeeze into that crevice?” or “I saw a similar spot on the other side of the map — maybe they connect?” The labyrinth of Animal Well is crafted so that getting lost is not a punishment, but an invitation to discovery.

Thus, the first layer of our dissection reveals a key principle: Animal Well deliberately weakens external navigational aids (the map) to strengthen internal ones (observation, memory, mental modelling). This shift of focus from interface to world is a fundamental condition for awakening true curiosity. When the game stops dictating your path, you start searching for it yourself — looking closer, remembering better, forming hypotheses about links and possibilities. That state of active, self-directed searching is the fertile soil where exploratory excitement thrives.

But merely making the player look around is not enough. For curiosity to stay alive, it must be rewarded. And so we move on to the second design layer — namely, the tools at our disposal within this world.

Level 2: Tools as a “Swiss Army Knife”

We have plunged into the world of Animal Well, where the environment itself is a puzzle. But how do we interact with this intricate mechanism? Once again, the game departs from convention. Instead of handing out clearly specialized keys for specific locks, it offers a set of tools that at first seem simple yet gradually reveal an astonishing multifunctionality. This is not merely quality defeating quantity — it is design built on hidden potential.

Take the very first items you receive. Whether it’s the bubble wand, the yo-yo, or the disc, none of them comes with any description. You hover over an inventory icon and see… nothing. No hint, no cue as to its use. (And yes, if you are reading this and still haven’t finished **Animal Well* — what on earth are you doing here? Seriously, this game, and indeed every title on our list, deserves a completely blind playthrough.)*

Such a choice may seem outrageous to a player accustomed to modern standards. Think of any mid-budget or even AAA metroidvania — say, Ori and the Will of the Wisps or Metroid Dread. When you receive a new ability or tool, you almost always get a concise, precise tooltip: “Press X to do Y,” “This beam destroys Z.” It is convenient, it reduces frustration, it is… safe. Animal Well chooses another path.

[✎] — ❝The functionality of a tool must emerge first and foremost through the player’s direct interaction with the world and its systems, not through text descriptions or tutorials. Encourage an experimental approach to item use.❞

Why? Because description is interpretation. I can write “apple,” and half of you will picture green, another half red, and a third the logo of a certain company. Text always leaves room for misreading. Animal Well relies on a more intuitive channel of learning — experiment. The game seems to say:

“Here’s a thing. Go try it. Whack a wall with it. Throw it in water. Use it near an enemy. See what happens!”

It turns out that the bubble wand, which at first looks like an obvious solution for creating temporary platforms over chasms, can actually do far more. And the yo-yo, which feels a bit odd on first use, is far from a harmless toy. Soon enough — through a string of experiments (and the occasional accidental button-press) — you discover that bubbles can ▇▇▇▇ certain types of obstacles, while the yo-yo lets you ▇▇▇▇▇▇ ▇▇ objects and even ▇▇▇▇▇ ▇▇▇ some denizens of the well in ways the game never hints at.

Notice the blanks again? I’m once more hiding specifics, withholding clear answers. Why? Because Animal Well does exactly the same! It doesn’t dump a list of every function for each gadget. It gives you a tool and a world full of systemic interactions, leaving you — and your indefatigable curiosity — to fill those “▇▇▇▇” with knowledge earned through your own experience.

As Tyler Sigman, creator of Darkest Dungeon, advises in his small yet influential article «Three Rules to Balance By», the trusty K.I.S.S. principle (Keep It Simple, Stupid) works in game design just as well as anywhere else: the simplicity of things in no way precludes the complexity of systems.

Every tool here is a Swiss Army knife with blades of unknown purpose that the player unfolds alone, through trial, error, and those precious “what if?!” moments of revelation.

[✎] — ❝Tools should possess multiple, system-grounded functions that can be combined with one another and with the environment, creating scenarios the designer never foresaw yet that remain perfectly logical.❞

Balance, of course, matters. Make a tool’s functions too opaque and you doom the player to frustration. Animal Well finds the sweet spot: it offers basic, graspable uses almost immediately, yet leaves a vast space for discovering deeper, context-dependent interactions. A successful experiment rewards you not with an achievement pop-up, but with new knowledge, a new way to engage with the world — a world that has just grown a little clearer and deeper.

Okay: we have a world that forces us to look and think (Level 1). We have tools of unseen potential that invite us to experiment (Level 2). We stand in this enigmatic clearing with a kit of peculiar implements. Yet the game offers no explicit goal — no princess to save, no dark lord to vanquish. So what do we do? Why keep going at all? With that, we arrive at the very heart of Animal Well, the element that turns it from a mere set of mechanics into a hypnotic experience.

Level 3: Secrets upon Secrets

The answer is simple yet complex: the game invites us to unravel mysteries. Animal Well is a gigantic box of secrets wrapped in other secrets that, in turn, conceal still more secrets. Developer Billy Basso seems to have taken the metaphor of “hiding Easter eggs” and pushed it to the absolute limit (and yes, collecting eggs is literally one of the core mechanics, but that’s not the issue right now).

But here is what matters from a game-design standpoint: in Animal Well the value often lies not in the egg itself, not in the final reward (though those can certainly be handy, rounding off the experience), but in the act of locating it. The satisfaction comes less from obtaining another collectible and more from the moment of revelation — that “Aha!” when you finally grasp how to use that odd tool in that non-obvious spot to open a passage whose existence you only suspected.

[✎] — ❝The primary reward for exploration and solving secrets should be the sense of discovery and the understanding of the world’s mechanics, not merely material or utilitarian bonuses. Curiosity can be an end in itself.❞

So how does Animal Well craft this “secrecy” without reducing it to a routine hunt for identical Easter eggs? The key is layering. Secrets here rarely boil down to a banal “break the suspicious wall.” More often they demand a combination of observation (Level 1 — you must spot something unusual in the environment: a strange pattern, a faint shimmer, an object behaving oddly), experimental tool use (Level 2 — you must guess which tool to employ, perhaps in a non-obvious way), and an understanding of systemic interactions.

Picture a scenario (as abstract as possible to avoid spoilers): you see object A. Beside it phenomenon B occurs. You possess tool C which, as you learned earlier, can influence phenomenon B, but only under condition D. The secret will unveil itself only when you correlate all these elements: notice object A, grasp its link to phenomenon B, recall the non-obvious function of tool C, and create condition D to activate it. This is no longer “finding a secret”; it is solving a systemic puzzle using accumulated knowledge of the world and its rules.

[✎] — ❝Secret design must go beyond simple hidden objects. Create systemic riddles that demand observation, logical inference, experimentation, and an understanding of the relationships among various elements of the game world.❞

Such a multilayered approach serves several crucial purposes. First, it makes the search non-linear and unpredictable. You may notice a clue long before acquiring the needed tool or insight, creating long-term mental hooks you will return to later. Second, it rewards systemic thinking and experimentation, not just attentiveness. The game encourages you to think like a researcher, a scientist forming hypotheses and testing them in practice. Third, it constantly sustains intrigue: even when you believe you have scoured an area thoroughly, there remains that nagging thought: “What if I missed something? Could this odd thing actually be the key to something bigger?”

This structure doesn’t merely add content — it changes the player’s very perception of the world. Each wall, each pixel, each sound could be part of some greater riddle.

[✎] — ❝The multilayering of secrets is meant to create resilient exploration loops. The player must be able to revisit earlier zones with new tools or knowledge and uncover previously inaccessible or unnoticed interactions, thereby rewarding long-term engagement and systemic mastery.❞

As a result, the world of Animal Well ceases to be just a collection of screens and rooms; it becomes a kind of intricate cipher where any element might turn out to be a key. This engenders in the player a special state I would call “productive paranoia.” You start to suspect everything.

“That harmless statue? What if I shine a light on it? What is that odd sound? What happens if I come back here with another item? That wall looks too smooth…”

The game doesn’t merely hide secrets; it makes you believe that secrets could be anywhere, and that only your persistence and sideways thinking will unlock them.

It is precisely this depth and complexity of secrets — secrets that demand not just finding but understanding — that turns Animal Well from a metroidvania with secrets into a true exploratory labyrinth. We have learned to look (Level 1), to experiment (Level 2), and now to connect the dots and harbor suspicions (Level 3), solving ever more intricate puzzles the game throws at us. Yet there is still a fourth layer that envelops all of this and lends it a unique, hypnotic power…

Level 4: The Aura of the Unsaid

One cannot deny a simple truth: visually appealing things draw us in more strongly. Psychologists have filled volumes on the subject — our brains are wired to reach for what is bright, new, and distinctive. But does that mean a game must explode with color like Fortnite or blind us with photorealism to spark curiosity? Animal Well proves the opposite. Its pixel art is not merely a nod to retro aesthetics — it is a deliberate choice that serves a single overriding aim: to create mystery.

Picture a pitch-black room — you see nothing, there is nothing to explore. Then picture a room flooded with bright, even light — you see everything at once, the intrigue disappears. Now imagine a space lit only by scattered pools of muted light, some corners brightly exposed, others sinking into deep shadow. (I could slip in a horror-game analogy here, but I will spare you …) That third room is Animal Well. Its restrained yet detailed visual style, with its specific palette and lighting effects, does not try to dazzle you with sheer brightness. Instead, it creates contrast, hints at what lurks in darkness, and makes you lean in, scanning pixels for anomalies.

[✎] — ❝The visual style should not simply be pretty — it must serve the primary design goal.❞

Had the game been too dark, it would oppress; too bright and cartoony, and the sense of enigma and danger would evaporate. Billy Basso found a remarkable balance: the world of Animal Well looks familiar enough not to repel, yet strange and alien enough to evoke a constant feeling:

“I am a stranger here, and I do not understand the rules of this place.”

That visual ambiguity is critical — it leaves room for the mind to wander. Our brains dislike voids and uncertainty; they strive to complete images, to supply explanations, to construct a personal narrative where the game withholds one.

The audio design completes the spell. Basso made a bold decision: Animal Well has virtually no traditional music. In its place are cavernous ambiences — hums, clicks, squeaks, the scrape of mechanisms, mysterious signals. Why? Because music dictates an emotional tone; it steers the player’s perception. Its absence instead amplifies isolation, tension, and uncertainty. You are left alone with the world, and every sound becomes potentially important — a rustle behind a wall, a distant rumble, a strange beep — any of them might be mere background or the key to a secret, or a harbinger of danger. No wonder the community spawned the theory that “the entire game is one giant piece of audio-music.” (See the video «There's Music Hidden all over Animal Well»)

[✎] — ❝Sound design — including the absence of music — must work in synergy with the visual style to reinforce the intended mood. Environmental sounds can serve not only immersion but also as non-verbal cues or integral parts of mechanics and puzzles.❞

In the end, the visual style, soundscape, and total lack of explicit story or dialogue merge into a single organism. The atmosphere of Animal Well is not mere wrapping; it is an active gameplay component continually stoking your inner curiosity. The game supplies no external goals, because within this world of enigmas and ellipses, you forge an internal goal of your own — to understand. Understand where you are, what happened here, how these strange mechanisms work, and what lies hidden in the deepest dark of the well.

(I will drop in one more concise article — «Storytelling with Interface» It outlines, in the wake of Dead Space and the boom of immersive UI/UX, what happened and what we can still learn.)

You might say that the first three levels we analyzed — map, tools, secrets — are the content of a book. But this fourth layer — the atmosphere of the unsaid — is the cover that makes you pick that book up and refuse to set it down until the final page… and then start hunting for hidden messages between the lines.

Animal Well: The Takeaway

Ok, we have dissected Animal Well across four key levels — the map, the tools, the secrets, and the atmosphere. On paper it looks like a perfect recipe for a deep, compelling experience built on trust and curiosity. Yet I can already hear a skeptical voice from the audience — perhaps even yours:

“Hold on, genius. If Animal Well is that amazing, that revolutionary in its Design of Trust, why have I barely heard of it? Why isn’t it roaring alongside the industry’s giants? Something feels off!”

And you know what? That is a fair question. If curiosity is so powerful, if ditching hyper-hand-holding produces such depth, why haven’t the big AAA studios — Ubisoft, Sony, EA, take your pick — rushed to adopt these principles wholesale? Why do we still wade through oceans of markers and pop-ups in multi-million-dollar blockbusters? Do they all somehow miss the basics of game design or player psychology?

Paradoxically, they do use these principles. Yes, you heard right. Techniques for stoking curiosity, weaving intrigue, and rewarding exploration do appear in AAA games. They are simply… different. Often they are woven into other systems, aimed at other goals (retention, monetisation), and frequently diluted by that very hyper-protection we have been discussing. But we will park that complex conversation until the article’s end, once we have more examples and context.

For the moment, let’s be honest: Animal Well is not perfect. I’d be a hypocrite to ignore the approach’s downsides and systemic risks that can alienate a lot of players.

Lack of clear objectives: The much-praised “find your own purpose” can slip into plain loss of motivation. Many players need a tangible quest or narrative runway.
Potential frustration: The line between “intriguing challenge” and “I’ve no clue what to do next” is razor thin. Animal Well walks it deftly, but a mis-step can trigger a rage-quit.
Cryptic for cryptic’s sake: Some late-game secrets are so convoluted and demand such non-obvious steps that they can feel more like arbitrary gates than elegant puzzles. The border between “brilliantly hidden” and “impossible without a guide” sometimes blurs.
Specific pacing: The game is slow-burn. It asks for thoughtfulness, backtracking, experimentation. For players craving velocity and rapid progress, that can feel dull.

I get why Animal Well (and, frankly, the other games on our list) can repel people. It demands patience, attentiveness, a zest for experimentation — qualities not everyone feels like exercising after a gruelling workday.

So, in the final analysis? Animal Well is a brilliant example of how a game can orbit the idea of trusting the player. It shows how familiar genre staples (the map), tools with hidden potential, a multilayered secret web, and a carefully tuned atmosphere can mesh to turn curiosity from a passive emotion into the active engine of gameplay.

Our deep dive into Animal Well was deliberate. The game distills many of the core tenets of Designing Trust. That means our next case studies will be slightly brisker — some concepts are now familiar.

But don’t be fooled! The journey only grows richer. Each upcoming title — The Witness and Outer Wilds — adopts these principles in utterly different ways, honing in on new facets and pushing them to wild extremes. We’ll see how a game can revolve around language without words and how knowledge itself can become the sole progression mechanic.

So, as we climb out of the well, we are not ending the conversation — merely refocusing our analytical lens. We have seen how to awaken curiosity by making players watch, experiment, and suspect. Now let’s explore how to teach them to read the world without writing a single line of text. Next stop — The Witness.

III. Part 2: The Witness — “I Hear No Evil” 🙉

We have left the dark, claustrophobic depths of Animal Well, where curiosity fed on secrets and ambiguity. Now we step onto the sun-drenched, deceptively serene island of The Witness. Here our discussion of Designing Trust shifts to a new plane — from exploring the hidden to decoding the obvious.

Let me say up-front: in place of The Witness this article could easily have spotlighted another outstanding puzzle game. The industry has given us plenty that challenge a player’s intellect — from the philosophical The Talos Principle and perspective-bending Superliminal to the meta-narrative The Stanley Parable. Each, in its own way, plays with our expectations and forces us to think outside the box.

But, first, this is my article, so allow me a bit of subjectivity in choosing our “patients.” And second — far more important to our purpose — Jonathan Blow’s game offers a pair of unique advantages that fit perfectly into the larger picture of Designing Trust we are piecing together. The Witness pushes the idea of non-verbal teaching and learning through observation to an absolute, almost frightening, perfection.

Sitting roughly midway in the article, The Witness acts as a unique bridge. If Animal Well focuses on exploring space and systems through experimentation, and Outer Wilds on gathering information and weaving narrative through knowledge, The Witness centers on the pure process of learning and understanding through observation and logic.

It takes one single core mechanic — drawing a line on a panel — and builds around it an entire visual language, a rule-set that the player must decipher without a single line of text, relying solely on intellect and keen attention to the environment. That makes it an ideal proving ground for studying how a game can teach the most complex concepts while placing full trust in the player’s capacity for self-directed learning.

Philosophy of The Witness

Again, by some “fortunate coincidence,” we are dealing with a project that spent a full seven years in development. Yes, The Witness, like Animal Well, is the product of long, painstaking work — though let me tug at the facts a bit: Animal Well is one developer, whereas The Witness was built by an entire team. Yet behind those years lies not just perseverance but Jonathan Blow’s very specific development philosophy.

Blow is known for an iterative approach in which game design evolves as the project takes shape. He does not follow a rigid blueprint; instead, he creates an “experience,” constantly checking how players interact with systems and adjusting them on the fly. I can already hear outraged producers and marketers screaming about schedules, budgets, and risk! And I agree, friends — from a business standpoint it can look like a nightmare (although, truth be told, most games go through this process; some studios are simply afraid to admit it). Yet it is precisely this exploratory method that often yields a uniqueness impossible to obtain otherwise. Each element ends up tuned not merely by a spec sheet (and yes, they definitely had those — don’t underestimate them!) but by the player’s feelings.

Blow’s main focus in The Witness is nurturing that wonderful sensation the ancient Greeks so aptly named eureka! — a spark that is usually the result of curiosity. The whole game is a carefully engineered machine for producing moments of insight. Its design deliberately follows a psychological pattern:

First, the game misleads you with apparent simplicity (“just draw a line!”).
Next, it dead-ends you by introducing a new, incomprehensible rule or a twist on an old one.
That forces you to stop, observe, rethink what you see, and form a new hypothesis.
Finally, when the hypothesis proves correct, a flash of understanding occurs — the catharsis, the very “Eureka!”.

Blow clearly asked himself: Can gameplay not merely entertain but actually teach players to pay closer attention, to look at the world from another angle, to think unconventionally? The Witness is his monumental answer. Many puzzles — especially those tied to the environment — are constructed specifically to “open the player’s eyes” to what was always in plain sight yet invisible thanks to habitual perception patterns.

And once more, by “happy accident” (or perhaps simply because such projects are fascinating), there is an excellent documentary — *«The Witness Documentary»* by Noclip — plus a wealth of lectures and analyses (someone even assembled a playlist of virtually all his talks). If Blow’s philosophy interests you, highly recommends diving in.

If one distills Blow’s puzzle-design approach to its essence, nothing does so better than his own words, quoted in Game Maker’s Toolkit’s video «How Jonathan Blow Designs a Puzzle»:

“The more that a puzzle is about something real and specific, and the less it’s about some arbitrary challenge, the more meaningful that epiphany is.”

This fundamental difference between:

“I grasp the essence / I understand” and “I finally wrangled a solution”

Will guide our further analysis of The Witness. The game does not strive for you to merely “clear” a puzzle; it strives for you to comprehend the rule beneath it. That understanding becomes the key not only to the next panel but to a deeper perception of the entire island…

Level 1. The Silent Designer

There is a landmark — though rather old — essay by Greg Costikyan from 1994 titled «I Have No Words & I Must Design». In it, while groping for the essence of game design and a language of his own (which, at the time, essentially did not exist), he throws out the thesis:

Game ≠ puzzle, toy, or story.

The context in which I am about to use that phrase is different, and Costikyan himself arrived at other conclusions, yet the sentence still sounds provocative today — especially when we look at The Witness. A game that, at first glance, can be labeled “just a puzzle.” Absurd? Not quite. In this first level of analysis I will argue that The Witness is not merely a bundle of puzzles but something more: an interactive textbook for learning a new language.

Think back to the opening moments (or imagine them if you have not played). You are in a dark tunnel. Ahead is a dead-end and — a panel. No words, no sounds (almost), no hints. There is not even a visible interface. All you can do is run a line on the panel from point A to point B. Closed conditions, the simplest task. You draw the line. A door opens. You have taken the first step in learning this world’s “language.” More panels follow. Obstacles appear in the line’s path; the panels grow more complex, yet the game remains silent. You exit and see a path that splits, leading to a bunker door. On it — a panel with unfamiliar symbols. No solution. But the path continues to a small training ground.

Here the magic of The Witness’s non-verbal teaching first shines. On the first ground is a series of panels. Some show black and white squares. Through trial and error you grasp the rule: the line must separate them. On a second ground are hexagonal dots. Another round of experimentation and a new rule emerges: the line must pass through every dot. Two fresh “words” in your visual vocabulary. You return to the bunker door. Its panel has both black/white squares and hexagonal dots. The game wordlessly invites you to combine the two rules. You trace a line, splitting the squares while collecting the dots. Click. Door open.

What happened in those first thirty minutes? You did not simply clear a couple of puzzles — you began learning a language.

The first thing that strikes a designer is the extreme minimalism of feedback. In an era when games trumpet every success with fanfares, fireworks, and pop-ups yelling “YOU ROCK!” while showering you in meaningless achievements, turning themselves into casino-style stimulus machines, The Witness chooses the path of deafening silence.

Draw the wrong line? It merely vanishes or the panel goes dark. No jarring error buzz, no penalty. Draw it correctly? The panel lights, a cable glows, perhaps a door slides aside. That is all. No praise, no score.

[✎] — ❝Feedback can be only as much as needed to inform the player of success or failure. Excessive positive feedback shifts focus from the act of reasoning to an external reward, devaluing intellectual satisfaction. Failure should signal the need to revisit a hypothesis, not punish the player.❞

This choice is critical. It keeps the player from fixating on external stimuli. The sole reward is the act of solving and the feeling of comprehension. The game does not applaud you — you must applaud yourself for understanding.

I can bet my entire Steam library that Blow has read the MDA framework (Hunicke, LeBlanc & Zubek, 2004), which is why The Witness focuses on the aesthetic of Insight — the dynamic rewards you not with push notifications but with the pure “Eureka!” sensation.

Second comes the learning process itself. The Witness is a master-class in gradual introduction and combination of rules. Every new concept — colored squares, “Tetris” shapes, symmetry, and so on — is first presented in isolation. The game gives you a sequence of simple panels featuring only that new rule. You may experiment safely until its essence clicks. Then it begins combining the fresh rule with those you already know. Complexity rises not by piling on elements, but by forcing you to apply multiple logical conditions simultaneously, demanding synthesis rather than reflex.

[✎] — ❝Introduce new rules in isolation, letting the player grasp their pure form. Later complexity should come from combining the new rule with earlier ones, pushing the player toward integrated knowledge and systemic thinking.❞

Third — and most important — is the reliance on active deduction. The whole learning loop in The Witness mirrors the cycle familiar to any scientist or researcher:

Observation: You face a panel or symbol you have never seen.
Hypothesis: Based on prior experience and context, you guess what it could mean.
Test: You draw a line according to that guess.
Result analysis: If it works — hypothesis confirmed (at least locally). If not — return to step 1 or 2, refine, and test again.

The game trusts you to run this loop unassisted. It does not hint, does not nudge (certainly not with text). It merely supplies a structured environment for experiment and inference.

Contrast this with a typical tutorial — oh, the typical tutorial will get its beating — where text sprawls across mid-screen on a countdown:

“Press X to do Y.”

There you receive instructions. Here you gain understanding. You do not merely know what to do — you comprehend why it works. That is the gulf between “I wriggled through” and “I grasp the essence.”

(For extra context on why tutorials matter, see the charming micro-video «What Games Are Like For Someone Who Doesn't Play Games» a sweet tale of a Hollow Knight newbie.)

Returning to Costikyan’s essay, he claims:

“But interaction has no value in itself. Interaction must have purpose”

In The Witness, Blow finds that purpose not in narrative, competition, or collection, but in learning itself. The aim of interaction is to decode the world’s language. Thus the game revives that pure, unclouded thrill of discovery we knew as children, when the world brimmed with mysteries and each revelation felt like a true Eureka! The Witness is not just a puzzle game — it is a simulator of learning and insight. The developer stays silent so that you can hear the voice of your own mind.

By now, the most attentive readers may have noticed … patterns. And is not talking only about seven-year dev cycles or the existence of documentaries (though that is amusing, isn’t it?). Perhaps you feel a whiff of déjà vu — that themes of observation, experimentation, and system-understanding keep circling back, as if the text is gently hammering a point home. Do not worry; it is not paranoia (not yet!). Simply keep that sensation in mind. By this article’s end, these strands will weave into a single tapestry. For now, let us continue our dive into the voiceless realm of The Witness.

We have seen how the game teaches its language. Next, we will examine how it turns the entire island into the page of that textbook.

Level 2. Architectural Design

Do you love beautiful buildings? I certainly do. There is something mesmerizing about the way an architect works with space, light, and form — guiding our movement, shaping our mood, telling a story with nothing but walls and volumes. Good level design does the very same thing: it is the architecture of virtual space. We game designers — hand-in-hand with our level-designer colleagues — build structures too, except our visitors engage with them far more actively.

Here is an intriguing fact: when developing The Witness, Blow hired real-world architects. Why? Surely not just to make the island look pretty and believable. Partly, yes — but the deeper reason ties directly into our theme of Designing Trust.

(And I never hide my sources from you, so this entire level is essentially built on the video «Architectural Approach EP.1 Gaming Architecture» and on a few fragmentary behind-the-scenes comments by Blow, such as «Architecture in The Witness - Jonathan Blow»)

Let’s think about it: architecture and environmental design in the real world manipulate us constantly. Color coding in a subway, intuitive pictograms at an airport, the placement of shops in a mall, even the width of a sidewalk — all are engineered to steer our behavior, often without our noticing. We go where we are led, we focus on what is highlighted. It is efficient; it tames chaos.

But wait … isn’t that the wrong direction for curiosity? Does a design that pre-calculates and guides every step leave room for self-discovery? (Author, are you out of your mind?) Opinions diverge here.

Path A: craft a perfectly tuned system — escalators carry you, signals tick on schedule, instructions are crystal clear. Maximum safety, minimum effort, predictable outcomes. Convenient? Undeniably. Yet where is the space for “What if I turn here?”

Path B: remember how our brains work. They are pattern-seeking machines. We see faces in clouds and on Mars [(pareidolia)](https://en.wikipedia.org/wiki/Pareidolia#:~:text=Pareidolia (%2Fˌpærɪ,meaning where there is none.); with two dots and a curve we instantly perceive a smiley. We instinctively hunt for connections, rules, meaning even where none may exist. The Witness exploits this aspect of human psychology to the fullest.

[✎] — ❝Level design should do more than enable navigation — it must act as a tool for teaching and contextualising mechanics, using principles of visual language, affordances, and natural perception patterns.❞

I believe Blow and his architects chose Path B. Recall the “desire lines” in parks — those dirt paths people carve across grass when planned walkways feel inconvenient. Users “hack” the system by following intuition. The task of a good designer — architect, game designer, level designer alike — is not to fight that impulse but to understand and harness it.

They shaped the island not just as a set of puzzle arenas but as a giant interactive environment brimming with visual cues, forced perspectives, and hidden patterns that echo the panel language. Architecture is part of the puzzle, not a backdrop. Blow’s “designing the experience as it is developed” matters because it lets him adjust those desire lines after watching how players truly interact with the world.

[✎] — ❝The game world should encourage observation beyond the immediate task. Landscape, architecture, light, shadow, and objects may hide additional layers of information or serve as contextual hints for solving puzzles.❞

That is why the simple yet potent trick of “place an enormous mountain in the island’s center” works perfectly. The mountain is not a quest marker; it is a visual anchor — visible from almost anywhere, yet the route to it is anything but obvious. Sometimes terrain exists not only for story but for mechanic.

After a brief instructional opening, the game essentially sets you free. Go wherever you wish; explore the island in any order. It trusts that your gaze will latch onto intriguing architecture, a peculiar landscape feature, or a splash of color — and that your curiosity (and your pattern-trained brain — give it some credit!) will pull you onward. The island of The Witness is no corridor lined with arrows; it is a canvas, one vast page on which the player draws and writes their own path of discovery, reading not only the panels but the world itself.

Level 3. The Engine of “Eureka”

The elegance of many things in our world lies in simplicity. What is brilliant is often surprisingly concise. Look at the best-selling, most ubiquitous objects: the BIC pen. It has one function — to write — and it performs that function perfectly, reliably, accessibly. Or sandals — footwear worn thousands of years ago and, likely, thousands of years hence. Why? Because their design is simple, functional, time-tested. Such things possess a property that Nassim Taleb frames in his book — “antifragility” — they do not merely survive chaos but can profit from it, because their core purpose stays in demand and their simplicity makes them resistant to breakage and obsolescence.

Our minds often picture the future as radically different: flying cars, food in tubes, cryogenic pods — in short, Cyberpunk 2077, only flashier and with caravan-raiding on the side. Yet if you think about it, the most antifragile thing we possess may be the mechanism of thought itself: our ability to learn, adapt, and find patterns. Yes, the world changes at break-neck speed, and our brains — the same brains our many-times-great-grandparents had — do not always keep pace with technological growth. But the fundamental principles of how we learn, solve problems, and feel the joy of discovery remain unchanged.

We are discussing game design, not the philosophy of the future — so why bring this up? Because Jonathan Blow in The Witness seems to have tapped precisely into that principle of antifragile elegance. He did not erect a labyrinth of crafting systems, skill trees, or dialogue branches. He took one, basic mechanic — drawing a line on a panel — and focused on exploring its potential.

[✎] — ❝Depth of experience can be achieved not by multiplying mechanics, but by plumbing the depths of one or two key mechanics through varied rules, contexts, and combinations.❞

In The Witness you gain no new abilities or tools (save for a rare exception that proves the rule). From start to finish you possess only the power to draw a line. What changes are the rules that govern that line — symbols, colours, shapes, interactions with the environment. The game does not complicate the action; it complicates the understanding.

That strict focus — that limitation of interaction — paradoxically becomes the chief driver of Eureka. When you hold one tool and the instructions for it keep shifting (and must be deciphered), your brain must fire on all cylinders. You cannot “pick another key”; you must grasp how the single one works.

Blow, in essence, applies Bruce Lee’s maxim:

“I fear not the man who has practiced 10 000 kicks once; I fear the man who has practiced one kick 10 000 times.”

By polishing one mechanic to a shine and examining it through countless rule lenses, he makes the act of thinking enthralling. He did not need to juggle (or code) a monstrous web of interlocking systems. A pen and paper — a line and a panel — are enough to create a profound cognitive experience. If a perpetual-motion machine exists, am convinced it runs on exactly this principle: elegant simplicity and deep interconnection among a few elements.

[✎] — ❝Effective learning design strives not merely to hand the player facts or instructions, but to teach a method of inquiry usable within the game world. The reward lies in gaining competence, not just clearing a single obstacle.❞

Here, i believe, lies The Witness’s greatest achievement. The game proves that to craft a truly gripping intellectual experience you do not need sprawling systems. You need an elegant core mechanic and a masterfully designed learning process that trusts the player’s ability to think, observe, and comprehend. The game does not give you a fish; it teaches you to fish — and that teaching becomes more exhilarating than any fish you could catch. It is pure, distilled joy of discovery, packaged as a video game.

The Witness: The Takeaway

We climbed out of the deep well of Animal Well, where trust in the player manifested as encouragement to explore and experiment with a world full of hidden potential. We then wore our own “desire lines” into the sun-drenched island of The Witness, where that same trust took the shape of silent teaching — a faith in our ability to decode a complex visual language armed with nothing but observation and logic.

We witnessed how the right kind of immersion, stripped of UI noise, and an elegant, laser-focused interaction mechanic can not merely sustain curiosity but multiply the pleasure of that sudden understanding — the pure “Eureka!” moment.

And yes, I see you nodding. If you have followed my train of thought, you have surely spotted the red threads binding these games. Many of the design “rules” or “principles” teased out while examining Animal Well apply equally here — and vice-versa. Trust in the player, minimal feedback, learning through the system rather than through text … a pattern seems to be emerging, doesn’t it? Let us leave that curtain of intrigue half-drawn; game design is wonderfully intricate, and the full picture will come later.

Yet I cannot ignore the impatient voice from the back row, the one already itching in a certain place:

“Fine, I trusted your design! I wandered around, I drew the lines — and I’m BORED! Bored, you hear? Clearing outposts in Far Cry 10 is more fun! Shooting in Call of Duty 15 is more exciting! What, am I ‘broken’ now because I don’t appreciate this high-minded stuff?”

Of course not, dear reader! You are entitled to enjoy what you enjoy, and my duty as an analyst is to admit that The Witness — for all its elegance — carries substantial downsides that can make it feel dull or frustrating (sound familiar? yes, almost the same problems as Animal Well):

Lack of clear goals — With no explicit story or extrinsic motivators, if the act of puzzling fails to grip you, the island soon feels like aimless wandering through beautiful — but empty — scenery.
Potential frustration — Certain rules or rule-combinations can be far too hard for a given player. Stalling on one panel — or an entire region — can wreck pacing and kill motivation.
Deliberate tempo — The Witness is slow and meditative. It demands concentration, patience, and a willingness to stop and think. Not ideal for five-minute sessions or background listening.
The temptation to “peek” — This is the game’s unique Achilles’ heel. When you have bashed your head against a panel for ages, the “oh for *’s sake!”* impulse to open a guide is overwhelming. The moment you do, the magic of Eureka! shatters — you gain no understanding, only a **“passing grade.”

Confession time: I have never finished *The Witness* in the traditional sense. (Throw tomatoes if you must.) I first met it through play-through videos in 2016. Later I tried to finish it myself, hit a wall, burned out, and quit. Only while preparing this article did I rebuy it, replay a chunk, and grab a few screenshots. So yes — I feel these shortcomings keenly, and I cannot deny them. As ever, we will weigh pros and cons in our final verdict.

What, then, does The Witness contribute to our study of Designing Trust? More than any other game, it shines a spotlight on the fact that the act of comprehension itself — the instant of “Eureka!” — can be a potent, self-sufficient reward. Sometimes deep satisfaction flows from nothing more than understanding.

And with that surge of intellectual triumph — with the knowledge that our brains can indeed untangle intricate systems — we set course for our next destination. We are off to my favourite cosmos, where the rules grow stranger and the cost of failure skyrockets. A place where knowledge is not merely a prize, but the only way to survive. Fasten your seatbelts: our next stop is Outer Wilds.

IV. Part 3: Outer Wilds — “And I Speak No Evil” 🙊

Hold up. Before we go any further, I’m terribly sorry for this little pre-amble, but there’s something I have to ask. A-hem … You. Yes, you personally. Have you played Outer Wilds?

Please make sure. Are you certain it was OUTER WILDS? Not OUTER WORLDS? They’re two different games! Google it. Double-check. Look at the pictures! I’ve even attached a couple of screenshots just for you — see the difference? Be honest. Swear on your gamer’s honour — keyboard, mouse, game-pad, whatever you hold sacred. Have you actually finished Outer Wilds all the way to the end?

If your answer is “Yes,” I’m delighted you’re here! Welcome to our virtual camp-fire. Grab a marshmallow, settle in — we’re about to have a heartfelt, analytical, insider conversation.

And you. Yes, you, the one who just glanced away or started fidgeting. WHAT ARE YOU LOOKING AT? You’re not allowed in here! Door’s CLOSED. ENTRY FORBIDDEN. I’m serious.

Look, I could understand if you skipped Animal Well. It’s relatively new, looks like “yet another pixel platformer” — fine, excuses accepted. And The Witness? Released back in 2016, a bunch of lines on panels — I get it, the meditative pace isn’t for everyone.

But Outer Wilds?! NO WAY. If you haven’t finished it — OUT! NOW! GO AND PLAY IT. Only after that, only then, may you read the rest of this article. I’m serious. I’m not joking in the slightest. You’ll thank me later for kicking you out.

Here’s my Telegram channel t.me/slepokNTe so you don’t get lost, can come back, and know whom to thank afterwards. Yes, hit “subscribe.” And go play the game!

No, this isn’t a marketing stunt, nor cheap reverse psychology. I’m being as honest as I’ve ever been: a blind play-through of Outer Wilds is a unique, unrepeatable experience you mustn’t spoil. Even my careful analysis will inevitably touch on things you should discover on your own. Please, trust me on this.

All good? The uninitiated are gone? Only the enlightened remain? Excellent. Let’s get started.

Before diving into the Philosophy of Outer Wilds, I have a confession. I love this game with every gram of my designer’s (and plain human) heart. Doctors are told never to operate on family because emotion clouds judgment. In theory I should exclude Outer Wilds from this analysis or hand the section to someone else … But alas, it’s just me here — and who am I kidding, no one would write it the way I can!

This is my favourite slice of today’s autopsy, which means it will hurt all the more when we get to the criticism (yes, that part is inevitable). But first — analysis.

Those of you who have finished Outer Wilds — and I’m trusting only such readers remain — already know exactly what I mean.

… Aha! Caught one more scoundrel reading without “clearance”! DON’T YOU DARE SKIP TO THE NEXT PARAGRAPH! Seriously, do yourself a favour, friend. You’ve powered through half this article already — good job! But really, invest the time in the game, it’s worth it, and then come back to us.

So — are we absolutely sure everyone here is certified? Ready to tackle the philosophy? Let’s begin.

Philosophy of Outer Wilds

Humankind, for as long as it can remember, has wrestled with the question of meaning — the meaning of its own existence, the meaning of everything that exists. Mountains of philosophical treatises, religious doctrines, and works of art are devoted to that pursuit. Honestly, almost all conscious human activity is, one way or another, an attempt to grasp that very meaning.

Schools of thought abound, each offering its own answer —or refusal to answer. Existentialism says, “Exist first, then define essence.” Stoicism teaches, “What matters is not what happened, but how you react.” Skepticism asks, “Are you sure you truly know anything at all?” And so on, infinitely. There is no single correct answer; each of us may choose a philosophy, a way of knowing the world, a personal sense of purpose.

Bias is an inseparable part of perception. We view the world through the prism of our experience, convictions, desires. Yet, amid all that diversity, we share one impulse — the very search for meaning. Everyone, sooner or later, has pondered life and death, their place in the universe. Absolute objectivity in that quest is impossible. We are human; we are different.

And — with rare exceptions suffered by those with “main-character syndrome” — none of us is the center of the universe. The ability to see from another’s point of view, to step into their shoes, is a crucial step toward wisdom.

What does any of this have to do with Outer Wilds and, by extension, with game design? Everything. The entire Mobius Digital team seems to have felt those fundamental questions keenly. They built the game on a philosophy that strips preconception from the experience as much as possible.

In Outer Wilds I am not the Chosen One, not Dragonborn, not the savior of the galaxy. I am simply a curious explorer — one of many four-eyed Hearthians who are also trying to understand the universe. I enter not a static world waiting for a hero but a living, dynamic solar system that has existed and evolved by its own laws, utterly indifferent to me.

There is no pre-written protagonist with a grand destiny. The main character is me — the person sitting at the screen right now. My motives are my motives. My curiosity is my curiosity. No one hands out quests, no one plants markers, no voice booms, “Go there, save that.” I am free to do — or not do — whatever I wish. I enter this world and remain myself.

And this is not one of those situations where “when in Rome, follow their rules or break the game.” There are no rigid dos-and-don’ts that risk angering an invisible GM. The only rules I accept — after a short, entirely optional yet delightful tutorial on Timber Hearth — are the basic laws of physics in this solar system and a working grasp of my three tools: the signal scope, the scout probe, and the Nomai text translator.

The game hands me the bare minimum knowledge required to interact, and then — total freedom. A bold period is placed on that thought by the optional dialogue choice I’m offered after grabbing the launch codes:

“Tell me, what’s your plan once you’re in space?”

The fullness of every answer lies in its own freedom. Do whatever I like, fly wherever I want, explore however I please. The world will go on living, reacting to my actions — sometimes painfully — but it will not judge or shepherd me.

Once more: the game lets me role-play myself. I don’t adopt a class or persona; I remain who I already am.

Enough philosophy for now — though we’ll come back to it often. Let’s shift gears.

Want a joke? I genuinely thought Outer Wilds had dodged the “seven-year curse.” Nope! Count from the earliest student prototypes to full release and, sure enough, it took… seven years to make. Those coincidences are getting spooky. At least, I figured, surely no documentary was shot about it! Ah — right… «The Making of Outer Wilds» by Noclip. Damn. Once is chance, twice coincidence, thrice a pattern?

Apparently, fellow developers and designers, if you want to craft a game with a Design of Trust, guarantee a documentary, and wind up lauded in my blog, brace yourselves for seven years of dev-grind. See you around… 2032!

Jokes aside, the real production takeaway is that Mobius Digital was essentially a family. Designer Alex Beachum and programmer Loan Verneau are best friends; writer Kelsey Beachum is Alex’s sister; composer Andrew Prahlow another close friend. That closeness and shared vision permeate the game. Equally important: it grew from a USC student thesis that won a local contest and later the Independent Games Festival (IGF) Grand Prize. The seed idea was strong and pure, unburdened by commercial expectations.

Most crucially, from day one to launch the team held a single core statement:

“The central idea of the game is exploration for exploration’s sake.”

And the prime driving force had to be curiosity. As they themselves phrased it, Outer Wilds was conceived as

“A game that rewards the player’s inquisitiveness.”

Now, I think the picture is coming together. Those threads we pulled from Animal Well to The Witness are weaving into a clearer pattern. If you see it — shh, keep that thought for now. We’ll yank on every last thread at the very end. If you don’t yet grasp what “threads” I’m talking about — no worries. Let’s dive into the first level of Outer Wilds analysis.

Level 1. Physics, Time, Mechanics

Physics is a curious thing. On a basic, subconscious level it feels absolutely simple and clear. We don’t need textbooks to grasp that an apple falls down, not up; shove a rock downhill — it will roll; crash one bike into another — both riders topple. We’re born into a world ruled by these laws, and our bodies, our brains, are natural physicists-experimenters. We intuitively grasp trajectories, inertia, gravity without ever seeing the formulas.

Of course, physics also loves to break our brains. Popular-science channels, books — even reality itself — keep throwing concepts like quantum entanglement or dark matter at us, reminding us how little we actually know. But the basic Newtonian mechanics that run the everyday world (and most of the cosmos in Outer Wilds) are familiar.

That’s where Mobius Digital’s first stroke of genius lies. They didn’t invent alien laws; they took the physics we know from space movies, school lessons, and documentaries, and rebuilt it inside their miniature solar system. Yes, with some simplifications and gameplay shortcuts — nobody wants to spend hours calculating orbits like in Kerbal Space Program — but the essence stands:

Your ship has inertia — accelerate and you’ll keep drifting until you brake or crash.
Every planet owns a distinct gravitational field — near-weightlessness on asteroids, crushing pull on gas giants.
Objects carry mass and momentum — they collide, bounce, fragment.
Orbital mechanics (lightweight yet present) work — you can “park” in orbit or sling-shot with gravity.

Why does this matter? Because physics is one of those things we humans love to experiment with. We itch to probe the limits.

Outer Wilds hands us a sandbox for physical experimentation. The recognisable rules, multiplied by the impossibility of such antics in real life — most of us won’t be flying to space any time soon — spark the first, most primal layer of curiosity, built on a simple “What if…?”

“What happens if I land on that comet?”
“What if I aim the ship straight into the sun?”
“And if I dive into that ominous black hole?”

The game never forbids these questions — it invites them.

[✎] — ❝Using rules the player already knows from real life or shared culture cuts cognitive load and instantly sparks experimentation based on intuition. The game needn’t explain what the player subconsciously understands.❞

In real life such stunts carry a hefty price. Here, though… wait, there is a cost: death. Nature wired us with brakes — self-preservation, fear of pain, dread of oblivion — yet she also gifted us adrenaline and imagination.

One timeless fantasy is immortality, the chance to retry without fatal consequence. Films, books, comics — the ‘Groundhog Day’ trope is everywhere.

I’ll dig into the narrative reasons for Mobius Digital’s 22-minute time loop in Level 2, but from a pure mechanics standpoint it is nothing short of brilliant.

Think of classic checkpoints or save systems. They let us retry, but they carry a big downside: they often devalue everything done after the last save. Die before the next checkpoint?

“Great, back to square one…”

Countless controllers have perished to that feeling of wasted effort. Death becomes an annoyance, a flow-breaker.

A time-loop — essentially a timer — annihilates that problem and serves two key purposes (DesignDoc’s fresh video «How Can You Spice Up A Time Limit?» covers timers nicely):

Diminish — but not erase — fear of death. You know that in twenty-two minutes (or sooner, if you really mess up) everything restarts. Death isn’t game over, just cycle reset. That knowledge frees you. It lets you take risks, attempt crazy stunts, plunge where it’s terrifying, because the worst outcome is a fresh cycle. The fear remains — no one wants to cut a great run short — but it no longer paralyzes.
Create a safe lab for experiments. Knowing the reset is inevitable turns each loop into a standalone research expedition. You have limited time to test a hypothesis, reach a location, observe a phenomenon. Progress isn’t measured in meters traveled or loot gathered but in information obtained (more on that in the next level).

[✎] — ❝To encourage bold exploration the player needs a “safe harbour” — a mechanism that lowers the cost of failure and frames setbacks as part of an iterative learning process, not terminal defeat. Give the player solid ground so they dare step into the unknown.❞

Those safe harbours extend beyond the loop itself — but we’ll return to that.

In the meantime, this is the last but critically important element, without which neither the familiar physics nor the ingenious mechanics of the loop would work so effectively. This is the scale of the world.

Be honest: did you truly enjoy wandering the procedurally generated sextillions of worlds in Starfield or No Man’s Sky? Probably not. The thrills came from handcrafted points of interest, quests, unique finds. Vast but empty space grows dull fast.

The devs of Outer Wilds knew that. Instead of chasing bigness, they built a pocket-size solar system where every cubic centimeter is meaningful and handmade. Every planet, moon, and rock is unique — its own physics, dangers, secrets.

That compact scale solves several issues:

Makes the 22-minute loop viable. Within a cycle you can reach any point, study something, maybe hop elsewhere and still feel the tension. A larger world would turn the loop into pure frustration.
Provides a seamless experience. Planet hops take minutes, not hours. No loading screens yank you out of flow. You remain inside that universe, sensing its cohesion and dynamism — a level of immersion most space games never touch.
Allows deep craftsmanship. Content isn’t smeared thin; each planet brims with multi-layered puzzles, lore details, hidden ruins, quantum oddities. You glimpse a surface yet feel there’s more — caves, ancient labs, invisible phenomena. Because the world is small, that density feels believable, not artificial — our brains, as we learned from Animal Well and The Witness, love completing a convincing illusion.

Hence another, obvious yet vital rule for exploration-centric worlds:

[✎] — ❝The scale of a game world must match the density of meaningful content and the exploration tempo set by core mechanics. “Bigger” isn’t always better. A compact, richly hand-crafted world often yields deeper immersion and more purposeful discovery than a giant, empty, or procedural one.❞

So: familiar physics ripe for experimentation; a time loop that removes paralyzing risk and sets rhythm; a tight but profound world tuned to those constraints. We’ve built the perfect playground for curiosity. Now it’s time to layer meaning atop that playground — a narrative layer that the previous games shied away from.

Level 2. Narrative and Atmosphere

Let me ask a question whose answer, after Animal Well and The Witness, seems almost obvious: why do both of those games so fiercely shy away from an explicit plot? To me the answer is simple — freedom of interpretation. Any told story unavoidably sets boundaries, funnels perception, narrows the space for personal conjecture. And if the goal is to trust the player to find meaning and forge connections on their own, a direct narrative can feel like an obstacle.

Does that mean that, in Outer Wilds — where story plays a central role — this freedom vanishes? That the game forces a single, “correct” reading of events? Absolutely not. The secret lies not in having a plot, but in how the plot is delivered.

First, the one crucial detail the developers themselves, in «Alex Beachum Designing for Curiosity in Outer Wilds», called their sole “concession” to the player: the Ship Log.

The greatest design risk — and simultaneously the stroke of genius — in Outer Wilds is the total absence of conventional progression. My character never gets stronger. My ship never gains upgrades. I unlock no new abilities. The only thing that “levels up” is my knowledge — about the system, its history, its rules. Information is the only resource that carries between loops, the only key that opens new doors.

Now, hand on heart — would you really enjoy replaying Memento’s protagonist, forced to re-assemble the universe from scratch after every death with no help at all? The team realised that a pure memory-wipe simulation would be unbearably frustrating.

Hence the Ship Log. It is more than a log; as the developers themselves admitted, the web of connections in this log (yes, that whole spider-web in the screenshot you see by the end of the game) is, in essence, a visualization of their own design document, their narrative structure. The Log auto-records every key inscription, observation, and signal and—most importantly—maps the relationships among them. It offers no answers, no “Go here next”, but serves as an external memory that helps you arrange scattered clues into a coherent picture.

That “concession” is vital: it preserves progression-through-knowledge while easing the cognitive load of remembering a galaxy’s worth of facts across cycles.

[✎] — ❝When knowledge is the main progression mechanic, the player needs a tool that organises and visualises what they have learned. It must offer no direct solutions, but act as a reliable external memory so the player can track links and grasp the big picture without excessive cognitive strain.❞

The Log never says “fly there.” It merely whispers: “You learned X, and that seems tied to Y, which was mentioned in Z.” A brilliant compromise: the unbearable burden of recollection is gone, yet the thinking remains mine.

Second narrative triumph: the tangled Nomai saga — and the mystery of the universe itself — can be approached from almost any starting point. Kelsey Beachum explains this at length in her GDC talk «Sparking Curiosity-Driven Exploration Through Narrative in “Outer Wilds”». Yes, the game drops a subtle hint at the outset: something explodes in the sky every twenty-two minutes. A fear-driven design would shout:

“Circle it in red! Add a marker! Trigger a cut-scene! Quest accepted: Strange Explosion!”

Outer Wilds trusts me instead. If I want, I can chase the explosion. Or aim for the giant water-vortex world. Or the planet crumbling into pieces. Or simply poke around Timber Hearth. There is no “wrong” path. The game says:

“Fine. Do what interests YOU now.”

Why is that so important? Why not lay down a clear storyline and push the player along a rail? Because when the player chooses his own investigative path, when he decides which mystery intrigues him right now, he stops being a mere consumer of content and becomes an active architect of his own experience. His journey turns personal.

Think of the phenomenon of games like Crusader Kings, RimWorld, or Dwarf Fortress. What hooks us is not the graphics and not a polished plot. We treasure the stories the player forges while wrestling with complex systems: “I seduced the Pope and it collapsed the realm,” or “my brilliant yet deranged dwarf accidentally flooded the fortress with magma,” or “three colonists fought off giant insects for a week, living on raider corpses.” These are personal sagas born of freedom of choice and consequence.

Outer Wilds works in a similar way, yet inside a pre-written tale. Its narrative is built so that wherever you fly you are guaranteed to find a puzzle piece — a Nomai inscription, a strange physical phenomenon, a signal — that is valuable in itself and hints at other fragments, other locations, other questions. The game does not drag you along the plot; it scatters breadcrumbs, and you decide which ones to follow.

[✎] — ❝When designing a nonlinear, exploration-driven narrative, provide multiple entry points and distribute key information so the player can advance the investigation in a relatively free order; every fragment discovered should reward the current exploration and motivate further inquiry by pointing to additional leads.❞

Coupled with the breathtaking atmosphere — created by the chosen visual style, the soundscape, the constant feeling of fragility and loneliness in space — with Andrew’s piercing melodies that will trigger flashbacks long after the credits, and even the silent camaraderie of your fellow Hearthian travellers (alas, we have no space here to dissect them), this approach lets every player walk from total ignorance to deep comprehension on his own road, collecting Eureka! moments and emotional baggage unique to him. As one saying goes:

“The important thing is not the goal, but the path toward it. Upon reaching the goal you always feel disappointment and melancholy.”

Yes, one can argue that this is partly a “bottleneck”: many roads converge on a single finale, a single answer to the central riddle.

Yet allow me one perhaps harsh thought, sure to draw criticism in an analysis like this — a thought that will carry us into the third and final level of our Outer Wilds examination:

We humans also know our ending. We all die. Does that make our lives — our journeys, our search for meaning, love, and friendship — a meaningless “bottleneck”?

Level 3. The Meaning of Curiosity?

I hope my previous question didn’t plunge you too deeply into existential brooding, because we still have a whole level to dissect — and it is precisely about that: meaning.

All those mechanics — the elegant physics, the cunning time-loop, the knowledge system, the nonlinear narrative — are undoubtedly strong in themselves. Taken together they create engaging gameplay, a gripping story, a world that invites interaction. Yet what is the fundamental reason to play Outer Wilds? Why does the complete absence of external goals (saving the world, defeating a villain, collecting 100 % of the trinkets) not merely fail to harm the game, but — as I argue — actually help it reach such emotional depth? What, from a designer’s standpoint, is the MEANING OF CURIOSITY?

It seems that after our journey through Animal Well, The Witness, and now Outer Wilds, an answer begins to emerge. It is not lodged in any single mechanic, nor solely in the story or atmosphere. It lives in what those elements awaken inside us.

After much thought, analysis of these games, and reflection on my own experience, I arrived at a formulation that, to me, captures the essence. Allow me to present it as the final designer’s note — perhaps the most important in this entire discussion:

[✎] — ❝The strength of an interactive experience is directly proportional to the intensity of curiosity it inspires: only an ever-present “what if?” pushes players to uncover new mechanics, meanings, and emotions, transforming a game from a set of rules into a living, awe-inducing world.❞

Put simply: curiosity itself *is* the meaning. At least, in games built on Designing Trust. Outer Wilds gives you no mission because the very act of seeking answers — the process of exploration driven by your curiosity — is both the primary objective and the ultimate reward. The game doesn’t ask you to save the universe; it asks you to understand it.

That is why Outer Wilds performs, in my eyes, an incredible sleight of hand: it lets you live an entire life inside the game. But not in the way RPGs do, with leveling and quest logs; it is unique in its own right. The game allows you to walk the path of understanding yourself, to confront the grand mysteries of existence, to feel awe before the unknown, and, in the end, to find your own answer to humanity’s timeless search for meaning — through the experience of exploration for exploration’s sake.

Here lies both the game’s greatest magic and its greatest tragedy for the player: this experience is unrepeatable. Outer Wilds is a game you can never truly play twice.

(Those gathered at the campfire who have finished it know exactly what I mean. And you stowaways still reading — shame on you! You are robbing yourself of one of the most singular experiences our medium can offer.)

Once you learn the secrets of this solar system, once you grasp how everything connects, the magic evaporates. You can return, tour your favourite planets, but that pristine sense of discovery, that shiver before the unknown, that euphoric revelation — it will never be the same.

Knowledge is irreversible.

Which brings us to an important thought about the nature of curiosity and the value of unique experience. You can never recapture the childlike thrill of your very first favourite game. You’ll never quite feel the full excitement of your first trip to the sea again. You cannot relive the trembling of a first love. Those moments are unique exactly because they were encounters with the unexplored, fuelled by pure, unclouded curiosity.

And that is why curiosity is eternal. It drives us to seek new, singular experiences. No matter how conservative we grow, how set in our comfortable routines, somewhere inside us lives that child who wants to peek around the corner, take a toy apart, find out “what’s over the horizon?”

Games that dare to bet on that impulse give us something far greater than entertainment. They let us feel the joy of discovery again and again.

Titles like Outer Wilds, The Witness, Animal Well speak directly to this fundamental facet of our nature. They trust our curiosity, our intellect, our capacity to craft meaning ourselves. And in that trust lies their greatest power.

It seems the time has come for me to place a gentle period at the end of this exhilarating expedition through the worlds of Designing Trust — at least, for its main arc.

Outer Wilds: The Takeaway

I promised you criticism, and I keep my word. Ladies and gentlemen around the camp-fire, it’s time to take off the rose-tinted goggles — even if they shield you from a super-nova flash. I truly love Outer Wilds, yet we have to be brutally honest: for many players this game can feel… strange. Frustrating. Boring.

I’ve recommended it to dozens of friends. A good share of them, after a couple of hours flitting through this tiny solar system, still couldn’t find the point. The time-loop annoyed them, the Nomai texts exhausted them, they missed action, clear goals, shiny rewards. In plain terms, they were BORED.

And I understand them perfectly — just as I understand why another GTA, a linear shooter like Call of Duty, or a straightforward RPG with quests and skill trees will outsell it by an order of magnitude. Designing Trust, especially in the concentrated form we see here, carries a price and some heavy drawbacks that echo all the way back to Animal Well:

High entry barrier for the incurious – if a player lacks an inner drive to explore and unravel mysteries, the game has nothing to offer. It gives no treats to those who wait for external stimuli.
Potential frustration from the loop – while the loop removes fear of death, constant restarts, especially when you’re on the verge of an insight, can be infuriating.
A lot of reading and cross-checking – gameplay largely boils down to reading Nomai inscriptions and juggling a web of facts in your head. That’s simply not for everyone.
Moments of stagnation and confusion – much like The Witness, you can stall, unsure where to fly or how to bypass a hazard/puzzle. The Log helps but won’t hand over answers.
Deliberate tempo and lack of action – the game is meditative, unhurried – despite the loop. If you crave adrenaline, you’ll find none here.

“But doc, if there are symptoms, can’t we treat them?” – you might ask. Could Outer Wilds be made more “accessible” without killing its soul? Could we strike that ideal balance between trusting the player and lending a hand?

Of course I have an answer! And here it is: Qjbknpqjwpahu, jk oejcha wjosan ateopo bkn oqyd w ykilhat iwppan, uap eb ukq ynwygaz pdwp heppha Ywaown-yeldan nezzha, E’hh chwzhu odwga ukqn dwjz kran kj iu Zeoyknz! Dana'o pda hejg: dpplo://zeoyknz.cc/WUMvdXQmGF

What can I state with certainty after dissecting Outer Wilds? That this game is the quintessence of “Designing Trust.” It proves you can construct an entire world, an entire story, an entire breathtaking experience on nothing but curiosity and knowledge. It shows how mechanics (the loop), narrative (the Nomai saga), and exploration (freedom + the Ship Log) braid together into a seamless journey where the player himself, driven by his hunger to know, becomes both hero and engine. Outer Wilds is a monument to human curiosity and to our knack for carving meaning even in the face of an inevitable end.

Yet the fact that pure Designing Trust can be hard for the mass market doesn’t mean its principles can’t – or shouldn’t – be applied wisely and sparingly in projects of any scale, AAA included. Perhaps the future of truly deep, compelling interactive experiences lies in hybrid approaches, in the careful balance between guidance and freedom, hint and mystery.

Now that we’ve finished dissecting our three prime specimens, it’s time to gather every observation and weave them into a set of overarching conclusions in the final section of this article.

V. Conclusion: “Time to See, Hear, and Speak!”

(Slepok and I genuinely thank every one of you who has read this far! He’s been standing here posing since the very beginning — just for you! 👀)

This has been a long and — I hope — captivating journey through worlds built on trust and curiosity. If you’ve reached this point, you are either a truly curious reader or a fellow designer who loves game-craft just as much as I do. In either case — bravo, and my sincere thanks for walking this road with me.

But a simple thank-you isn’t enough. You deserve the distillation, the answers that have been shimmering in the air throughout this piece. It’s time to tug every one of those red threads some of you have already spotted and feel them tighten into the full pattern that lay hidden behind our separate case studies.

(Maximum analytic & systematic mode: ON)

We began with the pain — the sad fact that many games aspiring to be “interactive art” often degenerate into interactive instruction-following, suffocating the very essence of interaction: discovery.

Then we dissected three unique specimens of Designing Trust:

We descended into Animal Well, discovering how deliberate disorientation (via a bare-bones map), opaque tools that provoke experiment, and multilayered systemic secrets can weave a hypnotic web of exploration, forcing the player to rely on memory, observation, and wit instead of on-screen markers.
We stepped onto the sunlit island of The Witness, where an entire visual language teaches the player intricate rules with not a single word. We saw that the pure act of learning can itself be an elegant, self-sufficient puzzle whose grand prize is the Eureka! of understanding.
We launched into space with Outer Wilds, witnessing knowledge become the only resource and the key to progress. A time loop, nonlinear narrative, and boundless freedom — anchored by the Ship Log — turn the game into a profoundly personal quest for answers driven solely by inner curiosity.

These titles are not random curios, nor mere flashes of lone genius (though that, too). They are living proof that a design built on trust in the player’s intellect, perception, and innate curiosity is not only possible — it is astonishingly effective at creating deep, meaningful, memorable engagement. They don’t dole out fleeting “fun” via blinking waypoints; they generate that unique, personal experience at the seam where system meets player effort — the very experience we invoke when we speak of games as art.

Throughout the analysis I jotted design principles — those margin notes helped us structure the thought. They number quite a few (by my count, exactly 22 — symbolic, no?). Each was a rung on the ladder toward broader, perhaps more elegant conclusions. Without those rungs — without the “fishing rod” we assembled piece-by-piece — the final “fish,” those principles, would be airy abstractions. Now, I hope, they feel concrete and applicable.

So, what can we — as designers — take away? What practical beacons does Designing Trust provide? Here are my “notes to self” (and to you):

Dole out information, don’t drown the player — Instead of smothering them in hints, markers, tutorials, craft a purposeful information vacuum where it makes sense. A touch of ignorance, a pinch of uncertainty, is the best spur to active exploration. When the player earns knowledge through observation and experiment, that knowledge is priceless.
Teach through systems and space, not text walls — Shape mechanics, interfaces, and environments so they themselves hint at rules, possibilities, dangers. Let the player experiment, fail safely, and deduce patterns. The thrill of “I figured it out!” dwarfs ticking off another tutorial checklist.
Braid curiosity into the core loop — Exploration and experimentation shouldn’t be “something for later” or “only for completionists.” Make them essential — or at least a vital optional path — to progress or survival. Reward not only with loot, but with information: lore insights, hidden mechanics, systemic synergies.
Ambiguity is a tool, not a flaw — Use intentional vagueness, implication, visual or mechanical ambiguity to intrigue, to hint at depth, to make the player doubt and seek alternate solutions. The craft lies in distinguishing a fine, deliberate mystery from plain sloppy design.

…

And finally — perhaps the single most important principle underpinning everything else, one that demands not only skill but a dash of courage:

…

TRUST THE PLAYER — AND TRUST YOUR DESIGN! Stop panicking that the player “will get stuck,” “won’t understand,” “will rage-quit,” or “will post a bad review.” Yes, they might stall. Yes, they might not grasp things immediately. Some frustration, moments of wandering in the dark, that specific, relatable feeling of “what on earth is going on?!” — these are not design failures; they are an integral part of the discovery process. If your world is intriguing, if your systems are elegant, if your puzzles are fair — the player will find their way. They will search, try, and think. Give them that chance. Trust their intellect and their curiosity. And, just as crucially, trust yourself and the power of your design. Don’t rush to bolt on crutches where an elegant solution can be designed.

Personal Reflection & Take-aways

Do you remember the image we began with — the director who fears the audience won’t grasp his brilliant film and therefore hands out cheat-sheets before the screening? After dissecting games that dared to remain silent, mysterious, unwelcoming (and still gathered a fiercely loyal audience!), we, as game-designers, must ask ourselves honestly: have we become those prompter-directors? Has our industry’s obsession with tutorials, markers, pop-ups, and “streamlined” player paths become a symptom of our own insecurity — insecurity in the strength of our worlds, in the player’s ability to think and explore unaided? Maybe these crutches are not for the player at all, but for us — a guarantee that someone will at least reach the end of our “presentation,” even if they never grasp its heart?

Now, a cold shower for the dreamer-designer in me. Yes, we work in an industry. Yes, games must sell. Yes, onboarding matters and retention metrics are real. Does that mean Designing Trust is the sole province of basement indies? I say — no. The problem isn’t markers or tutorials themselves, but their mindless, bloated, often lazy use. Every game is now forced to be “for everyone,” and that pressure breeds these “solutions.”

Perhaps our industry chose the easiest path to “accessibility,” not the most effective. Instead of investing in intuitive systems, readable visual language, and organic learning through play, we slap on pop-ups. Is it faster to ship? Maybe. Cheaper in the short term? Probably. But do we lose depth of engagement? Do we create an army of click-followers, players who mindlessly chase markers and drop the game the moment the external stimulus fades?

A critically thinking designer must ask: Isn’t a deeply invested player — one who uncovered the world’s secrets himself — more valuable in the long run (loyalty, word of mouth, active community) than someone we led by the hand from start to credits, who’ll forget the game a week later? We need balance. We must treat accessibility’s root causes, not just plaster them with a blizzard of hints and “forty-second-rule” pop-ups.

(And isn’t it funny? No matter how safely the industry lays rails, that drive for curiosity still breaks through! Right now everyone whispers about the enigmatic **Blue Prince* on the horizon. I haven’t touched it yet — articles don’t finish themselves! — but I feel the pull and will dive in the moment this piece is done.)*

Games are indeed a unique interactive artform. Yet interactivity dies where freedom of choice and discovery ends. Our job as designers is not only to lay rails from A to B, but to craft labyrinth-worlds, riddle-worlds, ecosystem-worlds that invite players to dig deeper and make sense of their laws.

Perhaps the highest manifestation of design mastery is not to teach the player something specific, but to rekindle that primal spark that drives him to learn and discover on his own, even after the screen goes dark. If we succeed, the player won’t merely finish our game — he will live his own story of discovery inside it. That is, I believe, the loftiest form of interactive art we can reach.

So let’s build systems that trust this fundamental human drive. Maybe in that trust lies not only the key to deeper “interactive art,” but also to steadier, longer-lasting success. And that, my friends, is a thoroughly pragmatic goal, isn’t it?

See you where the secrets are even deeper → t.me/slepokNTe 👀

— End —

"They Got It!": Why Hollywood's Bow to Games Feels So Personal.

Nicolaos Tsitsonis — Sat, 12 Apr 2025 15:05:15 +0000

I wanted to just quickly jot down a few lines, impromptu style, you know, catch a thought on the fly and get it out there. But the topic of game adaptations turned out to be trickier. You start digging, and so much surfaces: purely analytical stuff requiring a sprinkle of facts and a systemic view, and, let's be honest, quite personal, almost nostalgic things. So yeah, fair warning: this post is neither fish nor fowl, impromptu and a deep dive all at once. The lens of game design analysis inevitably gave way to a dose of emotion. But hopefully, not at the expense of the core idea.

And the core idea is that the news feed has been literally buzzing lately – and it's no longer just isolated announcements, but a whole persistent wave that's actually been building strength for years. Yes, right now the Minecraft movie is grabbing headlines with its colossal media splash, McD's collab, etc, there are rumors about a Dead Space movie entering production, and the intriguing announcement of A24 working with Kojima on Death Stranding. The upcoming second season of The Last of Us, just days away, is being discussed like it's the TV event of the decade. But this trend wasn't born yesterday, was it?

Let's think back over the last ten years, especially the last three or four: the resounding success of the Fallout series, the animated triumph of Arcane based on League of Legends, the warmly received Cyberpunk: Edgerunners which gave the game a second wind, box office hits like Sonic the Hedgehog (three times already!), Uncharted, Detective Pikachu, and the absolutely monstrous Super Mario Bros. Movie. Let's not forget The Witcher on Netflix (even if based on the books, it's strongly associated with the games) or the Mortal Kombat reboot. Phew... The list goes on and on. So, today's big announcements aren't sporadic sorties by filmmakers anymore, but a confident, systemic movement, a powerful, long-established trend.

And against this backdrop of information flow, the time machine inevitably kicks in, transporting me back... to the past. As someone whose childhood coincided precisely with the heyday of HD consoles (Xbox 360/PS3) and the online gaming boom, I vividly remember that other wave of movie adaptations, which seemed... well, a bit different. Yeah, somewhere on the periphery, there was Lara Croft with Angelina Jolie from an earlier era, catchable on TV or discs. Of course, there was Paul W.S. Anderson's seemingly unkillable Resident Evil series, which kept coming out right during my school years (parts from 2010 to 2016, roughly). But what else? I recall Prince of Persia: The Sands of Time (2010) – supposedly a big Disney blockbuster, but it fizzled out. Or the failed Need for Speed (2014), trying to play in the Fast & Furious sandbox. Or the utterly unnecessary Hitman: Agent 47 (2015). And looking back from today (and even then, if you stripped away the childish excitement of seeing familiar names), it was often utter, unbearable cringe. Cardboard characters, idiotic plot twists, a complete disregard for the atmosphere and logic of the source material.

But! And this is an important "but". For a kid who spent tens, if not hundreds, of hours in front of a computer, it was... An Event. Even if it was clumsy, even if it was ridiculous, causing more bewilderment than delight, your game was being shown in the cinema. On the big screen! It was its own kind of validation, albeit a flawed one, but an important validation for your hobby, which most adults around considered a mere pastime at best, or harmful nonsense at worst. It was like an awkward but significant nod from the "big world".

The key problem with those films, as I see it now from the perspective of someone who digs into game mechanics and narrative structures daily, wasn't just limited budgets or imperfect CGI of the time. It ran deeper – in a total misunderstanding, or perhaps even an unwillingness to understand, the source material as a medium. Games were perceived by writers and directors as a collection of iconic elements: Here's a recognizable hero in a characteristic outfit, here are a couple of signature locations, here are a few types of enemies. This kit was then mechanically assembled into a generic Hollywood action B-movie or horror flick.

It felt like nobody seriously tried to analyze and convey the essence of the gaming experience. Why TLoU isn't just "another zombie apocalypse," but a poignant story about relationships, loss, and moral choices? Why Resident Evil, at its best, is about suspense, resource management, and oppressive claustrophobia, not just action scenes? Gameplay as a narrative tool, atmosphere created by interactivity, the unique pacing and rhythm of a game – all of this was either ignored or simplified down to mere set dressing.

So, what changed? Why does the current wave of adaptations evoke completely different feelings and expectations – not just among hardcore gamers, but also among a wider audience who previously hadn't even heard of cordyceps or necromorphs?

Games Grew Up. Obvious, but true. Modern AAA projects are often incredibly complex, multimillion-dollar productions with meticulously crafted worlds, non-linear plots worthy of good literature, characters you empathize with, and incredibly cinematic direction. They themselves have become closer to cinema in terms of ambition, narrative, and visual culture. Adapting such material to the screen no longer means "making up a plot from three lines in the manual." The source material itself is rich and self-sufficient.
Generations Changed. And the audience matured. In the director's chairs, among the screenwriters, and, more importantly, in the audience, there are now far more people for whom video games aren't exotic, but an integral part of their cultural background. They grew up on these games, they understand their language, value them, and consequently, demand more respectful treatment. Neil Druckmann, the showrunner for the TLoU series, isn't an outsider but the creator of the original. As a game director, he instinctively knows how to preserve the story's DNA, its tone, and key themes, even when adapting it for a completely different medium with its own rules and limitations.
Money and IP Power. The entertainment industry has finally realized (better late than never) that popular game franchises aren't just niche entertainment for geeks, but immensely powerful intellectual properties with huge, loyal audiences and, accordingly, colossal commercial potential. Investing large budgets in game adaptations, attracting top actors and directors, has become not just possible, but strategically advantageous. The risks are lower, the potential returns – enormous.

And here we arrive at the most interesting, almost personal point for me. From the perspective of someone who chose game design as their path, I always acutely felt this, let's say, one-sided attraction of our industry towards cinema. There was a persistent feeling that we were talented, ambitious, but still the younger siblings. We looked up to cinema, learned from it. Many iconic game designers – from Hideo Kojima with his cinephile tendencies to Neil Druckmann structuring narratives like the best dramas – didn't hide their admiration for the silver screen (silent and otherwise). They borrowed directing techniques, narrative structures, even the language of the frame. We, as an industry, strived for that standard for a long time, aiming to prove that we too could tell stories, evoke emotions, be art. Analyzing this process, one could even say that game design largely went through an apprenticeship under cinema in terms of storytelling and visual direction.

(And here, if this weren't just a ramble, I'd say that often people's favorite games aren't AAA projects but indie ones, and that games are an interactive art form, and imitating films isn't the best practice, blah blah blah, but I won't! Until next time :))

And now... Now something amazing is happening. It seems the pendulum hasn't just swung – it's flown back with unexpected force. The film industry, the very one we looked up to, seems to have finally seen something more in games than just a cash cow with a ready-made fanbase or a set of assets for an action flick (although that aspect, naturally, hasn't disappeared). There's recognition happening/has happened. Recognition of games as an independent, mature media form capable of generating complex, unique universes, deep characters, and, most importantly, a unique interactive experience that can't simply be copied, but whose spirit can be respectfully interpreted and translated to the screen.

And this is no longer that condescending pat on the back felt during the era of those old adaptations.

"Oh look, we'll make a little movie based on your colorful shooter, the kids will be happy!"

Now it feels more like a dialogue, a search for common ground, a mutual interest between major studios and talented creators. And this feeling... It resonates with something deep inside.

I remember myself – that kid watching clunky special effects and a ridiculous plot in a movie based on his favorite game, eyes shining. Adults around often didn't understand, shrugging: "What's so special about those games of yours?". But for me, for us, it was a whole world. A world that existed mainly in our heads and on old monitor screens, a world full of stories, challenges, and discoveries, which seemed like something frivolous, an almost secret hobby, incomprehensible to the "big" world.

And now you read announcements like Death Stranding from A24 (a studio known for its auteur approach!), see the colossal hype around Minecraft, the triumphant success of The Last of Us series, made with love for the source material – and you catch yourself thinking: That very world, once misunderstood and sometimes even scorned, has grown up. It broke free from the confines of monitors, wrapped itself around modern culture, became an integral part of it. And we... We who grew up alongside it, we grew up too. And that childish, naive, yet so sincere and unwavering feeling that "Games – they're important, they're serious, THEY'RE COOL!", suddenly turned out to be true. A truth that everyone now acknowledges.

And you know, that kid from my childhood, the one who avidly watched even the most disastrous adaptations just to see familiar characters on the big screen... He'd be standing next to me now, looking at all this with silent, almost reverent awe and probably nudge me, saying:

"See? I told you! They got it!"

That feeling, when your faith, your passion, what was your personal, almost intimate world, finally receives the deserved recognition and respect at the highest level... It's... a very powerful and very warm feeling. Like you've been vindicated. Vindicated for all those hours spent in fictional universes, for that belief in their significance. And those universes are now coming alive on the big screens, and doing so with the dignity they always deserved.

It's incredibly inspiring. Inspiring to move forward, here, in gamedev, to create our own worlds, tell our own stories, knowing they are no longer confined to the box of "just games." They are part of the larger cultural conversation. And this is, perhaps, the best time to be part of this industry.

P.S. Yeah, not exactly a typical post for the blog, for the format. Less analysis, more reflection. But I didn't want to lose this thought — it's also part of my perspective on the industry that's taking shape here.

There is more secrets ⇢ t.me/slepokNTe 🕵️‍♂️

Why is everyone but Game Designers writing about games?

Nicolaos Tsitsonis — Sat, 29 Mar 2025 14:16:48 +0000

Just yesterday, I finished reading «Games. The Key to Their Meaning»” by «Friedrich Georg Jünger» (quick note: this particular book hasn't yet been translated into English, but since I'm fluent in Russian, I managed to read the Russian translation, which is readily available), and found myself wondering: Why do older essays, articles, and books on game design (or related topics) — like «Homo Ludens» by Johan Huizinga — seem deeper to me than many modern bestsellers?

These works were written long before the emergence of the video game industry as we know it, yet they provide an astonishingly clear framework for understanding what a game is and why it’s needed. After reading these, let’s call them “old-timers”, I found a certain foundational structure forming in my mind. Not a set of ready-made frameworks, but an overall grasp of the nature of play, the right questions to ask, a theoretical basis one can rely on.

Huizinga, for example, claims that «Play is older than culture», reasoning that animals played long before humans appeared. He shows how play underlies our society, our thinking, and human psychology. Jünger went even further, arguing, quote:

“Play is the only truly natural phenomenon in the world.”

These powerful ideas force you to look at games on a broader scale, to see their “skeleton” — the fundamental principles and the meaning of play. Reading these books, I could literally feel and understand how a structure was forming in my head: why people play, what games mean to humans, and what role a Game Designer plays in this grand context.

What Do Modern Authors Write About?

For contrast, I picked up a couple of modern books on game design — and it felt like stepping into a completely different genre. Instead of discussing the essence of a game, I was met with chapters on entirely different matters:

Management: How to organize a team, development methodologies, Agile, etc.
Producing: How to stay on budget, communicate with publishers, plan sprints.
Marketing and monetization: Retention, funnels, KPIs, and how to squeeze the maximum LTV out of a user.

Are these topics useful? Absolutely. But they have very little to do with actually understanding the game. In some of these books, you might not even see a definition of “game” or an analysis of game mechanics until halfway through — and the authors go straight into practical production issues. You read and catch yourself thinking:

“Where’s the actual game design?”

It’s worse if you never even ask yourself that question and just absorb the material… Many pages are spent on the obvious — stretched-out examples that never form a coherent picture. In the end, after reading a modern book, I’m often left with a slew of scattered tips, but no feeling that I’ve actually gotten closer to knowing how to make games.

I’m not saying that modern game design books are all bad. Some ofc are excellent. But they’re few and hard to find. Meanwhile, fundamental works like Huizinga’s or Jünger’s are considered “outdated,” and because of that, we lose sight of what might have been the best starting point.

What to Do?

I’m by no means calling for “digging up the past” or going back to the design of the NES era (or even earlier). Modern games, mechanics, and technology are our future, and we MUST work with those. My rant is purely about literature, about how and what it teaches future (and current) Game Designers. If at some point you want to feel solid ground under your feet, consider picking up:

«Homo Ludens» — The Bible for those who want to grasp games as a cultural phenomenon.
«Games. The Key to Their Meaning» — A look at games as a way of confronting absurdity. (Note: since already have say this book hasn’t been translated into English, but a good alternative might be «Man, Play, and Games» by Roger Caillois, which explores similar themes and is available in English. Otherwise, consider using AI translation tools to access the original.)
Essays by Sid Meier — Yes, he’s alive, but his ’90s writings are more candid than 90% of modern books.

And only after that dive into “F2P Monetization for Dummies.” Because without understanding why people play, all those “how-to”s are just technique for technique’s sake.

Why is this an issue? Well, I think the problem lies in the blurred role of the Game Designer today. From the very start, Game Design formed, so to speak, “by force.” The first Game Designers were developers, artists, marketers, managers — the very people who built the industry literally from scratch. As a result, today we expect a Game Designer to manage teams, calculate metrics, and think in terms of marketing.

All of that is obviously important — otherwise, how would you deliver a working game? But in this multitasking, universal profession, we seem to have lost the architect — the person who designs the fundamental framework of the game and is responsible for its meaning and structure. Consequently, modern texts break game design into pieces and forget the main thing — the game itself. That doesn’t mean new knowledge is useless; it just often “circles around” rather than hitting the core.

My call to action:

Read books that go beyond “Game Design.” Dive into philosophy, psychology, and cultural studies. Understanding a game is born at the intersection of disciplines, not in the confines of a single textbook.
Don’t confuse game design with game dev. Coding a mechanic is one thing; understanding why it’s needed and what meaning it conveys to the player is another. Keep that difference in mind.
Choose books written by real authors, not copy-pasters. If a book is simply regurgitating trends — drop it. Don’t confuse the cause and the effect; always look for the reason behind things.

Conclusion: Is a Crisis a Good Thing?

Yes. Because a crisis means we’re reworking the old and preparing for something new. Modern literature on game design, just like the industry, can’t yet provide a unified picture. It’s either bogged down in disjointed areas from marketing to management or repeats the obvious. But that’s only temporary.

What’s strange is that almost no one mentions this. Hardly anyone tries to pinpoint the issue at the core of the Game Designer’s profession. Everyone is busy discussing trends, new engines, soft skills… and the foundation is somehow overlooked.

If you’ve read this to the end — go buy “Homo Ludens.” It’s not the easiest read, but after it, I’m sure you’ll start seeing games differently. And yes, if you want to talk about books I might have missed —leave a comment. Maybe together we’ll compile an interesting “must-read” list!

There is more secrets ⇢ t.me/slepokNTe 🕵️‍♂️

Game Design Cannibals: Who’s Eating AAA Games and Why?

Nicolaos Tsitsonis — Sat, 15 Mar 2025 18:09:26 +0000

I. Preface: “The Sweet Heart of a Game: The Story of One Phrase”

The idea for this article came to me long ago from a phrase that, at first glance, seemed ordinary. I heard it at a conference a few years back from a mobile game developer — someone who clearly knew his craft. He was talking about how to create new projects. During the Q&A session, someone in the audience asked:

“How do you come up with an idea for a mobile game?”

The answer was so simple that I didn’t immediately grasp its depth:

“Take a AAA project, remove all the unnecessary stuff, and leave only the sweetest part — the bit that makes people play again and again.”

Those words stuck with me. They felt both brilliant and scary. Brilliant, because there’s a logic you can’t deny: successful mobile games often revolve around simplified versions of mechanics from big projects, which is how half the mobile market works. Scary, because it revealed a dark side of the industry — one where creativity loses some of its importance and dissolves in the act of deconstruction. Instead of inventing something new and unique, we engage in a sort of “cannibalism,” carving out the tastiest pieces from existing games and serving them under the sauce of mobile “accessibility.”

I kept coming back to that phrase, dissecting it in my mind, and the more I thought about it, the more examples I saw around me. It turned out that the act of “extracting” key elements from complex games had already become a sort of standard. But what kind of standard is that?

Let’s be honest: the success — yes, actual success — of Diablo Immortal is hardly a coincidence or just a case of “carving out” mechanics for a “wide” mobile audience. Despite the well-known “Do you guys not have phones?” line from BlizzCon 2018, which became a meme and a symbol of disappointment for many fans, the game managed impressive results. At release, it racked up over 15 million downloads in its first week alone, and years later, its monthly audience still runs high. Why? I’d venture to say the developers truly understood how to pull out the most critical parts of the Diablo experience and adapt them for a new platform — mobile. They held onto those “sweet” bits: the grind, the loot (and loot boxes), the enemy-clicking (slash-killing) mechanic, plus the rewards, and removed everything that might intimidate newcomers or cause performance issues on mobile devices.

And PUBG Mobile is a special case. When the Korean studio PUBG Corp decided to bring its multiplayer shooter to mobile platforms, many were skeptical. How could you adapt a tactical shooter with long matches and complex controls to phones? (Especially considering that, pre-2019 and pre-COVID, the average mobile play session ranged from 6 to 20 minutes, tops.) But the developers did exactly what my conference colleague said: they took the essence — arcade shooting, the thrill of winning, the fast-paced competition — and simplified everything else to the extreme. Matches got shorter, controls became intuitive (complete with things like auto-loot), and the interface was made as touch-friendly as possible. It worked. PUBG Mobile didn’t merely replicate its PC sibling’s success — it eclipsed it. According to various analytic companies, the mobile version brings in about four times more revenue than the original and has a far bigger player base. The heart of the game didn’t just keep beating; it got stronger when it was transplanted into a new body.

Sure, you might say that’s just adapting to mobile, that we shouldn’t compare apples to oranges. But the mechanics are right there, out in the open — simplified, trimmed down, but still recognizable. Let’s begin at square one.

To understand this concept, we need to see it not as some abstract idea but as a practical method. In writing this article, I wanted to dissect specific examples, pinpoint key patterns, and give readers a tool they could use to analyze mechanics — for both simplification and expansion. This approach will allow us not only to watch certain games “devour” others but, hopefully, to discover why that happens and to try applying it in reverse.

It does seem like a strange asymmetry. On one side, we have enormous AAA projects with thousands of details to pull from and adapt into mobile. On the other, we have simple games that stay that way forever. Why?

So, we’ll attempt to figure out two major phenomena:

How mobile games “devour” AAA projects, extracting only the crucial pieces and adapting them for new formats.
Whether you can go the other way — take simple mechanics and build large, multi-layered game systems around them.

To make it clearer and easier to follow my reasoning, I created a custom diagram called “The Game Design Hourglass.” It tries very hard to reflect not only the essence of the process I’m describing but also to visually represent how deconstruction of mechanics and then reconstruction can occur. At its core is that “sweet heart” — the key mechanic that remains appealing, motivating players to return again and again. We’ll revisit the diagram as we go along, adding to it so we can more clearly see how adaptation and transformation unfold.

And in the end, each game is a story, and a story can be told in many different ways. I’ll try one of them here.

II. Part 1: “How to Eat an Elephant? (One Bite at a Time)”

To start, let’s establish something for everyone: creating mobile games isn’t as simple as it might look. And creating successful mobile games is even harder. I’ve often stumbled on the notion (and occasionally the advice) that succeeding in this industry is all about making your game as simple, quick, and “viral” as those short videos we see on TikTok, Reels, Shorts, etc. But that’s a misconception, although it springs from an accurate, if superficial, observation because indeed about 70% of the games on mobile marketplaces fit the “viral” mold. Yet what matters is that most of them have an extremely short lifespan — sometimes under a week. Then they vanish.

We need not “pity” those developers because their strategy revolves around quick returns, not long-term survival. Such games aim to grab maximum profit in minimal time, surfing a spike of interest from viral content or aggressive ads. They’re “one-and-done” titles. But if you look at the remaining 30%, you’ll see that these are just the tip of the iceberg. Below the surface sits a deeper, more complex world of mobile games, in which success is measured not in days or weeks, but years.

Only a small portion of these can achieve lasting success, a fact that often goes unremarked. That’s why many long-term hits in mobile build on a key principle: they look at the longer horizon. And that’s where we find the interesting connection between mobile games and AAA projects.

It turns out that “long-lived” mobile hits generally share an important characteristic: they create a kind of depth that can keep players engaged for months or even years. That depth might not be obvious, the way it is in AAA, but it’s definitely there. Often, it’s revealed in carefully designed, addictive systems that operate on a subconscious level, prompting players to come back time and again.

To understand this phenomenon, it’s vital to define what I mean by a “good” mobile game. Yes, it’s subjective, and each game designer (or player) might define it differently. But for this article, I’ll propose an axiom: A good mobile game successfully combines three key elements: addictiveness, accessibility, and long-term value.

Addictiveness — the game’s ability to be habit-forming, leveraging repeated interactions and positive reinforcement. Players need to want to return, even if their total session is just a few minutes. This happens thanks to reward loops, progression, and the constant sense of forward motion.
Accessibility — the game’s ease of onboarding. Mobile players usually don’t want to spend hours learning complex systems or wade through lengthy tutorials. The game should be intuitive right away, with a minimal barrier to entry, but still able to go deeper if the player desires.
Long-term Value — the aspect that separates truly successful mobile titles from one-hit wonders. It’s not just the option to keep playing longer, but the presence of content, mechanics, and systems that sustain interest over an extended period. It might be seasonal events, deep leveling systems, social components, or even emotional ties to the game world.

Moving on with this thought, we need to note one key idea: game design itself doesn’t change based on the platform. The core principles that make a game fun — whether on PC, console, or mobile — remain universal. The thrill of victory, the satisfaction of progression, the emotional attachment to a fictional world — those are timeless. The differences lie not in the mechanics but in how we tailor them to each platform’s constraints and opportunities.

Simply porting a AAA game to mobile rarely leads to success. Look at Grand Theft Auto: San Andreas, Death Stranding, or Resident Evil. They all shone brightly on their original platforms, but their attempts at going mobile weren’t nearly as well-received. I can’t think of anyone who’d say, “Hey, I completed Death Stranding on iPhone and loved it!” But why not? It’s not just the technical limitations (although those matter). The bigger problem is that these titles carry over their complex systems and lengthy sessions, which just don’t fit the mobile audience.

Mobile players come in expecting quick access to fun, short sessions, and simple controls. Therefore, success in mobile requires more than just porting the mechanics; you need a rethink. And that’s where we start “eating the elephant” by taking pieces of big, heavy systems and extracting the aspects that fit a mobile format.

How Deconstruction Happens

Before going further, let’s jump back to our hourglass diagram and “zoom in” on its upper portion, focusing on the deconstruction stage. For clarity, we’ll look at it in a simplified form for now: an overview of that downward journey toward the core. This is the path we’ll take to see exactly how you reduce AAA-level complexity into something more streamlined for a new platform.

To make sense of this, let’s see game design as cooking a dish. Imagine a AAA game as a layered meal — like a fancy restaurant lasagna. It has loads of ingredients: sauce, cheese, pasta, ground meat, spices. Each is crucial, and there’s also specialized equipment and chefs, creating a unique taste. Now imagine needing a similar dish for a different audience — say, folks who love quick snacks or street food. You can’t just serve the same heavy lasagna: it’s too filling, time-consuming, expensive, and complicated for that setup. Instead, you take the key ingredients — like cheese and sauce — and craft something new, perhaps mini-pizzas or cheesy breadsticks.

The base ingredients haven’t changed (cheese and sauce), and you still get the same final outcome (tasty food that fills you up).

That’s exactly what happens with mobile games. Devs take the complex systems of AAA projects and distill them to their “main ingredients” — mechanics that deliver the real fun and addictive potential. Then they transform those mechanics to suit the new environment. It’s more than “just simplifying”; it’s reimagining, which only works if you have real expertise.

Okay, so now you have this knowledge too! Let’s dig in. With an idea of the “kitchen” tools used in this side of game design, we can move on to the juicy part: seeing deconstruction in practice. Because, as people like to say, “Better to see once than to hear a hundred times.” Let’s analyze a concrete example that, in my opinion, would be silly to skip — Genshin Impact.

One of the world’s highest-grossing mobile games, Genshin Impact, started with a simple but challenging question:

“How do we bring a full-scale RPG experience to mobile?”

The devs at miHoYo didn’t reinvent the wheel. They looked at the average mobile hardware on the market, noticed that the Nintendo Switch’s hardware was roughly comparable to mid-range phones (around 2020), and that the most successful example of an open-world action game with stellar visuals was The Legend of Zelda: Breath of the Wild. Two plus two equals bingo!

That game, presumably, became their primary model for research. miHoYo meticulously studied Zelda: BOTW, investigating its mechanics, art style, and open-world approach. But simply cloning it wouldn’t have worked — mobile devices impose different limits, and mobile players have their own tastes. That meant a thorough deconstruction of key elements was needed.

Let’s pause here for a second. Try putting yourself in the shoes of Genshin Impact’s designers. Ask yourself:

“How would I bring the Breath of the Wild experience to mobile?”

Think of the key components of the game, the constraints of the mobile platform, and which mechanics you might keep, simplify, or scrap. When you’re ready, read on!

Example #1: Open World and Exploration

In BOTW, you have a huge, seamless open world where you’re free to go almost anywhere from the start. This creates a dizzying sense of freedom, where if you see a mountain on the horizon, you can climb it. Exploration is always rewarded: shrines, Koroks, new gear — all scattered around, encouraging constant movement.

Problem for Mobile Devices:

A giant, seamless open world needs tons of resources — both technical and in terms of player time. Mobile sessions tend to be short, and loading such a big environment drains the battery, heats the device, and can be tiresome.

Our Game Design Fix:

We don’t attempt to recreate the seamless world. Instead, we split it into separate regions that load on demand. This eases the device’s load but keeps the sense of scale. Each region is big enough for players to explore freely but not so big it overwhelms the system.

Next question: how do we preserve the motivation to explore? Our solution comes from a basic psychological principle: if something looks out of place, checking it out should be rewarded. We fill each region with visual clues — strange structures, unique enemies, weird natural phenomena, sparkling objects — and each clue reliably leads to some kind of prize.

Rewards might be tiny (common consumables) or more substantial (chests with Primogems or unique items), but the principle is the same: curiosity is always rewarded. The player quickly grasps: “Something unusual? Let’s go look.”

We’ll also have an exploration metric for each region. A percentage gauge on your map shows how many secrets you’ve discovered so far. It doesn’t spell out exactly what’s missing, preserving the feel of exploration, but it satisfies the completionists.

Why It Works from a Game Design Perspective:

We form a closed reward loop: Curiosity → Exploration → Reward → More Curiosity.

This is perfect for short mobile sessions: you see something interesting, spend a few minutes investigating, and get instant gratification, plus you secure your progress. At the same time, you get that big-world freedom from BOTW, minus the need for hours-long sessions to see any progress.

Example #2: The Combat System

BOTW (in some ways, a distant ancestor of the “souls-like” trend, though that’s a whole other topic) has a fairly involved combat system. Success depends on a range of factors; it’s not just about quick reflexes but also about solving a bite-sized tactical puzzle. You watch your weapon’s durability, choose gear to counter enemies, gather materials for upgrades, and keep adapting. The main draw is that feeling of “tactical puzzle” in combat.

Problem for Mobile Devices:

Deep combat with many moving parts doesn’t translate well on mobile for two big reasons: tricky touchscreen controls and the short session focus. Plus, a steep learning curve might scare away newbies, who comprise a big share of the mobile audience.

Our Game Design Fix:

We want to preserve BOTW’s core essence — the “tactical puzzle” in each fight — but make it simpler so it’s instantly intuitive and easy to control. Our solution:

Rock-Paper-Scissors Elemental System:
Instead of elaborate weapon systems, we build a clear elemental mechanic: each element has definite strengths and weaknesses (Cryo vs. Hydro, Pyro vs. Cryo, Electro vs. Hydro, etc.). It provides tactical depth minus a huge learning curve.
Visual Clarity for Elemental Reactions (Feedback):
Every elemental interaction is instantly visible through bright effects and bold damage numbers. Correctly pairing elements yields a “puzzle solved” high, and the visual payoff is immediate.
Simplified Controls Without Losing Strategy:
Base attacks are done with simple taps. The true depth lies in mixing elements. Mashing taps can yield basic results, but mastering elemental combos massively boosts your success rate, giving the all-important sense of skill progression.
Staggered Complexity:
The fundamental combat loop is available from the get-go (also reflected in the starting hero the player controls), but deeper systems (artifacts, constellations, synergy bonuses) unlock over time. That hooks casuals with easy accessibility while also letting hardcore players chew on a deeper endgame.

Why It Works from a Game Design Perspective:

We kept BOTW’s spirit — a tactical puzzle in each fight — but changed its outward form. Instead of a giant system with endless variables, we introduced a straightforward and visually striking elemental mechanic with enough room for tactical mastery. That setup appeals to both newbies (who love the explosions and big digits) and experienced players (who optimize combos for maximum effect).

Example #3: Progression and Rewards

Progression is often the toughest piece for me. In BOTW, you boost health and stamina, find better weapons and outfits, and unlock new abilities. Rewards are scattered across the world, and you can collect them in any order. There’s no daily reward structure or progression limit.

Problem for Mobile Devices:

Free-to-play mobile games demand a lengthier lifecycle and reasons for the player to return consistently. A model with zero limits, like BOTW, risks letting players blow through content too quickly. Also, you need some free/paid balance — devs have to eat too!

Our Game Design Fix:

Multi-layered Progression:
We split progression across multiple parallel systems: Adventure Rank (overall “level”), character levels, weapon levels, artifacts, and constellations. That leaves the player with multiple mini-goals, which fit well into short play sessions.
“Resin” (Energy) System:
Introduce a resource that restricts how many top-tier rewards you can snag in a day. It regenerates over time, nudging the player to come back day after day. Important: basic exploration and main quests aren’t limited here, so it still feels like BOTW’s open freedom.
Structured Events:
Set up a regular cycle of in-game events, from daily tasks to seasonal adventures, each with its own rewards, ensuring a constant flow of fresh content.

Why It Works from a Game Design Perspective:

Multi-layered progression makes you feel like you’re always moving forward, even in short sessions. You’ve got a reward that’s always just around the corner, which keeps engagement high. The “Resin” system can feel restrictive, but really it prevents burnout (psychologically) and opens a natural window for monetization. Meanwhile, regular events ensure the world feels alive and evolving, which is essential for keeping players around long-term.

Finishing Our Feast!

Phew! That elephant sure was big. But if we’re honest, even a breakdown of Genshin Impact is just scratching the surface. If we tried to dive into every case of AAA deconstruction for mobile (and there are plenty of fun ones), we’d be going through a whole herd of elephants. My appetite’s not that enormous yet, so I’ll leave other cases (like how PUBG Mobile retooled PUBG: Battlegrounds, or how Mobile Legends simplified League of Legends) for the comments or another day!

So let’s outline the rules of deconstruction: how can you justify the notion of “taking a mechanic from Games X and Y and popping it into ours”?

Key Core Extraction:
Focus on the mechanics that form the core appeal — the features that deliver the most fun and can be simplified without losing their essence. You need to see how they fit the overall loop and figure out which are “anchors” and what you can discard or simplify for mobile/casual play.
Platform Alignment:
Technical constraints, touch controls, and short sessions are the deciding factors. When porting mechanics, think about how players interact (swipes, taps, not buttons) and plan for a 5–10 minute window (if you can hook them in that short time, you can open the door to longer 30+ minute sessions). If a mechanic can’t fit that time window, either optimize it or split it into smaller sub-tasks.
Multi-Layer Progression:
Shape your progression so that the player sees both short-term rewards and a reason to keep playing in the long run. The system should work in two modes: immediate gratification (after just one short session) and a bigger payoff if you come back tomorrow. Then the player sees how valuable each session is and doesn’t abandon the game, thinking about it even when not playing.

Now that we’ve drilled down into how to devour an elephant, turn lasagna into cheese sticks, and basically deconstruct a game, why not look at it the other way around? Let’s say we want to do the opposite: build something more complex out of something smaller. Suppose we take the running mechanic from Subway Surfers and layer it with roguelike elements, procedural generation, and a story that makes people come back not just for a quick snack but for a full-course meal.

Stage 1: “Initial Complexity.” At this point, the game is huge and multifaceted, brimming with mechanics, long sessions, and high system requirements. The goal is to meticulously record everything that makes the original experience what it is. Essentially, it’s a phase of deep analysis and understanding before we remove or simplify anything.
Stage 2: “Filtering and Simplification.” This is the heart of deconstruction. Here you discard the stuff that doesn’t fit the new format or constraints. You discover the “key fun points,” adapt the mechanics to the platform (simplify controls, shorten sessions), and eliminate anything that might overwhelm the player or device. Revisiting our examples, this is where Zelda: BOTW’s seamless world or detailed combat tactics get reworked and replaced with the pure emotional highs of exploration and combat — now reconfigured for mobile.
Stage 3: “Final Essence.” By the end of this stage, you have a significantly simpler — but still recognizable — structure. It’s where you assess whether you’ve preserved the core loop, struck a balance between accessibility and engagement, and are ready for the next step.

Notice how our three earlier rules align with these stages. For example, Key Core Extraction neatly represents the shift from “Initial Complexity” to “Filtering & Simplifying”. Platform Alignment is the key driver of the “Filtering & Simplifying” stage, dictating how you adapt mechanics for the new platform. Meanwhile, Multi-Layer Progression emerges toward the “Final Distillation,” where you shape progression systems that keep players invested.

So that’s how you eat an elephant, turn lasagna into cheese sticks, and dissect a game. But what if we try going the other way around? What if we take a simple snack and build it into a full meal? For instance, imagine taking the running mechanic from Subway Surfers and adding roguelike elements, procedural generation, and a story that keeps players coming back not for a “quick bite” but for a full-course experience.

Because that’s what we started pondering in the first place: not just how to simplify but how to build up something from a smaller base. On we go to the next part!

III. Part 2: “How to Build a House? (Brick by Brick)”

This part of the article is quite personal to me. Let me be straightforward: if it weren’t for my “game designer’s” professional bias and a weird, almost masochistic habit of diving into every beta test or closed preview, I probably never would have written this. The idea, the “bold analysis,” came about because of my habit of poking my curious nose into any intriguing new project.

It’s not even that I have a special passion for buggy, half-done titles (though, honestly, I do enjoy them). It’s that you get a unique chance to watch a game grow, morph, and transform, sometimes dying off in infancy, sometimes becoming something else entirely. That’s precisely how these reflections on deconstructing and constructing game mechanics took shape.

Betas usually serve as little experiments and thought exercises for me, but for some time now, HASTE: Broken World had been on my radar. I was quite eager to “poke around” the game, not just because it looked cool, but also because I’ve always liked LandFall and their approach (big hello to those folks!). So, when the chance for closed beta came along, I jumped at it. While I was playing around with its procedurally generated levels, my brain kept churning: “What exactly am I feeling right now? Why is something so simple so addictive? Which detail is hooking me?” And that’s when I saw not only how simple systems could evolve into something more but the other side of the coin: not just deconstruction of large mechanics, but also construction. There it was, the missing puzzle piece, the flip side of the medal, the reason for this article!

(By the way, if you haven’t tried the new HASTE: Broken World demo on Steam yet, hop to it!)

HASTE is perfect for our little investigation, precisely because I got to see how it ended up at its current form. I know how the devs got there. This example is especially valuable to me: not only did I watch the process, but I know the devs hadn’t set out with my “construction–deconstruction” framework. Their idea came from internal prototypes, not from picking apart someone else’s game. And yet, ironically, HASTE practically “intuitively” implements the constructive approach we’re about to discuss, as though the team subconsciously followed the same reasoning we’re describing, creating a robust system out of a single, simple mechanic that resembles a mobile runner.

Now that I’ve laid out the personal aspect and walked you to the spot where the puzzle pieces fit together, let’s move forward. We’ll see exactly how you can build a substantial, deep gaming experience around the simplest possible mechanic — “running forward.”

How Construction Happens

Let’s go back to our “Game Design Hourglass,” but now let’s focus on the lower half. The top half showed the transition from complexity down to a simple core, while the bottom half is the reverse: we start with that basic core and expand upward, adding layers and systems. Think of it like “zooming in” on the lower portion, still without too many details.

It’s usually easier to simplify something that exists than to expand it. Breaking is simpler than building, right? Pulling cheesy sticks out of a lasagna that’s already there is no big deal. But making a lasagna out of cheesy sticks is the real challenge. The key is that even in this “building” approach, minimalism doesn’t vanish. Construction is not about cramming everything in but rather a minimalistic expansion. We’re not piling up a giant fortress; we’re trying to build a comfy, fully functioning house out of single bricks.

Broadly speaking, a mobile (or casual) game can sometimes be 100% sugar cubes: brimming with positive reinforcement, quick rewards, and super-simple rules. You have a “box” that’s mostly immediate gratification. But if you want to turn that “box” into a bigger, more varied experience, you’ve got to lay bricks of deeper, more deliberate mechanics. And that, in turn, requires a structured approach — a mirror to our method of deconstruction. The difference is that, in deconstruction, we had all the “fancy bits” to strip away. In construction, we’re facing the emptiness beyond the core. We need a framework that can sustain a bigger experience while still keeping that “sweetness” of short sessions, accessible fun, and so on.

Hence, construction isn’t just “adding more stuff.” It’s about carefully, gradually integrating new systems so you don’t crush the original simplicity and fun. And crucially, the basic rules of game design remain universal. In principle, the “constructive” path can be no harder than the “deconstructive” path — it’s the same balancing act, turned upside down.

If you watch gameplay of Subway Surfers on the left and HASTE: Broken World on the right, you’ll spot a direct resemblance, much like Genshin Impact and Zelda: BOTW. This doesn’t mean anyone’s “stealing ideas” (we know LandFall got here through a different, three-year route from an unrelated prototype). But imagine you’ve got the brainwave:

“What if we take Subway Surfers and expand it to a grand-scale project?”

What bumps in the road would you face? What would that thought process be like?

You’d soon run into a not-so-obvious but rather massive stumbling block: imagination. Unlike deconstruction — where you see a finished product and remove parts — here, you don’t have a perfect blueprint or reference. You not only have to pose the question but also envision how to grow a game from “run forward.”

It’s easy to get stuck. The first pitfall is referencing existing games: “Well, Sonic runs too, so let’s be like Sonic!” But you didn’t want to just clone Sonic or “make a Sonic out of Subway Surfers,” right?

Hence, at this stage, the game designer has to be very clear on which rules and principles they’ll use to build something big around a core that’s small. That’s where we jump back to the analytical vantage point: imagine we’re the game designers who got this assignment:

“Here’s the mobile runner Subway Surfers. Your job is to expand its simple mechanics into a full, rich game without losing its basic appeal — but also without turning it into Sonic.”

Forget for a moment that LandFall already made something kind of similar (albeit via a different route) or that HASTE: Broken World exists. Let’s just see how we’d do it from scratch, using fundamental game design logic and the concepts we’ve discussed so far.

Time to get our hands dirty “building a house.”

Example #1: From “Three Lanes” to Meaningful Landings

In classic Subway Surfers, you swipe left and right to dodge, jump to clear obstacles, and pick up coins across three lanes. For our expanded version, we’d like more variety and a sense of skillful control. The base runner doesn’t have much nuance — you either jump or crash. So what if we introduce an extra “landing quality” factor that shapes your run’s results?

Problem We’re Solving:

In typical endless runners (Subway Surfers, Temple Run, Minion Rush), after a bit, the experience can feel repetitive: the player only has quick-swipe reflexes and memorizing obstacle patterns. We want each jump or slide to have at least a pinch of strategy.

Our Game Design Fix:

Add a “landing” system — a mini-skill check whenever you come back down after a jump or drop. Picture a “timing bar” or “precision gauge.” Depending on whether you land spot-on or flub it, you gain certain bonuses or penalties.

Instant Reward:
A proper landing might ramp up your speed or grant a special “energy” (Boost or Energy) you can spend on extras like short-term turbo, a super jump, or temporary invulnerability.
Pacing Shifts:
By highlighting landing control, you introduce mini-lulls where the player thinks, “I need to time this jump perfectly to stay efficient for the next five seconds.” No longer is it just about memorizing patterns but also about when and how you land.
Synergy with Other Systems:
Perhaps good landings trigger more valuable pickups (coins, crystals, etc.). That encourages players to keep getting better at these mini-skill checks, rather than merely swiping mechanically.

Why It Works from a Game Design Perspective:

First, we preserve the usual “three-lane” environment, but it’s no longer just a fixed corridor. The player has more agency, and the space feels “deeper.” Second, the same frantic reflex-based tension remains, but now there’s a skill element: nailing “perfect landings” to gain advantage. Third, because we’re awarding bonuses or penalties, players are incentivized to hone their skills over time, ramping up their resources and enabling riskier maneuvers.

Extra Note: “Surfboards” and Similar Boosters

Subway Surfers has a “hoverboard” system that acts like a temporary safety net and bonus engine. In HASTE: Broken World, there’s a similar “Surfboard,” but it’s not just a passive bonus. It’s an ability you activate with an “energy” resource you accumulate through skillful landings. That adds a layer of tactical choice: you can’t just pop an ability whenever; you need to decide when and how to trigger it, depending on your current state and energy reserves.

Hence, by one decision, we elevate two simple mechanics — movement and temporary power-ups — into a meaningful system, while retaining the original accessibility.

Example #2: From Tedious Repetition to Adaptive Difficulty Scaling

Any endless runner typically increases difficulty in one way: the longer you run, the faster it goes, and the more complicated the obstacles. But eventually, players see the repeating patterns and the novelty evaporates. We want each new attempt to feel fresh and exciting.

Problem We’re Solving:

Classic mobile runners might hit a “difficulty ceiling.” Sure, speed keeps rising, but the level geometry or obstacles remain pretty much the same patterns in different sequences. Once the player memorizes them, the only factor left is “speed.” They either eventually crash from sheer velocity or get bored.

Our Game Design Fix:

Use procedural (or hybrid-procedural) generation with a “dynamic difficulty budget.” In other words, every track segment draws from a certain “budget” of points that the game can spend on obstacles and environment features. The further you go, the higher that budget, so you see more varied and challenging obstacles. Key elements:

Vertical and Horizontal Variation:
We can drop the static, three-lane flat approach. Our expanded runner might include slopes, multi-layer platforms, branching paths, or overlapping traps. That stops the game from feeling monotonous.
Smooth Difficulty Curve:
Rather than just flipping on “turbo mode” at X minutes, let the procedural generation ramp up complexity based on the difficulty budget. If the budget is high, the system can spawn nastier obstacles, cunning traps, special events, or even mini-bosses. This helps maintain the sense of “flow” — hard but still doable.
Progress and Reward System:
Each segment can rate you on how quickly you passed it, how many items you grabbed, or some bonus criteria (like precision landings). High scores encourage skillful play. You might get buffs that carry into the next segment.

Why It Works from a Game Design Perspective:

Procedural generation with a difficulty budget keeps things from becoming stale. Patterns appear in new combos, forcing you to adapt. The difficulty curve adjusts continuously, hopefully matching your developing skills and giving that satisfying sense of “I can do this if I stay sharp.” Rewarding skillful players with bigger prizes completes the motivational loop.

Example #3: Quick-Fire Solutions

To finish our little “construction” tour, let’s do a few more expansions we can add when evolving a simple mobile mechanic into something deeper. This time, we’ll keep it short and sweet: “Problem → Solution.”

Roguelike Flavor and Procedural Goodness
Problem: Endless runners can still feel repetitive; after you’ve seen enough patterns, you might get bored.
Solution: Add meta-progression, like a roguelike (randomized items, between-run growth, branching paths a la Slay the Spire) and keep using robust procedural generation. For a Subway Surfers example, you might let players choose a branch after each run, with each new track featuring unique obstacles and random gear that buffs your character. Think “Subway Surfers meets deckbuilding.” Sounds wild, but balanced right, it’s addictive. (Hello from HASTE!)
Story and a Real Ending
Problem: Many mobile runners have no narrative or finale; it’s all endless, so the motivation fades when you realize “it never ends.”
Solution: Give it a storyline split into chapters (or biomes). Each ends with a boss or final test. Still keep an endless mode for those wanting high scores. But now you also have a reason to keep pushing for story progress.
Escaping the F2P Chains
Problem: Mobile games (especially runners) often rely on microtransactions.
Solution: Either skip F2P altogether or at least tone it down, so you aren’t pushing microtransactions at every turn. That freedom lets you build deeper systems for long-term enjoyment, not just micro-purchases. (Thanks, Captain Obvious!)

Why It Works from a Game Design Perspective:

These three tweaks — roguelike systems, a storyline, and friendlier monetization — let you keep fast, casual sessions while expanding the concept into a bigger project. Procedural generation and roguelike elements combat repetition. A storyline adds a sense of progress and closure. Minimizing harsh monetization sets you free to include more thoughtful, long-lasting mechanics rather than quick hits of gratification. You can mix and match these ideas however you like. The key is seeing beyond that immediate “sugar” and realizing that “run forward” can be the foundation for much bigger things.

A House the Game Designer Built

I’ve practically gotten calluses on my fingers writing all this… Let’s take a tiny break. If you’re still here, that means we’ve done a pretty solid job, and our “house” now stands with a proper frame and shape. All that’s left is to look around and see how well we transformed a lightweight, casual concept into a truly deep and compelling game.

As we discovered, the fundamental principles of game design remain the same, whether we’re deconstructing something huge or constructing something large out of something small. The main challenge is striking that balance: not drowning in details, keeping the “heart,” and ensuring the result remains fun and user-friendly.

So, what big lessons can we extract about construction?

Core-Driven Expansion
Don’t throw a hundred mechanics at the player. Let each new system grow directly from the fundamental gameplay. If “running” is your cornerstone, make all expansions revolve around it: landing mechanics, energy usage, interesting obstacles. Steer clear of random add-ons that feel disconnected.
Modular Layering
Expand in layers, not everything at once. Start the player off with the basic mechanic in pure form, then gradually add new capabilities, challenges, or progress loops. The game feels like it’s constantly evolving without overwhelming newcomers.
Meaningful Complexity
When adding challenge or intricacy, ensure every piece has a point. Complexity for its own sake isn’t good design unless it reinforces a reward system or has synergy with existing mechanics.
Motivation Loop
As you expand features, anchor them in a reward structure that feeds back into the game’s main loop. If you add “landings” and “energy,” let them integrate with progression, bonuses, or advanced content. That way, your new system is more than just a gimmick — it’s central to the overall experience.

Now that we understand how construction works, let’s revisit the bottom half of our hourglass in more detail. The top showed how we simplify complexity; the bottom shows how we build from a kernel. Just like deconstruction, we can break it down into three steps:

First Stage — “The Starting Core.” Here, we have the simplest, platform-friendly mechanic that must be intuitive and fun by itself. This is your “box,” your foundation. It’s crucial that this core really is engaging. If it isn’t fun, no amount of bells and whistles will save the game.
Second Stage — “Modular Expansion.” This is where we systematically add new layers. Each mechanic blossoms out of the core, developing more robust surroundings, deeper gameplay, new progression routes. The player already feels comfortable with the basics, so each addition expands an established framework.
Third Stage — “Full Complexity.” In the end, we have a multi-layered, coherent design. Every new system has its place, and your motivation loops become more elaborate. This is the time to confirm you haven’t overloaded the game with features and that it’s still approachable. If we did it right, the game can keep players long-term without scaring them off or boring them.

Once again, the rules we detailed for construction map neatly onto these three steps. For instance, Core-Driven Expansion lines up with “The Starting Core.” Modular Layering is all about “Modular Expansion,” while Meaningful Complexity and Motivation Loop shape “Full Complexity,” where the game remains welcoming and players return over and over.

So there you have it — your “builder’s handbook.” It’s a kind of compass to keep you from getting lost in the vast realm of “let’s expand a simple idea.” We’ve built our house and hung a few curtains. Now, it’s just a matter of deciding who’s hosting the housewarming party!

But, as always in game design, there is no end to improvement. You can always add more features, systems, or a basement with quirky secrets. I encourage you not to stop here: feel free to continue the conversation in the comments or future articles. I’m certain some of you can “build a house” that’s even bolder and more elegant.

For now, let’s pop the champagne and watch the fireworks as we bring this to a close!

IV. Conclusion: “The Sweet Heart of Game Design”

Kicking off with a simple question — “Can we adapt and rework mechanics between AAA and mobile games?” — we arrived at the understanding that construction and deconstruction are not just possible, but incredibly helpful. Through concrete examples, we saw that the formula for success lies in skillfully identifying and adapting the core elements that drive gameplay, always looking for that sweet spot between accessibility and depth.

Now that we have both halves of our “Game Design Hourglass,” it serves as a universal lens: flip it around to watch deconstruction, or keep it upright to see simple cores expand outward. It’s not some one-size-fits-all approach and will need tweaks per project, but I think it illustrates a few of the big constants in game design. We can apply it either when analyzing large, complex titles for simplification or when turning small casual concepts into deeper games.

Above all, remember that at the center of any lens is the heart of game design itself, which you can’t build purely out of analysis or “right tools.” That heart needs a creative spark — a clear vision of the project’s meaning and a team that cares enough to bring it to life. That creative spark is what lets us see adaptation not as “cannibalizing” the original but as transferring its essence into a fresh form. A game designer in that sense becomes a donor or an inspirer — not just piecing together borrowed parts, but retaining what made them special while adding a new layer of meaning, so the end product finds its own identity.

I believe this method isn’t just about borrowing other titles’ mechanics; it’s also about genuinely understanding their core, so you can adapt or expand them consciously and craft new experiences. Both construction and deconstruction help us isolate the most important bits, discard the clutter, or gradually build complexity around a simple foundation without losing that delicate balance of depth and approachability.

If you’ve ever wondered how to make your game deep yet easy to learn, I urge you to experiment with both approaches. Take a mechanic from your favorite game, pare it down to its bare essence, and then try “growing” it again by adding layers of meaningful systems. At least now you have a way to try it on paper! So, get those Game Design Documents open and dive in!

P.S:

Yes, this is my first hefty article, and I’ll admit it turned out veeery… big, and somewhat personal. I hope that if you’ve made it here, you’ve found something useful, gotten some inspiration, or at least got a bit of food for thought. For me, writing out my thoughts like this is labor-intensive but super helpful in clarifying and organizing my own experiences.

I’d be genuinely happy if you shared your thoughts, comments, and especially your critiques. Remember: the sweetest heart of game design is the ability to see possibility where others only see constraints.

See you in the land of bigger secrets → t.me/slepokNTe
Or if you looking for more... linktr.ee/nickkeepkind