Previously on RDD:

• Resonance Developer’s Diary #6: Death, rewind, death, rewind

Ah, hello. I didn’t hear you come in.

Have a seat. It’s been a while. What’ve you been up to?

That’s nice.

Talk about Resonance? Sure! I’d love to!

It’s been a couple months since the last diary, so I figured I’d chime in with a brief update and then describe the process that goes into making one complete room, so that you can get an idea of why making an adventure game takes so gosh darn long!

Read on!

So where are we now?

Development continues at a pace appropriate for a game being developed in the spare time of four guys with other jobs, which is to say, slowly. However, the team and I continue to be impressed at the high quality of everything that is coming out of the pipeline.

Since the last diary, I took about six weeks off programming Resonance (but continued directing the team for the creation of art and music assets) while I donated some time to Erin Robinson‘s upcoming… eventually… game, Nanobots. The breather from Resonance’s code was quite useful, helping me inflate that motivation balloon that slowly deflates as you pour hour after hour into something. I also stole some code straight from Nanobots, specifically some ingenious code for camera motion and control, and brought that back into Resonance in a highly polished form. So, that was helpful!

After setting Nanobots aside again (at about 95% done!) when Erin got busy with her real life, I dove back into Resonance with renewed enthusiasm and we’ve been moving along at a pretty nice clip for the last couple months.

As far as percentages for Resonance go, it’s tough to estimate, since a ton of programming went into the gameplay systems (multiple inventories, swappable characters, unique dialog system, death/rewind system) before any real gameplay started being produced. I can say that the game is divided into three acts, with act one being, by far, the most complicated, and I can see the completion of act one in the distance, though there’s still a lot to do. Realistically, we’re still at least a year away from seeing a release.

What’s taking so long?

Good question! When you play an adventure game, it’s hard to really appreciate the amount of effort put into every little detail unless you’ve actually tried to make one yourself.

To give you an idea, one of the first rooms implemented in Resonance, will take the player around three minutes to finish. In fact, since it’s a timed challenge, you must finish it in three minutes! But it’s very fair, I assure you, since it’s the section that introduces the rewinding concept to the player, so you can play it over and over again. But this three-minute section of gameplay took around a month and a half to implement. Certainly, not all parts of the game are as complex and difficult to code as that room, but you get the idea.

So, let’s discuss the process that goes into making just one “room” of an adventure.

Design
Everything starts in the design phase, and aside from a few alterations and changes that I make once I start coding or testing, all the design is essentially done. In April of last year, I finished a gigantic document that describes every background, explains all the puzzles and gameplay, and gives an idea of all the characters, animations, and other art assets we’re going to need.

Background art
The real work pipeline for a certain room starts when I request the background art from the wonderful Nauris Krauze. I start a thread in our development message board that contains the description from the gigantic design document of the room and any other comments or instructions I might have for the background. Nauris then begins painting the piece and I’ll focus my energies elsewhere (another room, a gameplay system, Nanobots, etc.).

Nauris will soon post a rough work-in-progress version of the background, which I’ll give feedback and additional instructions about, and then he’ll refine and polish it until we eventually get the final background.

Characters and animation
I’ll also, at this point, begin requesting character animations and additional sprites from Shane Stevens. We have a thread for each major character and one big thread listing every animation needed with some semblance of prioritization. Sometimes animations need to wait until the background is done, since the animation might need to be lined up with certain parts of the background, like a character interacting with a lever on the wall or something.

And I’ve got to give some additional props to Shane here. I’m really demanding a lot from him. I’m really thankful that he’s approaching this game as a showcase of his skills, because he’s producing quantity and quality! Some games use cheap tricks to avoid having to make an animation, like fading out and fading back in, or just making the character make a vague generic gesture in the direction of something he’s interacting with. But here, we’ve got characters reaching out, grabbing objects on the background, sitting, standing, carrying things. It’s really impressive, and the extra effort is obvious.

Initial implementation and additional art
Once I have the background, I’ll lay that into the game engine and make it walkable. That is, I’ll draw little paths on the ground in the game editor to define where characters can and can’t walk in the room. Next, I’ll lay in any objects that will be in the room. These are the things that the player can interact with or sometimes just provide background animation.

Apart from coding and designing, I’m also doing some additional graphics and effects, and I like to get those out of the way first thing before I get too far into the room’s implementation. For example, in one room, you’re walking around the a shady urban street corner. In the background, you can see a train bridge between two buildings. In order to help the room come to life I made an animation of a train zipping across the bridge which now plays at random intervals during gameplay. In other rooms, I’m adding smoke, fire, electrical effects, or whatever the scene calls for that is outside the purview of Nauris, the painter, and Shane, the pixel-master.

Defining the interaction
So, once I’m satisfied that the room is looking good and feeling alive, it’s time to make all the define all the clickable items in the room. To do this, I need to tell the game where and what each item is. So, if I want a sink to be an item in the room, I have to go into the game editor and draw a shape around the sink to tell the game that it’s clickable. Each room has 15 to 20 interactable items.

Next, each interactable item in the game needs an icon. This is for the Short-Term Memory inventory. Remember, any item you see in the game, be it an important item like a safe or a character, or a useless item like a chair or some graffiti, can be placed by the player into the Short-Term Memory. So everything you can click on in the game needs a 20×20 icon. I also have to enter a name for each item so that it will appear in the inventory as well.

Adding a Short-Term Memory to an empty slot

Implementing the actions necessary for completing the scenario
Once I’ve done that, it’s time to add the interactions to those items. The first thing I do is go through and add all the things that solve the puzzles and correctly completes the scenario. Clicking on this accomplishes that. Using inventory object X on room item Y produces result Z. You get the picture. Basically, everything that would appear on a walkthrough of the game is done in this stage. Depending on the complexity of the puzzles, this can take a long time. This is, frankly, the most fun part of programming your game, because you get to quickly see the puzzles and game as a whole taking shape.

Implementing everything else
Unfortunately, it’s followed by the least fun thing: filling in all the things that happen when you do any thing else not required to solve the puzzle. This takes a long time, and a lot of freeware adventures (and some commercial adventures) skip this part all together, which I think is just lazy. How many times have you used an item on something that you thought would give an expected result only for it to return the dreaded “I can’t do that.” and give no further explanation? In the words of Locke (the bald guy on Lost, not the philosopher) “Don’t tell me what I can and cannot do!” Instead tell me why! In this long and boring part of game implementation, I go through and write what happens when you try to do anything other than those things that are required to solve the puzzles and complete the game.

There are three interactions for each item in the game: ‘Look,’ ‘Interact,’ and ‘Use inventory on.’ All of these need specific and useful results.

‘Look’ is pretty easy, so the first thing I do is to go through each object one by one and add code that makes the character face the item and then describe it. Sometimes these are clever remarks, sometimes they’re just dull descriptions. But here’s the rub! There are four playable characters! That means, I need to write four different descriptions of each item (unless it’s in a room where only some of the characters can access). I try to write four descriptions that are appropriate for each character, but sometimes you just can’t think of any new ways to describe a chair!

Next up is ‘Interact.’ Most items in the game, if you interact with them, nothing useful happens. You’ll get the character saying something like “Why would I do that?” But I don’t want you to just hear that a million times, so I’m not using any default messages for this. Again, each of the four characters will have a unique response to the player trying to interact with each item in the game. Again, it gets tough to think of four reasons why the player doesn’t need to use that toaster right now…

Also, where appropriate, I try to use animations instead of simple messages to show what the character is trying to do. For a real in-game example, in the street scene I mentioned earlier, when you click on the bus stop sign, instead of the character saying, “I don’t know what I’m going to do with a bus stop! Hurr hurr!” he walks up to it, grabs it, tries to pick it up, fails, and thinks to himself, “I’m not really sure what I was expecting there.” It’s a small touch that probably most players wont even see, but it shows that I’m trying to make the game more than just the characters refusing all of the player’s orders except for the ones that are right.

Finally, for ‘Use object on’ I do leave some of it up to default messages rather than writing up messages for each combination of item and inventory object, which would be a staggering number of results. Instead, I try to write results for the combinations that are most likely to be tried, and leave the rest up to default messages. Still, each inventory object has it’s own set of default messages, so it’s at least more descriptive than “I don’t think those two things go together.” So, if you use a rock on a window (something the player may be likely to try), the character will say that he doesn’t want to break the window, but if you use a rock on a bench (something the player is unlikely to try), you’ll get the default message for using a rock on something (“I’m not sure how a rock is going to do anything for me there.” or whatever).

At this point, the room should be mostly complete, but we’re not done with the endless writing of messages, oh no! Next we’ve got to deal with all your inventory items.

Any Long-Term memories, or Inventory items found in that room need some more interactions. Left-clicking on a LTM watches the memory, so I’ve got to make that. Right-clicking on a LTM gives a brief description of the memory, so I’ve got to write that as well. Left-clicking on an Inventory item results in the character ‘using’ the item, which sometimes results in just a message, like “I’m not sure how to use this coin right now” and sometimes has more interesting results for the more interactable inventory items. Right-clicking on an inventory object results in a description of the item.

Examining an inventory item

Ok, that wasn’t so hard. But now we’ve got the STM. Since you can add just about any object you see in any room to your Short-Term Memory, I’d guess we end up with somewhere in the neighborhood of 600 to 800 possible STMs. Each of those needs a description as well.

Character interactions
If you thought we were done, you were wrong! We’ve still got to cover interacting with the various characters that populate the game!

If there’s a character that you can talk to in the scene, then we’ve got to write all the dialog. And as another complication of the three-inventory system, we’ve got a lot to write!

First off there’s the basic dialog with the character. These are the smattering of conversation options that pop up right when you start talking. Just click one and a short conversation about that topic takes place. I try to write several of these for each character, often the conversation branches and loops, so that can make it quite a bit more complicated.

Next, one of the cool parts about Resonance, which I’ve discussed before in a Developer’s Diary, is that you can use inventory items as dialog options, as well. That means that you can talk to almost any character about any item in your Long-Term Memory, Short-Term Memory, and Inventory. The LTM and Inventory are fairly predictable because there are only so many LTM’s and Inventory items that will be obtained throughout the game. It’s still a lot, but it’s manageable. The STM on the other hand, is out of control. Like I said before, with somewhere in the neighborhood of 800 possible STM items, you can really talk about anything in the game! And I’m not going to write that many conversations!

So, again, I’m going to use a lot of default messages. I will write full responses for likely conversations, like talking to someone about a picture sitting on their desk, but if you try to talk to the chief of police about the microwave in your character’s apartment, you’re probably going to get this:

“Hey, I’ve got this microwave in my apartment that-”
“Is this important?”
“Err… no.”
“Then don’t bother me with it. I’m a busy man.”

So really, I just need to write that first line for each of the STMs and then one generic “Stop talking to me about useless stuff” bit for each character that you can talk to.

Testing
Once I’ve got all this stuff added in, I get to test the whole room over and over again until I’m satisfied that it’s working, and then it’s on to the final phase, music and sound!

Audio
During the whole time that I’ve been implementing all this stuff, I’ve been releasing incremental alphas to the team. Nikolas Sideris plays and brainstorms up what the room is going to sound like. He then provides me with sound effects for all the actions that need it, ambient noises if necessary, and finally, the music.

Often this needs to be done after the room is already complete, since he may want to perfectly time the music with certain events in the room and needs to wait until that timing is locked down.

Once the music and sounds are all implemented, the room is finally, finally, finally almostdone!

Final testing
Next, I release a final alpha of the room to the team, and maybe show it to a few trusted eyeballs outside the team for testing. Based on their feedback, the room will be tweaked and iteratively improved until it’s perfect. There’s a lot of love going into every pixel of this game!

And we’re done!
All in all, I’ve just walked you through what takes me, on average, two weeks of my spare time to do, not counting the art asset creation which is usually being done as I work on other parts of the game. Wasn’t that quite the roller coaster ride? We had ups, we had downs, we laughed, we cried, we pulled my hair out at the roots! I hope you now have a better understanding of why developing a game like Resonance takes a long time. I also hope you have a deeper appreciation for all those fantastic freeware and independent adventure makers out there!

Remember, if they’re making freeware, the only payment they get back is your feedback, so send your favorite freeware author an email today thanking them for their hard work! Or at least comment below!

Oh, and before you go, I’ve got a special media treat for everyone coming up later this week, so check back soon! Update! Here it is!

This entry was posted on Wednesday, April 2nd, 2008 at 4:29 pm and is filed under Game Design, Games General, Resonance. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.