Previously on RDD:

• Resonance Developer’s Diary #1: The Beginninning

Welcome back to this month’s Resonance Developer’s Diary. If you missed last month’s inaugural diary, make sure to click here and check it out.

This entry is divided into three parts. First a progress update, then a discussion of some of the game’s design goals, and finally some previews of one of the game’s unique gameplay systems.

Progress has been slow but steady. An apartment move for Nauris and some interesting hospital visits for me (which I intend to write about here soon!) caused some interruption to the workflow. I’ve also taken on some side jobs to help raise the funds for this game. I started transcribing self-help podcasts for a Japanese company that wants to make Japanese versions. I get paid around 300 dollars per hour of audio that I transcribe, so it’s paying for a good couple backgrounds. Unfortunately, thanks to muddy audio and mumbly interviewees, the transcription process can take a while sometimes.

This month, a few more gorgeous backgrounds have rolled in. We haven’t started the process of animating the backgrounds to make them look alive yet, so the game is looking a little too static at the moment. But rest assured, that will be remedied before the conclusion of development. What we do have are some dynamic and beautifully illustrated scenes.

The characters and animations have been progressing smoothly. I’m continuously amazed at Shane’s pixel-pushing abilities.

Programming has been progressing, but didn’t quite reach the milestone I had set for myself this month. I should have the first fully-playable, dialogue-complete section done in the next two weeks though. Then we’ll see about revealing some sexy screen shots.

I continue to find project management a learning experience. I’ve been surprised at how much of my time actually goes into dealing out tasks, making example sketches and diagrams, reviewing assets, and asking for revisions. I don’t like giving criticism, especially when the stuff I’m seeing is so phenomenal and light-years beyond my own artistic capabilities. But I’ve learned that I have to be strong to make sure that the game stays on course to achieving my creative vision. This is not to say that I’m beyond taking advice or suggestions. I think that my team has learned how receptive I am to good ideas, and I’ve learned how full of good ideas that they are!

Thanks to Shane, the GUI has ended up looking totally different from how I originally envisioned it (though it still works the same way) and now I can’t wait to show the purdy thing off. Nik, who I haven’t tasked to music quite yet but still keeps tabs on everything, poked his head into one of the background asset tasks that I dealt to Nauris and pointed out a simple yet brilliant change that I could make to greatly enhance the tension that the scene required. And Nauris has come up with some brilliant cinematic ideas for scene layouts and transitions that will really make the game hot stuff.

Working over the internet with three people in three different countries from my own adds some challenge to the whole thing, but I think we’ve overcome most of the speed bumps and have gotten the process down pretty well. Still, it’s slower going than I thought, but I think the end result is something we’ll all be proud of.

In lieu of the afore-mentioned sexy screen shots, I’d like to briefly discuss some of the design goals of the game and, in the process, drop some shocking (note: not so shocking) revelations about the game.

This game, like most adventure games, is intended to be played by using your brain more than your reflexes. In most adventure games, the focus is on the story which is broken up by a number of obstacles in the form of puzzles. Your reward for solving puzzles is more story. Sometimes, these obstacles feel completely unnatural. They can become tacked-on “guess what the designer was thinking” try-everything-on-everything-else fests. This is what adventure games should not do.

If I may use my own game as a negative example: In Anna, I wanted to tell this story of an artificial intelligence and her relationship with a technician. I also wanted to try something new and fun presentation-wise with regards to the parallax pseudo 3D. In these two respects, the game was a success. However, in my opinion, Anna fails as a game in the puzzle department. They really just seem like they were tacked on to add some game to the game. I mean, whoever it was that invented a Towers of Hanoi interface for their computer system really needs to be fired. In my defense (against myself?) I had to come up with the puzzles and implement the entire game in a week. I’d like to some day remake the game with better puzzles.

During the designing process of Resonance, I was careful to avoid these kind of tacked-on puzzles. As much as possible, puzzles that the player comes upon should be defined by problems caused by the plot with solutions involving the plot and rewards that move the plot along. Obstacles encountered shouldn’t be arbitrary or unrealistic. Puzzles should feel natural, as if you could encounter them in real life, and should be overcome in manners consistent with real-world logic. If the solution is not readily apparent, it should be hinted at in the normal course of the game, and if possible, should be tied in with the story.

Even the puzzles that aren’t immediately connected to the story, like a character who wants you to do something for him before he’ll give you the information you need (Oh, the shame of utilizing such an old adventure stand-by!) involves the player using information that he has gathered over the course of the game and has a significant impact on the main character.

With Linus Bruckman, I made a game that appealed to fans of mind benders and logic puzzles, but immediately turned off a lot of more traditional adventure fans. In making a commercial game, I still want to include those mind benders that I love, but I need to also make a game that appeals to the traditional crowd, since they’ll be making up a large percent of the target market. To do this, I’ve tried to implement multiple-solutions to some puzzles in Resonance in order to account for various players’ different playing styles.

For example, in one early section of the game, you need to get to a room that has been rendered inaccessible. There are two ways to gain entry. A mathematically-minded person might approach the problem by attempting to rewire a security door in a complicated logic puzzle. A person with a different mind-set might try to gain entry from a different side by combining some inventory items. At least one of the ways will hopefully appeal to to each player and the real completists will want to try both for the extra points! (I’ll discuss the usefulness of the point system in a later diary.)

In making the obstacles encountered in the game feel grounded in the real world, I thought about how I encounter and overcome issues in my own life. Most of the time in the real world, we manage to pass the “puzzles” that interrupt our “stories” by conversing with other “characters.” That is to say, if I need some paper to make some copies for my next class, I ask Satoko-san in the front office about extra paper and she gives it to me. The standard approach to dialogue puzzles in past adventure games has been to navigate a tree of options to find the right outcome. This can be effective, in practice, except that the starting point of the dialogue tree often betrays the challenge of the puzzle from the outset.

To demonstrate what I’m trying to say, let’s set up a fictional adventure game scenario. While investigating a murder in an upscale London hotel, you notice something glinting from behind a vent cover near where the body was found. Unfortunately, you didn’t bring along your trusty screwdriver. Stepping out in to the hall, you see a maintenance room. But the adventure game gods are aligned against you and the room is locked. Down in the lobby is a elderly janitor mopping the floor. You click on him to start a conversation (as you do with every NPC you come across in an adventure game, right?) and the dialogue options are:

• “Hi, I’m detective Grint Beefwell, and you are…”
• “Where were you last night around eight o’clock?”
• “What do you know about Doctor Hamfist, the man who was murdered last night”
• “Can you give me the keys to the maintenance room on the second floor?”

Instantly, right there, it’s like one of your puzzles has been solved for you. Without really thinking about how you were going to unlock that maintenance room, the answer has presented itself. In real life, you’d have to at least think, “Hey, a janitor, perhaps he could give me the key to that room” before asking him about it. But the game just assumes you’ve done that and, if you haven’t, just hands you the solution anyways. I wanted to make sure that the player has to do some of the reasoning on his own.

To this end, I’ve implemented three inventories for the player. One is the standard, tried-and-true, bottomless inventory that all adventure game characters seem to have. (Though in this game, you won’t be carrying around giant ladders in your pocket… probably…) The second inventory is your short-term memory. The player’s character has three slots in his short-term memory. What fills those slots is up to the player. Just about any object or character the player comes across can be added to the short-term memory and later overwritten by something else.

In our example above, our heroic dectective, in noticing the maintenance room, might think that it could be important in his hunt for a screwdriver. The player would then assign the maintenance room door to one of the short-term memory slots and continue on. Later, when he encounters the janitor, the player should think to himself that this guy might know something about getting me inside that room. The player can then initiate a conversation with the janitor and choose an entry from his short-term memory as a topic of conversation.

Player: “Excuse me, I saw a room up on the second floor marked maintenance.”
Janitor: “Yeah, what about it?”
Player: “I was wondering if you could give me the keys.”
Janitor: “I can’t just go handing out keys to rooms to any guy who asks! I’d lose my job. I’ve got cats to feed!”

The player can also use normal inventory items as conversation topics.

Player: “Perhaps this police detective’s badge might help convince you to give me those keys.”
Janitor: “Oh, I’m sorry. I didn’t realize… Here you go.”
Player: “Thanks.”
Janitor: “Say, you a real detective? Can you figure out who’s been stealing my newspaper every Wednesday?”

Of course the tried-and-true dialogue options are there too:

• Sure, let me give you my card.
• I’m busy, find some one who cares.
• Wednesday is coupon day, accuse the nearest old lady.

Using the short term memory inventory as a dialogue starter has opened up the game to lots of new interactions. The player will have to reason out who might be able to offer help with certain obstacles and then use the new short term memory inventory to communicate their queries. I find this a much more satisfying option than talking to every character you see until all dialogue options have been exhausted to solve each puzzle. It adds thought and real-world logic to the puzzle.

I mentioned above that there were three inventories. Along with the standard inventory and short term memory inventory is, not surprisingly, the long term memory inventory. This inventory is not limited in size like the short term memory, but the player cannot readily store information in it. Instead, the long term memory acts as kind of a journal of “the story so far.” Each major event, and some more minor events, will be added to the long term memory, allowing a player who may be coming back to the game after a break to receive a quick refresh on everything that’s happened. The long term memory will also contain memories of the character’s past and of events that took place before the game started, providing background and useful information. Like the other two inventories, the long term memory will also be used as dialogue starters and be involved in puzzles. Sometimes talking about past events with other characters can reveal useful information or dredge up other long-forgotten memories. Other times, talking about things that you’ve already done might result in hints about things that you have yet to do, acting as a well-integrated hint system.

The three inventory system has been almost fully implemented now, and I think it opens up some interesting new doors in terms of puzzles that don’t rely on leaps of logic or “try everything on everything else.” Hopefully, I can utilize these new tools to their full potential to make a fantastic adventure game.

That’s it for this diary entry. Next one in a month, and lots (note: probably not lots) of interesting blog postings between now and then. Enjoy this? Post a comment. Too wordy? Post a comment. Gotta pee? Post a comment.

Next time on RDD:

• Resonance Developer’s Diary #3: Ruminations and Spontaneous Combustions

This entry was posted on Monday, July 2nd, 2007 at 3:06 pm and is filed under Game Design, Resonance. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.