Jump to content

  • Log In with Google      Sign In   
  • Create Account

Does the interface of every graphic adventure game suck?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
16 replies to this topic

#1 jwezorek   Crossbones+   -  Reputation: 1863

Like
1Likes
Like

Posted 07 August 2014 - 10:49 AM

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, 07 August 2014 - 02:19 PM.


Sponsor:

#2 TechnoGoth   Crossbones+   -  Reputation: 2766

Like
0Likes
Like

Posted 07 August 2014 - 11:18 AM

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.



#3 Servant of the Lord   Crossbones+   -  Reputation: 19572

Like
3Likes
Like

Posted 07 August 2014 - 11:46 AM

If you qualify Myst as a graphical adventure game, I feel like Myst's direction has the right idea: First person, mouse-interactions, little or no HUD. Especially as we get closer to widespread VR headset adoption, where minimal or no HUD is important, and first-person is almost a must.

 

One way to implement it, is click (or right-click) to bring up a context-sensitive-menu (probably radially like the Lost City of Malathedra's) with possible options on it.

 

To even further immerse the player, I'd probably drop all GUI elements, including the context-menu, and use combinations of keypresses and mouse-clicks to do each interaction type (limiting to only a small selection of possible verbs).

 

It'll be interesting to see how well The Witness turns out - it's trying to be a modern first-person adventure puzzle game, and one thing they are doing to prevent the undesirable "hunt for pixels" or "guess the solution" puzzles is make every interactive object look identical (therefore using a known and clear game-specific visual language to communicate to the player - players can tell what they can click on just by looking at it) and every puzzle uses the same core interactions and just build up mechanics.

 

Other ways to combat hunting for interactive elements include things like highlighting or glowing elements (feels to "hand-holdy" though), making the elements more saturated compared to the background, or giving them a cell-shaded like outline, using specific color schemes or color language for interactables (Mirror's Edge took that to a too hand-holdy extreme though), or using (like The Witness) an object-language for intractable (every RPG has 'chests' as a known interactable, even if they toss in other less-clear interactables like furniture or bookcases).


It's perfectly fine to abbreviate my username to 'Servant' rather than copy+pasting it all the time.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Of Stranger Flames - [indie turn-based rpg set in a para-historical French colony] | Indie RPG development journal

[Fly with me on Twitter] [Google+] [My broken website]

[Need web hosting? I personally like A Small Orange]


#4 Thaumaturge   Members   -  Reputation: 1397

Like
2Likes
Like

Posted 07 August 2014 - 11:55 AM

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, 07 August 2014 - 11:57 AM.

MWAHAHAHAHAHAHA!!!


#5 Ravyne   GDNet+   -  Reputation: 7409

Like
2Likes
Like

Posted 07 August 2014 - 12:01 PM

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, 07 August 2014 - 03:07 PM.


#6 sunandshadow   Moderators   -  Reputation: 4918

Like
1Likes
Like

Posted 07 August 2014 - 03:01 PM

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).


Phone game idea available free to someone who will develop it (Alphadoku game - the only existing phone game of this type is both for windows phone only and awful. PM for details.)


I want to help design a "sandpark" MMO. Optional interactive story with quests and deeply characterized NPCs, plus sandbox elements like player-craftable housing and lots of other crafting. If you are starting a design of this type, please PM me. I also love pet-breeding games.


#7 jwezorek   Crossbones+   -  Reputation: 1863

Like
1Likes
Like

Posted 07 August 2014 - 03:08 PM

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, 07 August 2014 - 03:14 PM.


#8 ActiveUnique   Members   -  Reputation: 835

Like
0Likes
Like

Posted 07 August 2014 - 05:11 PM

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.


I've read about the idea guy. It's a serious misnomer. You really want to avoid the lazy team.


#9 valrus   Members   -  Reputation: 671

Like
1Likes
Like

Posted 07 August 2014 - 07:42 PM

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.



#10 jwezorek   Crossbones+   -  Reputation: 1863

Like
0Likes
Like

Posted 08 August 2014 - 09:11 AM


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, 08 August 2014 - 10:55 AM.


#11 Thaumaturge   Members   -  Reputation: 1397

Like
0Likes
Like

Posted 08 August 2014 - 10:40 AM

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?


MWAHAHAHAHAHAHA!!!


#12 jwezorek   Crossbones+   -  Reputation: 1863

Like
0Likes
Like

Posted 08 August 2014 - 11:08 AM


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



#13 Thaumaturge   Members   -  Reputation: 1397

Like
1Likes
Like

Posted 08 August 2014 - 11:33 AM

 

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.


MWAHAHAHAHAHAHA!!!


#14 jwezorek   Crossbones+   -  Reputation: 1863

Like
0Likes
Like

Posted 08 August 2014 - 04:07 PM


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.



#15 valrus   Members   -  Reputation: 671

Like
1Likes
Like

Posted 09 August 2014 - 01:10 PM

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.)



#16 jwezorek   Crossbones+   -  Reputation: 1863

Like
0Likes
Like

Posted 10 August 2014 - 11:27 AM


[...] 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, 10 August 2014 - 03:33 PM.


#17 valrus   Members   -  Reputation: 671

Like
0Likes
Like

Posted 10 August 2014 - 03:10 PM

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).






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS