How pillars and triangles can focus your game design
In game design, freedom can lead to paralysis. But in the latest issue of Wireframe magazine, Stuart Maine explains how game pillars and the iron triangle will help you focus on what’s important.
This article will cover two game development tools that are designed to help decide what’s important in the game you’re making. The iron triangle revolves around the practical realities of making a game, while game pillars cover the creative side, but both relate to the importance of focus. Let’s begin with pillars.
Every game media has its strengths, such as wargaming’s communities, the shared experiences of board games, or the collaboration of RPGs. One of the advantages of video games is their sheer flexibility – we can race across alien worlds, explore Egyptian tombs, or keep fit while going on magical quests. But that infinite flexibility can be a real problem for game creators, because if the game you’re making can include literally anything, then how do you know what to focus on?
Let’s assume you have an idea for a game based on a particular world or character, or a certain type of gameplay. Alternatively, you might have used player types (see Wireframe issue 39) to decide on a particular audience and the features they like, or if you’re working with someone else’s IP, then that brand’s owners might have a type of gameplay in mind. Game pillars help move beyond those starting points and guide you through development.
A game’s pillars are a list of around three ‘core statements’ created early in that game’s development. You could come up with your pillars before you’ve started development to help narrow down the possible game you might make, or you might do this after prototyping has given you an idea you want to pursue. You can even retroactively create pillars to help rescue a game that’s been in development for a while and has lost its way.
- Each statement should be short – no more than a sentence – and each should be phrased as a rule you will follow throughout development.
- Use active language. We will, we like, this game is, our audience wants, and so on. Don’t use negative language if you can rephrase the same statement as a positive.
- Importantly, make your pillars focus on how your players will feel over the things they will do. This is probably the most important concept here, so let’s explore it further.
Dig deeper into the ‘why’
It’s easy to write ‘our game will feature 2D puzzles and platforming’, and technically that is a pillar because you can refer back to it later. But it doesn’t really say anything about what that platforming is for. By that, I mean why are you making a game about platforming? To dig deeper into the ‘why’ behind your pillar, you could rewrite that sentence to one of these:
- Explore evocative alien worlds, telling a story through atmosphere and details
- It’s satisfying to master deep systems and figure out hidden rules
- Our players will achieve a state of flow through challenging, precision gameplay
Those are my example guesses at a pillar each for the platform games Flashback, Spelunky, and Celeste. All are 2D platformers, but they’re ‘about’ very different things.
What to do with your pillars
Note that none of the above examples specifically talk about the gameplay being platforming, because pillars should focus on the feelings and emotions you want your game to evoke, rather than how you’re going to do it. That’s because pillars aren’t a feature list to check off, more a tool to help remember the things that are important when you’re submerged in the day-to-day realities of game development. Pillars are the why of your game, and the actual development process is coming up with the what to match those initial goals.
Print your chosen pillars as large as you can and put them up somewhere you’ll see them every day. That way they’ll become ingrained in your thoughts and you’ll easily be able to refer to them when someone suggests a new feature or change to the game. Will that change help bring your game closer to your pillars (great), not really affect them (neutral), or work against them (bad)?
I’ve seen studios use pillars on struggling games to discard any areas which don’t match them. You particularly see this if a game is taking too long to release (because most professional studios have to get a game out to some sort of deadline – more on this below), with people looking back to their pillars to help work out what to cut. If feature A is cool, but feature B aligns with the pillars, it’ll take a strong argument to keep A.
There are a couple of approaches for coming up with a game’s pillars, each with advantages, but also potential problems to look out for. Both of these approaches assume you already know to some degree what the game will be. Your pillars will help guide the eventual game’s details, but they’re a tool for staying on track as you forge ahead, not for coming up with ideas in the first place. If you haven’t agreed on a concept for your game yet, then run game jams, conduct audience and market research, or paper prototype ideas first.
Second, both approaches assume any business, audience, IP, or technology factors are already agreed and set in stone. For example, you might already know that this will be a multiplayer game, that it must be released within this time frame, or that it must be built on the technology created for your previous game. We’ll talk more about this with the iron triangle, but basically, any real-world issues that are beyond your control must be acknowledged or you risk coming up with pillars that set you up for difficulties later.
The two approaches are to have the entire team brainstorm potential pillars, or have vision holders dictate them:
ONE: If the entire team is involved, then you run brainstorming sessions where everyone’s potential pillar ideas are stuck up on a wall. Then the group chooses the best pillars or combines a couple of ideas into pillars (remember the point about keeping them short – mashing many ideas into a long pillar is cheating).
The advantage of this approach is that everyone understands and buys into the chosen pillars because they had a say in creating them. The downside is that this process can take time, with potentially conflicting ideas needing to be whittled down until an agreement is reached.
TWO: The other approach is for ‘creative vision holders’ to come up with the game’s pillars and then present them to the rest of the team. Obviously, this is much less collaborative and more about saying, ‘I have a vision for this game which I think could be incredible, will you help me make it?’ The advantage of this is that everyone can rally behind a singular vision that someone is passionate about bringing to the world. As a result, the game’s pillars are likely to be extremely focused and all pointing in the same direction. The downside is that it requires everyone else to get on board with the game’s pillars even though they didn’t help come up with them.
Either way, once the pillars have been created, everyone on the team has to work with them in mind – there’s an implied contract that these rules must be enforced to ensure the game keeps moving in the right direction. Even though it can be unpopular to say no to someone’s idea, that’s what pillars are there to help with (and of course, pillars don’t say ‘that idea is bad’, simply that it doesn’t fit this particular game. Write the idea down and maybe build your next game around it).
Here are some actual pillars from games I’ve worked on:
- Live through the apocalypse by any means necessary.
This pillar from a military-themed game establishes that any action is acceptable in order to survive, implying a gritty, survival-of-the-fittest tone.
- Does it make me feel loved?
A pillar from a game that was designed to appeal to an audience that liked romances and was looking for escapism. This guided our characters, environments, and art style.
- Make me feel powerful, and make me say, ‘That was awesome!’
It’s always worth considering a pillar covering who the player is in this game. If you’re making a game about being a giant robot, then ensure players feel big and powerful.
- Small actions = epic reactions.
From a puzzle game themed around combat. Because the player is making very small actions (tap, drag) we wanted to ensure the game responded with weighty reactions.
- Express your own style in a safe way.
If you’re working on a game for kids, it’s worth thinking about the challenges and worries in their lives, and whether your game can help them safely explore those areas.
- Trust the player – it’s their game, let them play how they like.
We used this for a procedurally created game, reminding the team not to create puzzles but to focus on systems that players could use and abuse any way they wanted.
The value of pillars
I realise that game pillars are quite an abstract topic, but in my experience across many games and studios, they have proven their worth. At the start of a project, they help avoid the ‘blank page’ problem of being able to make anything you can imagine, and later they help you say ‘this, but not that’ and avoid wandering in the development wilderness. So however you choose to structure or word your game pillars, I wholeheartedly recommend spending a little time thinking about the why before you launch into the what.
Speaking of which, let’s take a look at the iron triangle and how it will impact your game, because no matter what you do in the games industry, the triangle will impact you. As a result, it’s important to have an idea of how it works and what it means to your projects. A quick disclaimer: I’m going to simplify a complex area for space reasons, so if it interests you, check out online resources on this and other project management topics.
Art versus business
Have you ever played a game and clearly seen that it was unfinished? Missing features, obvious bugs, and a lack of polish show that you’re playing a game that needed more development time. The iron triangle is the reason games are released in an unfinished state, but it isn’t some malevolent force – it’s simply where reality butts up against creativity in game development.
Coined by Dr. Martin Barnes, the triangle applies to premium games as much as free ones, and to indie games as equally as blockbusters. It relates to…
Three areas of game development
- Quality: How ‘good’ is your game? Good could mean it has many features, levels, NPCs, and weapons, or that what you have is highly polished and balanced. It also dictates how many bugs you let through into the finished game (no one ever fixes all their bugs, you just choose which are most important).
- Time: Implementing all of the above takes time, so this point of the triangle relates to how long your game will take to be released. Most game developers have to release their games to some sort of deadline; see ‘Time = money’ for more on this.
- Money: The longer a game’s in development, the more money it costs, with most coming from the wages or living expenses of the team working on it. Money is the most complicated of the three factors because there’s a limit to how much you can throw at a game. A feature that’s going to take a lone developer ten months can’t be done in one simply by paying to put ten developers on it – people get in each other’s way and you have to pay even more because that many people need a lot of management.
Choose your priorities
Now we know the three points of the iron triangle – where things get interesting is that those points are all interrelated, and the rule is you can only control two of the three points. You can select which two points you want to control, but you have no say on what happens to the third. That’s why it’s called an iron triangle – the outcome of the third point is decided by what you do with the two you’ve chosen to control.
These are the outcomes you can expect based on the two points of the triangle you choose to control:
- Controlling time and money is where you see licensed tie-in games. Because they need to release alongside (say) a movie, they must come out on a certain date, and they can’t cost more than a certain amount otherwise it isn’t worth making the game in the first place. The point of the triangle not controlled here is quality, meaning the game will be as big and polished as it happens to be when the time and money run out.
- The second choice is to control time and quality, meaning the game must come out on a certain date and be at least ‘this’ good (e.g. large, polished, and bug-free). This option means you relinquish control over the game’s cost – it will simply cost as much as it needs to, to ensure it hits your quality bar and is released on time.
- Finally, you can control money and quality, meaning the game will be big and polished, but the team is kept small to limit development costs. This means you have no control over how long the game will take to release because a small team making a polished product can only work so fast.
You might be wondering why any of this matters – after all, you could be making a game in your spare time or working at a studio where other people make these decisions. But if you understand which of the points of the triangle your project is trying to control, then you can work more effectively, making choices that work towards those needs rather than against them.
As a side note, if you’re working at a studio and whoever’s in charge insists they can control all three points of the iron triangle, consider that a Big Red Warning. That sort of denial of the fundamentals of project management means overtime – and a game that’s likely to go off the rails.
The iron triangle isn’t about hateful business realities quashing your creative dreams, it’s about choosing and understanding your priorities so that you control your game, not the other way around.
To recap: choosing your game’s pillars helps you focus on what’s important, and choosing which two points of the iron triangle you want to control helps you focus on the reality of making a game. Both of these are important, because not deciding on a game’s pillars can lead to the end result being a mess of conflicting ideas pulling in multiple directions, and ignoring the iron triangle leads to games spiralling into overtime, delays, and impossible demands. Yes, making games should be fun, but a little focus early in a project’s life can pay off big time later on.
Get your copy of Wireframe issue 52
You can read more features like this one in Wireframe issue 52, available directly from Raspberry Pi Press — we deliver worldwide.
And if you’d like a handy digital version of the magazine, you can also download issue 52 for free in PDF format.
ainda gosto mais do minecraft!