Explorables Of Pull Algorithms

Pull Algorithms

Often when designing games, we need to design a pull algorithm, or a way to give the player a random game object from a pool of random objects. It's hard to visualize how these random distributions look in practice and so difficult to design them well. Over the course of this article, I’m going to present a bunch of small simulations to help understand various algorithms.

Table of Contents

Basic Player Engagement

Stimulation

This is our first simulation and it’s pretty simple. Just click the interact! button to give the player a game piece. Different players require different amounts of engagement. If a player receives too little stimulation, they will leave.

This is a really abstract representation of how getting stuff in games works. Nevertheless, you can imagine that if this were Pokemon Go, every time you pressed the interact button, the player got a new Pokemon.

On The Simplifications of the Article

This is an obvious and gross simplification of the player's experience. However, if we look at it as purely the experience on the single axis of the pull system, and a heavy simplification of that as well, we can still derive value from these simulations. It is also worth remembering that a new feature could do well in this simulation, but still be bad for your game due to something that this article doesn’t cover, such as negatively impacting the decision making in the game or increasing complexity to the point of impenetrability. Video games are complex and need to be looked at with multiple lenses.

Basic Systems

A common game development pattern is to use a system to drive the player’s engagement instead of hand-crafting it in the manner of the above simulations. It’s often time consuming and expensive to hand-craft a full drop pattern. So, with this simulation, we’re going to go over a basic system to do that for us.

There are three sliders to play with in this simulation:

Observations:

Pull Systems

Simple Simulation

We're now going to add some detail to the previous simulation to make it skew closer to a real pull system.

The impetus for this piece came from watching Pokemon Go release the second generation of Pokemon into the wild, so we’re going to use that game as the primary example for the rest of the piece. In particular, we’re going to look at the way players randomly encounter new Pokemon to catch, and consider that a pull system.

We’re going to start with the most abstract representation, where we’ll just assume that all of the pieces are of equal value and we’ll assume 100 of them.

Observations:

Possible Improvements:

Pokemon Go

Let’s get a little deeper into what a real pull system looks like. Taking Pokemon Go itself, different Pokemon are differently valuable due to the following axes:

We're not going to simulate all of that, just something a little closer to it than the simulation above. Note, that at this level of abstraction, this data can represent a lot of games, not just Pokemon Go. To do this, I:

Observations:

Introducing New Content

Pokemon Go, when introducing the second generation, just added more pieces to their existing pulls. Releasing like that when your players have already performed a large number of pulls results in a graph that looks something like the below one.

Observations:

Various Pull Algorithms

We've only worked with simple, highly random pull algorithms thus far. In this section, we'll take a look at some other kinds.

Deterministic

What does this graph look like in the trivial case of just going through every element one by one?

Note that it feels very different for players to get random pulls and to get deterministic pulls. One reason for this is that being able to calculate the effort required for something changes the way players value that thing. These simulations have no way to model that though. They can only show you what players get.

Observations:

Placing a Ceiling on Bad Pulls

A common approach to smooth out the variance of a pull system is to place a ceiling on the number of low-value pulls. That results in graphs that look like this:

Observations:

On a personal note, I dislike it when games do this without communicating the skew to the player because I feel it reinforces the gambler’s fallacy. I also feel that making the cap more explicit is a better experience for the player as the player doesn’t feel like bad pulls help them get to good pulls when it is implicit.

Pokemon Red and Blue

Another option is to divide your pool of pulls across a lot of smaller pools and then let the player move between them. This is essentially what Pokemon Red did and also what a game like Heroes Charge does as well. This changes the flow to be much wavier, and so the graph looks more like this:

Of course, there are a lot of ways to implement a division like this and the amount of effort required is dependent on the kind of separation that you want to make.

Observations:

Conclusion

This is, of course, a very incomplete taxonomy. Hopefully though, it lets you think about how players interact with the pull systems that you have made and the potential problems and benefits of these solutions.

You can look through the source code here - https://github.com/nikwin/pullArticle

If you have any feedback on this or if you want to see more things like this, you can reach me on Twitter at @murthynikhil. If you make any new simulations like this, please do tell me. I’d love to see more explanations like this.