I have spent the last year working on casual PC/Mac games. There has been a fair share of ups and downs along the way. Most of the downs have been the direct result of my stubbornness and contempt for casual games. To be a successful designer, you cannot have a lack of respect for the audience you are designing for. Sounds easy enough, but it's a lesson that has taken the better part of a year to sink in.
When designing games for the casual audience, there are a few different challenges that must be overcome. And by "overcome", I don't mean "dealt with", I mean "worked with". This where having respect for your audience comes in. Casual games present themselves with different rules and expectations than "core" games, and it's your job as designer to stick to those rules. Otherwise, you run the risk of creating something for yourself and not for your audience (I know I've been guilty of this from time to time).
One of these challenges that I have learned how to work with is the challenge of storytelling in a casual game. Let me begin by explaining my (former) process of writing a story for a casual adventure game.
I begin by writing a complex, convoluted story filled with murder and mystery. It features secret identities and double crosses. I begin by leaving the reader disoriented and confused. Only at the end do I reveal all of the plot twists and explain what has happened. I am writing an award-winning novel (or so I think). Next, I think of how to fit the "amazing" story into the context of a game. Calling it shoehorning would be an understatement.
This, needless to say, was proven to be ineffective on many occasions. We would get feedback from players complaining that the story was confusing, the goals unclear and the world uninteresting. My initial reaction was to scoff at these "insults", responding only with "well they just don't get it!"
My counter-argument would be to point out that I've played games before where I've been left out of the loop until the very end (side note: using the argument "but other games do it!" like a 5 year old is not the way to win over your fellow developers when you're pitching a game design concept).
My stories weren't working in these casual games, I had to do something. I did the only thing I could do: learn.
One interesting thing about game development is that there is never a shortage of opinion about your game. You will hear criticisms from fellow developers, from your bosses, from the publisher and from your audience. Because harsh criticism is always a tough pill to swallow, it's far too easy to dismiss all of this feedback and simply move on (this is the wrong thing to do). It takes time, but when you eventually learn to embrace this feedback and learn from it, your games will improve drastically.
What did I learn about storytelling, specifically? Well, simply put, I learned how to streamline my stories into easily digestible (yet still exciting) tales that get the point quickly and draw the player into the world immediately.
What do I mean by this? Let me give a few examples from a game that I have worked on:
In the first draft of my story, the character meets several characters, including the villain. The player has no idea who any of these characters are, and does learn who any of them are until the very end of the story (all of the characters have overlapping stories and a shared history). The problem with this was that players were playing a demo version of the game (chapter 1 of a 6 chapter game), and had no idea what was going on. This was a problem because people were judging the game based on this demo sneak peek, and they were not impressed. Of course, my reaction was to tell them that they have to wait until they can play the entire game to understand the story. This did not go over well at all.
The game was being seriously judged based on this player feedback, and all of this negative feedback was holding the game back, something had to be done. I had to step back and re-examine my approach to this story. I had to think about who I was telling this story for and how to best deliver it.
My re-write of the story featured a more obvious villain (the villain is introduced to the player right away) and setting the player off in a chase after this villain. For the purposes of a game, this provides the player with an immediate goal. This is important and was lacking in the previous version. To add an element of intrigue (and to give players the satisfaction of experiencing the story at their own pace), clues are hidden throughout the game world. There are newspaper clippings, advertisements and notes left behind for the player to find that help them learn about the villain as they pursue him.
This approach has proven to be much more successful. Players are no longer left confused and disoriented but are given a clear goal. Most importantly, players are able to experience the story at their own pace and can learn (or ignore) as much as they choose. This method works much better than having characters on screen talking back and forth for a long time (a good sign that the game designer is trying to flaunt his "amazing" storytelling ability).
As I've said, this is a lesson that's easier taught than learned, as it took me a few development cycles to really learn the lesson. Most importantly, the real lesson is to understand your audience and what your design goals are. If you simply try to do "what you think is best, period", then you are setting yourself up for failure.
Humility is a powerful tool, indeed.