Simulating a Parser in Twine? [split from The Art of Language Agnostic Design]

Why are you checking the VERB NOUN? Twine isn’t ScottKit. You don’t want to check the VN MATCH in Twine. You want to check the COND Variables.

My examples check the COND, instead of MATCH. Why are you checking the MATCH?

I thought you wanted all three…without the noun and verb it isn’t very parser-like, it’s just toggling variables, unless I am missing something.

I am not familiar with ScottKit. Does COND mean checking whether the door is open/closed then setting it to open/closed in this example? You could do that within the check passage too of course, more or less what you suggested above with $doorOpen.

So in the check page: <<if $verb eq "open" and $noun eq "door">><<set $doorOpen to true>>Now the door is open.<<endif>>

Then in the room page you would have the <<if $doorOpen... part that responds to that.

What are you talking about? I have all three. Just the order that’s different. Instead of ScottKit MATCH-COND-ACTION, Twine version is COND-MATCH-ACTION. You know, just like the examples show.

Checking the condition means that you don’t have to deal with bad inputs. Only good ones. You still have VN. “OPEN DOOR”. It’s there on the examples, see?

I just don’t know what to say.

I’m clearly missing something or coming at this from a different angle. Let’s leave it there.

Go simple!

if (COND) {
  link MATCH // click link to ...
  do ACTION // set variables and print some text
}

Harlowe?

(if: $doorOpen is false)[(link: OPEN DOOR)[(set: $doorOpen to true) You open the door.]]

3 posts were merged into an existing topic: The Art of Language Agnostic Design

A post was merged into an existing topic: The Art of Language Agnostic Design

Will a Twine user answer the very simple question of whether or not this works? And if not, any suggestion what will? It doesn’t matter whether it’s Harlowe or Sugarcube.

<<if not $doorOpen>>
    <<click "Open the Door">>
        <<set $doorOpen to true>>
        <<print "You open the door.">>
    <</click>>
<</if>>

I just don’t see what’s so difficult about a simple conditional clickable text that would cause so much confusion. Is conditional hyperlink actually impossible to do with Twine? Please help me because Twine doesn’t run on Raspberry Pi, which is the computer that I use. TIA.

PS: OK if you can do it with pure Javascript as well.

Edited to add print

I think I see what you are getting at now. This is for SugarCube.

You first have to set a variable in a passage titled StoryInit. Let’s make the door closed by default.

<<set $doorOpen to false>>

Now for the link… put this in your Start page:

<<link "Open the door">>
	<<if $doorOpen eq false>>
		<<set $doorOpen to true>>
	<<elseif $doorOpen eq true>>
		<<set $doorOpen to false>>
        <</if>>
<</link>>

Note that this alone with just swap the variable silently and endlessly. There are a lot of ways to update the passage—either by refreshing it, by going to a new passage, or by targeted replacement of a div.

Here is one way to make it refresh the current passage with ‘goto’ then print the $doorOpen variable. It replaces the Start passage above.


<<link "Open the door">>
	<<if $doorOpen eq false>>
		<<set $doorOpen to true>>
	<<elseif $doorOpen eq true>>
		<<set $doorOpen to false>>
    <</if>>
<<set $this to passage()>>
<<goto $this>>
<</link>>


<<if $doorOpen eq true>>The door is open/You open the door.<<else>>The door is closed.<<endif>>
1 Like

2 posts were merged into an existing topic: The Art of Language Agnostic Design

Various examples of Language Agnostic Design as presented from previous posts.

1 Like

A post was merged into an existing topic: The Art of Language Agnostic Design

You may want to note in the original post that this thread is about implementing a Parser for a specific Twine story format, and not for Twine story formats in general, as all the examples are SugarCube based and each Twine story format has its own level of JavaScript support.

eg. Harlowe has been deliberately designed to restrict an Author’s ability to use JavaScript to enhance the core features of its engine, or those of a project based on it.

1 Like

Feel free to add Harlowe examples, or others you like. Whatever you want, buddy. Do it with Python, if you like. No one is stopping you.

As I stated, Harlowe doesn’t support using JavaScript to enhance a project, as it has no documented JavaScript API to access the internals of its engine. It also doesn’t allow using Standard JavaScript object methods (1) for value data-types like String, Number, Array or Data-map within its macro calls.

Any implementation would need to be Macros only code.

  1. unless called within a HTML <script> element, and only on values accessible within said element.
1 Like

So I had a quick go at a Twine parser in Sugarcube based on the door example with three verbs; ‘look’, ‘open’ and ‘close’. This is how I would go about forming a skeleton that a real parser could be built around:

First is the main passage. This has the array ‘$objects’ that contains all the the information for the door. In a real project this ought to go in the ‘storyInit’ passage but I stuck to using just two passages total for this example:

:: Door Sim

<<silently>>

<<set $roomDescription = "You are in some kind of room. There is a door here.">>

<<set $objects = [{
	name: "door",
	description: "It's a door. The door is closed.",
	status: "closed",
	onOpen: {
		commentPos: "You open the door.",
		commentFail: "The door is already open.",
		posStatus: "closed",
		exec: '<<set $objects[0].description = "Thanks to you the door is now open.">><<set $objects[0].status = "open">>'
		},
	onClose: {
		commentPos: "You close the door.",
		commentFail: "The door is already closed.",
		posStatus: "open",
		exec:
			'<<set $objects[0].description = "Due to your heroic efforts the door is currently closed.">><<set $objects[0].status = "closed">>'
		}
}]>>

<</silently>>\
\
TWINEPARSER DOOR SIM 2022

$roomDescription

<span id="input"><<textbox "_input" "">> <<link "ENTER">><<parseInput>><</link>></span>

<div id="output"></div>

Then for the ‘parseInput’ widget (in a separate ‘widget’ tagged passage):

<<widget "parseInput">>

<<set _inputArr = _input.split(" ")>>
<<if _inputArr[0] == "help">>
	<<set _returnComment = "Valid verbs are: 'look', 'open', 'close'">>
<<elseif _inputArr[0] == "look">>
	<<if _inputArr.length == 1>>
		<<set _returnComment = $roomDescription>>
	<<else>>
		<<set _returnComment = "You can't see a " + _inputArr[1] + " in this room.">>
		<<for _i = 0; _i < $objects.length; _i++>>
			<<if _inputArr[1] == $objects[_i].name>>
				<<set _returnComment = $objects[_i].description>>
				<<break>>
			<</if>>
		<</for>>
	<</if>>
<<elseif _inputArr[0] == "open">>
	<<set _returnComment = "You can't open that!">>
	<<for _i = 0; _i < $objects.length; _i++>>
		<<if _inputArr[1] == $objects[_i].name>>
			<<if $objects[_i].status == $objects[_i].onOpen.posStatus>>
				<<print $objects[_i].onOpen.exec>>
				<<set _returnComment = $objects[_i].onOpen.commentPos>>
			<<else>>
				<<set _returnComment = $objects[_i].onOpen.commentFail>>
			<</if>>
			<<break>>
		<</if>>
	<</for>>
<<elseif _inputArr[0] == "close">>
	<<set _returnComment = "You can't close that!">>
	<<for _i = 0; _i < $objects.length; _i++>>
		<<if _inputArr[1] == $objects[_i].name>>
			<<if $objects[_i].status == $objects[_i].onClose.posStatus>>
				<<print $objects[_i].onClose.exec>>
				<<set _returnComment = $objects[_i].onClose.commentPos>>
			<<else>>
				<<set _returnComment = $objects[_i].onClose.commentFail>>
			<</if>>
			<<break>>
		<</if>>
	<</for>>
<<else>>
	<<set _returnComment = "I don't understand '" + _inputArr[0] + "'.">>
<</if>>

<<append #output>>_returnComment<br><</append>>

<</widget>>

The ‘parseInput’ widget could be expanded to include more verbs, the ‘$objects’ array fleshed out accordingly and so on. The input box and output text display would need some work to make it resemble a traditional parser engine. It’s certainly doable.

3 Likes

This has much more to do with design ideas then concrete code, but I wonder if drop down menus to select different verbs and objects would be an elegant implementation of this (having objects appear in the menu once they’ve been mentioned so you always know what verbs and objects you can use but not know exactly what might work). I had mentioned the game Degrees of Lewdity in the original post on agnostic design and that was another thing I thought was interesting about it compared to an inform game, as during it’s “combat” encounters you can select in a drop down menu several different verbs for your different body parts to do.

I think a strength of this sort of approach is you can get the unique uses of verbs one might not expect exactly such as in inform. One example that just came to my head is having look as a very from the beginning,perhaps it’s usually just used to get more info about the location one is in, but then when in a room with a telescope you could then look at other rooms you aren’t in. So all of the possible choices are still presented to the player so they are never truly lost, but you can still have these sorts of puzzles or just dynamic usage of verbs.

Edit: Another thing to note with this aproach is that I believe this would follow the Match-Cond-Action format more so then Cond-Match-Action as you could have actions that do not match that the player can try. For example with the look example, trying to look at a room you aren’t in while not in a room with the telescope could be attempted by the player but result in a failure. But obviously if there is never a telescope in the game and thus never added to the menu the player can never try to use it, where as in parser games you could try to look through the telescope in any game even if the parser just yells at you (I don’t think this is a big difference but for some people with some designs this could be important).

Final edit I promise: Another thing that occured to me is that this can also be a great way to ease players in to new verbs, instead of having them all available at the beggining, new mechanics through verbs can be slowly added to the menu through the course of the game. Obviously some games will be fine having all the verbs available from the beginning but I could definitely see how this could be helpful in a puzzler for example where puzzles may start off very simple with only one or two verbs to use to solve them, and then slowly over the game more are added until at the end of the game you are using dozens of verbs to solve them.

3 Likes

Definitely. If you’ve played any Legend games, they had parser and elevator menus for verbs and nouns. Some people did complain the explicit list could be spoilery.

frederik-pohls-gateway_2

I’m also a huge fan of early SCUMM. Even though they were graphic adventures, you could construct a sentence clicking verbs and images in the picture or items from inventory. This led to some very satisfying haptic interaction, such as searching a dark screen for a light switch since the sentence would complete with whatever object the mouse was on, even if you couldn’t see it.

MV5BYjI0YzY1MTAtMDI4MC00NmM1LWI3ZWYtNTgzODQzZWFlZDVmXkEyXkFqcGdeQXVyMzY3NzA2NTY@.V1

Robin Johnson’s Gruescript is a similar hybrid.

I’ve always thought the ideal interface would be SCUMM-like but without pictures, where the player could click any word in the prose to create a sentence which would then be parsed.

I have played a game where there were no explicit links, but clicking any word would bring up either a authored “nothing to see here” message (perhaps the definition of the word, or a treatise on conjunctions) or interaction links for interesting words. It was unique because it discouraged lawnmowering. Any reference to a character would let you talk to them, clicking an noun might give a message for examine, or allow you to open a box or pick something up if it were allowed.

6 Likes

I think the slow introduction of objects and verbs over time can help with spoilers, the problem I think is balancing that with design philosophies such as fallouts, go anywhere any time kind of philosophy. So it becomes a matter of balancing the characters knowledge of locations, objects, people/creatures and the players. I think an example of an elegant solution in this regard is having places reachable through both exploration, and knowledge of the place. So for example a character who knows where Blue Hell Bar is could ask about it and could travel quickly to it such as through clicking GO TO then BLUE HELL BAR but then a player who’s character doesn’t know about the bar could still traverse to it because they know the directions they need to follow to get there (here you could also gate content by difficulty such as fallout where experienced players can still get there through skill but inexperienced players are dissuaded). I think with verbs this can balance can be less important since it’s possible to use verbs in a lot of interesting ways, the hurdle that immediately comes to mind is you can’t have some crazy verb thats only used to solve on puzzle in the sidebar but I think thats actually a good thing, in that verbs then need to be more generally applicable, so I guess what I would suggest is just having a smaller pool of very general verbs so you have an idea of what they should do most of the time, but they are general enough where you can create scenarios where they work slightly different to have the player think outside the box. (In the other thread an exmaple scenario was having the character swallow a key card to bypass a lock, including swallow as a verb and only using it here would stick out to the player but in a game where the eat verb was somewhat regularly used along with a few other verbs this then goes from a wacky puzzle that no one would probably think of in a parser, to a kind of spoiler option, to then being a unique way to use one of the verbs in your tool belt thats is thinking out of the box but isn’t as ridiculous).

Again I should state I have 0 experience coding in twine but I think this could be doable in it in a hybrid system of what I’ve mentioned before where one could instead select a verb from a drop down menu in the passage then click the object in the passage. (Not to say using twine instead would be better necessarily but just to bring it back to Twine). A problem I do see here though in this hybrid approach/ is that all interactable nouns have to be in the passage which would break the telescope example, or at the very least make it spoilery.

2 Likes

This might actually work in parser with a continuous scroll (no screen clearing except for major scene changes?) Though I can foresee if we want to ASK AUNT MATILDA ABOUT THE MYSTERIOUS COAT, one would have needed to open the closet to generate the text to know that there is a mysterious coat, and they may have to scroll three rooms back from where they encountered Aunt Matilda to click on the coat to complete their input!

That’s kind of the point where ideally you’d like the player to be able to type in MYSTERIOUS COAT if necessary, or at least have an inventory item “memory of the mysterious coat” to click on.

1 Like