Is there received wisdom about handling driving and drivable vehicles in IF? I’m specifically concerned about a WIP in TADS3/adv3, although I think the design considerations are probably pretty universal (for IF).
The “default” model appears to be strongly “simulationist”, at least in TADS—once in a vehicle, the parser treats it more or less like a suit the player is wearing. Navigation works the same, rooms look the same, and the main game difference (again by default, and not counting any game-specific logic for vehicular travel) is that the status line gets an extra “(sitting in a car)” or something similar.
An alternate approach I’ve seen a couple times is to convert driving into more or less a brief cutscene. Something like a “>DRIVE TO [location]” command which produces a short travel description before depositing the player at the new location.
I’m thinking of implementing something in between the two extremes I’ve described above, where vehicle travel doesn’t just use normal navigation rules—the player proceeds along a road, making decisions to stop, turn off, turn around, and so on instead of the standard n/s/e/w—but which isn’t merely a non-interactive cutscene. But I’m not sure how annoying/confusing/boring this might be to players.
Of course the answer (like in most of game design) is invariably to fiddle around until something seems playable and fun, but I was curious if there were a bunch of IF titles out there with clever vehicular travel sequences that I’m unfamiliar with.
Near the beginning of the game, your PC takes a ten-turn cab drive which consists of repeatedly pressing Z while a minimally described string of locations passes by. A long cutscene would be a lot better.
(You’re not driving yourself, but then, it’s functionally the same as DRIVE TO.)
I wouldn’t say it’s the “default” model. Rather, the Vehicle class exists if the author wants to provide a means for moving around the map while inside a nested room. If the author wants to use cut-scenes, they’re free to do that as well.
(I say this not to challenge you, but as an observation from experience. adv3 is a big toolbox. One mistake I made when I first learned TADS was to think I had to use all the tools in the box, rather than selectively picking which made sense for the story I wanted to tell.)
I suspect the answer is “it depends.” I could see there being a novelty factor to moving through the game world this way. But if this becomes the primary mode of transportation, it risks getting old real fast.
In some puzzle-style games, there’s a middle section where the player is scampering about to gather objects and use them in the right places. If moving about is hampered by manually navigating a car through the streets, that could drag on the experience.
I thought of three to four games as examples, but none of them use cars quite the way you’re describing. Perhaps you could ask on a different area (“General”?) for examples of games where the player actually drives the vehicle.
Also, you might look at IFDB for games tagged “car” or “vehicle”.
Here are the examples I could think of. I would be interested to see what examples you were referring to in your post.
In 9:05, arguably the only text adventure ever written, driving is reduced to a series of yes/no decisions about where to get on or off the freeway. The parser nature of the game is suspended and we essentially enter a choice-based system. But I think the feel of it is similar to the in-between approach you describe. It conveys/simulates only the most pertinent elements of the driving experience, in a way that doesn’t feel like walking around.
In Dial C for Cupcakes, the player character is driving around for the first part of the game. You only get out of the car when you come to the end of the chapter. Navigation is according to compass directions. This is basically the “suit” approach you’ve described. In fact, the car isn’t treated internally as a vehicle: It’s “part of the player.” The only things I did to sell the illusion were preventing you from interacting with stuff that’s “outside the car” and giving you a bunch of reasons not to “get out.”
In Curse of the Garden Isle, driving is handled with the “cutscene” method. The car is a backdrop that appears in almost every location, and you never really do anything with it.
Description of the car is "Your dingy Malibu is here, ready to get going whenever you are."
Instead of entering the car, say "Which way would you like to go?"
Instead of opening the car, say "Which way would you like to go?"
There’s a bunch of “before going…” text that describes the drive between locations. I have a strong feeling that many or most players miss this text. When you enter a new location, your eye tends to zip up to the bold location name and start reading from there.
In Curse of the Garden Isle, I was trying to tell a story about visiting and physically walking around in locations that are connected by long stretches of road. In Dial C for Cupcakes, the driving segment was supposed to be about half-aimlessly wandering around a neighborhood and getting a feel for that neighborhood, without doing all the legwork to investigate things in detail. Hopefully each game’s approach to driving simulation serves the goals of that game, and contributes to the way each game represents its setting.
I had a series of road trips earlier this year that prompted me to give some thought to the portrayal of the driving process. My gut tells me that getting bogged down in the procedural steps of driving will be fiddly and annoying if it’s more than a few turns of work, but it could be rewarding if enough care is invested into it? The approach I was working toward was to not worry about the literal pressing of pedals and turning of wheels, but I still wanted to focus the player’s action on things like maintaining appropriate speed for the road, being aware of lanes, the variety of traffic, etc, while balancing this with another layer of interactions with the environment of the car interior, following lines of thought, and so on.
Yeah, it’s clear that there’s some amount of either interactivity or descriptiveness is required, but I’m not sure where the line is.
Planetfall starts out with a (fairly brief) vehicular segment, Photopia has a couple, and there are thing like the (optional) amusement park rides in Sorcerer. But while those are all from good games, I don’t think that I, as a player, really enjoyed those sequences.
But I’m kinda of two minds. On the one hand as a player I generally dislike long cutscenes (and I don’t think I’m alone—one of the apparent paradoxes in IF is that IF in players are happy to do a lot of reading but they generally don’t want to have to read a lot all at once) and minimally interactive sequences that are isomorphic to an elevator ride (push the button and then just tap your foot while you wait for the ride to take care of itself). But at the same time I absolutely think that, for example, the start of Planetfall would feel very different if you didn’t have the escape pod sequence at the start. Or if the destruction of the ship and the escape pod trip to the planet was just a paragraph of text, or a longer introductory blurb.
In TADS3/adv3? Depends on how much of the game is accessible via vehicle. If it’s a lot, you could twiddle the Actions to implement checks. In most cases it’s probably easier to figure out what locations the vehicle(s) can travel in/through and use OutOfReach on the rooms to implement checks.
In my case most of the locations available for vehicular travel are probably going to be different than the player can traverse on foot (mostly to hand-wave away the differences of the scale of travel distances).
I mean it’s default in the sense that adv3 implements a Vehicle class and that’s the way it behaves if you don’t override it.
But I agree that it’s a little questionable to call anything about vehicular travel in IF a “default” because vehicular travel actually seems to be comparatively rare, at least as a gameplay element. That’s part of the “problem” (if you want to call it a problem).
Which is a little weird, considering how commonplace vehicular travel is in everyday experience. I think this is one of those cases where the tools we (mostly) use today to write IF are extremely well-suited to implementing games that look like Colossal Cave Adventure (only enormously more elaborate) and so writing sequences that look like they might’ve come out of C&W are very easy to implement and sequences that are wildly different in scope or content can become quite difficult to implement.
Yeah, that’s basically the sort of thing I’ve been thinking about, only with even less fiddly low-level “control the car” sort of stuff. So at the level of abstraction of doing something like >TURN LEFT AT THE LIGHT (or just TURN LEFT) and that sort of thing instead of requiring detailed descriptions of the manipulation of the car’s controls.
On the other hand I do thing all those bits need to be available for examination by the player—I find it jarring if I’m supposed to be in the front seat of a car and the game expresses bewilderment at the concept of a steering wheel.
I think that the pieces and parts of an interactive fiction will ideally accomplish two things: advance the action and provide moment-to-moment satisfaction. Settling for one or the other may be necessary at times. Doing neither is a test of the player’s goodwill.
In general, simulations can be a bit of a trap. They often present fun programming problems to solve, while they do not likewise guarantee an enjoyable player experience.
One problem with simulating driving is that most of us do it without thinking about it. It is not easy to simulate not paying attention to something by asking a player to pay attention to it.
Still, driving in non-IF video games is a widely enjoyed activity. We have Forza,Gran Turismo, and even the Grand Theft Auto games as examples. A key difference there is that driving is a major activity in those games, and significant development time has been invested in it. In IF, driving is usually just a flavorful way to bridge multiple geographic regions. The typical IF game is not concerned with driving in the way that those video games are. These are not driving games. That may be the gap. Perhaps an IF game with driving as a central mechanic/development focus could be quite compelling and interesting. & offer the rest of us a model!
Or has this already happened? If not, perhaps something parallel—piloting a spaceship, for instance—might be applicable.
This is a fantastic observation. I replayed Planetfall a number of years ago for nostalgia reasons and was surprised by the slow pace of the opening sequence—my memories of Floyd, the miniaturization sequence, and the, ah, aftermath of the biolab escape had blotted out the oddly leisurely opening of the game.
I think what you’re pressing up against is the divide between engineering and, for lack of a better word, creativity—engineering solves a defined or known problem, while creativity (sometimes) creates or discovers problems that the artist must sloppily solve to reach a desired endpoint. If there was a “standard” cut-scene procedure, someone would make an extension for it.
I think the Planetfall opening is the opposite of a player-controlled driving sequence. The protagonist can die immediately, and lots of first time players will. This establishes stakes, yes, but also creates friction between the player’s lack of agency (the protagonist is categorically not driving) and those stakes. This becomes all the more interesting when the player realizes that they may not land on solid ground…
transcript follows
*Planetfall Pod Escape*
A massive explosion rocks the ship. Echoes from the explosion resound deafeningly down the halls. The door to port slides open.
port
Escape Pod
This is one of the Feinstein’s primary escape pods, for use in extreme emergencies. A mass of safety webbing, large enough to hold several dozen people, fills half the pod. The controls are entirely automated. The bulkhead leading out is open.
The ship shakes again. You hear, from close by, the sounds of emergency bulkheads closing.
enter web
You are now safely cushioned within the web.
The pod door clangs shut as heavy explosions continue to buffet the Feinstein.
z
Time passes…
You feel the pod begin to slide down its ejection tube as explosions shake the mother ship.
z
Time passes…
Through the viewport of the pod you see the Feinstein dwindle as you head away. Bursts of light dot its hull. Suddenly, a huge explosion blows the Feinstein into tiny pieces, sending the escape pod tumbling away!
As the escape pod tumbles away from the former location of the Feinstein, its gyroscopes whine. The pod slowly stops tumbling. Lights on the control panel blink furiously as the autopilot searches for a reasonable destination.
examine window
I see nothing special about the window.
The auxiliary rockets fire briefly, and a nearby planet swings into view through the port. It appears to be almost entirely ocean, with just a few visible islands and an unusually small polar ice cap. A moment later, the system’s sun swings into view, and the viewport polarizes into a featureless black rectangle.
z
Time passes…
The main thrusters fire a long, gentle burst. A monotonic voice issues from the control panel. “Approaching planet…human-habitable.”
z
Time passes…
z
Time passes…
z
Time passes…
examine viewport
I see nothing special about the window.
The pod is buffeted as it enters the planet’s atmosphere.
z
Time passes…
You feel the temperature begin to rise, and the pod’s climate control system roars as it labors to compensate.
z
Time passes…
The viewport suddenly becomes transparent again, giving you a view of endless ocean below. The lights on the control panel flash madly as the pod’s computer searches for a suitable landing site. The thrusters fire long and hard, slowing the pod’s descent.
z
Time passes…
The pod is now approaching the closer of a pair of islands. It appears to be surrounded by sheer cliffs rising from the water, and is topped by a wide plateau. The plateau seems to be covered by a sprawling complex of buildings.
z
Time passes…
The pod lands with a thud. Through the viewport you can see a rocky cleft and some water below. The pod rocks gently back and forth as if it was precariously balanced. A previously unseen panel slides open, revealing some emergency provisions, including a survival kit and a towel.
I think that the scene explicitly benefits from the player’s lack of control. I might even call the waiting anticipatory, if not interesting.
In the sense that the player isn’t directly piloting the escape pod, yeah. But not in the sense that the player is still in control of the interface, if that distinction makes sense.
I think the real sense of urgency/danger/whatever that the sequence produces, if any, comes from the fact that the game doesn’t take the player away from the parser. You’re still get a prompt every turn, even if there isn’t much to do. Without that, there would be no sense of danger, because most players will realize, consciously or unconsciously, that the game isn’t going to kill them in a non-interactive cutscene/intro paragraph…or I guess if it does happen, then it’s unavoidable/required to advance.
That’s my point. You need some level of interactivity, even if it’s minimal, to “sell” the idea that there are stakes.
And while I’m not writing anything involving exploding space ships or escape pods, I think the same basic value proposition holds in more or less any situation in a parser-based game: you have to keep giving the player a prompt, even a placebo one, if you want them to worry about anything.
Personally, a limited simulation is the better way to a good narration.
Driving a car thru a quiet, peaceful neighborhood can be a potent vector for showing what is at stake, for example. Then after reaching the destination, all hell broke loose… but the travel ought to be a short one, three-four turns maximum.
side point, I’m currently doing the finishing touches to a little masterpiece: a sequence with a quick, narrativist, one-turn solution, and a long, 7-8 turns, simulationist solution. (not driving-related, suffice to say that is about a natural but controversial activity, and in my designing, allow to probe the player’s stance about the controversial; basically, people whose don’t like doing that can get rid of the issue in a move, and people whose can appreciate the intimist side of the controversial issue can enjoy the sequence)
I don’t entirely agree, because there were vehicles in Zork, which codified things like prepositions and indirect objects and giving commands to NPCs. All of those are quite common in modern IF.
Maybe? I don’t feel like sequences like the rubber raft bit or the balloon bit are super common, but yeah I think they’re absolutely part of the inspiration for how Vehicle is handled in e.g. TADS3.
My point is that all (parser-based) IF authoring systems seem to be very good at handling things like moving around rooms using the canonical direction commands, picking up small objects, and examining things. Which are the core gameplay of IF games going back to the first IF games. And they’re not that good at handling lots of other things, even things that are common in everyday life, like talking to people and driving/riding in vehicles. Part of this is of course the underlying technical complexity of the different kinds of interactions. But I also think there’s a sort of implicit understanding about the “scope” of what’s expected in an IF game. Where I put “scope” in scare quotes because I don’t think it’s a hard limit or anything like that, just that some things (wandering around and picking up small objects) are very much considered expected core gameplay elements, whereas things like vehicular travel and conversations with NPCs aren’t exactly unheard of, but they are in no way as intrinsically a part of IF gameplay as >N and >GET LAMP are.
Like if you look at Cloak of Darkness, which is (intentionally) a sort of reductio ad absurdum of IF game design, you have environmental puzzles and inventory items and basic navigation but you don’t have NPCs or vehicles.
Nearly every IF project I have in progress uses vehicular operation as a core mechanic.
As long as I can get my ADHD in check, I’ll have something to show for it.
But trust me: It’s a viable idea. Frankly, it’s untapped potential, which I’m surprised hasn’t become its own subgenre.
I feel like anyone who has played the BattleTech boardgame would start connecting dots about how different kinds of vehicle operation could be really fun, even in a text-based, turn-based, no-combat setting.
Right now, I’ve been test-driving (eheheh) everything from submarines to orbital ships to tanks to airplanes to cars to surreal-realm transports, all in an IF environment.
I love IF and I love vehicles.
It absolutely requires some trickery, sanding, and careful simulation, but it can be done, and it can be fun.