Re: [glob2-devel] info on latest edits in Unit.cpp

[Bradley Arsenault]

On 4/23/07, Leo Wandersleb <address@hidden> wrote:
> Hi list
>
> I was trying to improve unit<->building matching what i could not achieve as 
> well as expected. But for other ideas i hope on help by Bradley as I guess they are 
> more promising.

The new system itself was a big improvement over the previous system,
I recorded less starvation, and more work getting done when there are
free workers. I wanted to solve the bug of when there are free workers
and they aren't working.

Really, there is only so much work you can crank out of a set of
workers, no matter how much unit-job assignment optimization you do.

> == What I did ==
> first i changed a while(workersNeeded) into a if(workersNeeded) what resulted 
> in a more even distribution of workers.

I suppose this might work. It reduces the priority system to almost
ineffective, seeing as only the last few units will actually be sent
to higher priority buildings, as opposed to my design of rigid
priorities. But if it works, it works.


> second i didn't prioritize units having the right resource over all other units 
> but rather weighted each case to pick the best (formula made up based on some 
> ideas and tested but surely not perfect although no strange behaviour occured).

> (third i tried to change unit removal as it only removed one worker that wasn't 
> needed anymore and not all of them but it doesn't get called at the right time. 
> upon delivery of res x all units carrying res x that are no needed anymore 
> should immediately released)

Yeah, I suppose this would be a minor bug. The program would keep
those units, and they would quit after they reach the building and try
to pass the ressource.


> All this resulted in a slight improvement when there were -55/140 workers free. 
> in numbers:
> my version took 110 game seconds
> version 23 took 130 game seconds
> to finish all construction sites in a given save game.

Aye, this is most likely due to your first change, less units are
going to Inns, and more to construction sites, since Inns are priority
buildings.

> With 9/218 workers free i got:
> my version took 40 game seconds
> version 23 took 40 game seconds
> to finish all construction sites in a given save game.

Yeah, this is because most of my optimization work on the old system
was done when therre are free workers, and my plan of what made it
better was based entirely arround there being free workers. In both
our systems a building is garunteed a unit if its available, so there
would be no advantage to your system really, because all the buildings
still get workers.


> == What needs to be done ==
> *release all units not needed anymore without waiting for the delivery of an 
> unwanted res.
> *if there are more jobs than workers, workers should choose job, not the other 
> way round!!
>  in such a condition single units will automatically work for the first 
> building in the line even if there are as important buildings maybe needing the 
> carried resource.

The second change is going isn't going to be easy. It doesn't fit in
with the architecture I created, at least not directly. And I highly
doubt that it will make a very dramatic improvement. It would add
allot more unnesseccarry complexity, it would make the code confusing,
considering the same task is done in two areas, with an obscure
condition seperating the two.

I very highly doubt the advantage, but we should definitly measure it.


> I expect a dramatic improvement on large town management by the second change.
>
> Greetings, Leo Wandersleb

Well I would start by making a few unit-building matching functions in
Team, similar in structure to the building-unit matching functions.
Use a predicate based system, again very similar. My original design
was to have a two pass predicate system.

There would be a class UnitPredicate, which would have a filter
function that tells whether a unit can work at a particular building
(filtering out any units that can not work, for any reason), and then
having a comparison function in the predicate as well. The code would
be elegant, something like this:

///Copy the myUnits into a local vector
std::vector<Unit*> units(myUnits, myUnits+1024);
///Create the two predicates
UnitFilterPredicate ufp(this);
UnitSortPredicate usp(this);
///This will move all the units that don't satisfy the predicate to the end,
///and returns the new endpoint for units that do satisfy the predicate
std::vector<Unit*>::iterator end = std::remove(units.begin(), units.end(), ufp);
///Sort the units at the begginning, (the ones that satisfied the predicate)
std::sort(units.begin(), end, usp);
///Iterate through the first units, up to the end point, or until all positions
///have been satisfied
for(std::vector<Unit*>::iterator i=units.begin(); i!=end &&
desiredUnits > 0; ++i)
{
   i->subscriptionSuccess(this);
   desiredUnits-=1;
}

Thats just quick off the top of my head, I will probably implement it
with my core rewrite that I *am* working on (slowly, lots of code to
read).

Other than that, go right at it

--
Really. I'm not lieing. Bradley Arsenault.