Howdy, Stranger!

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

Using Twine as traditional input style text adventure.

edited December 2015 in Workshop
I appreciate this is not the type of text adventure Twine is designed to create, but would it be massively complicated to do so?

I'm referring to this type of affair:

You are in a forest. To the west lies a cabin, while a stream runs east.

>
|

(Where > is a flashing | waiting for an input?)

Comments

  • The main hurdle will be the text parser needed to convert the user input into commands your story engine understands, this thread on gamedev has some suggestions.

    I would suggest looking at some of the other environments which have a text parser built-in like: Inform, ADRIFT, TADS, etc
  • Thanks, greyelf. Your answer is sufficient enough to dissuade me. It was only a general query anyway, as I can always use Quest if I really want to create parser-based text adventures.
  • Yeah, I used to write those. Pain to write and frustrating to play (wear hat, don hat, put on hat, put hat on... ). Much easier for the player if you just put up a nice hyperlinked 'Try the hat on '.
  • edited December 2015
    mykael wrote: »
    Yeah, I used to write those. Pain to write and frustrating to play (wear hat, don hat, put on hat, put hat on... ). Much easier for the player if you just put up a nice hyperlinked 'Try the hat on '.
    I'm really torn on this debate. I grew up on parser-based text adventures, so may be a little biased towards them. I can certainly see the advantage of the multiple choice type, especially from a developer's side, but so often when I load one of these types of games up, I'm instantly bored. Just a wall of text with three or four words as hyperlinks. I look at it and my brain instantly says, "Oh, just press any of them, it doesn't make any difference anyway."

    Fair enough, that's probably the fault of the designer, but more often than not this is how I feel when I start to play them.

    That's why I'm trying to do something a little different with mine, by having very short location descriptions and never using any possessive pronouns (I, you, he).

    Parser-based games feel far more open to me. As a kid I used to love the thrill of discovering a command that did something to advance the game.
  • Hmmm. You might be able to use <<click>> coding to make something that lets you build up a command word by word. Nice thing is you don't have to parse it as it can make a tokenized version under the covers.
  • mykael wrote: »
    Hmmm. You might be able to use <<click>> coding to make something that lets you build up a command word by word. Nice thing is you don't have to parse it as it can make a tokenized version under the covers.
    Ahh, the good old days of early Graphical Adventures like Maniac Mansion and its click-able menu.

    Maniac_Mansion.png
  • mykael wrote: »
    Hmmm. You might be able to use <<click>> coding to make something that lets you build up a command word by word. Nice thing is you don't have to parse it as it can make a tokenized version under the covers.
    Not sure I follow. Could you elaborate, please.

  • Sorry about the "rejected answer" in the above post. I miss-clicked. Meant to quote.

    I was going to say that it won't be easy to create a game like Maniac Mansion or Shadowgate or whatever.

    Twine was really meant to make Web-based Choose Your Own Adventure or Lone Wolf-style game books.

    You could make Twine do anything, of course. You could write a side-scrolling Mario Bros. clone if you wanted. But that's not what it was designed to do.
  • Jud_Casper wrote: »
    Not sure I follow. Could you elaborate, please.
    As shown in the image I linked to.
    You display some possible options on the screen, the reader clicks on one of the options which either results in more options being shown or executes the option(s) already chosen if they equal a known command.

    eg, If the reader clicked on Read you could show a second set of options listing the items (if any) the reader knows about/is carrying that can be read. If the reader selects one of the items (say Dairy) then you would execute the Read Dairy command.
  • greyelf wrote: »
    As shown in the image I linked to.
    Ah, I get it now, although that's not really what I had in mind.
  • While not allowing completely freeform input, it does at least avoid giving obvious hints by printing them in highlight hypertext somewhere on the page. There's a balance in there somewhere between making it easy to build and play and not spoon feeding it to the player.

    I was thinking of something more along the lines of using click and replace to build up the link text at the bottom of the page. This would go to a dispatch room which would work out where you went next. Probably more work than it's worth though.
  • mykael wrote: »
    Probably more work than it's worth though.
    I suspect so, especially when there parser-based text adventure creators already out there.

Sign In or Register to comment.