Back to basics part 1: End-states & Wincons
Hi, and welcome to the beginning of a(nother) new series of articles. As the title suggests, this one’s going to focus on the absolute basics of game design, and is meant to be both a good starting point for beginners, as well as a generally useful review of some of the more key concepts in games.
Today’s topic is about as basic as it gets, since it concerns the key defining quality of games: end-states and victory conditions (AKA win conditions AKA wincons). So, without further ado, let’s hop into it:
What is this wincon thing, anyway?
To quote Wikipedia (the most credible authority on everything ever; emphasis mine):
Key components of games are goals, rules, challenge, and interaction. Games generally involve mental or physical stimulation, and often both. Many games help develop practical skills, serve as a form of exercise, or otherwise perform an educational, simulational, or psychological role.
A game is inherently a competition, and as such, it needs a way to determine a winner. Regardless of the number of players and the nature of said competition, the game needs to have a conclusion. Even if it’s the player(s) against the game itself (in which case, we can just treat the game itself as a player), the game still needs to have some kind of end-state.
Now, there is an entire absolutely massive philosophical discussion to be had here, about whether a game really needs to have a winner, but for now, we’re just going to assume it does, and leave said philosophy as an exercise to the reader.
All that said, a wincon is a condition that a player needs to meet when the game reaches an end-state in order to be declared winner of the game.
Aside: Wincon vs end-state
Over the course of this article, I’m going to try and keep these two concepts separate, even though fulfilling a wincon can itself cause the game to end. In the next section, we’ll cover the most common end-states, and this will hopefully become clearer given those details.
Game Over
As unfortunate as it might seem at times, all games need to end at some point, and how your game reaches that end has major implications for everything, from feel, through pacing, to balance. Fortunately, all game endings can be put into a few broad categories. From there, it’s fairly straightforward to go and pick an approach that best fits your game.
There are multiple ways one could divvy up these end-states-slash-conditions, but the one I’ll be using shows the relationship between the end-state and the game’s duration:
- Fixed game length
- Fixed number of turns/rounds
- Fixed amount of resources or moves
- Variable game length
- Game ends when some specific state is reached
- Game ends when a player accumulates a specific number of points
- Game ends when all other players are eliminated
- Fixed number of rounds/moves that can end early
These are very broad categories, and there’s a fair bit of overlap and semantics that needs to be taken into account when discussing these, so we best get to it.
End-state: Fixed number of turns
This is one of the most common ways of ending the game, and for good reason. If you design your game to be played over a fixed, consistent number of turns, you have pretty much total control over the game’s pacing. As an example, I’ll use 7 Wonders. It’s a card drafting game, played over 3 rounds called Ages. Players have a fixed number of actions they can do during each Age, and the cards’ effects get stronger with each Age. I’ll skip over the rest of the game’s specifics, since they’re not that important.
Talking more generally, with a fixed-round game, you can carefully control the game’s balance, decision space, and just rules in general for each round individually. You can easily introduce new rules that only activate at a specific round, or even remove or change already active rules. Give the players more actions during the last round to really up the tension of the game. Completely change the way resources are spent to punish players that have been hoarding things from turn 1. Have a combat-free round in an otherwise combat-heavy game. The list of possibilities goes on…
Now, you do have to keep in mind that while you can tweak things round-for-round, it’s still the same game, and in the vast majority of cases you’ll have some state that persists across the rounds. That is, unless you plan to make it just a series of unconnected minigames, but let’s assume we’re going for a single, coherent gameplay goal. Tweaking round 3 will have consequences for rounds 4 and 5, and you will have to jump in and tweak those as well if you want things to remain consistent.
Overall, a fixed-round system is very simple and straightforward. So, why not use it all the time? Well, not every game benefits from having this type of pacing. This system is good for introducing rule and/or balance changes on the fly, but does it in a way that’s not very granular. If you want the game to flow more smoothly and linearly instead of having these kind of large jumps, it would be probably best to avoid a fixed-round structure.
Of course, one can say ‘What if I just make the changes small enough to keep things smooth?’ Sure, you can absolutely do that, but it’s a bit of a double-edged sword. The lack of granularity is actually a strong point of this approach. If the changes between rounds are large, that helps each round feel distinct. Smaller changes would be more linear, but that can come at the cost of making the rounds feel too samey. Again, nothing wrong with this. After all, just because you can change rules between rounds doesn’t mean you must. Using fixed rounds just for the sake of pacing is a perfectly fine way of doing things, too. These are all just tools—how you use them is completely up to you and the game you want to make.
End-state: Fixed amount of resources
A very similar approach—one that can technically be treated as just a specific implementation of the fixed-round system—is for players to start the game with a fixed (and equal) amount of resources or actions that doesn’t replenish over the course of the game. And, to ensure that the game moves forward, players usually must spend a resource/action each turn. This way, you give the game a fixed length while maintaining a smooth, linear gameplay flow.
One of my personal favourite board games—Small Star Empires—takes this exact approach. It’s an area-control game, and each player has a fixed number of pieces of a couple different types, and they must place one on the board each turn. Each player starts the game with 16 ‘colonies’ and 4 ‘trading posts’, and the game ends when no player has any pieces left to play. This way, the game is guaranteed to end within 20 turns—sometimes less, but never more. From a design standpoint, tweaking the overall number, as well as the ratio between the different actions lets you change the gameplay without really changing any of the rules. The game’s expansions add even more types of resources, and if you’re doing something similar for your game—through expansions or just game modes—you can easily change the game’s length and pacing through parameters like these.
For both end-states mentioned so far, the wincon is more often than not ‘the player with the most points at the end of the game wins’. This is an extremely straightforward way of determining a winner, from both an implementation and gameplay standpoint.
As a wincon, it measures each player’s overall progress/advantage over the course of the whole game. Whether a player takes the lead early or late in the game doesn’t really matter, since they have to keep that lead to the end either way. It also doesn’t matter how large the lead is, at least not in the context of ending the game. 7 Wonders will always go through the three Ages; Small Star Empires will see players taking 20 turns in >90% of games—a player can end up not having any legal moves, in which case they have to basically wait until the end of the game.
Because this type of wincon is checked only at the end of the ‘timer’, players can end up having the same amount of points, in which case tiebreaker mechanics take effect. How these mechanics are implemented depends completely on the game itself, but they’re usually something that arises from the primary wincon, i.e. something that would be beneficial to do while progressing towards the wincon.
In Small Star Empires, the tiebreaker is ‘the player who has the longest continuous line of pieces on the board gains 3 points’. This type of tiebreaker goal makes for a good way to try and squeeze out points, especially when you can’t really access any of the actual valuable tiles on the board anymore, which often happens near the end of the game. Another common tiebreaker mechanic is to give players points based on their leftover resources at the end of the game, or some kind of set collection bonus (having a specific number of things that make up a specific set, or a number of things of the same type etc.).
An absolutely crucial thing to remember with any kind of tiebreaker mechanic is that it must not be more valuable than the primary goal. If that’s the case, players (especially newbies) might mistakenly focus on the tiebreaker points, and end up missing the point of the wincon. You don’t want to end up with a ‘minigame’ distracting players from the actual game. It’s best to have tiebreakers that are ‘side effects’ that arise from pursuing the primary wincon.
End-state: Game reaches a predefined state
The two end-states we’ve discussed so far have been ones where the game has a fixed length, but for the following few, we’ll look at ways to end the game immediately upon meeting some condition. This condition can be any number of things, since it’s based on the state of the game itself, and it almost* always manifests itself in the form of a race.
*Brief aside: this applies to scenarios where the first player to get the game to the predefined state wins, but one can also have it work like the fixed-length games: when the state is reached, the game ends, and the winner is determined after the fact. The race approach is used in the absolute vast majority of games with this kind of end-state. Going forward in this article, I’m gonna assume that all variable-length end-states and wincons work as races.
The absolute simplest—and arguably most well-known—example of this type of win condition is chess, specifically the checkmate. In fact, we often use the word ‘checkmate’ to describe any kind of defeat or inescapable position. For those (somehow) unfamiliar with chess, checkmate happens when a player runs out of legal positions for their ‘king’ piece, and a legal position means that it’s not threatened by any opposing pieces.
Chess is actually a perfect example of variable game length: the quickest possible checkmate—aptly named Fool’s Mate—takes only 2 turns to do, and as the name implies, it requires some absolutely foolish gameplay from one of the players in order to be achieved. As for the upper bounds on game length, that goes off into ridiculous territory. The number of possible moves is so large that it’s virtually infinite, at least when playing on anything less than astronomical time scales. However, people have realized this, and to keep things relatively sane, have implemented a few rules that put more reasonable bounds on game length. I won’t get into those, but you can find more info here and here—they essentially amount to ‘end the game if it hasn’t been going anywhere for a while’.
Because the game length is not predefined by the rules, the designer’s approach to the game’s pacing differs drastically. Now, you no longer have direct, precise control of when you want things to happen and how the balance shifts as the game progresses. You definitely still have control, but it’s much more nuanced. While throwing away this type of fine-grained adjustment might seem like a bad idea, it’s actually far from it. It’s a different approach, with its own set of strengths and weaknesses.
For example, let’s look at predictability, i.e. how easy it is for players to predict who’s gonna win the game ultimately. In a 5-round game, the tension can absolutely be killed if one player manages to get a massive lead during round 3, to the point of it being obvious that the other players can’t catch up. Now, of course, this depends on how the scoring functions and how easy it is to work out mid-game, but it definitely can and does happen. The fact that the game has a predefined length makes it easier for the designer, as well as for the players, but it does come at a cost.
On the other hand, variable-length games are much more unpredictable on average, and this can affect the tension in the game tremendously. It can guide players to adopt a ‘fight to the death’ attitude, since even with a massive lead, predicting if and when the win happens is not that clean-cut. Of course, in both cases, this depends on the amount of interaction in the game, and how easy it is to catch up to the leader, but the unpredictability of these kind of ‘race’ end-states is generally exciting in a way that fixed rounds aren’t.
It’s all pros and cons: fixed-length is more straightforward to design, pace, and balance; variable-length is harder to tune, but offers a much smoother and potentially more tense experience. And just to add, the fixed-resource type of end-state feels like it belongs somewhere between these two extremes—of course, where exactly depends on the implementation.
End-state: Player gathers required number of <something>
When talking about end-states and wincons, it’s absolutely critical to mention one condition which absolutely towers above the rest in terms of how often it appears: first to reach X points wins.
The reason this type of wincon is so common is that it’s pretty much the simplest implementation of a ‘race’ to design and develop, and most of that comes down to a single factor: granularity. Being able to easily tweak the amount of points gained and the victory threshold massively helps with iteration speed. There’s also the fact that this granularity gives players a good sense of how close to winning each player is, which leads us to:
Aside: Countdown to victory
When talking about point-based wincons, we have to address the method—or rather, the timing—of counting said points. For both fixed- and variable-length games, you can always count each player’s points after the game ends, or you can keep constant track of points, updating the values as points are scored.
The difference in tension between these two methods can be immense:
- Counting only after the game ends generally leads to games where players can’t be completely sure which player’s going to win. While you can have a vague idea of who’s in the lead, and even by how much, nothing’s clean-cut until the final count—of course, barring a player getting so far ahead that any ambiguity is gone.
- Counting during gameplay, while giving more information and hence providing less uncertainty, can also be very useful in games with good catch-up mechanisms. Especially in free-for-all multiplayer games/gamemodes, being able to see when someone’s getting ahead, and how quickly, can serve as a ‘wake-up call’ to other players for the sake of trying to catch up to or slow down the leader.
- With games that span multiple rounds, counting can also be done between rounds, but not within a round. This method is a bit of a middleground, since it gives players information about victory progress during key moments, i.e. the round transitions, but hides the progress during the round itself.
When developing a game with a point-based system, be sure to try and test it with different score tracking methods, and use the one that best aligns with the amount of public information and tension you want for your game.
End-state: Last player standing
So far, with all the wincons we’ve looked at, all the players are part of the game from the beginning to the end, but that doesn’t always have to be the case. In multiplayer (2+) player games, there’s always the option of having player elimination, with players having loss conditions instead of wincons. In this case, the game ends when all players but one have been eliminated, and that player is declared the winner.
This type of end-state is much harder to use than the others, i.e. it requires a very specific type of game, in which elimination makes more sense than keeping all players around until the end. The biggest downside of this is the fact that players don’t like being eliminated. Think about it, from the moment you’re eliminated, you basically become a spectator; you can’t affect the game anymore. That said, nothing’s stopping you from letting eliminated players still have some form of input, especially if it’s a team-based game.
Generally speaking, when a player is eliminated, they tend to lose interest in how the rest of the game goes, or at the very least, their interest is vastly diminished by virtue of them not playing anymore. If player elimination is a crucial part of the game, then you could also take some time and consider how interesting the game is to spectate. If you have something that’s fun to watch even all the way through, eliminated players should want to stick around to the end more; doubly so if you give spectators some agency: if your game supports it, maybe let them intervene as a one-time thing. Embracing these ‘wildcards’ can make the game a lot more exciting for everyone involved.
By the way, in my opinion 1v1 games exist in a weird superposition of technically being both elimination-based and not at the same time. There is only one player to eliminate, but is the loss because of the elimination itself or just reaching the wincon first? Dumb thought experiments like this are left as an exercise to the reader.
End-state: Hybrid (fixed-length that can end early)
The final type of end-state on this list is an interesting middle-ground between the 2 major categories: fixed- and variable-length. Nothing prevents you from making a game that lasts a set amount of turns/rounds/moves ‘by default’, and then throwing in a condition—usually a pretty difficult one—that immediately ends the game when met (the immediate-win condition can also be an immediate-loss condition in co-op games).
The big thing you have to decide on when implementing this type of end-state is which aspect—’timed’ or immediate end—is going to be the main way of winning the game. Having the fixed-length be primary generally means that the early-win is a kind of ‘failsafe’, ending the game if a player gets so far ahead that continuing for the entire length would just feel bad for the others.
On the other hand, early-win being the main way of winning turns the fixed length into a failsafe against the game going on for too long. You do have to take care here that regardless of what the wincon for the full-duration end-state is, it’s comparable in excitement to the early win, as well as making sure that both wincons care about the same things (the same things you need to keep in mind as with the tiebreaker mechanics we mentioned above).
Victory how?
Now that we’ve gone through and put the end-states and wincons into neat little buckets, the burning question on your mind probably is: Which end-state/wincon combo do I pick for my game?
The answer will disappoint you if you weren’t already expecting it, since it depends. The best way to figure this stuff out is, as always, through playtesting. It’s not uncommon for most mechanics in a game to work just fine except the wincon. If that happens to you, your best bet would be to try and analyze why the current one isn’t really working out, and then promptly rip it out and change it with another option. Fortunately, once you find the proper wincon, it tends to stick, only requiring balance tweaks as the rest of the game around it changes.
There’s a closely-related question here that can have some hefty implications on your design process overall: should you design the wincon first or the mechanics first? This is a much more nuanced choice than it might seem at first glance, for a number of reasons. Generally, you’ll start with whichever you think of first, so the question would be better reframed as “should you lock in the wincon or the mechanics first?”
Both approaches are equally viable, and offer different wiggle room for your design going forward. Locking in the wincon first means that you’re free to do whatever you want with the mechanics as long as they ultimately help getting players to the wincon. Going mechanics-first lets you be a lot more fluid about the entire design, albeit potentially at the cost of having a harder time deciding on a proper wincon later. As I write about in this article, most mechanics should move the game closer to the end-state, and not being certain about what that end-state is can make it harder to visualize and reason about the impact of a mechanic or effect.
Conclusion
Well, that was a fair amount of stuff to write, and there are actually a fair bit more things to ramble on about, but we have to try and keep this within reason. Games need to end, and players need to win. There is a lot of finagling that can—and inevitably will—be done regardless of the choice of end-state and wincon. Like with many other things in game design, being aware of which options you have and which solutions to problems exist is half the battle, sometimes more. The other half comes down to experience, and playtesting until you get sick of the game and beyond.
I’m slowly running out of comments to pair with these songs, but I guess this kind of meta-comment works too. It’s a good song, OK?
This is InvertedVertex, signing off.