From ghudson@cie.uoregon.edu Tue Mar 6 17:09:23 1990 Received: from oregon.uoregon.edu by ernie.Berkeley.EDU (5.61/1.36) id AA19401; Tue, 6 Mar 90 17:09:11 -0800 Received: from cie.uoregon.edu by oregon.uoregon.edu; Tue, 6 Mar 90 17:07 PST Received: by cie.uoregon.edu (MC 2.0/SMI-4.0.1.2(JQJ)) id AA09277; Tue, 6 Mar 90 17:07:48 PST Date: Tue, 6 Mar 90 17:07:48 PST From: ghudson@cie.uoregon.edu Subject: Re: Haggling To: wilson@ernie.Berkeley.EDU Message-Id: <9003070107.AA09277@cie.uoregon.edu> X-Envelope-To: wilson@ernie.Berkeley.EDU Status: RO > Drat. This will ahve to be fixed somehow, maybe by setting a bit in each > individual object when bought/sold, so that it can only contribute to the > good/bad bargain counts once. Reasonable. Shouldn't take too much coding. Since this is getting so complex, you might try to put in some clue as to how good of a bargainer you are, e.g. when you start bargaining, you have a small (10%-20%) chance of getting a message like: The merchant looks at you distatesfully The merchant eyes you with a hint of respect Something like that. Now, on to our (3*bad + 20) formula: Simplified, this could be algorythm'd like so: ptr = 20; case pointer += 3; case pointer -= 1; if (ptr == 0) Okay, that was of course a mishhash of something slightly resembling C code, but you get the idea. But I don't like how if you missed the final offer by one gold piece, your pointer goes up by three, even if the item was worth some 900 to start with. I'd think it'd be better if that was more like: case pointer += (price paid - low price) / low price * 10 So you lose one point for each 10% over the final value that you paid. This isn't particularly accurate, unfortunately, but that might be remedied by a (float) ptr. (I just realized that "ptr" is a pretty dumb name for what should be called "counter" or something. Sorry...) Back to our spoiler solution, do note that one could still buy a bunch of junk and still up (down, via my algorythm) your counter, even though you didn't need the item. I really don't have a solution, other than expanding the code so that each price range (increments of about a hundred, so the first few would be 10-100, 11-200, 201-300 and the last few would be 801-900 and 901-1000 or 901-999, however you work it) gets a separate counter. Natur- ally, this would have to be accompanied by a decrease of the original counter value to 10 or 5 or so (or a different value for each range, since players will buy a lot more items in the 10-100 range). > Thanks for the warning. Just came to my mind. It isn't quite so bad, since items under 10 gp final price don't count, so one couldn't up your counter by buying flasks of oil or something. Greg Hudson ghudson@cie.uoregon.edu "Though the Earth, and all inferior Creatures be common to all Men, yet every Man has a Property in his own Person. This no Body has any Right to but himself." -- John Locke, _Two Treatises of Government_, 2nd Treatise I am blatantly close-minded and refuse to admit it. There are missionaries aplenty, but few enlightened. Believe me.