[Widelands-public] Buildings & Resources

[Elann V. <ela...@ya...>]

----- Original Message -----
From: <Si...@gm...>
To: <wid...@li...>
Sent: Thursday, July 25, 2002 3:04 PM
Subject: Re: [Widelands-public] My contribution


> > I've thought about managing needed material for buildings before, during
and after construction. I'll explain it if you haven't.
> pls explain. probably you can contribute. as you will see (looking
> through building.cc), there's a framework done which will be used, but
> your work may fill in neatly, though
>
> Greets
> Holger


My idea is to create a class Needs which would contain the list of needed
goods - maybe another class for needed people though people and goods are
treated much the same way (except that you don't have to carry people of
course). Each flag and building would have one along with a container -
could be named Inventory for example.

The idea for fulfilling needs is to compare Needs and Inventory. For each
kind of resource where Needs>Inventory, an "order" must be transmitted. Then
there are different possibilities : centralized requests or peer-to-peer
requests.

In centralized requests, each settlement has a "base" from which the goods
are shared. Another possibility would be to have as many "base" as there are
stock buildings. (then the nearest would be tried first then next nearest
...) If we keep the first centralized possibility, it means the "base" knows
all the stocks and determines from where to send requested goods. In both
cases, the request is something purely virtual, seen only by the programmer.

In a peer-to-peer model, when something needs something (a flag needs a
good), the nearest available carrier comes to see what is needed. (we could
add to SII a mobility in flags to show need). If he has it at the other end
of his road, he brings it back. Else he asks the next carrier in the
direction of a stock. (this could be determined by a stored distance to
stock or something like that - the carrier has to come from a stock, he
could store his path to know the way back). This way until a carrier finds
the wanted thing, in a flag stock or available in a building.

The quite complicated matter is the priority of requests. This could be
achieved by flags asking with a level of priority. A carrier keeps in mind
his current job's level of priority and if something with a priority >>
occurs, he forgets it. If the priority is just above, maybe he can complete
it before. (else it would become a vast heap of abandonned goods).


That's all for this mail - I've written quite a lot for one post. I may
develop more or write it down more formally if you ask me.

CU

Elann


___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com