Pillars of Design: A Supporting Role

A while back, we talked about GDD (Game Design Documents) - what makes a good one, what makes a bad one. Today, we are going to look at the current in-vogue alternative approach, known as the Design Pillars approach. This way of thinking is interesting, as it is both intuitive and instinctive, in that it reflects the actual process of designing very well. Is it actually useful for communicating a design? Yes, I think I would say so. Whether it's strong enough to stand on it's own without back-up from a GDD however, I'm not as convinced.

Before we start examining the practicalities or otherwise of Design Pillars, let's briefly overview what they are. And, well, that's hard to do. Nobody (at least within the scope of my Google-fu) seems to have taken the time to sit down and create an industry-standardised definition of what the Design Pillars are. The short answers seem to be "the goals of the project..."

...or occasionally, more specifically, "the emotions the player is meant to feel when interacting with the project."

Now, this is fine, and helpful, and a good way to talk about a project. What do we want to do? What do we want the player to do, to feel, to see and explore? What kind of experience are we making? These are all really important things to consider, and should absolutely be written down somewhere, collectively agreed, and then blown up into a massive poster and stuck to the studio wall where everyone can see it. Good Design Pillars then, defined (roughly) as above, should serve as excellent guiding principles for a game project, and everyone in it, to ensure they share a vision and a goal.

However...

Is this really enough to replace the GDD? I'm not convinced. Getting rid of the GDD might work in a small, experimental setting where there is an shared belief that both the process and the product are, at least in part, an artistic endeavour. Design Pillars works for teams where the destination/end product is being discovered as part of the process. Which is a totally valid way to work for indies, small studios, and terrifyingly experienced veterans, like Brenda Romero. It's also an approach that should really suit people working with a known IP, which, because it's well known and established, actually becomes the dominating constraint on their creative endeavour. You can make the best, most fun detective game in the world, but if you send Detective Poirot to outer space to fight zombie aliens half way through it, you've most definitely missed the point of the Agatha Christie game you were making.

Where the Design Pillars concept - to my mind at least - really comes unstuck, is when the outcome of a project is a fixed entity. And this happens more often than you would think. In contract work and client work, the owner of the product, the person who is paying you to make this game, has already decided what they want from the process. A game play designer might be brought in, a monetisation designer might be brought in, but they serve the needs (sometimes whims!) of the client, and may find themselves working against one another at times. The client wants a game to be fun all the time - because why wouldn't you - but the gameplay designer knows that a game must at times be unfun in order to create moments of fun. The gameplay designer knows that gameplay is a rollercoaster of effort and reward, and that though constant rewards may sound like bliss, in terms of experience design, it quickly becomes boring and a disincentive to play. The monetisation designer knows that the client and most of the programming team have an idealogical hatred of in-app purchases, but also knows that the client will be rather disappointed if their game is a massive commercial failure. So every decision that is made and implemented into the game will, by it's nature, be a compromise between a set of aims, failing to satisfy any of them to an optimum degree. The Pillars, as described as a set of binding principles which dictate decisions, therefore cannot be effective in a team where different persons are serving as Champions of conflicting design requirements; each team member will end up in conflict with one another and ultimately with the Pillars themselves, especially if they are budget-responsible. A pillar of "endless replayability" must eventually be recoiled against the protests of a furious accountant and an exhausted level design team.

Design Pillars are too singular and monolithic to satisfy the needs of game design work on their own. Whilst the GDD may be cumbersome, and time-consuming to maintain, it serves - and this is crucial - as a record of decisions made thus far, and why. The GDD is a living document, it evolves with the game, and the analogy made previously, of a Bible, stands well in this case. The Design Pillars are the Principles of Engagement, they are the Ten Commandments, The Five Pillars, The Noble Eightfold Path. The GDD is the Bible, the Qur'an, the Sutras, the essential supporting document that explores those principles in more depth, explains them, examines them, justifies them and places them into a context with commentary or even story-telling. Though you can have the Design Pillars without the GDD, the Qur'an without the Five Pillars of Islam, they are really two halves of a whole, and you only really understand one by consulting the other. How did we get here? Why is this our conclusion? Why are we acting in this way? We can look up the answer to these questions in the GDD. Just because nobody reads the GDD for fun doesn't mean that they don't appreciate it when it can be brought in to mediate arguments!

Therefore, whilst I think the idea of Design Pillars is a good one, I'm unconvinced that they should be adopted at the expense of the GDD in the majority of cases. Rather, the GDD and the Pillars should work alongside one another, providing high level direction backed up with detailed explanation. Designers might not want a GDD, but as a Producer, I think you need one.

#GDD #Design #DesignPillars