Love of adventure lives on: lessons from an indie game designer
First posted on 01 February 2012. Last updated on 01 February 2012.
|
| Captain Zaron and the Trials of Doom is a browser based fantasy adventure game developed by Studio Meristem. |
|
|
Captain Zaron and the Trials of Doom
Captain Zaron and the Trials of Doom is a full-length point-and-click fantasy adventure game created by indie game designer Peter Lemiszki of Studio Meristem. The game tells the story of the fearless mercenary and pirate Captain Zaron, who must save his sister Elsa from being sacrificed by an evil tyrant named Mulduralm in an ancient ritual that will herald an apocalyptic end to the entire kingdom. The game contains over 150 locations and features artworks reminiscent of classic LucasArts and Sierra adventure games. The game can be played in any modern web browser with Adobe Flash.
For more information, visit Studio Meristem.
There has been very little difference of opinion amongst both adventure game enthusiasts and adventure game designers as to what is causing the current decline of the genre. Famed game designer Ron Gilbert saw the writing on the wall back in 1989, when he created a list of game design pitfalls in an essay subtly titled Why Adventure Games Suck (1). Sadly, his conclusions about the genre still ring true today. The lesson is simple—frustration and entertainment do not mix.
Yet, an obvious problem does not always imply an obvious solution. After all, if adventure game designers set out to ensure that the player will ever have the slightest trouble solving any of the game's puzzles, the result will be an incredibly boring and unsatisfying game offering the player absolutely no sense of triumph. A game may have dazzling art and a fantastic story, but if it never gives the player a problem to solve or a challenge to overcome, then the player is going to miss out on a huge part of the gaming experience.
Instead, good game designers intend for the player to have to stop and think—but only briefly. If a player is only stumped for a few moments when faced with a puzzle, then the designers have succeeded in offering the player the best of both worlds—the joy of problem solving, but without the frustration of getting stuck.
Lessons in game design
As a game designer, this was my goal when I began designing Captain Zaron and the Trials of Doom, a browser based game (Adobe Flash required) that is a fantasy point-and-click adventure inspired by some of the adventure games I had played and loved when growing up. I wanted to mix what I considered to be the greatest strengths of classic adventure game series, such as Quest for Glory, King's Quest, The Legend of Kyrandia, and Zork, into a modern adaptation that would attract veteran gamers of the genre but would also find an audience amongst younger gamers who might be unfamiliar with the games that inspired it. After years of work, I finally completed the project and released the game publicly for free in November 2011. The response to my game far exceeded my expectations. Soon after the game was released, I began receiving passionately written emails sent from players all over the world and of all different ages giving me their reactions to my game.
After reading all of these emails, I arrived at a pair of important conclusions:
The demand for adventure games is alive and well, all across the globe.
The intense dislike of getting stuck in an adventure game is equally alive and well, all across the globe.
What struck me most about these emails was just how starved these gamers were for adventure games, the amount of time they had invested in playing mine, and their determination to finish it. The experience convinced me that the adventure game genre could not only survive but could even undergo a renaissance if game developers could learn how to avoid certain pitfalls that had continued to plague the genre.
While creating my game, I learned a trio of lessons:
Lesson 1: every puzzle is 1.5 times as hard as you think it is
I studied screenwriting in college. However, it was not until I joined a writer's group after graduation and began writing some scripts in workshops that I realized how difficult it often was to get outside of my own head when brainstorming. I found this concept to apply equally to both writing and game design.
Your ideas may seem intuitive to you because you first come up with them. Yet, not everybody is going to be on the same wavelength. Game designers must learn how to put themselves fully in the player's shoes in order to predict how the player will react to a puzzle. If you believe that a puzzle is a bit too easy when designing it, then the puzzle is probably just right for the player.
Lesson 2: text is your friend
Amongst the most pleasurable surprises for me while programming my game was realizing just how much I enjoyed writing the text.
In fact, I have come to believe that text is the most undervalued asset in adventure game design. The stage may be the meeting place of all the arts (as said by Oscar Wilde), but adventure games add another element into the mix—the written word. It comes as absolutely no surprise to me that legendary game designer Roberta Williams has gone on to become a novelist—the similarities between reading literature and playing a text adventure are obvious. While screenwriters must develop an entirely different set of skills than novelists, game designers have the strengths of both mediums at their disposal. Sadly, it seems like a lot of modern adventure games are veering away from having the player read any text at all, which (I believe) is a step in the wrong direction.
Lesson 3: reflex based challenges need to be moderated
In an attempt to include more variety of gameplay, I designed a few timed swordfights into the game. This ended up aggravating a lot of players. In the days after the game was released, I received many emails from gamers who had spent hours playing my game, only to reach the sword fighting scene (fairly late in the game) and be unable to get past it. A particular fan even wrote me a lengthy essay explaining why the sword fighting was incompatible with a "bona fide" adventure game. It soon became clear that I would have to program a new version of the game that would allow the player to moderate the difficulty of the sword fighting, a feature that I should have implemented at the outset. The irony for me was I thought that, by including sword fighting in the game, I was actually helping to create a following for the game by attracting gamers who were more accustomed to a lot of action play.
Instead, a substantial part of the adventure gaming audience has a taste for the genre precisely because the gameplay does not require having quick reflexes. Rather, adventure game fans enjoy being able to proceed through the game at their own pace and of their own accord.
Final thoughts
I hope that those of you who are developing your own adventure games have found these lessons to be informative. Of course, the most important lesson is that, when it comes to designing your game, the opinion which truly matters the most is your own. It takes a very long time to illustrate and program an adventure game, and you will never reach the finish line if you not love your creation every step of the way.
References
1. http://grumpygamer.com/2152210 (Why Adventure Games Suck)