I think that any system would in the end of the day have to optimize the common case (probably item for gold), while allowing more complex transactions to be relatively painless. Perhaps it would be appropriate to have two different systems for each kind of transaction. The transaction ID system you gave, KaVir, doesn't seem to do very well with more interesting transactions, even something like buying two items and getting a slight discount over buying them separately ("buy in bulk" discount or whatever).

Agreed, although I think it would be nice to keep them consistant with each other if possible.

How about this:

Syntax: barter <player> <item> [<additional items>]
Syntax: barter <transaction ID> <item> [<additional items>]
Syntax: view <transaction ID>
Syntax: accept <transaction ID>

> barter bob sword dagger
You offer to barter a steel longsword and an iron dagger with Bob (transaction ID #X17).

(Bob types 'barter #X17 axe' - he cannot accept as he's not yet made any offer of his own)

Bob offers to exchange your steel longsword and iron dagger for a bronze battleaxe (transaction ID #N04).

> accept #N04
You give Bob your steel longsword and iron dagger in exchange for his bronze battleaxe.

Alternatively:

> barter bob sword dagger
You offer to barter a steel longsword and an iron dagger with Bob (transaction ID #X17).

Bob offers to exchange your steel longsword and iron dagger for a bronze battleaxe (transaction ID #N04).

Bob offers to exchange your steel longsword and iron dagger for a wooden spoon (transaction ID #Q43).

> accept #N04
Bob isn't currently offering anything with transaction number #N04.

Or from the other side:

> barter bob sword dagger
You offer to barter a steel longsword and an iron dagger with Bob (transaction ID #X17).

Bob offers to exchange your steel longsword and iron dagger for a bronze battleaxe (transaction ID #N04).

> barter #N04 egg
You offer to exchange your rotten egg for Bob's bronze battleaxe (transaction ID #L11).

> accept #N04
You've already made an offer.  It's up to Bob to accept or make a counteroffer.

So basically whenever one person makes an offer, it's up to the other to accept. The difference is that the acceptance requires an explicit transaction ID number, meaning it's impossible to slip something in at the last second.

In theory 'barter' and 'sell' could be combined into a single command ('trade'?), but I think I'd prefer having them as two commands.


The 'bulk' thing sounds like more of a shop scenario rather than individual players. If shops play an important part in the mud then I'd suggest a separate system for them, perhaps with some way of attaching prices to objects (including bulk prices if desired) and automatic purchasing rather than an exchange of offers.

Well, you could also have situations where I'll give you two items in exchange for one item, but you might disagree, so we go back and forth for a while: having a trade table makes this back and forth a lot easier. The output you gave works well for fixing the swap-at-last-minute problem, but it could get pretty confusing to have a long stream of these things for back-and-forth haggling.

BTW, shops are fairly important on many games to my knowledge; I think you might have a somewhat unusual situation with your relatively less important shops. (I'm talking about NPC-controlled shops, by the way.)

Back to the OP:
What base? From a Rom-ish standpoint I'd simply extend the object structure to include 'asking price'. If it has one, then it's for sale. (don't save price to pfiles).

Then, the player is simply like a shop if they have certain items for sale.
Maybe a command like 'request # <item>' to set an asking price on it.

You can do all the 'sets the money down' and the 'item' down stuff in the actual transaction. Unless it's meant to all just be RP in which case they can RP that out to their heart's content, and then just type 'buy 3.sword'.

Well, that's why I said something as short as a second's forced delay would probably work perfectly - it wouldn't noticeably interfere with regular trading, but it would prevent split-second scams like that.



This looks like it could work well. I don't think having pages at a time of this is a huge concern since, presumably, the players are still capable of actually communicating with each other - thus, you wouldn't need ten back and forths if you just send the person a tell that you won't trade your battleaxe for anything less than two rotten eggs and a goat's foot.

As far as proper shops go, what's wrong with keeping/using the traditional commands with them? Unless, of course, you want to get into things where the faction that the shopkeeper belongs to likes or dislikes you, which then affects how well they respond to your bartering…but there's no reason that would have to be on a per-item basis, you could walk up to a shopkeeper, 'list' their inventory and prices, and 'haggle' with them to try to affect all of their prices by some percentage.