Welcome to my new blog post!

Today, we will discuss how to prototype different types of live events using a framework I’ve prepared.

The live event prototyping framework is a framework for hybrid-casual games that enables even seemingly different events to use the same configuration infrastructure, while helping standardize communication between product and development teams.

Before continuing with the article, you can try it here:

Live Event Prototyping Framework by Burak Ökten for Hybrid Casual Games

As a game designer, I’ve often experienced that some of the biggest challenges in event design and implementation are explaining how an event should work to developers, while also trying to build economy models across excel files that keep growing and becoming harder to manage. For this reason, I specifically decided to develop it with a designer-first approach.

I derived this framework from another economy framework I worked on last year. You can read more about that topic in my article, Why LiveOps Feels Unpredictable for Game Designers. While it is your responsibility to check the accuracy of the results produced by the framework, my goal here is to help product teams in particular with the following:

1. Quickly prototype any hybrid-casual event that comes to mind,

2. Approximately simulate your existing game economy when needed,

3. Take a quick look at how schedule changes would affect your existing game economy,

4. Prevent developers from struggling with different event templates, and

5. Help you get a quick start if you want to create your own LiveOps solutions, whether remote or client-side.

To be honest, the number of studios trying to use their own LiveOps methods is not insignificant. For this reason, I believe it will be quite useful for you, especially if you are using solutions such as Firebase Remote Config.

Although this framework does not claim to be a production-ready solution, I think it may inspire different tools you may want to develop in the future.

Now we can return to the main topic of the article. Although the framework’s website already provides access to its documentation and sample events, I thought it would be useful to walk through how to add an event step by step. Along the way, we’ll also cover some of the other features worth highlighting.

Here’s a quick look at the outline of the article:

1. Introduction, in this section, we briefly discuss the core features of the framework,

2. Event Prototyping, in this section, we prepare a Season Pass event.

Then, let’s begin!

Introduction

The live event prototyping framework consists of 4 main sections:

1. Builder - in this section, we design events,

2. Planner - in this section, we schedule the events,

3. Economy - in this section, we run an economy simulation of the events we placed on the calendar, and

4. Configurations - in this section, we can either export the configuration of the events we designed, or import previously exported events and continue working on them.

Builder

The Builder page includes the Units, Groups, Packs, Progressions, and Features modules that we will use in event design, as well as the Segment module that covers all of them.

To design an event, you first need to create the relevant Units such as coins, lives, rewarded ads, and so on. These Units are then grouped in the Group module so they can be used together, and those groups are assigned to Packs so they can be used as rewards or offers. Next, Progressions define how rewards are earned, and these progressions are assigned to Features to activate event-specific functionality. Each completed Feature item represents a designed event.

We’ll explore these processes in practice in the Event Prototyping section.

Planner

Features prepared in Builder page can be added to the calendar in Planner page on a segment basis. In the calendar, the event duration type and repeat rules can be adjusted according to your requirements.

Economy

On the Economy page, the events scheduled in Planner can be simulated for the relevant segment. In this way, when needed, the results of similar features with different schedules in different segments can be compared.

Configurations

On the Configurations page, the changes on the Builder and Planner pages are previewed at the configuration level in JSON format. If desired, configurations can be exported or imported for later use. To make usage easier, you can use the left menu to filter within the JSON file.

Event Prototyping

In this section, we will discuss step by step how we can prototype an event:

• Season Pass Event with 2 tiers: 1 free and 1 premium.

Each value we enter while preparing the configurations will be for sample demonstration purposes. We will not be concerned with making them resemble the configurations of any particular game.

That said, on the framework’s own page, you can find the Streak Rewards, Collect Items, and Race events inside the Sample Segment. I added these as examples as well.

I assume you already know how the core loops of these events work. Therefore, I will not go into those details.

Season Pass Event

In this example, I’ll show how to prototype a Season Pass event.

Designing Units for the Season Pass Event

First, we need to decide on all the units related to this event.

Let’s choose the following units as rewards:

• Coin

• Life

• Boosters (A, B and C)

Then, let’s determine which unit we will progress with in the Season Pass:

• Level

We should also define a unit for the cost of the event’s premium tier:

• RM (Real Money)

The Unit library should have become something like this:

Designing Groups for the Season Pass Event

At this stage, we will group the units to give as rewards in both the free and premium tiers.

Although we haven’t reached the Progression section yet, we need to decide whether the rewards will be distributed in a group-based way. Since the premium tier is purchased only once and its rewards are granted through progression, I’ll use group-based behavior instead of creating separate purchasable packages. We’ll revisit this when designing Progressions.

To keep the article concise, I’ll use five milestones for each tier.

Reward groups for the free tier:

• Coin x10

• Life 15 Min

• Booster A x1

• Booster B x1

• Booster C x1

Reward groups for the premium tier:

• Coin x50 + Life 15 Min

• Coin x100 + Booster A x1

• Booster A x2 + Life 30 Min

• Coin x150 + Booster B x2

• Coin x200 + Booster C x2

You can create the groups as shown in the image below:

Designing Packs for the Season Pass Event

Here, we will only need 2 packs: one for the free tier and one for the premium tier:

• Free Tier Pack

• Premium Tier Pack

The packs you add for the free tier should look like this. Since this tier is free, we don’t add any pack cost. And because we’ll be using group-based reward distribution without probability-based rewards, we don’t enable Enable Probability. Even if we did enable it, it wouldn’t take effect because group-based rewards will be active.

For the premium tier, however, we need to define a cost. I’ll set this to RM x999. As a real-world example, we could assume this corresponds to EUR 9.99.

In this scenario, the player cannot access the rewards unless they purchase this pack. One thing to keep in mind is that the economy simulation does not check whether the player has enough resources to purchase a pack.

Burak Ökten

Lead Game Designer | Economy, Progression & LiveOps Design | Level Difficulty Analysis

If you’d like to design a more comprehensive economy system for your game, feel free to reach out to me. We can review your reward flow and monetization structure together and discuss opportunities for improvement.

Let's Connect

In the lite version I published, the economy simulator completes purchases with 100% probability. In a more realistic scenario, we would need to use “rule-based” or probabilistic modeling. However, to keep the simulations simpler, I did not include these.

Designing Progressions for the Season Pass Event

We need 2 progressions: one for the free tier and one for the premium tier:

• Free Tier Progression

• Premium Tier Progression

As we discussed earlier, we will not give the rewards inside each pack all at once; instead, we will give them when each milestone is reached. For this reason, we enable group-based.

On the other hand, as we will see in the Feature design section, since we want the premium tier to use the same level progression, we will not need to fill in the Unit section.

Designing a Feature for the Season Pass Event

In this section, we connect the progressions inside a feature and create an event:

• Season Pass Event

The progressions we added in the previous step should not be independent from each other; they should progress at the same time. For example, if the player purchases the premium tier after making progress in the free tier, they should also be able to collect all premium tier rewards up to the milestone they have currently reached. For this reason, we do not enable independent or serial progressions.

Looking at the options in the image, we want this feature to have a home button, become visible when the player reaches level 25, become active when the player reaches level 30, and automatically join the player to the event. This way, the player can start progressing through the free tier as soon as the event is triggered.

Scheduling the Season Pass Event

Let’s assume we want to schedule this event monthly and have it repeat 3 times in total. In this case, we need to select period as the event duration and monthly as the event repeat rule. Even if we leave the repeat count as 0, the event is still considered active for 1 period.

Simulating Economy of the Season Pass Event

For the Season Pass event, we entered only 5 milestones in total and kept the progression intervals short. For this reason, we have the chance to keep the simulation much shorter. Still, for demonstration purposes, I chose a 7-day period.

You can take a look at the changes in unit amounts in the images below:

Although we did not cover every specification of the framework in this article, I think the system will become clearer in your mind through this example, as well as the examples and documents inside the Sample Segment.

If you have any questions about the framework, feel free to leave them under this post. I’ll be happy to answer whenever I can.

See you in the next article!

The huge success of Pixel Flow! by Loom Games seems to have influenced the entire market. It looks like we’ll keep seeing games built around a similar format for a while. Ignoring such a popular title would feel unfair, so it’s worth taking a brief look at it.

In this post, I’ll focus on a slightly more mechanical aspect of the game and briefly discuss how we might estimate the intensity of levels while designing them. The main goal is to show how we can help level designers while preparing levels by giving such feedback.

Before getting started, I’d like to share the chart that I will present at the end of the post right away. Below you can see how level intensity values, scored on a scale from 1 to 10, are distributed across the first 50 levels.

Level intensity is treated as a measure of the stress required to complete a level. This stress may be caused by difficulty, or the board design may force players to make more moves.

Before moving on to the calculations, let’s briefly talk about the assumptions:

1. I tried to estimate the level intensity by dividing the player’s total number of moves by the number of shooters. I assume that if the number of clicks on a shooter block increases, level intensity increases because the player may try to avoid failing (although counterexamples are also possible, which is why intensity itself cannot explain level difficulty alone).

2. I assumed the dataset I use represents a player segment (but in reality, we would need real player data).

3. I assumed no booster use, so the data was selected based on this.

4. In reality, we would need more levels for a good analysis. However, recording the data takes too much time, so looking at 50 levels is enough to discuss the methodology.

You can find the dataset sources I used here:

• I recorded the number of moves, the average counter number per shooter and the number of shooters from this YouTube playlist.

• I retrieved the number of waiting lines and the number of colors from the Pixel Flow deconstruction prepared by .

Now that I’ve briefly outlined the assumptions, we can return to the main goal of this post: can we model how intense our levels are for our own games as well?

We discussed a more ML-focused version of this idea in the paper Balancing Level Difficulty in Hybrid-Casual Puzzles using ML and System Modeling. I highly recommend taking a look at it.

First, let’s take a look at how the game mechanics relate to level intensity. As usual, we will try to apply white-box modeling:

1. Increasing the number of colors may increase the number of moves. Because the slots may fill up faster if the player cannot select the shooters in the correct order.

2. Increasing the average counter number per shooter may increase the number of moves. Because higher counter numbers mean additional loops around the board.

3. Increasing the number of shooters may increase the number of moves. Because they may accumulate in the slots while playing a longer level.

4. Increasing the number of waiting lines may decrease the number of moves. Because the player will have more choices to select from.

5. Normally, we should also consider obstacles, which I discussed earlier in the article I mentioned before. However, I won’t include them here because we don’t need that complexity in this short post.

So, basically, extra moves should be proportional to the following equation:

The reason I use the values a, b, c, and d as exponents rather than as multipliers is that it allows us to adjust the weights of the features more easily.

When I used this model in a linear regression to predict extra moves, the R² was 0.76 and the 5-fold CV R² was 0.61, with moderate errors, which is expected considering how small the dataset is.

Below, the actual and predicted level intensity values are shown after the extra move predictions, before being scaled to the 1–10 range.

It’s actually quite useful in terms of giving level designers insight, especially when new levels start to be added to the existing level set. It also seems possible to roughly estimate the intensity of levels that haven’t been released yet.

To be honest, I really wonder how it would look with a bigger dataset!

This post ended up being quite short, but it was still nice to do a bit of brainstorming.

I also recommend reading my other posts where I discuss why we should build level design systems that are more reasoning-driven and predictable, rather than relying on black-box level design.

See you next time!

Welcome to my first blog post of 2026!

There’s been a lot of discussion around LiveOps challenges lately. As a systems designer, I’d like to explore the topic from a game designer’s perspective.

While LiveOps inherently involves multiple layers, I want to highlight certain difficulties faced in game design and product decisions, specifically within the scope of this article:

1. We want to add the event X from a competitor game into ours, but we do not know how to adapt it to our audience and game economy.

2. Even though the level funnel is made of the same levels, engagement and monetization metrics change with every release. We cannot explain why.

3. We believe the new event will work, but we do not know what outcomes we should actually expect from it.

4. Since these are proven mechanics, we decide which features to add by looking at competitor games. However, the configurations do not fit our game economy well.

5. The package prices in the competitor game are well balanced. We applied the same setup, yet something still feels wrong because we cannot reach the KPIs we expect.

6. We built a very similar version of the competitor game and even copied its economy. Why does their game earn money while ours does not?

7. Should this event unlock at level 40 or level 50? Which level would produce better results?

8. If we give 75 coins instead of 50 at the end of a level, would it affect our IAP packages? We assume it would not.

9. Our A/B test results come out trivial even though we changed both price and content of the IAPs significantly. How is that possible?

10. We want to adjust level difficulty dynamically, but we do not know how to align the reward flow with it.

11. We currently measure level difficulty purely by intuition, yet we want to tune difficulty across each set of 100 levels. How can we achieve this?

Most of the problems in the list come from weak system design and not being able to form clear hypotheses. Teams are afraid of missing trends, so they make random decisions based on conclusions they think are right. The A/B tests built on top of those conclusions then fail to give clear results. I already covered the last problem in my previous articles if you want to go deeper.

If you have not run into these problems before, congratulations! It probably means you already have a solid pipeline and do not deal with these kinds of headaches. In that case, you can keep reading the rest of the article just for fun!

I divided this article into 3 main sections:

1. Introduction. In this section, we discuss what executable hypothesis design is and what it is not.

2. Existing Approaches. In this section, we focus on common issues in game design processes during event design and explore how they can be solved.

3. Framework Design. In the final section, we discuss a framework that enables systems to communicate with each other and allows us to implement executable hypotheses.

Introduction

Before talking about what executable hypothesis design is, let’s take a look at what it is not:

1. It is not player simulation.

It does not predict how the player will behave in a situation. It explains which behavior a specific situation could produce.

2. It is not a prediction model.

A prediction model estimates the outcome using past data, while executable hypothesis design reveals the behavior a hypothesis would produce.

3. It is not an alternative to analytics.

It is used not to explain past player data, but to test the future. It does not make predictions based on data, but better models can be prepared by being informed by data.

4. It is not an alternative to A/B testing.

It is not an alternative to A/B testing but a complement to it. It tests the hypothesis before the experiment and shows which parameters are worth trying.

5. It is not an AI agent or a bot.

It is not an intelligent bot that plays the game. Instead, it is a system that explains the decision-making mechanism.

6. It is not magic!

To apply executable hypothesis design, we first need to clearly define our in game systems, especially the economic relationships between them. We cannot build sound hypotheses on top of the random behavior produced by a poorly modeled system.

7. It is not just about resource balancing!

Changes in player engagement and frustration can also be modeled, for example, based on difficulty parameters and reward flow.

Executable hypothesis design is a mathematical hypothesis modeling method used to reason in advance about which behaviors game design decisions will produce. Its strongest aspect is that by running different behavior models together, it makes causal relationships visible that cannot be seen through intuition alone.

Hypotheses can always turn out to be wrong, and it is rarely possible to know with complete certainty until you run an A/B test. Executable hypothesis design is not about proving whether a hypothesis is right or wrong. Instead, it provides a preview of whether the hypothesis can steer the system in the intended direction.

Existing Approaches

Let’s start with one of the most common mistakes made when developing a new event or feature. A competitor game, usually one that is already established in the market and generating revenue, releases a new event or makes a change in the game. Product teams notice the update and begin preparing to add it to their own game as quickly as possible.

The motivation is often driven by FOMO and the belief that “they must know something if they added it”. In this case, A/B testing is rarely performed. The underlying assumption is that if every mechanic matches the competitor’s game exactly, this game will also succeed.

This is one of the main reasons why so many games fail, even when they try proven mechanics that have already worked in the market.

In some studios, this issue is addressed by deconstructing competitor features in detail. The problem is that deconstructions only provide assumptions about the game in which that feature exists, and they are not guaranteed to be accurate. If they were, we would expect all identical games to make money.

Just like a fingerprint, the implementation of a feature is unique to the game it belongs to. From the design phase to development, every step of that implementation is specific to the game in which it is built.

Implementing new features through iteration and A/B testing delivers significant gains compared to the first two approaches. However, this approach assumes that in each iteration we can interpret the event related data correctly and use it to guide the next improvement.

With careful work, this approach can be effective up to a certain point. But when multiple events and other game dynamics are active at the same time, and iterations overlap with different LiveOps periods, the results often reflect what works for that particular moment rather than clearly explaining themselves.

The core issue is that the system itself still cannot be clearly defined on the product or game design side. As a result, the process remains at an intuitive level rather than becoming fully structured and explicit.

A better solution is actually right in front of us, and it starts with integrating formal models of the systems we already design into a simulation. Although the term formal model may sound academic, it simply means defining each feature we add to the game in terms of its inputs, outputs, and interactions with other features using mathematical rules. When these models run together in an economy simulator, they allow us to balance the game economy even before calibrating it with player data. This is especially useful before launch. However, during LiveOps, things become more complex and require more than this.

At this point, I want to emphasize why it is important to define all features as formal models. Their value goes beyond executable hypothesis design. They are also essential for building a solid bridge between game designers and developers:

1. There is no gap between what the game designer prepares and what is implemented.

2. When designing a feature, game designers must think through how it interacts with other systems.

3. The impact of removing a feature from the system is known at an implementation level, not just intuitively.

4. Any system’s simulation matches how it behaves in reality. This allows the simulation to be calibrated using real data.

5. It helps game designers polish the feature before implementation begins.

There is also a commonly misunderstood point that I do not want to skip. For example, you might design a non deterministic chest where the probability of dropping 1000 coins is 10%. However, the real impact of that percentage within the system can only be calculated if we know what proportion of players who have access to the chest actually interact with it. In this case, the chest itself is a sub model. It must be modeled together with the percentage of players in the overall population who open it, as part of a higher level system. These are the kinds of configurations we calibrate once real player data starts to come in.

Sample Hypothesis Model

In this section, without going into too much detail, we will discuss how a simple hypothesis can be expressed as a formal model and what kind of insights it can provide.

For simplicity, I use sample player data from a 100 level range, using average values for each level. In reality, a simulator would run these models for each individual player at every level. Here, however, I only want to illustrate the core logic. For that reason, I made simplifications both in the data and in the assumptions specifically for this example.

Based on the churn and booster level funnels shown above, assume that you want to reduce churn in levels where it is 5% or higher. Instead of adjusting the level parameters to make those levels easier, you consider reducing churn by introducing additional boosters. Based on this assumption, you form the following hypothesis:

If we add extra boosters to levels with more than 5% churn, churn on those levels will drop, and IAPs on other levels will stay stable. This happens because the change targets local difficulty spikes without affecting the overall economy or spending patterns.

Let’s turn the hypothesis into a formal model and see whether the system actually produces the behavior we expect. I prefer to design these models as white box systems, where the logic is explicit and interpretable. Their parameters can also be calibrated using data through regression or supervised learning.

What we should not forget is this: our goal is not prediction. The goal is to run a consistent and explanatory behavior mechanism in the simulation. We aim to build a mechanism that behaves reasonably.

For this example, we will ignore several factors for the sake of simplicity, such as coin earnings, their exchange into boosters, and the impact of difficulty trends on player engagement. We will also assume that the average booster usage represents the number of boosters required for a player to complete a level. In reality, this value may also be influenced by the boosters used by players who churn. In that case, looking only at the average may not be an accurate approach.

First, let’s think about which state could trigger churn. For this model, I make the following assumptions:

1. As we move negatively away from the average number of boosters required to complete a level, the probability of churn should increase. As a player, if I do not have enough boosters, I either need to make a purchase or quit the game at that point.

2. I assume that the churn output produced by this behavior follows a sigmoid function. The fewer boosters players have relative to what is required, the more likely they are to churn. However, if they have enough boosters, or more than enough, that tendency decreases.

Based on these assumptions, we can model churn behavior using the following sigmoid function:

where f(b1, b2) represents the calculated churn value for given b1 and b2, with b1 representing booster consumption and b2 representing boosters at level start. k1, k2, and c are constants to be calibrated.

For the given values, the model explains 81% of the real data. On average, the model’s predictions deviate from the actual values by 19%. For this example, this level of accuracy is sufficient.

As shown in the chart above, introducing additional boosters only on levels with churn of 5% or higher reduces booster pressure not only on those targeted levels, but also on others where no extra boosters are introduced. The reason is that players who accumulate sufficient boosters may choose not to consume them immediately and instead carry them forward to subsequent levels, indirectly affecting the system as a whole. This is critical because our original hypothesis ignored this possibility. The simulation, however, reveals that it must be monitored carefully.

Moreover, actual IAP points decrease in the simulation because the new booster inputs reduce the system’s tendency to generate IAP behavior compared to the original state. As shown in the chart above, IAP opportunity shows a drop on the levels where IAPs were originally made. Previously generated IAPs now have the potential to be lost under the new system behavior.

Even though I did not include the IAP and booster usage models in this article, we should not forget that the simulation runs on these formal models and produces behavior accordingly.

Framework Design

To be able to use formal models, all systems need to speak the same language. There may be more casual ways to achieve this, but designing a framework is always more scalable. It allows new modules to be added or removed when needed.

In this section, I briefly introduce how you can build an economy framework and connect related systems, using a proof of work tool that I developed.

Unit

A unit is the core building block of the economy.

Any measurable element is a unit:

Level, coin, life, booster, real money, rewarded video, session, hour, day, event tickets, collectible items and more.

A unit can have an equivalent in another unit:

Booster = 1200 Coins
Session = 5 Levels
Day = 4 Sessions etc.

A demonstration of the Units module is given below:

Group

A group is a bucket of units with a gacha mechanic.

Groups control how many units can flow through an action. Each group can have multiple units, with optional gacha as in the examples:

Group 1: 1000 Coins + 3 Boosters - all content always drop

Group 2: 1000 Coins (50%) - each time there is 50% chance to drop coins

Group 3: 1000 Coins (50%) + 3 Boosters (50%) - each time there is 50% chance to drop either coins or boosters

Time value makes a unit infinite temporarily:

Group 1: 30 Minutes Booster

Group 2: 1000 Coins + 30 Minutes Life

A demonstration of the Groups module is given below:

Pack

A pack is a ready-to-purchase combination of groups.

Packs can function both as shop items and as reward items. When a pack is used as a feature reward, its contents are managed by that feature.

e.g. Progression-based event rewards.

A demonstration of the Packs module is given below:

Feature

A feature is a dynamic module for liveops event design. Although many different sub-systems can be attached, I considered 5 main systems:

1. Period

2. Rewards

3. Rules

4. Progressions

5. Streaks

It can be designed in any form from Piggy Bank to Battle Pass Plan, from Streak Rewards to Collection Events.

A feature can be modeled to analyse how the game economy reacts to changes in the parameters of a potential event. One event can be a combination of multiple sub-events so that each part can be tested separately.

A demonstration of the Features module is given below:

Resource Flow > Units

A resource flow system defines how modules are activated throughout the levels.

Units section in the resource flow is responsible for distributing feature-specific resources, as well as constant amounts of resources that are guaranteed to be gathered or spent per level.

It is also useful for answering questions such as, “How does the resource balance change if we add X amount of coins at level 120?” without touching any module.

The probability of any resource distribution can be defined directly here if the proxy design is not introduced into the system.

In the image given below, a collectible key is introduced into the system and triggered when the event is active.

Resource Flow > Packs

Packs are introduced through the resource flow to define the levels at which they are available for purchase. They’re based on rewarded videos, such as level-end ad rewards, are also introduced here.

The probability of purchasing a non-free pack depends on the purchasing rules defined in the proxy design.

Resource Flow > Features

Features in the resource flow define at which level an event is triggered, but they do not determine how the event is executed, as that is a feature-specific configuration.

Event joining, replaying, and reward-obtaining probabilities can be defined as constants if no proxy rule is provided.

Resource Flow > Equivalents

As first shown in the Unit section, each unit can have an equivalent. However, this equivalence can change when new packs, events, resources, etc. are introduced into the system.

Equivalents section in the resource flow handles these changes when a new equivalency is defined.

e.g. Introducing a new event increases level completion per session +3. This can either be an assumption or derived from real data:
Old -> Session = 5 Levels
New -> Session = 8 Levels starting from level 40.

Proxy Design

In this section, I group all formal models under proxy design. This makes it possible to manage the models from a single central structure.

Proxy Design module runs 5 major mathematical models designed to simulate player behavior based on either hypotheses or insights derived from analysis of real player data:

1. Churn Rule (how close a player is to abandoning the level)

2. Fail Rule (how close a player is to failing a level)

3. Pack Rules (when a player tends to make an IAP or watch a rewarded video)

4. Consumption Rules (e.g. when a player tends to use a booster)

5. Exchange Rules (e.g. when a player tends to exchange coins for a booster)

These models are game-specific and therefore require separate modeling for each game. In either case, it grounds abstract ideas so the models can be easily improved or completely changed, while also creating coherence between them.

Apart from regular math expressions, supporting custom expressions also increases the depth of the proxy models. Here are some examples:

1. stsigmoid (stochastic sigmoid)

An s‑shaped decision curve that blends a base chance with a ratio and adds mild randomness.

e.g. More booster uses barely reduce failure at first, then sharply improve success after a threshold, before the effect stabilizes.

2. stgauss_score (stochastic gauss score)

A bell‑shaped score centered at a target value that falls off with distance from the target and adds mild randomness.

e.g. At a given level, as difficulty rises, the IAP probability climbs up to a peak, then declines beyond that point.

3. ema (exponential moving average)

A moving average that weights recent values more heavily while still smoothing the overall trend.

e.g. Churn from difficulty may not be just about one level as players react to recent difficulty trends, so using an ema helps capture that behavior.

4. mmin, mmax (moving minimum and maximum)

The lowest and highest values seen over the last n points in a series.

5. ref (reference value)

The value of a variable from player data for comparison inside a formula.

6. exchange

It converts a value into a target unit using the configured unit equivalences.

And that’s it!

Although this is a much broader topic than what can be fully covered in a single blog post, I tried to explain the key concepts as clearly as I could.

Thinking in systems can be demanding, but it is crucial for understanding how decision mechanisms evolve through cause and effect, not only in game systems but in everything we touch in life.

It was a pleasure to write this post, and I hope you enjoyed reading it as well.

See you in the next one!

It’s been a few months since I last published a new article. But here we are! This topic has been on my mind for a long time, and I finally had time to share some important concepts with you. I believe you’ll find it useful!

Hybrid-casual puzzles are rising stars, and the trend seems to continue increasing steadily. In this blog post, we’ll explore a slot-limited puzzle game to model a system that controls level difficulty, and finally, we’ll create a machine learning model to predict the win rate of levels based on a given configuration.

Before we move on, here is Stick Jam, a prototype I prepared for this article:

I inspired by Voodoo’s Slinky Jam to prototype Stick Jam. You can watch the video below to get an idea of its gameplay:

We will discuss 5 major topics throughout the article:

1. Game elements and rules, discussed in Introduction section.

2. Theoretical background of system design in Stick Jam, discussed in Understanding Variable Relationships section.

3. Controlling level difficulty, discussed in Difficulty Adjustment Algorithm section.

4. Modeling player behavior and simulation setup, discussed in Simulation Design section.

5. Win rate prediction for levels, discussed in Predicting Outputs with Machine Learning section.

Introduction

Stick Jam consists of 2 main parts that players interact with:

1. There is an NxM board with sticks on it. The minimum board size is 3x3 and the maximum is 8x8, although there is no theoretical upper limit.

2. There are 2x7 slots. The bottom row is for placing stick colors collected from the board, and the top row is for extra slots. When the “Extra Slot” booster is used, the rightmost color in the bottom row moves to the top row. I also decided to limit the number of extra slots, even though it’s not strictly necessary.

Players try to collect all sticks by checking for color matches on the slots. When 3 of the same color are placed in the bottom slots, they form a match and are removed. If the bottom slots become completely full without any match, the level fails. If players collect all sticks without letting the bottom row fill up, the level is completed.

Levels are generated dynamically based on a difficulty configuration, which we will discuss in the next sections. Therefore, no players encounter the same color sequence.

Special Sticks

1. Double-colored stick: It represents 2 sticks at once, so when collected, it occupies 2 slots.

2. Multi-stick: It has a counter that shows how many sticks must be collected before it is completely removed from the board.

Double-colored sticks tend to make the level finish faster, but also increase the failure probability. They require careful placement, otherwise, it’s easy to end up in a state where only one slot is available but all collectible sticks are double-colored.

Multi-sticks, on the other hand, introduce a bit of chance by hiding the next color, which can make players feel either lucky or frustrated.

Understanding Variable Relationships

Designing a system starts with understanding the internal role of each variable added to it. Then it continues with identifying relationships between variables, observing how they affect system behavior, what hidden features they reveal, and how they respond when a new variable is introduced. These relationships may stem from mathematical dependencies as well as algorithmic constraints. In our case, we’ll see that both aspects must be considered, and each contributes to data-driven level design.

Level difficulty directly depends on how we control the frequency of color-matching in the slots. If the system arranges colors in a way that requires more than the available slots, we call it a “hard level”, otherwise, it's an “easy level”. The transition between difficulty levels is gradual and controllable. This transition is also the key to dynamic difficulty adjustment.

Before diving into the algorithm, let’s start by exploring each variable and their theoretical relationships to define the system’s limitations:

where N_s is the number of slots and N_c is the number of unique colors. This inequality guarantees a solution for the worst-case scenario, which is when there is only one stick to choose from each time after players remove a stick from the board.

If the number of slots is 7, then a solution is guaranteed for up to 3 unique colors in the worst case.

where N_st is the target number of slots used in the color path generation algorithm. This inequality basically states that a solution is always guaranteed when the condition is met. We will discuss how it works when we model the algorithm in the next section.

where N_stick is the number of sticks in a level. It must be a multiple of 3, and the number of unique colors cannot exceed the dividing the number of sticks by 3.

where N_stick,a,avg is the average number of available (ready to collect) sticks from the beginning to the end of the level after each stick is collected. M is the number of moves needed to solve the level. It is equal to N_stick.

Increasing the average number of available sticks gives players more options to choose from and makes the level easier.

Difficulty Adjustment Algorithm

1. Introduction

We discussed game elements and variable relationships up to this point. I strongly recommend reading the previous section before diving into this one. Now, it’s time to bring everything together to create a difficulty algorithm controllable by a few parameters.

First, we should define which variables we can directly change, what output we should expect, and how we can measure it. Measurement is very important, otherwise system design cannot reach its full potential. Even worse, it may turn into a useless model that wastes your precious time.

When we look from the player’s perspective, if any visible layer of sticks shares the same colors, it means it’s easier to select sticks for color-matching. If these sticks don’t share many colors, it forces players to think strategically before removing a stick from the board. Thus, the controlled output should be the stick colors based on the layer they are standing on.

An important point I want to highlight is that we should expect different outputs for different inputs within the same level. This means that stick placement or distribution in a level doesn’t directly affect the output. In the next sections, we’ll see that it affects how we perceive difficulty across levels.

Now, the question is which variables can control the output? If it were possible to change the number of slots dynamically for each level, it could be useful. However, this also has high potential to be very annoying for players. Instead, we can control its counterpart. By adjusting the target number of slots instead of the actual number, we can take advantage of slot-dependent control without modifying the real slot count. When the target slot count is less than the actual slots, the level tends to be easier. If it's greater, the level becomes harder and sometimes it becomes even impossible to solve. I’ll show how this works in this section, so keep reading!

The other variable we can directly control is the number of unique colors. Levels with too few colors would be very boring and lack visual variety. However, randomly distributing colors could naturally lead to quick failure. We will use unique colors and target slots in a way that allows more colors for easier levels and fewer colors for harder ones. This is the level of flexibility we aim to achieve.

You will observe how variables can change the difficulty of the same level in the following videos:

This level is generated with 8 unique colors and only 4 target slots. It can be considered an easy level.

Again, 8 unique colors. But this time, the target slots are 8. Can you tell the difference?

Finally, 8 unique colors and the target slots are increased to 12. It’s basically a paywall level!

The beauty of this algorithm is that it still preserves randomness, so refreshing a level produces completely different color sequences while keeping the average difficulty the same.

It can also be applied to the special sticks defined earlier. Here is an example of a multi-stick level:

This level has 7 unique colors with 7 target slots. Look how the upcoming colors help ease the slots!

2. How It Works

There are 3 major algorithms working together:

1. Sorting sticks based on their parent counts.

2. Creating a color path based on the number of unique colors and the number of target slots.

3. Assigning colors to sticks.

Sorting sticks is the easiest part. When a level is designed, the only requirement is to check which sticks are parents of which. A stick may have more than one parent, or it may have none. If it doesn’t have a parent, it means the stick is ready to be collected.

Color path generation is a bit tricky. Take a look at the following flowchart:

The goal of this algorithm is to create color matches before the theoretical slots are completely filled. It guarantees at least one way to remove sticks from the board, as expected. We’ll look at how it’s affected by the average number of collectible sticks in the next sections. You can also check the Understanding Variable Relationships section for a discussion of the theoretical background.

Here are some examples of generated color paths with different configurations. Each number represents a unique color id:

• Generated color path for 7 target slots and 10 unique colors:

  • 7, 0, 5, 2, 9, 5, 5, 3, 9, 9, 6, 6, 6, 1, 7, 7, 8, 8, 8, 4, 0, 0, 1, 3, 1, 2, 4, 4, 3, 2, 8, 2, 6, 4, 0, 4, 4, 3, 2, 2, 9, 0, 0, 5, 8, 8, 7, 6, 6, 1, 1, 1, 7, 9, 9, 3, 5, 7, 3, 5

• Generated color path for 12 target slots and 10 unique colors:

  • 6, 5, 2, 9, 4, 0, 3, 1, 7, 8, 9, 9, 1, 2, 2, 8, 5, 1, 3, 4, 5, 7, 6, 3, 0, 4, 0, 8, 6, 7, 3, 2, 6, 4, 7, 5, 1, 8, 9, 0, 5, 5, 1, 6, 6, 9, 3, 1, 2, 7, 9, 0, 8, 3, 4, 7, 0, 2, 8, 4

As seen in the generated paths, the algorithm tries to keep the number of slots at the target count and creates color matches just before it becomes completely full.

Finally, we should assign the generated colors to sticks by considering the number of parents in ascending order. After this step, the level is ready to play!

These algorithms can also be applied to dynamically control level difficulty. Assume that players continue to fail a level. It’s now possible to decrease the difficulty automatically after N attempts, based on your data and what you consider the sweet spot.

Although I didn’t introduce a flexibility variable, it’s also possible to control randomness with such an addition. However, that would be too much for this article, and it’s always better to model your system step by step. After each step, observe the real-world behavior and then calibrate the parameters.

Simulation Design

Without testing the algorithm in real-world, it’s not really possible to predict the results accurately. Unlike what we expect theoretically, systems may behave differently when deployed in a real environment. On the other hand, testing with real players is often costly, especially in terms of time. An alternative approach is to simulate the real environment with a proper setup. Although it’s not a 100% replacement for real-world testing, it provides valuable insights into how solid your system is and can serve as a reference point for adjusting configurations before real tests.

I decided to use simulations to generate a batch of data, as shown in the table below. Here is the configuration used:

• Number of levels: 17 (with various number of sticks)

• Target slots: 4 to 12

• Unique colors: 3 to 12

• Simulated players per level: 1000

Collected data:

• Average number of collectible sticks

• Win rate

• Total 1449 rows

Note that when the number of sticks cannot support enough unique colors for the given configurations, as discussed in the Understanding Variable Relationships section, those setups are skipped.

None of the simulated players are allowed to try a level more than once. Thus, I didn’t focus on the number of attempts, but rather on the win rate. However, it’s possible to calculate the average attempts per virtual player by dividing one by the win rate.

The table below shows 10 rows of randomly selected data from the dataset:

Modelling Player Behavior

Designing a solution checker algorithm is a good approach if you want to ensure that a level has a solution. However, it lacks two important things. First, it doesn’t tell us how players perceive the level's difficulty. Second, it’s not applicable when we intentionally introduce unsolvable levels (e.g. when we expect players to use boosters earned through gameplay). So, what should we do? The best approach is to model player behavior by thinking like a player. Put yourself in the player’s position and try to understand: How would you play? How would you try to solve the level without using boosters? And finally, what limitations would you have as a player? A solver algorithm can try multiple paths to find a solution or the best one, but a player doesn’t have that luxury.

In our case, let’s look at how a player might play and what limitations they face:

• They must follow the gameplay rules. There are no exceptions.

• They can decide which sticks to remove from the board based on visible sticks. They cannot predict the color of hidden or upcoming multi-sticks.

• They can also decide which sticks to remove based on the state of the slots. They may consider whether there is a color match, whether a slot is almost full, or whether it is empty.

• They can combine these observations to choose the best stick to remove.

• Even if they construct a strategy, they cannot keep all game states in mind, unlike a solver that traces every possible path. Instead, they have limited ability to track possible moves, and this is the core of the player model.

Consider the following flowchart of the player model:

As a reference, I designed and played many levels, observed how I reacted while collecting sticks, and took notes. Since it’s not the main focus of the article, I won’t go into every detail of how it works. However, as shown in the flowchart, it uses a type of weight-based algorithm to decide which stick to collect. This allows the algorithm to behave more like a real player rather than a solver.

Predicting Outputs with Machine Learning

As we discussed earlier, the whole point of the simulation was to create a dataset for the machine learning model. Our goal in this section is to find a model that fits the dataset and makes sufficiently accurate predictions for win rate. This will then help us predict the win rate before we even begin designing a level.

It is indisputable that if we had real player data, it wouldn’t result in a dataset this clean. What we would normally expect is noisy data with various disturbances, such as failures caused by bugs, incorrect or missing analytic events, targeting the wrong audience, and so on. However, since we are using simulation results, we assume the dataset contains no noise other than the natural variation in simulation outcomes. I tried to minimize this by increasing the number of simulated players to 1000, but it cannot be completely eliminated.

As the ML model, I chose Gradient Boosting for win rate prediction. The selected features were N_st, N_c, N_stick,a,avg, and N_stick. During cross-validation on the training data, the average R² score was 0.938 with a standard deviation of 0.011, and the RMSE was 0.098. On the test set, these values were 0.952 for R² and 0.086 for RMSE. I also tested different hyperparameter configurations to avoid overfitting as much as possible. The model appears to explain 93.8% of the variance in win rate with the given feature set, and its performance was even better on the test data. The higher R² score on the test set is noteworthy, as this may be due to the simplicity of the data structure or the effect of chance. When tested with real-world data, this outcome may very well reverse. Feature contributions were 46.8%, 21.1%, 19.5%, and 12.6% for N_c, N_st, N_stick,a,avg, and N_stick, respectively. Keep in mind that while the results are promising for this article, larger datasets and further tuning are needed in real-world scenarios for better predictions.

Let’s continue with the predictions. Since it’s not possible to include every combination here, I decided to choose a few configurations that make sense to examine.

Configuration 1:

• N_s = 7

• N_stick,a,avg = 4

• N_stick = 42

Result:

In the chart above, N_stick,a,avg, N_stick, and N_s are held constant, while N_c and N_st vary. As expected, when the number of unique colors is 3, the outcome becomes completely independent of the target slots. This theoretically ensures a 100% win rate, as discussed in the Understanding Variable Relationships section.

As the number of unique colors increases, the win rate decreases. However, maintaining a higher number of target slots slows down this decline. For example, when the number of unique colors is 10, the win rate with 5 target slots is nearly four times of the lowest value.

It’s also interesting to observe that continuously increasing the number of target slots eventually stops making a difference. This is expected, because when the target slot count is lower than the actual number of slots, the solution becomes more obvious (and the level easier). But as we keep increasing the target slot count, the added difficulty loses meaning, as players tend to fail faster.

Another notable point is that the win rate is predicted to be very high for all target slot values until the number of unique colors reaches 6. I assume the average number of collectible sticks helps balance the negative impact of increment in the target slots. However, this would need further testing with new levels to confirm.

Configuration 2:

• N_st = 7

• N_s = 7

• N_stick = 42

Result:

In this second chart, we observe how the average number of collectible sticks affects the win rate for different numbers of unique colors. N_st, N_s, and N_stick are held constant. The first observation is that increasing the number of collectible sticks initially causes a sharp drop in the win rate.

The reason is that when the average number of collectible sticks is 1, there is only one possible move at a time. This removes the influence of player decision-making. However, when there are two or more options, the number of unique colors starts to heavily impact the outcome.

As we continue to increase the average number of collectible sticks, we also see a rise in win rate. This aligns with the theoretical expectation that getting closer to 2*N_c+1 improves win probability. This effect is especially noticeable when the number of unique colors is low.

On the other hand, the model seems unable to accurately capture win rate when the average is 1, as the theoretical expectation is 100% in that case.

As we observed, level design cannot be considered independent from system design. Relying solely on randomness turns the game into a black box. That’s why measurement is like a two-sided coin: one side is modeling level configurations and building a controllable difficulty system, and the other is collecting analytical data. Combining both allows you to make better predictions and more importantly, understand which variables affect player engagement. I would also recommend reading my other blog post Designing Tripeaks Solitaire Levels with Predictable Outcomes which covers a similar topic.

This was my third article, and I really enjoyed preparing it. I hope you liked it too.

See you next time!

In this article, you will discover why we need and how we can design a properly constructed level generation algorithm, supported by theoretical calculations and compared with Monte Carlo simulations.

What you won’t find is a complete procedural level generation system, as I don’t show how to generate level layouts. That can be the subject of another post.

Keep in mind that without the involvement of a level designer, levels would be completely soulless. Therefore, the system I describe in the post is not a replacement for a designer, but a supportive tool for them.

I selected tripeaks solitaire for this post, as it is a trending genre for a while. Although this is a highly technical article, I did my best to smooth out the sections and add gameplay videos as much as possible.

There are 4 main topics throughout the article:

1. Basics of casual Tripeaks Solitaire, discussed in the Introduction section.

2. Theoretical aspects, discussed in the Key Considerations section.

3. How to generate ranks, discussed in the Auto-Rank Generation Algorithm section.

4. Player model, simulations and their results, discussed in the Monte Carlo Simulations section.

Additionally, I specifically added a simple obstacle mechanic to show how it can affect the gameplay, as well as the effect of the average number of open cards, which is also an important concept in level design.

In the upcoming articles, I will also discuss live event modeling and how to create a balanced game economy around it. So I would recommend subscribing if you haven’t already.

Introduction

Before exploring the auto-level generation concepts, it is good practice to review the game elements. Although I covered a broader version in the Candy Crush Solitaire Deconstruction and Experimenting with Auto-Level Generation article, we will specifically focus on the parts relevant to this article.

In a casual tripeaks solitaire game, the goal is generally to clear the entire board (tableau) of cards, unless the objective is to collect specific items, create desired streaks or achieve a predefined score etc. Players try to match the top waste pile card with board cards that are either one rank lower or one rank higher. Card ranks are cyclic, meaning the first and last values are also considered neighbors. Although a standard deck consists of 52 cards and 4 suits (hearts, diamonds, clubs, and spades), it is not mandatory to stick to these numbers. Card generation can be handled dynamically based on the situation.

The board consists of open (playable) and hidden cards, as well as obstacles that prevent cards from being revealed. The stockpile (deck) is used when the top card of the waste pile does not match any of the board cards. The hold slot is a unique mechanic introduced in Candy Crush Solitaire, however, I included it because it is a cool feature. Players can set aside the first card from the waste pile into the hold slot to create more consecutive matches. It is completely optional to use.

Key Considerations

In this section, I will cover some important concepts. If you have read the auto-level generation section of the Candy Crush Solitaire Deconstruction and Experimenting with Auto-Level Generation article before, you may skip some parts. However, I recommend reading all of them, as they provide deeper explanations of the auto-level generation approach and how I evolved the system.

1. Group-Based Randomization

Unlike a pure probabilistic approach, constrained randomization guarantees that an event will occur within a given closed space while keeping the occurrences random within the given space boundaries.

Assume you have 10 cards, each with a 10% chance of being a matching card. In a non-deterministic approach, there is no guarantee that you will find a match even if you draw all the cards, nor is there a guarantee that you will have only one match. On the other hand, constrained randomization ensures that exactly one card will be a match while keeping its position random.

In the previous article, I showed that we can manage the number of matches between board cards by using constrained randomization to create consecutive chains. For example, we can set up a configuration consisting of 5 cards, where only 2 matches will occur. In this scenario, the following possibilities become available (M: matching card, U: unmatching card and 2 matching cards create 1 match):

• [M-M U M-M] e.g. [2, 3, 5, 6, 7] and total matches = 2

• [M-M-M-M U] or [U M-M-M-M] e.g. [2, 3, 4, 5, 7] and total matches = 2

The problem is that even though the total number of matches seems equivalent, the longest consecutive matches in the second group are three times those in the first one. Moreover, we cannot guarantee the longest or shortest chains we desire. So, how can we solve this?

The solution comes directly from the group itself. Instead of preparing a configuration with 5 cards in a group and 2 matches, we can represent it with 3 different blocks, in total, with 2 matches, and this can be in any form:

• [M-M] [U] [M-M]

• [U] [M-M] [M-M]

• [M-M] [M-M] [U]

The biggest difference is that any two blocks must now have ranks that do not match anymore:

• ✅ [2, 3], [10], [5, 6] → none of the groups are matching with each other.

• ❌ [2, 3], [10], [4, 5] → first and last groups form a consecutive match.

Then, we shuffle the groups. This way, the result remains randomized, but with more control over the outcome. We will dive into the details of the algorithm in the later sections. However, if you want to see how it works visually, watch the video below.

3 repeating groups are defined with sizes 3, 2 and 1 respectively. I didn't apply the shuffling so you can track the cards based on their groups:

• START → [A, 2, 3], [8, 9]

• [A, 2, 3], [8, 9] → [A, 2, 3], [6]

• [A, 2, 3], [6] → [6], [J, Q, J], [4, 3], [8]

• [6], [J, Q, J], [4, 3], [8] → [6], [J, Q, J], [4, 3]

• [6], [J, Q, J], [4, 3] → [J, Q, J], [4, 3], [8 _ _]

• [J, Q, J], [4, 3], [8 _ _] → [J, Q, J], [8 _ _]

• [J, Q, J], [8 _ _] → [8 9 8]

• [8 9 8] → [2, 3]

• [2, 3] → END

2. Variety of Card Ranks

How many unique card ranks can be visible at the same time in a level? How can we manage the difficulty of the level without compromising the fun factor? One of the key considerations we should have an eye on is the use of card rank variety in the algorithm, without alienating player engagement.

When the number of unique cards increases:

1. It creates a dynamic level from the player's perspective, as it provides more possible and random ways to complete the level.

2. It becomes harder to manage the level difficulty, because undesired matching conditions become unavoidable with increasing number of open cards.

Look at the following examples. They represent the open cards for 2 different levels. Although the number of required stockpile cards is the same for both in the best case scenario, which one do you think seems more attractive in the overall picture?

• [7, 8, 9, 10, J, Q]

• [7, 8, 7, 8, 7, 8]

My approach is to minimize the duplication of ranks for any state of the level without sacrificing the level configurations that we will discuss later. Keep in mind that we cannot make all the cards unique, as it would completely eliminate the chance factor. In fact, as we will discuss later, the algorithm will never try to keep all the cards unique.

Any level designer should be informed in real-time by the level tool while designing the level, so they can achieve the desired outcome without spending too much time on trial and error. We all know that it is unavoidable to test the levels before launching them, because we have to ensure how the level feels. However, it is always beneficial to speed up the level design process with automated tools, as we are currently starting to discuss.

Let’s start with calculating average unique cards we can have

where N_avg_unique_cards is the average number of unique cards a group can have and N_groups is the number of groups decided at the beginning. The number 12 comes from subtracting 1 from the total number of unique cards, which is 13 (from A to K).

Let's assume there are, on average, 6 cards open on the board in any state and 3 groups with sizes 2, 1, and 3, respectively. Based on the equation, N_avg_unique_cards becomes 3. This means that, on average, we are allowed to use 3 unique cards per group without breaking the group sizes.

In order to keep it simple, let’s start from A and increase the rank to fill the groups:

If a new card is revealed after each card is collected from the board, and we also continue to collect all group cards in an ideal scenario:

Although I keep it simple in this example, the total number of group sizes is not necessarily equal to the number of average open cards.

Let's look at another example. This time, there are 4 groups with sizes 3, 2, 3, and 4. Again, assume that the number of open cards in any state is equal to the total group sizes. Based on this new configuration, we calculate N_avg_unique_cards as 2.

Initially, we can have a card set like this:

If you didn't notice, the system tries to form the given number of groups without creating any consecutive matches between them, even if there are 12 cards open on average.

For any group, the minimum number of unique cards can be described as:

where N_group_size is the number of cards per group. Because we know the number of board (tableau) cards and groups through level design, we can calculate the average group size:

At this point, it is also possible to calculate the average number of groups that become visible based on the average number of open cards. For example, even if 10 groups are defined at the beginning, only 3 groups may be visible at any given state:

where N_avg_groups is the average number of visible groups, N_avg_open_cards is the average number of open cards at any state, and N_avg_group_size is the average number of cards per group.

We will use these equations in the next sections to calculate required amount of stockpile for any configuration.

3. Effect of the Hold Slot Use

Decreasing the number of unique cards per group increases the use of hold slots due to the increasing number of duplicate cards:

There are 2 ways to use the hold slot:

1. Any 2 groups can be connected by a missing number that creates a consecutive sequence.

2. Duplicate cards in a group can be collected for groups with a size greater than 2.

Then, equation becomes:

where N_avg_hold_slot_use is the maximum number of possible hold slot uses and p_hold_slot_use is the probability of hold slot use for a player. The reason we divided it into 2 is that we cannot use the hold slot for both conditions at the same time.

4. Stockpile Requirement

Another important variable that level designers should be aware of is the number of stockpile uses required. An increased requirement for stockpile use is generally related to level difficulty and provides insights to the level designer.

where p_stockpile is the probability of matching cards coming from the stockpile.

It is also possible to calculate the max expected stockpile use:

5. Consecutiveness

Consecutiveness is a measure of consecutive matches on the board in a row. If you watch the video, you will see that there are 17 matches on the board (excluding the first collected card), and its consecutiveness is 1 since we can collect all at once.

We can calculate the consecutiveness as a configuration variable:

and we can also use the following formula to compare simulation results:

It is also possible to measure the effect of the hold slot use after the simulation is completed:

Keep in mind that when I use consecutiveness as a configuration variable, the availability of hold slot use isn't considered, as its effect can only be measured after its use. We will compare c_sim, c_sim_hold_slot and c_config in the Monte Carlo Simulations section.

Another related measurement is the average number of consecutive matches. Different from consecutiveness, we can define consecutive matches based on the number of cards matched in a row, except the first card. Its calculation, on the other hand, cannot be easily made by a simple approximation due to its recursive nature. Consider the following example:

• Open Cards: [1, 2, 3]

• The waste pile card should match with either 1, 2, or 3.

• There are 2 ways to have 3 consecutive matches in a group:

  • 1 → 2 → 3, no card left

  • 3 → 2 → 1, no card left

• There are 2 ways to have a 2 consecutive matches in a group:

  • 2 → 3, 1 left

  • 2 → 1, 3 left

• There are 2 ways to have a 1 card in a group, if the previous chain has 2 cards.

• Probabilities: 67% 3 consecutive matches, 33% 2 consecutive matches and 33% 1 match only. Keep in mind that P(1 match | 2 matches) is 33%, so if you want to calculate the overall probability, you should sum the probabilities of 3 and 2 consecutive matches, which equals 100% as expected.

What if we have more than 3 open cards? This will lead to multiple branching possibilities each time the player chooses a path. I handled it with a recursive algorithm, and I discussed the results in the Monte Carlo Simulations section.

6. Effect of Obstacles

Obstacles are not only meant to keep players engaged with new content, but they are also crucial in level design when you want to create specific paths for booster use, as well as to balance the level difficulty. They are vital for monetization and can be very powerful when used effectively. However, it can also easily become a nightmare for level designers if the possible outcomes cannot be foreseen during the level design, such as whether a solution is available or the potential ways the level could be failed related to obstacle placement.

Brick Wall Obstacle

Specific to this article, I created a brick wall obstacle that requires players to completely break it in order to open the card behind it. When the player collects a card, all brick wall obstacles in the front line take damage. A total of 3 damage is needed to break it completely.

Normally, it is expected to flip the card behind immediately when it is no longer blocked by a wall piece. However, I avoided adding such additional details to focus on the main goal of this article. Therefore, if you notice in the videos that a card is not flipped even though the wall piece is removed in front of it, this is the reason.

You can watch the video below to see how it works. We will also discuss its effects in the simulations later.

Auto-Rank Generation Algorithm

Although the rank generation algorithm itself is easy to follow, as shown in the flowchart, the tricky part arises when a new group is created. The challenge is to find a random non-matching rank while ensuring that its neighbors also have the potential to avoid matching with other existing groups. There are several possible approaches, including ignoring future groups' rank intersections. However, my approach is to find the farthest non-matching numbers in a cyclic group (since A and K are also neighbors), so that it can maximize the separation between existing and upcoming groups. For example:

• [A, K, Q, J, 10, 9] is current group on the board.

• Available non-matching ranks are 3, 4, 5, 6, and 7. Normally, we could randomly select any of these values for the new group.

• 5, on the other hand, is the farthest rank, so the algorithm chooses it.

At some point, however, assigning a random rank may become unavoidable and it directly affects the consistency between theoretical and real results. This is why the number of cards, obstacle placements, average number of open cards, number of groups, and group sizes become very significant.

Monte-Carlo Simulations

Monte Carlo simulation is a very useful technique when you need to observe a system's behavior with given initial parameters. You can either run it with a mathematical model or a computational model.

Simulations help create solid hypotheses that provide a basis for a better-structured A/B test, rather than trial and error, which causes the loss of money and most importantly, time.

A tripeaks solitaire game, in our case, requires a computational model to imitate the game so that we can create scenarios close enough to real-life situations. As you read, we have already discussed the theoretical facets of the system, and in this section, we will test them against the simulation results.

There are 4 main parts in the simulation system:

1. Core system, which includes all group-based randomization and related algorithms.

2. Game system, which includes everything about the game logic that imitates tripeaks solitaire.

3. Player model, which emulates player behavior based on a given decision-making logic.

4. Simulation environment, which connects all modules to run the simulation.

I used Python for the simulation and Unity for level design. The core system is also implemented in Unity to record the gameplay videos shown throughout this article.

These initial parameters are given to run the simulation:

• Level configuration: they are generated from Unity.

• Number of players.

• Max iteration per player: we don’t want players try to complete the game forever if they somehow stuck.

• Groups, as we discussed in Group-Based Randomization section.

• Shuffle groups.

• Stockpile matching probability parameters, based on constrained randomization.

• Hold slot use probability.

• Consecutiveness (calculated only for the probabilistic card generator model): This parameter represents the probability of generating a matching card between board cards. For example, if it is 1.0, it means that each next card will have a match with an open card on the board. Its value is calculated as shown in the Consecutiveness section.

Level configurations, groups, hold slot use probability, and consecutiveness change with different experiments. The number of players, max iterations per player, shuffle groups and stockpile matching probability are the same for all simulations. Their values are 1000, 1000, True and 1, respectively. Stockpile matching probability is always set to 1 to remove its effect on the number of stockpile cards drawn per player. Groups are always shuffled for each player to ensure that different players encounter different variations of the same level as much as possible.

1. Player Algorithm

As shown in the flowchart, players are not trying to find the best path, instead, they are playing randomly, in a way that makes sense from a logical perspective. Hold slot use depends on the probability, p_hold_slot, given in the configuration.

2. Simulation Results

In this section, you will find the initial configurations, simulation results, comparisons with theoretical calculations, and gameplay records of the levels simulated.

Simulation 1: Comparison with the Probabilistic Card Generator Model

So, you may think that what’s the point of creating a structured system while we can just use a purely probabilistic method while generating the ranks. Why do we need to invest time, when it is nearly as easy as writing, “I want the matching probability of the next opened board card to be 50% with another board card”?

Look at the videos below. The first one is completely based on a probabilistic model:

And the one below is the structured one that we discussed:

Did you notice any difference? It's hard to tell, except that I clearly drew 2 more cards in the group-based model. This is the main reason why so many of us don’t care too much about how the model will affect the result: because, obviously, we can’t just tell by playing it ourselves, and this can end with a very unpleasant result.

Let's first look at the configurations:

1. Level configuration: layout is as shown in the video. 24 cards in total.

2. Groups: 4 repeating groups with sizes: 6, 3, 2 and 1, which include both long and short group sizes. 6 is selected for the longest group to avoid exceeding the total number of unique cards (13 in total, from A to K) because these groups are repeating, and 2 groups of size 6 make a total of 12 cards. The total sizes of the other groups are also selected as 3, 2, and 1 for the same reason, and their total again equals 6. The total size of the first and second groups becomes 9, which is the max number of open cards that can be visible by design.

3. Hold slot use probability: 0.

4. Consecutiveness: 0.7 (calculated, only for probabilistic model).

The longest chain is the maximum consecutive matches made by a player until the level is completed. As shown in the chart above, 77% of the players gather around 6 in the group-based model, if we allow a ±1 tolerance in length and this value is 54% for the probabilistic model. While only 7% of the players in the group-based model exceed 7, this is 38% for the probabilistic model. So, if you design a level expecting most players to collect a max of 6 cards in a row, think twice if you are using the probabilistic model!

The theoretical average consecutive matches value is calculated as 1.1, while it results in 1.5 for the group-based model and 2.0 for the probabilistic model.

The number of cards drawn from the stockpile is the core of level monetization, and it is normally one of the easiest configurations you can adjust. If you know your level needs 10 cards to solve, you may start the level with 9 cards, giving you a chance to encourage players to spend currency for extra cards. If you want a real example, read the sections starting with Data Collection Methodology of the Candy Crush Solitaire Deconstruction and Experimenting with Auto-Level Generation article.

Look at the stockpile use comparison chart. Theoretical min and max values are calculated as 8 and 14, respectively. Therefore, if you are designing a level, you should expect most players to spend within this range. 96% of players in the group-based model fall within this range, while 69% of players in the probabilistic model do. However, this isn’t the worst part: 30% of players in the probabilistic model don't even need to spend the theoretical min amount of stockpile cards, while it is only 3% for the group-based model. Do you really want to give up 30% of the players? They won’t even need to use any boosters!

I assume that we’ve agreed on why a structured model is better than a purely probabilistic model. Now, we can start exploring the behavior of the group-based model with different configurations.

Simulation 2: Long Groups

Long groups are generally the safest when generating ranks when they used with other long groups, because it is possible to duplicate numbers to avoid intersecting with other groups. We will examine this scenario in this simulation.

1. Level configuration: layout is as shown in the video. 24 cards in total.

2. Groups: 3 repeating groups with sizes of 8.

3. Hold slot use probability: 0.5 for hold slot use on.

I included hold slot use because I was very curious about how it would affect the result. When hold slot use is enabled, it is used an average of 2.7 times in this simulation.

If we again consider the longest group, which is 8, and also include 7 and 9 with a tolerance, 75% of the “hold slot use off” players gather around it, while this percentage is 82% for “hold slot use on” players. Nearly 25% of the “hold slot use off” players fall below 7, while this is only 5% for “hold slot use on” players.

The main reason is that when we increase the size of the group, the probability of having a matching waste card with a rank in the middle of the group increases, causing it to behave like 2 separate, neighboring groups. Hold slot use, on the other hand, unites these groups again.

We can look at the average consecutive matches to see the overall picture. It is calculated as 2.5 theoretically and results in 3 and 4.5 for the “hold slot use on” and “hold slot use off” scenarios, respectively.

Theoretical stockpile use is calculated as min 3 and max 12 for “hold slot use off“ and min 1.8 and max 12 for “hold slot use on”. Due to the increasing matching probability of middle cards, theoretical max tries to handle the worst case scenario, which is nearly not happening as in the chart.

Average stockpile use is 6.4 for “hold slot use off“ while it is 4.7 for “hold slot use on“.

Simulation 3: Short Groups

When we decrease the group size while also increasing the number of groups, it is possible to bump into the scenarios where avoiding intersections or neighbor ranks is impossible. In this simulation, we will test this.

1. Level configuration: layout is as shown in the video. 24 cards in total.

2. Groups: 3 repeating groups with sizes of 4.

3. Hold slot use probability: 0.5 for hold slot use on.

As seen in the chart, 86% of “hold slot use off” players reach a longest chain of 4, increasing to 96% when including a tolerance of ±1. For the “hold slot use on” players, these values are 44% and 53% respectively. We see a peak at 8, with nearly 25% of “hold slot use on” players, because it connects 2 groups.

The hold slot use average is again 2.7 as in the long group configuration.

Theoretical consecutive matches value is calculated 1.8, while simulation results are 1.9 and 2.6 for “hold slot use on” and “hold slot use off” cases, respectively.

Theoretical min and max stockpile use values are 6 and 12, respectively, for the “hold slot use off” case, while it is 3.2 and 12 for “hold slot use on”. Average number of cards drawn drops from 8.5 to 6.9 when hold slot use is enabled.

When we consider all theoretical calculations, they seem to construct a solid base overall, providing enough insights to begin.

Simulation 4: Effect of Obstacles

As we discussed in the previous sections, obstacles can easily cause a level to fail, even if you think there is a solution. The best way to experiment with these cases is to use a simulation for testing.

Watch the following videos. A solution, most of the time, is possible:

However, the obstacle mechanic and its placement can lead to paths that are not possible to solve:

Regardless of whether you are designing the level with the intention of having several paths to fail states, which is expected (otherwise, we couldn’t challenge the players), we should know what percentage of players will face this situation. In this experiment, we will examine it.

1. Level configuration: layout is as shown in the video. There are 24 cards with 5 brick wall obstacles.

2. Groups: 12 groups with sizes 4, 3, 2 and 1. There are 7 groups with size 2 and 3 groups with size 1.

3. Hold slot use probability: 0.

Simulation results showed that 89% of the players completed the level successfully, while 11% failed. A hammer booster would be very useful for these failed players.

Theoretical consecutive matches value is calculated as 0.8, while the simulation result is 0.9. Theoretical min and max for stockpile use are calculated as 12 and 14, covering 77% of the successful players. There are 15% of players who draw less than 12 cards, which is a bit more than expected. The main reason is that theoretical calculations don’t account for obstacle use, and it would be good to consider the equations based on the introduced obstacle mechanics.

Simulation 5: Effect of the Number of Open Cards

In this section, we will discover how the average number of open cards affects consecutive matches and stockpile use.

In total 7 card layouts tested with 3 different group configurations:

• Level configuration: 7 layouts as in the images below. It is assumed that “1, 2, 3, 4, 6, 8 and 12” cards are open on average for each layout.

• Groups: Balanced (from simulation 1), Long (from simulation 2) and Short (from simulation 3).

• Hold slot use probability: 0.

1. Consecutive matches peak when there is only 1 card open, as expected, because the player has no choice other than collecting the only open card.

2. There is a decline when we start to increase the average number of open cards until 4, because the stockpile deck now has more choices to match with a card from the board, causing fragmentation of the groups.

3. After 6, we start to see an increment. The main reason is that random ranks start to rise, as it becomes unavoidable to find a rank that is not neighboring two different groups.

4. Long groups cannot maintain their group sizes when the number of open cards increase because of the fragmentation we discussed in the Simulation 2: Long Groups section.

5. Balanced groups performs well with minimal change. Consecutive match loss percentage based on the max value for each configuration in the worst case scenario:

   1. 30% for balanced groups config.

   2. 59% for long groups config.

   3. 47% for short groups config.

1. When there is only 1 card open on the board, we see the minimum number of stockpile uses, as expected, because only 1 stockpile card is enough to collect each group cards.

2. Balanced groups config requires more cards, as its average group size is 3, shorter than the average of the short groups config, even though it includes a longer group size.

If we consider that most levels vary between 3 to 6 open cards on average, both charts show that groups have a minimal impact on consecutive matches and the average number of cards drawn. Unless it is a custom rank design, we should expect no major change in these values just by changing the number of open cards.

It would definitely be better to experiment with more configurations. However, I believe it is enough for the context of this article.

As we experienced with simulations, most of the time theoretical calculations give results close to those of the computational model. This means that we can keep the chance factor in the levels while predicting and controlling the outcome.

I believe you enjoyed reading the article. Although it is a highly technical post, I tried to minimize the use of technical terms as much as possible for a better readability. You are welcome to ask questions if you have something in mind you are curious about.

Thanks and see you next time!

Welcome to my very first post on Substack!

After years of hands-on experience in game systems design, I've decided to share valuable insights with you in this blog!

Let’s start!

King finally launched its brand new tripeaks solitaire game, Candy Crush Solitaire globally. You'll be captivated from the first level, thanks to its smooth animations and cute graphics. Although I had the opportunity to test the game before the global launch, I waited for the official release to write this article and access the most recent version of it.

In this article, you will find 3 main topics:

1. Deconstruction - I tried to keep it as brief as possible and supported my findings with the data I recorded. You will discover the game mechanics and how they work.

2. Data Analysis - In this section, I explain how and why I collected the data, as well as how I processed it to extract information. You'll also find key concepts to help you better understand the charts.

3. Auto-Level Generation - How can we auto-generate levels using just a few configurations? This section is dedicated to level generation experiments based on constrained randomization.

FTUE & Tutorials

Candy Crush Solitaire has a smooth FTUE, supported by a classic approach with bubble tutorials that teach players how to match cards, assuming they've never played tripeaks solitaire before. Obstacles are not introduced until level 22, unlike match3 games like Royal Match, which introduce them from the first level.

The game directly starts at level 1 after the Terms of Service and notification permission popups, and it never interrupts gameplay in the early levels if the player follows the desired path. If the player waits or makes a wrong move, a bubble or feedback animation plays instantly to guide the player back onto the correct path.

Before diving into the details of the systems, it's best to introduce the interactive elements in the game. I’ve included a short introduction section defining the related UI elements to make the rest of the article easier for the reader to follow.

Keep in mind that any game mechanic mentioned in this article is always defined in detail in later sections. Thus, keep reading!

Definitions of Game Elements

As a well-known mechanic in the puzzle genre, players can select boosters at the beginning of the level. There are currently 2 pre-level boosters. The last one is marked as “coming soon”.

The game includes all the classic elements of a tripeaks solitaire, in addition to obstacles, power-ups, streak meter, in-level boosters, level rewards and hold slot.

Core Loop

I always like to define the core loops as a nonremovable / unchangeable loop of the game, so that we can identify the fundamental structure that engages players. In this scenario, level progression is defined as the core loop that also feeds meta layers of the game, as in the core loop diagram.

Players must spend coins or one ticket per level to enter. Using pre-level boosters is optional unless the win streak mechanic is active. The main goal is to clear the board completely by collecting all cards on the tableau. Successfully completing a level rewards the player with coins and other currencies used in meta layers. In case of failure, the player must retry the level to progress. Finally, there is no way to replay the same level after a successful completion.

Meta Loops

1. Postcard Progression

Postcard progression is the first meta loop introduced to players. Although the fast progression on the first postcards creates short-term engagement, it mainly aims for long-term engagement. Completing levels awards players with energy, which is used to decorate the postcard with new scene objects. When a postcard is completed, next one becomes available.

In the first 100 levels, there are 6 postcards:

1. Waikiki Beach (Hawaii, USA)

2. Eiffel Tower (Paris, France)

3. Central Park (New York, USA)

4. Higashiyama District (Kyoto, Japan)

5. Swiss Alps (Altdorf, Switzerland)

6. Pyramids of Giza (Giza, Egypt)

Although the postcards look pretty good and the animations are decent, the progression doesn't initially feel satisfying because the changes on the postcard are subtle, and it is already filled with colorful objects. However, after the postcard is completed, the final animation showcasing the entire progression is very satisfying as shown in the video above.

2. Weekly Challenge

Weekly Challenge becomes available after level 5. It is a competition based social feature where players compete on a leaderboard to reach the top 3 before the week ends. It creates a mid-term engagement from the very early stage of the game. Players collect stars by completing levels, and those who successfully fill the streak meter are rewarded with additional stars, that provides a competitive advantage. Top 3 players are rewarded with various prizes, including coins, boosters, deck parts, and card packs.

3. Card Deck (Skin) Progression

Deck parts can be obtained through progression in other meta layers to unlock new deck skins. It targets players who have already enjoyed the game and want to customize their gameplay experience. This feature becomes available after level 9.

4. Cotton Candy Clouds Event

Cotton Candy Clouds is a time-limited, milestone-based event that resets progression and refreshes rewards after a certain period. I also encountered a name change from “Cotton Candy Clouds” to “Bubble Gum Parade”. Players are supposed to collect a card of a specific color (event currency) to reach each threshold. Each milestone completion rewards players with different prizes. It becomes available after level 12.

5. Album Progression

A collectible album mechanic drives long-term engagement thanks to the satisfaction of finding new items and achieving milestones. Collection card packs can be found in levels marked as including a pack. Additionally, other meta layers also provide some card packs as rewards. Each new album is unlocked at a certain level. Completing an album gives a grand reward, while reaching a milestone by collecting a specific number of cards provides a small coin reward. It becomes available from level 28.

6. Chocolate Hunt Event

Chocolate Hunt is a time-limited event that becomes available after level 46. Each successful level completion rewards the player with spoons, which are used to break the chocolate and reveal candies. When the candy box is ready, a reward is given, and the next box becomes available with a larger chocolate bar. Each stage requires more spoons to complete.

7. Salmon Race Event

Salmon Race is an optional, time-limited, competitive event introduced after level 50. Although it was available before the global launch of Candy Crush Solitaire, I haven’t bumped into it again since then, probably because of an ongoing A/B test. Max 4 players with same skill level are grouped to compete in each race. Players must complete 4 consecutive levels without losing before others to obtain stage rewards and unlock the next race with better prizes.

8. Tug of Cards Event

Tug of Cards is an optional, time-limited, competitive event introduced after level 75. There are 2 teams, each consisting of 20 players, competing against each other to collect the card type (event currency) decided by the team leads in order to defeat the opponent. The team with the higher score at the end of the event wins and receives the grand prize. Additionally, players within the same team also compete against one another to rank up and earn more rewards, even if their team loses.

Other Meta Mechanics

1. Offline (Idle) Earning

At the end of the level 4, an offline rewarding mechanic, typically seen in idle games, is introduced. This mechanic rewards players with coins every 4 hours. Unlike in most idle games, time continues to count even when players are online. If we assume players are inactive for 8 hours of sleep, they would need to return to the game 5 times to claim the reward, resulting in an increased number of sessions. The same mechanic is also used in Solitaire Grand Harvest by Playtika, as shown in the video below.

2. Daily Gifts

Daily Gifts mechanic becomes available after level 6. Player must log in the game everyday in order to collect the daily reward. If the player misses a day, the reward for that day cannot be obtained later. When the player reaches day 7, a top reward is granted.

3. Piggy Bank

Piggy Bank becomes available after level 25. When it is completely filled, it gives players a chance to buy it before it disappears in 15 levels. If the player doesn’t purchase it on time, it disappears but leaves a free ticket.

4. Season Pass

Season Pass becomes available after level 54. Level completions reward the player with candies, which are used to progress through it. There are both premium and free tiers, as shown in the image.

5. Bonus Gift

A wheel of fortune mechanic allows players to win bonus rewards daily.

Boosters

As we’ve come to expect from Candy Crush Saga, Candy Crush Solitaire is no exception when it comes to the super smooth, juicy booster animations that are a signature of King.

Despite being a different genre, Candy Crush Solitaire also features boosters from its elder sibling, such as the Fish (Wild), Lollipop Hammer, Colour Bomb and Flying Saucer, while maintaining similar mechanics.

1. 5-Extra Cards

When you run out of stockpile cards, there is a running A/B test you can encounter:

1. Test group: 5-Extra Cards booster is automatically triggered. While this makes the gameplay smoother by reducing distractions, it also creates an unnecessary sink for coins. In most cases, other boosters like Wild and Hammer are more useful than 5-Extra Cards, but players may not have enough coins after the auto-triggering. This has the potential to encourage players to visit the shop more often, leading to more IAPs. However, it is also clear that it can be annoying until players realize that the extra cards are not free.

2. Control group: 5-Extra Cards booster is optional to activate.

Even if the control group wins (we’ll see), there can be a player-controlled setting that allows players to enable or disable the auto-triggering of this booster, letting them decide how they want to play the game.

2. Undo

Undo booster relies on inattention when matching cards, which can be caused by color similarities, card rotation, and more, depending on the level design. When the hold slot is introduced, a new strategy emerges that requires players' attention, leading to more optimal moves to consider. Missing the best move often encourages players to use Undo booster more.

3. Fish (Wild)

You can use the Fish (Wild) booster to collect any card from the board, ideally to create a consecutive match chain.

4. Colour Bomb

Specifically, the Colour Bomb booster’s effectiveness and how satisfying it feels depend heavily on the level's visual structure and luck (since it is placed randomly in the deck), which can quickly lead to disappointment. On the other hand, for a level with a high number of open cards, it’s very effective, as shown in the video.

5. Lollipop Hammer

The Lollipop Hammer booster removes any card you choose from the board or hold slot, making it especially useful when you don’t have enough stockpile cards to reveal certain blocker removers, such as keys.

6. Flying Saucer (UFO)

Flying Saucer booster is always activated at the beginning of the level and removes 3 random cards from the initial board. Based on the data collected, all levels, except bonus levels (where boosters cannot be used), have at least 3 consecutive matches from the board, with an average of 9.5 cards collected consecutively. This means that unless the initial open cards on the board are specifically chosen not to match with the waste pile card, the Flying Saucer may not be as effective as desired (but let’s accept that it has a cool animation, so why not use it?).

Power-ups & Obstacles

Here is the list of power-ups and obstacles used in the first 95 levels:

1. Extra Card

An Extra Card adds additional cards to the deck (stockpile) based on the number written on it.

2. Key & Locked Cards

A locked card locks a group of cards and requires a key card to unlock.

3. Conveyor Card

There are 2 types of conveyor cards: up and down. They increase or decrease their count after each move. Using the hold slot doesn’t count as a move.

4. Candy Necklace Card Couple

Linked cards with a Candy Necklace can only be collected together.

5. Chocolate Card

Chocolate Card requires a card of the same suit to be cleared in order to be revealed.

Hold Slot

In level 11, the hold slot game mechanic is introduced, allowing players to set aside the top card of the waste pile when needed. In the best-case scenario, this mechanic doubles the chance of matching a waste pile card with a board card compared to the classic approach.

The hold slot requires more attention and also encourages the use of the undo booster. It adds more strategic depth and increases enjoyment by allowing for more consecutive card clearance from the board.

After getting used to the hold slot, other tripeaks solitaire games feel a bit sluggish in gameplay compared to Candy Crush Solitaire. I expect more upcoming games to incorporate a hold slot, and it’s highly likely we’ll see it introduced in existing games, at least as part of a special event with custom levels.

Special Level Types

1. Bonus Levels

Bonus levels feature a red, casino-like table with coins scattered around, creating a luxurious, premium atmosphere. These levels are essentially the same as other levels, except there's no way to fail. They are also part of the main progression, so they cannot be skipped. As expected, no currency is required to play them. Other mechanics, such as the streak meter, pre-level, and in-level boosters, are also unavailable. Additionally, there are no blockers or power-ups. There are 4 bonus levels until level 101.

Although they don’t seem very lucrative compared to regular levels at first glance while playing, after including the level cost, only about 7.4% of regular levels are more profitable than an average bonus level based on the data collected.

2. Hard Levels

Hard levels are treated as part of the regular levels in this article, because there are no additional or missing mechanics, as seen in bonus levels. In the first 95 levels, there are 12 hard levels in total, and 6 of them are marked as super hard level.

Purple color choice and skeleton pattern of the board create a cute villain atmosphere, which reminds me of the Witch character from Clash Mini by Supercell.

Interestingly, there were other non-hard levels that were actually harder than these levels. However, when we look at the overall picture, hard levels (including super hard levels) are more difficult than the other regular levels on average. Here are some statistics that make it easier for you to understand:

• Comparison of the average consecutiveness (max: 1, min 0) - A higher ratio means that more board cards can be collected consecutively before a new card is needed from the stockpile. 1 means that all board cards can be collected in a chain, while 0 means that each board card requires a new stockpile card.

  • Hard Levels: 0.54

  • Non-hard regular levels: 0.63

• Comparison of the average match probability of the stockpile cards (max: 1, min 0) - 1 means that any stockpile card opened will always match with a card on the board, while 0 means it will never match with a board card:

  • Hard Levels: 0.47

  • Non-hard regular levels: 0.56

• Comparison of the average number of booster uses (including all types of boosters):

  • Hard Levels: 2.6

  • Non-hard regular levels: 1.6

Candy Crush Solitaire also offers a Hard Level Kit offer just before super hard levels, as shown in the image above. It is a level specific pack, and it seems quite stingy in terms of content, as players are expected to use all in this level.

Other Mechanics

1. Streak Meter

As is common in the tripeaks solitaire genre, streaks are also part of the levels, encouraging players to collect more cards consecutively by rewarding them. Although there are additional rules, such as collecting same color cards or collecting one red and one black card in a specific order, which double the rewards (coins, extra cards, and wild cards), simply collecting any numeric card without using the stockpile is also enough. After each successful streak, the next one begins with a higher requirement, which is expected to encourage players to use more boosters.

2. Win Streak

When the Win Streak is active, additional boosters are automatically added to level. It means that booster use is not optional, and so it makes levels easier to complete. Win Streak aims to increase playtime while also boosting number of sessions because of the time-limited nature of the mechanic.

3. Loss Aversion Popup

When a player wants to quit the game without completing a level, a loss aversion popup appears, showing the rewards the player will lose, something commonly seen in many other games, regardless of the genre.

Data Collection Methodology

All statistics provided in this article were generated from data collected between Feb 6 and 8. The app version was 1.0.21, the platform was Android. The game was downloaded from Play Store TR. It should also be noted that there were ongoing A/B tests, as mentioned in the sections above, and it is highly possible that level configurations were also segmented. Thus, the collected data may not represent all groups.

The goal was to investigate how level difficulty is affected by level configurations that have a direct impact on the consecutive matching of cards, as well as how the hold slot affects the overall gameplay experience. This data was also used in the section about auto-level generation, which I believe is essential for level designers.

The data was collected from the first 95 levels. Although the target was 100 levels initially, level 95 was the first time I didn’t have enough coins and in-level boosters to complete the level, so I finalized the data collection there in order to stay within the time limits I decided at the beginning.

The following table displays the first 10 rows of the collected data. The first 8 columns are level configurations, while the other columns are derived from playing levels and so completely subjective.

I followed the rules below while playing the levels:

1. Do not use any pre-level boosters unless it is part of the tutorial, or due to the Win Streaks mechanic.

2. If there is no way to pass the level without using boosters:

   1. If there is enough coins, choose 5-Extra Cards over Wild and Hammer boosters.

   2. If there aren't enough coins but Wild or Hammer boosters are available, use Wild first, then Hammer if needed.

   3. If there are neither enough coins nor enough in-level boosters to pass the level, quit level and try again later (which is happened at level 95).

3. Try to collect cards consecutively as much as possible by creating the longest chains:

   1. Use the hold slot as much as needed.

   2. If more than one card matches the waste pile card, choose the one that forms the longest consecutive matches on the board.

   3. Use Undo if a better move is missed by mistake.

Important Concepts

I believe that some clear definitions are necessary to understand the information I extracted from the data before we discuss the charts. While it is not possible to cover everything in just one article, here is the concepts which I believe you should have an idea.

1. Consecutiveness of the Board Cards

How can we measure the fun of a tripeaks solitaire level? What’s the most engaging action a player can repeat that stimulates their positive emotions? It is obviously collecting cards consecutively, which is also the reason why the Wild card exists: to continue collecting cards without breaking the chain!

Consecutiveness of the board cards basically gives insight about how many cards can be collected from the board consecutively in the best-case scenario in any state.

As seen in the image above, collecting “K, Q, J, 10, 9, 8” respectively is the best solution we can achieve. We can say that number of consecutive matches is 5 for this example, because we are able to collect 5 more cards after collecting the “K”.

If we generalize the calculation and clamp it between 0 and 1, so that we can compare different levels:

where c is the consecutiveness variable, N_collected is the number of collected consecutive cards and i represents the state of the level. We can easily calculate the average consecutiveness by using this formula. However, it is not practical enough, because it requires recording all states. Here is another approach I used in this article to calculate the average consecutiveness:

where c_avg is the average consecutiveness variable of given level, N_board is the number of board cards, N_groups is the number of consecutively collected groups and N_hold is the number of times the hold slot is used.

Although this will be the topic of another post, this formula essentially measures the the ratio of matched connections based on the total number of connections (when we assume all cards can be collected consecutively) between board cards. Keep in mind that N_board doesn’t include blockers, such as Locked Cards, which cannot be collected.

2. Match Probability of the Stockpile (Deck) Cards

As we discussed, consecutiveness is the number one factor driving engagement for a player. However, without matching with a waste pile card, there is no way to play the game.

Match probability of the stockpile cards is a good way to measure how likely a match is to occur with a board card. If you watch the video above, 10 stockpile cards are drawn, and only 2 of them match a board card. Thus, we can say that the match probability is 0.2 for this stockpile. If we generalize the calculation:

where p_stockpile is the match probability of the stockpile, N_match is the number of matches and N_drawn is the number of stockpile cards drawn.

It is independent from hold slot use.

3. Effect of the Hold Slot Use

As discussed in the “Hold Slot” section, hold slot use doubles the matching probability of waste pile card in the best scenario. In the video, the match probability of stockpile is given as 0.2. However, using the hold slot doubles the chance for the waste pile card, allowing the player to collect 4 cards instead of 2 from the board.

Charts

I tried to avoid using boosters as much as possible except for the 5-Extra Cards booster, as shown in the chart. I used 50 5-Extra Cards, 12 Undo, 4 pre-level and 18 Wild and Hammer boosters in total.

As seen in the above chart, the total coins earned across levels are always higher than the total coins spent. It is obvious that coins obtained from level completions are not sufficient to progress without coin rewards coming from meta layers. However, I can say that there are no paywalls in the first 95 levels, and IAPs are not mandatory to progress. Keep in mind that although I failed the first time at level 95 it was not because I didn’t have any boosters. The reason was that I was avoiding using pre-level boosters (which I had 25 of them) to measure the level difficulties, and I didn't have enough coins to use any in-level boosters.

In this chart, calculated values represents the required amount of stockpile cards to complete the level without using any boosters. Calculated (Max) shows how many of them is needed if players doesn’t use the hold slot, and Calculated (Min) represents the minimum number required in best-case scenario when the hold slot is used. Drawn indicates how many cards are drawn from the stockpile to complete the levels. Initially Given is the number of stockpile cards given at the beginning of the level.

It seems that in the first 20 levels, the initially given stockpile cards are more than enough. For the remaining groups, it fluctuates between “nearly enough” and “not enough”, which makes booster use mandatory.

If you didn’t notice, although the Drawn cards are supported by the hold slot, they are much closer to the Calculated (Max) rather than the Calculated (Min). The main reason is that the number of hold slot uses is directly affected by the consecutiveness of the board.

The best-case scenario for the hold slot would require an additional matching card on the board each time a waste pile card is matched and held, but this is not always possible.

Auto-Level Generation

Until now, we have discussed different concepts that affect the difficulty of the levels, which is directly related to how much players will enjoy a level. In addition to what we've discussed, there are other elements that typically affect engagement, such as

• the average number of initial cards opened during gameplay

• the placement of power-ups and blockers

• the custom arrangement of cards to create a deterministic path when necessary

• visual aesthetics of card placement

etc.

These elements are already in my pocket to discuss in upcoming articles. However, in this section, we will focus solely on consecutiveness and match probability based on constrained randomization to experiment with auto-level generation.

1. Constrained Randomization

When we talk about randomness, we’re assuming a non-deterministic result, even though it will eventually converge to the expected result. As commonly given as an example, think about tossing a coin in a completely isolated environment. We can assume that heads will eventually come up 50% of the time in total, although we cannot predict how many times we should toss the coin to get this result.

Constrained randomization provides a solution to ensure that the probability of an outcome occurs within a given number of experiments. For example, if we decide to toss the coin twice, it guarantees 1 heads and 1 tails, while still keeping the randomness of the order.

If we come back to auto-level generation, I use constrained randomness for consecutiveness algorithm. The easiest way to apply constrained randomness is to define a group (block) size and occurrence value. For example, if there are 20 board cards, and the group size is set to 5 with 1 match per group:

• 4 groups are observed.

• There are 4 ways to place matching cards within a group (M: matching U: unmatching and 2 matching cards create 1 match):

  • [M M U U U]

  • [U M M U U]

  • [U U M M U]

  • [U U U M M]

Note that I'm not interested with card types here, only the placement. Although it is possible to calculate the number of ways using combinations for this simple example, increasing the number of matching cards introduces extra steps to consider.

While additional rules can be defined to limit the max number of consecutive matching cards in a group, the underlying logic remains the same. In addition to this, we could also consider the number of matching cards instead of the number of matches, which are fundamentally different. However, I decided to use the number of matches in this article.

2. Auto-Generated Level Examples

In this section, the algorithm automatically decides the next revealing cards. This ensures that consecutiveness and match probability remain unaffected regardless of the player's strategy. Thus, the level designer can directly manipulate the cards and even create better solution paths without needing to worry about whether the level will be too easy or too hard.

Example: 1

Total number of cards: 24

• Hold slot use: Not Allowed

• Consecutiveness (board cards):

  • Group size: 2

  • Number of matches per group: 0

• Match probability (stockpile cards):

  • Group size: 1

  • Number of matching cards per group: 1

As shown in the video, a total of 24 stockpile cards are drawn as expected. Since the consecutiveness is zero, each board card requires 1 new stockpile card.

Example: 2

Total number of cards: 24

• Hold slot use: Allowed

• Consecutiveness (board cards):

  • Group size: 2

  • Number of matches per group: 0

• Match probability (stockpile cards):

  • Group size: 1

  • Number of matching cards per group: 1

Hold use is allowed this time, and the rest of the configurations are the same as in Example 1. If we calculate the max and min number of stockpile cards required, we can see it should be between 24 and 12. If you watch the video, you'll notice that it's actually 15 and hold slot use is 9.

Example: 3

Total number of cards: 24

• Hold slot use: Not Allowed

• Consecutiveness (board cards):

  • Group size: 6

  • Number of matches per group: 2

• Match probability (stockpile cards):

  • Group size: 1

  • Number of matching cards per group: 1

The total number of stockpile cards drawn is 18, while the calculated value is 16, but they are close enough.

Example: 4

Total number of cards: 24

• Hold slot use: Allowed

• Consecutiveness (board cards):

  • Group size: 6

  • Number of matches per group: 2

• Match probability (stockpile cards):

  • Group size: 1

  • Number of matching cards per group: 1

In this example, I kept the same configurations as in Example 3, but allowed the use of the hold slot. In total, the hold slot was used 6 times, and the total number of stockpile cards drawn is 9, which is very close to the minimum calculated value of 8.

So, that’s all folks! I think that’s enough for this post. We covered a lot of game mechanics, statistics, and finally explored how we could auto-generate levels. I hope you enjoyed!

See you next time!