In Part 1 we talked about what game pillars actually are — rules to test decisions against, not directives or mood boards — and the three traps that tend to make them useless: too many, too obvious, and too vague. If you haven’t read it, it’s worth starting there.
This is the part where we look at what good pillars actually look like.
How Pillars Get Found
Before getting into what good pillars look like, it’s worth talking briefly about how they get discovered — because discovered is the right word. Pillars aren’t something you sit down and invent on day one of a project. They emerge from the work of understanding what your game actually is, and that understanding takes time and effort to develop.
Pre-production is where that work happens. Playing the games that inspired the project. Watching the films that capture the tone you’re chasing. Building prototypes that prove — or disprove — how the game should feel to play. Pillars should not be the first thing decided on any project. But they should be clear before production ramps up, because once you’re in full production the cost of not having them becomes very high very fast.
One path to finding them — and I’ll acknowledge this is its own hotly debated topic — is the vertical slice. A small, polished, representative chunk of the game that demonstrates the core experience. By the time a vertical slice exists, you’ve made enough decisions about how the game feels to play that the pillars tend to solidify naturally. You look at what you built and you start to understand what it actually is, which tells you what it needs to stay.
Not every project has the time or resources for a full vertical slice (or in some cases several vertical slices). But the principle holds: pillars come from making things and learning from them, not just from a whiteboard session before anything exists.
A Hypothetical Game
To show what good pillars look like in practice, let’s build a hypothetical set for a hypothetical game — a cozy game, the kind where the point is to settle in, putter around, and make something of a world at your own pace.
Here are four pillars for this game:
- Failure is fun, not punishing
- There is a clear path to greatness and you can see your progress
- The world changes and reacts to you
- Everything can be accomplished in small steps
These are high level. They don’t describe specific mechanics, specific art direction, or specific systems. They describe the experience the game is trying to create. And — critically — each one is specific enough to test a decision against and get a clear answer.
Let’s do that.
Testing The Pillars
Failure is fun, not punishing
A designer proposes that when a player’s crops die from neglect, they lose all the seeds they planted and have to start the farm over from scratch.
Test: Does losing everything and starting over feel fun or punishing? Punishing. The pillar fails this decision cleanly — hard resets on progress are exactly what this pillar exists to prevent. The decision doesn’t make it in.
Now flip it. A designer proposes that when crops die, a little animation plays of the plants dramatically wilting, the player gets a small refund of seeds, and a cheerful NPC shows up to commiserate with them. Failure becomes a moment rather than a setback.
Test: Is this fun rather than punishing? Yes. The pillar supports it.
There is a clear path to greatness and you can see your progress
A designer proposes a skill system where improvements happen invisibly under the hood and only become apparent once a major threshold is crossed.
Test: Can the player see their progress? No. The pillar fails this immediately — invisible improvement is the opposite of visible progress. The decision doesn’t make it in.
Flip it. A designer proposes that every skill improvement is represented visually — a bar that fills, a number that ticks up, a small celebration when a milestone is reached.
Test: Is the path clear and progress visible? Yes. The pillar supports it — and in doing so, it’s already started defining UI requirements without anyone having to call a separate meeting about it.
The world changes and reacts to you
A designer proposes that NPCs have a fixed set of dialogue lines that don’t change regardless of what the player has built or accomplished: “We only have the budget to record 50 lines of VO for the whole game so we should only have the NPCs say very limited and specific things.”
Test: Is a world with static NPCs a world that reacts to you? No. If the villager says the same thing whether you’ve built a modest garden or a sprawling farm, the world isn’t reacting — it’s ignoring you. The pillar fails this decision.
Flip it. The same villager now comments on the new cabin you built, asks about the crops you planted, and mentions they noticed you cleared the land to the east — delivered as text bubbles rather than voiced lines. And suddenly the pillar has done something else useful: it’s opened a conversation about whether the game needs VO at all, or whether voiced lines should be saved for major moments only. The pillar didn’t just reject a decision — it redirected the budget conversation toward something that actually serves the game.
Test: Does the world react to the player? Yes. The pillar supports it.
Everything can be accomplished in small steps
This one deserves a fuller illustration because it’s doing more work than it might seem.
Imagine the player wants to build a cabin. That’s a significant accomplishment — it takes time and resources. But the path to the cabin is visible from the start: gather lumber and nails, which means cutting down trees and mining iron, which means having an axe, which means finding or crafting one. Every step in that chain is something a player can meaningfully progress in a short session. They might not get to the cabin quickly. But they can get closer, and they can see exactly how much closer they got.
Now a designer proposes that before the player can build on a piece of land, they have to defeat a boss that guards it. The boss fight takes thirty minutes and failing it sends you back to the start.
Test: Is a thirty minute boss fight a small step? No. It fails Pillar 4 immediately — and it also fails Pillar 1, because losing thirty minutes of effort to a failed attempt is punishing, not fun. Two pillars reject the same decision. That’s the system working.
Flip it. Instead of a boss, clearing the land requires the player to complete a series of small tasks over multiple sessions — removing rocks, cutting brush, leveling the ground — each one achievable in a short sitting.
Test: Can meaningful progress be made in small steps? Yes. The pillar supports it.
What The Pillars Did
Look at what just happened across those four tests. The pillars rejected specific decisions — hard resets, invisible progress, static NPCs, a thirty minute gating boss fight — not because someone in authority didn’t like them, but because they failed a shared standard that everyone on the team agreed to in advance. And they supported specific decisions for the same reason.
Nobody had to argue from personal taste. Nobody had to invoke their seniority or their vision. The pillar either passed or it didn’t.
That’s what good pillars do. They move the conversation from “I think” to “does this fit what we agreed this game is.” That shift is small in description and enormous in practice, especially on a large team with a long production timeline and a lot of decisions to make.
Notice also that the four pillars together paint a coherent picture of a specific kind of game without ever describing the game directly. They don’t say “cozy.” They don’t say “relaxing.” They describe the experience through the rules that protect it. That’s the other thing good pillars do — they communicate the vision to someone who has never seen the game, in terms specific enough to be useful and high level enough to leave room for creativity within them.
Not Every Game Needs Pillars
Before closing, it’s worth saying clearly: not every game needs pillars before it gets made.
A game jam is a pretty good example of how you can make something fun entirely on instinct and momentum. The constraints of a 48 hour jam are so tight that the game finds its own shape through necessity rather than principle. That can produce something genuinely surprising and good.
Pillars tend to matter most on larger games with larger productions and longer timelines — projects where the sheer number of people and decisions involved makes a shared reference point not just useful but necessary. Their entire value is in clearly and deliberately communicating a vision at scale, and reducing the routes to arguments that scale inevitably creates.
If you’re making something alone, or with a small trusted team, in a short window — you might not need them. You might already be the pillar.
But if you’re building something big, with a team of people who need to make hundreds of decisions independently and have them all point in the same direction — knowing what your pillars are, and making sure they’re the right ones, is some of the most important work you’ll do before production begins.