Re: [glob2-devel] Some gameplay comments on 0.9.3

[Stéphane Magnenat]

Hello,

> > - I think that the warriors are too strong, especially at the start of
> > game : it makes rush too easy in my opinion,.
>
> Although I did not experience them to be too strong (they barely kill a
> swarm and this swarm can produce warriors to occupy the "rushers".) I
> wonder what is wrong about the possibility to rush? I want to have choice
> and a threat from second one gives me the choice take rush or to risk
> putting all on growth or take defensive measures and thus do something in
> between those two.

I agree; but in my case, my strategy was to build a second swarm some 20 cases 
away while building my inn close to my first swarm (they were far away any 
water), and the unit allocation behavior made units constantly traveling 
those 20 cases. In that setup, warriors were too strong, but I agree that 
this is more related to the unit allocator than to the warriors themselves.

> > - I've seen that the unit allocation algo. was changed for reallocating
> > unit each time after one work (such as bringing one resource) ; while
> > this add dynamism, it is very frustrating at start of game, because units
> > tend to change targets of work very often and the whole colony behaves
> > really bad. This may be a bug in the way the score for unit-to-work
> > allocation is computed, or an instability in the allocation algo. Maybe
> > we can lock the unit to a target for more than one work, as it was done
> > previously.
>
> we've switched back to bradley's ua as people (or person) complained the
> waste of resources that occured in my algo.
> i can remember talking to you Stephane about the fireing after each task
> and how it makes sense. it solves the issue of new tasks (like training) to
> get chosen far too late. i guess the problem now is that they don't work
> for any task for some time. in times of under employment the behaviour you
> are missing now (glob grabs wheat and puts it into swarm 15 times in a row)
> should be the same with fireing and instantly hireing it as it is the best
> choice. in times of full employment, the top priority task pulls the unit
> away after one wheat which is not necessarily bad. it's only bad as there
> are several top priority tasks each stealing workers from the others. here
> we must switch to ( free_worker_count <= 0.05*worker_count ? "worker
> chooses task" : "task chooses worker" )

I think that firing after each task makes sense as long as distance to jobs is 
correctly weighted. I think that in the case I experienced, the distance to 
job was not weighted properly or there was not enough delay for the latest 
employer to propose a new job. The result was units constantly traveling 20 
cases. When my colony was sufficiently advanced, things went very smooth; so 
I don't say the algo. is bad in itself, but maybe it should be weighted 
depending on the context.

Have a nice day,

Steph

-- 
http://stephane.magnenat.net