Re: [htsserver-devel] finally start implementing the trading engine

[Sven M. H. <pe...@so...>]

On Fri, Jan 14, 2000 at 12:31:40AM +0100, Uwe Hermann wrote:
> This is what we have at the moment:
> 
> 
> typedef struct good_t
> {
>  char name[MAX_LEN_GOODNAME];
>  long nominal_price;             /* standard price; is the same in all towns */
>  long price_paid;                /* price you paid when buying the good */
>  long price;                     /* current price */
>  long amount;
>  long demand;
>  long supply;                    /* TODO average amount of goods in town? */
> } good_t;

We shouldn't save the nominal price in here, because it'll always be the same.
Rather create a list containing only goods and their respective nominal
prices. Name it good_nominals or something.
Or wait, I have an even better Idea, name the list good_specs and also put in
it an ID number for every good. Then use the ID num in all other structs. One
could even consider saving pointers to the respective good_spec structure in
structures like good_t. That would save us loads of memory and cut down
_severely_ on cpu usage during lookups of good data.

Another thing: what's the price member?? I'd make it the average of all offers
for this good in the area. It could then be described as "average market
value". The respective trader can compare it easily to his 'price_paid' and
decide whether it's worth looking into the specific offers. There should also
be a member 'price_change' or something, indicating the change of the price
since the last update of the price member.

Also, consider a different name for the structure. Just 'good' is a bit
misleading, especially if we introduce further stuff dealing with 'goods'.
Suggestion:

typedef struct personal_good_data personal_gdata_t {
	struct good_spec *good;
	long amount;
	long price_paid;	/* per unit */
	long price;		/* average price of open offers in this area */
	long price_change;	/* price change since last time we checked */
	long demand;		/* somehow resembles how much has been bought
				 * of this good in the near past. */
	long supply;		/* similarly to the above, somehow resembles
				 * how much supply of this good the market
				 * seems to be holding currently. */
}

You might have noticed, how all this stuff is pretty focused on the traders,
it all seems to apply perfectly to a client, rather than to the server. This
leads me to a - rather radical - suggestion. Don't implement behaviour of
towns / AI traders in the server. Create "AI clients" which behave kind of
like the bots in popular 3D shoot-em-ups. This sounds pretty complicating, but
I think it's doable if one looks at it the following way:

We had planned the towns to act kind of like traders that a) can't move, b)
have huge storage capabilities, c) always buy/sell stuff in order to create a
base economy for human traders. If we scrap that concept and instead
"populate" the town with a really simple AI trader which does the same thing
(doesn't move away -> needs no freighters, hires storage from the town as
necessary, and monitors the market to eventually accept offers of other
traders) we have a much more flexible and realistic simulation of the economic
happenings. And it won't be more complicated, because It doesn't really have
much more to do. On the contrary, it's probably easier, because it's seperated
from the server, which will make the server application easier to overview.

In respect to that we must think about, what of the above actually applies to
the server, and what to the client. I'd use the above structure
'personal_gdata_t' for the client and save only the amount of goods a client
owns in the server. The server is not really interested in what the client
thinks about market flow and stuff like that (provided it's not concerned with
acting as the trader, mind you). All it needs to know is, whether to allow the
client to buy/sell a certain amount of goods at a given time.

in the server:

typedef struct player_good_data player_gdata_t {
	struct good_spec *good;
	long amount;
}

in the client:

typedef struct personal_good_data personal_gdata_t {
	struct good_spec *good;
	long amount;
	long price_paid;	/* per unit */
	long price;		/* average price of open offers in this area */
	long price_change;	/* price change since last time we checked */
	long demand;		/* somehow resembles how much has been bought
				 * of this good in the near past. */
	long supply;		/* similarly to the above, somehow resembles
				 * how much supply of this good the market
				 * seems to be holding currently. */
}


> Every trader(players, computer-players, towns...) will have one of
> these good_t.

ACK.

> The goods will be stored in linked lists. Only those goods which are
> available in a town will be in the list of the town, and only those will
> be shown in the client.

I'd display only open offers for that town. You don't usually know how much of
a good all other companies posess. I'll go into more detail about offers and
such further down in this mail.

> > How to travel? (map, streats, storage format)
> 
> Not sure about this. Haven't really thought about it, yet.

It is my understanding that players don't travel at all. They all reside in
the central town of Holsham from where they monitor the activities in
different cities. They have freighters which can be sent to these cities which
enables the trader to sell the goods contained in the freighter to others who
have storage capacity in that city. One should be able to gain storage
capacity by stationing freighters in the city or by hiring local depot space.

> Human vs. Human:
>  There will be a chat-like environment, where both traders (or 3 or 4..)
>  can agree on a price and amount of what they want to trade.
>  
> Also see docs/FEATURES for some more stuff.
> 
> 
> >   *let the game engine say the prices (how?)
> 
> If you buy/sell from/to a town, you'll have to either pay the price the
> town asks for, or not buy at all. I don't think you will be able to
> work out price agreements with a town.

Now here comes my suggestion: Create _one_ way of trading that applies to
everyone (humans, AI, AL (:])). My idea would be to have, in each town a list
of open "offers" to which anyone interested can respond.

Offers can be "buy" or "sell" offers. If a player wants to sell a particular
good, he opens a "sell offer" for a certain amount of that good. From that
moment on, he doesn't actually "have" the good anymore. However, he will of
course be able to revoke the offer, which will bring his goods back. Anyone
else can accept the offer, which will immediately gain him the offered goods
at the offered price. The money is transmitted to the originator of the offer.
You can easily imagine the same for "buy offers".

If an offer doesn't seem to be of any interest to anyone, the player can of
course change the offered price. He might also have been persuaded to do this
by another human player, who might have contacted him via the standard chat
interface.

I think one should be able to mark offers as "confirm" or "no-confirm", which
means, if anyone wants to accept an offer, the player is asked to confirm the
trade, while with a no-confirm offer the trade will be initiated automatically.

I'm also thinking of the problem of a large number of traders acting
at the same time. But I think we'll be able to deal with that. Imagine the
following scenario:

A player offers "wheat" for 15 creds per unit as a confirm offer. Now, this is
a real bargain and everyone else wants it. Now this poor player immediately
receives 20 requests for accepting the offer. It'll be a pain to go through
every request, but I think this can be handled quite conveniently by the
client by providing actions to the player like the following:

- accept
- deny
- deny all
- revoke offer

Of course, if the player choses "accept", all others are implicitly denied...


Ok, I think that'll be enough for you to chew on ;-)


Greetings,
Sven

-- 
Sven M. Hallberg <pe...@gm...>
PGP key available at http://www.sh-home.de/~sol
 [ KeyID........: 0x0F520CF9 ]
 [ Fingerprint..: 56 61 00 18 14 B4 01 01  06 90 D0 29 96 BD 58 6F ]
return 0;