Fast travel (GO TO ROOM)

What are your opinions on having a ‘GO TO’ command that takes the player directly to that room if it exists, no matter how far away it is.

Right now I’m working on a game that has the typical compass directions but the player can also type ‘GO TO KITCHEN’ and it will move the player there. But only if the kitchen is actually a neighbouring room, otherwise the game will tell you that the location is out of reach.

So I was wondering if the ‘GO TO ROOM’ command should also work by teleporting the player there anyway, even it’s not a connecting room.

The i7 game Bronze has a pretty good ‘GO TO’ command. It’s in part 4, section 5 of the source.

It doesn’t teleport but goes move by move. If you haven’t been to the location before it won’t work and if there’s something on the route that is blocking, the command will halt.

With teleporting there’s a risk that it may bypass conditions. E.g. if you can only access a room after you block a waterfall, the teleport command should check this for this specific room. If not, you may get unwanted behavior.

1 Like

I am hugely in favour of a GO TO command unless the map is small. But you need to give some thought to how it works.

  1. Your proposed approach would annoy me a lot. It’s neither helpful nor logical. It’s not logical because a room is not “out of reach” just because it’s not adjacent. It is unhelpful because it’s precisely when a room is some distance away that you want such a command. Your command is unusable unless the player knows the map (i.e. knows that a room is adjacent), and unnecessary if she does. So think again.

  2. “Teleporting” is a problem too, unless you are absolutely sure (i) that nothing could happen between the current room and a target room and (ii) that it doesn’t matter, either for game play or for general impression, that travel is instant.

You should probably have a look at games that have this feature, which is often implemented in different ways. Off the top of my head, Nightfall, Counterfeit Monkey (I think?), and Hadean Lands are possible exemplars. Of those, I’m guessing the Nightfall method might be the simplest, and it is still useful.

  1. In an ideal world, which this isn’t, I want to be able to GO TO any room that it is credible to suppose the PC would know about, using a single command which will be “interrupted” only if travel is interrupted, and which will otherwise provide a short summary of the journey (which need not necessarily list every room visited on the way), and which if interrupted will explain why. EG:

GO TO KITCHEN
You go down the stairs and make your way to the kitchen.

GO TO KITCHEN
You go down the stairs and into the hall. But the door to the kitchen seems to be locked.

  1. Consider also all the other ways you help those of us who are poor at remembering spaces to navigate:

(a) exit listing in the status line,

(b) exit listing with rooms identified,

(c) inserting narrative into room descriptions (so that “A door leads north.” becomes “The kitchen is north.” once it’s been explored or is known about),

(d) writing descriptions so that exits are easy to identify (less important if there is an exit listing systems),

(e) interactive (difficult, but lovely) or accompanying (much easier) maps,

(f) minimal use of non-cardinal directions and confusing geographies (e.g. curved rooms),

(g) accommodating obvious alternatives (e.g. if “You are in the greenhouse. A door leads north out into the garden.” then “out” should work as well as “north”, and not tell me i’m not “in” anything.),

(h) helpful “You can’t go that way” messages which tell you what ways you could go.

Obviously there may be legitimate reasons not to adopt any or all of those; there may be times when you legitimately need to make navigation difficult. But usually not.

1 Like

Great advice here, thanks. And good tip about checking move after move for obstacles en route.

At this time, the GO TO is simply a substitute for a compass direction. But I will probably follow your advice and make it an actual fast travel mechanic. So the player can type GO TO and if the location has already been visited, the player will GO there. Providing a short summary of the trip is also a good idea to implement.

Also, I’m writing my own parser and creating a GUI to go with it. The possible exits + their rooms will always be visible in a separate part of the game window as well as in the room description to avoid confusion about possible directions. A map will also be included and will actually play a part in the game.

For HL I found it useful to divide the world into “zones” – that is, groups of rooms where fast travel between them was always possible. If you can get from X to Y without moving through a lockable door or a puzzle, they’re in the same zone.

Then I hand-coded the connections between zones, with appropriate checks. (Fast travel between zones might be possible – if the door is opened and the puzzle solved. Or it might not. The system was then attached to the puzzle-auto-solver, a much more complicated problem.)

I’m afraid my code doesn’t make a good extension, because it’s mostly hand-coded routes and checks. But it’s one way to tackle the problem, if you have a complex map and you want to be thorough about it.

Can you share more details of your project? Would be interesting to see what you’re working on. Maybe in another thread to keep this one on topic.

Sure, I love talking about it.

The reason I’m creating my own is simply because I love programming and I have always wanted to create a text adventure from scratch. And to prove to myself that I can do it. My aim is to make a parser that can be as robust as the Infocom parser, but I know that’s not at all an easy task and will take me a while.

The advantage of programming it myself is that I have all the freedom to make it what I want it to be, the main disadvantage is the fact that it’s easy to forget to implement stuff that a parser should be able to do. So it will require a whole lot of testing and a whole lot of debugging.

I’m doing this in Java, using JavaFX for the GUI. I’m just more of a programmer than a writer.

I guess I can make another thread about it, mostly because I’m interested in knowing who else likes to create their own parser and to gather some experiences.

Great input and a neat idea.

Right now I’m looking if I can write a pathfinding system for the GO TO command. One that can also be used for wandering NPC’s. But it’s not going to be easy.

Same here. I wrote my own development system because I like programming too. I’m not an author, I like trying to build a system that can handle complex situations like the GOTO. I wrote it in C, java wasn’t there yet when I started :slight_smile:

My system has a goto(object, destination, number_of_moves) function. It uses the story map and sort of a spanning tree algorithm to determine the shortest route from the object’s location to the destination and then moves the object towards the destination by the number of moves. I use this to let NPCs travel around. It also has a firstdir(source, dest) function that returns the first location to move to when going from source to dest, without actually moving. This can be used to check whether the move is permitted.

Are you programming the adventure in java together with the interpreter or is it a stand alone interpreter that takes an inputfile? I made a compiler that compiles a tekst input file to a binary that is read by the interpreter.

Right now I’m trying to learn the interpreter to handle ambiguous input like “hit man with hammer”. This could mean "hit the object called ‘man with hammer’ " but also “hit the object called ‘man’ using the hammer that is in your inventory”. I think that by considering object descriptions and inventory the interpreter should be able to figure out how to parse this.

I browse the forums here for questions from story authors working with various development systems and then check whether my system can handle such situations.

That’s a nice way to implement pathfinding. I’m not there yet at this time. Right now it’s just a teleport to the location. Which is not a bad thing since there shouldn’t really be any obstacles in the game I’m planning to write, but I will ultimately need a real system for NPC’s.

Yes, I’m making it a standalone application with an installer. Windows, but also Linux and Mac. Mostly because I have never made a standalone desktop app and I would like to see how that all goes! :slight_smile:
I’m used to creating things for Android or regular Java Enterprise stuff for the web, which isn’t very exciting.

The example in ambiguity you gave is interesting to me. It never crossed my mind that a player may mean ‘hit the the man that’s holding a hammer’ instead of ‘hit the man with the hammer that I have’.

I’m not sure how I would handle such a case. Then there’s also the obligatory ‘hit man with hammer with hammer’. But on the other hand, I don’t know if it’s really necessary. I think that when a player types in ‘hit man with hammer’ it should be fair to assume he means a hammer in inventory. But it’s definitely an interesting exercise!

Well, I’ve already spent some time thinking about this :slight_smile:

As I see it, the thing is that a preposition (e.g. ‘with’) can have 2 purposes in the user input:

  1. tie an object to an action - hit WITH something
  2. further detailing one individual object - man WITH

I want to teach my interpreter to assume that when there are 2 prepositions in the input sentence, the latter will tie the object that follows to the action and the first one detailes the object. So, “hit man with hammer with hammer” will be parsed as hit the man who has a hammer with the hammer from my inventory.

The ambiguity issue arises when there’s only one preposition - hit man with hammer. I think I will teach the interpreter to assume at first that the preposition is meant to detail the object. If it cannot find an object in scope that matches this description, the interpreter must backtrack and assume that the preposition is meant to tie the object to the action.

So in case of “hit man with hammer” it will try to find an object in scope that matches the description “man with hammer”. If such an object exists, the interpreter will process the command and probably ask something like “What do want to hit the man with the hammer with?”
If it cannot find such an object it will try to find 2 objects “man” and “hammer” and tie them to the ‘hit’ action.

I agree that this won’t happen often and by choosing your object names wisely it may be avoided alltogether. But then, I like programming…

I’ve thought about this a little bit (and I am not a programmer, so take what I have to say with a whole salt mine). It’s a bit reminiscent of the Winograd Schema Challenge–which, as you will gather, is a very difficult challenge in general. Consider “SHOOT THE MAN WITH THE GOLDEN GUN.” Does “with the golden gun” apply to the verb “shoot” or the noun “man”? Well, it depends on whether you’re holding the gun or the man is.

The great thing about this for our purposes is that the game shouldn’t need to use general knowledge to figure out a lot of these things. So, you know and I know that if I say “bribe man with clipboard” it’s the man who has the clipboard and if I say “bribe man with money” it’s I who have the money. And that requires a lot of general knowledge about clipboards, money, and bribing which computers don’t have and it would be a pain to program in. But in this case, we can just tell the game: If the player is holding the thing after “with,” then it’s the indirect object of the action. If someone else is holding it, then it’s a description of the object of the action. And if you need to make a guess–well, the programmer of the game can use what they know about their model world to program the right guess in.

Inform actually can handle this kind of case:

[code]Bopping is an action applying to one thing. Understand “bop [something]” as bopping.

Bopping it with is an action applying to two things. Understand “bop [something] with [something carried]” as bopping it with.

Instead of bopping when the player carries nothing: say “You don’t have anything to bop with.”

Instead of bopping: try bopping the noun with a random thing carried by the player.

Report bopping it with: say “You use [the second noun] to hit [the noun].”

Understand “with [something related by carrying]” as a person.

Understand “man” as a man.

Arena is a room. Bob is a man in the Arena. He holds a Nerf lance. Jim is a man in the Arena. The player holds a Nerf sword.[/code]

This yields:

Note that “with lance” was used to decide between Jim and Bob, but “with sword” was a specification of the weapon not of the person I wanted to bop, so Inform had to ask who I wanted to bop. (The code for that disambiguation is deep within the Inform parser and is a huge PITA. If you’re writing your own parser I suggest looking at it carefully.)

Now, this can get a lot more complicated in ways that Inform can’t handle. As far as I can tell there’s no way to have Inform do something like make sure that “frob x with y” is understood as a certain action only when x and y have a certain relation (except for a couple special-case tokens like [things inside], which again are huge PITAs and responsible for a ridiculous amount of complexity in the code). But I really like this idea of Understand lines, because they let the system outsource a lot of stuff to the game author; and if I wanted something from a new parser it would be more flexibility in the kind of Understand lines I could write.

The annoying thing is that you want to understand “bribe X with Y” even when X and Y don’t have the appropriate types or relation, because you want to print an appropriate rejection, not “I don’t understand that verb.”

What you want is for that parsing to be preferred in the disambiguation stage. Inform wants to work this way, but is rather too weak. (As is widely grumped about, does-the-player-mean rules aren’t up to snuff for two-object grammar lines.)

Yeah, what I’d really like, if I could have whatever I wanted, is something where parsing and disambiguation happen together. (And I understand that this is not remotely plausible for Inform! I’m talking blue-sky thinking here.)

So you might have something like, with the initial numbers just meant as comments:

[1] Understand "bop [x] with [y]" as bopping x with y when y is a weapon held by the player (100%). [2] Understand "with [x]" as y when y is a person and y carries x (100%). [3] Understand "bop [x]" as bopping x (90%). [4] Understand "bop [x] with [y]" as bopping x with y when y is a weapon (60%). [5] Understand "bop [x] with [y]" as bopping x with y (50%).

And then the parser goes through a possible parsing, takes the percentages that are assigned to all the Understand lines it has to use to get that parsing, multiplies them, and picks the one with the best percentage. So:

“Bop Bob with sword” goes to line 1, “bop [Bob = x] with [sword = y; weapon held by the player]” and gets understood as bopping Bob with the sword as a 100% match.

“Bop man with lance” can’t go to line 1, because the thing after “with” isn’t a weapon held by the player. But according to line 2, “with lance” can be understood as a 100% match for Bob, which lets us plug Bob into line 3, which is a 90% match for bopping Bob. So overall we have a 90% match for bopping Bob here.

We also can match line 4, with x as Bob (or Jim) and y as the lance. But since line 4 is only a 60% match, we only have a 60% match for bopping Bob with the lance or Jim with the lance, and this is dispreferred to construing it as bopping Bob.

Then if we try “bop Jim with lance,” since line 2 isn’t at all a match for Jim, the only available line is 4 (or 5), so we get a 60% match for bopping Jim with the lance as our best match, and it gets sent to whatever will tell the player they haven’t got the lance.

(Unfortunately in this particular case, “Bop Bob with lance” winds up getting construed as bopping Bob, which is less desirable.)

There are probably flaws with the percentage system that I haven’t thought of–it’s just a brainstorm.

Another idea might just be to have fallback parser errors for when an object could be understood but didn’t match the grammar line, along the lines of Inform’s “You can only do that to something animate” error.

I’m not in favor of having too much ‘intelligence’ in the interpreter. Especially if the author cannot override it.

In the example:

bop man with lance You use the Nerf sword to hit Bob

What if we want the player to take the lance from Bob and then hit?

bop man with lance You take the nerf lance away from Bob Who do you want to hit with the lance? Bob or Jim?

Or maybe the object is on the floor in the room, so the test for the character owning it will fail.

Maybe hypothetical situations, my point is that the author must be in control.

A more realistic example, my interpreter has a goto() function that can be used to let NPCs walk around between locations. Initially, this function had loop detection built in (before each NPC move the route is recalculated so there is no knowledge of the previous location).
I removed the loop detection for 2 reasons:

  1. It’s the author’s responsibility to create such a map that it won’t loop;
  2. What if someone wants to create a puzzle where you have to drop obstacles to trick a robot into going back and forth between locations. Loop detection would prevent this puzzle.

Just my thoughts. Thanks for reading.

It seems like I wasn’t clear, sorry! In my example (and in the original example from Inform 7), all the Understand lines are written by the author. So the author is in control of how the line gets parsed. My suggestion was that instead of putting the “intelligence” in the interpreter, it would be a good idea to set up a framework in which the author can easily program in the “intelligence,” as it were.

From my perspective this:

is trying to put too much of the intelligence into the interpreter. The interpreter shouldn’t assume that the default is always that a preposition is meant to detail the object, because the author is in a better position to know when that should happen than the interpreter is. Consider the following:

The point here is that we want “examine the lime in the coconut” to be parsed as “examine (the lime in the coconut),” but we don’t want the second “put the lime in the coconut” to be parsed as “put (the lime in the coconut)” so the game responds “Where do you want to put the Key lime?” Which the author (or a standard library) should be able to take care of by specifying that reading “put in [y]” as putting x in y is preferred when x is not in y and dispreferred when x is already in y. But that’s not something that the interpreter should program in as a general rule for how to read prepositions, it’s specific to the verb “put.” (There would be no particular reason to do the same thing for “squeeze lime in coconut,” for instance.)

(By the way, note that in the example I gave, if the mace is on the floor, “bop man with mace” is going to get parsed by line 4, since it doesn’t match lines 1 or 3–since nobody in the room matches “man with mace” according to line 2. So if the author’s action processing rules make sure that you try to pick a thing up before using it to bop anyone, that will work as desired.)

Inform gives the author control over a lot of this by having Understand statements in a standard library where it’s not too difficult to override them. But there’s some low-level behavior in the parser that’s annoyingly difficult to override (it requires tinkering with some very complex parser code), especially with disambiguation–this is part of what zarf was alluding to when he talked about does-the-player-mean rules not always being up to snuff.

It seems to me that (especially if you’ve already programmed loop detection) a more author-friendly solution might be to allow loop detection as an option? So if they want a puzzle that requires loops, they can turn off loop detection, but if they don’t, they can leave it on. Again, seems like it’s better to give the author more control, as long as it doesn’t involve outsourcing too much work to them.

And thank you for reading! Obviously this is your project which you’re doing partly out of a love for programming and you have no obligation to listen to my desires. It’s just that you obviously are thinking very hard about what you can do with a parser, and if someone did write a system with a parser that was easier to customize than Inform’s, I would seriously look into that system.

Seems like you’re falling into the “too much intelligence in the interpreter” trap no matter which option you choose. Maybe the game has smart robots and stupid robots in it. Maybe the game involves hacking the robot navigation database to show a bridge where there is no bridge so the robot plummets into the abyss.

Inform doesn’t do a great job of exposing its path-finding algorithm, but it lets you customize the relation it path-finds with, which is something. And, ultimately, the algorithm is written in I6 – it’s not built into the interpreter, so it can be replaced.

(Hadean Lands does not use Inform’s native path-finding at all.)

That’s interesting.

First, I wrote the text below based on my understanding of interpreter and parser:

-Parser: translates the player’s alphanumerical text input to low level stuff like object identifiers and passes this on to the interpreter.
-Interpreter: runs the story, as in executes the opcodes in the binary that was generated from the sourcefile by the compiler.

Maybe not fully correct but the above was my reference when I started my project years ago.

So, If I understand correctly you want to be able to provide to the parser additional information for matching objects, depending on the action (verb) that is being parsed? This information is determined by the author on a per story basis.

put X in/on/under/… Y: if an object that matches the player’s input is already in/on/under/… Y, do not consider it as a candidate for X. Something like this?

I don’t have this with my parser. Mine’s more static and - in a (coco)nutshell - works like this:

  • player enters line of text;
  • parser performs grammar and types checks and converts text to word ids and selects appropriate types;
  • parser identifies groups of words (say, adjectives+nouns) that make up the object(s), subject(s), etc and tries to match these to the names of objects and locations from the story.
  • This last action results in 0, 1 or more hits for object and subject.

Currently, with more than 1 hit, the parser will print a question for the player asking "Which … do you mean? " and then lists the hits if tound for the player to choose from.

Now, what I think I should do is - before asking the player to select from the list of hits - the parser should tune in with the interpreter to check whether the story author wrote additional rules for this specific action/verb that may further narrow down the list of hits? And then if still more than 1 hits remain get back to the player to ask which one to use.

I like this idea. I’m going to think about a design for this and how I can implement it.