Inform10 web front end word completion

So. A bit experimental, but i put in some word completion to my web front end. here’s Bigfoot Bluff by PB Parjeter as a test.

HOW:

Press TAB to get a suggested word completion, press it again for a different one. Often the first one is good.

Makes for much easier playing!

3 Likes

I like that. I think these features make IF much more accessible to newer players.

Does it cycle through all possible combinations?

  • Attack goblin with axe
  • Attack goblin with lantern
  • Attack goblin with bad breath

etc

Glad you like it! It would be nice if it could do that. But it would require some cooperation from the game.

One of my problems with the inform system is lack of metadata. The game engine appears unable to express to its environment even the most basic information. Such as:

  • The inventory
  • The current exits
  • The map in general
  • The objects in scope

I’m rather hoping that this sort of data could be made available through the compilation to C route. Eg by “well-known” properties that could be accessed externally. The run-time must know this somewhere. It’s a question of making it available.

I’d be interested if anyone can shed any light on this.

1 Like

The run-time doesn’t really know any of this information. The library has conventional ways to express it, but the game can customize any of it freely.

You could define standard ways for the game to express this information to the outside world. (This was pretty much the idea behind the TextFyre system.) But then you’re putting extra burden on the author to follow the standards, no matter how they customize the parser or world model. This is a hard thing to ask. Authors do all sorts of wild stuff, and judge the results by whether the game plays right! If you tell them “Oh, you can’t add objects to scope that way, they won’t tab-complete correctly” then 90% of them will just ignore you.

Thanks for the explanation. That’s how i understand it currently.

However, the run-time must be able to make certain well-known assumptions in order to calculate scope. I don’t know how inform does this, but one way, is that the system has to have a well-known notion of “in” between objects. And typically scope is calculated as the recursive set of objects “in” the thing the player is “in” (obviously this doesn’t take into account closed containers, transparent ones etc, but it’s the basic starting point).

As i was saying, Inform might not use “in” at all. But however it does it, it must have some relation or property or set of properties that are “well-known” to the runtime as “roots” of the scope calculation.

I take your point that the game can adjust scope. It seems the game can add or subtract items from scope. But it must be doing that in a way the system can discover, unless the game can redefine the scope calculation altogether. But i can’t see how that would be expressed in I7 (perhaps some i6 extension maybe).

That being said, I’m thinking there are some well known properties that can be hooked, given the game is not redefining huge parts of the runtime itself (which most don’t).

Am i completely wrong here, or might there be a way. Thanks for information.

The point you might not be getting is that the run-time system, if you mean the executable game file, doesn’t know there is such a thing as scope at all. That’s just code. The parser is just code. It’s slightly different code in every game, although most of the differences are due to what version of Inform it was compiled with.

You can’t just look at an object and say “attribute 3 tells you whether it’s a container and attribute 4 tells you whether it’s open”.

I take your point that the game can adjust scope

The game can also adjust exits, and inventory, and everything else you mentioned.

1 Like

uh ?

if I have read well, you have wrote a “cheat 'terp” ???

Agree that is useful for newbies, but I warmly recommend a metacommand on the model of HINTS OFF.

Perplexed regards from Italy,
dott. Piergiorgio.

Not so. It doesn’t suggest commands, but only completes words. Further, it won’t suggest something that hasn’t been mentioned by the game.

From my limited understanding of them, making in-scope things available to the terp would be plausible with Vorple or FyreVM, which allow backchannel communications. But support for it would have to have been coded into the game’s source in advance.

1 Like

Famously, the interpreter makes so few assumptions that the game can be… Tetris.

Check out Andrew Plotkin’s “freefall.z5”. I’ve quite enjoyed playing it.

So the interpreter runtime really knows absolutely nothing about commands. Everything which makes the game into Interactive Fiction is implemented in Inform code. It’s possible to have a framework of Inform code which provides hooks to the interpreter (as Zed mentioned), but it would have to be implemented on the game side.

This isn’t relevant to Inform 10, but an interesting historical note is that early versions of the Z-machine did expose more game-specific details to the interpreter. For example, the interpreter was responsible for handling the status line; for this purpose, the first global variable was always expected to hold the object number for the location, and the second and third globals were expected to hold the score and turn count as integers.

Details like these did make it easier to keep the game files small (the Scott Adams data format takes this to extremes) but limited flexibility. Version 3 of the format added options to customize the display slightly (such as displaying the second and third globals as a time instead) and version 4 onward gave up and passed all the responsibility over to the game, allowing for things like Trinity’s “location name only” status bar.

1 Like

It seems to me that i could just write a bunch of functions in
inform7/Internal/Inter/WorldModelKit/Sections/WorldModel.i6t that provide the necessary meta info and/or actually apply operations (or better, put them into a new section file).

For example, we have

[ CarrierOf obj p;
	p = parent(obj);
	if (p && (p ofclass K8_person) && (obj hasnt worn)) return p;
	return nothing;
];

That will determine if obj is carried, so a function to return the current inventory could iterate over child(player) and discard those worn.

There’s already a similar iterator defined thus;

[ TestContainmentRange obj e f;
	if (obj ofclass K9_region) {
		objectloop (f ofclass K1_room && f.map_region == obj)
			if (f > e) return f;
		return nothing;
	}
	if (obj ofclass K5_container or K1_room) {
		if (e == nothing) return child(obj);
		return sibling(e);
	}
	return nothing;
];

I don’t think games are in a position to redefine the basics of the world model, this this would be a solution for all games regardless.

The outside UI would just call these new functions directly in C.

3 Likes

Hunh. I hadn’t thought of that as a potential vector for backchannel communications. Nice.

1 Like