In today’s episode of “There’s No Such Thing as a Stupid Question”, I’ll ask this:
I haven’t played nearly as much IF as 99% of most of the people here, so I was wondering: What is the difference between a story mode and a non-story mode in a parser game? I recently played “One King to Loot Them All” in this year’s IFComp, and it had a story mode which I made sure was turned on because, well, I like parser games that have a good story. But I didn’t try replaying with the mode off, so I don’t really know the difference (and I personally enjoyed the initial experience and have moved on to other games for now. There are so many!)
I noticed a comment in another thread which I lost track of, in which the person said they did not like story modes because they are more puzzle-oriented in their tastes. So clearly there’s a difference.
Also, is story mode an I7 thing in particular? I don’t see why other languages couldn’t replicate it, but is this a feature of the language?
Basically story mode is just that: telling the story of the game. But you can still enter commands to look around, and examine things etc. All story mode does at this point, is to “do the next thing” when you press the ENTER key without typing anything. I have seen players playing my game and occasionally switching to story mode to briefly let the game play itself when they got stuck.
Sorry to disappoint, but the story mode as I implemented it is not a standard feature of Inform7. It works for my IFComp entry because the player does not have complete freedom as is generally the case in parser games. The game is “story-forward”, driving the player onwards.
Prince Quisborne, also in IFComp and written in TADS, has a similar readthrough mode. I think the goal is to ensure that more people see more of the game, and for both I support the idea.
For both, like Onno said, hitting ENTER just puts in the next command automatically.
What I think is nice about it is that it’s less like playing the game and more like watching a youtube video of someone playing a game. But youtube videos, while great for video-based games, are kind of bad for parser games because your reading speed might differ from the video maker’s. So having this ‘press enter to continue’ for me hits exactly the same feel that watching a youtube gaming video does. For me, I’d only like to use such a mode to try out the beginning of a game I’m hesitant about or to speed through a game I likely wouldn’t have time or interest to play otherwise.
It is a nifty feature, and it’s probably not even that hard to implement? If you already have an exhaustive hint system in place, and therefore have all the cases for “and now player has to do X”, it should be easy to implement a “try doing X”?
It depends on the complexity of the game. In my current WIP I have a quest system, and a journal the player can consult on what tasks remain unresolved. But implementing a story mode raises the question: If the player has multiple things to do, which should I pick next? Maybe the player is in a certain location where it would be more sensible to pick a different “next action”. I do want to add it into my next game, but it requires some additional experimentation. Individual quest lines are usually linear (as most puzzles are), but when you combine things the number of options starts to grow…
An easy way out would be to create a list of commands as a walkthrough and save the game at the point the player leaves the “golden path”, and return to it when they want to resume the playthrough. But I am trying to go beyond that, and not jerk the player back to the point they left the walkthrough, when they explore and manipulate things in the world.
This is actually quite hilarious, because I didn’t know this and discovered that typing “enter” progressed the storyline in the game in many situations. I thought it was an implementation of the action “enter”, as in to enter something, which didn’t make sense for certain responses to the command. But the first time I used it, it made sense to use it in context, because the direction commands weren’t working as hoped and “enter” was an alternative. It’s almost dumb luck that I was using the story mode without understanding what it was.
It does make me wish, however, that the proper command to progress the storyline was given when using “enter”. More out of curiosity than dissatifaction, really.
Do you mean showing the command itself before showing its output? I considered doing this, but I much preferred the “text flow” when I string the texts together… it more or less reads like the original story I created before building the game. The only “jarring” pieces left are the room descriptions which pop up whenever the player changes location.
My version does this. I think Wade Clarke’s does, too. (e: and John Z! He gave me the idea in the first place).
E: there’s always room for different philosophies, but I didn’t want to disguise my parser game as a short story. Rhetorically, that’s not what I wrote. I want to help people experience my work–a parser game–with minimal friction while allowing them to experiment as much as they like (without messing up the walkthrough).
Yes, that’s what I meant. Honestly, since I didn’t know what “story mode” even meant, it probably would have confused me for a while with the way I blundered into using it. But now, with greater understanding, it does make me wonder.
As kind of an aside, especially for the sake of judging a game in under two hours, I’ve discovered I much prefer when the supplementary material for the game in the competition is a collection of hints as opposed to a collection of commands that need to be given in sequence. In another game whose name I won’t mention, I actually gave up because I was wandering around trying stuff and I clearly did everything out of order. I had no idea where to begin with the walkthrough from where I was, and didn’t feel like restarting the game. So I just quit.
.