Re: Up next: facility_worth?

[Hans Ronne <hronne at pp dot sbbs dot se>]

>I don't remember if I ever heard your several reasons, but there isn't a
>generic
>plan to build because there are very few games in which building is a goal in
>itself.  The purpose of building is to have units that can achieve some goal,
>and unit doing the building must know what that goal is.  So even if you have
>a plan to build, you still end up needing to go through the same computation
>of whether you need to attack or defend more, and then choose a unit type that
>seems most appropriate - but you build it instead of going to do the job
>yourself (at least if you're immobile and untransportable :-) ).

The main problem with the current build code, as I see it, is the code
fragmentation. We have plan_offense_support, plan_explorer_support,
plan_colonizer_support for non-advanced units and auto_pick_new_build_task
for advanced units doing pretty much the same thing, but in slightly
different ways. And there is no plan_defense_support, which there should be.

I have also seen a lot of cities build explorers etc. when they really
needed to build defenders to protect themselves from imminent attack.
Therefore, I think the best time to decide what should be built is as late
as possible, i.e. when the unit picks the build task. Until that moment,
all options should be on the table, and not be restricted by plan types
that may well be outdated. This is how the advanced unit build code works.
When a unit has been completed, auto_pick_new_plan is called to analyze the
current situation and decide what type of units are needed, after which
auto_pick_new_build_task immediately picks the unit to build. However,
these two functions could just as well be consolidated into one. A plan
type which is picked and then immediately converted into build action is
kind of redundant. It does not correspond to a long-range goal, I agree
with you on that point.

So my vision of a unified build code would be something slimilar. The
tactical situation is analyzed on-the-fly, when the unit needs to pick a
new build task. Depending on what is needed right there and then, anything
may be built: an offensive unit, a defensive unit or a facililty.

>Another consideration is games like galaxy, where you want units that
>build their projectiles while moving in for the attack.

Mobile units that can build are indeed difficult to handle right now.
Lincoln also ran into that problem recently with his colonizer game. I
think the main problem is the fact that we only have one task queue. If the
unit pushes a move task, it tends to forget what it was building and where.
One possible solution would to have a separate task queue for building,
kind of similar to unit-based research. The unit would then be able to move
and build at the same time. This was actually one reason why I wrote the
acp-independent build code: that it would be possible for those units to
use acps for other types of actions at the same time. Yet another idea that
remains to be fully implemented, though.

>One of the uses of putting worths into doctrine is that you could then have an
>AI with designer-suggested weights play against an AI without, and see who
>wins.

Yes. Or different sides with different designer-suggested weights. Kind of
a cheap version of the multiple AI scenario.

Hans





Hans Ronne

hronne@pp.sbbs.se