§9.4. Money
Money could be anything which the two people in a bargain both agree is valuable. Here, the player and an ogre agree on a copper coin as money:
The player carries a copper coin. The ogre carries a rock cake. The cake is edible.
Instead of giving the coin to the ogre:
now the ogre carries the coin;
now the player carries the cake;
say "The ogre grunts and hands you a rock cake."
Now Inform does provide an action, "buying", and a command for it, BUY, but they ordinarily respond simply "Nothing is on sale." This is no longer true, so we should make BUY CAKE work. The difficulty here is that a command like BUY CAKE does not specify what should be handed over in exchange. Here we just check that the player has the coin, but in principle we could check for any of a range of monetary tokens - coins, notes, cheque book, debit card, and so on.
Instead of buying the cake:
if the player has the coin, try giving the coin to the ogre;
otherwise say "You have no money."
In more advanced economies, where shopping replaces barter, the seller will stock a wide range of differently priced goods. For a tabulated catalogue of wares, see Introduction to Juggling: to allow the player to negotiate prices, see Money for Nothing. In both of those examples, the player's current financial worth is simulated only as a current total amount of money carried - say, $2.50. This is typical, because in most situations what matters is how much money is in the pocket, not how it is made up. Money behaves more like a liquid than a set of items: hence terms like "liquidity", "cash flow" or Frozen Assets - the name of the simplest example demonstrating this. If we really need a comprehensive simulation down to pieces of currency - where it makes a difference carrying four quarters rather than a dollar bill, because the quarters can be fed into a vending machine - see Nickel and Dimed.
Fabrication takes the problem in a different direction, making calculations about the cost of a new garment based on the price of the pattern, the quantity of fabric required, and the value of the fabric type chosen -- showing off what we can do with unit multiplication in Inform.
Widget Enterprises explores the challenge of pricing widgets for maximum profit, given certain necessary costs and customers with varying willingness to pay.
See Actions on Multiple Objects for an implementation of giving that allows the player to offer multiple objects at once, where their combined value determines whether they are accepted
![]() | Start of Chapter 9: Props: Food, Clothing, Money, Toys, Books, Electronics |
![]() | Back to §9.3. Clothing |
![]() | Onward to §9.5. Dice and Playing Cards |
|
|
|
|
|
Suppose we have a whole catalog-full of equipment that the player might want to purchase and use. We'll start by defining our purchasing rules: We allow things to have prices, and the player's price to indicate how much money the player has:
Because we're allowing the player to order things that he can't currently see, we need to borrow a special kind of grammar from the Understanding chapter. All our orderable items in this example are toys, so "any toy" means any object of the toy kind, whether or not it is in view at the moment:
We should also handle the situation where the player orders another of something he has already bought and which is right in front of him:
So much for the general rules for this scenario. Now we move on to particulars: the actual items the player is allowed to order. Each item will have a description, a price, and a difficulty representing how skilled the player must be in order to make use of that item. Since we are going to use price and difficulty in the table that defines our juggling equipment, we need to mention these kinds of value before the line that says how toys are defined.
Notice that we are allowed to define "description" and other already-known properties in the table as well.
And of course this will be no fun unless the player is allowed to use the equipment:
|
|
Suppose we have a whole catalog-full of equipment that the player might want to purchase and use. We'll start by defining our purchasing rules: We allow things to have prices, and the player's price to indicate how much money the player has:
Because we're allowing the player to order things that he can't currently see, we need to borrow a special kind of grammar from the Understanding chapter. All our orderable items in this example are toys, so "any toy" means any object of the toy kind, whether or not it is in view at the moment:
We should also handle the situation where the player orders another of something he has already bought and which is right in front of him:
So much for the general rules for this scenario. Now we move on to particulars: the actual items the player is allowed to order. Each item will have a description, a price, and a difficulty representing how skilled the player must be in order to make use of that item. Since we are going to use price and difficulty in the table that defines our juggling equipment, we need to mention these kinds of value before the line that says how toys are defined.
Notice that we are allowed to define "description" and other already-known properties in the table as well.
And of course this will be no fun unless the player is allowed to use the equipment:
|