Any game developer that's worked with other developers knows how it starts. Someone suggests an idea, which they're really excited about. Someone else on the team thinks it won't fit. The two go back and forth and both as both are left wondering what the right decision is. This is exacerbated in the early phase before you know what your game is or before it's fun.
Or sometimes the director of the game is faced with great suggestions from the team and community. There's money and time on the line - sometimes millions and years. You really want to make sure your ego isn't getting in the way, that you're open to new ideas, but you also don't want to risk the game and work you've all put in to get to this point. How do you decide what to include? Which suggestions will truly amplify?
And this problem worsens when you attempt to make better, more original, games.
How can these disputes be resolved? Better, how can they be prevented? How do we know if we're actually making the game better, and it's not just feature creep?
What's helped me is to start by creating pillars & values. These are memorable catch-phrases that ground and direct everyone.
- Pillars are the foundation of all development. They are called pillars because they "support" the planning and building of your game, especially when other people and disciplines are involved.
- Values are ideologies for the whole game. They're useful for areas your pillars don't cover. They often represent the values of the team or company building the game.
Pillars could be the what of your game. They won't change if the market changes, nor if the team changes, nor if a cool new game shows up.
They are the aspects that most excite you about the seed of a game, they are what you want to make in the first place. Short, emotional phrases have worked the best for me. Examples: Interconnected Story Webs, Never-ending Surprise, Dynamic Environments (NS2), Asymmetric Strategy (NS2),
Here are the original Subnautica pillars:
Intoxicating Creation: The overwhelming excitement of being able to build anything.
"I do not think there is any thrill that can go through the human heart like that felt by the inventor as he sees some creation of the brain unfolding to success...such emotions make a man forget food, sleep, friends, love, everything." - Nikola Tesla (1943)
Thrill of the Unknown: Excitement, dread and tension of exploring the unknown. No idea what dangers/rewards are down there.
Cascading Hysteria: Uncontrollable outburst of emotion, fear, irrationality, laughter, weeping, etc. FTL style chain of "oh sh!t" dependencies, where a failure in one system can affect others, until you're suddenly in trouble.
I like to flesh each of them out with a paragraph or two of examples (or that Tesla quote), but most of the time you just need something memorable enough that everyone can remember the exact wording in the middle of a conversation.
Looking back at these, I think we mostly focused on the Thrill of the Unknown (the whole game and eventual story), with a medium amount of Intoxicating Creation (base building, farming) and just a dash of Cascading Hysteria (base flooding and sub fires). Ideally we would've done more to support them all.
These weren't formal when we started, but now we often formalize them at the same time we create our pillars. They could be thought of as the how of your features. They also tend to mesh tightly with who your team is.
These values are a bit more design-focused, but I don't think this is a necessity (I was leading the team as the designer so tend to think this way):
Never tell the player what to do. Let them decide. If there's something we want them to do, breadcrumb it.
The world doesn't care about the player. The player is a foreigner in an unknowable, majestic alien world. This lead to Non-Violence to creatures and the world.
Respect the player and their time. Don't manipulate them through achievements, dopamine and extrinsic rewards. Give them an amazing, rewarding experience that takes effort.
Note that these are pillar-independent - they affect them but also most everything else in the game. They help define the mindset of making the game.
- Pillars shouldn't take long to make: perhaps a couple hours of the leads talking and writing together. I think a great game could certainly have only one pillar, but I think it would be hard to make one with five or more. When in doubt, have fewer.
- Ideally, everything that goes into your game will be in direct support of a pillar. When an idea doesn't seem to support a pillar, it can be discarded, without it being personal or subjective from the lead.
- Each pillar is like the horizon - it leads you somewhere but you'll never fully arrive.
- Ideally, every aspect of your game will evolve, except the pillars and values. If you change one along the way, it would probably ripple to create a lot more work (or reduce the "integrity" of your game).
- When a straightforward or low-cost idea supports multiple pillars, you can implement it immediately - probably with no questions asked and no meetings. This is where your game can make big leaps.
- Even if you're a team of one, pillars are useful for yourself, to keep integrity in your game your development on track.
- If you make your pillars public, it could give a solid base of reasoning for discussion about new features among your players. If you make your values public, your players may understand more about its creators.
- Both pillars and values need to be continually reinforced during development. Refer to them with their their exact wording whenever you can. Teams have so much to keep track of, it will take awhile for them to really sink in.
- I've found pillars to be more useful in video game development than board games, probably due to the cross-functional nature and larger size of those teams. But I still have at least one guiding principle and/or inspirational paragraph that I can return to when I'm stuck. Here's my one pillar for a board game prototype I'm working on:
“After one and a half months the tomatoes were climbing up the sunflowers, in-between dwarf beans, celery, cabbage. The climbing beans were growing up the sweet corn through a sea of squash. Everything surrounded by salads and onions, potatoes, spinach and peas; with garlic and leeks around the edges; Swiss chard, beetroot and peppers with shallots and turnips in the gaps. A food jungle…so much food everywhere!”
I could've summarized this as Food Jungle, Automatic Abundance or Overflowing Nature, but for a team of one I'm happy to just the paragraph).
Pillars and values serve as kind of an artistic version of first principles.
First principles is kind of a physics way of looking at the world, and what that really means is, you … boil things down to the most fundamental truths and say, “okay, what are we sure is true?” … and then reason up from there. That takes a lot more mental energy. - Elon Musk
But instead of forming a basis of reasoning, they create shared understanding of artistic constraint.
If we did somehow codify all the first principles in game development, they would describe the fundamentals of all games, not just the one you're choosing to make. They would include principles of interactivity, feedback, feel, form, aesthetics, immersion, drama, architecture, layout, music composition, etc. A daunting task.
But even if we did codify them, teams would still want to create pillars and values to lead them to the specific game they want to make.
“Making games combines everything that’s hard about building a bridge with everything that’s hard about composing an opera. Games are operas made out of bridges.” - Frank Lantz
I'm just getting started with this, so I could use some guidance for what you like and don't. So please let me know what you think.
Special thanks to David Kalina who first created the concept of values for Below Zero, alongside our traditional pillars.
When the Subnautica pillars were first written, we had no idea about multiplayer, story, platform or many other important elements. We had been prototyping for a couple months at most, and the game was at this stage.
Tim Keenan on using Game/Design Pillars to guide Duskers development: