Cypher seems to be etirely doable with Quest: https://www.youtube.com/watch?v=7zPG6wi8fcQ

Is there anything I might be missing? Anything that looks difficult to implement there?

I haven't played Cypher, but I think you're right. Maybe the biggest obstacle would be distribution -- I don't think Quest has a good desktop story on Mac/Linux right now. You could compile the Quest story to JS though, so that might be a workaround.

Yeah - I think it is very workable.

PC desktop, web player, Android, iOS... Thats not bad as a platform base goes.

I think Steam will allow greenlight with that provided the PC version measures up.

The potential for rapid development is certainly here with Quest. Maps, graphics and that pretty slick hyperlink based mobile UI (maybe done in a 50/50 with some screen realestate devoted to graphics) can make a very professional product.

Mobile and PC are both key - and a slightly expanded PC UI might be worth a fork in development.

I would really like to get a solid DIY end-to-end solution for Android and iOS. Quest is much of the way there already (there's an open source to->JS converter here, https://github.com/textadventures/quest , then you need something like Phonegap to get the rest of the way I guess).

I have been looking into phonegap. Its not bad at all. Given it also covers some smaller platforms, but seems to do it simultaneously (aone to many port). Blackberry, Windows Phone and Kindle Fire are certainly not in the same leauge as Android / iOS but extra sales are extra sales.

It looks, from a bit of reading yesterday, that so long as the HTML+JS version you feed into phone gap works well, all is well in the end. But GIGO is also the case. (Converter seen, but not yet played with at all)

Thinking about mobile UI design, with Quest we've got either text option (hyperlink or no) and we've got static picture frames and we've got the ability to set up tabs for specific stuff (like puzzles, multiple choice options, presentation of tables / data, RPG elements like inventory management, etc.)

The picture frame option in Quest is nice because we can count on that space being temporarily covered up with a keyboard pop-over when we want it to be. Or at least that is how I am seeing things in my mind's eye. Have been trying to think about any other mobile UI issues.

A desktop version is easier because we can just spread things out ... less need for tabs, we can go with windows or side by side panes (taken directly from the layout of the mobile tabs. Desktop development is a must for me due to Steam Greenlight ... but the mobile development can give me all the pieces and its the mobile where screen realestate is constrained.

The UI, in my mind, is a constraint. It limits engagement in a story. There is no perfect UI except maybe conversation / oral / human (debatabe point, the thought here is that stories were all originally 'told', also there is the richness of information to consider) ... but when I think about UI design I want it to be as minimal a constraint as possible on my story. This leads me to think that a good background score, sound effects, audio treatment are essential. Text is not so much as punctuated by, but accompanies the visual pane. This is supported by audio atmospherics. Text itself flows in a certain way and here the hyperlink or verb-entry issue crops up ... so too does color of text, font and other typesetting.

Sorry for the stream of thought posting ... but it helps to hash this stuff out with people who know what I don't about the engine. Any comment or insight is always welcome.

EDIT: So from the breif bits of reading about the conversion process, there can be issues. What sort of issues? Is there anything I can do during my dev arc to proof agianst problems? What makes the conversion smooth?

From what I understand, while a couple of Quest games have converted to apps, these were done with help by Alex (the Quest dev). He can still do that, but he charges a fee per platform (check the website, it was like 200 euros last I checked). There's the open source converter to do it yourself. But, I don't think anyone has successfully used that yet. I believe it needs some work.

While I like typed-in commands a lot, if I were going for Greenlight I'd probably stick with links. It would make it a lot more accessible to a general audience, not to mention it would make the UI easier on mobile (though opinions differ on that, with things like Swype, tapping on words to send them to the command line, word completion, etcetera).

Quest has audio but I don't know its capabilities, like how well does it do fades, cross-fades, etc. It might be possible to use a JS library for that.

If anybody does any work on implementation of broader audio use I'd love to see it. I'm pretty new to any sort of programming and JS and all the things it can do are still waaay over my head, but I'm a musician and really into the idea of scoring and adding other sounds to my games, and the one layer, on/off audio system, while much much cooler than nothing, is pretty limiting. I've been racking my brain for a clever workaround but haven't come up with anything and I figured more complex audio options would be pretty low on the list of features to implement.

What kind of features would you want to see?

The biggest one would definitely be multiple audio layers. At least two, so you could have persistent music in the background with action-based sound effects over top of it (a sword clash, a door slamming, maybe even voice work, etc). The more layers the better basically, but I can't really see really needing more than a few for anything I have in mind, and just having two instead of one would make a major difference for me. It doesn't seem to me like too big of a jump from what there is now, but I don't have any idea what I'm talking about, heh.

Being able to fade in and out and crossfade would be really nice, too. You can obviously already make the audio file itself have a fade, but then you can't loop it. You can kind of get it to work by having two files, the same except one has a fade and one doesn't, then playing the one with the fade first, holding the game up until it's done, then playing the loopable one and looping it, but then the player has to wait for the whole first file to play. Though this could be helped by just having a "play one time, then" sort of a deal that you could put scripts into.

What would be super cool would be something sort of like the idea of scenery is with objects, where you could start multiple sounds at once and toggle whether or not you could hear them. Then you could build musical arrangements dynamically as things happen, like having battle music where a dramatic melody cuts through when you land a critical hit, or dropping to just percussion when you get low on health, and everything would stay synced up and in time with everything else. Something like that might be too demanding in terms of processing, though, even with compressed audio.

Sorry if that was too much all at once, I've had these things on my mind for a while.

I agree on the audio. Multiple layers and simple fades would be very useful. Looping files is pretty important to save space and using short files.

Sound effects living on a different layer from the background score is also useful so that there is direct interaction with various sounds and objetcs.