By haggling, probably unsuccessfully.

In the real world, I can walk into a grocery store (supermarket or locally owned) that sells eggs in cartons of a dozen, pick up a carton for $1.50, calculate that that works out to 12.5¢ per egg, and try to buy 2 eggs at checkout for 25¢, but the clerk will refuse to sell me those 2 eggs because the store does not offer the purchase of individual eggs. If I want those 2 eggs, I can buy a carton of a dozen for full price. This is because a carton of only 10 eggs is essentially unsalable for the grocery store.

In the game, the shopkeeper has prepared a lot (pouch, case, or whatever) of 20 sling bullets for 4cp total. (We know the bullets are sold as a lot because if they were intended to be sold individually they'd be priced at 5 bullets for 1cp, not 4 times as many for 4 times as much.) You may be able to calculate that the price per bullet is 0.2cp, but that doesn't mean the shopkeeper is willing to sell a partial lot. The shopkeeper has the right to offer whole lots of 20 bullets, take it or leave it, but selling fewer bullets than a full lot probably requires the shopkeeper to count them out, which is a waste of time they could be using to serve other customers who know how to follow commerce norms and buy what's actually on offer.

Even haggling is unlikely to be successful. Suppose you offered 1cp just to buy 1 bullet. Even though that's 5 times the shopkeeper's unit price, the shopkeeper would still likely decline because the remaining 19 bullets don't constitute a full lot. The next customer will likely be uninterested in purchasing that partial lot without haggling of their own unless the shopkeeper refills the lot or discounts it, which again makes the prospect barely worth the shopkeeper's time and effort.

So, let the player haggle if they want to, but the shopkeeper should behave like a real person, which probably means refusing to sell a single unit of a supply that's not being offered in single units. If you think the player can successfully haggle an agreeable total with the shopkeeper, it certainly shouldn't involve the invention of a new currency or the cutting of coins (fragments of a coin are collectively worth less than an intact coin's face value in most realistic economies), but the terms that the player and shopkeeper find agreeable depends entirely on the player's argument and shopkeeper's demeanor.

In ancient or medieval times, coins were sometimes cut in pieces to deal with this kind of problem. So if you do want to make this possible, simply have the shopkeeper chop up the coin. Of course, this only goes to a point. I would assume a quarter is the furthest I would take this. Which in your example would up the price a little - 5 quarters for 5 bullets - which isn't unrealistic at all, bulk prices are common.

In addition, this gives you the option of filling the PCs pockets with bits and pieces of coins. Perhaps they will tire of the book keeping at some point and just agree to be a bit more hand-wavy from now on ;)

An example of the practice - a half-siliqua

Lets look at a real world example. To do that, lets replace "Sling bullet" with "piece of paper" and "cp" with "cent". Pricing is the same, so 5 pieces of paper is one cent.

Now, imagine going to this store and buying one piece of paper. Are they going to let you pay .2 cents? Of course not! Instead, they'll probably do one of the following:

• Charge you one cent (since anything less is impossible)




• Make you buy 5 pieces of paper (since that's the standard price for one cent)




• Just give it to you for free (since .2 cents is negligible)

There's really no difference of options in your world, and based on the circumstances and character of the merchant, all of these seem like viable options. As a DM, you'd have to choose at your discretion which choice your merchant makes.

However, from a database perspective, you can still enter the cost of each sling bullet at .2, and when calculating the price for N of any object, simply give ceiling(N * price). That at least gives you a fair asking price which should scale with the real value of the items (and maybe nice merchants will round down while stingy ones round up).

Imagine you are on a farmers market in real life. You go to a vegetable stand and say to the shopkeeper:

"I would like to buy one pea, please"

"You mean one pound of peas?"

"No, one single pea"

What would the shopkeeper do? Weight a single pea, realize it's not even a single cent and consider how to handle the situation? There are other customers waiting in line behind you. They don't have time for caring about such a ridiculous problem. So how would they deal with such a situation?

A friendly shopkeeper would tell you that you can just take that single pea for free. It's such a small value they won't even notice that it's missing. A less friendly shopkeeper would tell you to stop wasting their time with such ridiculous nonsense and tell you to get lost. A pragmatic shopkeeper would tell you that you need to buy at least 50g of peas because that's the minimum their scale will measure properly.

That's likely how a shopkeeper in your campaign world would react, too.

• Tell the player they can have that one sling bullet as a free sample, but the shopkeep will want money if they buy more later


• Tell them they need to buy them in packs of 20.

If you have a player who is that penurious with his character's money, you might offer him six bullets for a copper -- don't forget to remind him that's more than 15% off!

For your DB app, you should put actual prices in the table because otherwise you have to write all kinds of handling code for items with quantities (what if a player wants to buy 24?).

If you want to represent the books perfectly, you add another column listing the amounts that are given in the books. So bullets are purchased in batches of 20. But you keep the information intact and can work with it.

You can also drop this information and simply implement a rounding rule, so players can purchase any quantity they want, but they only pay full coins (or you can add the quarter-coins idea above).

When you subdivide standard lots, the price goes up

Take my local pizzeria. Like many pizzerias in the US, their pricing is structured around you buying two pizzas. So

• Two large pizzas are $22


• One large pizza is 18


• One slice (1/8 of a large) is 3.50

Per-slice prices are 3.50, 2.25 or 1.37... Depending on volume.

Consider soft drinks, assuming 16 22 32 and 44 ounce sizes. The local movie theater prices them 4.50 4.75 5.00 5.25. The convenience store prices 1.19 1.29 1.39 1.49. It's not proportional, not nearly, because the store lease is the same either way, as is the clerk's time.

So you are incorrect to subdivide prices for sling bullets. 4cp for 20 mathematically means 1cp per 5, but that certainly won't correspond to retail. More likely:

• 20 for 4cp


• 4 for 2cp


• 1 for 1cp

Needless to say, this puts the kibosh on the parsimonious fellow aiming to buy his bullets one at a time. Now, thriftiness kicks in, and he can plainly see the value is in buying by the 20.

The exchange of a similar valued good

Many peasants may readily trade supplies that are too cheap to be concerned with their gold value. Instead, they may simply trade similar cheap items or menial jobs, so long as it doesn't seem outrageous.

Perhaps the merchant needs a bundle of sticks, for building a fire; or a collection of flower petals for their medicine.

If you're already headed in the direction maybe they'll ask you to send a message since it's not out of your way in exchange.

Minimum purchase

Require they spend at least 1cp and offer some other cheap item in addition to the bullet. If there is nothing suitable, get them to buy something more expensive and offer to throw the bullet in for free.

Let's be real

What are these bullets made of? If they are anything more valuable than stone (e.g. lead) then they will have more intrinsic value than the copper itself. Tell them to use the copper piece as a bullet.

For purposes of the application, I agree with listing with the assumed quantity in the book. And a "per each" value, as well - at least for informational purposes.

For play purposes, use varied coin from "other realms" along with cutting coins. The RoleMaster system uses Tin pieces and Bronze pieces below Copper pieces (1cp = 10tp = 100bp)*. But you could give change in a variety of small coins, perhaps by weight and composition.

This can allow you to provide clues/hooks to adventures. (Suspicious merchant: "Where did you get this coin?") It can also allow you to burden a "particularly difficult player" with a bunch of coinage that people are willing to give him in change but none will accept (except maybe the banker who will assess it all) for payment.**

(* The cost of items differs in that system, as well, such that you actually use the Tin and Bronze pieces. IIRC, 1cp is one day's wages for a day laborer there, in a medieval setting.)

(** This is based in RL. I've worked in places where we would regularly get foreign coins in the snack bar and such. Sometimes it would be because it looked or felt enough like a US quarter or nickel or dime that it got dropped in the kitty as one by mistake. Retailers put up with it, too, and some would actually put out a box of foreign coinage and you could exchange a handful for US money.)

Expanding on Lord Farquaad's comment,
this is the solution I used for the database of creature stats, in particular, carrying capacities. Very small creatures have maximum loads that are not an integer number of pounds, so they are recorded in ounces. Every load is an integer number of ounces.

I agree with you that it's nice to avoid floating-point numbers if possible. For example, suppose that you can buy 20 of an item for 3gp. Then one is worth 20/3 gp, or about 6.66666667gp...but rendered in binary, it's 110.1010101010101010101010...

It's annoying to deal with. Unfortunately, I don't think having a separate integer for a decimal part will make it any less annoying to deal with.

The solution I used was, obviously, to record the number in a different, smaller unit --- ounces instead of pounds. That's literally what I called the field in the database, max_load_ounces.
You constantly have to be converting between units anyway, especially if we're talking about coins.

Unfortunately, in the case of copper pieces rather than pounds, there isn't a natural smaller unit that conveniently turns everything into integers. (Well, the Dark Sun setting has "bits" like the farthings/fourthings KorvinStarmast mentioned, but that would probably just get more confusing and annoying to deal with, since Dark Sun has ceramic pieces in place of copper pieces, in the sense that a tenth of a silver pieces is a ceramic piece, except it sort of has ceramic pieces in place of gold pieces, it's complicated.)

Since there isn't a convenient smaller unit, I think you're fully justified in just making up one for your own convenience. If you know in advance every single one of the objects you're going to include in the database, then all you have to do is take the common denominator of all the fractions --- the least common multiple of all the denominators.
But if (as I assume) you don't know everything in advance and you want a unit that will be pretty safe, you probably want one-sixtieth. Why one-sixtieth? For the same reason the ancient Mesopotamians used it. Because 60 = 2*2*3*5. 1/4 becomes 15/60. 1/3 becomes 20/60. 1/5 becomes 12/60. Sixtieths give you pretty broad coverage for the most common fractions. Sixtieths will probably work for everything you'll run into.

I was about to say you could just call the field market_price_60th_copper_pieces, but looking at your repo, you decided to get fancy and make "gp" a proper type with its own internal translation.
https://github.com/ocket8888/dndDB/blob/master/gp.c already does automatic division every time a value is output --- you internally store the value in copper pieces, and translate to gold pieces on-the-fly by dividing by 100. You could just as easily store the value internally as sixtieths of copper pieces. (Or, if https://github.com/ocket8888/dndDB/blob/master/items.sql already has all the items you want and you know you won't run into any more unexpected fractions, you can take the actual common denominator instead of hedging and making the common denominator 60 to be safe.)

In any case, the good news is that if you do later run into an unplanned-for fraction --- like if for some bizarre reason the market price of something is 1/7 --- it's not too hard to translate the existing database to use a smaller unit: just multiply every price by a new prime number (in this case 7). If you have hardcoded INSERT commands as in https://github.com/ocket8888/dndDB/blob/master/items.sql , just run a SELECT for the multiples and use the output mode that spits out INSERT commands --- in SQLite this is .mode insert, I don't know how to do it in Postgres but I assume Postgres must have something analogous.

For the sake of completeness, it's worth noting that the worth of D&D coins have no seigniorage --- a gold coin is a fiftieth of a pound, and a pound of gold is worth 50gp. The point of minting is purely to guarantee the purity of the metal (and its standard weight) with the reputation of the minting kingdom. The fancy design is a nice bonus that makes it nigh-impossible to shave off little bits of gold from the coin without people noticing. But at the end of the day the value of a coin is its weight of precious metal, so you could use any unit of weight as a unit of value. I don't recommend that, because units of weight are bedlam. We'd have to start talking about Troy pounds of gold versus avoirdupois pounds of gold, and you probably don't want to go down that rabbit hole.