I was brought onto a project as part of a co-development arrangement. My whole team went through an onboarding process that included a presentation of the game and its pillars — the foundational principles that were supposed to guide every decision made on the project. I remember sitting there trying to get my bearings on what we were building and what we were supposed to be building toward.
The slide went up. Six major pillars. Eight minor pillars. Several additional items formally labeled as “posts.” I knew the moment I saw all of them on the screen at once that we were going to have a problem. Not because the people presenting weren’t knowledgeable or passionate — they were — but because by the time you have that many pillars, formally categorized and tiered, you don’t really have pillars anymore. You have a document that can justify almost any decision and almost any counter-decision, depending on which pillar you pick up and point at.
One of them, presented as a major pillar if I’m remembering correctly, was something functionally equivalent to “The Game Should Be Fun.”
I wrote it down. Then I crossed it out.
A Topic With Strong Opinions
Game pillars — sometimes called design pillars — are one of those game development concepts that tend to generate strong opinions. Like design docs and narrative bibles, most developers have a position on them and aren’t shy about sharing it. Some advocate for them strongly. Others think they’re unnecessary, or worse, that they actively get in the way of the kind of organic discovery that produces the best games.
I have a take on that, as I do on most things. But the short version is that pillars, like most tools, tend to get blamed for problems that are really about how they’re used. The concept isn’t the issue. The execution usually is.
What Pillars Actually Are
Here’s the definition I keep coming back to, and it’s not the one you’ll find in most introductions to the concept.
Game pillars are not directives. They’re not a mission statement, not a mood board in sentence form, not a list of things the game is going to be. They are rules to test decisions against.
That distinction matters more than it might seem. A directive tells you what to do. A test tells you whether what you’re doing is right. When a design question comes up — and in game development, design questions come up constantly, at every level, from the broadest creative choices to the smallest implementation details — a good pillar gives you a way to evaluate the options. You hold a proposed decision up against the pillar and ask: does this pass? Does this fail? Does this conflict with something else we’ve committed to?
That’s what pillars are for. Not inspiration. Not decoration. A decision-making tool.
This is also why discovering and solidifying pillars in pre-production matters as much as it does. A game without clear pillars is a game where every significant decision has to be argued from scratch, every time, by whoever has the most authority or the most energy in the room that day. Pillars don’t eliminate disagreement — nothing does — but they give disagreement somewhere to go. They create a shared reference point that exists outside of any individual’s opinion, which does a lot of heavy lifting that a less experienced or less communicative creative director might otherwise struggle to provide.
The Three Traps
Back to that onboarding presentation. What I was looking at, across those six major pillars, eight minor pillars, and assorted posts, was a document that had fallen into all three of the most common pillar traps simultaneously. They’re easy to illustrate with the same example, so let’s use it.
Too Many
In my opinion, a game should have around three to five pillars. If you cannot encompass a high level game vision in three to five pillars, you have too many. That’s a position people push back on, and I understand why — it sounds restrictive. But the restriction is the point. Three forces a discipline that fourteen doesn’t. If you can only have three, they have to be genuinely high level. They can’t be implementation details or genre descriptions or wishful thinking. They have to be the things so fundamental to what makes this game this game that every other decision can be tested against them.
When you have too many pillars they start to contradict each other. And contradiction turns a decision-making tool into a debate tool. You’re no longer testing a decision against a shared standard — you’re shopping for the pillar that supports the decision you already wanted to make, or the one that lets you shoot down the decision you didn’t. Six major pillars, eight minor pillars, and several posts is well past any useful ceiling. At that point the document isn’t guiding the project. It’s providing cover for whoever is loudest in the room.
Too Obvious
“The Game Should Be Fun” is not a pillar. It is the absence of a pillar wearing a pillar’s clothing.
Every game should be fun. That’s not a design principle — it’s a baseline assumption. The problem with a pillar this obvious isn’t just that it tells your team nothing they didn’t already know. It’s that it’s so universally true that it can be used to justify almost anything, which means it can be used to block almost anything too. Pillar X says we should change Y. But Y is fun, isn’t it? And fun is one of our pillars. Conversation over.
That’s not a pillar. That’s a rhetorical shield. The specific kind of fun your game is pursuing, the specific experience it’s trying to create, the specific feeling it should leave a player with — those can be pillars. “Fun” cannot.
Too Vague
“Accessible to players” sounds like a reasonable design principle right up until you try to use it as one. Accessible how? Accessible as in the controls are easy to understand? Accessible as in the camera moves clearly enough that players can always see what’s happening? Accessible as in the game is designed so that people with certain physical conditions can play it comfortably?
Those are three completely different design conversations. Three different sets of decisions, three different sets of constraints, three different potential conflicts with other pillars. A pillar that three people can read and walk away with three different mandates isn’t a shared standard — it’s a future argument waiting to happen. Vagueness in a pillar doesn’t feel dangerous in pre-production. It feels inclusive, accommodating, open to interpretation. That’s exactly why it’s dangerous. By the time the argument it was always going to cause actually arrives, you’re deep in production and the cost of resolving it is much higher than it would have been if you’d been specific from the start.
What Comes Next
The three traps — too many, too obvious, too vague — are the easy part. Identifying what bad looks like is useful, but it only gets you so far. The harder and more interesting question is what good pillars actually look like, what they accomplish, and what the process of discovering them in pre-production actually involves.
That’s Part 2.