So now that I’ve reviewed some of the details about objects in Inform 7, it’s time for a little practical experience with them. We’ll make something like a pen-and-paper RPG, so we’ll want to define the player and a monster to fight and such.
A person called Thorn is in dungeon entrance. The player is Thorn. Thorn carries an old iron sword.
An old iron sword is a thing. The description of the old iron sword is “This sword is well-worn and in serious need of attention from a skilled blacksmith. Still, it’s at least good for another fight or two.”.
A goblin is in dungeon entry. Dungeon entry is down from dungeon entrance. A goblin carries an old iron sword.
This code looks good, but it will throw up an error when Go! is hit and Inform 7 attempts to compile it. This is because three different statements conflict about the old iron sword and it is a unique item. This first ‘carried’ statement attempt to create it, and the second line explicitly tries to create the sword, and the goblin carry conflicts with the carry by Thorn. This however would work.
A person called Thorn is in dungeon entrance. The player is Thorn.
An old iron sword is a thing. The description of the old iron sword is “This sword is well-worn and in serious need of attention from a skilled blacksmith. Still, it’s at least good for another fight or two.”.
A goblin is in dungeon entry. Dungeon entry is down from dungeon entrance. A goblin carries an old iron sword.
(code for goblin defeat event)
Now the old iron sword is carried by the player;
say “You pry the old sword from the goblin’s not-quite cold dead hands. At least now you’re armed.”.
This code is fine, the sword is created with detail, it is then carried by the goblin(since this comes afterwards, it doesn’t try to create the sword, just set it as carried by the goblin). Then sometime during play the sword is transferred to the player.
We could also do this.
OldSword1 is carried by the player. The printed name of OldSword1 is “old iron sword”.
OldSword2 is carried by the goblin. The printed name of OldSword2 is “old iron sword”.
This creates two swords that sound similar, indeed if both are on the floor of the room, the player will see this: “You can see an old iron sword and an old iron sword here.” That is unpleasant, plus the player can’t type ‘take old iron sword’ and get either sword without a Understand “old/iron/sword” as the oldsword1. Even if both were ‘understood however, then the player can’t pick between them.
To make many unique weapons, it’s better to actually make them unique. Have the player carry the old iron sword and the goblin carry the rusty chopping blade. We could also do something special with such swords.
Sword1 is carried by the player. Sword1 can be reforged. The printed named of Sword1 is “[if sword1 is reforged]gleaming steel sword[otherwise]old iron sword[end if]” (plus matching conditional understand and description)
This gives us a system where the player can gather old used blades from adventures, take them back to town and have a pro reforge them. A can be enchanted property could raise the possibilities further with a mage enchanting swords that have been reforged.
A better thing to do is define kinds.
A weapon is a kind of thing. A sword is a kind of weapon.
The old sword is a sword. It is carried by the player. The goblin carries one sword. There are two swords in dungeon entrance.
This allows us to have multiple swords(which could have stats) along with the option to make unique named swords. Named swords inherit the stats of the sword kind unless they’re changed. For instance if swords usually have damage of 8, the old sword could have damage of 5 (which can be changed when reforged to a higher number).
This also handles multiples more easily, if the player types ‘take sword’ in the room with two swords, the game will just pick one since it understands they’re identical.
The general limit with copies of a kind is Inform limits it to 100 copies in one location. This can be raised to 200 easily, but there are places where an economy of items will help.
Here is a more advanced weapon model.
A weapon is a kind of thing. A weapon can be dagger, sword, mace, axe, spear or bow (this is the weapon-type property). Understand the weapon-type property as describing the weapon. The printed name of a weapon is usually "[weapon-condition][weapon-type]". The printed plural name of a weapon is usually "[weapon-condition][weapon-type]s". A weapon has a number called w-condition. The w-condition of a weapon is usually 50.
Definition: A weapon is worn if its w-condition is 20 or less.
Definition: A weapon is pristine if its w-condition is 80 or more.
To say weapon-condition:
if w-condition of item described < 20:
say "corroded ";
if w-condition of item described < 40:
say "worn ";
if w-condition of item described > 60:
say "fine ";
if w-condition of item described > 80:
say "pristine ";
8 weapons are in old town. 5 worn spear weapons are in old town. 3 bow weapons are in old town. [If a kind-copy is not uniquely named, the number of copies must be specified.]
Old Town
You can see eight daggers, five worn spears and three bows here.
This is a bit advanced, so I’ll explain what’s happening from the beginning. All weapons in this code are made from a ‘blank’ weapon kind. Their printed singular and plural names depend on the weapon-type property. They also have a stat for weapon condition. There is a ‘To say’ statement to apply a name, and a condition between 40-60 is no ‘say’, which is why it shows up as ‘eight daggers’. Finally the weapon-type describes the weapon, allowing the player to grab a sword by typing ‘take sword’ or ‘take weapon’. Since dagger is the first weapon-type, it is the default, hence eight weapons = eight daggers.
-
The 'item described' is a variable Inform uses, it's basically whatever object Inform is currently dealing with. If Inform is printing the name of Weapon-37, then the item described is currently that weapon. This is handy to know in this instance because here we can't refer to it as 'the noun' or 'the second noun' or a temporary value like 'chosen-weapon', mkaing it handy for descriptions and printed names.
-
The definitions are the most fun. They make Inform understand ‘five worn spear weapons’ as ‘five weapons with spear weapon-type and w-condition 20’. Inform will also understand ‘Let chosen-weapon be the most pristine weapon in location;’ which has inform select the weapon with the greatest w-condition because the definition says ‘or more’.
There are more advanced things that can be done with this implementation as well.
Shall we have a weapon shop? Well all objects must be created at the beginning of the game, so with the previous example, the author would have to define how many swords are in game, how many axes, etc. In this model, it’s just weapons and as the author we can turn a bow into an axe by saying, “Now the weapon-type of chosen-weapon is axe;”.
So what’s the best way to do a weapon shop without creating an excess of weapons?
If there are no off-stage weapons:
say “The weapon smith is currently out of stock.”;
otherwise if there are less than 10 off-stage weapons:
say “The weapon smith has a few weapons in stock.”;
[weapon buying code for when there are off-stage weapons, player chooses to buy a pristine(85) sword.]
Let chosen-weapon be a random off-stage weapon;
Now the weapon-type of chosen-weapon is sword;
Now the w-condition of chosen-weapon is 85;
Now chosen-weapon is on the shop counter; [if the player has a carrying capacity, placing it on the counter for pick-up is safer.]
In this way, the weapon-smith serves as a way to ‘recycle’ weapons, which are moved off-stage after being broken in combat, broken down for parts, etc. If we want the shop-keep to have an initial stock, we just declare some weapons exist and they’ll be created out of play. “There are 20 weapons.”
In this method, the game just needs a total pool of weapons and the properties of the weapon can be changed to fit when code places one in a treasure chest, in the hands of an enemy or the player buys one. It also allows code for ‘destroying/losing’ weapons by putting them out of play and thus where the recycling code can find them and use them again.
The exception for recycling is that unique named weapons shouldn’t be recycled the same way, otherwise if Excalibur gets broken and the player recovers it, it might have been in the hands of a respawned goblin as a worn dagger.
A person called Thorn is in dungeon entrance. The player is Thorn. Thorn carries an old iron sword.
An old iron sword is a thing. The description of the old iron sword is “This sword is well-worn and in serious need of attention from a skilled blacksmith. Still, it’s at least good for another fight or two.”.
A goblin is in dungeon entry. Dungeon entry is down from dungeon entrance. A goblin carries an old iron sword.
This code looks good, but it will throw up an error when Go! is hit and Inform 7 attempts to compile it. This is because three different statements conflict about the old iron sword and it is a unique item. This first ‘carried’ statement attempt to create it, and the second line explicitly tries to create the sword, and the goblin carry conflicts with the carry by Thorn. This however would work.
A person called Thorn is in dungeon entrance. The player is Thorn.
An old iron sword is a thing. The description of the old iron sword is “This sword is well-worn and in serious need of attention from a skilled blacksmith. Still, it’s at least good for another fight or two.”.
A goblin is in dungeon entry. Dungeon entry is down from dungeon entrance. A goblin carries an old iron sword.
(code for goblin defeat event)
Now the old iron sword is carried by the player;
say “You pry the old sword from the goblin’s not-quite cold dead hands. At least now you’re armed.”.
This code is fine, the sword is created with detail, it is then carried by the goblin(since this comes afterwards, it doesn’t try to create the sword, just set it as carried by the goblin). Then sometime during play the sword is transferred to the player.
We could also do this.
OldSword1 is carried by the player. The printed name of OldSword1 is “old iron sword”.
OldSword2 is carried by the goblin. The printed name of OldSword2 is “old iron sword”.
This creates two swords that sound similar, indeed if both are on the floor of the room, the player will see this: “You can see an old iron sword and an old iron sword here.” That is unpleasant, plus the player can’t type ‘take old iron sword’ and get either sword without a Understand “old/iron/sword” as the oldsword1. Even if both were ‘understood however, then the player can’t pick between them.
To make many unique weapons, it’s better to actually make them unique. Have the player carry the old iron sword and the goblin carry the rusty chopping blade. We could also do something special with such swords.
Sword1 is carried by the player. Sword1 can be reforged. The printed named of Sword1 is “[if sword1 is reforged]gleaming steel sword[otherwise]old iron sword[end if]” (plus matching conditional understand and description)
This gives us a system where the player can gather old used blades from adventures, take them back to town and have a pro reforge them. A can be enchanted property could raise the possibilities further with a mage enchanting swords that have been reforged.
A better thing to do is define kinds.
A weapon is a kind of thing. A sword is a kind of weapon.
The old sword is a sword. It is carried by the player. The goblin carries one sword. There are two swords in dungeon entrance.
This allows us to have multiple swords(which could have stats) along with the option to make unique named swords. Named swords inherit the stats of the sword kind unless they’re changed. For instance if swords usually have damage of 8, the old sword could have damage of 5 (which can be changed when reforged to a higher number).
This also handles multiples more easily, if the player types ‘take sword’ in the room with two swords, the game will just pick one since it understands they’re identical.
The general limit with copies of a kind is Inform limits it to 100 copies in one location. This can be raised to 200 easily, but there are places where an economy of items will help.
Here is a more advanced weapon model.
A weapon is a kind of thing. A weapon can be dagger, sword, mace, axe, spear or bow (this is the weapon-type property). Understand the weapon-type property as describing the weapon. The printed name of a weapon is usually "[weapon-condition][weapon-type]". The printed plural name of a weapon is usually "[weapon-condition][weapon-type]s". A weapon has a number called w-condition. The w-condition of a weapon is usually 50.
Definition: A weapon is worn if its w-condition is 20 or less.
Definition: A weapon is pristine if its w-condition is 80 or more.
To say weapon-condition:
if w-condition of item described < 20:
say "corroded ";
if w-condition of item described < 40:
say "worn ";
if w-condition of item described > 60:
say "fine ";
if w-condition of item described > 80:
say "pristine ";
8 weapons are in old town. 5 worn spear weapons are in old town. 3 bow weapons are in old town. [If a kind-copy is not uniquely named, the number of copies must be specified.]
Old Town
You can see eight daggers, five worn spears and three bows here.
This is a bit advanced, so I’ll explain what’s happening from the beginning. All weapons in this code are made from a ‘blank’ weapon kind. Their printed singular and plural names depend on the weapon-type property. They also have a stat for weapon condition. There is a ‘To say’ statement to apply a name, and a condition between 40-60 is no ‘say’, which is why it shows up as ‘eight daggers’. Finally the weapon-type describes the weapon, allowing the player to grab a sword by typing ‘take sword’ or ‘take weapon’. Since dagger is the first weapon-type, it is the default, hence eight weapons = eight daggers.
-
The 'item described' is a variable Inform uses, it's basically whatever object Inform is currently dealing with. If Inform is printing the name of Weapon-37, then the item described is currently that weapon. This is handy to know in this instance because here we can't refer to it as 'the noun' or 'the second noun' or a temporary value like 'chosen-weapon', mkaing it handy for descriptions and printed names.
-
The definitions are the most fun. They make Inform understand ‘five worn spear weapons’ as ‘five weapons with spear weapon-type and w-condition 20’. Inform will also understand ‘Let chosen-weapon be the most pristine weapon in location;’ which has inform select the weapon with the greatest w-condition because the definition says ‘or more’.
There are more advanced things that can be done with this implementation as well.
Shall we have a weapon shop? Well all objects must be created at the beginning of the game, so with the previous example, the author would have to define how many swords are in game, how many axes, etc. In this model, it’s just weapons and as the author we can turn a bow into an axe by saying, “Now the weapon-type of chosen-weapon is axe;”.
So what’s the best way to do a weapon shop without creating an excess of weapons?
If there are no off-stage weapons:
say “The weapon smith is currently out of stock.”;
otherwise if there are less than 10 off-stage weapons:
say “The weapon smith has a few weapons in stock.”;
[weapon buying code for when there are off-stage weapons, player chooses to buy a pristine(85) sword.]
Let chosen-weapon be a random off-stage weapon;
Now the weapon-type of chosen-weapon is sword;
Now the w-condition of chosen-weapon is 85;
Now chosen-weapon is on the shop counter; [if the player has a carrying capacity, placing it on the counter for pick-up is safer.]
In this way, the weapon-smith serves as a way to ‘recycle’ weapons, which are moved off-stage after being broken in combat, broken down for parts, etc. If we want the shop-keep to have an initial stock, we just declare some weapons exist and they’ll be created out of play. “There are 20 weapons.”
In this method, the game just needs a total pool of weapons and the properties of the weapon can be changed to fit when code places one in a treasure chest, in the hands of an enemy or the player buys one. It also allows code for ‘destroying/losing’ weapons by putting them out of play and thus where the recycling code can find them and use them again.
The exception for recycling is that unique named weapons shouldn’t be recycled the same way, otherwise if Excalibur gets broken and the player recovers it, it might have been in the hands of a respawned goblin as a worn dagger.
Posts
0 comments:
Post a Comment