Thanks for all the feedback and discussion so far.
I plan, at least for now, to have the creator build the game with Python, which allows for some true cross-platform (Windows, Mac, Linux + Online) as well as allowing the game code to be human readable.
I completely agree with the needs to future proof and have a stable backing, which is one of the reasons I decided to go with Python, which is a fast-growing and popular with institutions (such as banks), which means that it will be supported for hopefully a long time, plus it is pretty open with documentation and versions, meaning that the interpreter should work for a long time. (JavaScript is an idea, but I like the offline features of Python and am more comfortable in working in something similar for now.) As well, since most Macs and some Linux come pre-installed with Python, there is no need for a download of Python by the user, and for Windows, there is the note below about .exe files, but a Python download could be done quickly and a system within the game file could theoretically offer to take you right to the Python website for a download of Python 3.
The system will (probably not in version 1, but hopefully in an version soon after) have an ability to turn the game into a .exe file, though this would be optional for the game.
The game package the system will create will be a folder with a copy of the manual (if created by the author), a ReadMe license for the system & game, the gameās executable and any images/soundfiles required to be played (Images should be immediately supported, soundfiles may take time - Iām still looking into it).
Let me just add that Iāve been enjoying this thread! I still stand behind most of the arguments Iāve put forward, but thanks to the subsequent discussion Iāve gained some new perspectives and a better understanding of the full picture. Some of those insights are already turning into concrete design choices for Dialog and the Ć -machine.
I tried NativeScript. It looked interesting, although i tried building the demo and it gave errors. But i think you donāt really use javascript so much as a custom schema UI schema - but i think thatās the whole point of the ānativeā bit.
Capacitor looks interesting, Iāll have to have a fiddle with the Ionic framework first, as that seems to be the main idea.
Also, i now remember thereās also Electron, for desktops.
Iām glad to see the security aspect raised. For me, the Terp + game system works because I only have to trust the writer/s of the interpreter. The Terp āholds the game hostageā in a sense.
For example, I remember that TADS2ās default settings are that TADS only has write permissions for the directory that itās in (probably true of T3 too, but I donāt know offhand.) So I only have to trust Mike Roberts not to be a criminal/psycho/naive/incompetent, and donāt have to worry about the game authorās intentions at all.
So if we are talking about the convenience of one-click-to-play, Iād be interested in seeing a system that builds games that run in a sandbox. That way essential/ephemeral libraries could be bundled in with the game, as a means of at least partial future-proofing.
Sure it would make downloads bigger, but thatās only a problem for people like me, stuck with pay-as-you-go internet, and to be honest bulky items like hi-res backgrounds and video clips dwarf the size of most libraries.
For me, the issue of the code being open source greatly helps with the trust issue too (as well as being extremely useful when learning the system.) Once Iād gotten beyond the IF equivalent of āTeeny songs for Tiny fingersā I really found it helpful being able to take the back off I6, and see how Graham Nelson had done whatever was puzzling me that evening, and itās one of the things I miss about I7.
As well as that cool nerdy thing about the box being inside itself, of course.
