Fictionarium, successor to Fabularium

I think you have to specify the full path to the folder.

Probably not, but keeping games in one folder is a good idea in my opinion :slightly_smiling_face:

1 Like

Sorry for not posting so long. This post is just to let you know that I am still working on it.

There are a lot of things that need to be done:

  1. Renaming the project with the new icon.
  2. Getting the project to build at all with the new compilers (both for the outdated garglk used by the project using the latest clang as well as the updated Android SDKs).
  3. The file management mentioned in the previous replies with access to Downloads needs actual complete revamp. If we want users to install and use the app without rooting, then we must limit access to the app folders and that needs a redesign in how it works.
  4. I think we need a better integration with ifdb. An experience where the user just installs the app and can find a game to select and play from the app. This the far reaching goal I want to get to (there is a lot of work to get to there, but I hope to get there in time).
  5. Bug fixes on this thread and the original Fabularium one should take precedence.

Many things to do. So, I apologize for starting the hype and then not giving anything to play with :smiling_face:

Please do stay tuned. I will try to get something out as soon as my other commitments (day job, family, etc.) allow.


Limited access to folders is the worst thing about Android. It’s like the mobile computing powers that be want to make each file accessible to only one app, undoing the 40-year-old file-centric computing paradigm. I have a half-dozen IF interpreters on my phone. Why would I want to have that many copies of each story file?

1 Like

While I do somewhat agree, I also see the reason why they went into this direction. For example, Fabularium as an app, could access all sorts of data from other apps. If those other apps would implement some sort of tamper or encryption protection by default there would not be a problem. But many don’t.

There is an important warning in Fabularium that you should not point it to a system directory… It might inadvertently destroy important data on your system. That warning is not needed any more: it is already prevented by the system.

To us, this is a nuisance. However, lot’s of users just click “I agree” and “OK” to give a shady app access to everything on their phone. Fabularium and Fictionarium are open source, anybody can see what the app is doing and shady actions are at least somewhat discoverable (hopefully not at the mercy of the same exploit as xz fiasco).

All of the apps in Play store go through a review process but it’s not whitebox: they only test what happens in certain scenarios. If an app asks for readwrite access to all the data on the phone they might review most scenarios where it’s ok, but a shady app could hide its nefarious intent from them. So, their review process would require whitebox review, which is about 10x more difficult than blackbox with just a few permissions and removing the ones that are really problematic to review.

Long story short: I understand and mostly agree with what they did. Even if it does make my efforts a bit harder.

I would like to know, though, why do you have so many interpreters installed? What is missing in Fabularium that you want to use a different app? It won’t be soon, but I do take feature requests for Fictionarium and maybe we can address your use cases in future releases.


Keep all your story files in an app subdirectory. Attempts to access any files outside is a world of pain.

They’re not very big anyway, and can be regarded as an offline cache. Perhaps allow a cache size option. The app will just delete the oldest as required and download on demand.

Only if there is a way to turn this off, or maintain persistent files separately. The ability to load and retain custom story files (that may or may not be on IFDB) is very important to anyone using the app for beta testing, etc.


Good idea. or allow the “size” to also be “unlimited”.

I second this. Apps should never assume I’m going to be able to get stuff online, and certainly should never delete stuff without my consent.


Does anyone know what Scott Adams game format is supported in Fabularium? The wiki says that the interpreter supports the scottfree format, but it doesn’t open the corresponding dat files.


Looking into it now, but I have a guess what the problem is.

As discussed above, Fabularium depends on IFID to create each game’s /GameData directory.[1] When I use the “Add to Game List (manual)” option and fill in the IFID field, the game is successfully added. When I use “Add to Game List (auto)”, however, Fabularium adds the .dat file to its /Games directory but doesn’t create the corresponding /GameData directory, so the game never appears in my library.

I haven’t double-checked this, but it’s the most likely explanation I can think of.

  1. This already causes problems when testing multiple versions of a game, or if an author mistakenly reuses an IFID: Fabularium can’t add a game with any IFID that already has a /GameData directory. ↩︎


I checked, this method works. Thanks!

Glad to hear!

If you ever figure out how to use Fabularium’s alleged support of HTML games, let me know—that one I’m still stumped on.

Well, I think your way works great for html games as well. Unzip some twine game, specify the format “html” and you’re done! I haven’t figured out how to save yet, though. Perhaps it depends on whether the game itself has such an option.


Huh, really? I can add the games to my library, but every time I’ve tried to open one, the app has immediately crashed.

Sounds like that might be an issue on my end rather than a general Fabularium issue, then.

Yeah, I was surprised, too. It all comes out so easy. Are you using the latest version? Check the error log file. Maybe it’s the file itself?

Hm. Just tried downloading a different twine game, and oddly enough, this time it worked! Maybe I did something to mangle the ones I was testing with before? Ah well, at least it works now.

How is this project coming along? I’m certainly excited by the idea. Fabularium is okay but it’s got a lot to work on, and that isn’t going to happen anytime soon but I’m glad this is happening.

(Also, my next game is written in z-machine and no Android 'terp can support it without changes.)

1 Like

I was using the BEBEK terp for Adrift 5 games a lot. (Scare is only for Adrift 3 and 4 games which BEBEK is not good for) It is quite good for most games but a few games do not run properly. I understand that it was not based on the open source code of ADRIFT 5 which can probably explain the deviations. Would be great if Fictionarium could improve on this.

1 Like

Indeed my progress is slow. In the past two weeks it’s been superseded by my day job (I work at a startup and it’s really hectic at times).

That said, it’s been a month since I started the thread. In the mean time I have been cleaning up some of my work, that was made just to make it run on my phone and was not releaseable.

I hope to have an experimental version out in the next few days. And, by experimental, I really mean experimental. It would help me if you try things out, but there might be some severe regressions that I failed to notice. So, once it’s out, please don’t yet rely on it. I will be working towards stabilizing it, but getting a 5+ year old project off the ground is always challenging.

One more question: I ported the code to use the same version of garglk as is in use in F-droid with the addition of @Keltena 's fix. That base is 1,500+ commits behind official garglk. My long term plans are to bring the garglk base up to date, but since modification were made on to the base, I will need to figure out how to ease that integration in the future (that will take time but being a backend engineer with 20+ years of experience, many of those in C, that will feel like home :slightly_smiling_face:). So, finally, my question: what modifications are needed? Would the latest garglk run your code?


Yes, terp updates are in my plans. As mentioned in my previous comment, I do intend to bring the latest garglk into the base, but even that will take time. The bebek code base and changes there are still an enigma to me but will keep it in mind.

As soon as I organize the base of Fictionarium at least somewhat I will open an issue to address this. Will probably not be soon so please be patient with me :slightly_smiling_face: