This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Error handling


On Tue, 2003-01-07 at 00:27, Hans Ronne wrote:
> So then the tech development is the culprit, since side_can_build always
> will return zero for something that has not been developed yet.

I imagine that the best solution would be to add something to
side_can_build that returns "true" if the unit cam be developed. 
Although I think that there should be a unit_can_build function
somewhere so that the AI considers not only if the unit can be built,
but if the colonizer can build it.  In this game, for example, there are
several units that can build explosives on-the-fly, but only two can
actually develop them.  

> The problem here is rather the plan. Right now, a unit that can colonize
> (build units that can build other units, not necessarily of the first type)
> will always be assigned PLAN_COLONIZING. The theory here is that colonizing
> is a very important activity that is essential for winning the game. Thus,
> units who can colonize should not waste time on building other stuff. What
> you are asking for, is the possibility to do exactly that. This would
> require a hack to the mplayer where say 10% of the colonizers were assigned
> another plan, such as PLAN_DEFENSIVE, to build defensive units. There is a
> catch here, though: mobile units will build stuff if assigned
> PLAN_DEFENSIVE (or any other plan) only if they have zero defensive worth
> etc (see mplayer_decide_plan). Which is not the case for you. In short, the
> concept of mobile builders is not well supported in the code.

The way that the AI handles colonization seems problematic.  Oftentimes,
in games such as fantasy.g or postmodern.g, it will focus on
colonization to the exclusion of everything else.  As a result, the AI
finds itself doomed if it is subjected to even *one* loaded airlifter or
cloudkeep.

Likewise, in my new game, even if the AI somehow manages to land any
military units on my shores, if I have at least one tower, I can be
constantly shooting at its forces regardless of whatever else is
defending the area.  Oftentimes, the tower can even sink a troop
transport before it reaches the shore!

> Actually, the base can build any of three things: a base, a tower, and a
> >wall.  The base is the primary producer of everything.  The tower is
> >neither advanced nor acp-independent, but it can fire at enemy units and
> >build explosives (rockets and such).  The wall is nothing more than an
> >impassible barrier with 1,000 HP (a tank has 50 HP), and so doesn't act
> >in any way.
> 
> So in this case the problem is that your bases are acp-independent (it is
> this that matters rather than if they are advanced) and therefore use the
> old code in plan_explorer_support . I am willing to bet that your spy plane
> is well down the unit list.

Oops, I meant that the *engineer* can build a base, a tower, or a wall. 
And nothing is acp-independent.

> >What is confusing the AI may be that the engineers are built to quickly
> >clear wrecks and demolish fortifications, and so can do 6d6 damage to
> >any wreck and any wall.  Most military units can only do 1d6 damage.
> >The engineer, however, can *only* attack wrecks and walls.
> 
> Well, this makes sense (to the AI at least). It does high damage and
> therefore has high offensive worth.

I think that this is the same kind of simplistic reasoning that makes
the AI's performance so bad in games such as future.g.

> >It seems to me that every mobile unit *except* the engineer is able to
> >move to the nearest base or tower and resupply when it needs to.
> 
> So perhaps you should do some more debugging to finds out what these
> engineers are doing instead.

They seem to just continue to search for victims, find themselves unable
to colonize (the debug messages don't clarify the intervening thought
process), and re-plan.  Only problem is that nothing happened after it
re-plans.

I'll keep debugging and see if I can find out anything else.

-- 
Lincoln Peters <peters2000@mindspring.com>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]