Wrapping Quixe into an app with PhoneGap

I’m searching a way to convert Inform games into Android apps. I tried AndroidIF (used by Simon Christiansen for Patanoir) but there are things I didn’t like with it.

Then I thought about using Quixe and PhoneGap (even though I have zero knowledge in JavaScript). I did a quick test by using the web pages generated by Inform and, a few problems aside, it worked quite well!

The only issues I encountered for the moment is that the keyboard flickers, there is no way to minimise it and the text doesn’t scroll automatically to the bottom.

So my question is: is it worth continuing this experiment, or are there drawbacks that I should worry about?

Out of curiosity, I also tried building the app for iOS to compare it with iosglulxe. Again, would there be drawbacks to use Quixe/PhoneGap instead of iosglulxe? I assume the latter is faster, but I find it easier to customise the former.

Thanks!

Speed is the big difference. Also, I have tested iOS VoiceOver thoroughly with IosGlulxe; I don’t know how a Phonegap app will do with it.

Without a Node/Electron environment, Quixe has to use HTML local storage for all its save files and transcripts. This may be limited in space, and it will be a nuisance to export that data from the app.

I built from scratch an Android app on Quixe just a couple months ago. I’m talking a pure offline app that can work with the phone in airplane mode. Let me highlight some things to understand:

If you are talking specifically Android, I would point out that there is a key division line of Android 4.4 and Android 5.0. Chrome is by far the best performing browser engine, faster than Firefox on Android devices I’ve tested (both Intel and ARM CPU, which covers almost all devices). They key change is that with Android 5.0 and newer the internal WebView is now a component on the Play Store that can be updated without upgrading all of Android itself (5.0 to 5.1, 6.0, 7.0 etc). Previous to that, in Android 2.3 to 4.4 days - solutions like Cordova / PhoneGap some would bundle an entire download of the Chrome engine binary into your app and it could come out 45MB for the end user. Because the WebView used to be outdated and would be glitchy and insecure(due to not getting updates) if used to browse the live internet - say for downloads of game files. It’s all a matter of how many outdated devices you want to support. Android 5.0 and newer is a practical cutoff for a new app in 2017. Also take some time to consider if Amazon devices is a target, their Android can be it’s own issue too. Cordova / Phonegap may help there, I don’t know.

PhoneGap is designed to accommodate both iPhone and Android in one standard API. It also has a nice system of modules if you want to very easily integrate things like Android smart watches, vibration, GPS, etc that a web browser wouldn’t normally know of. If you need that, fine. But if you do not need cross-platform, also consider just using the standard Android internal WebView component (which is now a properly maintained and updated Chrome engine) and just load Quixe that way from your assets folder.

From a performance perspective, I found Quixie to be very good on Chrome engine on Android. Surely practical and usable. The reason I abandoned it was due to GlkOte and the layout - I personally wasn’t happy with multiple Glk windows on a mobile phone screen. However, you have another options too for Glulx - and that’s FyreVM-web github.com/ChicagoDave/fyrevm-web which completely removes GlkOte form the equation and lets you do Glk windows and other things how you wish while still using Inform 7 as your platform for authoring. I did spend a couple weeks exploring fyrevm-web but didn’t actually go so far as to build an app for Android WebView like I did with Quixe. But i see no reason why it woudln’t work perfectly fine - and you could compare it’s performance today by just using Google Chrome browser on Android to get an idea of how it compares to Quixe.

If you are authoring your own work in Inform 7 - don’t overlook targeting z-code (instead of Glulx like Quixe). For Android apps, you have Text Fiction, Son of Hunky Punk, JFrotz, Twisty, others?. In fact, if you are willing to not use any Glk sound/images/windows (which .z8 of Inform 7 6M62 doesn’t support anyway) you can run Glulx on Twisty 2.0 or Son of Hunky Punk today (both on Github) if you are willing to go unsupported by the authors/publishers. Both are open source and do have working Glulx integrated via Git interpreter (which is very fast on Android).

On Apple side, there are much fewer screen sizes so adapting Quixie is probably easier. Adapting Quixe to support the much more diverse choices on Android screens is one of the trouble areas. How smart is iosglulxe on layout and look and feel (I’ve never used it)? Performance wise, Glulxe is a slower interpreter than Git - and I’m going to assume that Apple is using Safari for it’s internal WebView for PhoneGap? i have no idea how well Quixe performs on a Safari engine… but I can say Quixe is rather fast on Chrome engine! Fast enough that it’s a viable option compared to Glulxe in my testing on Android. With Apple, someone else will have to report speed and memory usage.

One other thing to look for is how the app behaves when user switches to another app such as email or web browser. Are you going to save the game, unload, restore, re-load when they come back, etc? Quixie may not expect the operating system to unload the game without the user’s consent - so you have to deal with that issue that a normal “desktop user” of Quixie on Firefox, Safari, Chrome wouldn’t do.

Both interpreters assume that the screen is a rectangle of arbitrary size, which can change size at any time. Then they lay out the Glk windows inside that.

(For Quixe the screen is the browser window, so the user can resize that freely. For IosGlulxe, the screen size is the device size, but iOS isn’t really a fixed-size UI any more – the on-screen keyboard can pop up and down, the device could be reoriented, and there are various other details. So the interpreter still has to be ready for the screen to change size.)

Quixe now supports autosave; it can autorestore at startup time.

Yes, but the performance difference between C and Javascript is larger.

What I hoping for in future mobile is that we can break free of the single outer rectangle. David’s been telegraphing that with FyreVM-web and working with his code (absent of GlkOte) and his (now dead) fork of Quixe I realized what he was getting at. On mobile devices with all their screen sizes, it makes sense. The 80x25 model of decades past, I’m sure most of us just assumes screens would get larger and smaller wasn’t really in the game. Mobile changes shapes, as does rotation.

But Glk’s window concept actually works very well for mobile. If you break the outer rectangle. And I’m even working on a runtime way for users to share layout-rewrite rules to decades old games. For example, you could tell the app to break apart Counterfeit Monkey’s two windows and stack them one above the other instead of side by side, or move the map to the right (which works better on a 5" mobile phone than having it on the left - as you really don’t need to be seeing the map first thing - even add the ability to swipe in/out screens). Kerkerkruip is another great example of this, reference screen shot: i.ytimg.com/vi/t2sJ5PdOABQ/maxresdefault.jpg

Imagine being able to have copy/paste one line of config for each game (or download a prepackaged set) that re-arranges each of Kerkerkruip windows to fit your preference. For people who play a game like Kerkerkruip every week, this is a big change in flexibility! You could assign the font family of your choice to each window, tell it what size you want, and how is stacks (think of Tetris pieces). And ideally people can share these configs on the forum here or a website if they want (a copy/paste JSON style config).

But David’s concepts go further. You can basically create an invisible window of zero height and width (channel I/O, data stream), assign it a glk rock just like you do a traditional Inform window, and send commands. For example, you can have a command channel to vibrate the phone, rotate the screen, create contacts, execute scripts, etc. All this can be done using established Inform 6 & 7 concepts and authoring tools.

This was an concept in the early days of Glk design, but the API wound up being pretty one-rectangle-centric. I’m not sure you can get away from it for existing games.

Games designed for a different display paradigm are of course a different matter.

Thanks for all these Informations. I’ll stick with iosglulxe for iOS. (except maybe if I need pictures or multiple windows. I don’t think it supports it.)

That’s not possible. It’s difficult to fit a reasonable Inform 7 game into Z-machine now, and anyway my games are in French, and all the things the French translation adds make the game too big for the Z-machine.

But is it possible to used those to bundle your game as a standalone app? I have absolutely no knowledge in mobile development. If I had the abilities, I would write my own interpreter.

If I don’t find a solution, I’ll just release my games on iOS. Or use AndroidIF, even if I dont really like its layout.

Since you are wanting Glulx due to size of the project, let’s eliminate Text Fiction, JFrotz. Son of Hunky Punk has a rather proven user interface that had some features added in recent months - and you can try it out right now on Z-machine stories. play.google.com/store/apps/deta … punk&hl=en Where things are going to be lacking is multiple windows and getting the developers to support Git interpreter officially - but you could hire someone (and I’ve updated the Git to newest on Github). In some ways, your needs are easier because you want it to just run the features your story needs - and the reason the devs are reluctant to support Git interpreter is due to people wanting it to support loadable games of all varieties like it does for z-machine / z-code.. Re-purposing it as a single-story app for Play Store in some ways simplifies things. It’s not like AndroidIF is a “supported app” either.

I’ll be up front: Quixe is well done and feature complete. Phonegap/Cordova will run it on both Android and iPhone basically the same way. You could make an app with Quixe that will work in airplane/offline mode. You aren’t going to find something that has all it’s capabilities on Android immediately. As you noted, AndroidIF isn’t feature complete. Nor is Incant, Twisty 2.0, and Son of Hunky Punk. If you go with compiled C code - like Son of Hunky Punk & Twisty - you are going to have more device problems on Android. It isn’t like Apple and iosglulxe where there is the consistency of only a select set of supported devices. You will get user complaints that it crashes on certain phones and tablets that you may or may not have access to. Going Quixe is probably the “safer route” for Glulx because Phonegap/Cordova is rather popular and proven compared to any of these Android interpreters.

Every one we are talking about is open source and you could make your own app from for the Play Store just like AndroidIF. But not every one has step by step instructions as clear as AndroidIF does. Even Quixe lacks a “step by step” to building an app for Android.

Yes, I already know about Son of Hunky Punk, I have it installed on my phone.

If I had the money! :stuck_out_tongue:

Well, it’s just a matter of pressing the release button in Inform 7 and putting the generated files into PhoneGap. No need for a step-by-step solution.

As I said, I know nothing about Android development, but I know enough HTML and CSS, and I guess I can manage, with Google’s help, the Javascript for the additionnal features I need.

I’m just trying to see if there is an “easy” way within my abilities and my means to publish to Android. (Luckily, I don’t have to look for iOS, thanks to zarf!)

I’ll try experimenting a bit more with PhoneGap and we’ll see. It’s not urgent.

Good luck. Your posts did inspire me to get Incant code on github updated up a bit. I’m working on that right now and I can put up an apk.

I would look Ionic over PhoneGap (which I didn’t think was still a thing).

Ok, the best-working Glulx feature-wise on Android is Incant, in my view. I just forked it fresh on Github with some of my previous unpublished work. It was 2.5 years untouched and the original author seems to be busy with other things.

  1. I restructured the source code and updated things. It now is ready to go for Android Studio version 2.2.3 project. Builds with Android SDK 25. There are two forked Github checkouts you need, the second probably probably needs to be checked out manually as I don’t think I got the submodule include setup correctly.
  2. I added newer Android permissions check that Android 5.0/6.0/7.0 have so it doesn’t just fail without any idea why.
  3. I added some code to try and deal with crashes it had when you rotate the screen or otherwise change away from the Activity due to it trying to save the active game in the instance. Some games are too large to do that with and I have a switch/case in the code for different strategies you can use to do better than what the 2.5 year old code did (which was just crash the app).
  4. I disabled speech out. If you want to see that, compile it yourself and/or watch the YouTube video the author posted. It makes testing it as Glulx interpreter too slow.
  5. I disabled speech recognition input for same reasons. But it is a feature you can enable in the code. The README has some grep targets to look for if you want to do this quickly.

The new fork, github.com/WakeRealityDev/incant

You can download compiled APK for side-loading on Android devices here: github.com/WakeRealityDev/incant/releases - the TW_x tag releases “for Thunderword”.

Unlike the current AndroidIF code, you don’t need to use any special extensions to run your Glulx code on Incant. It also knows how to unpack gblorb files, which is lacking in AndroidIF. I had forgotten that this was a couple of the technical downsides to AndroidIF. Incant’s performance can be slower than Quixie on Chrome (same Android device) - that’s the reason I stopped developing against it - because I didn’t have the technical skills to optimize a Glulx interpreter on the Android Art runttime. But it’s plenty fast for most games in my testing! I have no idea how AndroidIF’s performance compares, I didn’t benchmark it. If someone does compare them, please let me know. For benchmark: I suggest Bronze (source code is on Github to compile it to Glux on Inform 7 6M62 github.com/I7-Standard-Examples/Bronze ) as reasonable performing complex and Counterfeit Monkey as extremely difficult (it’s slow on many established interpreter apps).

So, I tried to make a Quixe app with Ionic (thanks DavidC for the advice).

It’s more of a proof of concept, but it works quite well. You can see the result here. The main issue is that the keyboard flickers wildly on Android, and it is impossible to hide it. It works well on iOS however.

What do you think? Should I continue working on it or would it likely be a waste of time?

I think there are authors who will want to publish that way. I’d encourage it. There could be some plugins for Ionic to deal with the Android keyboard issue, such as github.com/driftyco/ionic-plugin-keyboard

I know back in December I had some reports of crashes with the APK for Incant! - I have just now put it up on the Google Play store as an alpha-test release so I can get back crash reports. The code has had some more work done on it since Q P Liu 's original 2014 release and my December 2016 APK - it now saves preferences concerning it’s audio interfaces (the menu checkboxes on opening page).; It is fully open source and along with AndroidIF - I think a useful app to base a self-publish release on for Android. Link to technical demonstration on Play Store: play.google.com/apps/testing/co … ity.incant - It’s also a nice and small APK, under 650K.