The question in more detail: Is it possible to make a parser-style game, or something rather close, in Twine 2.0 without having to get pretty deep into code? My main goal is to obfuscate some of the possible path options on certain pages. Maybe I'm just not thinking "outside of the box" here but I'm an oldbie and my mind immediately goes to command line inputs like "examine <thing>" where "thing" could be anything notable in the text.
It could be in either Harlowe or SugarCube. I'm flexible at this point except for having some concern over my scripting skills.
I just really don't want to have to go to Inform for this project since the intended audience is people who wouldn't understand having to install an interpreter.
I hope this makes sense. I don't really have all the correct language for this sort of thing (yet). Ask me to build a MU* and I'd feel fairly comfortable but otherwise I've quite fallen behind on modern options. ^_^;
Thank you!
-coyohti
Comments
You could add a text-box within a footer and write very basic code to understand one/two word commands using basic IF/ELSE-IF/ELSE statements but then the Reader has to "guess" what those commands are and maybe even how you spelt the word (eg. colour vs color), but at the end of the day you are going to have to write some code.
I once was an Admin/Liege/Wizard on a number of different MU* and recently (briefly) thought about doing something like this in Twine, one explanation of how to possibly implement this that I found informative was this one on reddit which you may also like.
If you want to obfuscate ("hide") links within your passages then you could change the style of those links so that the look the same (or very similar) as/to the passage text BUT remember that some of your Readers may have vision issues which means that they may never be able to find those hidden links.
My alternate idea is to arrange some way to make a certain event occur at random (or not at all). The story/game I'm developing works even if the player never experiences the "easter egg" event. From my limited knowledge of Twine at the moment it seems that a random event could be within its scope - I just need to start researching!
Thank you for helping!
You could try adding lots of links that don't do anything special, to camouflage the link that does do something (but it's a lot of work).
You could give every room a 'search' option that takes a few seconds regardless of whether or not it reveals anything. The time delay is to discourage people from simply clicking it in every room they enter (and, maybe, bad things happen if they search in the wrong room).
You could say the same about any point and click game. There is an entire genre of games based around the hidden link mechanic - HOPA games. No one should be discouraged making in a genre just because the mechanics of that genre are not accessible to everyone. I support accessibility, but people should feel free to create in what genre they choose.
A Twine game with hidden links is essentially a textual point and click or HOPA game, therefore does not need to be held to the same accessibility concerns as a standard website.
The only caveat I have is that you'll need to make a tutorial on any hidden link mechanic, since people won't necessarily expect it in a Twine game. But without further ado, it's easy to do a "parser-like" click mechanic in SugarCube.
In css:
in your passage:
Then in the table passage you'd write:
So "table" does not show up as a link but when someone clicks on the word table they go to the Table description page and then can click the <<back>> link to return to the point they were at. Because of the <<back>> macro, you can link any number of random tables to this description if you desire.
Or you could do something slightly more fancy and in your main passage set some rule variables, eg
I just have felt discouraged in the past when I asked how to do things that didn't accord with current web standards. I just want people to realise it's ok to do things like link hiding, and disabling other web standards in a Twine game.
Still makes for interesting reading, but what I'm struggling to understand is why there's so much debate about hiding links. If it's a traditional parser text adventure, there wouldn't be any links. If you don't want links in your passage, don't wrap them in link, so instead of: You'd say: And then somehow account for the player typing e or east with a text input.
The debate was related to Accessibility and games, some (most?) developers don't see the need to support it which results in less games available for those effected to play.
Ah well. Thanks anyway.
Maybe somebody can adapt this for Twine.
It's just that I got to wondering while messing about with the <<textbox>> macro, if one could be prised out of Twine.
Otherwise, we'd have the entire genre of Guitar Hero games not being made, for example. They're not accessible on multiple counts.
Likewise, you shouldn't let accessibility concerns discourage you from making a particular game. The design vision should not be compromised. If parser games are not accessible for everyone, so be it.
That said, sometimes there are other ways around it. I do not use hidden links in my game anymore because I figured out a much better mechanic for making a parser style game in Twine. It's discussed in my game dev blog.
https://forums.thesecretworld.com/showthread.php?87285-The-Dreamers-Wake-A-strategy-puzzle-game&p=2025335&viewfull=1#post2025335
Doesn't parser - in the context of an adventure game - mean that the player types into a text box whatever command they see fit for the given situation, giving at least the illusion of much more freedom than one gets from CYOA games?
None of the examples in this thread, purporting to be parser games made with Twine, are what I consider parser text adventures.
Parsers don't offer unlimited freedom, just like other mechanics don't offer super limited choices.
I think if you can get the array of choice without being a parser it is a good thing, because parsers have significant UI drawbacks.
Traditional parsers have a good number of advantages over 'Click click' CYOA games. Puzzles are easier to implement, challenging games are easier to construct and above all there's no sense that the players' hand is being held. The illusion is that they're on their own and what they say and do is up to them.
Let's remember that the text adventure rebirth stems from those classics of the 80s, virtually all of which were parsers.
Parser, when talking about text adventures, is a little > symbol which sits below the descriptions and has a flashing cursor to indicate the player must input commands instead of clicking links, to progress through the game.
One way the above could be broken down is:
a. nouns (sword and chest)
b. verbs (put and into)
c. adjectives (red and large)
Another way could be to use pattern matching like ADRIFT does:
I mean, if parsers only give freedom when "done well" I can always just say that other mechanics give the same illusion of freedom when done well, too. It's just a question of implementation, not the mechanic per se. I've seen an awful lot of badly done parsers.
I just meant that instead of trying to simply replicate the parser, we can look at what game design objectives the parser solved, and try to solve them in our Twine game some other way. In doing so, we're implanting the "spirit" of a parser style game, so still a valid option when one wants a "parser style game in Twine". Just because it may not look like a parser game doesn't mean it isn't addressing the same gameplay goals.
I weighed in here because I actually designed my game as a parser game originally, so I kinda have experience in addressing the "parser or Twine?" question. But I discovered that anything the parser could do, click and keyboard mechanics could do better. If you want a game to have lots of freedom, I favour putting more effort into giving the player actual freedom with loads of choices, rather than only an illusion of freedom hiding railroad tracks.
Eg my first prototype. Looks much different today.
So in this first investigate mechanic, you had to enter the investigation clue into the parser. But I found another way to get as much apparent freedom with a click mechanic, with the bonus that it is a lot more accessible and fun to play. There are still wide-ranging and complex puzzles.
Of course, if you want a parser game because "I simply like parser games" that's a different issue entirely and a valid reason for implementing a parser. But imo, "more freedom" isn't a reason that holds up to sustained scrutiny. It quickly starts to fall down when the player begins to find that the game keeps denying their attempts to exercise freedom. Good parser games address this in various ways, but it requires a lot of work. That's work that I feel can be better put to implementing more valid choices in a click game, to attain a wider scope of choice freedom.
Twine is, in my opinion, the best authoring system available, but I'm not a massive fan of CYOA. I played them in book form and absolutely loved them, but a real text adventure for me is those where you type your commands, not click pre-defined ones.
Twine, for making proper parser games, would be wonderful. Hopefully TME can knock one together in a couple of hours.