Re: [glob2-devel] Unit state machine

[Kai Antweiler]

> If you have any reccomendations, desires, or find a feature request
> relating to units, say so now, and I'll try and fit it into the new
> system.

The idea from last year:
 using priority and proximity to assign globs to jobs.

For proximity you have to take account of Leo's transporters.
If this is too hard, we have to use Steph-style transporters.
(By the way:  We can inhibit traffic jams infront of the tp,
 by allowing multiple globs to be on the same field, around the tp.
 That way the tp can be one field big and therefore won't attract
 globs that want to shortcut a local route.)
But I'd prefer to have tps handled by unit assignment code.
Having all glob-behaviour routines concentrated in the code.
Also this way it's more tweakable.

Ah yes, pay attention to make it easy to tweak and enhance.



How do you want to implement the unit building assignment?
The hungarian algorithm for maximum weighted bipartie matching is O((m+n)^3).
Will that be fast enough?  Or do we have to use suboptimal solutions?
http://en.wikipedia.org/wiki/Hungarian_algorithm
http://www.public.iastate.edu/~ddoty/HungarianAlgorithm.html

Vertex set 1: Buildings
Vertex set 2: globs
Edge per resource: exists if glob has correct or no resource type, and can
                   do the job before starving.
Weight of Edge: distance + priority ?
                (small priority number = highest priority)
                or distance * priority, or sqrt(distance) * priorty ?

You'd need the distances between at least all free globs an job offering
buildings.  Better between all nonstarving globs and job offering buildings,
so that jobs can be switched.





Feature proposals:

Globs that go to a restaurant to eat and carry wheat, should increase
the inn's wheat-counter by one when they arrive - if it wasn't maximal.


Globs that want a job, have to comply a triangle inequaltity hunger
check.  If the path 2 * glob->resource + glob->building is bigger than
the glob food level, they should not take the job.
(Maybe unless no one else is about to do it.)


Implement a mechanism, to self destruct a building when construction
finishes.  So that we can use virtual buildings to plant resources.
So when a glob assigns to a "seeding flag", it gets the resource,
brings it to the flag, which then destroys itself and tells the map
to change the field into a resource.


Another bold idea is a mixture of priority and Steph's god actions:
Money.  Buildings have to pay globs money.  The more money a building
offers, the more likely a glob will want to work for it.
So basically this is like priority.  But when we limit the amount of money,
and have the player have to earn it someway ... a new game element.
You shouldn't have too much influences on how to spend money.
Set infinity start money and we have ordinary priority system.


-- 
Kai Antweiler