A quest list?

Authoring Inform 7
1

Does anyone know of an addon for generating quests lists? I’ve been trying to make a very basic one (one where you won’t know what a quest is until you’re given it, thus making it active, and also with the ability to view active quests in their own list), but i’ve been having issues getting it to work. I basically created a new thing called “quest” that could be either unknown, discovered, or solved. My problem is that I can’t seem to change this property after it’s already been set, inform won’t accept any variation of “Change QuestBlahBlah to discovered.”.

If there’s already an addon that makes quest lists, it’d save a lot of trouble. -_-

2

There are addons that make lists. There are addons that make using lists more… flexible? I don’t know anything about lists. I hear they’re resource hogs, so I’ve been avoiding them.

I suppose you could create a table.

Table of Quests
Name                                                  Discovered                       Completed
"Kill All Rats"                                        0                                     0
"Talk to Old Man"                                  1                                     1

Et cetera. Change the value of the discovered column when you need to.

If you’ve defined a thing with a property:

A quest is a kind of thing. A quest can be discovered. A quest is usually not discovered. A quest can be completed. A quest is usually not completed.

Kill All Rats is a quest in The Dungeon.

[Insert whatever code here gives the quest]

Now Kill All Rats is discovered.

[Insert whatever code here kills all rats]

Now Kill All Rats is completed.

Hope you get the idea without a complete code sample. What happens when you try to compile? Any errors? Does anything at all change?

I don’t know if a table would be faster for this or not. I’m basically just trying to avoid tables at all costs. Anything I can use a property or a truth state variable for, I’m gonna do it.

[Edit: Apparently spacing is hard.]

3

It took me a while to figure out how property defaults work, so I will share with you what I’ve learned. Your example can be simplified to the following, and I’ll explain why:

A quest is a kind of thing. A quest can be discovered. A quest can be completed.

When you declare a binary property, the first (and possibly only) value that you give is the “turned on” value. By default, binary properties are “turned off:”

a quest can be discovered [but by default it is not discovered, so you don't have to state that explicitly.]

Even if you give a name to the second, “turned off” value, that’s still true:

a quest can be discovered or undiscovered [the default is still "not discovered," but now that has a name: "undiscovered."]

But beware! As soon as you add a third possible value, the property stops being binary, and the default values are flipped. Instead of the last value being the default, now the first one is the default! For example:

A quest can be discovered, completed, or undiscovered. [the default for THIS is "discovered!"]

In practice, this is usually what you want. You can think of a binary property as something you “turn on” when the time comes, so it starts out in a nondescript “turned off” state. But an enumerated property is something that counts up from zero, so it’s natural for it to start out at zero. The following ordering would make more sense, wouldn’t it?

A quest can be undiscovered, discovered, or completed.
4

You’re absolutely right. But since in all of the “beginner” examples I’ve ever seen, this value is specified as false, I always include it. Much the same as boolean values (exactly the same thing, which I’m sure is what you meant) also appear to be false if not specified true.

I think I would disagree with your appraisal of desired behavior on the third property, however. What if I want “A stone is heavy, square and igneous” but later in the game I want “A stone is light, round and sedimentary”? Maybe it’s just my understanding of the mechanics.

As you’re correct in the case of the former, however, I’ll assume you to be correct in the latter.

5

It sounds like you’re talking about three independent properties. I was talking about having three or more possible values for the same property. Perhaps it was confusing because in the original example, “discovered” and “completed” were independent values. You could do it that way, but would you ever want to have a quest that was completed but not discovered? My example uses a single property that has mutually exclusive values, so a quest can never be undiscovered (or discovered) if it is completed.

When you declare a property with three or more values, it becomes a kind of value rather than a Boolean:

A sound is a kind of thing. A sound can be silent, barely audible, clear, loud, or deafening.

Internally, Inform represents these as numbers. Silent would evaluate to 0, barely audible to 1, all the way to 4 for deafening.

6

Why yes! It worked! I now have a quest list! I was even able to create a new action that would say [list of discovered quests]. Giving each quest a printed name also allows me to elaborate on what the player needs to do to complete the quest when checking the list. Thank you. :smiley: