You should also check out TaleMonster and Yarn which are both mobile platforms, although both utilize Twine which might not be optimal on mobile platforms for creation.
There is also WunderVerse on iOS, but you said Android.
They are all iOS (Yarn has plans for Android) and don’t really feature an opensource way.
Rather than suggesting me half alternatives, please focus on my questions, thank you!
Sorry to take up your time, I’ll not waste any more of it in the future for sure.
Thanks! Sorry to hear you have no interest or suggestions for my project. If you have any in the future, feel free to post them!
Hi,
Your project looks interesting. Choice engines are not so complicated to prevent making your own. Also, it gives you flexibility.
One aspect of a different system to those already out there is that it will be possible make different games. This is a good thing.
I also develop for Android. I am currently making my own IF system, although only the runtime will be on Android. The plan is to author on desktop, run on mobiles. Progress is going well, I’m hoping to have a demo soon. My system is not web based.
I have a suggestion for your choice engine:
Is there a scripting language you can add to your JSON system. Since you’re web based, Javascript seems the obvious choice. I’ve noticed most choice systems have rather weak scripting, being mostly simple variables and states.
The idea would be to replace all your variables/actions and conditions by statements in, eg JS. Or is this what you’re already doing?
I find it puzzling that people are still building i-f creation systems on Android, when Inform 7 and z interpreters are already available there.
OK, the IDE for Inform beta on Android is flaky, but it compiles OK and it can be tested on the Android. (see my route at [url]https://intfiction.org/t/using-mobile-devices-to-create-if/9772/1]). I guess someone will eventually stabilise the Android build (the original developer seems to have left town).
My adventure ICEWEB was developed and tested entirely on Android, and eventually released via PC.
Otherwise, if you have constant WiFi, you can use one of the Web systems. See [url]https://intfiction.org/t/using-mobile-devices-to-create-if/9772/1]
The lack of Glulx interpreters on Android makes it more difficult to use I7, though, or even to play I7 games. Few of those fit in the Z-machine any more.
As i understand it, the Joozey system is for authoring choice games under Android without internet connection.
My system is not for authoring on Android, but for playing on Android (as well as other platforms). it’s not web based, and it doesn’t use the z-machine nor Glulx.
Although i’ve nothing against I7 or any other system, i wanted to create something different, with a different feel and different possibilities.
For example, right now people are talking about either parser games or choice games. I see these as two sweet spots of a continuum. I’d like to focus on what i think might be another sweet spot: choices with objects, or loosely, choice + inventory.
I have a parser style back-end engine, but the front end is choice based. There’s no typing needed to play the game. Clicking on a choice, actually sends a text command to the back end (as if it were typed). A bit weird, but it works.
Since choices depend on what you can actually do in any given situation, it’s possible to query the back end for this. Kind of like, using the system in reverse.
Twisty and Incant are both Android front ends to glulx (and zcode) interpreters. It looks like both projects have been quiescent for a while, although there was some success (threads: 1, 2) running I7 games a couple years ago.
Thanks for your interest. I try to keep in mind future extensions, adding music and images, maybe even sequence animations, to make a broad range of choice-based games. My target audience are writers that just want to write and do not know how to program, hopefully making IF writing more accessible.
I’m not web-based. Trying to steer clear from that mess 
. You have a range of devices that wont work (properly) with javascript.
For conditions I use an expression interpreter to evaluate logical and mathematical expressions.
Actions have predefined commands to use like navigating back or undo, adding to a variable or deleting one.
Every inputted string, in all texts and conditions, is processed with a regular expression to replace a variable with its actual content or a default value.
I’m using this library eval.dev.java.net/ for evaluation.
Is your system supporting existing formats?
What are you missing in the weak scripting possibilities in existing systems?
I hope you manage to finish your project.
Yes this is correct. I want my editor to be as easy to use as possible for tech-savvy authors, so the interface should feel natural. Current web-based solutions are often buggy and have unpredictable behaviour, as a natural result of them being web-based. Native is the way to go 
.
There is one android IF authoring app that I tried to use for a while, but it’s buggy, lacked crucial features and not easy to work with.
play.google.com/store/apps/deta … estory.app
Thanks for those links. They seem to never have made it to the playstore in some form of editor. Ant-based builds, that’s ooold 
. Source might prove useful later on if I want to port those formats. For now, I’m keeping things simple.
I am not web based either. It’s because making an appified web experience does not come over the same as most users expect from apps. For example, use of material design, settings pages, sharing etc.
Thanks for the eval java link. Looks like you’re already doing what i was suggesting.
by “weak scripting”, i was referring to choice scripts like Twine. I could be wrong here and am prepared to be corrected, but reading the Twine wiki, it seems there is little provision for things like; defining functions, local variables, data types and normal programming structures like for, while, do loops etc.
Like i say. I could be wrong about this in Twine.
I am not supporting any existing formats because i want to make something new and different. The way i see it, is that it’s not about making something better, just making it different.
I do think there’s lots of space for new and different systems. Yours will have a different gameplay mechanic than mine, that’s also different from what’s currently out there
All this is good.
Well technically there is another glulx interpreter for android - and it handles most games (I’ve had weird problems with some with really complex graphics and lots of windows) really well.
My site’s down, but it’s here. The caveat is that it’s not particularly easy to use, and if you aren’t rooted you’ll have to use LD_PRELOAD to load the libraries it depends on (e.g. ncurses).
web.archive.org/web/201605301633 … droid.html
It’s got better compatibility than the twisty fork as of the last time I compiled and installed it a few months ago.
But yeah, we really need to have a proper android terp. I’ve been playing around trying to make an SDL2-based one, but it’s nowhere near ready.
The other (crazy) alternative would be a debian chroot or something, coupled with the ‘XSDL’ X server. This works really well, but is total overkill and not really the ‘right’ way.
If someone familiar with Java and android GUIs wanted, ‘zag’ is a java-native glulx interpreter that just needs a new frontend (it’s based on Swing, IIRC). It’s currently the only up-to-date glulx interpreter that supports graphics that runs on X11 (linux/BSDs/Unixes) besides Gargoyle.
github.com/Banbury/zag
Apparently it implements ‘zing,’ which stands for “zing is not glk.” It’s almost a GLK, though, so it SHOULD be possible to write a ‘zing’ implementation for android and interface it to the zag backend relatively easily (if you know java amd have prior android experience).
I’m somewhat familiar with converting Java to Android, having done that exercise with a PC based Java application.
There’s quite a lot of hassle converting Java programs to run on Android. I spent most of my spare time last year converting a Myst-like game program from PC to Android. OK, once I got down to the game logic and the various structures and methods, it was fine, but there’s all sorts of complexities to do with:
- Making sure it can task-switch with anything else on the device, especially phone functions
- Not losing your place when the user turns the device from landscape to portrait
- Configuring it to work on a WIDE variety of screen sizes, shapes, pixel densities, etc.
- Yes, there are Swing-equivalent UI elements, though Android users are big on gestures and taps - in particular, I had a lot of trouble with double-click compatibility from device to device
Compared with porting applications across different flavours of desktops/laptops, it’s non-trivial. The good thing about it is that the Android Studio on PC cross-compiles and emulates the wide variety of screen configurations, so once you get the hang of it, it’s quite rewarding, but I’m not sure I’m ready to go through the pain again!
I see my thread gets a bit derailed all the time so I changed the title to be more clear. Hope that is ok here.
To wyatt8740 and Gil, hope you can collaborate further together! (in a separate thread 
)
Progress update
Currently the following functionality is added:
- Evaluating expressions for paragraphs and choices: you can show and hide text parts simply if the input condition is true. This way, you can evolve a story on one page dynamically, or come back to a previous page with content slightly changed.
- Stories can be created and saved on the device external storage, so you can grab it yourself too with a browser app. Saving goes automatically with every action, so little to no loss of data if your phone suddenly dies.
- New pages can be created and linked to by each choice.
- Choices can modify variables (e.g. add / remove sword)
Next week planning
- Extending variable editor (add/remove a variable in numbers, set to number)
- Create Read interface for testing the story
Sorry. My bad. :\
I feel I should point out that this quote seems to be the only mention of open source, it doesn’t seem to be mentioned on the resources you link to either (also you don’t seem to have asked any questions, at least in the current version of your OP?) Is the project open source? And if so what do you mean by that, is it say MIT/BSD licensed, or GPL, or is it dual licensed so authors choose between paying a fee to distribute their games closed source or distributing them open source along with say your GPL code? The intention is unclear to me… can we for example see the Java source for the Android app?
On Texture you note that it requires an Internet connection yet I believe the games can be downloaded as HTML files and presumably could be packaged using say Phonegap to run as Android and iOS apps. I suspect that Texture is a simpler system that your own with less scripting ability, however your “summary for version 1” sounds more like what little I know of Twine, which like Texture is also web based, in that it uses client side web technologies (HTML, CSS and Javascript to run).
I am curious what you mean by “You have a range of devices that wont work (properly) with javascript.” especially as it seems the demands of an “expression interpreter to evaluate logical and mathematical expressions” would be rather basic, and it looks like you are depending on a WebView for rendering your layouts. What devices have such poor Javascript support that they can’t handle simple expressions? (I actually want to know btw; I understand there are limitations when it comes to newer HTML5 features, especially pre-Android 4.3, but the devices with really poor support, must be in a tiny minority which is ever shrinking as devices get dropped or traded in for newer, better models) Without further explanation it just sounds like you don’t like certain technologies, which is fine, it’s just that’s different to claiming nebulous problems (you mention wanting to be “native” but your screenshots look no more native then HTML running in a webview).
With the suggestion “I will release the first version of the editor in the playstore for free and ask for donations if you find it useful or like to see further development.” I see that as being rather a tough sell over an open source, well established Twine 2 backed by an existing community. Not least because while an author might have some pain to use say Phonegap to publish a Twine story on iOS and Android, the author knows that their story won’t die even if Twine’s community (not a single person) were to vanish; it would seem with your system the author is dependent on your app for their work to live on, and they have to trust that you will neither release changes that will break thier story nor change the terms that make that app available to end users in order that those users can play the author’s story (I myself am new to the community but I have noted concern over format support is a real issue - authors want their stories to be available for the long term and it seems that they have seen many authoring systems/formats)
I do think it’s great that you have solved a problem for yourself, I just feel you have shared less information about your intentions in this thread than your replies seem to suggest you feel you have, and from what you’ve actually mentioned it seems premature to ask people to buy into this idea. I’m sure there is room for alternatives for authoring choice based games, but it just seems like you dismiss the existing solutions too flippantly, and the people trying to help you too callously, for this to be worth much attention in my humble opinion.
Yeah, good point re: hijacking your topic. Your title is now more specific.
Thanks for your reply turnip, good questions. Thanks for pointing out that you’re missing info.
What is opensource is the saved stories, in plain json format. They are very simple to understand. Anyone can build a writer or reader reading those files, so continuation of support is somewhat guaranteed by giving the format a low learning curve and free to the community to use.
I’ve been thinking what portions I want to release and what not. Certainly the Android reader. Possibly the basic Writer too, and perhaps offer a paid version with fancy stuff to dress up your story with images, music, themed colours. That’s for a later release though.
Possibly texture supports offline use, I might have judged that too quickly. My tool is native android, no html/javascript, webviews or internet involved anywhere. I stay away from webviews. The output is a json file, which can be put online using the javascript reader I also developed.
I support down to SDK 11, android 3.0 Honeycomb. It accounts for 99% of all devices. I started out using a webview, reusing the javascript reader I built, but already I hit html5 limitations on storage of local variables. Webview has had several developments through different versions, and taking in account all those iterations in code is a lot of testing and work. In my experience there will be several issues popping up with webviews both in different versions and different manufacturers (like Samsung). The complication webviews bring about does not weigh up to its benefits for me. I rather develop native Android and Browser applications in their own right. I found this detailed support overview: mobilehtml5.org/ for individual features. Several of them I need for a smooth experience that aren’t there for 3.0, such as vitual keyboard, Filesystem API and audio. Hybrid solutions make it all possible but too much hassle for too few benefits in my case. So yes I definitely have a preference for certain technologies, and not for others. But it depends on the project whether or not I will use them anyway.
Their work can live on without my app: the reader is also available in javascript and they can host it themselves on their own site. The editor, yes, it is possible I would take the app from the playstore (though as long as they keep it installed on their device, they’ll have that). But that chance is extremely unlikely. The only time I ever heard of a popular app being taken down was Flappy Bird. I have no such intentions. The app stays in the store indefinitely as far as I’m concerned. I think chances are bigger that Twine closes down. And because the saved story file is freely readable, someone could take the initiative to build their own reader/writer tool, further allowing continuation of individual works.
I hope I clarified some of the missing information. Everyone is free to buy in my idea or not. I see no downside of premature promotion of financially supporting my investment in this project. The sooner I can convince people of the potential of my idea, the better.
I will watch my words dismissing advice and suggestions too flippantly. I get annoyed quickly by negative-focussed comments, but that is something for me to work on.
Thank you again for your time to comment!