A Hardy Developer's Journal – as written by indie adventure game developers

Interfaces are important.  I love interfaces.  Forming an intuitive and fluid language that is used by the player to communicate with the game, and a way for the game to communicate back is fun.  But adventure games, even the commercial titles, rarely get much interface love.  Games in the genre tend to stick to one of the commonly used control schemes. 

In the indie and amateur space, you see a lot of classic Sierra or Lucas Arts verb interfaces.  That’s because these come built-in to the most commonly used freeware engine and also because a lot of the hobbyist developers are at least partially aiming to satisfy their nostalgia by recreating the games of yore.

Commercial titles (though, I admit I haven’t been playing many as of late) tend to stick closer to the two button interact/examine or interact/walk system plus an inventory.  These interfaces are tried and tested.  Why mess with them?

Well, you don’t necessarily have to.  Experimentation with your game’s interface isn’t required.  Doing so runs the risk of turning out terrible (as well as the risk of turning out brilliant) and definitely isn’t necessary, especially for the hobbyist who is making a game out of nostalgia.  Hooray for the good old days!  But if you are looking to have a little fun and experiment a bit, creating a tailor-made interface can be fun for you and can result in a much better game.  I’m not even advocating creating a revolutionary new interface for the genre, here.  I’m just suggesting that you should let the gameplay you would like to have in your game decide the interface rather than the interface decide the gameplay.

That’s a difficult distinction to make, I think, especially when the adventure genre has been so set in its ways, with many players adverse to change.  Developers seem to design their games via a preconceived notion of how adventure gameplay works.  Thinking outside that box can be difficult.

Gameplay vs. Brainplay

Adventure games are not traditionally interface-centric games, at least not in the same sense that the more action-oriented games are.  Mental exercise time!  Think of a game and then think about where the actual gameplay is taking place.    (Warning: I’m about to talk in very general terms about genres of games, please forgive me the many exceptions!)

In a rhythm game, platformer, or shmup the challenge and fun comes from the player mastering the controls.  Most of the action takes place in the hands (or whatever part of your body is used to manipulate the controls).  The brain is involved, but only as a conduit.  It takes in the information the game feeds you via visual, auditory, or tactile stimuli (be it the rhythm of the music and the little colored circles traveling on a track in Rock Band, or the position and behavior of a goomba wandering across the screen in a Mario game) and quickly tells the hands (or whatever) how to react.  There’s usually little-to-no strategic or lateral thinking involved.  Your skill in the game primarily is measured in your mastery of the game’s interface. (Stop me if I’m using too many parentheticals.)

On the other end of the spectrum, in an adventure game, the primary challenge is figuring stuff out.  You take in as much information as you can — plot, characters, situation, surroundings, and available resources — and try to figure out what it is you should do to overcome the obstacles you face.  It’s a completely different type of brain processing than what takes place in the previous example.  No longer is the brain relaying messages as fast as possible while your fingers jump through hoops. The brain becomes the focus of the gameplay while your fingers chill until they’re needed. The challenge of an adventure game doesn’t come from mastering the interface, it comes from the mental gymnastics required to overcome the game’s challenges. (Ok, that’s the ideal situation… Often it just becomes “guess what the designer was thinking when he was looking for ways to stretch the play-time out.” But that’s a whole other article.)

The adventure game interface is present to allow the player to communicate the actions he wants to try to the on-screen avatar.  Entering in these commands should not be a complicated process that the player gets better at by practicing and mastering the controls.  It should be a simple process.  If the player knows what the character needs to do to progress, but doesn’t know how to get him to do it, the interface has failed.

To put it another way, when Mario sees a goomba, the player knows what to do.  It’s the action of doing it that is difficult.  But when the Guybrush Threepwood finds himself locked in a room with a shoelace, a basket of lemons, two dragon scales, and half an eggplant in his inventory, the player shouldn’t know immediately what to do, but once he has an idea, it should be easy to perform the tasks he intends to try.  Instead of requiring quick reflexes and nimble fingers to overcome, adventure game obstacles will require (ideally) observation, consideration, and lateral-thinking.

There’s a whole spectrum between interface-focused gameplay and brain-focused gameplay, obviously, probably with relatively few types of games residing precisely on the poles.  Real-time strategy games, for example, are somewhere near the middle, requiring strategic thinking to lead your troops (or whatever) into battle, and a strong mastery of the interface to simultaneously give commands to all your troops and efficiently direct their actions.  But in their traditional form, adventure games really do sit pretty firmly on the brain-focused side of things, with little fun or challenge being derived from the interface itself.

So why mess with the interface?

So, isn’t this an argument that the genre doesn’t need much attention given to the interface?  After all, it’s not an integral part of the gameplay.  On the contrary, I believe that this all reinforces the need for a finely-tuned interface — one specifically designed for your game.  It just requires a much different type of interface than the games on the other end of this spectrum.  An adventure game, ideally, should have an interface that allows for a complex set of commands, but does so as simply and intuitively as possible.

A game’s interface, in any genre, is a great thing to toy around with, especially an adventure game where so much of the game is heavily scripted.  By which I mean that each action in an adventure is given a specially programmed and unique result, rather than just programming, say, one unified platforming system and using that throughout a game, allowing you to tweak gravity or running speed to fine-tune gameplay. An adventure game’s interface can be tweaked, tested, and incremented before you start designing puzzles that make use of it.  It’s much harder to take an incremental approach to the development of the plot’s progression or to the puzzle design, making the interface ideal for experimentation and innovation.

In addition, it’s easy to picture an adventure game’s interface as a spoken language since the commands the player gives are more similar to verbal commands.  Verb-object commands such as “Use Sink,” “Talk to Bill,” or “Use cheese on mousetrap” work great in English, whereas complex commands involving timing and holding down a button for a specific duration like you might use in a platformer do not.  This is a very easy way to begin building your interface: defining the language and commands that need to be used by the player in the game in plain English, and then devising an interface to facilitate them.

Consider what kinds of gameplay you want in the game, consider the commands required to support that gameplay, and come up with interface solutions for those commands.  Doing so will give you an interface tailor-made to the type of gameplay that you want to support!  If the interface is not custom-designed to accommodate the gameplay you want in the game, you will instead be shoe-horning all the gameplay into whatever interface you wound up settling for.  Don’t let your interface limit the rest of the game!  Mold the interface to fit your ambitions!

The necessity of an easy-to-use interface

Before you get carried away with your nutty interface, though, remember that the ideal adventure game interface needs to be simple and fast to use to facilitate easy communication from the player to the game.  There is a tradeoff between adding many new and/or complex commands to your interface and the ease with which you’ll be able to deliver them.

Again, an adventure game’s gameplay takes place in the brain, not in the interface.  We need to make the interface be as easy and fast to use as possible.  In general, the less time it takes your hand to translate your brain’s decisions into commands that the game can understand, the better.

I tend to like interfaces that only require one click per action and get easily annoyed at games where I have to click once on a verb and once on an object (or the other way around) in order to give a command.  Especially if the verb GUI’s position is far removed from the objects I’m interacting with.  For this reason, I prefer verb-coins (Full Throttle) to top-of-the-screen (Kings Quest) or bottom-of-the-screen (Maniac Mansion) verb-banks. I also find cycling through multiple verbs with the mouse button to be frustrating (practically every AGS game) though usually better than the verb banks that usually accompany it.  So, my personal tendency is to keep everything to either the left mouse button or right mouse button without any intervening verb GUIs or multiple clicks to cycle commands.  Again, that’s a personal preference.  If you disagree, let’s hear it in the comments! And there has to be a better way to implement a verb-bank interface than the ones created twenty to thirty years ago.

I know that I said the intended gameplay should dictate the interface, not the other way around, but I don’t think limiting the gameplay to two mouse buttons would be limiting the gameplay in most adventure games.

Now hold on there, Vince, there’s no way to have three, five, or eight verbs with just two buttons and no extra GUIs, so you’re limiting it right there!

I disagree.

Let’s think about the game Spooks for a second.  I did all the programming and provided some advice or suggestions to Erin on the gameplay, so I get to pick it apart a bit, right?  Spooks used the traditional Sierra interface: A verb-GUI would appear if you moved the mouse to the top of the screen containing the verbs “Walk,” “Use,” “Examine,” and “Talk.”  We could remove the “Walk” verb by making a click on any non-interactable part of the screen into a walk command, so we’re down to three verbs to shoe horn into two mouse buttons.

So, think about “Use” and “Talk.”  You could use “Talk” on any character in the game to start a conversation.  And “Use” would allow you to pickup or interact with any object in the game (or result in some clever “I don’t need that” one-liner).  However, if you used the “Use” verb on any character, you would always get an “I can’t go around feeling people up” message, whereas using “Talk” on any object would always result in an “I don’t think an inanimate object is going to respond” message.  So, the set of objects that produce a meaningful result when using the “Talk” verb does not overlap the set of objects that produce a meaningful result when using the “Use” verb.

Pardon me while I whip this Venn diagram out:

That’s what Spooks looks like.  A more compelling use of the interface would have looked like this:

Since there’s no challenge to figuring out whether you should “Talk” to something or “Use” it (Does it have a mouth? “Talk.” Otherwise: “Use.”) and there’s no puzzle that requires the distinction, I would argue that the game would have been improved by combining “Talk” and “Use” into one “Interact” verb.

We could then have made the game a two-button no-verb-interface game. No more mousing to the top of the screen to pick a verb before mousing back down to click on an object. Think of all the mouse mileage you would have saved! And think of how little (i.e. not at all) it would have impacted the challenge and fun of the game!

Just to clarify, I love Spooks and think Erin wrote an amazing game, but long after we finished it, I realized that the game was using the Sierra interface because that’s what was pre-built into the game’s engine and not because it brought any value to the game.

Similarly, most games built using the Lucas Arts interface, which has even more verbs, looks like this:

Again, the extra verbs seem redundant and could be condensed down to two with little-to-no sacrificing of any puzzles, but greatly reducing communication time and interface-related frustrations.

Of course, this is reflecting a flaw in the game design, not inherently in the interface.  Either of these interfaces can be fully utilized with the right design choices.  If you’re going to have all those verbs, justify them by making it a challenge to figure out which verb to use.  And make certain objects have meaningful results for more than one verb.  I think that this too rarely happens and it automatically turns me off when I see a game using a multi-verb interface.

Again, the ideal interface for an adventure game is simple and fast, so if you’re going to add extra commands or complicate the interface in any way, make sure that the game justifies the complications by fully utilizing the interface’s potential.  On the other hand, the ideal interface allows for complex commands to be delivered from the player to the game.  There is a tradeoff between a complex vocabulary of available commands and a simple and easy-to-use interface.  Finding the way to balance both is the key.

***

End of Part 1 of 2

***

Next time on: This Article

Hopefully this article has inspired an adventure hobbyist to break free of the bonds of the built-in interface and try something new and fun.  I hope you’ll excuse the sometimes quite sweeping generalities that I employed.  (Feel free to take me to task for them in the comments.)  There are no real hard rules regarding how to go about all this while designing your game’s interface, so I’m just aiming to introduce you to some things you may not have thought about.  The second half of the article walks through how I applied this line of thinking to the design of the interface for my game-in-progress, Resonance.  Check back soon!

Go to Part 2

About The Author

Vince Twelve is the creator of the award-winning Anna and What Linus Bruckman Sees When His Eyes Are Closed. He is also the programmer behind the award-winning Erin Robinson games: Spooks and Nanobots. Right now he is developing his first time commercial effort – the innovative Resonance.

Related articles

• Adventures in Interfacing Part II: Interfacing the Adventure
• +j+ When cute little things are mean to each other \v/ … – INTERVIEW with Erin Robinson
• Visually Directing the Player
• Design Taught in Pitfalls #4: When do I Stop?
• Design Taught in Pitfalls #3: The Long Haul