Hi all, this is the continuing story of me working on my WIP for an upcoming comp.
I lean towards “learning” to play the game by letting the player figuring out mundane things at first, and then, once accomplished, automate it for smoothing out the gameplay. Basically trying to find a “right” level (or “middle ground”) between going full manual (if Inform7 still does) and full auto (using e.g. Locksmith by Emily Short). The below is an example of a specific scenario, but I have others which are specific to my game. I am looking for generics here.
full manual
>n
The door is locked.
>open satchel
You open the satchel, revealing a key.
>take key
You take the key.
>unlock door
You unlock the door.
>n
The door is closed.
>open door
You open the door.
>n
full auto
>n
You open the satchel, revealing a key.
You take the key.
You unlock the door.
You open the door.
So basically, once the player did the manual procedure once, the next time the player encounters the same scenario, the game will do the steps on behalf of the player.
This is an interesting approach. Since I’m new to IF and haven’t published any interactive fiction yet, my opinion should be taken with a grain of salt. Additionally, my IF knowledge is limited compared to many users here. Personally, I’m also not inclined to impose tedious gameplay on the player, where every action has to be broken down—even the first time, when the action is obvious—as if their character were a puppet devoid of any autonomous logic. It’s not very fun, and it would be even less so with the stories I envision, which include puzzles, secrets, and all those enjoyable elements, but at the level of the overall story or key narrative arcs. Like you, I chose a two-level system, though structured differently: most of the time, obvious and intermediate tasks are automated as much as possible (as far as my still-improving coding skills allow); however, when the character encounters a real puzzle (like disarming a trap, opening a secret passage, or starting the aliens’ shuttle) in their world—which is fictional to us—the player must perform a logical, sequenced set of actions (and in this case, what you’re suggesting could also apply - to identical traps or the same shuttle models, for example).
Agreed. Maybe the example I exposed above was misleading. Door unlocking and opening I will probably leave fully automated (using Emily Short’s extension), but for puzzly things I do want the player to do the work at least once.
Another example (probably just as bad, but I cannot resist to poke fun sometimes):
Hanoi Room
You see three wooden poles. On the first pole are a large disc,
a medium disc, and a small disc.
On the wall hangs a proclamation.
R unfolds a little folding chair, puts it on the floor, and takes a seat.
He grins evilly, says "I am pretty sure you can figure this one out.
Wake me when you are done!", and promptly falls asleep.
>get disc
You take the small disc from the first pole.
>put disc on third pole
You put the small disc on the third pole.
: etc
Second encounter:
Another Hanoi Room
You see three wooden poles. On the first pole are a very large disc,
a large disc, a medium disc, and a small disc.
On the wall hangs a proclamation.
R unfolds a little folding chair, puts it on the floor, and takes a seat.
He grins evilly, says "You know the drill. Wake me when you are done!",
and promptly falls asleep.
>get disc
You take the small disc from the first pole.
You realize you have encountered this problem before.
You quickly move all discs in the proper order to the third pole.
: etc
Yes, that’s what I do as well. The accompanying narrative makes the story more cohesive.
Sorry, I just noticed that.
For now, though there’s certainly room for improvement with dedicated rulebooks, I keep a few truth states that switch to true once the player successfully completes a tricky, local puzzle sequence. I use check action-processing rules to speed up gameplay the second time around.
Check disarming a wolf trap when wolf-trap-experienced is true:
say "You deftly disarm the trap, your prior experience guiding you.";
It’s also an opportunity to teach the player new unlocked verbs (like to disarm, in this case).
Check disarming a wolf trap when wolf-trap-experienced is false:
say "How do you plan to go about it?" instead;
I think it’s a good idea, to be honest, but be careful that (and this is more a design thing): if you are making the game humorous, it works (maybe if you even more subvert expectations), but otherwise it can cause a sort of anticlimax once you’ve planned it all out. I’m not sure.
Don’t worry I will only try to automate the “boring” stuff. Otherwise I might as well go all the way and implement:
> win game
*** YOU HAVE WON ***
"Surely you have won," R comments.
"You truly feel victorious right now, don't you?
If not, you might consider UNDO..."
I think that asking questions like this is a sign that you need to rethink your game structure until the question is moot. Instead of automating away the mundane manipulations, find some in-world excuse to not have to do them in the first place. To pick a cliched example, instead of requiring that a maze be navigated several times, add a shortcut through a door which can only be unlocked from the far side.
I’m all for it. Perhaps some puzzles could be streamlined initially, but I like the power that comes from saying “oh hey I don’t have to do this again” or the thumbs-up a game gives me for going through the motions once, but only once. I’ve tried to do it with some of m own games.
The GO TO / GT verb seems to work well here.
One problem I see immediately is, the player might not know of this convenience at first. So you may want to start with a small 2-step puzzle and tell the player “Okay, if you want to do it again, you only need the first step. And this will be available in the future for longer puzzles, too.”
I wrote a whole game (Hadean Lands) that automated repeated tasks in exactly this way. People thought it was pretty good.
However, the gimmick of the game is a time loop – effectively a Groundhog Day scenario. The whole point is that you keep getting reset to the start state. So it makes sense that you encounter the same puzzle repeatedly.
But also, there’s always a new puzzle past that one. (Until the game ends!) The player wants to get past the earlier puzzles rapidly because they’re thinking about the later ones. So they don’t mind being an automaton for that segment.
Furthermore, there’s a design justification for the time loop. Some puzzles have multiple solutions, with different consequences. The player might want to retry and focus on a different solution for a specific puzzle. In fact they might want to quickly try several loops with different combinations of solutions. The autosolver mechanism makes this easy; the player is now working on a metapuzzle made up of the solutions of earlier puzzles. For this to work, each earlier puzzle has to be a one-command “macro”.
TLDR: Auto-solving can be a useful mechanism, but only if the entire game is designed to make auto-solving both necessary and interesting. In any other game, I simply wouldn’t make the player solve the same puzzle twice.
If you want to look at my implementation, the source code is here: Hadean Lands: The Source Code . Unfortunately, pulling it out and using it in a different game isn’t going to be easy. I didn’t try to make it generalizable. It’s also built for Inform7 6G60, which is a very old version – it certainly won’t compile as-is today.
@zarf First of all, thank you for your highly interesting feedback. I will definitely go and examine your code!
Your remark is insightful, and on this specific point, I’d like to clarify my thinking: some stories may present similar challenges to the characters in different locations, but the author may not necessarily know in advance in which order the player will explore the game world. Overcoming these similar challenges might require the same prerequisites: the right tool, the right information, the right method, the right secondary character, or a combination of all these and more.
My proposal is to unlock new macro actions that the player can then use—possibly automatically—when exploring other locations. Narratively, this is compelling in terms of immersion: the character learns, progresses, and integrates new ways of interacting with the game world. Of course, the key is also to present situations that seem similar if the player isn’t careful, but lead to failure, an altered outcome, or succeed but ultimately prove insufficient.
I’m guessing you have a specific reason for repeating puzzles? Otherwise there isn’t much point in having, say, two identical Towers of Hanoi, when only one is actually solved anyway. Make sure there’s a diegetic reason for repeating puzzles.
If it’s accessing the same place with a certain puzzle (e.g. tapping the right bricks to open the secret door), maybe the player keeps the secret door ajar so that they don’t have to reenter the code. Just find reasons to make the whole thing easier.
I think one principle might be that a game should not require repeat activities step-for-step unless they can replicate the wonder players feel when performing them the first time.
(though as with everything I’m sure there are exceptions)
We should probably distinguish between the replication of identical puzzles in the world model and the replication of puzzles in the player’s experience. When the character has the opportunity to learn new actions by solving a particular type of puzzle, that puzzle can be presented multiple times in the world model. Once the action is learned, the remaining puzzles are auto-solved, and the game skips directly to their outcome.
Example: the character is a fugitive wrongfully accused of embezzling public funds in a sci-fi universe, hunted by all the law enforcement agencies of the Galaxy. He knows nothing about the five main types of interstellar propulsion systems, yet the game will give him multiple opportunities, on various planets, to learn how to pilot these vehicles. We could imagine that once the Z-AR-Fire-3000 propulsion system (the best one in this game) is mastered through a puzzle, a new action is unlocked: set autopilot Z-AR-Fire-3000 to any planet.
Concur and agree: navigational tools and/or maps is one of the best tools for handling narrative pace (being the “key” for unlocking new section of the map) so your example should be in the toolbox of every IF (and CRPG) designer/coder…