Personally, I like to fiddle with coins n' stuff in RPG's. Otherwise, you can't give the players the feeling that they're adventuring to get the next meal on the table. Which is what they're doing, at least in the beginning of my campaigns.
Anyway, the problem is that it's pretty boring to do the math involved every single time you buy a pint of beer. So, inspired by Brian and in a moment of creativity, I've coded a little money-changer. So far it's capable of improving the value:pound-ratio of your purse (i.e. transforming silver into gold as far as possible etc.) and transforming your coins into light, imperial or heavy weight.
When ready, it should also be able to do the eventual changes needed when adding or subtracting money. Perhaps will it also be able to do a little percent math.
Now, is there anyone else how might be interested in a program like this?
If you want, I can send you some code or pseudo-code for the 1:12:20:4 (or, more properly, 1:12:240:960) conversions and calculations for Gold/Silver/Copper/Bits when adding or subtracting money. I had to do all that for the Character Generator for when you buy and sell stuff anyway.
(edit: I inspire you? Cool! :-))
Brian.
The pseudo-code would be great.
Here ya go. It's a bit messy, but you should be able to follow it easily enough.
Apologies to those who can't read Pseudocode or don't care to.
Function TakeMoney (receives string COST, returns boolean)
// This function deducts money from the characters total. The passed
// variable cost is assumed to be in the following format:
//
// Either a single value in brackets with g,s,c or b as the descriptor
// such as (3g) or (10s)
// Or two values, comma seperated such as (3g, 10s)
//
// Why in brackets? That's how it is the the book thus it gets passed
// that way.
//
// Gold, Silver, Copper, Bits are global variables which contain the
// current amount of money the character has. g,s,c,b are local
// variables which contain the amount of money to deduct. In the
// previous example, this would be g=3, s=10, c=0, b=0 for example.
Local Variables
g,s,c,b (integers)
cost2 (string)
begin
// divide up the COST string to remove the brackets. For a
// single value it ends up sans brqackets in cost (eg: 3g). For
// a double, the second element ends up in cost2. (eg: cost=3g
// and cost2=10s)
// Next, convert those to values so that the local variables
// end up with the right values in them. For example, g
// ends up with a value of 3 and the local variable s ends up
// with a value of 10. That's pretty easy. c and b should be
// assigned values of zero in that case of course.
call sortmoney // see function below, this smooths out the cash in
// case any strange values are in there (so 20 copper
// would be converted to 1 silver and 8 copper, for
// example.
Calculate the total amount to deduct in bits
Calculate the total amount of money possessed in bits
// the two above steps are just done by adding 960*g plus
// 48*s plus 4*c plus b
if money owned < money to deduct then
return false // not enough money, do nothing
else begin
// Bits component - basically it first checks if there is a cost
// in bits, if not it doesn't do anything. If there is, it checks
// if the character has enough bits to cover it. If the character
// does, it just subtracts b from Bits. If he doesn't, it calls the
// addbit function, which attempts to convert 1 copper into 4
// bits, if it can't, it simply just returns false and the purchase
// fails. Note that addbit can call addcopper if the character
// has no coppers but still has silvers to convert to coppers
// to then convert to bits, and so on.
//
// note - the ability to return false is just there for completeness
// there's no way it can because we already established that
// there was enough money to cover the entire cost
if b > 0 then
if b > Bits then
if not addbit then
return false
else
Bits := Bits - b
else Bits := Bits - b
end if
//now do the same with coppers
if c > 0 then
if c > Coppers then
if not addcopper then
return false
else
Coppers := Coppers - c
else Coppers := Coppers - c
// Ditto silver
if s > 0 then
if s > Silver then
if not addsilver then
return false
else
Silver := Silver - s
else Silver := Silver - s
// And gold
if g > 0 then
if g > Gold then
return false
else
Gold := Gold - g
else Gold := Gold - g
call sortmoney
return true // was able to deduct the money
end function // end of takemoney
Function Addbit (returns boolean)
// this function attempts to add 4 bits by subtracting 1 copper
// if there is no copper, add some from silver if possible
if Copper = 0 then
if not addcopper then
return false
// now subtract one from copper and add 4 to bits
Coppers := Coppers - 1;
Bits := Bits + 4;
return true
end function // end of addbits
Function Addcopper (returns boolean)
// this function attempts to add 12 copper by subtracting 1 silver
// if there is no silver, add some from gold if possible
if silver = 0 then
if not addsilver then
return false
// now subtract one from silver and add 12 to copper
Silver := Silver - 1;
Copper := Copper + 12;
return true
end function // end of addcopper
Function Addsilver (returns boolean)
// this function attempts to add 20 Silver by subtracting 1 Gold
if gold = 0 then
return false // no gold to convert
// subtract one from gold and add 20 to silver
Gold := Gold - 1;
Silver := Silver + 20;
return true
end function // end of addsilver
Procedure sortmoney
// Just shuffles money so that if there are more than 3 bits, it subtracts
// them in groups of 4 and adds 1 copper each time, and so on up the
// line
until Bits < 4 start loop
Bits := Bits - 4;
Copper := Copper + 1;
loop
until Copper < 12 start loop
Copper := Copper - 12;
Silver := Silver + 1;
loop
until Silver < 20 start loop
Silver := Silver - 20;
Gold := Gold + 1;
loop
end procedure // end procedure sortmoney
Procedure GiveMoney // add money to total
// this procedure doesn;t need to be pseudocoded. Just add whatever
// amount to each value, and then run sortmoney to balance it all out.
end proceudre // end of GiveMoney
I hope that's all readable.
Brian.
Hell yeah I'd be interested. Money changing is a bugger.
Besides, it's another toy on the toolbelt... And you can never have too many toys.
"Yup yup, time to get the old arms hacked off." ~Toymeister
Edit: Oh, yeah.. You may want to keep in mind that, once you go into play, you may not always manage to get the most efficient coins in your purse, and you may not even have all your money in the same national currency. If you can come up with a program which takes into account all of that, I will publicly canonize you right next to (well, maybe just under) Brian as a Saint of TRoS support toys. Ooh, and if it can keep track of multiple purses, that'd kick ace too. It's not likely that everyone's going to bring a laptop to the game, so if one person can use the program to track every player's cash, that'd rock out.
::wanders off chanting "Toystoystoystoys..." under his breath::
Yeah, sounds like an interesting project. Wish I had thought of it first :-)
Some other things you might want to put in there (to go along with Lance's list)
* A facility to change money from one currency to another, and have it work out all the details. This should include a variable "moneychangers charge", from 0% to 10% which will be deducted for each transaction.
* An ability to track which currencies are accepted in which other countries, that can be constantly updated as the campaign progresses. This should also have a facility to have alterable individual exchange rates for the situation (for example) where Gelure coins are accepted but only with a 2% surcharge or any Tegaarn coins are accepted but the rate of exchange for Tengokun coins is slightly higher this year because of rumors of coin shaving in that country. Etc.
Brian.
Umm, in my book the ratios are 1:20:240:960, not 1:12:240:960... (Table 7.1 pg 201 DFW1001). But I see you have it correct in the Pseudo Code.
Lance
Well, I'll probably be able to get most of that stuff to work.
Multiple purses are already in there, as is the "infrastructure" for different currencies.
And I'll be dissapointed if I can't make it ignore gold coins when changing, for example.
Other things you'll probably be able to do is to transfer money between different player's purses.
Brian
I had already planned for it to be able to handle percents, so I'll be dissapointed with myself if the currency-changer doesn't make it.
What you suggested about which currencies are accepted in which countries seems to be a lot of (monotonous) work... But hell, if you can code for every damn wound in the appendix, then I should be able to do this.
Whew! Seems like a lot of work. But this is fun, and I like the challenge.
Quote from: MokkurkalfeBut hell, if you can code for every damn wound in the appendix, then I should be able to do this.
Heh... you should see the code block that handles the wounds in the Combat Sim. It's several thousand lines of code... :-)
Brian.
it'd be nice if you guys were able to release all of this in a massive generator... something similiar to how the AD&D core rules cd was laid out... where you opened it up, and had all your options laid out before you...
combat sim, character gen, money changing.... add a map tool and it'd rock
I agree, prophet. Eventually we'd like to put it on disk with a nice autorun menu and everything.
Jake
that would be spiff... course since i know nothing about coding (im a grphics guy)... i dont know all the code side logistics. ya know, making sure every little program could work with the other...
i think it would be great though, course for us visual people, a great GUI would be nice... i like visually pleasing things... course, i honestly can say that i hope the celtic patterns would be involved (the various designes in the book and on the wesite.. i really like those
Quote from: Jake NorwoodEventually we'd like to put it on disk with a nice autorun menu and everything
Hell, that stuff's easy. I can handle that.
I might need some help with the graphic design though. As you've all likely noticed, I can do the functional stuff but I'm not so hot at making it pretty.
Brian.
Quote from: Jake NorwoodI agree, prophet. Eventually we'd like to put it on disk with a nice autorun menu and everything.
Jake
"and they rejoiced" (a-one, a-two...) "Yay"....
=D
You know I have to add that you guys are putting some excellent work out there in support of TRoS. I for one really appreciate it!
Some questions.
What do the countries call their copper bits. Do they just call them bits?
And should Odeon Teeth be included? If so, are they Light, Imperial or Heavy wheight (whale teeth?).
And do you say one Marluki Dollmar or one Otarmarluki Dollmar or one Marluk Dollmar or what?
The last question might also become another problem with other countries as well...
Edit: Oh, and what's the plural of all these coins n' currencies?
Edit again: Oh, damnit. I'm more or less gonna need to know how to write all the countries' currencies in plural, as in "42 Cyrinthmeiran pennies". Anyone who could help here?
Youknow, as a linguistic expiriment, that actually intrigues me. I might actually put somehting like that together this week...
Jake
Wouldn't it be more straight forward to handle all the money as bits, and then just convert it when you display it? Then you'd only have to munge with gold, silver, etc when you actually show the money, the behind the scenes stuff would be simple arithmetic. In a bad form of psuedocode, it would be like this.
Function Convert to bits
takes gold,silver, pennies, bits
returns bits
return gold*960 + silver*48 + pennies*4 + bits
end function
function bits to others
takes bits
returns gold,silver,pennies,bits
load bits to temp value
gold=bits div 960 (div is integer answer only)
tempbits=tempbits-(gold*960) //removes part that was turned to gold
silver=tempbits div 48
tempbits=tempbits-(silver*48) //removes silver
pennies=tempbits div 4
bits=tempbits-(pennies*4)
end function
This might be a simpler way to do it, and it would make the different coins types easier to implement. Just store the bits as halfweight coin and you wouldn't lose any data converting up.
Jason
Quote from: JasonWouldn't it be more straight forward to handle all the money as bits, and then just convert it when you display it?
Yes, that would, except that when you're talking multiple different currencies and different coin weights etc, it's desirable to know how many of each coin the PC has rather than an abstract number based on bits. Hell, if nothing else it could be important for encumbrance rules, assuming anyone bothers with encumbrance in RPG's these days.
Brian.
Indeed. A given PC might know that he's better off with 5 gold pieces than 3 gold, 39 silver, 11 copper and 4 bits weight-wise, but he may also find it difficult to spend that gold in a common inn, or even to find a money-changer outside of the big cities who even carries gold.
Then when you consider that that 5 gold's worth may be spread across the coins of different nationalities...
Hm. It seems like it would be best to display a player's coins as a string value, or else you'll have to have display spots for dozens of different coins, from Stahlnish Pfennigen to Ahrian Gold Disks. Perhaps for spending down money, you could have a selection box which you can choose the nation you're in, so when you spend, it detracts from the currency accepted by that nation.
Brian,
I was referring more to your psuedo code, which does convert money up as well. Keeping track of every type of money, while possible, causes many other situations that would need to keep track of. Questions like which coins to spend first, what if certain merchants won't take certain coins, etc. (teeth come to mind.)
Now, back to geek coding.
I would use a linked list to store the money. Each item would be a record that noted the name of the coin, its type(gold,silver,penny,bit) and its weight (light,normal,heavy). Then you could have as many types of coins as you wanted. Some concessions would be in order regarding the sum value of these coins, perhaps your could choose a country value equivalent. Ooh, and when you'd buy something, you could drag money types over until you had enough to cover it, and the merchant would have a currency type that he would make change in, or give him a motley of coins and a preference of what to give to who.
Now we've gone behind a generator program and into a role playing game framework. Gosh computers are fun sometimes.
Jason
I was thinking it'd be simpler just to determine how money is spent outside of the program, then just inputting it. For example, if I am in Stahl, and I buy something costing 13 silver, I might give the man a gold. So I'll minus 1 Stahlnish mark, and then add 7 funten. The program still does what it's supposed to do, but isn't required to be quite so complex.
Slowly but surely the program is taking shape. I've had o deal with a dose of real life, which slowed things down a bit, but hopefully, I'll be able to get some more coding done soon.
Currently, I've allowed for 40 different currencies, including those in the book plus generic light, generic imperial and generic heavy. That leaves 9 or 10 (depending on wether teeth will be included) empty currencies which you can make into your own.
The thing that Wolfen suggests is finished. That is, you can Transfer Cash, which means you "physically" transfer coins from one player purse to another, or to the "world". No changing is done.
The next thing I'm gonna do is the Transfer Value bit. That will be more like "transfer money equal to 10s and 6c(Cyrinthmeiran, Imperial weight) into my purse.". There, you can tell it to do some changing in order to make it as few coins as possible.
Other options here might include exchange rates for different currencies as well as being able to give different currencies different priorities. Perhaps you want to get rid of your foreign coins before you start using native ones. Or maybe you want to *hide* your foreign coins until you get out of the country?
Oh, BTW, can anyone come up with better names than Transfer Cash and Transfer Value?
Each purse can store some 17 (I think) different coin types. I could have made it more, or limitless, but it felt unnecessary.