Re: Up next: facility_worth?

[Lincoln Peters <peters2000 at mindspring dot com>]

On Fri, 2002-07-26 at 16:11, Hans Ronne wrote:
> 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.

That scheme sounds like it would work if the fragmentation were not an
issue and plan_defense_support did exist.  Although I imagine that a
unified PLAN_BUILD would be less prone to fragmentation in the first
place.

> 
> 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.

Last-minute decisions are not always as good as foresight.  In
fantasy.g, a wizard might be able to save his homeland from invasion by
building a Lightning spell that blows up the enemy's loaded cloudkeep
(or flying carpet, or sailing ship, or whatever).  However, few games
allow things to be build so quickly that last-minute decisions are
effective at all.

On the other hand, building exploratory units (e.g. priests with crystal
balls) should not happen at all when an invasion is underway and the AI
needs offensive units (e.g. cavalry) and defensive units (e.g.
paladins).  That is a bug no matter how the code is supposed to work.

> 
> 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.

That makes sense.  It sounds to me like the "Build" plan might work by
using different goals for building different kinds of units.  In the
"Lord of The Rings" game, it might look like:

Goal: Build offensive units, then destroy Mordor's orcs.
Goal: Build defensive units, then fortify Gondor's City Minas Tirith.
Goal: Build exploratory units, then know vicinity 5x5 around Mount Doom.
Goal: Build colonizing units, then build 3 new city units.
Goal: Build facility unit to improve defense by 50%.
Goal: Build siege units, then capture Mordor's City Minas Morgul.

(The idea behind the second goal is that it would be passed on to the
units that it builds.)

Theoretically, the planning code would then determine the units best
suited for the job and build them.  Of course, it would be wise to build
an army of knights to fight off the orcs *before* the orcs are within
the vision-range of the city.

> 
> 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.

I think that the problem was fixed in galaxy2.g; photon torpedoes were
changed into a material that is consumed when starship attack by
firing.  So the problem no longer exists there, although in "Colonizer"
the problem remains.

Of course, there are situations in some other games where separate task
queues for such units would be unrealistic.  For example, in fantasy.g,
the smartest thing that a wizard could do when entering battle is to
build an arsenal of spells that can be launched as soon as enemies are
spotted, as well as an arsenal of magical items that will help the
wizard defend himself.  It would be ridiculous if a wizard could move
and cast a spell at the same time.