Just wanted to announce that I have recently released Fabularium, a free Android-based GLK implementation with extensions to handle TADS HTML. Search for “fabularium interactive fiction” in the google play store.
I’ve been working on this in my spare time for a few years now and I feel it is now at the point where it can handle pretty much anything you might throw at Gargoyle, plus extras - eg TADS multimedia. The app is also able to create IF, using the Inform 6 and TADS 3 compilers. Still polishing source code, but intend to post that to Github or similar in the not-too-distant future.
Would appreciate feedback from anyone who has the time / inclination to try it out. Some parts are still a little rough around the edges (e. g. the text file editor), but not terribly motivated to polish further until I know there is some demand for it.
Hopefully this will help encourage more of the Android community to get into IF.
I don’t know if everyone seeing this realizes just how long Android users have been waiting for a Glulx/TADS/etc. app that “just works,” let alone one with attractive typography, cover art, extensive options, text-to-speech, full multi-interpreter support (!), HTML TADS (!!), and built-in compilers (!!!). Even the keyboard is thoughtfully designed. I’ve tried every incarnation of a Glulx player that’s ever been released for Android, and even developed an (unpolished, unreleased) one of my own, and this is literally my dream app. Inexpressible thanks for all the time you’ve put into developing this!
Feedback: gameplay seems smooth and stable thus far. There are a few features that would be nice (like autosaving games when you press the “Back” button, rather than telling you to type “quit”), but having fought with the garglk terps on Android myself, I understand why this may be technically nontrivial. Two more minor feature requests:
Better formatting of boxed quotes in Z-code games. Many older classics, such as Curses! and Christminster, put a lot of effort into making their splash screens look good, and for some reason modern interpreters tend not to handle this very well. Try launching Curses! in Fabularium vs. desktop Gargoyle and you’ll see what I mean.
The metadata retrieval tool is spectacular, but it would be nice to be able to edit metadata manually (particularly the name and cover art).
The app also tends go unresponsive when you open a game file rather than selecting it (in the Explore tab).
Thanks for all the positive feedback! Nice to know people are enjoying the app.
Yes, autosave is a feature that I would really like to see also and yes it’s technically non-trivial to implement across all IF formats. A key issue is that the GLK layer (which is what Fabularium implements) only maintains the state of windows, text buffers, etc. It does not “know” anything about the stack, RAM, ROM, etc., managed by the terp - and different terps will manage these things in different ways. So preferably autosave would be initiated by the terp, which would save its current stack, etc., then call through to the GLK layer (in this case Fabularium) to save the GLK state. I believer this is how Andrew Plotkin does it with Glulx - see https://www.eblong.com/zarf/glk/terp-saving-notes.html. I may be able to get Fabularium autosaving games when the Glulx terp is used; however I probably won’t get it working with the other terps unless the authors of those terps release updates to support it. I don’t want to go in and start making major modifications to terp code.
Another option might be to have Fabularium save the complete memory state of the terp + game and then restore it, but that’s a very crude solution and would probably fail for bigger games on memory-limited devices such as older phones.
Yep, I’m aware of this issue also, which occurs on devices with small screens. However I think you’ll find the problem is present in Gargoyle too. To see this:
Work out effective screen size (in rows and cols) when running the story on a device with Fabularium. You can see what the effective screen size is on your device via the keyboard - press FN, then press and hold “B” (DBG) until a message comes up saying “debugging mode is now on”. Then press “W” to dump current windows sizes. [Incidentally, when in debug mode “M” will give you memory usage and “S” will give you stream info; hold “B” again to turn debugging mode back off. Sorry, like a number of other features this isn’t documented yet. Another undocumented feature that might be useful is that you can paste clipboard text into any text buffer by long-pressing that buffer - if the text includes new lines, Fabularium will issue the commands one at a time.]
Now fire up Gargoyle with the same story, constrain the Gargoyle window to the same number of rows and columns, then restart the story.
I can’t vouch for Windows, but I fired up the Linux version of Gargoyle just now, constrained its window to the same rows x columns dimensions as Fabularium on my phone (2 rows x 46 columns), and the attached screenshot shows the result. Looks almost the same as Fabularium.
Conclusion: the issue is either present in the terp (in this case Bocfel) or the story (in this case Curses).
Agreed. And unlike the earlier point this is fairly trivial to implement, I just haven’t got around to it yet. Watch future releases…!
Yes. The way the Explore tab currently works is very simple - if you click on a directory it navigates to that directory. If you click on a file, it tries to open that file in a basic, built-in text editor. The reason why the app goes unresponsive when you click on a game in that tab is because it’s trying to load the contents of that game into a text view. And for a game that is more than 1 Mb or so, that eats up memory quickly. Try opening your games in Notepad on Windows or gedit on Linux and you’ll see what I mean. So this is not so much a bug as a user interface that needs further work. I think in future versions I’ll detect when the user is trying to open a large file in the text editor, then pop up a message checking whether they really want to do that (and warning that it might lead to an ANR error on mobile devices).
I don’t have a Kindle Fire HD, so unable to test. But the app should run on any version of Android from SDK 16 (4.1, Jelly Bean) onwards, and the Kindle Fire HD uses a forked version of Android that is presumably more recent than that, so - assuming the forked version didn’t take out any core bits - the answer is “probably”.
Current priorities for next few releases:
Improve stability and performance
Improve accessibility (including for the blind/vision-impaired, and for people who want to use a language other than English - i.e. translations and keyboard support improvements)
Additional features to reduce typing - e.g. perhaps recognising swipes / gestures for particular commands, perhaps keyboard buttons that can be programmed for specific commands, etc
Edit metadata functionality (and show a progress spinner when user is downloading metadata so people on slow connections don’t think the app has just frozen)
Implement the remaining few TADS HTML tags and support TADS resources that are bundled separately (e.g. *.rs files)
Improve the user-friendliness and functionality of the “CREATE” feature: I’d love to see this app help budding authors to get their great IF pieces up and running, and at some point I’d like to include a “SHARE” command to help people easily send their masterpieces to each other (and the IFDB) via email, WhatsApp, etc.
If anyone has a burning desire for a new feature that’s not mentioned above, please do let me know.
Thanks again for the feedback and if you like this app, please consider rating it. Aside from motivating me to keep working on it, more reviews will help it move up in the Google play search rankings so other people can find it.
And if you hit up against bugs, crashes or other frustrations, please let me know at email@example.com.
I have played my work in progress again, and the only issue I have encountered so far is that Fabularium does not clear the screen at the expected moment. (I have implemented clearing the screen using TADS 3’s cls() command, FWIW.)
Fyi, Fabularium has a few currently undocumented features that might assist the development of your work:
If you want more verbose info on how Fabularium is running your work, you can check out the terp.log and glk.log files under the Fabularium folder. These files are (re-)generated for each play session. Terp.log captures messages (including any errors and warnings) from the session’s terp, in this case tads. Glk.log captures errors and warnings from the Glk layer (e. g. if a game tries to send text to a window that doesn’t exist). There are a few less common TADS html tags that I haven’t implemented yet; if Fabularium encounters one of these you should see a FIXME message and explanation in glk.log.
If you want to see the raw html that your game is sending to the Fabularium GLK layer, you can enable that in the settings.
After looking deeper into this the problem seems to be on my end.
I had written code that looked something like this:
"A creature came out of nowhere and snuffed out the flame of your torch,
plunging the cavern into darkness! <<inputManager.pauseForMore()>><<cls()>><<me.getOutermostRoom.lookAroundWithin()>>";
But have since modified it to make it like this:
"A creature came out of nowhere and snuffed out the flame of your torch, plunging the cavern into darkness! ";
(I have not tried the sample code, but hopefully it gives some idea of where the problem was.)
It seems to me that the second implementation is better coding practice, but I am not sure what should happen if an author decides to do the former. FWIW FrobTADS handled it with only one minor hiccup – an extra paragraph break after the text. (Trying to track down the reason for the unwanted break is what led me to the solution.)
Wonderful app. Can’t wait to use it a lot. It’s opened up a whole new world of games I couldn’t play before on my phone.
Have a problem playing 1896 World’s Fair Mystery. The text is squashed up beside the photographs to make it unreadable. Can’t find the settings that may address that. I’m using a Samsung Galaxy A5 2017.
Edit: I already forwarded feedback to the developer, who was kind enough to respond in full. I have great confidence in the future of this project but it looks changes might be months ahead. Someone should invent some cloning technique so that at least one of him can commit more time to the project.
Wow, what a gem.
I stumbled upon Fabularium in the Google Play store while searching for text adventure related downloads. Until now I was using Text Fiction (its conversation-style interface lends surprisingly well to IF) but it supports Z-Code only and unlike your app, it can’t handle some of the Z-Code display output (status line, menus).
But now this treat, a whole bunch of engines in a single neat package. I’m so happy that I can now finally play my Magnetic Scrolls collection. I know there is another developer currently appifying (and selling) Magnetic Scrolls games, but their interface choices haven’t really been to my taste so far and anyway I prefer having a single app with a personal game library.
I love Fabularium’s library with thumbnails, the easy import of (zipped) story files and the metadata download. The interface for playing games is very focused (full screen, keyboard never hides) and despite the ever enlarging text feed which I suppose is rendered in HTML, the app remains responsive. There’s also no noticeable battery drain. In short, awesome work so far! My new favorite mobile IF app!
I do have some issues I’d love to see being solved as well as suggestions for changes and features. I apologize in advance for the long read. BTW I can’t comment on writing games as I haven’t tried that yet.
First some issues I’ve encountered:
Magnetic Scrolls image files don’t seem to be showing, even if the are in the game’s directory.
I accidentally hit the navigation keys (< > etc) a lot while typing and they make weird characters appear in the input line. These characters seem to be ignored by the interpreter I’ve tried, but it doesn’t look nice.
Double-tapping a word in the text, which writes it on the input line, also includes interpunction (dots, comma’s, etc). I think that tapping words should only include alpha-numerics. It also sometimes copies two words when the words are short.
The save / restore process in the Magnetic Scrolls interpreter interacts a little weird with the app. The interpreter asks me for a filename and a confirmation, but the filename is ignored by save dialog. I know interpreters apply their own rules on save and load and you can’t always break into that, but I think at least the filename should be passed to the shell application.
Now a wish-list worthy of a spoiled kid’s birthday:
I’d like to see a list view rather than the currently very small icons. This should allow for larger thumbnails as well as a bit of text from the game blurb, publisher, rating, or other metadata you find appropriate.
A new sorting option for games: date last played (started), so that games I’m currently playing bubble to the top.
Once a game is imported, I think a metadata download should be started automatically, because I end up doing that for every game import anyway. The ‘Get Metadata’ option can then be changed into ‘Refresh Metadata’.
I think our editing options on the input line are rather limited. I guess this is because you want to be true to the original games where the input line is integral to the text feed. But, because it’s not a native input field, we miss out on all the Android built-in benefits. For example, when I notice too late that I made a typo at the start of the line I now have to backspace everything away and start typing again, rather than moving the cursor by tapping the place to put it, or tapping a word and use spelling correct, or automatic spelling correction. So I would really like to see a native input line introduced, which simply adds the final input line to the text feed after pressing enter. We then get benefits like spelling correction, adding words to a dictionary (spell names come to mind in some games, or names of characters), and word prediction. In the same vein, some sentences that are reused a lot in a game (“Consult guide about”) become part of word prediction suggested by these dictionaries. If it is possible in any way, it would be great if for each game the app could build up its custom dictionary and word prediction (as so they do not interfere with other games). I don’t know what the feasibility is of this, these may require games to create sub-language on top of the current language (usually English). However they should not become a default dictionary for the entire system.
Alternatively, at the very least it would be nice to have the keyboard extended with a fold-out of icons for common actions (examine, get, drop, inventory, open, close, lock, unlock) which can be configured / changed per game.
Other interface suggestions:
I really prefer a single tap to copy a word from text to the input line, because as it is it’s already challenging enough to tap a word once (maybe make this configurable?)
As mentioned in the issues, the navigation keys get in my way a lot, while most of the time I wouldn’t even use them. I would suggest having one button on the keyboard that switches to a secondary keyboard which contains these navigation keys, as well as keys that are regularly used in combination with them (tabs - space - enter?)
I love the ability to customize, but there’s quite the overwhelming array of settings to configure the display with that I think will realistically only be touched by people with a lot of perseverance to get it ‘just right’. I would suggest moving them to a theme configuration file, which people can edit using a text editor. The app should have a sample display with a refresh button to reload the config file so you can see your chages more quickly. You can then include a theme (down)load so that these theme files can be easily redistributed.
For people less inclined to programming, it would be great if Fabularium would support Inform 7 in addition to Inform 6 (I7 uses I6 behind the scenes I believe). I don’t know how hard this is to do, this will depend on the portability of the tool chain behind I7.
Quite the list but honestly I’m already very thankful for what you got us, I really hope that you find the time, motivation and community support to continue this project. So far, so awesome.
Problem with this is there are some games that rely on capturing individual key entries. I’m thinking specifically of Taco Fiction, but there are probably others as well. You do have the option of using your system keyboard, which probably has auto-complete built in.
You can change the default keyboard to “latin”. Just edit the fab.ini file and include the line “keyboard latin” near the top. The latin keyboard (which is defined in the keyboards.ini file) includes common IF keywords and navigation as long-press alts to standard keys. (I’m not sure why the latin keyboard isn’t the default one. It’s way more useful than the default one. My favorite feature is the dedicated “save” key.) If you play with the configuration files, it’s definitely possible to define a keyboard interface that applies only to a specific title, with custom commands (or even lists of commands) for particular keys (spell names, etc.)
My only bug report so far, which Fuzzy reported as well: The keyboard navigation keys do not work at all. The up arrow does not scroll through the command buffer. This would be a useful feature to have working.
Other than that, I love this app. Really, really nicely done. Thanks!
This is a different input method. For a Glk interpreter, capturing individual keystrokes means calling glk_request_char_event() instead of glk_request_line_event(). So the interpreter can distinguish these, and use native input in the common case.
I can’t give a whole lot of feedback on the app yet, but here’s what I have:
[*]The settings menu option doesn’t work on the Create tab. (And help sometimes didn’t on the Play tab)
[*]There is no feedback from the compile button. I couldn’t tell if it was failing to run, or just not understanding my code.
[*]Indirectly related to the second: I missed that the app supports Inform 6 creation, not Inform 7. The help screen section on creating games should probably say which version of Inform it can compile.
I want to add my voice to the request for I7 creation support. My primary motivation for installing was to make IF games on the go, and I’d much rather use Inform 7 than Tads.
That all said, there’s a lot of potential, and the general design seems pretty good. Thanks for the nice app.