Re: [glob2-devel] Nicowar Revision 3, New Unit Allocation System Needed

[Stéphane Magnenat]

Hello,

> This bug has been talked about, and a fix had been started in another
> branch. But its since been forgotten about. So, I'm going to rewrite
> the unit allocation system myself. The new system works like this:

We began to rework it with Nbut then Nuage had to move in another country for 
job so indeed this work was idled. The branch is unit-rewrite and it can be 
some help to you if you want to work on unit allocation.

> 1) The focus is on the building, the building chooses the unit
> 2) Every tick (or so), buildings are prioritized, and higher priority
> buildings (eg Inn) get first pick
> 3) The chain is worked down untill every building is satisfied.
> 4) The unit remains working at the building untill it can no longer
> work there or the building lays the unit off the job
>
> This fairly simple set of rules has the advantage that every unit will
> be used if it can be used. No playing arround. No bugs. Just pure,
> simple allocation. It can have some surprisingly intelligent results.
> Prioritizing the buildings doesn't have to be simple. Building
> priorities can be based on
> 1) The type of building (eg Inn has higher priority)
> 2) User settings (the low-medium-high buttons that have already been
> discussed) 3) The number of units already working at the building
>
> How a building picks a unit doen't have to be complex. Units with the
> ressource that the building needs comes first (unless the task at hand
> isn't collecting ressources), and after that the closest unit is
> picked.
>
> Minimizing the complex rules is meant to minimize bugs and maximize
> the result. The only complexity in this system should be how buildings
> are prioritised, but even that is simple, clear, concise code.

I only partially agree here. It's clear the simplest way to do something 
should be chosen, but one has to take care that if there is some complexity 
in the task (and there is), there is a lower bound on the complexity that 
cannot be broken. For instance, in glob2, you should not allocate a unit to a 
building directly but rather wait some time (for instance 32 ticks) to see if 
there is no unit that has a better score of allocation. In the same idea, one 
should not only take the distance of the unit into account but the 
triangulated distance of unit/resource/building to compute the score.

Have a nice day,

Steph


-- 
http://nct.ysagoon.com