• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
jwezorek

Does the interface of every graphic adventure game suck?

16 posts in this topic

Do any graphics-based adventure games have an interface as rich as the pseudo natural language interface common to Infocom's games from the 1980s?
 
If not what would such a game be like?
 
... and for the purposes of keeping this question specific enough to be answerable without answers devolving into lists of games from the last couple of decades that are good, let's define "graphics-based adventure games" conservatively as the sort of direct descendants of the adventure games of the 1980s; i.e., I am not considering Assassin's Creed to be an adventure game or even L.A. Noire. However, if someone really objects to this definition then answer away and explain why I am wrong to frame the question like this.
 
Voice/speech-to-text would be an obvious thing to do, but part of me feels like it would be a cop out.
 
What I am looking for is an interface that is purely graphical but still allows puzzles deeper than the essentially verb-noun type puzzles that SCUMM type games allow. Basically, to me the SCUMM/Lucas Arts games like Monkey Island and so forth are kind of the visual equivalent of Scott Adams games or are like visually richer and 3rd person Sierra Online games, sort of 3rd person Wizard and the Princess. 
 
What I want to figure out is what the visual equivalent of Zork II would be like, or The Hitchhiker's Guide to the Galaxy. In Zork II, say, you have a puzzle where you slide a place mat under a door, insert a letter opener into a keyhole, pull the place mat back revealing that it now has a key on it, and open the door with the key. I don't see how you could represent a puzzle like that in a Maniac Mansion style game, so I am trying to come up with a 3rd person style graphics adventure game in which you could -- but maybe it isn't possible.
 
Edited by jwezorek
1

Share this post


Link to post
Share on other sites

I don't remember any of the infocom games that weren't text only.  I always hated text based interfaces.

 

If you're looking for modern take on the classic sierra and lucas arts age adventure games I recommend taking a look at the the Telltale games.

0

Share this post


Link to post
Share on other sites

Hmm... I don't think that I've encountered one with that degree of complexity, no.

 

I think that the closest that I recall was the interface used by Gabriel Knight 3: clicking on an object brought up a small menu of icons representing the available actions for that object, and specific to that object. While some were common--such as "examine"--there were also actions that appeared only a few times. For example, when clicking on a tray of food, one might be given icons for "examine", "eat" and "smell"; a book might have "examine", "take", "read" and "dust for fingerprints" (it was an investigative mystery). The actions available could also be context-sensitive, such as a dumb-waiter door offering "open" when closed and "close" when open. (I think that there were cases in which more options were available, but alas seem to be blanking on an actual example.)

 

While lacking the explorative element of text-parsers--you don't get to guess what verbs are available--it at least lacks the blindness of such parsers--you don't have to guess which verbs are available--and does at least allow for a variety of context-sensitive actions.

 

[edit] I've been ninja'd on the "verb-menu" idea, it seems; one thing perhaps worth noting is that I've been involved in an argument over whether radial menus were a good idea for such a menu; I think that in the end I conceded that radial menus probably wouldn't work well outside of first-person cases, in which the object sits at and the menu appears in the centre of the screen.

Edited by Thaumaturge
2

Share this post


Link to post
Share on other sites

I think part of the problem, as they say, is that a picture is worth a thousand words. In the old text-only adventure games the descriptions could be very rich but it was also very clear what the nouns were. In an image-based adventure game, literally every distinct thing on the screen is a potential noun, and that obscures which nouns are actually viable or interesting, which kind of gave rise to the sweep technique where you revert to sweeping the entire screen with the cursor when you're stuck on a puzzle. I don't know if its reasonable to implement a natural-language-like interface in an image-based adventure game, but there's certainly room for innovation.

 

If you want an example games with somewhat different takes on the genre interface, check out the more recent installations of Broken Sword from The Adventure Company, or Shadowgate 64 for a (admittedly, probably poor) example of a fully-3D, first-person adventure game.

Edited by Ravyne
2

Share this post


Link to post
Share on other sites

Other than the Myst series, Sanitarium is the best graphical adventure game I ever played.  The Longest Journey is very good too.  But if you're looking for a linguistic interface in modern adventure games you're not going to find one - there was pretty widespread agreement that they were sucky and immersion-breaking.  The closest you will find is a dialogue system like that in The Longest Journey or that in the Persona series (not adventure games).

1

Share this post


Link to post
Share on other sites

Some thoughts... (and a description of the Infocom interface for younger readers)

 

I've been thinking about this for a couple of days and I think the key thing that you would have to do to make a graphical game like this would be get rid of all the guessing. In a graphical game what can be done needs to be explicit.

 

When you strip away the hype of natural language processing, the Infocom interface was basically the following:

 

  1. Nouns were marked by the game. (You enter a room once and get the elaborate description, you then start getting the abbreviated description which was a list of the nouns in the room, some of which you could take and some of which were fixed to the room, but all could serve as objects in commands while in the room)
  2. There was a list of common verbs that you knew you could use: get, move, pull, push, insert, give, tie, untie, open, close, cut, destroy, burn and a few more. This list was augmented by a few unknown verbs that were game dependent.
  3. The verbs in 2. could take direct objects as well as indirect objects where applicable. Indirect objects could be entered either as proper indirect objects or via a prepositional phrase e.g. "Give the Chistmas tree monster the coconut" or "Give the coconut to the Christmas tree monster" respectively.
  4. Prepositional phrases worked for modifying some objects if, I think, the object exposed a property for a slot associated with the preposition -- I'm guessing this is how it worked internally anyway; for example in The Hitchhiker's Guide to Galaxy pretty much the whole solution to the Babel Fish puzzle involved prepositional phrases and the object model they induced "Hang dressing gown on hook (so the "hook" has an "on" slot). Cover grating with towel (the grating also has an "on" slot which <cover> <with> knows to map to). Place satchel near door. Place junk mail on satchel. 
  5. There were places in which you could issue commands in the same form to other agents e.g. "Robot, give the coconut to the Christmas tree monster" 

On 1. and 2, I would definitely consider any guessing of words required to be a negative thing. It was mitigated by the fact that after you played a few of these games you pretty much knew which verbs you could expect and relying on the need for a magical verb to solve a puzzle was considered bad form (although it happened. the life raft in Zork I was like this: you had to guess that a pile of plastic was "inflate"-able)

 

so 1. you could do in graphics in some way. 2. you could also do by way of limiting the list to very few and having some kind of uniform mechanism for engaging one of them -- something that isn't a menu though, I find the menus I've seen ugly, but also more that just an "action" button. Don't know exactly how I will do it but this seems solvable.

 

It's 3. and 4. where there really seems to be room for innovation. I think that there would need to be a visual language for the slots bound to objects that I am assuming exist invisibly to the user in infocom games. In infocom games you had to guess what you could do to and with an object. In the interface I am envisioning I think you would need to make what you can do to an object explicite via some mechanism.

 

(and 5. couldn't be done without text ... although in a 3rd person game essentially your avatar is just a special object you are interacting with that follows the commands you are entering in some way so in theory you could have more than one)

Edited by jwezorek
1

Share this post


Link to post
Share on other sites

I could be wrong and misunderstanding this part of what you said.

 


(and 5. couldn't be done without text ... although in a 3rd person game essentially your avatar is just a special object you are interacting with that follows the commands you are entering in some way so in theory you could have more than one)

 

You can do #5 with a swap character button, or menu.

 

Have you investigated context sensitive buttons? That is what I've come to believe is expected in pretty much any graphics interface.

 

Argument: Innovation for any one button press is limited by an unwritten law, which I believe it's common knowledge "easiest implementation of an equal action wins."

Logic: Using language, language has become a huge chasm for a player to leap over, and they'd have to say or type "jump the chasm" while running at it. Using context sensitive buttons, pressing 'A' can get your player over this chasm. In a competition head-to-head, or just by saving time, the player supporting context sensitive buttons wins.

 

I have the feeling this is some form of nostalgia fuel.

0

Share this post


Link to post
Share on other sites

I might be missing something here, but SCUMM had commands with multiple object "slots" as well -- give always had two slots, use usually had two slots but it depended on what was chosen as the first object, and I think possibly some others could (like "push" maybe) when context demanded it.  You would know because a preposition would appear after the first object was chosen, indicating you had to choose another object in order to complete the command.

 

These were used for the same things as the Infocom multi-object and prepositional commands.  "Hang the dressing gown on the hook" and "cover the grate with the towel" aren't functionally different than "use the dressing gown on the hook" and "use the towel on the grating".  "Use" is less specific, but there are few puzzles where there would be genuinely different and non-erroneous ways to use X on Y where the verbal distinction would be important.  (For example, "use towel on grating" might also be interpretable as "clean the grating with the towel", but if one of those is a correct action and the other is a red herring, the game isn't improved by being able to make this distinction.)

 

This system could be straightforwardly extended to the vocatives (your #5); you would have just needed to have a "tell" command: choose "tell", choose the object (the addressee), "to" appears, choose another verb, choose the objects associated with that verb.  (Not that I can think of anything particularly interesting to do with this that couldn't be done by switching to that character, as ActiveUnique suggested.)

 

What I want to figure out is what the visual equivalent of Zork II would be like, or The Hitchhiker's Guide to the Galaxy. In Zork II, say, you have a puzzle where you slide a place mat under a door, insert a letter opener into a keyhole, pull the place mat back revealing that it now has a key on it, and open the door with the key. I don't see how you could represent a puzzle like that in a Maniac Mansion style game, so I am trying to come up with a 3rd person style graphics adventure game in which you could -- but maybe it isn't possible.

 

In SCUMM, this would just have been "Use place mat on door, use letter opener on keyhole, pull place mat, pick up key, use key with door".  Again, there's a loss of specificity -- you can no longer specify *exactly* what's done with the place mat -- but again that's not much of a loss.

1

Share this post


Link to post
Share on other sites

might be missing something here, but SCUMM had commands with multiple object "slots" as well -- give always had two slots,

 

I'm talking slots bound to objects not slots in commands.

 

Generally I think that it is a mistake to try to re-ify a text command with a GUI. This is what SCUMM did and it is not what I am after. It is what sunandshadow says is "immersion-breaking and sucky" above. And anyway If you wanted to do this the best idea would be a speech-to-text interface which given the small vocabularies of these games could be perfect without training with today's technology. Failing that you could just have some kind of menu system that is basically an onscreen keyboard optimized for this kind of game. But this isn't what I want.

 

I want a pure GUI that is as rich as the infocom text UI. Ultimately what I think is interesting about infocom games was the object model rather than the pseudo-NLP. The object model allowed semi-emergent behavior: you want to put the letter opener on top of the clock? okay, it is on top of the clock -- because the clock knows it can have stuff on it. You want to put the elephant on the clock? No, the clock says it can't have something that big on it.

 

This object model, or soemthing like it, would need to be translated into some kind of visual language...

Edited by jwezorek
0

Share this post


Link to post
Share on other sites

Hmm... At least some of that could be done these days via a physics engine: you can put things on top of objects that have a sufficiently flat top surface, and can't put very big things into very small things, for example.

 

However, for less physical elements, or elements less suited to physical simulation (cartoony worlds or magic, for example), I'm not sure of how to go about it save by attempting to list all possible types of interaction and appropriate parameters for them (for example, object A has the property "surface", which means that things may be placed on it, with the parameter "small", meaning that only objects of size "small" or below are accepted).

 

I do still think that the context-sensitive menu, as I and others have mentioned, is a potential middle-ground: each object specifies what actions may be taken with it, and contains logic by which it responds to those actions; in some cases that may allow for an inventory item to be specified, but in many the action alone--such as "eating" a plate of food--may make sense.

 

As to Infocom, to what extent did they have an actual object model, rather than simply--but exhaustively--filling in interaction combinations?

0

Share this post


Link to post
Share on other sites


Hmm... At least some of that could be done these days via a physics engine: you can put things on top of objects that have a sufficiently flat top surface, and can't put very big things into very small things, for example.

 

Yeah, you're right, but full physics engines open their own can of worms. Some emergent behavior is good. Too much emergent behavior and you can't construct a (traditional) adventure game because you can't count on anything. I need a semantically stylized world not an interactive physics simulation. The AAA games are exploring this space anyway and they are sure as hell better at than me.

 


 
I do still think that the context-sensitive menu, as I and others have mentioned, is a potential middle-ground: each object specifies what actions may be taken with it, [...]

Oh, I mean I agree ... I am just wondering (1.) if you could standardize some kind of model for specifying what can be done to what (2.) expose an interface to this model that doesn't involve (literally) spelling out actions with text in (literal) menus.

 

As to Infocom, to what extent did they have an actual object model, rather than simply--but exhaustively--filling in interaction combinations?

 

Oh, no, they did it basically the way I am saying -- they had to: it was actually an optimization for space on the tiny computers of that time. Their software was way ahead of its time. The first object oriented codebase sold commercially and the first virtual machine sold commercially. this is pretty interesting if you are interested:

 

http://www.gdcvault.com/play/1020612/Classic-Game-Postmortem

0

Share this post


Link to post
Share on other sites

 

Oh, no, they did it basically the way I am saying ...

Impressive! I haven't yet read the article to which you link, but have put it aside for later reading: it sounds rather interesting indeed!

 

 

I am just wondering (1.) if you could standardize some kind of model for specifying what can be done to what (2.) expose an interface to this model that doesn't involve (literally) spelling out actions with text in (literal) menus.

Funnily enough, I actually had a shot at something like that--although I'm not sure that my experience is terribly useful here. In my case, I had a set of spells, and objects responded to those spells in a variety of ways; to a given spell, some objects might be inert, others had default behaviour, and others had custom behaviour. For example, given a "pull" spell, an anchored object might not respond at all; most non-anchored objects (such as rocks) might have go with the default behaviour of moving towards the player; and a few objects might have custom behaviour, such as water rippling or a pendulum swinging.

 

Alas, my implementation didn't work out, however. (I think that I recall that one problem was that players found it difficult to intuit what a given spell might do.) However, this may well not reflect on the central idea of such a system as you describe--it's just an anecdote of my own experience.

1

Share this post


Link to post
Share on other sites


In SCUMM, this would just have been "Use place mat on door, use letter opener on keyhole, pull place mat, pick up key, use key with door".  Again, there's a loss of specificity -- you can no longer specify *exactly* what's done with the place mat -- but again that's not much of a loss.

 

Oh just to follow up on this ... (I meant to write this earlier but forgot) ... the problem with the loss of specificity isn't that guessing verbs is good or that a "use" button is bad, it is that if you pare it down this much you open the door on the style of play in which you just try "use"-ing every object on every other object and every room-based interactable.

 

Having to be specific rules out this kind of guessing because of the combinatorial explosion of verbs and prepositions.

0

Share this post


Link to post
Share on other sites

Prepositional phrases worked for modifying some objects if, I think, the object exposed a property for a slot associated with the preposition -- I'm guessing this is how it worked internally anyway; for example in The Hitchhiker's Guide to Galaxy pretty much the whole solution to the Babel Fish puzzle involved prepositional phrases and the object model they induced "Hang dressing gown on hook (so the "hook" has an "on" slot). Cover grating with towel (the grating also has an "on" slot which <cover> <with> knows to map to). Place satchel near door. Place junk mail on satchel. 

I want a pure GUI that is as rich as the infocom text UI. Ultimately what I think is interesting about infocom games was the object model rather than the pseudo-NLP. The object model allowed semi-emergent behavior: you want to put the letter opener on top of the clock? okay, it is on top of the clock -- because the clock knows it can have stuff on it. You want to put the elephant on the clock? No, the clock says it can't have something that big on it.

 

This might be overstating the internal richness of the model.  Having read the source of some of those games (not HHGG, though), and having programmed in similar systems in the MUD days, I don't recall this kind of relationship between complex user input and a complex object model, especially with respect to prepositions.  What complexity the model did have (although I would call it "elegant" rather than complex or rich) wasn't dependent on the richness of the input, because by the time the engine is performing operations on the model the input complexity has been stripped down to nearly SCUMMy simplicity.

 

I think the reason the graphic adventure games didn't really support the more "emergent" possibilities of a text adventure was more a function of the "other" side of user interface: limitations on game feedback, rather than limitations on user input.  When the results of user interaction with the world are expressed solely in text, that's easy, cheap, and flexible the way graphics aren't.  You can put anything on anything (that makes sense), in anything (that makes sense), etc. because there's no real additional cost to generating the appropriate sentences.   (Consider King's Quest IV, the most complex of the text-input King's Quest games.  There's little in KQ4 like the freedom and emergent possibilities of an Infocom game, even though the parser is reasonably sophisticated.  The constraining factor wasn't the input, but that results needed to be portrayed visually.)

1

Share this post


Link to post
Share on other sites

[...] Having read the source of some of those games (not HHGG, though) [...]

How did you read the source of an infocom game? Is there code in the public domain for one of them? I mean, for a modern personal computer: Zork was public domain but that would be DEC fortran. 

 

 


I think the reason the graphic adventure games didn't really support the more "emergent" possibilities of a text adventure was more a function of the "other" side of user interface: limitations on game feedback, rather than limitations on user input.  When the results of user interaction with the world are expressed solely in text, that's easy, cheap, and flexible the way graphics aren't.

 

Yes, I agree totally with this.

 

This is why I am saying that Infocom's natural language thing is kind of just a lot of hype and what you would need to do in graphics to do what they did in text would be to make a "visual language" for representing a very simple object model i.e. when something is "on" something it always looks like this; when something is "in" something it always looks like this. And then allow the user to interact with it i.e. when the user "opens" something he always does this.

 

So in order to do this you would need some kind of stylized graphics and I am thinking of maybe a mode in which you focus on a room object and the game kind of switches to first person with the visual language inter-actability thing enabled. Sort of like when you "examine" an object in text.

 

I mean, I don't really have this all worked out but that is why I started this thread.

Edited by jwezorek
0

Share this post


Link to post
Share on other sites

How did you read the source of an infocom game? Is there code in the public domain for one of them? I mean, for a modern personal computer: Zork was public domain but that would be DEC fortran. 

 

The original Muddle code for Zork is here; not sure of its licensing: http://retro.co.za/adventure/zork-mdl/ .  You can run it, I think, on the Confusion engine.  For a modern PC, I think there are also ports of some of them to more recent Inform parsers like 6 and 7.  I couldn't say how accurate they are to the original but I believe the general execution model hasn't changed much.  (Well, for 6. I have no idea what's going on in 7 'cuz I can't read it.)

 

This is why I am saying that Infocom's natural language thing is kind of just a lot of hype and what you would need to do in graphics to do what they did in text would be to make a "visual language" for representing a very simple object model i.e. when something is "on" something it always looks like this; when something is "in" something it always looks like this. And then allow the user to interact with it i.e. when the user "opens" something he always does this.

 

So in order to do this you would need some kind of stylized graphics and I am thinking of maybe a mode in which you focus on a room object and the game kind of switches to first person with the visual language intractability thing enabled. Sort of like when you "examine" an object in text.

 

Ah, yeah, I get ya.  

 

Here's an idea, maybe not exactly what you're thinking of but similar.  There's a view mode where everything interactive in the scene is represented (maybe as itself, maybe as a label, maybe as a low-poly model of itself textured with an image of its label) a little "spread out" from its representation in the world.  In between objects are lines that represent relationships ("in", "on", "belongs to", "near", etc.)  Your inventory is all the objects that are connected to you by "belongs to". You change the world by changing these lines.  To give a picture to Sam, you move the "belongs to" line from the picture to Sam rather than to you.  You move the vase to the floor by moving the vase's "on" line so that it goes to the floor rather than the table.  Etc.

 

This is weirdly artificial but I think it'd work if the game universe was also weirdly artificial (if, say, you're in a simulated reality and gain the ability to see the object model that underlies your world).

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0