Can I do this with Inform?

Hi folks. I’ve recently rediscovered Inform after years of being away from interactive fiction. I’ve had a game idea for years, and am wondering if Inform might be a good engine for it?

The basic concept involves space-based navigation in the spirit of lots of old MUDs/MUSHes/MOOs that had those sorts of systems. You had ships that traveled in 3-D space in real-time using simple vector trig for motion. You’d fly your ship with commands (“heading 30 mark 16”, “warp 8”, etc.) scan, enter other commands for system information, etc. But your character was still in a room, sitting at a console. “Look” would describe the room, “aft” would stand from the console and walk out of the bridge, etc. Even if I can’t support basic 3-D navigation, I’d be happy with a simpler vector-based solution that incremented X/Y/Z coordinates by a specified value each round.

So I’ll need real-time interaction, which I understand Glulx supports. There is a basic real-time extension, but it looks like that only supports setting one-off timers, when what I really want is an event that fires every second or so.

I understand there are better engines for real-time, but the more I think about it, the more I really want to do something like this with an interactive fiction engine. I want the space navigation to have a certain level of grit, but I’d like for the interactions outside of spaceships to have a level of richness. I’d like for players to wander around on planets, look up at the sky as a backdrop, see lots of generated text based on characteristics of the planet’s industrial/political sophistication, etc. and that’s a lot more possible with an IF engine.

Can Glulx be contorted to do something like this? Are there any good examples of repeatedly-firing timers triggering certain events in real-time, not simply one-offing themselves? I’m working my way through Writing Inform, but if this just isn’t possible or is highly painful then I’d rather stop reading now. :slight_smile:

Basically I want to get rid of turns entirely and switch to a model like the old Infocom’s Border Zone, where everything happened in real-time. Can I do something like this?


Twisting Inform into a realtime system is probably either going to be a lot of work or end badly.

But there’s no reason you can’t have the timer repeatably set itself, giving you a ‘real time’ effect, and that is probably the easiest way to do it. Make sure that the timers can only run code when the game is waiting on the player’s input. If they can interrupt processing of a player’s command you’re going to have all sorts of nasty issues.

One issue I foresee is that you won’t be able to use the Every Turn rulebook. You could create your own Every Tick rulebook and follow it every tick.
Another issue is that you will have to implement your own time keeping mechanism since the built in one just counts each turn as one minute… and you aren’t using turns. But that’s trivial.

For your space travel; well, even in those muds, it wasn’t really ‘realtime’. It was just short turns that advance at a steady pace, without waiting on you. Every game ever is implemented this way, even modern 3d ones, so keep that in mind. All you need is short turns that don’t wait for input. Nothing fancy!

Any idea how Border Zone did it? Was the timer paused on player input? I remember there being a fast and slow mode specifically for slow typists, but it’s been decades since I’ve played that.

Though now that I think of it, I do like pausing the timer when input is being taken. It takes a lot longer to type “fire missile” than it does to pull a trigger, and the alternative is having short and incomprehensible commands. I may have those, but it’d be nice if the player could learn them rather than needing them to play.

Anyhow, thanks for the encouragement. I’ll keep reading through the manual and will hopefully have more ideas on how to implement this soon.

For my music game, I used a simple glulxe timer for real-time effects:

[code]Include Glulx Entry Points by Emily Short.

To set the glulx timer to (N - a number) ms:
(- glk_request_timer_events( {N} ); -)

When play begins:
set the glulx timer to 500 ms.

A glulx timed activity rule:
follow the music playing rules. [or whatever processing you want to happen every 500 ms][/code]

And you can of course change the 500 ms timer length to whatever value you want; every half-second was all the granularity I needed.

In Borderzone, it is sort of the other way around: the timer is only running when waiting for player input. Infocom implemented it by extending the interpreter opcode that reads input from the user: every 1/10 second it called a separate function, which advanced a counter and, depending on its value, caused the opcode to stop reading user input and go do something else.

Using timers in Glulx is certainly one possible approach, but it does get quite hairy, as if you want to interrupt player input you’ve got to mess around with the low-level library code that handles player input: you also need to worry about what to do with the player’s half-finished input: do you put it back after whatever new text has appeared? Speaking as a player, I found that very annoying in Borderzone.

If you don’t want the timer to interrupt the player, an alternative (and likely easier approach) would be to use the date/time functions added to Glk (the user interface layer of Glulx) (see [url]Glk time and date functions]). That would let you get at the current system time, which you could use to see how long the game has been running since it was started to make decisions about what to update after processing player input. You’d need to worry about restoring a saved game when doing that, though).

This is all definitely possible – I set up the Glulx system with Border Zone as a target case. It will probably require some low-level hacking. (You can either leave half-finished input on the input line, or discard it, your choice. You can even put back some different text if you want.)

To a first approximation, an IF game is always waiting for input. Command-processing occurs in imperceptibly short intervals between input waits.

(The approximation breaks down on slow interpreters, of course. That’s when the player perceives “lag”.)

It sounds like you want the timer to run while waiting for input but only when the input line is empty – pause the timer as soon as the player starts typing.

There are two problems with this. First, I didn’t design Glulx for that case; it may not be possible to make it work smoothly. Second, the player will immediately catch on and use the space bar as a pause key.

You could modify Jon Ingold’s Interactive Parsing extension, which reimplements standard input so that each keypress can be tracked separately, to pause the timer when the player starts typing. But Zarf is right that that is a pretty bad design, even if it is technically feasible.