WYGIB: Part Two! The Sierra Operating System

[Vince Twelve]

Snarky, that was an excellent and well argued post!  Thank you!  As I mentioned at the start of the first article, I'm no HCI expert, only having worked along side several for nine months.  I really appreciate someone with the proper training coming in here to set me straight on some points.

With the operating system, I was trying to demonstrate how annoying I feel the interfaces are by placing them out of the context of games.  I wanted to do this because of the nostalgia-tinted glasses that I mentioned.  However, you are exactly correct.  The usability concerns that apply to a computer, which aim to simplify tasks, do not apply to games, where tasks should be more complex.

The usual joke is that the optimal usability solution for any computer game is a button marked "WIN".

So, so true!  I'm considering adding one of those to Resonance!

As I said, I do think that the annoyance that I feel when I play most games with these interfaces takes a back seat to the second issue about misuse, where the OS example still applies.  I've mentioned up thread, but need to make it clearer in the article, that this issue is primarily due to the developer's misuse, which apart from many of the classic Lucas/Sierra games and a handful of amateur games is extremely widespread.  The annoyance issue is subjective and the OS example doesn't apply very well for the reasons you mentioned.  But I maintain that if your game doesn't have some instances where the usage of "Talk" and "Use" are some how shuffled up, diverting from the norm, then the verbs are redundant and should be combined.  This goes for the Lucas interface as well.

I think the OS comparison does apply, if only loosely, here.  The example where I combine all the fake Resonance documents/video/music, into one master file and then use the verbs on that instead of having each of the files separate demonstrates a way to use the interface's potential in a way that your commands have more meaning without being redundant.  Doing otherwise isn't complicating the interface in the interest of creating gameplay.  To me, that's squandering the potential of your interface.

I'm mainly saying that if you're not going to take the special attributes of your chosen interface into consideration when designing your game and your game comes out resembling one of my worst-case Venn diagrams, you would be better off with a less obtrusive GUI which wouldn't sacrifice gameplay at all.  Ok, maybe it would sacrifice some illusion of gameplay, but fake gameplay made up of unnecessary clicking isn't what attracts me to the genre.

And, yeah, the article is made up of a lot of exaggerations and too-strong statements (none of these games are actually "broken") to try and get the point across and spur some discussion.  I know there are some games who use these interfaces to great effect, especially the old classics around which the interfaces were designed.  I mainly want to make sure amateur devs like me are keeping in mind the full potential of their chosen interface when they design their game.

I'm definitely going to use some of these points in the rewrite before posting the final article to the blog.  Thanks a bunch!  Looking forward to hearing what's so great about the interfaces!  (D'oh!  You posted it while I was writing this.  Reading now, post back in a bit)  Edit: Actually, I'll post back tomorrow.  It's way late.  But it's another great post! Thanks!

[blueskirt]

I see your point, but if you're changing the game to fit the UI, you're doing it wrong. The UI must be designed to fit the game, and not vice versa.

My bad, I had trouble finding the right words for that sentence, I thought these would works but obviously it came out all wrong. What I meant to say was: we should encourage people to take the high road rather than the low one, to come up with insightful/funny messages that add to the experience, rather than avoid the problem entirely with a 2 buttons interface. While a 2 buttons interface at full potential is better than any UI that isn't used to its full potential, a LucasArts/Sierra UI at full potential is better than a 2 buttons interface at full potential IMO.

Vince: I was kind of tired of all those game articles that focused exclusively on storyline, narration, story structure and characters development. It's good to see articles that kick the adventure gameplay design in a direction which test our positions and open our eyes to the flaw of today's games. May we be 2 buttons UI proponents or multiple verbs UI proponents, it is quite true that a lot of indie adventure games don't bother to use the Sierra/LucasArts GUIs to their full potential. I hope you will keep kicking the adventure game gameplay design in new directions, maybe touching the subject of puzzles, death or the importance of breaking new walls in term of gameplay.

[Shane 'ProgZmax' Stevens]

The trend in graphic adventures since then has been towards simplicity of UI, probably for the better, but we still need to maintain the balance inherent in the fact that adventure games still are about trying to figure out what you can do.

I completely agree with this, which is why I'm not particularly fond of over-simplified interfaces.

[Snarky]

Thanks for your reply, Vince. Although I'm fond of the LucasArts UI, and think that it was a great solution for its time and a respectable one for amateur games today, I definitely don't think it's above criticism. You're doing a great job of that, and I'm glad the discussion is spilling over into larger issues. As for the Sierra interface, I'm not a huge fan of the right-click-to-cycle-through-cursor-modes principle, but it does get the job done quite efficiently (as long as the number of modes is limited; the Gabriel Knight UI was almost a joke). The standard Sierra inventory system is horrendous, however.

I should point out that although it means I'm aware of some of the issues of interface design, an HCI degree doesn't make me an expert. I've never examined these UIs the way a professional would, and as I mentioned, I'm working in a pretty different area of HCI. So I'm just commenting as an interested amateur with an opinion.

To return to the point I was making about inefficient interfaces, I'm just playing Apollo Justice on the DS. It has all sorts of mini games where you have to perform simple tasks (dust for fingerprints, make molds of footprints, use an X-ray machine) in incredibly inefficient ways. The whole point is that it's fun to use the touch screen and see the effects on the screen. Too few adventure games take any joy in the interactions themselves. Some text games play with language, and you have stuff like the magic cursor in Discworld and the "story told through sentence bar" in the fight in the mansion in Monkey Island.

But recently, outside of the DS and other Nintendo platforms, I can pretty much only think of Fahrenheit and a certain Linus Bruckman. That's a shame. I think the Wii has proven that fun interactions are the keystone of fun gameplay. Maybe we're all too jaded about PCs to have much fun with simply a mouse or keyboard, but I hope not.

Edit: I got a bit off topic there and managed to distract myself from some of the points I was going to make.

1) I think the two-button UI is pretty good (it elegantly supports four actions--"walk to", "look at", "action", and "use X on"--with only two buttons, without complicated click patterns, verb-coin gestures or sub-menus) for what it does, but one problem it has is lack of affordance. There is no visual indication of how it works. You could watch someone play it and have no idea how they're making it happen. You pretty much have to read the manual, or figure it out by trial and failure. This is one area where the LucasArts and (to a lesser extent) Sierra UIs have the upper hand. I seem to remember that there was a Star Wars fan game that tried to use little legends on a crosshair cursor to indicate the leftclick/righclick actions, but the meaning of the labels was pretty non-obvious, at least to me.

2) I wanted to single out Reactor 09 as an AGS game that created an extremely slick, original UI (a version of context-sensitive pop-up verb-menus, as I recall it). However, even in that game I think there were one or two occasions (near the end) where the UI screwed with the gameplay. That's the risk you take when you try to innovate.

[cat]

There are many interesting point mentioned which I was thinking about a lot in the past few days.
First I thought "He is right, actually only look/interact is needed."
But then I started to think about this whole stuff and some issues appeared to me.

1) Accessability
First of all not all people have a right mouse button. A friend once played Monkey Island on his mobile phone in scummVM just with his pen input device -> no right click.
Also on some notebooks with touchpads doing a rightclick is a pain in the ***.

2) Inventory:
For example the BASS inventory gui was driving me crazy. It just didn't work for me. Additionally it limits the actions that could be performed. A torch for example could be switched on but it could also be handed to another person.

3) Limited possiblities:
Usually there are more ways to interact with an item. You could, for example sit down on a chair, but you could also push it somewhere and stand on it to reach something or you can use it to block a door.
It has happened in adventure games that I had a certain idea how I could solve a puzzle and when I tried to interact with the needed object something completely different happened. It's some sort of "well, I managed to solve the puzzle, but I wanted to do it totally differently" which I think is very bad for immersion.

Also, having a contextual verb coin would work here well.  A contextual verb coin doesn't have "Talk" "Look" "Use" on it, it has a different set of commands for each object you click on.  So, a potted plant might have "Look" "Break off a leaf"  "Push to the left"  "Push to the right" "Hide behind".  Not all of those would be needed in the game, but adding them can add that complexity and sense that you still have to figure out what you're going to do with it yourself.  And it's a choice that requires more thought than "Hmm... should I use 'Use' or 'Talk' on this plant... Duh."

As far as i remember, in Bernhard's Room you have to talk to a plant

However, the contextual verb coin could be a good idea. I usually don't like verbcoins because they increase time needed to do a certain action, but in this case this could work out very well. However, I think this is very hard to implement properly. If you could (let's take the chair example) move, sitdown and pickup the chair, every chosen option should do something. If you have the option "sit down" and then you get the response "I don't want to sit down" this is quite useless. The more options there are, the more implementation (animations, coding,...) is needed which will result in huge workload.

So actually I don't know what the best solution is, every GUI has its advantages and disadvantages...

[Vince Twelve]

Gwargle, I'm always on my way to bed... no time to post today.  Just wanted to say that I also get really annoyed at verb-coins that you have to hold and wait for.  Usually when a game uses one of these, I can't figure out how to play the game, clicking around with no success until I finally read the manual and realize that I need to hold the button down for a while.

Definitely left or right click to bring up a verb coin seems like the way to go to me.  I've never made a game with a verb coin (En Passant never got off the ground...) but I definitely don't think making the player click and hold for a second before each action is the best way to go.  I'd have to experiment with it.

[miguel]

Hi to all,
great topic start and very good opinions.
On my recent project (Blue Moon) I decided to make my own interface and came with something not original but functional, I hope!
Rui Trovatore Pires gave me some lessons on interface design and as I was improving the Blue Moon Demo he kept directing me on the best way.
It consists on a constant GUI placed on centre bottom of the screen that shows the name of whatever the mouse is over,
then,  If you Right-Click it pops a verb GUI, with some level of transparency, on top of the object that consists on some icons :     
                                      - examine
                                      - use
                                      - inventory (allowing you to use an item with the current object)
if a person is the object then a TALK icon will be present;
Right-clicking or moving EGO will turn the verb GUI off.
I've seen it on other games and think it is much more functional than the standart interfaces for the reasons everybody named before.
What do you think of it?

[Fyntax]

The trend in graphic adventures since then has been towards simplicity of UI, probably for the better, but we still need to maintain the balance inherent in the fact that adventure games still are about trying to figure out what you can do.

I completely agree with this, which is why I'm not particularly fond of over-simplified interfaces.

I HATE over simplified interfaces,

hate

hate

hate

hate

An interface such as in the new sam & max games is horrible, there if anywere is a perfect example of a broken game.

[Babar]

Yeah, I was playing one of the Sam & Max episodes recently, and it's very weird...it seems to be just a 1 button system? If there is nothing there, you walk to, if you tap twice, you run, if there is something there not interactable you get a comment, if it is interactable you either do something, or pick it up. Right-click only seemed to be there to skip text.

Also...I am just wondering, is it a problem that some GUIs may cover part of the screen? Sure, I got a little peeved at the end of one of the Monkey Islands when they started showing the backgrounds without the GUI, and I realised that the GUI actually hid some of the artwork, but if it is designed properly, would it be a problem? For example, if your game utilised the the entire screen of your...1024x768 resolution. But then, you magically got a 1024x808 resolution, where the extra pixels would be used to show a GUI. Or is it a matter of the GUI being 'intrusive' on the gameworld experience?

Another thing...since inventory being easily accessible is important, and things not covering the screen is also important, would the the pop-up inventory system (like in BASS) be one of the best current ones? Someone here mentioned they didn't like it. One of the Trilby games used an inventory GUI where when you clicked on something with one of the buttons, the inventory popped up, and you could use that. I wasn't too fond of that, because it covered what you were doing, seemed to cause extra clicks and inventory handling (like looking at it, mixing it, using it, etc) didn't seem to be handled well.

[DanielH]

Personally, I like the Broken sword UI. Left click: Walk/Interact, Right Click: Examine. Inventory at the top of the screen for easy acsess, with no pop-up windows or verb coins to break immersion. Over-simplified? Perhaps, but I think the biggest puzzle in an adventure game shouldn't be the interface.

[zabnat]

For me the best GUI has been that of CMI. It was essentially a extension of my spinal cord. Not because of the verb coin, it didn't pop up even once when I last played it, but the way I played. Having fingers on T and U I essentially had four mouse with a different cursor mouse on each button. I too hate oversimplified interfaces. And I wouldn't want to play the game with just a Win button (well, MI had the win button).

[Electroshokker]

Well, this is certainly a most interesting post.

What I learn from this is:

- design your gui to match your game complexity:

*) if you're only going to script one or two actions per hotspot, don't bother creating 8 buttons with lots of different options

*) if you've got a very complex game where almost any type of interaction actually does something (even if it is just to give a funny comment that makes the player laugh out loud), you might consider having a few more buttons

- Inventory visibility should match how often it's used.

put your inventory on screen if you're using it most of the time, hide it (but make it accessible enough) if you're only going to use it relatively sparse

- allow for multiple types interaction with a gui control

don't be the guy to create only one type of interface and then FORCE the player to use this and only this way to do stuff. Allow the player to choose from a (limited) variety of types:

*) the simplest being able to switch the left- and right- mouse button functions
*) the ability to use keyboard shortcuts
*) the ability to play the game with ONLY your left mouse button (I mean: laptops, PDA's, ... not everyone HAS 2 mouse buttons and a mouse wheel, you know)

- Use the LOOK function properly if you've got it!

Don't just state the obvious, give the player EXTRA information, as that's what it's for.

------------------------------------------------------------

I, for one, found this article and resulting comments very refreshing. It inspires me to improve my own game even more and check and double check so that there are no "you can't do that" or other blatant annoyances in it.

Though I'm more of a "let's give the player all kinds of options and make sure he WANTS to try out ALL of them" kind of guy, I'll probably give gui design some more thought next time around.

If I find the time I'll most certainly rework my current verbcoin module and game template to incorporate these lessons in the extend it's possible. (after all, it's still the choice of the game creator to use or not use any and all functions)

(And if I find a LOAD of free time I'll work on creating other templates which also include these lessons but for different gui types)

[DoorKnobHandle]

Electroshokker, you're right on everything you mentioned except that I think it's actually very safe to use two mouse-buttons in a game. You name laptops and PDA's as examples for environments with only one button but both those devices have two mouse-buttons as well and have had them since decades. So, allowing the player to play your game with one button only and not using them both would actually worsen your design because of over-thinking and -reaction.

[Electroshokker]

Electroshokker, you're right on everything you mentioned except that I think it's actually very safe to use two mouse-buttons in a game. You name laptops and PDA's as examples for environments with only one button but both those devices have two mouse-buttons as well and have had them since decades. So, allowing the player to play your game with one button only and not using them both would actually worsen your design because of over-thinking and -reaction.

ah, but my main point is to allow the player to choose the way he interacts with the game.

In those rare cases a player finds himself with only 1 button (like on Mac OS X), the player should be allow to choose the "one button"-mode rather then the default two-button mode.

By allowing customization of the way the interface responds (rather then changing the interface alltogether), the player will feel far less restricted and will always choose the way he/she thinks works best, thus giving a better gaming experience.


Consider this: most modern games all have a default profile defined for keyboard and mouse interaction, but they also allow the player to customize these.

My idea is to do the same for adventure games, but instead of full customization (except maybe for keyboard shortcuts), the player would be presented with a select amount of choices at the start of the game.

(Preferably the game remembers these settings for next time round, it would be very annoying to have to select the default/left/right mouse/keyboard/... mode every time.)

Example, the verbcoin system:

- default mode (left click pops up the verbcoin, release over the action of choice, right click deselects)
- switch right-left mode (right click pops up the verbcoin, release over the action of choice, left click deselects)
- loose click mode (left click on something pops up the verbcoin, leaves it there, click again to choose your option, right click deselects)
-...

Important is not to allow too many different modes, because that too would confuse the player.

In my case, I'd let the player make only two choices to keep things simple:

mouse or mouse+keyboard
2-button mouse or 1-button mouse

(note: the switch left-to-right mode would be invaluable to left-handed people, I'd think. We musn't forget these. Though I'm sure the OS already allows for these to be switched, which is why I wouldn't include it)

[DoorKnobHandle]

Even on Mac OS you can right-click.

I absolutely agree with everything you say, but I just think designing your UI with people who have only one mouse-button in mind is a little over the top.

[SSH]

I think a very configurable interface allows people who are disabled to access it: the more configurable, the easier it is for people to work around disabilities. For example, some people have no arm movement but can use mouse pointers via head and eye trackers. For them, they "click" by hovering in the same place, and some of the interfaces describes would make the use of these aids impossible or hard.

bicilotti also found a problem with his colour-based problems in Colorwise recently and worked around it. Purely sound-based puzzles are also exluding some players.

[DoorKnobHandle]

It's certainly a very honorable idea to give every person with every possible preference or disability a chance to enjoy the game equally, but it's just not realistic. At least not for all games or projects.

Also, if you had created a freely configurable interface that allows every armless, blind or deaf person to play the game, shouldn't you also be extra careful not to have a love-interest in game because homosexuals might be offended or, for that matter, exclude any kind of joke that could offend for example a person with a certain disability?

Once your train of thought starts heading into this direction, it ain't coming back so quick, it leads ad absurdum in a split-second.

[bicilotti]

It's certainly a very honorable idea to give every person with every possible preference or disability a chance to enjoy the game equally, but it's just not realistic. At least not for all games or projects.

Also, if you had created a freely configurable interface that allows every armless, blind or deaf person to play the game, shouldn't you also be extra careful not to have a love-interest in game because homosexuals might be offended or, for that matter, exclude any kind of joke that could offend for example a person with a certain disability?

Once your train of thought starts heading into this direction, it ain't coming back so quick, it leads ad absurdum in a split-second.

I think the point of SSH was that with a little effort on the developers part we can let people with disabilities play our games. It's not a crusade, just two or three ideas that can make the difference for some of us.

SSH had an interesting post on the subject in his blog (post that right now I am unable to find, gahhhh!)

[SSH]

I was merely saying that the more people you can enable, the better. I find it offensive to try and turn it into a "It's political correctness gone maaaaad" which in this country usually comes from the Daily Mail-reading reactionary bigot.

[Shane 'ProgZmax' Stevens]

Especially with free games, I can't really be bothered to implement a 'works for all, but is rather boring' interface because I'm receiving no compensation for it, and no matter how much effort you put forth people still manage to find something to complain about.  I think games work best when they have a specific audience in mind rather than generic attempts to reach out to everyone, anyway.