Design patterns get taught like recipes, or plug-n-play magical bits of design: “Add a hub”, “Make a crafting system”, “Give enemies attacks telegraphs”, “Implement a battle pass”, “We need a checkpoint system”. That approach is enticing because it turns design ambiguity into a to-do list, and for a designer, controlling chaos is oh-so-sexy: just follow the recipes, and you will make a good game. But doing so often produces a particular kind of failure: stacking recipes you do not fully understand creates inconsistent, muddled experiences that are a pain to fix.

Design Patterns aren’t magical one-size-fits-all solutions. They are solid, stable responses to recurring constraints, coming from either the development or the player: content limits, information overload, pacing balancing, economy stretching, players’ skill distribution, social friction… And it’s only when you clearly identify the constraints you are trying to solve that you will find the right design pattern to employ, or better, that you will find your own answer instead of unfolding a textbook pattern. Failing to do so will instead create friction, impossible-to-balance games, development hell, and chaotic player experiences.

I could have made this article a “Top 10 Design Patterns Every Designer Should Know”, but not only would this be of no help to you, but it may also continue this false narrative that they are the answer to all of our design problems. Instead, we’ll try and have a look at how we can solve our problems using design patterns as a framework.

The Danger of Treating Design Patterns as Recipes

In my experience, there are usually 3 dangerous reasons a team would turn to a design pattern:

• Coordination and alignment: It gives teams a common vision to discuss. “Hub” is easier to plan and align on than “a pacing recovery mechanic that manages content accessibility and gating.”
• Risk management: A solid pattern feels safer (planning, QA, iteration time) than inventing a new system, particularly when under development pressure.
• Competition imitation: “Every game in my reference is doing it, I’d better do it as well”.

In themselves, these reasons stand, and we can find many situations where these would be proper (complex team structure, time to market, player expectations and marketability…). Yet, these reasons aren’t sufficient, and they often critically underthink how drastically the addition of a new pattern will affect the player experience. Design patterns aren’t simple features; they are a trade, a conversion machine, if you will, that will solve a problem by accepting a cost somewhere else: in agency, clarity, pacing, fairness, development time, surprise. Examples:

• “Soft Gating” our content (skill/progression-based, rather than “Hard Gating”, the classic lock & key approach) can reward mastery and expand player agency, but it risks sequence-breaking our narrative and frustrating players if consequences aren’t signposted enough.
• Fail-Forward mechanics prevent the problem of failure “deleting time”, but risks softening the stakes and blunting the sense of achievement players should feel.
• Rubber-banding systems are great at creating tight, exciting races from start ot finish, but may rob players of their victory and dismiss their skills by “cheating”.

Adding a design pattern to our game without understanding it fully in your unique context puts us in a situation where its impact will be felt later in production (or when the game is live) and where solving it could be extremely complex and, more often than not, very expensive: we would inherit the costs of each pattern without earning its benefits, because we never adopted the constraints that made the pattern coherent in the first place

So let’s dive a bit into what a design pattern is, what it implies, and how it affects the player experience.

Design Patterns

Let’s start with a single, usable definition of what a design pattern is:

So… We have a lot to unpack here, and the parts in bold will be central to our study:

• Repeatable Structure: what makes the design pattern: the mechanics, content, rules, or flow that this pattern follows. Example: “Telegraphed attacks” implies perceivable cues (animation, VFX, SFX…), a readable window of opportunity, a clear expected reaction, and an unambiguous resolution. This structure supports itself on clear levers (why does this pattern work). Example: information > prediction > perceived fairness.
• Constraints: the pressure points, limitations, or problems we are trying to solve with this pattern. Example: limited player attention, calculation complexities, early churn, pacing/intensity range gap, economy inflation, production time, etc.
• Costs: the downsides we are accepting in exchange for the pattern benefits: these could be production-facing or player-facing. Example: reduced surprise, increased grind, balance complexity, development time, more complex onboarding, etc.
• Player Expectations: the implicit promise the game is making to the player through the use of this design pattern. Even unintentionally, every feature signals to players what to expect from the game. From now on, we will call them Contracts. Examples: “Even if I lose, I make progress”, “If I pay attention, I will succeed”, “The UI always shows me what matters”, “If I play a little bit every day, I will make steady progress”, “Preparation is the key to mastery”, etc. These contracts are fragile, easily broken, and will lead to loss of trust from the player and a damaged experience if ignored.

These are the key factors that dictate whether a design pattern should be used, and why starting with a textbook pattern is often a bad idea. In most cases, this is a bottom-up approach. Too often did I hear sentences like “We are a Live game, so we need a Battle Pass” or “This is a genre staple, we can’t ship without a crafting system”, without properly understanding the ramifications these decisions will have on the game and its development.

Instead, let’s start the other way around: What constraints is our game under? What costs can we afford? What contracts are we willing to sign with our players? These are the real questions that will let us find what design patterns make sense to use or bend in order to create a unique, cohesive experience.

From Pressure to Feature: a Constraint-first Framework

#1: Write the Constraint(s) you are facing without mentioning Features

Before discussing solutions, it is critical that we start expressing the constraint(s) we are trying to solve, precisely. Doing so will define a clear design space for us to explore.

Example, instead of “we need a crafting system”:

• “We need a durable motivation loop between content drops”.
• “We need to prevent players from feeling idle during downtime”.
• “We need progression depth without moment-moment paralysis”.
• “We need players to feel failures without losing anything important”.
• Etc.

Notice how different all these constraints are? A crafting system is only one possible answer to a wide array of problems! You may have also noticed that in none of those did I mention specific features: we want to define the design space of our constraint without shoehorning solutions.

#2: Write the Contract(s) you are willing to sign with your Players

Whether we want it or not, every feature of our games signals behaviors to our players, something to expect. It is critical to identify these contracts early so we can shape the features around them and not let the game dictate them to us.

If we continue the previous example, contracts for these constraints could be:

• “Even a short session still creates meaningful progress”.
• “Downtime is a different kind of play; it is not waiting”.
• “Experimentation is safe and encouraged; you won’t lock yourself out”.
• “Failure has a price, but you always get something for it”.
• Etc.

What is critical here is not only to pick the right contract for our constraint, but to pick a contract adequate to the other contracts we already signed with our players! Conflicting or invalidating contracts are what often silently kill a game experience.

• Contract A (Identity/commitment): “Your choices are what define you; Builds are unique; Commitment creates pride”.
• Contract B (No-regret freedom): “You can never mess up; Respec is infinite; experimentation is safe”.

If we look at these 2 contracts in isolation, they are solid, positive, and have been used separately in hundreds of games. But together they invalidate each other, and using both in the same game will create constant friction. Either commitment will stop meaning anything (Builds become outfits, not identities), or players will feel betrayed if some changes are permanent (“The game told me I could experiment. Why am I punished now?”).

Below are 2 other sets of contracts. Try to find where they may collide with one another and what games still use them together:

• Contract A (Open Exploration): “Go anywhere, the world is yours to discover, and getting lost is part of the fun”.
• Contract B (Narrative Urgency): “The story is urgent and paced. You must hurry”.

• Contract A (Readability): “If you read correctly, you deserve to succeed. Clarity is fairness”.
• Contract B (Spectacle): “Surprising, chaotic sequences are where the fun is at! Screen is full, retinas are burned, outcomes get wild”.

Conflicting players’ contracts is one of the main reasons why a game feels solid on paper but doesn’t play right (churn, play-time drop, low finisher percentages…), and this will almost always happen when stacking features for their isolated perceived value without crafting them carefully for a specific game.

#3: Identify the Cost(s) you are willing to pay

Everything has a cost: either we choose it willingly, or our features will choose it for us. Asking ourselves this question early will ensure these costs are understood, chosen, and backed into our features meaningfully. As we discussed previously, there are 2 kinds of costs: the ones the devs are paying, and the ones the players are paying. The costs we are very comfortable discussing are usually the development costs: balance difficulty, QA complexity, development time, monetary costs… This is day-to-day game development.

What we are not comfortable discussing (or accepting), however, are the costs on the player side while discussing adding new features :

• Telegraphed attacks, UI preview, fixed boss phases… > Reduced surprise / predictability / gamification
• Side quests, social spaces, base building, crafting loops… > Weaker narrative urgency / diluted stakes / UI complexity
• Ranked ladders, DPS meters, leaderboards… > Optimization culture / Identity threat
• Loot drops with high variance, gatcha, procedural generation, high RNG > Win feeling dilution / Grind and maintenance bore
• Layered progression systems, high synergies, multi-currency economies, deep crafting trees > Onboarding burden, player dissociation

We cannot get away from these: we will spend simplicity to buy variety, we will spend surprise to buy fairness and clarity, we will spend freedom to buy balance…. It’s inevitable.

There will be some costs that we find very much acceptable to pay in your game, but others will be a hard no. Choosing them, instead of enduring them, ensures that our teams and game experience can afford them.

#4: Pattern Candidates

After all this prep work, it is finally time to look at some design patterns candidates! And this is where having a strong design pattern literacy will make us shine. Let’s say we are trying to solve the constraint “Need for a durable motivation loop between content drops”, a multitude of patterns could fit: daily missions, milestone-based goals, a long-term meta-progression, rotating rules (mutators, weekly), hub projects, competitive ladders… Choosing the right one will be way easier now that we know what cost we are willing to pay, and NOT pay!

Still… with many candidates, how do we choose the best one before implementing and testing it? Well, here is a useful stress-test: write down one primary contract you refuse to break and one cost ceiling you refuse to exceed, both related to your constraint at hand. Then use these as kill criteria and discriminants for your candidates. You will be surprised how many are filtered out right off the bat.

• Kill Criteria examples: “If the pattern makes power feel cosmetic, it’s out”, “If this pattern only works for players logging daily, it’s out”. Etc.
• Discriminant examples: “Which candidate produces the best attributable failure?”, “Which candidate preserves tempo the best without increasing chores?” etc.

Let me take a concrete example: in the game I am currently developing, The Snackbar at the End of the World, the player must explore “the Wilds” every day to forage ingredients for their restaurant. The Wilds are split into 7 Biomes, each with their own ingredient sets that get increasingly more difficult. As we are testing it, a strong constraint appeared: late biomes must be reasonably fast to access. I can’t have players go through 30 minutes of early, easy content every run just to get to the biome they are interested in.

Multiple design patterns would fit the bill: a Hub, a shortcut system, a circular navigation between biomes, a meta-map…

In terms of costs, I have quite a few I am willing to commit to: lessened sense of adventure, stronger “gamification” feeling, loss of world cohesion… There are also costs I am NOT willing to compromise: development time (we are a small indie team), for one, but also the fact that players of every skill level must be able to access late content, and late biomes/ingredients access must feel strategic and let players showcase mastery. This last one is key as it directly collides with the constraint, and this is where we can try and find a unique solution to our problem.

In terms of discriminant, the one that mattered the most for me was “The candidate that produces the highest tempo control and strategic access”. This pushed me towards a Hub system (solution also widely used in our genre as well) but with a twist: 3 Hubs, stacked one on top of another. Each hub gives the player access to 2 to 3 biomes, but also to the next Hub. Accessing this next Hub requires the player to spend resources found in the current Hub. Coupled with a “Persistent Stash/Chest” (another design pattern), letting players bypass the requirements, I created what I believe is a great solution to my constraint, with very acceptable costs: players can rapidly access Hub #3 by being smart, strategic, and displaying mastery in the previous ones, I can easily hard gate the access to these Biomes for Narrative purpose, and even bad players can use the Stash system to quickly bypass Hubs requirements.

A Hub is a staple of the genre. But starting from the need for a Hub without understanding why would have never led me to this unique implementation (and for sure would have created much friction for me down the line).

Another interesting part of this study: it clearly points to my key tuning levers: the cost of Hubs transitions, and the Stash specifics (capacity, deposit/withdrawal limits): badly tuned, and I would either frustrate bad players (extensive grind, frustrating punishment), or dismiss the mastery component of the game if too generous.

#5: Contract-matching Metrics

Finally, we need to make sure we clearly identify the metrics that will let us confirm that our contracts are staying true, for the right reasons. If our contract is “short sessions still matter”, we may want to optimize for “% of sessions where players completed at least 1 mission”, or “DAU/Return rate”.

Be careful, metrics are easy to measure the wrong way: we can raise time in-game by adding maintenance loops and timers. We can raise retention by punishing absence. We can raise spending by adding friction and arbitrary sinks… In the example above, we can very easily skew your metrics by adding streak and FOMO systems, auto-complete missions (“log in for the day”), bribes (“Daily gift”), chore inflations, etc.

Players feel the difference between “the game wants me to…” and “the game forces me to…”. If our patterns drift our game from play device to obligation ones, we’ll get the numbers until we don’t.

A Final Warning: Player Contracts are Everything

A mistake I often see in production, and the reason I’m insisting so much on the “Player Contracts” lens, is the mismatch between what designers are trying to do and how players perceive it. For example:

• Systemic intent: “We need to prevent DPS spikes from trivializing encounters.
• Design pattern: Enemy scaling to player level.
• Player perception: “Progress is fake, getting stronger doesn’t change anything”.
• Previously Established Contract break: “Grinding makes me powerful”.

This design pattern is a classic one, and has worked in many other games, but in this hypothetical scenario, it creates a mismatch between the contract we previously made with our players and what the game is actually doing. A lot of other design patterns could fit the bill here: partial scaling, player-driven difficulty paths, narrative difficulty raising (ex: Hollow Knight’s corrupted crossroads), etc.

Upholding player contracts is one of the most important responsibilities of a Game Designer, in my opinion. And it’s oh-so-easy to forget about them… Sometimes, they are contracts we signed with players early on that can drift across the game (ex: enemies abandoning readability later on for the sake of “difficulty”), sometimes it’s contracts our game genre (or the genre we are advertising) signed for us that we aren’t respecting (ex: roguelites “failure is learning and progressing, runs are short, variety is expected” or looters “progress is constant and persistent, variance is where the fun is at, optimization is social”). Whatever it is, we MUST do our best to ensure they do not contradict each other, and they stay true throughout the experience.

“But wait a little bit… Sometimes, purposely breaking contracts or having them collide is what creates the best kind of content! An obfuscated objective, an intentionally impossible-to-read boss, a system that flips progression on its head! You are being way too strict!”

Ahah, now we talk! There are indeed moments where bending the rules leads to killer results. You could consider colliding contracts by segmentation (story mission vs. open world, for example), staging (the contract changes over time, and is properly telegraphed to players), or simply as big one-offs for dramatic effects! Here is where our experience as game designers will shine!

Conclusion

Treating design patterns like magical recipes will only make us curators of other designers’ solutions. Instead, approaching them like the potential answers to recurring constraints will make us the authors of our own trade-offs.

Study your game’s unique constraints, treat player contracts as your game experience’s sacred foundation, choose the costs you can afford (and the ones you WON’T afford), and only then start to consider solutions. Sometimes, it will look like the textbook design pattern; more often than not, it won’t. As long as you can explain it, tune it, and when needed, reject it.

A design pattern you can’t explain is a pattern you can’t control.

Did you enjoy this article? If so, please consider supporting GDKeys on Patreon. It helps keep this place free of ads and paywalls, ensures we can keep delivering high-quality content, and gives you access to our private Discord where designers worldwide gather to discuss design and help each other on their projects.

These games are made by folks who poured their hearts into every pixel and line of code. By supporting these creators, you’re helping passionate indie devs keep making the games they love—and sharing them with players like you. Every download, every share, every bit of support matters. Thank you!

I had my fair share of online game nights as well! But these somehow felt incomplete, less memorable, less sacred. Board games have these inherent qualities that make playing them with others superior. How is it possible, though, when video games can create incredible cinematics, gigantic and detailed worlds, make you wield a sword, drive a supercar, or tell you these incredibly immersive stories? After all, board games only have pieces of cardboard and a few tokens to do so.

I’m sure you already think of many possible answers: “The stories you create together with friends are more powerful than the ones being told to you by a piece of software”. True. “It’s about spending time together: game night beats sitting alone behind a computer”. Agree, I still miss the LANs of the old days. “The physicality of a board game makes the experience more real: it makes you more connected to the moment”. Ah! this one is interesting: physicality has great qualities (oh the smell of a new rulebook’s ink…) but also many shortcomings: setting up a board is a chore, distributing pieces in a game of Mahjong is tedious, someone needs to be the Bank in Monopoly and actually do the math and count bills, dice can roll under the couch, tokens will be lost, cards bent… All of these issues have been solved, and improved on, by video games: setting the playfield is instant, the game will distribute cards, shuffle decks, and count points for you, it will automate every repetitive, boring action… Video games have this superb ability to take care of all the friction and leave players with only the fun part of games!

Or so we thought.

I am convinced that this simplification process, streamlining games, letting players play together from all over the world from the convenience of their own couch, and making playing as convenient as possible, is what killed part of the soul of what makes these moments so special. If we want to create deeply engaging digital experiences, we will need to bring back friction, chaos, and appropriation to the video game space. Why? Because it is through them that Rituals emerge.

The Key Role of Rituals

Rituals have always played a critical role in human societies. They shape human experiences, develop social structures, and create meaning. They help us navigate uncertainty, reinforce social bonds, and provide a sense of continuity across generations. Anthropologists, psychologists, and sociologists have studied rituals extensively over centuries, showing that they serve both practical and symbolic purposes. Some of these rituals are based on habits (your morning coffee, or make-up routine, or how each object you carry has its own pocket, etc.), some are spiritual or superstitious (putting your lucky shirt, knocking on wood, repeating mantras…), while others serve social purposes (weddings and funerals, greetings, inaugurations…).

Whatever shape they take, these rituals have been found to affect the human experience profoundly:

• Rituals reduce anxiety and increase confidence – Alison L. Brooks et al. (2016)
• They provide a sense of control, especially in uncertain or traumatic situations – Mauricio Delgado and Andrew Wagner (2017)
• They reinforce collective identity and create a sense of belonging – Émile Durkheim (1912)
• Shared rituals increase cooperation and trust, even among strangers – Daniel Fessler (2014)
• Repetitive ritual actions create strong neural associations, making experiences more memorable – Pascal Boyer and Pierre Liénard (2006)
• Anthropologists even suggest that rituals evolved as cultural mechanisms to ensure cooperation and group survival – Roy Rappaport (1999)

Johan Huizinga, in Homo Ludens, famously drew strong parallels between Rituals and Games: both share a “Magic Circle”, a sacred space where different rules apply, and both are rule-based and very codified. Huizinga further claims that Rituals have evolved from their Play form and that early rituals were essentially games: “Ritual grew out of play. It was sanctified play.” Many games today (board games or sports) are direct descendants of old rites!

Video games, unfortunately, have often lost this connection to the sacred on the altar of convenience and entertainment and, by doing this, removed an essential part of what makes games social, fundamentally human experiences. It is my deep belief that video games must reconnect with the ritualistic essence of play. But to even attempt to do this, we first need a structure.

Rituals: a Taxonomy

Ronald L. Grimes, a scholar in ritual studies, spent most of his life studying rites. As part of his impressive work, he developed a taxonomy of rituals that categorizes them based on their function and form. This categorization is structured around 6 groups:

These categories may seem obscure at first read, and difficult to apply to our topic, but if we start studying them through the lens of board games we can connect many important parts of the game experience to each of them. Let’s take some examples:

We could list many more examples, but those already let us draw an important conclusion: almost none of these examples can be found in, or apply to video games. Looking at video game adaptations of board games (the easiest comparison) we notice that video games usually try to improve on the limitations of the physical product: animating actions, creating 3D renditions of cards and boards, bringing juicy cinematics to key moments of the game, adding SFX and VFX to every single interaction to create a highly playful, juicy, and immersive experience. And these are GREAT!

But video game designers have another tendency: they tend to view friction as a negative thing: why ask players to move their tokens or roll their dice when we can do it for them? Why ask them to calculate points by hand when a simple calculation can automatically display the final result? Why would anyone want to set up a game board when we can instantly instantiate it? Well, because these moments, with all their friction, are the fertile ground for rituals to emerge. And with rituals come meaning.

We could then argue that by stripping away friction in video games for the sake of convenience and streamlined experiences, we have removed a fundamental, sacred component of what makes games so meaningful and important. Rituals go beyond the game itself: they ground us in our humanity, forging connections with others through shared actions and meaning.

Replicating Physicality

Mimicking these complexities and moments of friction in a video game is a complicated task: asking players to set up an entire board by hand before each game will most likely lead to frustration and players dropping from the game entirely. Requiring players to count points by hand opens the field for cheating, and miscalculations, but also dead time. Allowing players to organize their board as they want in a card game will most likely lead to confusing tables and abuses, and letting players flip the game “table” is simply not acceptable.

Another issue is that many of these moments are directly linked to the physicality of board games, something naturally difficult to mimic in, well… a digital medium. But this doesn’t mean that there aren’t opportunities to take!

Take rolling dice for example. Many games reproduce this moment in various formats but often lose its physicality in favor of its pure functional purpose. Baldur’s Gate 3 introduced a beautiful UI for rolling dice which is not only extremely functional but also captures very well the excitement of seeing a die roll and waiting for its result. It’s juicy and efficient, and somehow replicates the physical aspect of dice (the rolling animation in the window) but, to me, it still feels artificial: it is the game that is rolling the die, not me, and as a result, I feel less connected to the moment, less in control.

Now let’s take the latest installment of Monopoly by Ubisoft: players can aim dice, and shake them. This may feel minor, but this feature truly connects players to their throw, it puts them in control. The fact that dice roll on the board, are affected by physics and collisions, and can knock pieces down is another excellent addition, opening possibilities for rituals to emerge (magic – knocking pieces down is bad luck and dice bouncing on board elements affects the result negatively, decorum – knocking down another player is rude and bad form, etc.)

Mimicking the potential of physical elements is often underused and could lead to more engaging, immersive experience. Take cards for example (MtG, Hearthstone, etc.). What if players had the choice of how they wanted to put their cards down: tap for a normal lay, double tap to flick the card on the board, hold to slam the card… Allowing players to convey emotion and intent in these moments could really elevate a game! Putting a card down, as insignificant of an action, is actually filled with intent and depth.

But only trying to replicate board games would be short-sighted: video games are their own unique medium, and many games already opened the way for ritualistic play in new, innovative ways.

Video Game Digital Rituals

If we look at the history of video games, we can actually find quite a few examples of unique, medium-centric rituals:

At this point, you may think that this feels random, with many of these examples just lucky occurrences born from big communities or dedicated players, and very difficult to design consciously. There is some truth in this, but this would be missing the point: your role as a designer is to create the ground, the fertile soil, for these rituals to emerge. Ritualization will arise naturally from player behavior, community habits, and repeated engagement. But for this to happen, we need the right environment, and it is your responsibility to create the conditions for them to flourish.

And designing this favorable environment will revolve around carefully balancing 2 key elements…

Freedom and Constraints

The first important step is to give your players freedom and space to express themselves. Seems straightforward enough, but these are often the first cut features in development, and for a very good reason: this freedom often occurs in non-key-gameplay moments. Think pre-match warm-up, victory showcases, hubs, secondary communication features… The games would often function just as well without these but, as we discussed, only considering the pure functionalism of games is often removing part of its soul.

Take Deep Rock Galactic for example: my memories of my time in DRG are as much about its hectic gameplay as it is about everything else around it: the mandatory beer before deploying, the victory dance after it, the flare spamming, “Rock and Stone!”, etc. All these moments could have been removed from the game to save time and money: a 3D hub is very costly compared to a UI matchmaking interface, a beer-drinking feature as well… And yet, I am deeply convinced that these seemingly minor features are what created a deep player engagement and made this game so successful: it built lore, made belonging and community emerge, and pretty much ritualized the game experience.

But, interestingly enough, Freedom isn’t enough: when everything is possible, nothing happens. Possibilities are infinite, and chaos isn’t favorable for rituals to emerge. We need to frame this freedom, to contain it enough in scope and moments.

We already took many examples of specific moments (pre-match, post-match, starting of a duel, specific game phase…), but the scope of each feature is just as important. Take communication for example: when limiting the words, and combinations of words players can use, they are forced to project meaning into it, to be creative about their usage.

Elden Ring is a beautiful example of a communication system done right.

• Limited vocabulary created jokes that evolved into community-driven traditions (much like an inside joke in a TTRPG). Ex: “Behold, dog!” used to describe anything, from turtles to dragons.
• 3D placement of said message, becoming part of the ritual and creating extra meaning to these messages.
• Finally, an upvote system reinforces the meaningful messages and pushes them to more players in priority, cementing their legitimacy and spreading their reach.

The key here is to limit expression just enough to guide player-made traditions while still allowing personalization and unicity.

Take Away

I am convinced (and hopefully now, you are too!) that the ritualization of the player experience is one of the keys to powerful, long-lasting player engagement and meaningful, fundamentally human experiences. Video games, historically, tended to destroy the elements creating this fertile ground, but we start to see more and more games introducing features that directly feed this deep connection to the experience.

Should you want to work on this aspect for your games, remember these points:

• Emergent, not developer-created: you can’t force rituals, you can only create the conditions for them to form. Rituals arise when players find meaning in repeated actions.
• Shared meaning through repetition: a ritual ground itself, and become powerful, when repeated and recognized by a group. Habits become rituals, and rituals become shared traditions.
• Stronger through time & participation: support long-term engagement and features allowing rituals to spread organically.
• Foster Freedom: give players the space to create their own rituals. Allow them to physically interact with the game world and their peers. Let them own their experience.
• Engineer Constraints: provide just enough structure to frame the possibilities. Constraints lead to shared meaning and expression.

Great game experiences linger not only in their mechanics, but in the rituals they inspire — those unspoken traditions that turn play into something personal, communal, and timeless, and invite players to be part of something greater than the game itself.

Praise the Sun!

Did you enjoy this article? If so, please consider supporting GDKeys on Patreon. It helps keep this place free of ads and paywalls, ensures we can keep delivering high-quality content, and gives you access to our private Discord where designers worldwide gather to discuss design and help each other on their projects.

Games, like any creative endeavor, are naturally prone to unexpected developments: we are all too familiar with games being delayed or straight out canceled. Unlike more traditional software development processes, game developers cannot simply follow a pre-established roadmap and expect to stick to it and ship as planned. Every game must find its soul, what gamers call “the fun”: the magical ingredient that will make everything click together, and this elusive goal cannot easily fit in a 2-year retro-planning.

This reality brings an enormous amount of chaos, and a lot of uncertainty, in the development process. Shipping a game takes nothing short of a miracle, and I have never heard of an easy, straightforward development (even ‘simple’ reskins, straight porting, remasters, or asset flips, bring unplanned surprises).

It then makes perfect sense to try and control this chaos: throw an army of producers, pipelines, and processes at the game, and try your best to stay on course. This approach usually tends to be met with skepticism and dubiousness by designers and creatives: how can you put a time and cost on a creation? Or break down an art piece into stories, weights, value delivered, and sprints?

Well, I thought like this for many years and gave a hard time to my producers before realizing that a proper game development process, and the milestones I would be passing, actually structured my creation process. It always improved my designs drastically and helped me get out of the endless cycle of iterations. Even as a solo dev, putting together and sticking to such a pipeline (even drastically simplified) brings structure, and ensures your development is mindful and building on strong bases, one milestone after the other.

In this article, I will break down what to me is a classic, efficient game development process, and discuss its various milestones: What should they contain, what should they not, what can they tell us about our designs, what are the risks associated with each of them, and overall open the floor to how we can improve this process.

A Typical Game Development Process

Every game is unique, and slapping a one-fit-all approach to a game development process is dangerous. That being said, our industry tends to like the 2 to 3-year productions (enough to produce solid content and innovative games, not long enough to freak out investors, raise your break-even to impossible heights, or risk missing a trend). Companies also tend to agree on some generic milestones, so this is what we will be considering for this article:

These 2 timelines represent what I consider to be a great start for a video game pipeline:

• First, the Conception phase: an exploration period, here to clarify the direction and promise of the game.
• Once the game’s vision gets clearer, a small and focused Pre-Production will refine topics like scope, pipelines, core gameplay, and feasibility.
• Then comes the actual game Production, where most of the game’s content is created.
• Finally, a healthy Polish period, clearly separated from the Production, to bring it home.

Of Note: every studio will have their own Pipeline: Milestones (Beauty Corner? First Playable (FPP)? Demo?), Phases (Pre-Alpha? Content Lock? Gold Candidate? Day1 Patch?), and Timeline: do not be phased by it as they all roughly translate to the same logic and adapt to different projects and teams (size, structure…).

Flexible, Low-Cost Conception

One thing you may have noticed is that I didn’t put a timeframe on the Conception phase (the timeline starts at M+0 after the Conception Phase). This is done on purpose as Conception is the most chaotic and unpredictable phase of a game’s development. Usually done using very small, surgical teams, often during the Polish phase of the previous game of the studio, they can take a few weeks up to several years (not recommended, but not unheard of). Conception usually ends with a “Kick-off”, sealing the deal on the game’s vision and officially starting the game development: the team would then slowly grow to its cruising size and the game would start taking shape at an exponential rate. This is the reason why I like not to consider it in a typical game timeline, but feel free to disagree.

It is quite common in big studios to have multiple games in Conception at the same time, a cost-efficient way to explore multiple directions before committing a studio to a direction for the next years.

Laser-Focused Pre-Production

Another interesting point is that even if the Production phase doubled in size between the two scenarios above, the Pre-Production phase stayed constant. This take isn’t unanimous but is an important one for me: too often, teams use Pre-Production as early Production, jumping into content creation and hitting walls later on. Pre-production must stay contained and as laser-focused as possible: it is here to confirm that 1) your team has the technical, artistic, and workload capabilities to make this game, 2) to prove that your game’s vision and core loop are valid (will the game be fun?) and 3) to define the scope of the Production phase.

Scope-Aware Production

The Production phase will be the longest of all: it is during this phase that most of the game’s content will be created. The main danger during this period is Scope Creep: Pre-Production concluded on a clear and actionable scope, but video games being video games, this scope will continue changing during Production: new opportunities, Playtests results bringing new considerations, great new ideas… I’ve never seen a Pre-Production scope being the final one, and it shouldn’t: great opportunities arise, and acting on it may greatly improve the game! But this is also the main reason why games get delayed: if new features go into the game, some of the current scope must go out of it. Refining the scope, trimming the weeds, and crystallizing the core experience will be the main challenges during Production. Be smart about it!

Healthy Polish

This point will sound like a no-brainer, but I have yet to find a team that managed to respect it: it is critical to leave a healthy buffer at the end of a production, where the entire team can be focused on polishing the current content instead of producing more of it. Usually, this phase is used as the buffer for all the slip-ups that happen during production and is almost completely eaten. This is a mistake, do not do that (yet I keep doing that most of the time -_-‘): prefer to cut some content or features that couldn’t fit Production and properly polish the existing. This is often the difference between a great launch and a bug-riddled mediocre one that leaves you scrambling for months trying to appease grumpy players.

That’s why the Polish phase of my timelines lasts for 6 months so that even if you waste 2 months of it for extra Production (because you won’t resist, been-there-done-that), you still have 4 solid months to make it work!

But enough of this: this is a design blog after all, and I’m fairly sure I lost quite a few readers already (though this is a fascinating discussion that I am more than happy to continue on our Discord!). So let’s now focus less on the phases themselves, or their duration, and more on the key deliverables of this game development process, and I will focus on 4 of them:

• Prototypes / Proof of Concept
• Vertical Slice / Horizontal Slice
• Alpha / Feature Complete
• Beta / Content Complete

Prototype(s) / Proof of Concept

Prototypes are a big topic: what should you prototype? How much effort should be put into one? Is it always low-cost or some prototype should try and shoot for more visual fidelity and polish? When to stop?
Well… It all depends on what you want to prove!

• Experimenting with a combat system would require quite an expensive prototype: a basic character, specific 3Cs, a Gym to test, and few enemies or dummies to fight against.
• Prototyping a progression system could be as simple as making a physical prototype, using index cards, like a board game.
• Proving an art direction could be done with mock game screens or a demo scene with unique shaders, materials, and assets.
• Validating a narrative tone, or mood, could be done using a visual novel: a few key arts and dialogues, or a cinematic quickly put together.
• … The possibilities are infinite and not limited to what can be done in-engine!

In the end, choices will have to be made. What aspects of your game must be proven, be it because they are very novel, a challenge for your team to create, or an element so central in your core loop that failing to deliver on it would jeopardize your promise?

In my current game, The Snackbar at the End of the World, we identified 3 critical topics to test:

• A polished, approachable combat system: being a very small team, making a compact, yet very juicy combat system is a challenge. It is also one of the key aspects of our game promise. We needed an in-game prototype! Using sprite banks to put together enemies quickly, and grey-boxed levels, we put together some of the 3Cs foundations and iterated directly in-engine.

• An evolved dialogue system: our game will come with a whole bunch of text to read, mainly through dialogue: I needed to find a UI representation and UX paradigm that ensures a pleasant and immersive reading experience. For this one, I went for an Adobe XD prototype: fast to iterate and very close to an in-game experience (it supports gamepads).

• Finally, our game innovates on the cooking section by proposing a micro-gameplay centered around a deck-building mechanic. This is a novel approach (no real benchmark) that naturally imposed some experimentation. Before even trying to represent it visually, I made a physical prototype using blank playing cards (a cheap component), which I later transformed into a Tabletop Simulator Prototype. This allowed me to experiment with many rulesets (currently at iteration 8!) at very little cost.

In the end, all these prototypes and research should work towards the proof of concept of your game to enter Pre-Production:

• Is your game vision consistent, novel, fresh, and/or exciting?
• Does your team have the capacity (number, capabilities) to realize this game?
• Are the most dangerous parts of your promise de-risked as much as possible?
• Are your systems and core designs flexible enough so they can be built upon, reworked, or reshaped easily without endangering the project?

Do not underestimate this phase: making prototypes, iterating on them, throwing them away, and making new ones is cheap and fast, especially compared to the cost such decisions will have during Production when a full team will be spitting content in a constant flow and when shifting production will be close to impossible (or incredibly costly both in terms of time and money).

Vertical Slice / Horizontal Slice

Let’s imagine that you have been working for some time on your game, and during the “Kick-off meeting” your project (thanks to your prototypes) has been greenlit and is now “go-to-production”. Great news! Your game shows promise, it seems viable (money, time, resources, market), and you are ready for the next step: Pre-production.

This is the moment where, with a bigger team (but usually not the full team), you will be tasked to “prove the fun” on the game scale, while also solving all the biggest questions of the promise. At the end of this Phase, you and your team should have a crystal clear vision of the game and can hammer at the content without thinking (too much) anymore. Or at least this is true on paper! But we will get to that.

The deliverables for the pre-production could take 2 forms: the most well-known Vertical Slice, and its lesser-known sibling, the Horizontal Slice:

If you are not familiar with these terms, here’s a breakdown:

• A Vertical Slice takes a small slice of experience from the full game (20mn to 1h depending on the game): this slice will be as complete (no missing core feature or content) and as polished (no placeholders, first balancing) as possible. The rest of the game, outside of this slice, will be ignored: usually all side systems, onboarding, end-game, etc.
  Example: If you were working on the latest installment of the Call of Duty campaign, a Vertical Slice would represent one of the game’s missions or even a few checkpoints of one of these missions only. No progression systems, no unlocks, no menus… Instead, only a few weapons, enemies, and tools, and a very contained level design and level art.
  I strongly suggest putting your Vertical Slice right after the game onboarding (cf. above graph): this is the first “non-guided” experience (aka ‘Real’ one), but early enough so little systems suffice and the core of your experience can be tested.
  
• A Horizontal Slice is also taking a slice out of the game, just a different one. Instead of focusing on a Release-quality micro-experience, it will focus on representing the entire game in an extremely rough state: the game’s entire loop and all its core systems must be present, and ‘testable’ in their bare form, but no effort will be put in providing polished content or a really “clean” experience.
  Example: If you were LocalThunk, working on Balatro, you could very much want to assess the replayability of the game on long sessions, with a hundred or more jokers, full random runs, and all systems present, instead of the same “1 run, 5 jokers” loop. In this case, you would focus your efforts on a Horizontal Slice, with barely any balancing, no Juice, and maybe even no art, just to try the full-scale game engagement and retention before investing in the production of any proper content that may be discarded.

Why Choosing a Vertical or Horizontal Slice?

In 90% of the cases, you will choose a Vertical Slice. Why? Because a Vertical Slice lets you:

• Prove your pipelines (art, tech, design…) from start to finish, ensuring that you have as little unknowns as possible regarding producing content.
• Produce release-level content on a small scale, which lets you project on the cost of scaling this for the entirety of the production. It’s an invaluable metric to enter production confidently.
• Creates a small, contained, finished product: you could use this Vertical Slice to convince investors, showcase your game at conventions, create a demo for your brand new Steam page, or organize playtests with external players.

Most games can follow the “if it’s fun for 20mn, it will be fun for 20h” logic: this is the approach we are taking for the game we are currently working on.

Now, this is not true for all games: extremely systemic games (engine-building games, CCGs), for example, but plenty of other genres (Metroidvania?) may not shine much with so little content and systems, and without having players projecting their experience on extended play sessions: opting for a Horizontal Slice may be the soundest decision to properly judge the overall player experience. It is way rougher, less player-friendly, and will prevent you from using this for the other purposes listed above (apart from having a group of players that can see past this, like our community).

It is worth asking yourself this question while developing your game, as this decision may truly help you while moving into the Production phase.

Alpha / Feature Complete

The Production Phase is slightly more peculiar, as it contains 2 distinct key deliverables. The first one is often referred to as “Alpha”, though I prefer the more straightforward term of “Feature Complete” and usually happens at around 2/3rd of the Production phase.

This deliverable’s content is pretty straightforward: every single feature of the game is in the game, fully developed: menus, UI, progression systems, weapons and combat systems, biomes transition, analytics, loading screens, tooltips and onboarding, game credits, accessibility options, adaptative music, rumbles, boss fights logic, randomizers, player abilities… Everything! The content is not fully there, and much is still in a pretty rough state, but it exists and it is testable.

The goal of this deliverable, and why it is important to try and get to it as soon as possible is to raise the final flags, and solve the last unknowns: it is very easy for systems not to fit with one another, create unforeseen issues, or just not performed on the game’s scale as it should. Typically, this is one of the reasons why games get delayed, and why every production pipeline focuses on features before focusing on content. Content is safe, content is plannable without (much) surprises. But features, and the final player experience, aren’t.

By Feature Complete (or Alpha), you should be able to run your first full-playthrough playtests without much player assistance and to project fully on a multitude of metrics: player engagement, repetitiveness, short-medium-long term motivations, difficulty, complexity and onboarding, and total game time.

Beta / Content Complete

Finally, at the end of the Production phase, is the last big deliverable of the project before Release: “Beta” or, as I prefer, “Content Complete”.

By this time, not only every feature but also the entirety of the content is in the game. It is a finished product, still with rough angles, but a finished product nonetheless. This build is the easiest to work with it has ever been: it could be used for Beta tests, “Friends & Family”, and possibly even ready for Steam Early Access (though I need to warn you, EA these days means nothing like the EA from the past and is a dangerous game to play).

At this stage you should focus on identifying where are the rough angles of your game: maybe a segment of your game falls flat and is churning hard, or a build is completely OP, or a system is considered subpar by players and simply ignored. Maybe your players missed a critical point of the game due to weak onboarding and are ruining their experience, or a lack of S&F creates blockers for players and excessive frustration… Whatever it is, your game will for sure have problems, and this is why identifying them AND having enough time for polish is critical. Not everything can be flagged by QAs (after all, they know the game by heart at this point, and a brand-new player experience is difficult to replicate).

This transition to Polish at Content Complete is also a good moment to turn to extreme agility: ship fast, often, and be surgical on your tweaks and improvements.

Many studios either minimize this Polish period, leaving only 2 months or so for bug-fixing, or shoot themselves in the foot, by having to cancel most of the Polish phase due to content still not being ready (and their inability to cut content). Also, this will be the moment when certifications are happening, and if you are targeting multiple platforms at Launch (particularly if you have console makers involved), you will become so swarmed that Polish will be forgotten in light of more pressing urgencies. Be very careful, as usually a great Launch (and a few extra Metacritic points if you care about it) are at stake here.

Extra Glossary

As I told you, every studio has its pipeline and way of doing things, and the terminology used in milestones can vary widely. Below are some extra terms you may encounter. Do you see extra ones I should add? Ping me!

• Beauty Corner: or beautiful corner, is a small area of the game (a room, a settlement, a bit of forest, a vista…) showcasing how the game will ultimately look like. Not too far from a Vertical Slice, but for the art and LD pipeline, it can be helpful in selling the game to publisher, nailing an art style “in-engine”, or challenging the processes and cost of developing a contained art segment of the game. Usually, Beauty Corners are not playable.

• Gym / Test Room: not a deliverable per se, but some studios consider them as such. These are test scenes, in-engine, used to demonstrate, prototype, and experiment on a specific game aspect (combat Gym, Level Design metrics, etc.)
• FPP / First Playable Prototype: a very common deliverable. Consider an FPP as the aggregate of all the prototypes done in Conception, into a single global proof-of-concept prototype. They are usually used as the deliverable to enter pre-production. Very useful in big games where many separate prototypes aren’t sufficient to confidently approve a game’s direction.
• MVP / Minimal Viable Product: a deliverable that is not part of our industry. Compared to other IT industries, it is very complicated to ship a barebone game and improve on it Live. I have seen this term used to replace the FPP or to guide prototypes on specific topics, but this is a rare occurrence. I would suggest not using it as it can be misleading.
• Pre-Alpha: used often as the deliverable’s name for the Pre-Production deliverable. I prefer the term FPP as it is more relevant to our industry. I also saw it used for many other Pre-Production or early Production milestones, often to say “ignore the rough patches” to investors, publishers, or players.
• “Locks” (Art Lock, Audio Lock, Design Lock, Animation Lock, etc.): these are many terms used as lesser milestones close to release. These Locks usually happen on massive games that imperatively need to stop production in a contained manner to stabilize and secure a game before Launch. When a department is in “Lock”, it usually means that nothing gets produced anymore, and the only work done is final debugging and fine-tuning realized in an extremely controlled manner and triple-checked. The mother of them all is the final “Content Lock”, the bridge toward Certifications.
• Candidate / Rollout / Gamma, Delta…: as a game is getting close to release, particularly when this game is multi-platform (and involves console makers) it needs to conform to massive lists of requirements that will need to be approved by third parties. Studios then create “Candidate Masters” that hope to become Gold. Some studios call this period the Rollout period, others continue the Greek alphabet after Beta… I like the term Candidates, it’s clear for everyone.
• Gold: when a Candidate Build passes all platforms and publishers’ requirements, it becomes Gold. This is the version of the game that will be printed on disks, or released on digital platforms. Legends say that the term Gold refers to the color of the disk the final game was printed on (though I tend to believe it the other way around, as I always had Gold Master disks as plain CD-ROMs).

• Zero-day / Day-one patch: though we are crossing into Post-Launch territory (I have a great article on this here), the Day-one Patch is often the last milestone before Launch. Once the game is Gold and is being distributed/deployed, we are still 2 months or so before the official release (deploying, manufacturing, and shipping games take time), which is 2 months more available to work on the game! With the current technology allowing us to push patches to players, it is common to use these extra months to fine-tune the game even more and deploy an update that players will download the day of the Release (“day 1” of the release). Just make sure not to be too greedy with it…

To conclude this article, my key pieces of advice would be:

• Even as a solo dev, a pipeline, and timeline can help you structure your development and not end up blindsided by issues you haven’t foreseen.
• A production Pipeline is not playing against creation: use it to your advantage, as each milestone will funnel you toward releasing the game, and it’s a good thing!
• Be open-minded when you are prototyping: not everything requires a prototype in-engine, and sometimes a deck of cards and a stack of Monopoly money is all you need.
• Vertical Slice or Horizontal Slice: choose carefully which one is more suited for your game, but also what you choose to include in these slices. They can be an invaluable tool (even sometimes for PR and marketing!) if properly scoped, or a fake sense of security that later backfires if badly constructed.
• Focus on shipping all your Features before shipping all your Content: this is where the dangers lie.
• Give yourself enough time for Polish! Whatever time you give yourself won’t be enough in the end, and you’ll regret not cutting a few more features to ship a cleaner, more polished game.

Good luck out there and, as always, let’s continue the discussion on our Discord!

Did you enjoy this article? If so, please consider supporting GDKeys on Patreon. It helps keep this place free of ads and paywalls, ensures we can keep delivering high-quality content, and gives you access to our private Discord where designers worldwide gather to discuss design and help each other on their projects.

When I started in the industry, times were simpler: the moment your disk was burnt and the final build sent, this was out of your hands. The disk would make its way straight to the factory, printed in dozens of milli… thousands of copies (simpler times I told you), and then right to the shelves ready to be purchased and played. Bugs that weren’t fixed would become canon, and memes years later, dominant strategies would find their way on the cover of the latest paper magazine issues under titles like “The easiest way to beat X explained!”, and once players had their fill of the game, they would just move on to the newest hot release and share the now discarded game with their friends.

But this was before. Our constant technological advancements opened doors nobody could have dreamed of at that time: doors that would be blasted open by Capitalism, because this is what businesses do. See, when a player drops your game to start another one, this is a lost customer (or a potentially lapsing one based on your optimism), a customer you spent months (and bags of money) convincing to spend their pocket money to give a chance to your game. This is closing all possibilities for extra monetization, for brand devotion, for easy content that would just build on the insane work that was released beforehand, for milking whatever could be milked. This is a big loss, and worse: a loss to other games from your competitors! And this isn’t acceptable.

“Hey, you aren’t that old!” you’d tell me (thank you! I’m not indeed!), “During your time you could already ship Expansions”. True. And this was helping for sure. But an Expansion still requires a consequent amount of work and content if you want to package it again with a decent product value, and the more time you put into these Expansions, the more players are dropping: this is trying to stop a flood with duck tape. This doesn’t mean that it is not a valuable approach, as demonstrated by games like The Sims, Flight Simulator, or Cities: Skylines, games with extremely high replayability where content packs make total sense and is proving extremely profitable by offering a “menu” approach of their content: buying the entirety of Train Simulator 2020 and all its DLCs will total not less than 12k USD after all!

Fast forward to the last decade. Enters connected hardware, and the possibility to update the game, fix it, and release more content for it on the flight. This has been the revolution you are now way too familiar with, as all of you heard about “Live games” (you clicked on this article after all), “Game as a Service”, and even maybe “Game as a Platform”. The sky’s the limit! We now can better the game, tune it, polish it, and improve it forever in order to create the true masterpiece it was always meant to be! Nah, just kidding: we can now keep our players forever in our games, creating a deep bond with them inviting recurring purchases and IP loyalty, and as long as we can drip-feed them cheap content, the sink-cost fallacy will do the rest, until the next installment of the IP comes out and a final event funnels your players to the new shiny content. The future is bright!

“Damn man, you went dark real fast”. Well, it’s the internet, if I’m not sensationalistic a bit, nobody will read me. But the business desires are strong, and Live games are a reality that not only will stay but keep growing. The good news is that this can very much serve the games in the long run. By working not only FOR your players, but WITH your players, you now have the possibility to tackle every short-coming and oversight your game had at launch, as well as truly engage with your communities: The Division 2 is entering its fourth year, as a solid player base still, and is going to bring new game modes and content that keeps expanding the scope of the game for all, free of charge. Destiny 2 latest content drop, 5 years later, is diving always deeper into their amazing Lore. Rainbow 6: Siege, which had a rocky launch 7 years ago, is now played by millions of players and regarded as one of the best competitive shooters on the market. Fortnite is now less a game and more like the hot 3rd place (the social one, on top of work and home), hosting concerts and being not only trendy but trendsetters. They broke the concept of Live games to become a ubiquitous platform. There is a real opportunity for developers to keep adding love to their games without having to make (too many) sacrifices.

Now to the point of this article: being a “Live” game doesn’t have to be reserved for big studios as it’s often the case, and distributing platforms are making it easier every day to adjust, update, and submit new versions of your games. This is quite an opportunity, and it is worth considering it ahead of your launch. But where to start? How can we plan on the unplannable? How to know if this is worth it, and when to stop? To answer all of this, we’ll need to start with the harsh reality: what can we even afford?

Team/Studio Capabilities and Resources

Keeping a game alive for an extended period of time is an important risk, and not only for multiplayer games with server costs: every developer you keep on a game is a developer that can’t work for a future project, and worse: it’s a developer that needs to be paid, which further grows the original game’s budget (and even as a solo dev, your time is money). Any plan for content must then account for its return on investment: how will these extra efforts bring value to your studio/team? It can be short-term focused, like selling DLCs, or content packs and items inside the game, medium-term, hoping to bring more full game sales by showing your commitment to support the game and its players in the long run (and get coverage with it), or even long-term, hoping that the immediate loss will transform into trust and goodwill overtime outside the game, and towards your entire company (obviously for companies having/planning more than a single game).

You probably noticed that I approach this topic from a rational business perspective, and didn’t touch the obvious “How about making my game better, just because I love the game I made?” which is common in the indie scene. Well… This is really a question you’ll need to answer yourself, as every developer has a different relationship and goals with their game, as well the number of sacrifices they are willing to make for the art and craft.

Now, let’s say budget and profits/funding are covered, and you can confidently plan for the long run without risking the future of your studio, there are still two very important aspects to consider: your team capabilities, as well as your game capabilities.

Team-wise, this is pretty straightforward: you need to answer the question “What can we produce with our current team?”. And many teams fall into this pit. A new narrative arc will require writers, translators, and possibly a cinematic team. A new game mode will require game designers, a bunch of GPPs, UI designers, and possibly level designers and environment artists should the mode require a new zone. Even something as “simple” as extending an existing progression system will require balancing, UI work, exposition, and a whole bunch of other things to be packaged into a full proposition. Understanding what you CAN produce before even talking about what you SHOULD produce will help you tremendously.

Finally, the last aspect to consider is what you can produce using your game, which is another pitfall easy to fall into. It is very likely that at launch your game will have a consequent technical debt. It will be very efficient on some aspects (say adding new cards in a CCG, or new gears and areas in a hack ‘n slash) but terrible in others. Deciding to add an online coop feature to a solo game or a fresh feature for a game not having the technical structure for it may very much drive you under.

Alright, let’s take a step back. We now have a game that is slowly heading towards launch, we know there are clear opportunities for us in post-launch, and we precisely identified what budget we may have (or hope to get back), as well as the resources and tech capabilities we may play with. That’s a terrific start! Now what?

Now? We look at our players.

Players’ Targets, Motivations, and Consumption Specifics

The key KPIs that interest us here are the Players’ Retention and Engagement (Acquisition and Monetization are critical as well but fall outside of this article’s scope): keeping players excited, driven to play for extended amounts of time, and preventing them from dropping (reacquisition of a player is pricey). And to do that, we need to deeply understand our core targets.

Throwback to the article on Players’ Motivations, every player has very different desires from a game, motivations for playing, and consumption patterns: some are completionists, some are driven by the fame and pride of being able to show off their best gears and skills, some just want to socialize with friends, or really get to know what happens next in the story… And some just want a quick play session to unwind at the end of the day. Understanding who the players of your game are, and what will make them stick to your game, is key. Without access to a dedicated marketing team, you can still approximate this: what kind of games are similar to yours? Can you study their community, can you ask yours? This is important as this will not only help you see what kind of content would engage your player base but also will help you approximate their consumption of your game and start to lay down your roadmap.

Remember that analytics built in your game will be invaluable, but only when your game goes Live obviously.

Let’s imagine that your game is roughly 40 hours long and that your average player will play 10 hours a week (your game structure can help set the play sessions duration). An easy calculation will show you that roughly a month after launch will be the perfect moment to drop some extra content: this will keep your most engaged players in the game at the moment they start extinguishing the current content, as well as encourage new players to join (possibly piggy-backing a price promotion for an extra push). Now if this content push is 10h long, then you can predict when it will be exhausted as well, and the cycle continues.

Now, I can hear you already: “Man, I’m not gonna push new content every damn week, this is insane!”. Well, first of all, I never said this would be easy! But also we can be smart about it.

Creating Content: the Smart Way

You are completely right that pushing “high-cost / fast-consumption” content in your game every week is not sustainable. If it takes you 2 weeks to make a new cinematic that will last 20 seconds of playtime, you can’t possibly include one in every patch you make. But this would make for a terrific reward at the end of a season, as Fortnite demonstrated over and over again for the past years.

So, for 95% of our new content (playtime-wise), we are instead looking for a “low-cost / slow-consumption” type of content. And this can be summed up in one word: Replayability.

I am a firm believer that the only sustainable way to operate a Live game is to incorporate as much replayability in the content produced as possible. And there are quite a lot of ways to do so! The most common way you may rightfully think of is competitive gameplay: the moment other players create the challenges and constantly fresh situations, you are looking at a potentially infinite playtime, and this is why PvP games are so often Live games (or at least why they have it easier than others). Talking about user-generated content, UGC features can play an incredibly powerful role in your retention and engagement metrics as well, like modding or game creation and sharing like in Super Mario Maker 2 which currently displays 10M+ courses, and more than half a billion level played!

But these are far from the only ways. Destiny 2 and The Division 2 are two examples of games that, on one side, use RNG and loot tables to artificially increase players’ playtime, and on the other have long progression systems creating significant grind. The Binding of Isaac has created a solid replayability loop by adding new objects, bosses, and zones at a minimal cost and targeting end-game players in order to delay the need for new content drops. Many PvE games focused their Live plans on extremely demanding and difficult content to delay their burn rate, such as Raids. Advanced social features (guilds, clans, etc.) are commonly added post-launch to strengthen the multiplayer aspect of the game. And I’m sure you will find many more smart examples of content replayability!

Let’s look at a few examples of a year 1 roadmap from some AAA:

Rainbow 6: Siege, focused on a solid stream of content, reinforcing their core loop (more operators, more maps). This is smart as the pipeline to create such content is probably extremely solid at launch and should diminish the risks associated with it. Now, this example is a great one to talk about an aspect that we haven’t touched on until now: start preparing your post-launch plans before going Live! Shipping 2 new operators (models, abilities, animations, UI, balancing, etc.) a new map (LD, dressing, balancing, etc.), and new game modes, all that in 3 months, is insanely hard. Also, your entire team will spend the first months after Launch fixing bugs, patching crashes, and doing emergency balancing passes. So consider saving a few bits of content pre-launch to be pushed in the months after!

Hood: Outlaws & Legends highlighted this with a quite smart plan: they also went for a 3 months per big update approach, but the risks are minimized. The new map and new game mode arrive in the game very fast after the Launch, which is great to build engagement and their player base. Being such big chunks of work, those were probably secured months before and kept warm for the first “red months” of the game’s exploitation. After this first update, each subsequent one focuses on 1 big improvement (a new character, a new system), and reuses existing systems and cheap content for the rest of the update (events, new cosmetics).

Destiny (basing myself on the leaked pre-launch roadmap on purpose), focused on end-game content pretty fast (in-line with the motivations and consumption of their player base). They pushed a new raid every 3 months (the first one being probably created beforehand) but took a long 6-months break before shipping their first big Expansion which allows them to have a very strong content push. This imposes of course to have enough content already in order to keep players from dropping in the meantime: quite a risk.

As you can see, most of this content has been built on the existing game, making smart reuse of their systems, assets, and strengths. And many players may think that this is somehow lazy, or protective, as seen on social media after any update. But the reality? Exploiting a Live game is going to push your team to its limits.

The Trenches of a Live Game

Let’s take a typical example: you would like to prepare for the first year of your Live game. This year will be composed of 4 big updates, or “beats”, one every 3 months, each of them bringing consequent changes to the game (a new game mode, a new progression system, a new category of gears or modifiers to freshen up the gameplay, etc.). Included in the delivery of the patch will also be a multitude of “cheap” fillers to delay the big content over time and keep the players reconnecting from one week to another throughout these 3 months: a twist on an existing game mode, special promotions, increased drop rates on some items, special events, etc.

Seems reasonable, and in line with what the industry is doing already as seen before! Now let’s break these 3 months into real deadlines: you will have 2 weeks to dive into analytics, surveys, community feedback, and backlogs in order to decide on the content of the update and prototype a few ideas in order to isolate the final update’s scope. Then, you will have 6 weeks of development: this is extremely short and doesn’t leave space for any significant step-back. You then will have 2 weeks of tuning, debugging, and polishing, and the final 2 weeks will be saved for first parties’ submissions and various approvals to go Live. This, of course, does not account for the various tuning, balancing, and various bug fixing that should be done on the existing content already.

Not only there is no room for errors, but once you finally ship an update, it is already time to start preparing the next one… And this, every 3 months, for years should you have a successful game and keep committing to it.

But not everything is grim! Working on a Live game is extremely exhilarating. First of all, things move fast: there are no second thoughts, no doubting, you are constantly shipping content. After years of long development cycles, this is freeing! Second: you are working with your players: through analytics (don’t forget to work on implementing them during development, they will be extremely precious!), community boards, streaming services, direct contact… You are not working in the dark anymore, but are constantly revising plans in order to adapt best to how your game is evolving.

I’ve spent amazing nights in various War Rooms, with beers and cold pizza, checking curves and KPIs, watching streamers, and dreaming of what the game could become, and would do it all over again as long as I have the energy to do so.

Conclusion, Roadmap, and Flexibility

Considering your game as a long ongoing product-service can have terrific advantages in some cases. They can support your studio for years of steady incomes, grow your player base and game visibility, and legitimately be the most fun you’ll have working on a game, and I’d highly suggest to at least ask yourself this question before launching one. Your plans will of course be more humble than the ones I have discussed in this article, but they will be a powerful tool alongside the more classical ones (sequels, expansions, one-shot).

Should you ever want to try and ride the Live path (or simply consider some forms of post-launch exploitation), and to conclude this article, here are my few pieces of advice summed up:

• Start Early: shifting mindset is difficult, and a post-launch game needs to be carefully prepared before Launch.
• Prepare the first content drop before Launch: your first months will be hell polishing the game and discovering unplanned issues. Do not expect much development work to happen during them.
• Know your budget, your team, and your game capabilities: by carefully looking inwards, accessible and realistic plans will appear and you will avoid falling for easy pits.
• Focus on replayability: low-production, high-playtime content is key to buying yourself time to bring the next update to life while containing your game’s players’ drain.
• Study your players’ motivations and consumption habits: each game has its own targets, each of them with different desires and expectations from the games they play. Knowing them will help you build a solid Live plan and roadmap.
• Study Analytics: once your game is Live, qualitative data (Reddit posts, selected community, etc.) won’t be enough to make big decisions. You will need quantitative data (your game’s analytics) as well as the people to analyze them.
• Stick close to your players: learn to let go (reasonably) of your creative vision, and accept that your game’s future will now also be shaped by your players. Team-work!
• Be flexible: as your game will live, its context will evolve (new games on the market, different demographics entering your game, etc.). Try and stay flexible for change, both in terms of tech and creativity.
• Brace yourself: this is going to be tough, and the rhythm will be vastly different than the one you had before Launch. But this doesn’t mean you can’t…
• Enjoy the ride! These will be very exciting times. Make the best of it!

To continue on the topic: Six common mistakes when moving to live-service games and free-to-play

Did you enjoy this article? If so, please consider supporting GDKeys on Patreon. It helps keep this place free of ads and paywalls, ensures we can keep delivering high-quality content, and gives you access to our private Discord where designers worldwide gather to discuss design and help each other on their projects.

>> Link to the Interview <<

Full Transcript

Can you introduce yourself in a few words? 

I have been in the industry for a little more than 10 years now. My shiniest medals involve being lead game designer for games like Assassin’s Creed: Origins, Immortals Fenyx Rising, and The Crew, and currently being UX Director for Ubisoft Bucharest. A year and a half ago, I also started a design community, called GDKeys, aimed at providing first-hand advice on video game design and feedback for students, indies, and hobbyists who may not have access to this kind of support otherwise. We currently have more than a hundred creators supporting each other and growing! 

How did you start in the industry? 

When I started, the industry didn’t have the titles, structure, or processes that we have today, so everything was very organic. I was an industrial designer back then, working on connected objects and the Internet of Things, and got recruited as an “interaction designer” for one of the first Just Dance games. Interaction design was a position that today will encompass UX design, User Research, or even User Testing. In this period, the motivation and human side of an individual was everything: you are a creator? Do we get along? Then let’s make games together! It was a pretty exciting time when everything seemed possible. 

Considering your cross-functional design profile, can you tell us what motivates your design philosophy? 

I will talk mostly from a Video Games perspective but my points can apply to any digital medium. Even though we are all pretty versed in interacting with the digital world, we need to realize that the means to do so are still extremely rudimentary: how are we supposed to create immersive experiences when we interact with these experiences looking at a cold screen on a wall, holding a plastic box with 20 buttons cramped onto it? How can we make you feel like a Viking warrior storming England? A fresh farmer building a new life outside the city? How do we make you feel connected to real humans and build trust and bonds? This is quite a challenge.

Blending these two worlds, the physical and the digital ones is really a question that drives everything I create: this will be core in defining the MetaVerse and Web 3.0, in designing tomorrow’s connected devices, and in shaping every digital experience in the future.

How did you find yourself at an intersection between UX design and Game design in your career? 

UX Designer, Game Designer, User Researcher, UI Designer, Level Designer… Nowadays, we have quite the terminology and a fair amount of boxes. But we need to realize that these terms exist mainly to specialize the work on the enormous project we have today. In reality, we are all doing the same job: we are designers, we create products and experiences for living beings, and the qualities required and work processes are very similar from one title to another. We have a saying in French that is pretty dear to me and sums it all pretty well: “Le Design est du Dessin a Dessein”, Design is drawing with a purpose. So, in essence, Game Designers are UX Designers. And I wouldn’t be surprised if the title of UX Designer evolves, or even disappears in the future in favor of even more specialized titles. With this in mind, finding myself with a double hat UX/GD was logical and happened naturally.

How do you keep a focus on ever-changing UX design requirements and game design requirements in your workflow? 

This is a very interesting question. When you think of it, humans aren’t evolving that fast, so how come UX keeps reinventing itself over the years? In my opinion, this is due to the fact that we are still in the early ages of digital experiences, and digital representation, constant connectivity, omnipresence, and access to information are redefining what it means to be human on a higher level: social dynamics, individuality, motivations, sense of purpose… So, on one hand, we need to define what will be the digital human of tomorrow, to adapt to new usages, to embrace an ever-growing amount of people and cultures getting access to technology, and to follow new trends. On the other, as discussed previously, we need to remove as many frictions as we can between the user and the experiences we create: the industry-wide shift happening at the moment on Accessibility, and making sure no user is left behind, is an excellent example (and one I’m now so happy to see taking place). 

In your opinion, what has changed between the start of your career and today such that UX design has gained so much importance for the games industry as a whole? 

I believe that what happened in the Video Games industry is the same as what happened in the IT industry 10 years ago: we finally reached a point with technologies where we can create products for the users directly. When a technology is in its early form, creating something that works is the priority: users will learn how to use it, as inhuman as it is. Now that we have passed this point, and that the process of creating games, websites, or mobile apps is completely unbridled and free-form, we can finally use our energy on making more intuitive, accessible, accompanying experiences, tailored for the users, their humanity, and their limitations.

Can you tell us what common ground you find between UX design and Game design processes? 

As mentioned before, I firmly believe that UX Design and Game design are the same job at their core. This is reflected in the processes we use in both: target analysis, research, personas, mood board, empathy map, wireframes, low-fidelity prototyping, playtesting, iterations… Everything you know about UX or UI design can be used in a GD framework. Being a Designer permeates disciplines, and we have nothing to gain by putting ourselves in labeled boxes. I would argue that the process of designing a chair and designing a mobile app is the same. Different materials, different industrial processes, same goal: the end-user.

Can you tell us an anecdote or story from any of your projects that you are really proud of?

This anecdote will be a Game Design one, but I trust you will appreciate it from a wider Design sense. It was a few years back when I was lead Game Designer on Assassin’s Creed: Origins. We had to create a wide range of enemies to challenge the players throughout their experience and this was the moment we were tackling the design of the final bosses of the game: they, of course, needed to provide the toughest challenge and ask our players to give everything they have. 

One classic way to approach this design problem is to look at our players’ skills when the encounter happens and make sure we push the required thresholds to beat this boss: reflexes, coordination, endurance, focus, observation, resources management… But for one of these bosses, Akhenaten, we wanted to try something different, and not only challenge players’ skills but also an innate specificity of any human being: their sense of rhythm. I don’t know if you ever realized, but humans are wired to understand binary rhythms: “and 1, and 2, and 3, and 4. And…”. It is the first rhythms taught in school, the rhythms that are used in the overwhelming majority of today’s commercial music… And it makes perfect sense, we have two legs after all, and this sense of rocking back and forth is deeply ingrained within each of us. This human fact, of course, found its way inside Video Game design too. Almost every enemy you will ever cross swords with will be designed with these binary rhythms at their core: attack-attack-rest-rest, prepare-attack-back out-rest… It’s everywhere! Now, what if we were to bring a twist to this status quo and create an enemy built on a different kind of rhythm: a ternary one? And so we did! This enemy has been wired to be ternary: “1 – 2 – 3, 1 – 2 – 3…” and this messed with our players: they came out of playtest describing this boss as “weird”, “unpredictable”, “odd”, “dangerous”, “chaotic”. Even so, this is not a particularly challenging enemy on the players’ skills front, it is globally perceived as one of the toughest enemies in the game: all of that with a simple twist to make him feel less human to our human users (Trivia fact: Akhenaton was seen as an odd human, with conspiracy theories even regarding him as a proper Alien). 

What inspired you to start a community around UX design and Game Design? 

Video Games are booming. It is among the biggest creative industries, growing exponentially, and, every day, new aspiring designers are joining our ranks. This is fantastic news, but one that is weighted down by the relative lack of training, courses, theory, and resources available. Becoming a Game Designer today is a difficult thing, and I believe we have a responsibility to create these communities, and this theory, in order to teach the newer generation of Game or UX Designers everything they need in order to push our medium even further.

Live design analysis and critique session of member’s ongoing indie projects

I only became a Designer thanks to the numerous mentors I found on the way. If I can be one to other designers as well, then I’d have paid my debt! Pay it forward.

How do you hope to help students, hobbyists, and indies with your knowledge gained from working in the AAA games industry? 

Over the past 10 years, the industry has changed drastically, to the point where I can’t tell you for sure where it will be 10 years from now. We experiment, we learn from the past, we adapt to new ways of consumption and new lifestyles… But there are some constants in this equation, and if I can at least put them out there, and write down the tools, theory ,and knowledge that I have accumulated over the years, then anybody can build on it, twist it, or tear it down entirely to build something new. There is just so much to learn already! But my experience is actually only a small aspect of what makes this community so valuable in my eyes. Having more than a hundred creators in one place discussing Design, debating, growing together, sharing their games and discoveries, giving feedback to each other… This is where the heart of GDKeys is, and here I’m but an enabler.

What have you learned from frequently discussing with students, hobbyists, and indie designers that can be worthwhile to even AAA industry designers such as yourself? 

So much! Design isn’t a deterministic science, and there is an infinite amount of possible answers to the same Design problem. I am bringing my truth to the table, which I believe to be a pretty educated one, but so is everybody else’s. Every designer brings his own self, and all these different points of view, design philosophies, cultures, sets of beliefs, experiences, and desires collide and challenge the way we perceive things and view Design. This is what creation should be about, and we have so much to learn from each other.

What methods and processes of UX research and UX design would you like to make clear that seem high-budget and exclusive to AAA but can be done cheaply and be helpful for a low-budget project? 

Testing. Without a doubt testing. A game, a website, a mobile app… All of these only exist in relation to the user interacting with them. Without the user, there is nothing. With this in mind, developing a product without the users playing a role in its creation is dangerous at best, and foolish most of the time. There is a misconception that testing is complex, requires a lot of preparation and experience, and costs a lot of resources in order to get actionable results from it. There is some truth in this statement, but I believe that, with the right state of mind, carefulness, and humility, any user feedback will be better than no feedback at all. Make your friends and family test your product, ask Reddit, Twitter, complete strangers, put your game in physical shows or digital festivals… You will learn so much from it and your product quality will skyrocket. 

What advice do you have for individuals hoping to be UX designers in the games industry?

Do not see yourself only as a UX Designer, you are a Designer applying your skills to a specific medium, and everything you’ve learned from other mediums will be valid and actionable. Now you will need quite a fair share of new skills and experience in order to shine: join communities like GDKeys, get in touch with other Designers, play as many games as you can (whether you like them as gamers or not), from every genre, and deconstruct them, study them. You will start developing your own Design approach and purpose in no time, and where and how you want to be a Designer will become a lot clearer! 

What’s next for you and GDKeys? 

I have no clue, and I find this both exciting and promising: I have a whole bag of ideas and desires, but the video game industry is very fluid, so let’s try and be as fluid and learn to adapt and reinvent ourselves alongside this insanely cool medium we are working with. Who knows, we may cross paths at some point, on GDKeys or elsewhere, and share a beer, debate Design, or make a game together!

How can anyone contact you?

They can write me an email at [email protected]

Ultimately, the history of games is a very human one. And though games transformed and adapted at an extremely fast pace through the ages, human traits, psychology, and characteristics stayed pretty constant. This prompts a question: are the game from the past still holding up by today’s standards?

Of course, we can already answer pretty well this question as we have games like Go, Chess, Dice, or Mahjong that are still considered masterpieces today. But what if we could go even further back in time, back to the earliest board game in existence for which we still know the rules (or at least one set of rules, but we will get to that), and look at its design with our modern eyes?

The Royal Game of Ur

Let’s start with a bit of history, to understand how we managed to get access to this fabulous piece of game design.

We are in 1922. Sir Leonard Wooley, then archeologist for the British Museum, is excavating the Royal Cemetery at Tell el-Muqayyar (southern Irak today) on the site of a Sumerian city, Ur, founded almost 6000 years ago.

Among his discoveries figures not one, but five artifacts resembling what seems to be an unknown board game, dated back to 2600BC. These boards are of beautiful craftsmanship: intricate patterns, obvious symmetry, precious stones like lapis lazuli, and red limestone inlaid, adorned with unknown symbols which, though not saying much, could testify of the importance they held. Being the first appearance of this unusual game, it took the name of the place of its discovery and became known as The Royal Game of Ur.

These boards were sent to the British Museum, which still holds them on display today, and were pretty much forgotten about, game design-wise.

But then new boards started to appear in other excavations: Iran, Syria, Egypt, Lebanon, Sri Lanka, Cyprus, Crete… Not only was this game played across the entire Mesopotamia and beyond, but it was also crossing the ages: these boards proved that the game, in its form, had been played at least until late antiquity. The Royal Game of Ur is a game that has been played, with minimal transformation, for at least 4000 years! To put things in perspective, Ramesses, and Nefertari, would they had been playing it, would have already considered this game a relic of the past, something that has always been.

But did they even play it? You bet they did!

The picture above represents a wall painting from the tomb of Queen Nefertari, showing her playing Senet against an invisible enemy.

Senet? Another game? Well… Kind of. The game of Senet is a game belonging to the same family of board games, the Tabla games (containing games like Backgammon, or Hounds and Jackals), and that bears strong similarities with The Royal Game of Ur: 3 rows of squares, 2 players, 2 sets of pieces, marked sticks for dice… Actually, they are so resemblant that we discovered multiple game boxes bearing the Senet board on one side, and the Royal Game of Ur on the other, with a central drawer to hold the game pieces of both games.

Think about it: an Egyptian Queen was not only playing but has been buried with boards of the game you are going to learn to play today. If this isn’t amazing for you, I don’t know what will!

But we are now reaching the point in our story where the real issue lies: finding games’ artifacts is one thing, reconstructing how these games were played is a whole other problem!

Think about it… When games have been played for thousands of years, they become part of the common knowledge: everybody knows how to play them. Having someone wanting to go through the long process of carving a clay tablet to record rules that will be useless in the present time is highly unlikely. This is why games like Senet or Hounds and Jackals, though determinant in the history of games have unknown rules today (or a lot of guesswork based on the ancestry of these games and game specificities like board and pieces).

But, in the case of The Royal Game of Ur, something significant happened.

Historically, when games have been ingrained into society for so long, they tend to permeate every aspect of said society, to the point that they infiltrate religion and beliefs. When this happens, usually these games get a regain of activity as well as significant evolutions in a very short period of time, a few dozen years. This is the kind of event that is worth documenting: how a game is now of important significance in predicting the future, guiding a soul through the Duat, or conversing with dead relatives… And this is exactly what happened with The Royal Game of Ur!

In the early 1980s, Irvin Finkel, a curator at the Same British Museum holding the game boards artifacts, was translating clay tablets unearthed in the ruins of Babylon when this one appeared:

This tablet describes the spiritual significance and omens linked to the different rules and cells of an unnamed board game (predictions like “You will draw fine beer” or “You will become powerful like a lion”). It also describes some advanced rules allowing betting. Not only the rules were very descriptive, but the diagram of the peculiar shape of the board of the game was engraved on the back of the tablet. No doubt remained: this was the rules of The Royal Game of Ur!

You are looking at the oldest rule book in existence, a clay tablet that allowed Finkel to piece together how the game was played (or at least the variation at this moment in time). The mystical aspect of the game, as well as the significance of its patterns and recurrence of the number 5, is still lost in time, but at least now we can play it.

Game Rules

The Royal Game of Ur is a 2 player race game that is an ancestor of the Tabla games like Backgammon. It is still debated whether Backgammon evolved or replaced this game over the ages as a less luck-based, thus considered superior, game.

Like other Tabla games, the rules are pretty straightforward: launch dice (or an equivalent of dice) to find out how many squares you can move your pieces, and manage to have all your pieces enter, travel through and exit the board before your opponent does it.

The board is organized as shown below:

And here are the rules:

• Each player owns 7 pieces.
• Each piece must first enter the board, then travel all the way until the end of the path, and finally exit by rolling the exact number to jump out the board (last cell +1).
• Players will throw 4 dice that can result either in a “0” or a “1”. The original version uses 4 sided dice that have 2 points painted in black and 2 in white.
• Once the dice are thrown, a number between 0 and 4 will be obtained. This number can be used to move any piece by this exact number. Subdividing the number isn’t possible. Example: I roll a 3, I could bring a new piece on the table to the third position, advance any one piece by 3 squares, or make a piece exit the board if the third move makes it exit the board. If no move is possible, then the turn is lost. Also, moving a piece is an obligation if possible, which shouldn’t be a surprise for Backgammon players.
• The first 4 squares, and the last 2, are safe squares for both players (only they can have pieces there) but the 8 central ones, the Combat ones, are shared between players, thus putting pieces at risk.
• If a player moves one of their pieces on a square already occupied by one of their opponent’s pieces, the enemy piece is “eaten” and goes back at the start, outside the board.
• The 5 Rosace squares are Jokers: landing a piece on one gives an extra turn to the player, but that’s not all: a piece sitting on a Rosace cannot be eaten (applicable, of course, only to the center Rosace, making it effectively the best cell of the game).

And… that’s pretty much it! If you still have difficulties picturing the game (as is usual with written rules), I very much invite you to watch the following video, featuring Tom Scott and Irving Finkel Himself, who not only rediscovered the game but is also an amazing entertainer and pedagogue!

Design Study

Now that we finally finished presenting the game, its history, and its rules, it’s time to ask ourselves a pretty important question: is this game any good?

On one side, it has been played for 4500 years, which should be a pretty good indication that it is robust and well crafted, but let’s prove it by looking more closely at its different components, as well as the different players’ strategies this game creates.

Randomness & Control Over Luck

The Royal Game of Ur has a strong Randomness component. Players will throw dice at each turn to determine by how much, and if, they can move. The existence of Luck, as discussed in The Components of Timeless Social Games, is an excellent way to bring uncertainty and exciting situations in a game: it makes it feel more approachable to new players, it evens the field in terms of skills required and also creates replayability.

Though the game is very Luck-based (estimated 60/40, possibly one of the reasons why Backgammon took over) it is countered by the dice values and design. The game is played with 4 pyramidal dice. Each of them can result in a “1” if the upper tip is white, or a “0” if not. And this is an excellent design!

The game could have used a single 4-sided die, ranging from 1 to 4, with equal chances to land on any possibility. But the use of 4 dice brings key advantages: First, players can throw a “0”, which would make them effectively lose their turn and potentially shift the course of a game. But most interestingly, it gives each possible roll very different odds.

Let’s study this breakdown:

• 0 and 4 are the rarest roll, each sitting at 1/16 chance to come out. This makes epic fails, and epic wins, rare and meaningful.
• 2 will be the roll that will come out the most, at 6/16 chances. This allows strategies to emerge: having a piece 2 squares behind an opponent’s will apply pressure and force them to move or risk getting eaten.
• 1 and 3, at 4/16 chances bring enough range to create a fresh, surprising, and evolving gameplay.

The choice of dice (number, face values) is extremely important in any game involving luck as it will affect deeply the amount of strategy and control players will have. The fact that Monopoly uses two 6-sided dice creates odds that tremendously favor certain squares of the board (and arguably allows one to predict the winner after 2 turns around the board, but this is for another article):

So, luck (and its control) )-wise, the game is holding pretty well so far! It is also worth noting that Rosace squares are placed every 4 tiles on the board, rewarding epic “4” rolls with another roll right away. To add to it, rolling twice a 4 will place one of your new pieces directly on the center Rosace.

This gives us the perfect transition to talk about the board design itself and the different player’s strategies at play.

Players’ Strategies

The fact that not every square is a “combat” square (compared to Backgammon for example) allows for some neat strategies to appear.

Imagine the situation depicted above: Black has 4 pieces on each starting square. Doing so will make the first combat square a dead zone (any roll but a “0” will let Black take it), and globally prevent White from even entering the battlefield without a seriously high roll. On the other hand, this situation also closes a lot of doors for Black to move, and the next roll will force a move in the combat corridor.

Though the first squares of the corridor are the most dangerous, they are also the cheapest to recover from: losing a piece at the end of it could drastically change the course of a game and send you back multiple rolls.

With this in mind, let’s look at the central Rosace, the most powerful square of the board: not only a piece there cannot be captured (and can then stay here for an extended period of time), but it also forces the opponent to jump over it to progress, putting this piece in jeopardy of being eaten far in the corridor.

Pro-tip: if you have one of your pieces on this Rosace, leave it here until the moment to unleash hell comes.

Finally, the 2 safe spots at the end of the board seem like a perfectly good place to stay while fighting other fronts. This statement is true up to the point your pieces there will block the ones progressing through the combat corridor: nothing is more frustrating than losing a piece at the end of the corridor because your other pieces clogged up the exit safe spaces.

This following situation, for example, would be a very unfortunate one to find yourself in should you play Black, can you now see why?

All in all, the strategic layer of the game is deep, and full of micro-decisions and risk/loss-aversion moments.

Catch-up Mechanics

Another surprise is how well the game develops its own catch-up mechanics and makes every match a pretty tight and thrilling one.

As discussed previously, the eating mechanic combined with the exit squares getting crowded is putting pushy players at risk: the more pieces they push at once on the board without properly getting them out, the more a player falling behind has a chance to eat a piece well advanced on the board, which would send them back several rolls. These micro catch-up moments are actually happening multiple times throughout a game and equalize constantly the game field in some pretty dramatic fashion.

But now let’s imagine that a player plays very well against you, and gets very lucky on top of that: a “6 to 3” pieces out so far, a huge advantage.

In this case, the leading player will have only 1 piece left to win the game, compared to 4 for you. Sounds dire, but it is actually not that bad: having a single piece left means that your opponent is at the mercy of Lady Luck, without options anymore (and obligated to make a move if possible). On your side? You have 4 pieces to spread around the board to prevent any possible progress.

These catch-up systems generate very tight games, always leaving the possibility for both players to prevail at the end (and I’ve had some fabulous comebacks!). At the same time, though luck plays a very important role in deciding the winner, the strategic aspect of the game allows the best player to win most of the time.

Regional Variants & Extra Rules

An interesting aspect of these social games is the regional variants they generate, and how it affects the meta of the game. Though we unfortunately don’t know much about the game, we can at least trace back one variant thanks to another clay tablet (destroyed during WWII but some pictures survived).

This variant, a betting one, adds a few extra rules to the original game:

• Skipping a Rosace square forces a player to put a coin in the pot.
• Landing on a Rosace square allows a player to take a coin from the pot.
• Winning the game awards the winning player the rest of the pot.

These extra rules add another layer of strategy, planning, and risk to the game. Say you are playing Black, find yourself in the below situation, and roll a 2:

Do you skip the central Rosace, put a coin in the pot, but play safe with your central piece? Or do you instead move the other piece, hoping for a “1” next turn, while putting yourself at risk with a white threatening you? Decisions, decisions…

Try the Game Yourself

If you read this article until here, you probably want to try the game yourself now! And lucky you, there are plenty of options for you to do so!

• You can purchase the official replica on the website of the British Museum. The pricey option, but quite a conversation starter to have on your coffee table, isn’t it?
• You can purchase cheaper replicas from Amazon.
• You can play the game on Tabletop Simulator.
• Or you can simply print the below picture on A4 paper and improvise the game pieces and dice!

If you want to give it a quick try with family & friends, just have a look at my homemade version below (that I still play today!):

• Hand-drawn board, marking the Rosaces of course
• 7 white and 7 black pieces taken from a checker game
• 4 classic 6-sided dice, with their 1, 2, and 3 painted black with a marker (counting for a “0”) and 4, 5, and 6 left white (counting for a “1”). The roll on the picture above is thus a 1.

Not only this work perfectly, but it is also more pleasant to manipulate cubic dice instead of trying to pick up 4-sided ones with greasy barbecue hands (I suspect Sumerians were having claws instead of hands).

Conclusion

Well… My personal conclusion is that this is a pretty damn good game! If you read my previous article, The Components of Timeless Social Games, you may have noticed that this game ticks pretty much every box of what makes a solid social game.

It may seem logical, but it’s quite fascinating to me that a game almost 5000 years old, evolving and branching through the ages and geographical spread, managed to naturally reach a point where its game design old strong from today’s standpoint. We are having jokers, double-turns bonuses, skip-turn maluses, catch-up mechanics, uneven odds, and strategical planning…

To me, this is proof that trusting players and communities to appropriate a game and make it evolve will transform it into a better version of itself, iteration after iteration, and why so many Game Design breakthroughs came from the work of modders. Game design is a very human craft, and it seems that the evolution theory and the survival of the fittest apply themselves in this domain as well!

Did you enjoy this article? If so, please consider supporting GDKeys on Patreon. It helps keep this place free of ads and paywalls, ensures we can keep delivering high-quality content, and gives you access to our private Discord where designers worldwide gather to discuss design and help each other on their projects.

This article is here to shed some light over the amazing learning material they produce outside of GDKeys: videos, articles, presentations… This is a gold mine of knowledge and a perfect complement of this blog.

Happy reading and watching, and don’t forget to give them all some love by liking, sharing, and commenting their work!

• User Experience
  • ARTICLE: The UX of Video Game Tutorials
  • ARTICLE: How UX Breaks the Fourth Wall to Make Better Video Games
  • PRESENTATION: UX Tools for Designing a Portfolio
  • ARTICLE: Video Game UI that Helps Immersion — Weapons Wheel
  • ARTICLE: Player Motivations and Video Games
• System Design
  • VIDEO: “Mis-stakes”, Urgency and the Problem with Main Quests
  • ARTICLE: “Dear”, a letter-writing simulator
  • ARTICLE: 3C Design for large scale traversal systems
• Combat Design
  • ARTICLE: Anatomy of an Enemy Attack in Dark Soul 3
• Video Games Studies
  • ARTICLE: Design Analysis of Control
  • VIDEO: Fallout 2, Nostalgia, and the ‘I Only Play Real Games’ Crowd
  • ARTICLE: Why do we Play Dark Souls
• Marketing
  • ARTICLE: Board Game Marketing Plan

User Experience

ARTICLE: The UX of Video Game Tutorials

Author: Bramha Dalvi

An exploratory article on tutorials approached through the lens of Flow and emotions, that challenges designers by identifying key decisions to be made while designing one.

ARTICLE: How UX Breaks the Fourth Wall to Make Better Video Games

Author: Bramha Dalvi

A deep article challenging the usual misconception of UX = UI and giving keys to understanding that UX  is not about “how can we make this easy” but “how can we help players fulfill what they seek” to quote Bramha.

PRESENTATION: UX Tools for Designing a Portfolio

Author: Iris Vos

What if creating a Portoflio could be approached with the same process and tools used for any UX-oriented project? A short presentation opening doors to classic UX tools.

ARTICLE: Video Game UI that Helps Immersion — Weapons Wheel

Author: Bramha Dalvi

A great study of usability, immersion, and experience fluidity, from the lens of a now-ubiquitous UI element in video games: weapons/items wheels.

ARTICLE: Player Motivations and Video Games

Author: Bramha Dalvi

Another look at player motivations approached through the toy/game distinction and the self-determination theory. Expands beautifully on the motivations article found on this blog.

System Design

VIDEO: “Mis-stakes”, Urgency and the Problem with Main Quests

Author: @Chemical

An excellent video exploring the sense of false urgency in games when narrative stakes and core gameplay collide against one another: the “mis-stakes” as @Chemical calls them (genius!).

ARTICLE: “Dear”, a letter-writing simulator

Author: Lila Grimaldi

What started as a small piece of portfolio turned into a unique look behind the curtain of narrative design, its tools, approaches, and philosophy, and the rational design logic behind it.

ARTICLE: 3C Design for Large Scale Traversal Systems

Author: Bramha Dalvi

As video games worlds become bigger and bigger, so grows the complexity of navigating them. This study explores the 3Cs of giant games in an extremely comprehensive manner.

Combat Design

Article: Anatomy of an Enemy Attack in Dark Souls 3

Author: Jerry Zhang

A precise study of Dark Souls 3 combat direction through the lens of its enemies attack and timings. Excellent to follow-up after the “Anatomy of an Attack” article.

Video Games Studies

ARTICLE: Design Analysis of Control

Author: Jordan Dube

What makes Control such a damn good experience? This article studies the game’s pillars: Weapons, Abilities, Enemies, and Upgrades, to try and shed some light on the hidden elegance of its design.

VIDEO: Fallout 2, Nostalgia, and the ‘I Only Play Real Games’ Crowd

Author: @Chemical

How does Nostalgia affect our perception of past games? Here is a deep video study of the design limitations of the timeless Fallout 2: combat, skills, narration… A fresh look at design progress over the past 20 years.

Article: Why do we Play Dark Souls

Author: Jerry Zhang

Less a Dark Souls study than a players study, this article dives into the inner motivations that drive us to play hard and punitive games, using the Competency pillar of the SDT as a base.

Marketing

ARTICLE: Board Game Marketing Plan

Author: Jordan Dube

An exceptionally dense article breaking down the construction of a board game business plan: thought process, analysis, studies, and strategies… A gold mine of information.

These tests can be daunting: they widely vary from one company to another, employers’ expectations aren’t clear, there are barely any examples or material on the matter on the internet, and worse: you will very rarely get any kind of feedback on the tests you perform, even if your test gets rejected and request some.

This realization, coupled with the fact that a lot of you are looking (or will look) for a job in the industry prompted a 2 months long endeavor to try and prepare you as best as I can for what will come your way.

Here is how it went:

• I created a mock game design test: this test has been created in the same way I usually create my tests during the official recruitment phases I conduct (length, topics, freedom, traps…).
• I gave you a month to fill said test with minimum guidance, the same way I would have sent you this test in a real recruitment scenario.
• I then judged these tests as if they were actual applications: no sugar-coating, no excuses, no interaction with applicants to explain their answers (something that would usually be done during an interview IF the test is being given a go).
• Finally, I held a 2.5-hour Live stream to go through the entire process: how to read a game design test, the breakdown of mine, all your answers, key takeaway, etc.

Should you have missed it, this article will give you everything you need to redo the experiment on your own (or get a refresher on the topic if you were part of it).

GDKeys Game Design Test

Let’s start with the beginning: the design test in itself.

As previously mentioned, this test has been done in one of the most common formats found in the industry, while removing on purpose any personal question made to frame the applicant, like “What was the last game you played? What aspects of it are worth noting? What could be improved?” or “How would you define Game Design? What is the role of a game designer in a production in your opinion?”.

Should you want to give it a shot, you will find the test below in .pdf format. For a test like this one, I would usually give applicants one week to send their answers: this does not mean that applicants should spend an entire week on it, but instead ensure that they will find the time in their schedule to make it happen.

WARNING: if you are planning to answer this test, I strongly advise you to stop here and read the rest of this article once your answers are ready! You will learn a lot more doing so, and facing this test unbiased will be excellent training!

9 Community Game Design Test Answers

During our experiment, 9 members of our community actually completed the assignment and sent me their answers (thanks folks, you rock!). This is priceless, as studying them will give you a glimpse on how wide the range and freedom are when answering such a creative test.

I packaged these 9 tests in the link below. Feel free to download and study them: in your opinion, what is great about each of them? Where do you see short-comings or mistakes? How about the formats chosen? The amount of text? What could you have applied to your own test to make it better? How much do these tests stand out from the rest? Etc.

Answering these questions for yourself first will help you shape your own approach and get priceless knowledge on the topic at hand.

Game design Test Live Presentation

Now, for the meaty part, you will find below the recording of the Live stream we held to discuss every detail of game design tests as well as getting my first-hand experience and observations on the tests submitted and how to answer one in general.

This is a long video, and 2.5 hours of terrible French accent can be quite a difficult experience… Luckily for you, I timestamped it so you can jump straight to the part that interests you!

Timestamps

0:00 Introduction
8:00 What is the point of a game design test?
14:35 How to analyze a game design test?
20:10 Analysis of our mock-test
43:48 How to answer a game design test? Let’s look at 9 answers provided by our community!
2:17:05 How to answer a game design test: key takeaway

Live Presentation Material

Finally, should you want to get the presentation I made for the live, here it is in a convenient .pdf format as well as copies of each slide:

Conclusion

A game design test is a difficult exercise… Always remember to answer it for yourself before trying to please recruiters: not only you will create more unique, interesting tests, but you will also ensure that you get hired by the company that truly fits you. Game design is a wide topic, and your personal approach and own vision is crucial. Finding a company that appreciates this in you, and recruits you because of that, will make you thrive and hopefully start an amazing and fruitful career!

I hope these will help you and hopefully make some of you realize your dream of working in the industry (if so, you better let me know!). Good luck with your future game design tests, and see you on Discord to discuss them or if you have other questions!

Did you enjoy this article? If so, please consider supporting GDKeys on Patreon. It helps keep this place free of ads and paywalls, ensures we can keep delivering high-quality content, and gives you access to our private Discord where designers worldwide gather to discuss design and help each other on their projects.

But there is one topic that we stayed clear from, until today: the implementation of an AI agent in our games, and the necessary technical design that connects the theory to the reality of our playable enemies.

How do we implement an AI, in an engine, for it to fulfill all of our crazy paper plans? How do we make an enemy behave logically? In short: how do we create and implement AI intelligence?

AI implementation has been a burning topic in the industry for the last decades: it made games enter the Pantheon of video games, created highly specialized positions, like AI designer, and is reaching far beyond our industry (we have rovers on Mars that are running using the very methods we will discuss today!).

This is also an extremely complex, and pricey, topic: AAA teams usually have full-strike teams working for years on their AI in order to bring us the enemies we are all used to play against. This brings us to this article’s purpose: what is the most straightforward, versatile, debug-friendly, and designer-friendly way to design and implement AI in our games?

In this article, we will focus on the decision tree approach, a philosophy that is still used today by AAA teams to create amazing AI agents, and yet that is accessible enough for anyone to implement relatively easily on their own games.

Here is the plan for this article:

• Frame our topic and identify the strengths and weaknesses of Decision Trees compared to different approaches.
• Design an enemy from scratch, using a human-friendly visualization, as well as going through each necessary creation step to ensure a clean design and enemy.
• Finish with a ready-to-use design tool for you to leave with.

This is a tough topic to tackle, but if all goes well it should be a lot less scary in no time! Let’s dive in.

The Many Forms of AI

To begin, we need to realize that there is a multitude of approaches when it comes to creating an AI, each of them with its own advantages and disadvantages.

Historically, AI was created the same way we have been automating other industries before: with Finite State Machine (FSM). In essence, every behavior and action of an enemy was coded as a state, which would transition to another one following some conditions (spot the player, run out of ammo, timer, being shot at, die, etc.).

This approach is robust and easy to implement, which is probably why it is still used today for simple system automation. Here is what an FSM would look for in a Pacman Ghost:

Pretty straightforward! The main catch with FSM is that it, unfortunately, tends to get extremely dense and confusing. Trying to code, improve on, and debug enemies as complex as the ones we find in games today can easily become impossible as their FSM will become a monstrosity of hundreds of interconnected states and rebounds.

Another approach then appeared: behavior/decision tree (there is a technical evaluation difference between the 2 but can be roughly approached the same way for the sake of this article). This approach is very straightforward: every frame, the game will run the decision tree of an AI agent. This tree is composed of a root, branching into layers of nodes, like selectors, and always reaches a child/leaf which represents every action this agent can perform.

Here is the decision tree of the original Quake enemies (Inputs: D = dead, E = enemy spotted, L = low on life, S = sound heard):

Decision trees have been used for decades in the industry and are still very relevant today. They are the approach that brings implementation the closest to the design, are extremely easy to debug and improve upon, and are pretty efficient in terms of resources.

The main criticism about decision trees relates to the “fake” intelligence it provides: just like an FSM, an enemy will never swerve from its decision tree even if a truly intelligent creature would have used every opportunity at its disposal.

Enters the advanced AI approaches!

The first one we will discuss is called GOAP, for Goal-Oriented Action Planning. This approach has been heavily theorized by Jeff Orkin and applied to his game F.E.A.R, which received critical acclaim for its enemies’ behaviors.

In short, enemies using GOAP are going to make their own decisions based on the actions at their disposal, the state of the world, and the goal they are trying to accomplish… Pretty crazy, right?

To do that, the game will continuously feed AI agents with a goal, as well as with the current state of the world. The agent GOAP Planner will then run every possible chain of actions said agent can accomplish and assign costs to each of these chains. It will finally select the optimal sequence of actions to fulfill the goal and act on them!

Let’s imagine, for example, that our agent has the goal of “get wood”. One of its actions is to “Collect branches” which would definitely fulfill the goal. The agent planner decides to assign a cost of 10 to this action (weighting the time and energy necessary to carry the task to completion). But another of its actions would also fulfill this goal, “Cut Tree”, which is a way more efficient solution! That action gets a cost of 4 by the Planner. The problem is that to cut a tree, the agent needs an ax. “Purchasing an ax from the market” is another action that our agent can perform, this time getting a cost of 5 (again, weighing in the time, money cost, and energy involved).

Once our agent has run all the possible scenarios, it is finally left with 2 scenarios:

• “Collect branches”. Cost = 10
• “Purchase an ax” + “Cut down a tree”. Cost = 5 +4 = 9

This time, our agent will decide on the ax scenario. If he didn’t have enough money for the ax (and thus should have found a way to get enough money first), the cost would have probably gone above the simple “Collect Branch”.

Also, since our agent now has an ax, but also one less tree, the cost calculation the next time it will need to collect wood will be entirely different. And this is the beauty of this approach: AI agents will adapt to the world, and react accordingly in the most efficient and logical way. It can lead enemies to make fabulous tactical decisions in accordance with a world state they are just discovering every frame.

So why isn’t every game running with this approach then? Well, first of all, because it’s extremely costly in resources. But also, this approach is hell to work with and debug: imagine a gigantic state machine but without any link between states, where the AI itself takes care of bouncing between these states as it pleases.

Then we could push the discussion even further and talk about Utility AI, abstracting, even more, the path to a goal by measuring its performance towards it, which is a phenomenal AI approach for strategy games with long-term victory conditions and a huge number of agents. And how about Neural Networks?

But we are opening too many doors…

My Approach

AI is a fascinating topic, but when it comes to our games we need to be realistic. Very few of us will ever have the need to implement a fully-fledged GOAP system and go for the cost and extra time and resources needed to polish it properly. And even if we could… Would it benefit our games?

And this is a very important question to discuss: there is a belief that “more intelligent AI = better games” which couldn’t be further from the truth! Most games will better benefit predictable, pattern-oriented enemies, some will even shine with sequenced enemies, repeating their actions without even a speck of AI behind it. Finally, some rare cases will really gain from having a state-of-the-art AI, like the amazing work that has been done on Alien: Isolation.

Having worked with all these systems on different games over the years, I came to the conclusion that most action games are best suited with a combination of 2 elements for their AI:

• A high-level state machine, dealing with the key behaviors of our enemy,
• A decision tree per state of the state machine.

It’s designer-friendly, very understandable even for non-initiated, easy to improve upon and debug, cheap in resources, and can be extremely efficient in displaying intelligence if properly designed: games like The Division 2, or the fact that at its core, the Xenomorph is driven by a decision tree are proof of it.

The bonus part? Unity and Unreal have all the tools to implement this approach with minimal work.

So let’s give it a shot, and design together, step-by-step, the AI of a basic enemy for a random action-adventure game!

Designing an Enemy

For the sake of this exercise, we will design the AI of a pretty basic enemy, let’s call it the Bandit, that will be a grunt enemy in our third-person action-adventure game.

His high-level behavior will be fairly classic: he will be placed in our fighting zones (camps, VIP locations, arenas…) and if undisturbed will just idle around. If he notices something suspicious he will go investigate and, of course, will attack the player on sight.

Our Bandit will have a dagger for melee combat, a gun for mid-range, and that’s pretty much it. So… where do we start?

0. High-Level State Machine

I personally prefer not to keep the entire logic of my enemies in a single decision tree: they become bulky, run excessively long logic sequences, and become a pain to work with (the picture above represents only a third of the Xenomorph decision tree for example).

For this reason, I like to have a state machine at the root of my enemies’ AI, breaking their behavior into a multitude of small decision trees: one per state.

For our Bandit, this FSM would simply contain 3 states

• Idle State: his undisturbed state. Also, the one he will spawn into.
• Combat State: the core purpose of our enemy.
• Investigation State: to ease the transition between the 2 previous states in a believable way, as well as bring a light stealth aspect to our game.

Once each stage is defined, we can now finish this FSM with every transition between them:

Our full FSM will be extremely simple:

• While in Idle, our Bandit will attack the player on sight, but will also investigate weird noises.
• While investigating, if 10 seconds pass without spotting the player, the enemy will go back to idle. “Must have been the rats!”.
• Finally, while in combat, if the Bandit loses sight of the player, and the player is more than 10 meters from him, he will enter an investigation (this is very rudimentary but will do the job for now).

This is a pretty good start! We can now finally enter the crunchy part of the AI: the different decision trees! Today, we will focus on a particular one, the combat state decision tree, but the other two would follow the same logic.

1. Combat State Decision Tree: The Core

Let’s start by talking a bit about what is a decision tree.

In broad terms, decision trees are a succession of nodes, on multiple branches, starting from a root node and ending on a leaf node (the actions). To reach one of the leaves, the algorithm will pass through a series of gates and conditions, branching every time.

A decision tree will always run top-to-bottom (or left to right depending on the directions you take it): every time a condition (the parent node) is reached, the algorithm will assess every one of its child nodes one by one. If the first condition of a child node isn’t answered, the tree will move to the second child, and so on until it finds a suitable one.

For easier reading, I will represent the actual flow of decisions in the tree in the rest of this article. This isn’t how it is typically represented but will ease our discussions (I will show you both representations at the end).

So, let’s put our first blocks together!

Our Root node will be the entry point of the Combat State.

Now we need to put our first conditions. Where do we even start? Well, I personally advise going to the root of the enemy: what will be its main decision parameters? Or, in other words, what is the primary parameter that will make it decide between different actions? This is a very important question!

For our Bandit, as well as most enemies you will encounter in action-adventure games, the answer is distance: “I am far away from the player, there is no use for my dagger and I should use my gun!”. But it may be different: mages could first make decisions based on their spells’ cooldowns, shapeshifters could make them based on their current form,and enemies in a musical-inspired game could make them based on rhythm… There are a lot of possible answers!

Now that we have our core decision parameter, let’s create our first meta conditions: we are laying down the big categories of behaviors of our enemy, the broad strokes. Our bandit will have 3:

• Is the player out of range (then it can’t attack)?
• Is the player in long-range (and thus in range for its gun but not its dagger)?
• Is the player in melee range (in range for both, but mainly for the dagger)?

Once again, every enemy for every game will have a different set of conditions: think them through carefully, and slap some rough values on them (we will polish them later).

With distance used for my core conditions, I took the habit of ordering them from furthest to closest from the player: in this case, the order wouldn’t matter, but we may end up with overlapping conditions and it usually works better this way (and is easier to read in my opinion).

2. Decision Tree Core Leaves

Now that our core conditions are in place, let’s attach actions to each of them, and give the first proper combat behavior to our Bandit:

The actions will stay very straightforward for now: we are slowly chiseling away and shaping our enemies: let’s not get carried away in details that may confuse us.

• Player out of range: our Bandit can’t attack and thus will navigate towards the player (run, bounce, whatever your action is).
• Player in long-range: it will use its gun for a single-shot action.
• Player in melee range: it will use its dagger slash (a base dagger attack).

And look at us: we already have a fully functioning enemy! Simple, sure, but it could definitely work as-is. Now a little advice: test it! Each step of our designs needs to be self-contained and testable, and this is the perfect moment to spot problems and refine our condition values.

Also, you may have noted the shape differences of my leaves (dotted lines and solid ones). This is a habit I took to help me read my designs more easily: solid lines represent the combat actions, dotted ones the fluff, repositioning, navigation, etc.

But we have a lot more expectations for our enemy (and killer animators that need work), so let’s densify this behavior a bit.

3. Variety and Random

Let’s face it: an enemy doing the exact same actions in the exact same circumstances will feel gamey and robotic. This could be a great thing if we are actually designing robots (cf. the enemy believability article) but our Bandit is human and should thus behave like one.

Not only that, but we may create terrible game situations! Let’s take an example: 4 Bandits spot me from afar (out of reach): they will all start running towards me, stop at the exact same distance (long-range), and all shoot at me at the same time. Not very immersive…

This is actually a situation where GOAP would shine by letting each enemy weigh its own actions independently (and this could be done with a simple ticketing system too!) But this doesn’t mean that we can’t fake it with our decision tree! Let’s bring random into play.

The idea is simple: for each condition met, our Bandit will roll a dice to decide between different actions:

• When the player is out of reach, the Bandit will either run toward (75%) or taunt the player without changing position (25%).
• When the player is in long-range, he will either keep running towards (50%) or take a shot with his gun (50%)

Let’s reassess our previous situation with these additions: out of our 4 enemies, on average 1 will taunt the player while 3 of them start running towards the player. arriving in long-range, half of them will take a shot while the other half will close the gap and engage the player in melee.

This feels a lot better already! And now it’s time to test again, with different situations, numbers, and positions of enemies, player inputs or not (what happens if you don’t touch any button? You can easily see AI flaws without the chaos that the player brings in the system).

This is also an important point: it may still sound artificial (every enemy stopping at the same distance from the player to take a shot for example), but the player is going to be our best ally here: the player is always in movement, always creating chaos and varying situations. This will create a very organic battlefield, even with seemingly artificial conditions.

Now let’s take care of our melee range.

4. Sequences and Combos

Having an enemy in melee range (thus really visible on screen) repeating the same attack can quickly feel odd and unnatural. This time we’ll try something else than using random branching: combos. And this is as easy as chaining leaf nodes.

Here is what our Bandit will now do when closing on the player:

• He will start with the dagger slash we had before (called now the Dagger Slash Right, we’ll assume he is a righty).
• Then he will come back to his original position with the mirror action (the Dagger Slash Left).
• Finally, he will extend and stab the player.

This sounds like a pretty sound succession of attacks: each attack uses the energy from the previous one, and they flow nicely together… But discussing it would be a topic for our Anatomy of an Attack article.

Now you may rightfully wonder why do we go with the struggle of creating 3 different nodes, thus 3 different actions, when we could simply create a simple action called “Dagger Combo”. The answer is control.

5. Abort Conditions

If we had all our attacks packed in a single action, then they would all play out exactly as expected all the time. But breaking them into different nodes will allow us to gain multiple opportunities as we will see. Another strong argument to make is that each of these bricks can be reused separately at different moments of the experience, for different attacks later on.

In our case, we will try and avoid the situation that many games suffer from, where an enemy starts a combo, but the player moves away and can now watch the enemy trying to land attack after attack while it’s evident they are just embarrassing themselves. Not very smart.

To do that, we will add an extra condition that will check if a hit has landed: if positive, then the combo continues. If negative, then our Bandit will “realize” that he isn’t hitting the player and will abort the combo.

I decided not to put an abort condition between the first 2 attacks as I believe they will flow in a continuous motion (going back to the idle position).

Abort conditions are probably the most common use of this split approach, but there are others: we could bring some random in it to create multiple combos at little cost or check where the player is after the first 2 hits to chain into different stabs (direct stab, 180+stab, jump+stab, etc.).

Let’s clean our decision tree by grouping this combo into its own little tree: it may seem useless here, but as combos often get dense and convoluted this helps keep the core tree readable:

We have a strong AI base, but it is now time to consider what could go wrong with it, and plan against it.

6. Core Extremes

Our Bandit core is based on distance conditions, and we already tackled the gameplay ones. But we are missing some scenarios, like the extremes of the system.

In our case, the first extreme will be the Target Unreachable state. It may happen that our Bandit won’t be able to find any pathfinding route toward the player (having the player on top of a cliff for example). In this case, we will need an emergency solution that won’t involve our enemy trying to reach the player: we will reuse our “Gun Single Shot” attack (even if the player is not in range, it makes sense that our Bandit will try nonetheless), and an occasional taunt specific for the situation, like “Get down there, you coward!”. This will prove that our enemy is very aware of the situation unfolding and his inability to act.

Note: unreachable conditions can vary widely from one game to another. This solution is given as an example but your own game may have a very different approach.

The second extreme is actually a realization and gameplay one: our dagger combo has a condition “player less than 4 meters away”. But having the player too close to the enemy will make the combo look glitchy (or straight-up passing through the player). So we will add a fourth distance condition, making our Bandit jump back when too close to the player. This should position him at the proper distance for our Dagger Combo!

We are now covering all basic situations and the full range of our core (distance): our enemy should behave fairly well. After another round of testing to confirm it, we can now start looking into the secondary conditions driving our AI.

7. Situational Conditions and Sequences

What interests us here is all the unique situations, happening outside our enemy, that could make him look stupid, and plan against them. In our mock game, let’s assume 2 situations:

• The player can block attacks (classic unlimited block with reduced mobility).
• After taking a strong hit, the player can be thrown on the ground (a disabled state with a button press to go back up).

These 2 possibilities are dangerous for our Bandit: his Dagger combo may look inefficient against a player blocking all attacks (and players would expect him to think around that), but will sure look ridiculous if the player is lying on the ground with the enemy doing all kind of inefficient flourishes above them.

Not only that, but gameplay-wise we want the game to push the players to react fast and vary gameplay approaches on the flight: we need to have enemies breaking the player’s guard and emphasizing that being on the ground is an extremely dangerous situation.

We are then going to add 2 actions to our Bandit AI: a kick that will break the player’s block (and allow the Bandit to properly start his Dagger Combo next), and a Dagger Finisher: a very deadly attack that will punish players ending up on the ground for too long.

Remember that decision trees run sequentially: our unique conditions must be checked every time before the common ones, and thus our Dagger Combo will end up at the bottom of this branch.

8. Security Leaf

Our enemy seems pretty solid for now and it seems like we are covering all the possible situations he may find himself in, but we may have overlooked a few extreme cases and thus will always need to add a security leaf: the extreme bottom of our decision tree, the action that will run when nothing else can.

You may tell me: “If he can’t do anything he will just do nothing, what’s the big deal?”. Well, there are 2 dangers here actually: the first one is that we may not notice that there is a problem with our enemy (and we will keep trying to solve why our enemy isn’t aggressive enough). The other is that it may add chaos to our enemy’s pacing.

Not only it is very helpful to add this leaf, but it is also good practice to never leave a condition floating without a leaf for every output.

I personally like to throw my taunts there: they are the least impacting actions of my enemies (no navigation nor player interaction) and are extremely visible: if I see my bandits taunting constantly out of the blue, I’ll immediately know there is a problem in their AI.

Almost there! We have but one last thing to take care of.

9. Priority Conditions and Sequences

In step 7, we talked about having our enemy react to situational conditions (player on the ground, player positioned behind him, player aiming at the enemy, obstacle obscuring his FoV, etc.) but we may want the enemy to have some extra conditions: conditions that should take-over everything else.

For our Bandit, we will imagine 2 conditions:

• Let’s say our Bandit can be stunned (smoke bomb, dirt thrown in his eyes, headshot maybe?): we will make him enter a Shooting Frenzy, an action where he will cover his eyes with his left arm while emptying his magazine shooting in random directions.
• We will go a bit over-the-top and create a Raging state when our Bandit’s HP falls below 20%. For this example, I made it branch to another completely different decision tree dedicated to this Raging state (that we won’t deal with today), making this moment one of the pillars of our Bandit (and inviting the player to finish off enemies fast).

As you can see, these conditions are very meta (can happen at all times and distances) and thus will be placed at the very top of our tree: at every tick, our decision tree will first ensure that the Bandit has more than 20% HP and isn’t stunned, then it will check that the player is reachable, then finally it will start running his core conditions.

Quite a lot of priority conditions can be added here: every gameplay’s unique states, strong hurt reactions, etc.

10. Final Decision Tree

Finally, after all these steps, here is our final Bandit decision tree (minus the Raging state):

This tree should very much be tested, polished, and iterated, but it holds together and should look smart and consistent in all scenarios. The next steps for me would be to polish the unreachable state and playtest a lot of this enemy to see how the random conditions hold (are the probabilities feeling right? Should I add more possibilities? Less? This can only be judged pad in hand in the end).

Our Bandit is quite expensive too, with its 10 unique actions, not counting the Raging state (definitely a AAA enemy budget, or a very important enemy in a more modest game). This could definitely be scoped down if need be.

At the start of this article, I mentioned that I would represent all the decision flow for easier reading. Since our decision trees will always run the exact same top-bottom way, I actually represent my decision trees in this format:

This is the exact same decision tree, but in my opinion, it’s a lot more convenient to work with and really represents how it will be coded in the engine (branches and leaves clearly identified). I leave it up to you to find the best format to work with.

Tool: Visio Decision Tree

Personally, I find it invaluable to have this paper design of my AIs before implementing anything. It ensures that I thought my enemy through beforehand, gives me a visual, legible representation of its brain, and really accompanies me in its different iterations and polish.

If you liked the approach I developed here and want to give it a try yourself, I prepared a Visio template for you to use, with the final decision tree of our Bandit in both formats, as well as the legend of my blocks.

You can access it here:

Exercise

If you want something to practice on, why not design our bandit-raging state? Let’s make it interesting: this state will only get a single new action, a signature move. The rest will have to be made of re-use from the normal Combat state (then bring a snapshot of it on our Discord!).

Conclusion

There would be so much more to cover when it comes to AI… A decision tree is but one of the bricks that will make an enemy behave smartly: pacing, group AI, animation inverse kinematics (look-at), animations themselves, etc. Like every topic with games, the suspension of disbelief will be kept in place by a multitude of different elements.

Whatever AI implementation approach you decide to go with, the search for smarter enemies (but not too smart or the gameplay falls apart) will never stop, and technology alone will only get you so far.

Advanced enemies are among the most difficult game design challenges, and are often botched: implementing it well will instantly put you above the vast majority of games and will surely become a stamp of quality for your games (even if it isn’t noticed directly by players). It feeds the game’s fantasy, makes the gameplay shine, and gives a soul to games.

Now go make fake brains!

To Continue Beyond

Should you want to continue beyond this article, here are excellent resources:

An introduction to Behavior Trees by the excellent AI in Games channel

Because GOAP is a fascinating topic (even though I usually advise against using it, it can be a pretty amazing tool to use on the right game):

To continue on GOAP, here is the site of Jeff Orkins, the father of the approach, filled with excellent resources:
http://alumni.media.mit.edu/~jorkin/goap.html

And a last article on GOAP, more code-oriented this time:
https://gamedevelopment.tutsplus.com/tutorials/goal-oriented-action-planning-for-a-smarter-ai–cms-20793

Finally, let’s open the discussion with an excellent article from Nikki Zee that approaches the topic of enemy AI from a different lens and really analyzes the various forms of AI and their pros and cons (FSM, utility AI, behavior trees, etc.):
https://nikkizee.com/ai-decisionmaking

Did you enjoy this article? If so, please consider supporting GDKeys on Patreon. It helps keep this place free of ads and paywalls, ensures we can keep delivering high-quality content, and gives you access to our private Discord where designers worldwide gather to discuss design and help each other on their projects.