Hello,
This is my first foray into the world of creating IF.
I’m working on a project where the player is “stuck” in a virtual computer mainframe. The game is supposed to last over a period of a few day (real-time).
My questions are:
Can the “quit” or “q” commands be disabled and a message appear stating that “Quitting is currently impossible.” I’ve tried using the Understand command but didn’t have too much luck.
The game is going to be accessible to a few players simultaneously, and events in it will change as the days go by. Is it possible to update the narrative, while making sure that whomever is currently playing will have the updated version available as soon as they continue? In other words, the player will have a web-based terminal open with the game running in it. Once the narrative is updated, will the terminal update itself through some backend process?
I hope this is not too confusing.
As far as your first question goes, assuming you’re using Inform 7, check out the quitting the game section at alice-blue.github.io/parser-parer/#end-of-form I don’t know that it’s considered very good form, though.
As far as the second question goes, no idea, I’m afraid. What kind of web-based terminal are you discussing, exactly?
Thank you very much for the quick reply and resources.
The inability to quit the game is done on purpose, to give the player a sense of being trapped inside the virtual world. Of course they can close the browser, but the idea is to give them a sense that they are stuck inside this digital organism that takes control of their actions while inside it.
There actions will be constantly autosaved.
Since the game will be played on a web browser (using an interpreter that will generate HTML/CSS code) - the design of the terminal will reflect one circa the late 1980’s (Apple ][+ days). Hopefully, the generated web code will be easily modifiable to match the art direction.
Quitting prohibited is initially true.
Check quitting the game:
if quitting prohibited is true, instead say "Quitting is currently impossible."
However, don’t do this, because it’s annoying and pointless. If the player wants to quit, they can close their interpreter window or browser tab.
Edit: I see that you posted your rationale. I think that you should ask yourself why the player would be typing “quit”. Either they’re not very engaged, or something pressing is happening in real life. Either way, they’re unlikely to appreciate being told no as an atmospheric touch. (I think that a player is more likely to close the tab, or to walk away and come back later, than to quit, so it probably doesn’t matter all that much.)
You’ll have to be more specific about what you’re planning to do. Are players supposed to be able to see and interact with one another, or just experience the changes in the world independently? If the former, then that’s not something that I7 supports by default, and I’d recommend that you look at guncho or MUDs instead. If the latter, then you could deploy a new game file periodically, but saved games and in-progress sessions are unlikely to be meaningful in the context of the new file. I’d suggest baking the world changes into the original file that you deploy and using something like glk timer events or glk_current_simple_time to trigger changes based on real time.