Do we really need radically new IF tools?

Hi all! I’m IF lover and in parallel senior full-stack developer. And recently I became interested in how to make IF. So I went through existing tools for creating interactive stories and I think they lack some really useful things. I don’t say that they are bad and yes, many great IF appeared thanks to them.

But I think we can do much more. Because IF is not about choices, passing through decisions and just reading. I believe that it’s about emotions and feelings, about engaging and participation in story.

Look at Lifeline, Telltale games - all these stories make us feel much more involved in them because of atmosphere that they create. They add timers, delays, soundtracks, appropriate style and other things that help them to recreate experiences and feelings of heroes.

So how about a tool to make IF more engaging with little effort to authors?

I plan to create app with features like these:

• Wide platform support - iOS, Android, Windows Phone, Blackberry, Mac OS X, Windows, Linux

• One click to export to mobile or desktop app (via build-in apache cordova integration), self-hosted site (via static generators) or standalone package to embed on your site

• Ability to add background music for locations and sounds for actions
music.PNG
• Support for timers to boost player choices and delays to enter them into an intriguing waiting
timers.PNG
• Build-in support for device information which you can use for experience personification (volume, geo, battery, brightness and other)

• Integration to services like Google maps or Facebook to make tightly coupled with reality experiences (ex. real life quests)

• Graphical view of whole story in dendrogram
dendrogram.PNG
• Easy to write markdown-like syntax with ability to add some complex scripts if you want

• Easy data binding with simple “mustache” syntax: You write “Oops! Oxygen level is {{oxygen.level}}”, set oxygen level to 23 and then reader gets “Oops! Oxygen level is 23”

• Animated background color tint changes to influence on story perception

• Ability to add styles such as fonts, borders and textures for different locations with ease.
style.PNG
• Global view of all variables (locations, objects, characters) in one place where you would able to edit them with easy and get overall view of story

• Ability to monetize without effort in Google Play, App Store and other platforms

• And many other things!

It’s rough sketch of future possible platform to create from beginning to end engaging interactive stories, quests or new reading experience with synced sounds and ambient music, that let you concentrate on your story rather than on writing code and fighting with software.

And now I want to ask you - do you want to change future of IF and spread really engaging stories all over the world? Do you think that such software can help us to do this? Because I plan to start Indiegogo campaign. It won’t be about money, but about to find out how many people want to do this with me, and do they really find such things helpful to them.

What do you think?

It took me a considerable amount of time to realise you were advocating FOR radically new IF tools.

I’m not sure people are using the existing ones enough, to be honest.

I don’t want to sound negative, but just a brief reality check: creating something like what you’ve outlined would take a single developer several years before the whole project is at a stage where it’s even halfway decent, even if you worked on it full time. An IF parser, especially when it comes with a full development system, is one of the worst cases of deceptively simple looking projects that are actually very complex.

If you’re asking veteran IF authors if they want a new system that does all that, the answer is most likely no, because the reality is that any new system isn’t going to be better than the standard toolkits that have been developed and improved by several people for 20+ years. Given time it might grow to be better than what we have now, but it’s going to take boatloads of time and effort to get there.

I’m only saying this because you mentioned the Indiegogo campaign. Once you’ve taken money from people to develop this thing, it’s very hard to back out from it if you find out only afterwards that the project is actually unfeasible. So before you launch the crowdfunding campaign I strongly suggest you outline the project schedule and resource requirements very carefully and have someone with experience in parser-based authoring systems read it and give feedback on how realistic it is.

That said, if you’re not set on making everything from scratch, I for one would be very interested if you’d instead plug an existing parser engine into your UI system. That way you’d save literally years of development time and you’d get a ready-made engine running under the hood that’s already familiar to a lot of developers.

I’m always wary when people talk about launching some new IF system with oodles of amazing new features because experience has taught me that none of these systems ever get finished. I guess when you’re at the brainstorming stage of design, it seems really easy to think “yeah, I can add this feature and that feature, it’ll be a doddle”, but when you actually go ahead and try to implement these features you tend to find they’re not as easy as you thought.

Do we really need radically new IF tools? Not really. The ones we have now work fine. I’d quite like improvements to the existing tools but I don’t think there’s really any need for new ones.

Just getting fixed bugs packaged into released builds of existing IF tools would be a radical improvement.

I just want to point out that most people would find it much more useful if the existing tools had more developers. It often takes years for bugs to be fixed in the systems we depend on most. If you’ve got the skills and the enthusiasm, would you consider helping existing projects rather than starting new ones?

Building on what Dannii and Juhana say, it seems to me that a lot of the features you talk about are mostly about how the guts of the game interacts with the user interface. To take Inform 7, which is what I’m most familiar with: It produces files that run in a virtual machine that run in various different interpreters on various platforms. Lots of these interpreters give the author little to no control over the appearance of the output–the program you write is going to output a stream of text; if you run it in Zoom, it will get formatted the way Zoom likes to format it, and if you run it in Gargoyle, it will get formatted the way Gargoyle likes to format it (well, the user can configure it by editing a text file).

There are also options to program in real-time delays and sounds, but as I understand it they’re not super well supported or intuitive to program, and they don’t always work in every interpreter.

So, the features you’re talking about: things like adding borders, fonts, and colors for specific locations seem like things that could happen on the interpreter side. You don’t need to write a new IF programming language with its own parser to enable a game to change fonts and borders for different locations, you just need to come up with a cross-platform interpreter that controls the borders, fonts, colors, sounds, etc. in a flexible way, and work out a way for the author’s game file to talk to whatever aspect of your interpreter controls those things. It’s my understanding that Juhana’s Vorple does something like this, for web only–but it’d be great to have something more flexible here, that supported larger game files (Glulx as opposed to z-machine, if your investigation of existing IF tools has made you familiar with that distinction), that could easily produce stand-alone executables and mobile apps (maybe Apache Cordova is key here?), and that was as easy to work with as you describe. But if that’s the route you want to go, in my opinion the easiest way to accomplish what you want is probably to do something like what Dannii is suggesting–start with Inform and work on projects (like Vorple and others) that deal with the way that Inform files interact with the interpreters and the things the player sees. As I said, reinventing a text parser from the ground up isn’t going to get you any further toward the stuff you want here.

(Oh, and Inform 7 already has mustachey syntax. You can tell it to print “Oh no! The oxygen level is [oxygen level]!” and, if you’ve set the variable “oxygen level” to 23, it will print “Oh no! The oxygen level is 23!” And the routines you call this way can be quite complicated, much more than simple variable calls.)

But on the other hand, do you really want to be working with parsers? Your examples talk about typing “inventory” and “drop,” but the examples that you cite are choice-based rather than parser-based, the concrete example of interaction you give is choice-based rather than parser-based, the idea of slappingtimed interactions on a parser gives me the screaming heebie-jeebies while I can see how it makes sense for choice-based projects like Lifeline (which I haven’t played), the idea that the author will be writing in markdown with maybe some complex scripts seems much more like the choice-based systems I’ve seen than the successful parser-based systems I’ve seen, similarly the idea of representing a story in a dendrogram seems like something you’d do with a choice-based system rather than a parser-based one, and I’m honestly fairly skeptical about the idea that authors will be able to write an engaging parser-based story without writing some code.

So, if you’re interested in choice-based systems, have you checked out everything that’s out there? Twine and Undum/Raconteur and Ink and the like? Twine authors definitely do a lot with sounds and appearances and real-time delays and a lot of the things you’re talking about, and Twine produces a tree map of the story. Now, maybe this stuff isn’t as smoothly integrated with the system as you’d like (it’s my understanding that the fancy effects people do in Twine tend to come from Javascript macros that they drop into their projects), but again, it seems to me that the best way to get things going might be not trying to reinvent things from the ground up but to try to work on developing your ideas in Twine or Undum, writing libraries to make it easier to do the things you want to do.

Another thing–if you are going to develop a new system and sell people on it, you’re going to want to write a killer story that people are interested in. People wouldn’t be interested in Ink if Inkle Studios couldn’t point to 80 Days and Sorcery! and their other products and say “This is the system we’ve used to make these awesome games!” And, no offense meant, but your English doesn’t seem to be entirely idiomatic, and that’s going to make it hard to write the killer story yourself. If you’re going to make a go of it I think you’ll need some writers on board from the beginning–probably something you’d need anyway, because your tool is meant to cater to what writers need so you’ll need feedback from them, but it’d be especially important if you need help developing the product you’re producing.

[As an aside, when I saw the title of the post I thought, “Sure! I’d like to see a radically new IF tool for parser IF!” Because I often find myself butting my head up against the way the Inform 7 parser works, in ways that are very difficult to modify. And I feel that it might not be that overly difficult to come up with a new parser if we just cannibalized a lot of the parser the way it is. But that’s not something I’m capable of doing, and it’s clearly not your primary interest, nor should it be.]

In case it’s useful, here’s a summary of some investigation I did a couple of years ago about what people need/want from IF toolsets still:

emshort.wordpress.com/2014/03/2 … ng-at-all/

Because things take time to develop, not all of these two-year-old wishes have been addressed yet, so there might be some useful ideas in there.

This is the most important factor in the success of an IF tool. If someone writes a great game using your tool, then others will do the same. Until then, you’ll struggle to get anybody to try it.

I’d like to hear more about this.

In my humble opinion…

Every web-based platform has this. Adaptive CSS styles are very common.

Okay, let’s see. Every Twine game (ever) works with apache cordova, self-hosted sites or as a standalone package as it is. So, where are the swarms of Twine mobile apps?

I know several engines that offer this ability to the author.
But it’s not a popular feature in the browser games, because of the size limitations.
One can easily bump a web game up to 20+ Mb with MP3s but it will be a pain to download.

Again, there are several engines with realtime capabilities but this kind of UI is very rare. You’ll have to push this style into popularity.

Aww, no love for the desktop? Again, most authors can’t imagine how to use this information, it’s not a popular style feature either.

With an assumption that this story style will be presentable as a dendrogram.

It’s hard now to find a popular engine without a simple text formatting syntax and string interpolation. Most of the engines without these features are rocking in other things.

Can you name any game that boasted this feature? Seriously, I’m curious how it looks and why it’s important.

Which is nearly identical to an ability to execute scripts in different game locations.
I’m sure you know this already as a full-stack developer, but visual design is NOT about just fonts and borders.
(as an incidental comment: couple of weeks ago I made a sort-of templating engine for Salet. Imagine the whole screen just rearranging itself when you go from inventory to location map. That’s a full HTML+CSS swap, definitely not a simple switch for the author to use.)

Sounds cool but not a game changer. And it also implies a world model, i.e. having distinct objects and characters.

Again, swarms of paid Twine mobile apps. The web-to-app conversion process is already easy enough for someone to do it, right?

I wish you good luck on the IF engine market.

This is why we can’t have nice things. I’ve been encouraging programmers to visit this board to participate in IF, but from the looks of this thread, I don’t know why anyone would want to.

I think people are just naturally cynical of newcomers and their wonderful designs for new IF systems that never go anywhere. If you could point me to one newcomer who has announced a system in the same way as this and that system has actually been released and been well received, then by all means do so.

Which isn’t to say that the OP should stop work on his system and abandon it altogether. If he feels he can make a good job of it, and if it can give the current systems a run for their money, then good luck to him.

I think/hope he meant the post that somehow managed to reprimand the new parser system for being choice-based. If it was a reference to my post, I apologize and it wasn’t my intention to be harsh or insulting.

@Juhana yes, I just meant the rude, low effort posts. There has been a lot of great ideas in this thread, too.

To be fair, saying that choice-based authors have “never played an actual IF game” very strongly implies it.

But back on the topic of this potential new app: Tallonar, if you’re still watching, do you have a basic prototype of what this system can create? I think it would make it a lot easier to evaluate if we saw directly what you wanted it to do. The mockup screenshots seem like a mixture of choice and parser and I don’t really have a good understanding of how they’ll combine.

+1 for the prototype.

There’s an overload rather than a shortage of tools right now. In these circumstances, mockup screenshots and feature lists just aren’t as useful. People have to take a prototype out for a spin. Make a “cloak of darkness” thing as a tech demo, then people’ll be able to be more constructive…