Re: [htsserver-devel] finally start implementing the trading engine
Status: Abandoned
Brought to you by:
uh1763
Menu
▾
▴
Re: [htsserver-devel] finally start implementing the trading engine
|
From: Uwe H. <uh...@bi...> - 2000-01-19 17:43:42
|
On Tue, Jan 18, 2000 at 03:45:56PM +0100, Sven M. Hallberg wrote:
> 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.
ACK.
Additionally there will be a file
/usr/local/share/games/htsserver/worlds/medieval/goods.dat or something,
where the initial values are read from.
Optionally they could be created randomly.
> 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.
Yes, probably.
Maybe we should even store all this data in plain arrays, as the
*number* of goods won't change dynamically during the game,
only the *contents* of the array will change.
This should simplify and/or speed up several things.
> Another thing: what's the price member??
It's basically just a variable to buffer the calculated price for that
good in that special town, so you don't have to calculate it again and
again, if you need the current price.
Not really mandatory, could be removed.
> I'd make it the average of all offers
> for this good in the area.
The details of calculating the price based on demand, supply and maybe
some other factors, is something we need to put lots of thought into,
because this is what is the most important thing in a trading-game, I
guess :-)
I'm currently reading some texts about economy, price, value, markets
etc. to get a feeling for this topic. I hope I can use some of that
stuff in htsserver...
> 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.
This is all client-side. If a client desires so, it can also save
*all* prices it ever saw, maybe to be able to output statistics or to
make market predictions, who knows :-)
> Also, consider a different name for the structure. Just 'good' is a bit
> misleading, especially if we introduce further stuff dealing with 'goods'.
> Suggestion:
Hmm.. depends. I don't think there will be that many other structs for
goods...
> long demand; /* somehow resembles how much has been bought
> * of this good in the near past. */
Yes, but not only. It's also influenced by the current weather, time,
political situation(if we introduce something like this in Holsham
Traders) and several other factors.
> long supply; /* similarly to the above, somehow resembles
> * how much supply of this good the market
> * seems to be holding currently. */
see above.
> 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.
The base economy is partly created by the inhabitants of the town, cause
they need food, clothes, weapons and drugs :-)
The more inhabitants, the higher the demand.
The more farmers in the town, the fewer demand for food from other towns.
The higher the crime-rate is, the more police uniforms are in demand :-)
etc. etc.
> 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.
We should do both. Have a base economy (rather statical, stays roughly
the same over longer periods of time, normally) and AI-controlled
traders, who behave quite like human players:
* they drive around
* buy/sell stuff
etc.
> 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.
Separated from the server? Guess not.
I don't really want to have to fork() 30-100 new processes which act as
AI-traders and probably even connect via sockets and use htsprotocol...
I think these AI-traders should remain in the server.
Also, because the admin should be able to choose the number of
AI-traders
1. dynamically during runtime
2. at the start of the game
3. in the configfile
> 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.
ACK.
> 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.
ACK.
> 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 */
Nope. Price is calculated by the server.
> long price_change; /* price change since last time we checked */
Yes.
> 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. */
This belongs in the server. The client doesn't know about supply/demand.
It only sees the price of a good, not how much demand there is for it.
> 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.
Sure. You won't know how much stuff a player has got, but only how much
he offers.
> > > 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.
Yes, well... but the transporters/ships/vehicles need to drive from one
town to another.
We need to calculate an amount of time, how long it will take a
transporter to drive from town A to town B. This could be calculated
based on a real map (2d or maybe even 3D), e.g. if you have to drive
over some mountains, you'll be slower, etc.
> They all reside in the central town of Holsham from where they monitor
> the activities in different cities.
Basically yes. BUT: The players can only monitor any prices/amounts etc.
of towns where they have a transporter stationed. Otherwise they don't
know how much something costs in that town, which other players are in
that town etc. etc.
I know this is not very realistic(I mean you have hoover-craft like
transporters, and a very high technical standard etc.), but it is *very*
important for the gameplay.
> 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.
Yep.
> One should be able to gain storage
> capacity by stationing freighters in the city or by hiring local depot space.
Yep.
Buying and/or hiring depots/warehouses should definately be possible.
> > 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 (:])).
^^
artificial losers? :-)
> My idea would be to have, in each town a list
> of open "offers" to which anyone interested can respond.
Hmm.. something like a bulletin board... yep. Or maybe 'market' is the
better word.
> 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".
Sounds nice.
> 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.
Yep.
> 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.
ACK.
> 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.
Yep. I don't see any problems here.
> 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:
This should be handled by the client, yes. Definately.
> - accept
> - deny
> - deny all
> - revoke offer
Ack. Depends on the client you use(whether it offers such options).
> Of course, if the player choses "accept", all others are implicitly denied...
Yep.
> Ok, I think that'll be enough for you to chew on ;-)
guess so, yes :-)
Uwe.
--
Uwe Hermann <uh...@bi...>
http://www.bingo-ev.de/~uh1763/index.html
-----------------------------------------
:wq
|
