For what it’s worth, I feel like this is less a weakness inherent to parsers, and more like an example of bad game design in general. This sort of situation could also show up in a visual game, too.
Also—and I don’t mean to put my whole autism on screen, but—most modern parser systems don’t (by default) allow for destructive objects actions unless the author specifically allows them to happen, usually on a per-object basis, which again means this would be a fault of game design.
There are a few games that soft-lock you because you left an item in a location that you cannot return to, but I feel like that is, again, a game design fault, and not really a parser fault.
Mind you, I have a small number of issues with the parser interface (despite having authored both a parser and a choice game), but if we’re poking at issues in something, I’d rather we be precise about it. Strawmen are unproductive.
I do get your overall point, though, about how choices implemented in a choice-based game can be written with much more direct planning and intent.
This is true. For example in Inform 7 the aforementioned plot-important greasy rag must be declared “edible” which is a normal thing the author would be aware of and an exception to the norm.
Where traps occur is when you’ve dutifully not declared the greasy rag as edible as a good author should, but then elsewhere in the game you implement a toilet and decide it’s fun to be able to put all the non-important bathroom props you’ve scattered in that room inside and be able to flush them down out of play into oblivion. In fact, this inspires a puzzle where you have to flush a scribbled note to be sure the Detective doesn’t locate it and pin you as a suspect.
If you’re a new author caught up in this, it’s so easy to not realize that this toilet-maw you’ve created gives the player a way to destroy every portable object in the game. It’s easy to think “of course the player won’t think to flush that very plot-important greasy rag”…but they will due to Parser’s Inherent Freedom to Do Anything™. Maybe the author wants to do this as a trollish “you should have known better!” moment, but proper Polite implementation specifies you do put limits on interactions that will break the game or set up a no-win scenario.
With experience you get a feel for this type of thing, But it can be initially difficult for a new author to sort of wrap their head around the chess game of multiple interacting systems and thinking five steps ahead of all the ways the cool stuff you implement can be used for accidental mayhem that breaks the game.
Kinda, although in DOOM you’re expecting to die at every turn. You can be smeared across the map by a stray rocket through no fault of your own except poor reflexes!
Yeah, I mentioned the edible shoe-rag as a ficticious example of different systems interacting. When I write games, I like to abstract away behaviour from individual objects through use of the class hierarchy etc. and the combinatorial explosion has made me miss certain constellations.
For a real example: I introduced a water region to make use of common backdrops. If you droped something in the water region it would sink to the room below, unless you happened to travel by boat. No problem here, since the player could dive to the bottom to retrieve their stuff. Half a year later in the writing process, I placed a new kind of location - a pier - into the water region to enable some backdrops you could see from there. You didn’t have to pick up or drop anything at the pier, you just had to get out of the boat. And so I missed the fact that there happened to be no location under the pier…
Anyway, that’s a bug, not a feature. I was, in my first post, actually referring to cruel design choices which are indeed not limited to parser games. They are, however, much easier to make in them through world model, expectations of freedom of action and tradition. And in fact, the aforementioned bug, too, arose out of my wish to enable the player to fool around with the simulation elements.
The biggest problem with writing parsers is anticipating everything the player will do, and trying to give them that latitude. It’s a total grind for an author, but it’s what makes parsers worth playing. When I wrote my first game and got it tested, I was shocked at the amount of sheer gruntwork-hours it took to close loopholes, implement everything, and generally make an interactive environment. When authors don’t spend the time, I kind of assume that they don’t like their game enough to do it (or that they’re newbies who didn’t get enough testing).
I’m an old-school player who made it through all the cruel games in the 80s and 90s, but today I will bounce right off a game that is cruel or that can zombify me.
It’s easy to accidentally be cruel, or to be lazy or inexperienced and fail to richly implement your game world in parsers. I don’t have any idea if choice-based authors experience this, or if the programs make it easy to clean up all your loose ends.
Too true. Although I’m happy to see that the cruel tradition is dying off, along with the excruciating level of nitpickiness/lack of implicit actions of the old-school model.
You don’t really have to do this for choice-based, but your choices should make sense story-wise. Like if the PC is meant to be very shy and reserved, having choices where they behave very extraverted will seem weird (it could work, but it would probably raise an eyebrow).
Another implementation issue is to have the choice be of a certain tone/vibe but the response following the choice be of a completely different kind.
Nah… the amount of time I’ve lose track of variations is… a lot.
Debatable. If you’re going to stop the player from flushing anything down the pipe except the incriminating piece of evidence, with a message like “Better not, you might still need that,” you might as well do away with the freedom to input these forbidden actions. Following along this line of thinking about game design, fairness and difficulty, you would want to tip off the player earlier on about the possibility of flushing something down the loo, so they know what to do with the evidence during the timed sequence later on. Doing this, you’re not going to hide the breadth of understood commands from the player, either. All of this begs the question why you should bother with a parser interface in the first place.
Well, there’s a big middle ground between allowing the player to take a zombifying action and giving away a puzzle. Good puzzle design is hard to implement well precisely because of the need to strike this balance, but quite a few authors manage to do it beautifully.
I bother because I enjoy the challenge of trying to do it well. Only a handful of people will play it, but there’s not exactly a concerted effort going on to bring more people into the fold. I love playing parser games and since I’ve been authoring them, I have a far better appreciation for authors who do it very well. Again, either an author is making the parser interface work with their story, or they’re not, and there have been times that it’s clear-- in my own work as well as others’-- that a choice interface would work better for a particular game.
If we were all beholden to our investors and our bosses, we’d all have all the programs in our toolkits and would think more critically about what format works best. But we’re largely amateurs having fun and trying to amuse each other, which is why most of us do it, I think.
The way I see it, parsers are more game-y while choice based wants you to get through the story. You’re not really going to find lock-and-key puzzles or big room investigations in choice-based.
The choices are how the gameplay lives or dies, so if you get five in a row that are on the same level of importance as “which brand of cat food do you buy,” (or worse, your selections being completely ignored,) it makes you wonder why the author felt it was necessary to make it a game rather than just publishing a full readable story without the padding.
Only very broadly speaking. There are excellent examples of both types of game in both types of input paradigm. I personally like gamey systems in parser games, but they are typically hard to master due in no small part to the command-line user interface. As AmandaB has pointed out above, the current trend is towards more accessible gameplay in parser games. Maybe not “click to continue”, but ideally still “works on first try”. This makes the player feel clever. And we all like to feel clever.
Disagree. If you create a custom rejection message for flushing, and the player tries to flush something else first, then this message indicates that flushing is a recognized action for this game. If an “I don’t understand that” message pops up, then the player has no reason to try flushing anything else, and they’ll completely miss the puzzle.
This assumes a parser interface. I was trying to make the point that abandoning the parser all together would potentially get this across quicker and in a more user-friendly fashion. In a graphical drag-and-drop interface, you could (for example) change the mouse cursor to a red X if this particular action is forbidden and to a green toilet bowl if it is allowed.
I don’t think that’s necessarily true, or at least it doesn’t have to be. The main thing about parsers is that by nature they obscure the available choices and a lot of the “gaminess” comes from poking at the world to figure out what you can and can’t interact with. Choice games have the interactive elements (links) front and center which does lend itself well to storytelling but doesn’t prevent you from implementing gameplay, especially if it’s turn or stat based.
I also believe that a successful story-based choice game relies heavily on the IKEA Effect to create player engagement, so while you need to have meaningful choices I don’t think that’s quite the same think as “significant”. That’s where I think the success of the Lady Thalia games comes from, to be honest – there’s a thousand tiny choices in each, most of which have little effect on the overall arc of the story. But the player gets feedback on them very quickly, sees how well or badly they’ve done on a heist, and feels like they have results proportionate to what they put in. But long term what you choose mostly affects your relationships with other characters and whether or not you get the best ending for Thalia herself, and very little about the plot changes. It’s some good game design sleight -of-hand and I’m very proud of it
Oh, in Twine you can definitely, e.g., fail to notice that a certain sequence of choices will lead to a combination of variables that will strand the player in a passage with no links out (because all the links are behind if-statements and the player hasn’t met the conditions for any of them to appear). That’s why having outside playtesters is so vital.
Well, yeah. Drag and drop interfaces are fun, too. That would be a way to do a game. But I’m not sure why there’s a perception that you simply can’t make something like a toilet puzzle work out in a parser game with some thought. The toilet doesn’t work until you find the plunger. Or until you turn the water on. You drop something in there and try to flush it and it doesn’t flush and ew, gross, it’s covered with toilet water now. You make it seem like there aren’t any options other than ruining puzzles or zombifying players or breaking mimesis. And I’ll grant you that there are a whole lot of parser games that don’t have thoughtful design. But there are also a lot of drag and drop or PNC games that don’t do that, either.
I feel like this needs clarification now, though I am surprised it does: I have no doubts about the possibility of building working, interesting, fair, user-friendly puzzles in parser games, since (and I hope this doesn’t come as a surprise) I have played through some scenes in some games which fit such a description and I have been trying myself to measure up to that standard as well when writing parser games.
I have, however, often wondered, as a player as well as an author, whether the effort put into this was worth it given the alternative to implement something without the involvement of the parser.
