Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Is it possible to make a "parser-style" game using Twine?

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

«1

Comments

  • I believe the simple answer about the parser is: No.

    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.
  • Thank you! This is pretty much what I had thought but since I'm not very well versed in any of this I thought I would present the question in case there was something I'd missed. I will look over the reddit thread and see if it's something I can wrap my brain around. At a glance it looks intriguing.

    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!
  • edited July 2016
    Hmmm. Links change color on a mouse over. Might be a way of hiding them. Of course, once folks work that out they'll just scan the mouse over all your descriptions and see what lights up.

    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).
  • edited July 2016
    greyelf wrote: »
    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.

    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:
    hidden a {	
    text-decoration: none !important;
    	font-weight: normal !important;
    	cursor: default, auto !important;
    }
    

    in your passage:
    <span id="hidden">[[table]]</span>.
    

    Then in the table passage you'd write:
    "This is a table."
    
    <<back>>
    

    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
    <<set $table to "brown">>
    <span id="hidden">[[table]]</span>.
    
    
    :table passage
    <<if $table is "brown">>This is a brown table.<<elseif $table is "black">>This is a black table.<</if>>
    
    <<back>>
    
    
    
  • Claretta wrote: »
    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.
    I did not try to 'discourage' the OP from hiding the links, I even suggested a possible means of doing so. I did ask them to think about the possible downsides when they make their decision on how they want to implement the features of their story.
  • edited July 2016
    I know, you didn't really discourage them. :)

    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.
  • edited July 2016
    I'm working on a parser-based system right now. No link-hiding, but I'm exploiting the click: function's ability to contextually create links in order to make the right words clickable when you have a certain action selected. I kind of like this way of doing it.
  • Here's my proof of concept; at the moment, I'm working on making the mechanics more solid for a larger game.
  • edited December 2016
    @Legba I appreciate the work that's gone into that game, but it simply isn't parser-based. The links might be more geared to the type of thing that's typed in parser adventures, but you're still only clicking links.

    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're in a forest. A house lies to the east
    You'd say:
    You're in a forest. A house lies to the east
    And then somehow account for the player typing e or east with a text input.
  • Jud_Casper wrote: »
    What I'm struggling to understand is why there's so much debate about hiding links.
    I believe the OP wanted to have both a parser and links.

    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.
  • edited December 2016
    So is the general consensus still saying that a linkless, traditional parser text adventure can't be done in Twine?
  • Accessibility should be available to anyone, no matter what. After all, you want everyone to enjoy your games, right? :)
  • Not sure if that statement is directly addressing my own, Gryphbear. If so, I'm not sure what you're saying. I just want to know if I can make a parser game in Twine :)
  • @Jud_Casper Sorry - that was to greyelf's comment on Accessibility. lol.
  • Jud_Casper wrote: »
    So is the general consensus still saying that a linkless, traditional parser text adventure can't be done in Twine?
    It can be done but you need to either build your own command parser or adapt an existing one to work with Twine, and neither of those are simple things to do.
  • edited December 2016
    greyelf wrote: »
    [...] and neither of those are simple things to do.
    Nothing ever is, is it? :(

    Ah well. Thanks anyway.

  • No coder myself, unfortunately, but I'd love to see a working parser for twine. Digging in the matter, I found an interesting discussion here and an example of a simple text-parser adventure game here

    Maybe somebody can adapt this for Twine.
  • edited December 2016
    richVIE, I think those are examples of coding a parser game from scratch - which if you're clever enough isn't a problem. The problem we have here is that Twine was never built to build parser text adventures.

    It's just that I got to wondering while messing about with the <<textbox>> macro, if one could be prised out of Twine.
  • edited December 2016
    Accessibility is a good thing but think the drive to accessibility goes way too far if it prevents certain game genres from being made.

    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
  • Claretta wrote: »
    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
    You're clearly aeons beyond the casual game creator, but from what I can gather from the article, the game still requires the player to click links and buttons?

    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.
  • edited December 2016
    I meant "parser style" in the sense of whether you can do the same sorts of puzzles. By the end of the game you have hundreds of reports in which to find the answer and that is no less apparent freedom than a parser puzzle.

    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.
  • Well I think that's a matter of opinion. While it's true to say traditional parser text adventures don't really give the player any more freedom, it does give that illusion when done well.

    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.
  • What's a parser?
  • edited December 2016
    Deadshot wrote: »
    What's a parser?
    Well that gives me a clue to your age.

    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.

  • Deadshot wrote: »
    What's a parser?
    In the context of a text based adventure game a parser is code that knows how to break down a statement like "put the red sword in the large chest" into something that the game's logic can understand.

    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:
    put %objects% in{side/to} %object2%
  • Well if you want to get technical, yes, but I was simply explaining what a parser-based text adventure was.
  • edited December 2016
    Sure, but I said "parser style" not "parser exactly". ;) I think the design goal should be to try and get the key advantages of parsers - lots of freedom, while modernising them to the Twine format.

    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.
  • Sorry, Claretta, that last post of mine was in reference to greyelf's.
  • edited December 2016
    I was replying to your reply to me. :)

    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.

    5rwqPWK.jpg

    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.
  • edited December 2016
    Claretta wrote: »
    I was replying to your reply to me. :)
    Ah, sorry. I was starting to get lost in here.
    Claretta wrote: »
    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.
    I think in truth, this is it. I grew up on traditional parser games and still maintain they encourage the player to think for themselves more.

    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.

Sign In or Register to comment.