TGC '10: Breaking the Fourth Wall
The trick of great game design is more than just having great ideas and a solid team; it's also about managing your own preconceptions, and focusing on the players experience.
Red Storm's Gary Stelmack has been designing games for ten years, and before that worked in QA, making him pretty well qualified in understanding how players interact with games, and what that means for designers. In his eyes, one of the key aspects of game design is that a player's perception of a game is the whole reality, and what you intended and what you actually delivered are not necessarily the same thing.
"Your first impression absolutely has to be the one you want to make," he said, "just like in real life; you never get a second chance to make a first impression."
Stelmack told the story of Red Storm's 2000 RTS Shadow Watch [http://www.amazon.com/Shadow-Watch-Pc/dp/B00004RKE4/ref=sr_1_1?ie=UTF8&s=videogames&qid=1278690563&sr=1-1] which had a very complicated AI that would move its forces into optimal positions, but the player never got to see this, and so it appeared that the game was throwing enemies at you at random. The disconnect between what the game was actually doing, and what the players perceived to be happening was sufficient to change the player's perception of the entire game.
Stelmack's solution is a very simple one however, although its execution can be difficult: have a clear vision of what you want a player to experience, and be able to put aside your preconceptions and listen to feedback.
Red Storm's approach is to start with broad goals for feature - Stelmack's example was a game where pistols were only supposed to be a last resort weapon - and then to prioritize those goals, so should something need to be cut or changed, the difficult decision of what has to happen has already been made.
From there it's a case of testing and modifying your game; creating specific levels to test individual systems, but also testing the game as a whole, asking the right questions, and encouraging your testers to be honest with their feedback and once the feedback is obtained, it has to be analyzed and acted upon, and Stelmack said that at Red Storm, the assumption is that it is the developers who have done something wrong, not the tester.
"It's very important to work around your own preconceptions. You put tons of hours into figuring out how all the systems are supposed to work. You know what all the numbers on the spread sheet are and what they're supposed to be. The player doesn't."
Permalink
Red Storm's Gary Stelmack has been designing games for ten years, and before that worked in QA, making him pretty well qualified in understanding how players interact with games, and what that means for designers. In his eyes, one of the key aspects of game design is that a player's perception of a game is the whole reality, and what you intended and what you actually delivered are not necessarily the same thing.
"Your first impression absolutely has to be the one you want to make," he said, "just like in real life; you never get a second chance to make a first impression."
Stelmack told the story of Red Storm's 2000 RTS Shadow Watch [http://www.amazon.com/Shadow-Watch-Pc/dp/B00004RKE4/ref=sr_1_1?ie=UTF8&s=videogames&qid=1278690563&sr=1-1] which had a very complicated AI that would move its forces into optimal positions, but the player never got to see this, and so it appeared that the game was throwing enemies at you at random. The disconnect between what the game was actually doing, and what the players perceived to be happening was sufficient to change the player's perception of the entire game.
Stelmack's solution is a very simple one however, although its execution can be difficult: have a clear vision of what you want a player to experience, and be able to put aside your preconceptions and listen to feedback.
Red Storm's approach is to start with broad goals for feature - Stelmack's example was a game where pistols were only supposed to be a last resort weapon - and then to prioritize those goals, so should something need to be cut or changed, the difficult decision of what has to happen has already been made.
From there it's a case of testing and modifying your game; creating specific levels to test individual systems, but also testing the game as a whole, asking the right questions, and encouraging your testers to be honest with their feedback and once the feedback is obtained, it has to be analyzed and acted upon, and Stelmack said that at Red Storm, the assumption is that it is the developers who have done something wrong, not the tester.
"It's very important to work around your own preconceptions. You put tons of hours into figuring out how all the systems are supposed to work. You know what all the numbers on the spread sheet are and what they're supposed to be. The player doesn't."
Permalink
