Fast Travel & Getting Lost

So, the whole of my game is gonna take place on a single really large warship, The Manik. It’s probably going to end up being much larger than ships in real life, but I digress.

One of the things I want to do is limit the areas the player can go to by the current chapter of the game. So as the game goes on, more areas open up to the player. However, I’ve also had another idea, and that is to open areas up with items.

For example, when the player gets a blowtorch, they can cut through some stuck bulkheads (It’s stuck because the whole goddamn ship has been squished like a beer can). Or the player might need a light that doesn’t go out underwater to pass through a submerged compartment.

This comes with one issue- The player getting lost early on. The obvious solution to this is to put puzzles and clues in every area, but the goal structure of this game is spread out over several chapters, and early on the goals are limited to the first few areas.

Getting lost in an unfamiliar area is probably one of the most quintessentially IF things I can think of though, so I have an idea- Fast travel.

Fast travel works by allowing the player to quickly go to a central room of a certain area- for example, the main entrance to the Brig, the Mess proper, the communication terminus. However, you can’t fast travel to places that you haven’t been, and you can’t travel to places that aren’t on your map, which updates as the chapters go on.

As well, most of these rooms are still a bit disconnected from the rooms you’ll need to be in, so there’s still some puzzling and navigation required even when you fast travel.

Fast travel, mostly, is just a way to prevent the players from getting lost in all three dimensions of this map and not being able to find their way back to the area they need to be. It also removes some of the tedium of probing your way through the abstract text-based environment of a goddamn warship while still preserving most of the real navigation-based puzzles.

What do you think?

Thank you.

GO TO NAVE (or any known room) is a well-understood IF verb form. Not many games implement it, for two reasons:

  • You have to be careful about your game design. Is there a door in the middle of the ship that the player could close and re-lock? Is going through that submerged compartment going to make the potato chips soggy in your inventory? Either commit to having no obstacles with side effects, or account for the side effects in the GO TO routine.

  • Many players are surprisingly happy to type N.NE.N.E.E.S rather than GO TO COMMS. It gets in your fingers. So you need a pretty large game for the idea to make much sense.

But if you’re willing to do the work, some players at least will be very happy with the command.

2 Likes

this ‘teleportation’ feature, is not uncommon. dialog has this available by default, as long it’s a previously-visited room.

as zarf says, though, it can lead to unforeseen results. has something changed in that room in the meantime? is there a daemon or timer running that gets “short circuited” by the player suddenly jumping to a new location?

IMO, it’s more trouble than it’s worth. if someone has chosen to play a text adventure game i think it’s OK to expect that they can handle basic navigation.

2 Likes

I’m very interested in this, yes! I guess a question is always whether parts of gameplay add or detract from the experience. If a lot of backtracking on a big map isn’t a rewarding player experience, it’s worth a look.

The challenge I see with fast travel on a big map is: how do players know where they want to go? Room names? Contents of rooms? It’s easy to show this stuff to players, but it gets kind of busy after a while. One way to keep that under control might be waypoints, perhaps a printed list with region descriptions.

I haven’t figured it out yet! But I think the information/presentation is turning out to be the hard part for me

2 Likes

(I will say, i’m playing dreamhold right now and not playing for 16 hours at a time is obliterating my ability to navigate)

(especially when I’m only able to play for 15 minutes)

Fast travel seems fine as a solution (and has many have said it’s a common one as well), but if the map is complicated, include graphical maps with your game (not just an ASCII representation or something). But many players will just look at the map (or their own map) and navigate through the rooms.

Make sure that once a puzzle is solved, the player can navigate between the rooms with just a directional command. For instance, if a code is needed to unlock a door, then once the door is unlocked, the door stays open so the player just has to GO NORTH through the door. If it’s a persistent obstacle, account for that in the fast travel.

3 Likes

oh an ASCII map for this game would be silly. I know I played around with it but i’m gonna draw out maps for the manik.

I always feel kind of bad for this kind of “oh, i’m right” response to people’s suggestions, I do it way too often and idk if it makes me seem like a jerk or not

1 Like

I think providing a map of some sort is the key, unless you want players making their own maps to be a key part of the gameplay. (Which some games do!)

But another solution is to ensure that the player can’t access another area until thoroughly exploring the first one, because exploring the first one lets them solve the puzzle to unlock the second. Then they need to thoroughly explore the first two to solve the puzzle to unlock the third, and so on.

This is why games like Hollow Knight tend to be pretty linear in the first area, before then opening up more broadly: it ensures the player has gotten used to the game and basic navigation, and started to form a map in their head, before that map opens up.

Hadean Lands is another game set on a wrecked ship (well, “ship”) that incorporates fast travel, and it also has this sort of “slowly opening up” structure. First you’re trapped in a single room until you solve some puzzles that teach you the basic mechanics of the game. Then you’re trapped in a single hallway until you do some more problem-solving. And only then do you get out into the main structure of the ship.

3 Likes

You could create a command like “go towards X” which computes a path towards the room and moves one room along the path.

I haven’t tested it myself, but isn’t Approaches by Emily Short intended to solve this exact use case?

1 Like

I’m talking less about the actual implementation and more of the idea, or the theory. Mostly just collecting people’s opinions and shaking them up in a jar to see what it tastes like

We’ll cross that bridge when we get there

Nightfall - Details has this kind of behavior.

1 Like

In my WIP, you can use either. You can try to go to anything you’ve seen, any room you’ve been to, or, to some extent, anyone that you know, from the current chapter, by name. I expanded it to things as well as rooms just because @aschultz was testing, and has this feature in his games, and said ‘Why don’t you add it?’

For tech reasons, you can’t chain commands in my game (can’t type N. W. N. W. W in one line), so in these circumstances, I think fast travel is already a help.

In testing, I don’t see many people using GOTO, though interestingly, what I do see is that now and then, they will use it in isolation to get to an object or room they’ve just thought of, by name, that’s now relevant. The result often looks stunning (to me reading the transcript anyway!) when it conveys that the game seems to know what they’re thinking.

Having content gated by chapter is what has made this all a challenge to program rather than Beyond The Pale. As soon as everything you’ve encountered is in scope for the purposes of GOTO, you have a mountain of programming to do to make sure the game doesn’t make stupid choices or ask agonising disambiguation questions. In IF, we already curate non-overlapping content names carefully. Now I do that even more carefully! It’s still tough even when each chapter’s contents are mostly a walled garden, and I’m thinking of the GOTO behaviour all the time.

The programming also takes circumstance into account. Things with similar names will be favoured or unfavoured by what I know the PC would be practically be interested in at that moment for purposes of advancing their lot.

My system also doesn’t freeze time while you’re moving. So every turn rules are running while you move. Your journey can be interrupted and stopped. I also have to block the text output of certain every turn rules while the player is ‘hurrying’, as Emily Short named it in her extension which was the start for my system.

So what I’m doing is probably the most wide-ranging incarnation of fast travel that has been. Not all of these angles of it are or would be necessary for every game, but I just wanted to share my experience of these angles in case they’re things the OP hasn’t thought about.

Not opening the GOTO command to people and objects probably reduces the work by 60%. It’s much easier to only ever have to think about room names.

-Wade

4 Likes

In one of my current WIPs (please look forward to it!), the player can go to almost any visited (or visible) place (until the endgame, anyway). Or to any thing. In fact, they can try to meow at the light switch, and the protag will try to go to the location of the switch before meowing at it.

That’s also per turn travel, too, and suppressing some every turn stuff seems essential.

It becomes a bit of a nightmare thinking about disambiguation in that way… though I think I’d be smarter about things if I had it to do over. I always barge in without a plan.

I get away with a lot because I have a small map and a lot of scenes. Things tend to stack nicely. The scope of your game is a whole different league.

But my big worry about this kind of approach applied to a big map is the fact that players probably don’t remember room names perfectly. Or things! So jogging the player’s mind about what is where and what might need doing at any particular time seems important. And that in turn ties into goal management, and choreography, and so forth. It leaves me wondering how to talk about a large world in a way that is useful without exploding into many lists.

I have a year to figure that out, hopefully.

Anyway, excited about your game @severedhand, as I hope you already know

5 Likes

Like I think I said, quick travel takes you to the middle of an area.
Areas in this sense are made up of groups of different rooms.
So going to The Brig, which is an area, will send you to one room in the brig. You can’t quick travel to every individual room.
Going to the Mess will take you to the mess room. And etcetera.
The map shows these areas by their names, and if I include quick travel I will also include an explanation of how it works.

Like I think I said, quick travel takes you to the middle of an area.

This certainly simplifies the implementation, but you may have to do extra work to convey to the player what an “area” is and why only some rooms are eligible for fast travel.

Depends how it works, of course. If there’s a teleport gate in certain rooms, that makes it obvious. If it’s a GO TO ROOM command, probably some explanation is needed.

1 Like