Most games run on game loops. They are repetitive processes that, when you do them, achieve a goal that can be also a part of a game loop in an upper level.
Game Loops exist because they drive incentives for a player to behave in certain ways, in order to create an experience. That is why we System Designers deal with them.
However, certain Game Loops can be used to drive a very special desire in a player: the desire to progress. This progress can mean a lot of things:
– Unlocking new content
– Unlocking new features, skills or abilities
– Performing better or more efficiently
– Discover more of the history, or the world of the game
– New game modes
And much more!
When you create a Game Loop where progression is gradually delivered to the player after certain conditions are met, we create a pacing. The pacing will determine how patient, skillful, lucky, or a combination of all; a player has to be in order to get to the next step.
Naturally, our players will get better, accumulate more power and have more options the more of the game they already unlocked, so to keep the challenge interesting we also gradually increase the difficulty or cost of these conditions, thus pacing is usually incremental.
When you set what content is given based on the challenge level a player confronts, you are creating a Game Economy. In essence, this is at the heart of what Economy Designers do!
Designing a Game Economy is not necessarily related to monetization. Any game where a player unlocks stuff as part of its Game Loops, will have to deal with Game Economy problems. Some games rely on them so much that they require Economy designers dedicated full-time to the multiple and subtle aspects of this.
Creating a progression isn’t easy. How do you know the progression is the right one for each player? After all, each player is different, has a different amount of skill, time to play, interests, and several other factors. What if the reward is awesome for a certain player but not appealing for another? How do you balance a certain piece of content so it is acceptable for a newcomer but not boring for a veteran? This is the bread and butter of Progression design.
Progression systems are typically associated to spreadsheets. This is just one tool the designer has when designing a Progression system, and it might not be the best one at all times. We tend to use spreadsheets because it allows us to model a certain part of the game, but it is not the only tool we use!
In essence, a model is a tool for making predictions or testing hypotheses. Think of it like a “simulation toy” of a certain part of the game we are interested in tweaking.
So in the model we put an input and a configuration, and then we get an output. The model then tells us a lot of valuable information:
– It can indicate if our output is what we expected. Will a player in X situation do Y?
– It can indicate if our configuration will behave as we want. If the player does X how will react the game rules?
– It can validate behaviors or suggest tweaks to our rules. If I want outcome Y, what situation should the player be in?
Models are not always spreadsheets (though they are definitely helpful). A model can be a piece of scripting, an ingame tool, even the game itself (usually in some kind of “debug mode” for ease of usage). Each project is different, but conceptually, the idea is that the model will help us tweak the game immensely.
For a Game Designer creating a Progression system, being able to create and use Models is a very valuable skill.