9.4. Money

| Chapter 9: Props: Food, Clothing, Money, Toys, Books, Electronics |

| 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

253
| Example Frozen Assets A treatment of money which keeps track of how much the player has on him, and a BUY command which lets him go shopping. |
WI

272
| Example Introduction to Juggling Assortment of equipment defined with price and description, in a table. |
WI

254
| Example Money for Nothing An OFFER price FOR command, allowing the player to bargain with a flexible seller. |
WI

251
| Example Nickel and Dimed A more intricate system of money, this time keeping track of the individual denominations of coins and bills, specifying what gets spent at each transaction, and calculating appropriate change. |
WI

258
| Example Fabrication A system of assembling clothing from a pattern and materials; both the pattern and the different fabrics have associated prices. |
WI

252
| Example Widget Enterprises Allowing the player to set a price for a widget on sale, then determining the resulting sales based on consumer demand, and the resulting profit and loss. |
WI

> Suppose the player is responsible for pricing at Widget Enterprises. Widget production entails a certain fixed cost as well as a cost per unit; and somewhere out in the world there are a number of customers interested in purchasing widgets, but the player starts without knowing what this distribution looks like. We can express the profits as an equation: the total made by selling widgets, minus the cost thereof. The Table of Customers holds the data about customer preferences, and whenever the player selects a widget price, we consult it to determine how many customers in total would be willing to buy at that price. "Widget Enterprises" Widget Stand is a room. A monetary value is a kind of value. $1.99 specifies a monetary value with parts dollars and cents. Equation - Profit Equation P = nV - (F + nC) where P is a monetary value, F is the fixed cost, C is the unit cost, V is a monetary value, and n is a number. The fixed cost is a monetary value that varies. The fixed cost is $5.00. The unit cost is a monetary value that varies. The unit cost is $10.66. Table of Customers
> base | maximum value
> 2 | $26.00
> 5 | $20.00
> 8 | $15.00
> 2 | $13.50
> 1 | $9.00
To decide what number is the units sold at (V - a monetary value): let total units be 0; repeat through the Table of Customers: if V is less than the maximum value entry: increase total units by the base entry; decide on total units. Understand "set price to [monetary value]" as setting price to. Setting price to is an action applying to one monetary value. Carry out setting price to: let V be the monetary value understood; let n be the units sold at the monetary value understood; let P be given by the Profit Equation; say "You set the price of your widgets to [V], resulting in sales of [n] unit[s] and "; if P is less than $0.00: let L be $0.00 - P; say "a loss of [L]."; otherwise if P is $0.00: say "break even."; otherwise: say "a profit of [P].". Test me with "set price to $0.00 / set price to $100.00 / set price to $15.00 / set price to $8.00 / set price to $25.00 / set price to $14.99". As written this will be a rather dull guessing game for the player; more interesting would be to enhance it into a fuller economic simulator with more control over fixed costs and customer price points.

Previous | Contents | Next