I think you mean "A Story Format for making proper parser games" because the Twine application (1 or 2) itself has little to do what you want, except maybe needing an extra screen (or two) for defining the particular command set used for the story.
Yes, greyelf, that second comment was not meant to be taken seriously.
Story Format, a new port, a complete re-build... call it what you will. It would still be great to have a version of Twine that maintains the usability and customisation, but that's designed specifically for making parser text adventures.
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.
That's because CYOA games are boring. There are more interactive fiction models than CYOA or parser, and Twine can do more than CYOA. I don't consider my game to be CYOA for instance.
The problem with parser games relative to twine games is that the parser needs a lot more information than the twine games needs. A basic twine games needs very little to let you 'examine seal' or 'kill crow'. Parser games, on the other hand, need to know that your possible actions include 'examine' and 'kill', then they need to know that that location has a 'seal' and a 'crow'. Then it needs to know how to examine and kill each of them.
I should have a Java/AWT based parser from an old mud/adventure engine I wrote many years ago lying around. I'd originally written it as parser only, but then I'd expanded it to support hyperlinks in the text that would give you options to pick commands that it then put onto the command line for the parser to execute. Then, a couple of years ago, after I'd dusted it off, I found Twine... It's input was separate HTML passages for each room, but you might be able to adapt it into a Twine story format. I certainly don't have time.
Simpler (much simpler) might be to do something based on that style. Click on seal and you get a pop-up with 'Examine Seal' and 'Ignore it' as options. Click on Crow and you get a popup with 'Examine crow', 'Kill Crow' and 'Ignore it' as options. The SugarCube replace macro might be your friend here. You can also use the 'abbr' html tag to 'hide' more detailed descriptions of objects - your have to hover your mouse over it to see the expanded text.
If you want a parser subsystem you're going to need structures to hold objects by location (assume you can have multiple twine passages in the same parser location) and to determine the effect of any action you take against them.
Simpler (much simpler) might be to do something based on that style. Click on seal and you get a pop-up with 'Examine Seal' and 'Ignore it' as options. Click on Crow and you get a popup with 'Examine crow', 'Kill Crow' and 'Ignore it' as options. The SugarCube replace macro might be your friend here. You can also use the 'abbr' html tag to 'hide' more detailed descriptions of objects - your have to hover your mouse over it to see the expanded text.
..../quote]
It is possible to do something like this with collapsible 'links'. it doesn't actually popup though.
It does reveal links and a description if you want to do it this way.
The first stylesheet code is just for styling and setting the 'hidden' link apart, but the point is it allows you to hide content, and show content. This is all I know how to do so far with this macro - toggleclass. I recently learned about it. And this is for Sugarcube 2.12.0 and Twine 2.0.11 btw.
For Harlowe - sorry, I don't know how to do it. I'm primarily a Sugarcube coder. lol.
I'm obviously still not making myself clear on this.
I appreciate it's only my opinion, but none of these suggestions would work - they're not even a compromise as far as I'm concerned.
Yes, Twine can do far far more that give players the option to either turn off the alarm and go back to sleep or get out of bed, but however you dress your Twine game up it's never going to look or behave like a traditional text adventure.
The text adventures to which I refer have a block of text describing your location/situation (no hyperlinks, regardless of how cleverly they scripted or what they do) and then a flashing cursor on the line below. You read the text, decide what you want to do and type it in with your keyboard using your fingertips before pressing Enter to get a response.
I think by the point that you finished altering Twine to function as a parser game, you'd be dealing with a different piece of software. Sure, there's probably a way to get it to do that, but it strikes me as trying to use a tool for something it wasn't designed for. Not that that's necessarily a bad or unworkable idea-- I think it'd be swell if Twine had a story format that did what you describe-- but there are already other programs designed specifically for the purpose that would probably be easier to start with.
The usability of and customization possible in Twine are a great reason to use it, but I think they aren't the best reason to use it to make parser games. You've probably heard of it already, but there's this program designed expressly for creating traditional room-and-object parser games called Inform 7, which I'd recommend if you're trying to make something with a parser. I've tried it, and my impression of it was that it was extremely good at what it did. That narrowed focus does come at a cost: in a system designed to simulate a series of rooms containing objects, trying to create elements of the game that don't fit the paradigm in which it was designed (i.e., things that aren't rooms or objects) was increasingly frustrating, and I eventually decided that it wasn't the right tool to use for what I was trying to create. But it'd be just the thing for a parser game.
So, basically, I'd recommend using the tool best suited to whatever you're trying to create. If that's something with hyperlinks, timers, and changing CSS, trying to Macgyver it into Inform 7 will be a nightmare. If it's a parser game, Twine will likewise be a headache to use.
So, basically, I'd recommend using the tool best suited to whatever you're trying to create. If that's something with hyperlinks, timers, and changing CSS, trying to Macgyver it into Inform 7 will be a nightmare. If it's a parser game, Twine will likewise be a headache to use.
I've avoided Inform because I've heard its language has quite a steep learning curve, and there doesn't seem to be much scope on the customisation front. ADRIFT is another and has virtually no customisation options.
For these reasons I use Quest, but like all other authoring systems it has its bugs and failings. That said it's the best I've found for parser text adventures.
I just happen to think Twine is quite something. The forum help is second to none and the system seems very stable indeed and largely free of bugs. I love that it creates games in html and a Story Format, or even a brand new system, for creating parser games would be great.
I know what you're saying and respect the valid opinion. I just think the inquest is too narrow.
When I say "parser-style" I think of how to innovate with mechanics to fuse the best advantages of parser and click.
For example, I can think of click games that are more complex and require more intellectual thought than any parser game. I like to think how to achieve that goal within the constraints of clicks.
Imo, parsers are just good at hiding their railroading. They don't often try to foster emergent gameplay more common to click-based strategy games. Every solution was already pre-determined.
So maybe a smaller parser would be easier to make in twine. Eg have most of the game as clicks, but have a parser for puzzles. So you merge advantages of both systems. Just an example.
Personally I think using parser for basic commands like go north is horrid. There seems no valid reason to not just bind it to a shortcut key.
I apologize for naivety on this subject. I'm very new to programming in general. But, in Harlowe, couldn't you use the (prompt:) command to some effect?
Comments
I believe you are grossly underestimating the amount of work required to implement what you are asking for.
Story Format, a new port, a complete re-build... call it what you will. It would still be great to have a version of Twine that maintains the usability and customisation, but that's designed specifically for making parser text adventures.
That's because CYOA games are boring. There are more interactive fiction models than CYOA or parser, and Twine can do more than CYOA. I don't consider my game to be CYOA for instance.
I should have a Java/AWT based parser from an old mud/adventure engine I wrote many years ago lying around. I'd originally written it as parser only, but then I'd expanded it to support hyperlinks in the text that would give you options to pick commands that it then put onto the command line for the parser to execute. Then, a couple of years ago, after I'd dusted it off, I found Twine... It's input was separate HTML passages for each room, but you might be able to adapt it into a Twine story format. I certainly don't have time.
Simpler (much simpler) might be to do something based on that style. Click on seal and you get a pop-up with 'Examine Seal' and 'Ignore it' as options. Click on Crow and you get a popup with 'Examine crow', 'Kill Crow' and 'Ignore it' as options. The SugarCube replace macro might be your friend here. You can also use the 'abbr' html tag to 'hide' more detailed descriptions of objects - your have to hover your mouse over it to see the expanded text.
If you want a parser subsystem you're going to need structures to hold objects by location (assume you can have multiple twine passages in the same parser location) and to determine the effect of any action you take against them.
I appreciate it's only my opinion, but none of these suggestions would work - they're not even a compromise as far as I'm concerned.
Yes, Twine can do far far more that give players the option to either turn off the alarm and go back to sleep or get out of bed, but however you dress your Twine game up it's never going to look or behave like a traditional text adventure.
The text adventures to which I refer have a block of text describing your location/situation (no hyperlinks, regardless of how cleverly they scripted or what they do) and then a flashing cursor on the line below. You read the text, decide what you want to do and type it in with your keyboard using your fingertips before pressing Enter to get a response.
There's no links, no sub-menus.
It's clear now that Twine can't do that.
The usability of and customization possible in Twine are a great reason to use it, but I think they aren't the best reason to use it to make parser games. You've probably heard of it already, but there's this program designed expressly for creating traditional room-and-object parser games called Inform 7, which I'd recommend if you're trying to make something with a parser. I've tried it, and my impression of it was that it was extremely good at what it did. That narrowed focus does come at a cost: in a system designed to simulate a series of rooms containing objects, trying to create elements of the game that don't fit the paradigm in which it was designed (i.e., things that aren't rooms or objects) was increasingly frustrating, and I eventually decided that it wasn't the right tool to use for what I was trying to create. But it'd be just the thing for a parser game.
So, basically, I'd recommend using the tool best suited to whatever you're trying to create. If that's something with hyperlinks, timers, and changing CSS, trying to Macgyver it into Inform 7 will be a nightmare. If it's a parser game, Twine will likewise be a headache to use.
For these reasons I use Quest, but like all other authoring systems it has its bugs and failings. That said it's the best I've found for parser text adventures.
I just happen to think Twine is quite something. The forum help is second to none and the system seems very stable indeed and largely free of bugs. I love that it creates games in html and a Story Format, or even a brand new system, for creating parser games would be great.
When I say "parser-style" I think of how to innovate with mechanics to fuse the best advantages of parser and click.
For example, I can think of click games that are more complex and require more intellectual thought than any parser game. I like to think how to achieve that goal within the constraints of clicks.
Imo, parsers are just good at hiding their railroading. They don't often try to foster emergent gameplay more common to click-based strategy games. Every solution was already pre-determined.
Personally I think using parser for basic commands like go north is horrid. There seems no valid reason to not just bind it to a shortcut key.
For me, it's not a text adventure unless I'm typing things like n, get key, open door.