I put together a simple GitHub project to demonstrate the makefiles and a working structure to compile Glulxe + RemGlk to run on all the CPU variations of Android devices.
I tried this out and it compiled without problem using NDK 13b.
I’ve been meaning to pick up on our conversation about using JSON. It looks like we’d have to extend I6 to emit JSON for a richer interface to internals, and this could either be incorporated into remglk or go around it.
However, the first part would be how to build such an I6 extension. Do you know of any examples or templates to do this. Most extensions deal with adding new functionality to games, but this is different because it would have to (somehow) create and emit information to a new channel/window.
That’s the bit i need to know how to do.
Thank you for the testing, QC.
Well, you don’t really need to emit JSON from the inform level, from a RemGlk perspective that would be “JSON within JSON”. They key technique is to do what I think around here is called “channel I/O” - which FyreVM extensions for Inform 7 do this. Essentially a zero-size Glk window (invisible) TextBuffer can be an output target to send either fixed or multiple commands. For example, “roomname=Tavern Bathroom” sent to command channel. The command channel concept is “cleaner” in terms of legacy fallback, as older interpreters should ignore the stream of data.
Alternately, develop some kind of tag system in the main window stream. Example tag system: _|ADDIMAGE: _|GRESET: - Worldsmith story does this, here are some details: https://intfiction.org/t/game-of-worlds-technical-postmortemy-things/10734/1
As far as extensions for out-of-band, Vorple this year was enhanced to support two VM’s, both Z-Machine and Glulx, so it has a couple sets of extensions to reference. And I would look over FyreVM extensions.
Essentially we are talking “out of band I/O”, how to get Inform to send things outside the visible content. Technically this can be done with no extensions other than ones for creating a second window (multi-window Glk stories go back more than a decade, such as Jon Ingold’s Dead Cities). Vorple uses Glk files written to disk that it expects to be read, I would discourage this approach based on my experience working with it. Sending unicode text right to a hidden Glk TextBuffer window would accomplish the same thing and also can work remotely (the disk files that Vorple creates would only be on the server in a RemGlk situation, the client would have to download the files out of band or RemGlk software enhanced to send file data in the stream).
Worth nothing: Typically we are not talking massive amounts of data being exchanged. Mostly triggers, variables, etc. Mostly I think authors want to have predictable timing tied to the story narrative and information on what action or media they want (name of an asset such as a video file to play, etc). This is typically bypassing the legacy asset systems such as blorb files to work with a secondary asset system.
A related project has just been added to GitHub.com to build RemGlk+Glulxe using the clang compiler and CMake system of Google NDK 15c.
Once you get the source code in place, there is no longer any need for a shell command line to compile the C code. Android Studio should compile the Glulxe interpreter and bundle it directly in the APK generated.
The CMake build system has now been structured as a library and packaged with a a sample app named Thunderfall that can do primitive parsing of the RemGlk JSON and basic input of Glk character and line modes. The JSON parsing code is largely taken from the February 11, 2017 release of Thunderstrike example app on GitHub. But now you can completely compile RemGlk + Glulxe and run them all in a single app. The code also demonstrates how to include a story data file in the APK assets and to extract it to play. Link: github.com/WakeRealityDev/IFTer … droidCMake
This puts the technical side all on the very latest of Android Studio and Android NDK 15c. Now it’s all pure in the new CMake system and demonstrates how a story author could bundle their story into a distributed APK. All the added Android stuff is licensed Apache 2.0 - which allows liberal use of the code, including commercial.
Bundling a story into a distributed APK? Heaven help us! You’re talking about undoing ALL of the benefits of the traditional interpreter/story file separation.
Oh, well. It failed to catch on when they were doing it with Windows EXE files. Hopefully this idea dies quickly.
You don’t always want separation.
If you want to publish your story as a product, you’re going to need it bundled all in one, regardless of how it works internally.
I clearly don’t understand your point. There are thousands of interactive fiction stories being published on Google Play, Apple iTunes, Valve Steam, etc this way. It’s a topic of conversation (how-to) on these forums years before I came along in 2016. In fact, that’s exactly how Zork and classic IF is distributed - binary interpreter + binary data files in one “application” set of files. Putting a gblorb file inside of an APK in the assets directory is no different than putting a JPEG or GIF file or audio file or any other data file. It doesn’t even encrypt it, you can use unzip to extract the story right out of the APK. An APK is literally just another name for .zip file. The app is entirely self-contained, never accesses the Internet, and can play offline - such as in airplane mode. Doesn’t the Inform 7 IDE essentially do the same thing to create a bundle of the story data file + Quixe?
The Inform 7 IDE actually releases a base-64-encoded version of the game file, so it’s a bit of trouble to extract the original.
But yes, the entirety of the IF renaissance of the past several years has been about packaging up game files. Nobody has to see that “traditional interpreter/story file separation” unless they really, really want to.
Posted on GitHub just now: In addition to Glulxe CMake file, there is now a git checkout script and CMake file for Git, Magnetic, and Level9 interpreters.