 |
| Hideo Kojima, my hero, took a picture very similar to this and posted it on his Twitter. *squeeeeeeaaaaaal* |
The lecturer opened up by telling us that the most important thing we could do is to iterate frequently and to fail fast. That is, when designing a game, the first version of it is pretty much guaranteed to be terrible no matter what. So rather than spending a thousand hours on the first playable version and putting the cherry on top only to have it fall apart completely, it's more valuable to spend a short amount of time on early versions of the game. That way, you get actual hard evidence and reasoning to back up the changes you make, instead of playing the game in your head and finding out later that it doesn't work out quite the way you thought it was going to in the end.
He continued on to teach us about what's called the MDA Framework. The MDA Framework is a sort of philosophical structure in which you can organize your thoughts and make a better game. Respectively, the MDA stands for mechanics, dynamics, and aesthetics. A game's mechanics are the rules and systems that make it go. You would find the mechanics of a board game you purchased in that game's rule book. Dynamics are what happens while the game is actually played. The lecturer made the point that you can't enjoy a game of chess just by looking at a chess board; you have to actually sit down and play the game. That act is the dynamics of a game. Finally, aesthetics refers to the desirable emotional response to the game. The "fun" if you will. However, we later learned to try to eliminate words like "fun" and "gameplay" from our vocabulary, as they are not helpful in game design. It's like calling a painting "good." It might be good, but it's not a very scientific or informative term.
The MDA Framework can be used to gain a number of different perspectives on a game that one is designing, but the one that seems most valuable to me personally is that it allows you to effectively reverse engineer your game. That is, you start by choosing an aesthetic goal, design the way you want the player to interact with your game, and lastly, refine the mechanics until the game is solid. A to D to M. Depending on what your goals for the game are though, you could approach the MDA Framework from any angle you like.
I mentioned earlier that the word "fun" is bad and should not be used when possible. The lecturer has a personal philosophy he shared with us known as the eight kinds of fun. He listed them as such:
Sensation - The sensory experience a player has with a game
Fantasy - Games as make believe
Narrative - Games as an unfolding story (This is distinct from fantasy in that it's about the story of the player playing the game, rather than the fictional story the game is telling. A good example of this being the drama of a chess game.)
-Challenge - Games as a problem to solve
-Fellowship - Games as a social experience
-Discovery - Games that contain worlds to explore or systems to learn and become skilled at
-Expression - Games that allow you to create things or express yourself in one way or another
-Submission - Games as a mindless pasttime (see: Angry Birds, Tetris, etc)
He stressed that there were probably more kinds of fun that we could come up with if we really tried, but it was more about finding and using a vocabulary that we're comfortable with. We can craft our own theories as we make our own games. I found this eight kinds of fun method very useful though and I'll probably continue to use it.
Later in the day I attended another lecture which delved deeper into the MDA Framework. Specifically, where should the player come into the equation?
Depending on the approach you want to take, you could insert them anywhere. Making the player themselves a mechanic of the game is something that's become more and more popular in recent years with motion controls and cameras being integrated into party games. You could also view the player as solely a subject which should react to your game, though in my personal opinion, that approach is more suited to passive media such as books and movies. But if the player is considered in a game's dynamics, you're accommodating them as they actually experience the game. This is the most logical place to think of the player for most games, in my opinion.
To expand on the player as a piece of a game's dynamics, the instructor talked a lot about human psychology and how game designers can manipulate the players in a number of ways. The example he gave (conveniently enough since I wrote about this game at length a few posts ago) was Pacman. In theory, the powerups in Pacman should make the game easier, right? You give the player a tool with which to survive and it should make it easier for them to win, right? Well in the case of Pacman, it causes players to play much riskier and greedier. A real world example he gave was when several groups of people were asked to build a tower as tall as they could using only marshmallows and dry spaghetti. They performed decently under normal circumstances, but when a large sum of money was offered to the winning team, not a single team was able to construct a qualifying tower. This psychological phenomenon is called the greed catalyst.
Later he talked to us about something called a self-serving bias. I'm sure everyone has experienced this before, "I lost because I was unlucky, I won because I am skilled." People have a tendency to attribute their success to themselves, and their failures to forces outside of their control. This is called the gunslinger's alibi. This is actually useful in friendly multiplayer games because it allows one player to feel good without the other player feeling bad. Wizard's of the Coast (a notorious maker of trading card games such as Magic and Pokemon) have an internal philosophy with their magic series called the 70/30 rule. A more skilled player should win 70% of his matches against a less skilled player due to events in the game that he could not possibly foresee or prepare for. This is a great rule of thumb for casual multiplayer experiences, though the audience of a highly competitive game like StarCraft might cringe at such a deliberate imbalance.
The lecturer reached a point that I couldn't help but strongly disagree with, though. He said that players are more tolerant of failure that can be blamed on bad luck, or random failure. As long as they are not blaming themselves, he claimed, they won't become frustrated. Before coming to this lecture, I specifically carried a design philosophy very close to me that stated the exact opposite. The player should ALWAYS blame themselves for their own losses. It makes them feel like the game is worth playing, worth mastering, worth another round. The phenomenon of losing a game to something you should have known about is called a purloined letter. If you doze off while playing and forget a particular rule and lose to that rule, you can't really blame anyone but yourself. The instructor said that the gunslinger's alibi plus a purloined letter equals a rage quit, since it becomes impossible for the player to escape their own ineptitude.
It may be true that players are more accepting of random defeat, but I would argue that the only reason for this is low investment. Low investment means that they are dangerously close to getting bored, and a bored player is dangerously close to quitting. Also, if a game glitches out and shuts down, I would put that in the category of random failure. Losing to a coin toss. For me personally, nothing makes me angrier, so I was surprised to hear the lecturer speak in favor of such a thing, but I guess I've been playing video games for almost all my life so perhaps my perspective is in the minority. It's certainly more punishing and games I make might be less accessible for it.
Even I'll admit that it's somewhat of an unsolved mystery in game design. Mastery through repetition is one of the oldest themes in video games, but is it obsolete? Is it engaging? Is it appropriate for game design moving forward? Should trial and error really be the way a player is taught to get good at a game? Particularly in competitive multiplayer games, I'm quick to criticize games like StarCraft and Street Fighter for failing to teach the player how to actually get better at the game. Learning by going online and getting destroyed by more experienced players is incredibly discouraging, and it led me to quit competitive StarCraft, even though I love the game to death. It's a tough case to solve to be sure, because weakening failure also weakens success.
So that's basically a summery of GDC day 1 for me. Hotel internet has me behind schedule on these writeups unfortunately, and I'm far too lazy to do much proofreading on this. These are just meant to be quick summaries of my experience at the show, and jotting down what I've learned. Hopefully it's not too longwinded and boring. I certainly didn't take enough pictures to sprinkle through these articles.
 |
| Not too busy for now. That will probably change when the expo floor opens. |
Anyways, I'll write again "tomorrow!"
No comments:
Post a Comment