Mike,
Yes, the line is there but I was too agressive when cutting text from the source.
An adventurer is a kind of person.appears just above the line The player has some text called advname.
As for the printing rule,
when I examine an adventurer. I want that person’s name, gender, dex, and class to show up on a single line (in addition to a description the user will given him/her.)
OK, for all those who have demonstrated extreme patience with my stupidity and awful code, I think I got it (almost) right.
An adventurer is a kind of person. [Is this really needed since attributes are added directly to the player?]
Yourself is an adventurer. [This links the player to the adventurer kind.]
Understand the advName property as describing Yourself. [This links the advName to the player for EXAMINING or SHOWME commands.]
The player has some text called advName.
The player has some text called advGender. [Supercedes default gender.]
The player has some text called class. The class of player is "Fighter". [The player's class is "Fighter" does not compile. Why not? I would think they are equivalent.]
The player has a number called dex. The dex of player is 18. [The player's dex is 18" or "the player has a dex of 18" does not compile. Why not? I would think they are equivalent.]
MAXTRAIT is always 18.
MINPRIMTRAIT is always 12.
MINSECTRAIT is always 8.
Data is a kind of value. The data are stName, stSex, stClass, complete, and paused.
Stage is data that varies. Stage is stName.
[Displaying the adventurer's attributes.]
Instead of examining the player:
say "[advName of player], [advGender of player] [class of player] (DEX=[dex of player])".I put comments into the code to show where I was confused.
I also replaced the printing rule with an examine rule for adventurers.
This is close, a couple things that might tighten this up further:
You do say the player is an adventurer – that’s what “Yourself is an adventurer” is saying – and since as I understand it you want to allow the player to create multiple characters, you probably want to make this more general by making all the “the player has some [property]” lines to be “an adventurer has some [property]”, while likewise changing the understand line back to “describing an adventurer” rather than “yourself.”
This does work, but in general you’re likely better off just changing the description – preempting actions using instead rules can very easily get you into a lot of trouble later in. So you can just do this:
The description of an adventurer is usually “[advName] ([dex], [advGender])”.
(Note that if you keep using the default player object/Yourself, you’ll also want an additional line saying "the description of yourself is “[advName] ([dex], [advGender])”. This is because the standard rules set the description of the player to “As good looking as ever.” by default, so you need to specifically overrule it).
Yes, thank you. I understood all that you said. Also, it opens the door to the multiple characters that may occur.
I also understand that the location description never “sees” the player, as in “You see Barak here” if Barak if the advName of the player. If I create Barak and another adventurer, say Alice, then I expect to see Alice but not Barak in the look description.
1 Like
Yup, exactly – the player is the one doing the seeing, so ordinarily it’d be odd to say “you see yourself here.” But if there’s a circumstance where that would make sense for your game, you can just manually add it to the location’s description, or tweak the relevant part of the standard rules as needed.
It means you can have other adventurers besides the player. If the player is the only adventurer, then yeah, it’s not needed; but if there will be other adventurers, you should keep that line and amend the following lines like this:
Yourself is an adventurer.
Understand the advName property as describing an adventurer.
An adventurer has some text called advName.
An adventurer has some text called advGender.
An adventurer has some text called class.
An adventurer has a number called dex.
[And also define the class and dex of the player, of course.]
(I’d also suggest expanding the abbreviation to “dexterity”, though that’s just a personal opinion so you can do whatever you want really.)
Simply put, Inform does not understand possessives. Either of the following forms work:
The player has class "Fighter".
The player has dex 18.
or
The class of the player is "Fighter".
The dex of the player is 18.
As does the following form that sets properties in the same sentence as the definition (but this won’t work for the player specifically, I think):
Fred is an adventurer with class "Wizard" and dex 12.
And if you don’t like that you can always make up a new way to define it:
The verb to play as means the class property.
The verb to dodge means the dex property.
The player plays as "Fighter" and dodges 18.
(I’m not sure if that works with the player, it might have to be yourself instead for that one. Also, I realize that dodges 18 sounds weird; I’m not specifically recommending you do this, only noting that it’s available.)
As a side note, if you know ahead of time that there are a fixed number of classes, it might make sense for the class to be a kind of value:
A class is a kind of value.
[You can define all the classes in one line:]
The classes are Fighter, Wizard, and Cleric.
[Or you can define them individually like below:]
Fighter is a class. Wizard is a class. Cleric is a class.
The player [or an adventurer] has a class.
The class of the player is Fighter.
I believe that also gives you the bonus that you can write things like this, if you want to:
Instead of examining a fighter adventurer:
Or in other words, Inform treats the class names as adjectives that can be applied to an adventurer. (If you don’t want, that, just change the name of the kind to eg className and write has a className called class.)
1 Like
Thanks much. I feel like have emerged from a great fog. Regarding classes as values, I want them to be kinds because I want to treat them as a group.