intfiction.org

The Interactive Fiction Community Forum
It is currently Tue Aug 21, 2018 4:52 am

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 35 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
PostPosted: Wed Jul 02, 2014 12:16 am 
Offline

Joined: Tue May 04, 2010 3:47 pm
Posts: 20
Being a programmer who enjoys writing in his spare time, I've always wanted to give Interactive Fiction a go... the two parts of my brain don't like to intermingle, though. Every time I've sat down at the TADS workbench or Inform 7 IDE I've not been able to turn off my programmer switch and get into the actual story creation. It feels too much like programming.

When I write non-interactive fiction I use the awesome site Draft and do everything in Markdown. If you're not familiar with Markdown, it's basically a syntax for creating HTML in a much cleaner human-readable format (https://en.wikipedia.org/wiki/Markdown). Some time ago I got the idea that it would be awesome to be able to write interactive fiction the same way... Ficdown is the result.

It's basically a bunch of conventions added to Markdown that allow you to define a stateful IF game in a file that is itself a valid Markdown file. I've done a reasonably detailed write-up and tutorial here:

http://rdsm.ca/ficdown

All of the tutorial examples can be played using the (very alpha-stage) Javascript parser and play engine I wrote up, as well as a slightly longer (but still pretty lame) proof-of-concept game here:

http://if.sitosis.com/robot-king/

If you want to see what the raw Markdown for Robot King looks like, it's here: http://if.sitosis.com/robot-king/story.md. The javascript parser and play engine runs directly off of that file. I've also compiled the source Markdown into HTML if you want to see what that looks like: http://if.sitosis.com/robot-king/story.html (obviously none of the links will work, but it gives an idea of how pleasant and non-programmingish it can feel to build a game in this format).

I know there are already other scripting systems to achieve this kind of game, but I just really, really like Markdown and would prefer to use it instead of learning a different syntax like ChoiceScript. I also like the idea of being able to work on a game at any time over the web instead of being tied to a specific IDE or tool on my PC. It's also nice to be able to hit a preview button and have the Markdown rendered as HTML--it's much easier to proof read your scenes, actions, etc when all of the code cruft is removed and you're just left with your story in a nicely rendered format for reading.

I'd appreciate any feedback or comments. It's still at the proof-of-concept phase and the idea is quite young.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jul 02, 2014 3:44 am 
Offline
User avatar

Joined: Sun May 02, 2010 8:27 am
Posts: 232
Location: London
Interesting. I've been experimenting with something similar that uses Markdown, but the resulting scripts aren't valid Markdown themselves: https://github.com/textadventures/squiffy

I quite like the idea of using the syntax for headings to define scenes - it's something I don't think I've got quite right in Squiffy yet, as section/passage definitions are confusingly very similar to links themselves - but what if you didn't want an actual heading to appear at the top of a scene?

I wonder if the syntax for the "pick up key" example could be easier. Presumably this will be quite a common pattern. Also I'm not sure about redisplaying all the choices each time something like that happens. The way I'd do something like this in Squiffy would be to use the distinction I have between sections and passages - a passage for "pick up key" could set the flag, but all the rest of the choices from the text would still be clickable, so there's no need to redisplay anything.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jul 02, 2014 7:53 am 
Offline

Joined: Tue May 04, 2010 3:47 pm
Posts: 20
A scene that doesn't display a heading could be defined using an empty anchor title

Code:
## [Scene Name]("")


I have thought about way to potentially simplify the pick up key pattern... an obvious way would be to add some kind of shorthand to imply a state as both the conditional and the state toggle in an anchor, so something like

Code:
[Pick up key.](?#got-key)


that would automatically hide the link and set the toggle state once its clicked. As for not re-displaying everything once an action occurs, that's something that could easily be included as an option in the Javascript play engine once it's a bit more mature. For now I am rendering scenes as they would be rendered in a static-HTML or eBook representation of a story that was pre-compiled from a source file (since that's one of my goals with Ficdown).

Thanks for pointing me to your Squiffy project, I'll definitely take a closer look when I have time later today.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jul 02, 2014 9:59 am 
Offline

Joined: Sat Jan 23, 2010 4:56 pm
Posts: 5718
I like this approach. I guess my worry (without having tried the thing myself) is that you'd wind up needing more coding functionality than can be stuffed into the link-like syntax.

(When working on choice-based games, I almost always need "if-elseif-elseif-else" constructs. Or sometimes "switch-case" fits the problem better. ChoiceOf games tend to be organized around numeric stats, so you want "x=x+1.5" and so on.)

None of this is mandatory if you're keeping your design scope limited. What you *don't* want is to look back in a year and realize that you've invented yet another candy-ass scripting language.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jul 02, 2014 12:53 pm 
Offline
User avatar

Joined: Sun Dec 23, 2007 3:24 pm
Posts: 189
It's basically what I am doing with txt2tags there: http://anamnese.online.fr/site2/textall ... lue_death/
It's also possible to write in txt2tags and export to markdown and then to ficdown. Last but not least, txt2tags is very extendable, so you can also write in markdown (and probably use fictown sources) within my system: https://github.com/farvardin/whatistxt2tags


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jul 02, 2014 1:26 pm 
Offline

Joined: Tue May 04, 2010 3:47 pm
Posts: 20
The limited scope and lack of tacked-on scripting elements such as counters/numerical variables and more complicated conditional statements is definitely by design. I guess the vision I have for the format is to make it easy to write more traditional paperback-CYOA-style stories, but with enough state-tracking built in to allow a user's actions at any point to have an effect during any later part of the story (as opposed to just deciding what the next scene will be). The ability to move back to scenes you have already read is more of a byproduct of the linking mechanism than something I would expect the type of stories written in this format to use extensively--for example I don't really think it would be well suited to an Inform/TADS-style "open-world" game, where the player can freely move about a large map, revisiting and interacting with different scenes at their own leisure (though it could be used for such).

The limitation to simple boolean state variables, the lack of ability to toggle them to false once they've been set, and limiting conditional checks to conjunctions of positive values only are my attempts to artificially limit the potential scope of games in the hopes that even ones approaching a higher level of complexity could feasibly still be exported to a static hyperlinked format for conversion to stand-alone ebooks. Basically my motivation is that I really enjoy reading CYOA paperbacks with my kids, and would like to write my own that I could play with them on my Kindle, but want the ability to make stories with a little more depth where early decisions can have a longer-term impact later on (without having to manually create different decision-tree-paths for every choice made).

My big worry comes from the fact that, doing the math, with enough states and scenes and complexity it will always be possible to create stories that would simply be too large to be stored in a static format. For example, a hypothetical game with 20 different states and 100 different scenes, in which you could traverse to any of the 100 scenes at any point in the story, and for which the 20 different states could be toggled in any random order; Such a story would have to render each of the 100 scenes over a million times to accommodate each possible state combination (2^20), potentially doubled if each scene also has first-seen text, so that would be 200 million html files or ebook pages. That probably ain't gonna fit on my Kindle.

My hope is that the specification and its limitations will be enough that writing a story that complex would be a dog to manage and maintain, and instead encourages simpler games. Someone who wanted to write that game should probably be using a different authoring system anyway. A more reasonably written Ficdown game with 100 scenes and 20 state variables where the scenes flow together in a more linear fashion, where certain state combinations can be eliminated due to emergent dependencies between states, and where many of the states are limited to within specific portions of specific decision trees may very well compile to a more reasonable number of static files. I don't actually know yet, though. I'm not conversant enough in statistical analysis to figure that out... which is why my plan is to finish writing the compiler, write some stories, and see what happens.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jul 02, 2014 1:36 pm 
Offline

Joined: Tue May 04, 2010 3:47 pm
Posts: 20
farvardin wrote:
It's basically what I am doing with txt2tags there: http://anamnese.online.fr/site2/textall ... lue_death/
It's also possible to write in txt2tags and export to markdown and then to ficdown. Last but not least, txt2tags is very extendable, so you can also write in markdown (and probably use fictown sources) within my system: https://github.com/farvardin/whatistxt2tags


This does seem quite similar in its goals to Markdown. The one thing it seems to be missing that I'm using as part of the Ficdown spec is the ability to set the title tag on anchors. In Markdown you do this by adding the title in quotes after the href:

Code:
[Link text](/link/href "Link title")


I don't see anything analogous in the Txt2tags syntax.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jul 02, 2014 3:50 pm 
Offline
User avatar

Joined: Sun Dec 23, 2007 3:24 pm
Posts: 189
Quote:
The one thing it seems to be missing that I'm using as part of the Ficdown spec is the ability to set the title tag on anchors.


it's not in the official txt2tags syntax, but you can use regex to add personnalised markup, so you can do almost whatever your want with it. Another important thing which is missing is my system is the possibility to use flags (State Toggling). I understand some people may need this, for my part I'm more interested in classic CYOA adventures you can export to paper books or ebooks. But I know most ebooks readers have some kind of support for javascript so I guess it could be sensible to make it available one day.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Wed Jul 02, 2014 4:20 pm 
Offline

Joined: Sat Jan 23, 2010 4:56 pm
Posts: 5718
Quote:
My hope is that the specification and its limitations will be enough that writing a story that complex would be a dog to manage and maintain, and instead encourages simpler games.


Someone will always be stubborn enough to try. :) As long as the processing tool prominently displays the number of generated pages, and you have a notion of what "too many for a Kindle" means, users can self-regulate.


Top
 Profile Send private message  
Reply with quote  
PostPosted: Tue Sep 23, 2014 10:54 am 
Offline

Joined: Sat Apr 23, 2011 3:53 pm
Posts: 61
Rudism wrote:
A more reasonably written Ficdown game with 100 scenes and 20 state variables where the scenes flow together in a more linear fashion, where certain state combinations can be eliminated due to emergent dependencies between states, and where many of the states are limited to within specific portions of specific decision trees may very well compile to a more reasonable number of static files. I don't actually know yet, though. I'm not conversant enough in statistical analysis to figure that out... which is why my plan is to finish writing the compiler, write some stories, and see what happens.


This tool looks quite similar to my gamebookformat.

My static output formats (PDF, RTF, static HTML) do not contain any duplicated state sections at all, because I have counters etc that would not work anyway, and I'm assuming anyway that the player of the static version will keep state on eg a paper, like you do for a printed book. I did however think about the possibility of keeping state by duplicating sections, and I have an idea for what naive algorithm I would use to probably bring down the number of duplications if I ever get around to implement it:

Make a directed-graph representation of the story. I guess you have that anyway. Search backwards from every section that has a conditional, and find all paths leading back to a section that sets the conditional (ie search from the locked door back to all sections where a key is found). Then search forward through the story, marking in all sections what state variables can be true, false, or either, in every section in the story. Then a simple iteration over all sections will tell you what sections to duplicate, and for what state variable(s) it has to be duplicated. For instance for the key you only need to consider nodes that are along the paths from finding key to the door(s), and where the player can either have or not have the key (no point in duplicating sections where you are sure the player must have or must not have the key). Of course some sections will still be duplicated multiple times, because several variables could be set or not (and matters) in that location, but it should be much fewer than all of them.

I hope that sounded as easy at it seems in my head. :)


Top
 Profile Send private message  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 35 posts ]  Go to page 1, 2, 3, 4  Next

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group