What are they? How do you create them and how do you use them? Let's talk design!
Design pillars are a tool for you and your team to use in the pre-production and production phases of your game development process. Each pillar- and there are usually three- represents a critical aspect of the game you're intending to make. By replacing one pillar with another, you would be making an entirely different game. They are rules- not guidelines- that support your goal and vision of the ideal game you're creating. When used properly, they keep your scope narrow and avoid feature creep, enable your team to quickly make important decisions and help prioritize tasks and focus manpower.
Another way to think about the pillars is that they act as filters. If your design team would like to add a feature, the pillars can be used to determine if the feature is a good fit or not. Of course, other considerations like time and budget will come into play, but even if you had unlimited resources, if a feature doesn't agree with the pillars, then its shouldn't be added. Let me walk you through some examples and it should become clear.
For UnincrediBall (3v3 sports brawler), our team came up with three pillars early in pre-production. Creating them early allowed us to use them to filter the many decisions that need to be made in pre-production, and the game was ultimately built on top of them.
First pillar: No Downtime. This is a great example of how the simpler the pillar, the stronger it will be. We wanted our game to always have something for players to do and never have players waiting to play our game. Thus, there is no death or re-spawning, no hard crowd control, and no in-game cut-scenes. When we began to work out character abilities, stuns were out, but knock-backs were in. When determining whether to reset the player characters to their side of the field after a goal was scored, we decided no. Instead, players have a few moments to make a decision: where should I position myself? Defensively? Offensively? Or should I just harass the enemy team while waiting for the new ball to drop? Our game was built off of the concept of No Downtime, and thus we could use the pillar to filter design decisions.
Second pillar: Classes Inform Roles. This pillar isn't as widely applicable as the first, but was more important for certain areas of our game such as character design and the character draft UI. We had three classes: Attacker, Tank, and Support and each team drafted one character of each class. Each class had strengths and weaknesses that were enforced by their active abilities and passive stats. For example, the Tanks had high resistance (to counter knock-back) and were heavy hitters, but were very slow and could easily be punished for being out of position. These classes nudged players into their intended roles, allowing players to easily learn each character while also allowing them to experiment once they learned the basics. Notice: classes inform roles, not determine or dictate roles. Player freedom is usually a good idea for games. While playing a character as their intended role was easier and effective, we also saw many uses for characters outside their usual role which proved to be effective.
Third pillar: Pitch & Play. Our team realized early on that our final product- our game- wasn't really intended to go to market, but rather to be presented and played at an event called Pitch & Play. At P&P there's lots of folks from industry who are meeting up with old friends and socializing. It's well lit and there's always the murmur of conversations in the background. The crowd is made of equal parts gamers and non-gamers, and they typically visit a team for five to ten minutes before moving on to browse other games.
Thus, we formed our third pillar around the format of the Pitch & Play event, which affected an incredible number of decisions we made. Game lengths over 5 minutes would be too long. Most players didn't wear headphones, and playing audio through six side-by-side computers would be obnoxious, so audio became a lower priority. One of the main considerations was that we'd have a lot of headhunters, managers and the like who- while they were in the business of games- weren't exactly competitive gamers. We lowered our skill floor to allow these types of players to quickly get into the game, but kept a high skill ceiling for the hardcore gamers. We also added things like aim assist, ball-lock, and lots of tutorialization via the loading screens and color-coded iconography.
The third pillar also fit perfectly with our first pillar: No Downtime. Since we planned on only having five minutes to show off our hard work, we wanted to make sure players weren't spending any of those five minutes waiting to re-spawn or watching a cut-scene. Every second we had we wanted the player to be empowered and exploring the features of our game.
A couple tips to get you going:
- The fewer pillars the better.
- Having trouble narrowing down pillars? Remove one and consider what your game would be without it. Can you combine two pillars down into one overarching concept?
- Keep the pillars simple. Too complex and they won't be followed.
- Each pillar should have excellent reasoning behind it.
- While the pillars are rules, not guidelines, if you're re-designing and significantly changing the direction of the project, it may be wise to create new pillars.
- The pillars should not conflict with each other.
- Pillars can be used like filters for decision making.
Hopefully this post gave you some ideas about how to create and use design pillars. When used effectively they will save a ton of time by allowing for quicker decision making and reigning in the scope of a project. For practice, take a look at some of your favorite games and try to determine what their design pillars might be.
Additional Links
Gamasutra article on design pillars.
Comentarios