Managing Context

Authoring Inform 7
1

So I’m backtracking (again) through my Shadow code to expose data for UI purposes. This time I want to build word lists based on the state of the game. In order to do this, I need to manage the context of things, rooms, and doors.

I started out with a strongly-typed solution:

StoryContext is a kind. The EmptyContext is a StoryContext.

A Room has a StoryContext called context. The context of a Room is usually EmptyContext.
A Thing has a StoryContext called context. The context of a Thing is usually EmptyContext.
A Door has a StoryContext called context. The context of a Door is usually EmptyContext.

Section - Room Context

player hid in clockcase is a StoryContext.
player listening is a StoryContext.
abbot left quarters is a StoryContext.

Book - Word Lists

Word List is some text that varies.

Every Turn:
	if the player is in Abbot's Quarters:
		if the context of Abbot's Quarters is EmptyContext:
			now Word List is "hide/in clock, look/at cot, look/at clock, look/at desk";
		if the context of Abbot's Quarters is player hid in clockcase:
			now Word List is "go/west, open/the door";
	if the player is in Inside Clock Case:
		if the context of Inside Clock Case is EmptyContext:
			now Word List is "listen/with/tumbler";
		if the context of Inside Clock Case is player listening:
			now Word List is "listen"

I’m nearly positive that this is overkill. I could add a text property to Rooms, Things, and Doors and change that:

now the context of Abbot's Quarters is "the player has already hidden in the clock";

However, no one is going to read that sentence…it’s only for logic within the source. And too, comparing the context to a long string is silly.

I see this as sort of meta context, not game logic context. Or, one could consider it UI context. There is the danger that I will be managing game and UI context and missing things, but I have this nagging feeling that I want to keep their implementations separate…I can’t define why I feel that way. I just do.

Does anyone have any thoughts on guiding me to an optimal solution?

David C.
www.textfyre.com

2

Well, what immediately comes to mind when you display the use case that way is to give rooms, scenes, regions, items, NPCs, et cetera the ability to individually contribute words to a wordlist, and you’d then build a wordlist out of everything applicable or scoped at that point - not by having an inherent idea of what the wordlist would be in a given situation, but by building it out of the (more generalized) context of the state of the world.

3

So the logic would be?

var global word list

for each in-scope items:
get item word list
add item word list to global word list
next

return global word list

4

I don’t think you want to build the list explicitly, but use whatever reflection capabilities at your disposal to query the current state of the world. One question is how far back in time you’re going to want to look when you ask ‘what is the state now’. Does it matter that the player was listening in the Abbot’s Quarters ten turns ago?

5

No. I only want the state of the current location in the current context. History does not matter.

6

Random thoughts:

Comparing long strings in I7 is as fast as comparing object references or integers. However, for a case like your sample, you might as well say “StoryContext is a kind of value.” That way they’re represented in the compiled file as integers, rather than object structures – saves some memory.

Your code sample has a very simple model – a thing/room/etc has no more than one context value. That might not be sufficient. On the other end, vimes’s model is very general – perhaps too broad for what you’re trying to make happen.

Where, ultimately, do these word lists come from? From the player’s current environment? From the next move the player is supposed to take? From the possible next moves the player might make?

(The second and third options are game logic, like it or not.)

7

Yes, please tell us a little more about what these word lists are. How are you planning to use them?

Interaction designers (of some breeds at least) talk about affordances, how to design something so that people can look at it and just know what to do with it. Push? Pull? Turn? Slide?

Maybe you can do something inspired by this in IF, letting the things in the world list some things the player can do with them. Everything can be examined, portable things can be taken, doors can be opened and closed, lockable things can be locked and unlocked, etc. (I do realize there are complications with combinations of things, conversations, etc…)

But I’m not sure what you are trying to do. Are you looking for an exhaustive list of things the player can try? Or just the good bits that will take the story forwards? Because those are two different things.

8

So there were requests for a demonstration of my intent. I built a rough HTML version of what I plan for a touch interface. It mostly functions how I intend things to work. I haven’t done the compass rose and I’m debating whether just words are good enough. Kids/newbies are probably not going to care about a compass rose. It could be that a compass rose is a design feature of individual games. A game set in space probably wouldn’t make sense to use a compass rose.

shadow.textfyre.com/cbdemo/

I would leave the functionality open so that the player can click words entirely in the wrong order. The parser will respond appropriately or I may add some intelligent sentence repair logic to infer intent.

So my word lists would flow into this control.

Thoughts on building word lists and the control are welcome.

David C.
www.textfyre.com

9

So this is the direction I think I’m going. For each location and context, there is an action list. The command list will be created based on valid exists. The answer list is loaded when the parser asks a question (like did you mean x or y? or a Yes/No question).

[code]Book - Context Management

StoryContext is a kind of value. The EmptyContext is a StoryContext.

A Room has a StoryContext called context. The context of a Room is usually EmptyContext.
A Thing has a StoryContext called context. The context of a Thing is usually EmptyContext.
A Door has a StoryContext called context. The context of a Door is usually EmptyContext.

Section - Room Context

player hid in clockcase is a StoryContext.
player listening is a StoryContext.
abbot left quarters is a StoryContext.

Book - Word Lists

Action List is some text that varies.
Command List is some text that varies.
Answer List is some text that varies.

Every Turn:
build the word lists.

When play begins:
build the word lists.

To build the word lists:
build the action list;
build the command list;
build the answer list;
select the words channel;
say “[Word List]–[Command List]–[Answer List]”;
select the main channel.

Table of Action Lists:
location context word-list
Abbot’s Quarters EmptyContext “look,look at,hide,examine,search/in,at,in the,the,under,behind/cot,desk,clock,door,abbot,window”
Abbot’s Quarters player hid in clockcase “look,look at,examine,search/in,at,in the,the,under,behind/cot,desk,clock,door,abbot,window”
Inside Clock Case EmptyContext “look,look at,examine,search,listen,empty/in,at,in the,the,under,behind,with/cot,desk,clock,door,abbot,window,tumbler,glass,polish”
Inside Clock Case player is listening “look,look at,examine,search,listen,empty/in,at,in the,the,under,behind,with/cot,desk,clock,door,abbot,window,tumbler,glass,polish”

To build the action list:
now the Action List is “”.

To build the command list:
now Command List is “inventory,score,time,help,hint,about,north,northeast,east,southeast,south,southwest,west,northwest,in,out,up,down”.

To build the answer list:
now Answer List is “”.
[/code]