[Dev-sig] Economic/Transport Simulations

[Emerson, Tom (*IC)]

> -----Original Message----- Of Robert Leyva
> 
> I would enjoy helping, but have to qualify help to mean (just 
> a little, and not too often), as I don't seem to have much 
> free time lately.
> 
> But, I do want to help, just don't want to promise more than 
> I could deliver.

No problem -- I'm still in the "thrashing about some ideas" mode anyway
;)

As I mentioned previously, I'm approaching this in an "object-oriented"
way.  I'm headed more towards a "toolkit" for creating eco/transport
sims than about creating any one specific sim, so ideas are welcome at
this point.

OK, What I'm about to describe is getting "quite complex" even though
I'm only describing 3 basic objects:

   1) resources
   2) containers
   3) consumers
   
====================================================================

So, to begin with, we have a supply of "desirable resources".  Resources
are placed in "containers" that do one of three things to the resource:
change it's LOCATION, change WHAT it is, or simply hold onto it UNTIL
needed [changes it's "TIME" domain].  Ultimately the resource ends up in
the hands of the "consumer" who, naturally, "consumes" the resource over
time...

To begin with, a resource has very few attributes and almost no
behaviours:

   Attributes:
      * name or ID [what is the resource?]
      * perishable [does it go bad?]
      * spoilage-rate [If so, how fast does it go bad]
      * amount-spoiled [how much has gone bad so far?]
        (?) expressed as an absolute QTY or as a percentage (?)
   Behaviours:
      * [ONLY if perishable...] per time-tick, "age" 
        --> increase percentage-spoiled
        --> if percentage >= 100, "self transform" to a "waste"
(undesirable) resource

The way the RESOURCE gets to the CONSUMER is by placing it in a
CONTAINER.  [As I'll show below, a consumer can be a sub-class of
"container", so this "CONTAINER" can be the consumer itself i.e., the
consumer picks fruit from a tree in his own yard, but that doesn't make
for a very fun simulator ;) ]

In reality, the "resource" will be handed off between series of
mobile/immobile containers:
  * [a field-worker picks the fruit]
  * it [MAY] get TRANSPORTED to a WAREHOUSE
  * it [MAY] get TRANSPORTED to a PROCESSOR
  * [AT the processor] it gets canned or converted to jam/jelly
  * it [MAY] get TRANSPORTED [again] to another WAREHOUSE
  * it gets TRANSPORTED to a STORE
  * and finally the "consumer" buys it from the store...

These "container" objects have one property in common: how much of the
resource they "hold".

The behaviour of containers depends upon whether the container is mobile
or immobile.  A "mobile" container will CHANGE the "location" of the
resource, while an immobile object changes either WHAT the resource is,
or WHEN the resource is consumed (relative to when it was produced)  

To elaborate on that last point, consider a "refrigerator": this would
be a specialized form of an immobile [storage] object that has, as an
attribute/behaviour, the ability to reduce the spoilage rate of a
perishable item.  Of course, in "real life" a storage facility designed
for perishable items is usually MADE UP of "refrigerators" in the first
place, so we could easily state that ALL "storage locations" have the
ability to "reduce spoilage rate", and therefore the distinction between
a STOREHOUSE and a REFRIGERATOR would only be the capacity...  

this is even true of transports [refrigerated trucks] and processing
facilities [a primary point of "processing" food is to reduce how fast
it spoils, so in it's "raw" state, fruit would spoil in a week or two,
but if "processed" into jam/jelly, it will last for months...] but that
just makes this "simulation" platform way too complex

Finally, we reach the "consumer".  A consumer has a couple of critical
characteristics and some fairly simple behaviours:

   attributes:
     * a [fixed] location within the "world"
     * some quantity of a desirable resource "on hand"
       [so in effect they inherit from "container"]
     * some level of desire for the above resource
     --> which affects:
         * how quickly they consume that resource
         * when they WANT to replenish and 
         * when they MUST replenish the resource

   behaviours:
     * every "interval", consume some amount of resources they have on
hand [poof, they're gone...]
     -> if the remaining level of resource is below the WANT level, look
for more
     -> if the remaining level is at or below the MUST HAVE level [often
this would be 'zero'] actively seek out a replacement (the difference
between "merely looking for" and "actively seeking" could be how far the
"simulant" goes to find the resource, expressed in some "world-level"
units of distance)

So far, the only interaction between "resources" and "containers" is
what the container does to the resource [moves, transforms, or stores
for some time]  A consumer, however has a few additional interactions
[outside of the obvious: actual consumption of the resource!]

   * during an update cycle, a consumer can "make a decision" to throw
away the entire quantity of the resource if the percentage spoiled is
too high, or discard only the "percent spoiled" [reduce the qty-on-hand
AND reset the spoilage to zero%]
   * when replenishing, discard the spoiled portion before adding the
newly aquired resource; remember to reset the percentage...

rationale: the "spoilage-rate" applies to the entire amount of the
resource, but once spoiled, it can't get any worse -- think "compound
interest" here: if you start with 100 units and a 10% spoilage rate, 10
units "go bad" per update.  If after 5 update intervals you decide to
"throw away" the bad part, the remaining quantity "goes bad" at only 5
units/interval instead of 10.

So as I said above: three basic "objects", but they break down as
follows:

   1) resources
   2) containers
      2.1) that transport resources
      2.2) that DO NOT transport resources
      --> instead they:
      2.2.1) store the resource for later usage
      2.2.2) transform it into another resource
   3) consumers

And, though it may seem a stretch, "consumers" are really a subclass of
2.2.2: they hold some qty "on hand", they don't move, and they
"transform" the resource into "nothing" [or lots of waste...]


[OK, this is about the third iteration -- it isn't getting any shorter,
but it is FAR clearer than the original -- /trust me/ ;) ]