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: CRT Combat Model (really long)


>I guess the problem just gets a lot worse when the AI is dealing with
>mazes.  I'm not familiar with the algorithms that move units from one
>place, so I'll have to leave all that in your hands.

I think what would really help in your game is if each side starts with 3-5
units instead of a single human. Now the single human gets lost in the maze
half the time, and then goes into passive mode.

>Wouldn't an item that can be carried (e.g. a Guardian stone) be
>comparable to a facility in a city (e.g city walls)?  If they are
>comparable, it seems to me that the only necessary changes to the AI
>code would be to allow units to pick up "facilities" instead of build
>them.

You are right, and unfortunately, facilities are not supported in the ai
either. By this I mean the city will pick one at random to build, with no
regard for what is useful or neeeded.

>> This is strange. The garrison units work fine in e.g. the advances game.
>> You have to set ai-tactical-range greater than zero for them to attack
>> units outside the city, but it is 4 by default so this should not be the
>> problem. Maybe you should check out the code in advances.g and model your
>> garrisons on it.
>
>Perhaps the problem is that vision is line-of-sight and rooms are small,
>so it becomes much easier to launch a surprise attack.  Once I have
>units in place to attack an enemy place, there is rarely any path that I
>haven't cut off.

Looking at you game again, I noticed that the orc-holes etc. can fight. So
you really don't need garrisons. They are intended for Civ-type games where
cities are defenseless without a defender inside.

>Another thing that I should be able to do is tell the AI that a human
>should not be used as part of a garrison.  Perhaps there should be some
>way to weigh units as favorable or unfavorable for garrisons?

Just give the unit type a high defend value and a low attack value. Also a
low speed. The ai is smart enough to figure that one out.

>Perhaps the real issue is that when it is possible to colonize and/or
>improve, the AI never anticipates military trouble until it is too late.

Yeah. Just like its human counterparts :-).

>I guess the coordination isn't as much a problem in most games as in
>this one because not only do you have mazes instead of fractal terrain,
>you have passages that only allow one of anything to pass at a time.
>Also, most rooms aren't big enough to seriously fight in.  Maybe I
>should try allowing two of anything to pass at a time instead.

That's a good idea for other reasons too. I noticed some lockups where
units got trapped behind other units.

>I can re-configure Lightning stones so that they can't attack directly,
>but I don't know if I would want to do the same with dragons and/or
>beholders.  Sometimes, I want a dragon or beholder to be able to
>directly attack a place in order to capture (and defeat any garrison
>that might be there), but it would be unable to do so if it couldn't
>attack directly (at least it couldn't do so very well).

You can allow both direct capture and fire, but still disable direct
attack. The latter only disables indirect capture as a result of an overrun
action.

>When it comes to editing cell terrain, I really don't have a clue where
>one would start.  I suppose that in an "advances"-like game, a player
>who could alter cell terrain might want to turn desert into plains,
>thereby making it more useful for advanced units.  Then again, there
>doesn't appear to be any game yet where something like this is both
>possible and beneficial (in WW2 games, of course, it's possible to alter
>terrain with nuclear bombs).

It is possible to set up units in any game that can change the terrain. At
least in those games where production is dependent on terrain type, this
can make a huge difference.

>9. Sometimes, when a game is over, I find that the AI had some dwarves
>that started building a few places (strangely enough, all orc holes),
>but many were abandoned and left incomplete.  I could understand this
>happening if I had shown up, because the dwarves would re-plan to fight
>my forces, but my nearest units were all at least 10 cells away (and
>probably unseen by the AI's forces)!  Why would the AI leave those
>incomplete units lying around when there's no threat in the vicinity?

This is a known bug. I fixed it at one point in the advanced unit build
code, by writing a special resume_build_task function. However, the fix was
lost later when this code was merged with the general build code.

>10. Sometimes, a place will be assigned to hit or capture some enemy
>unit.  That makes no sense; the places are capable of fighting, but
>they're immobile, and they're much better at producing monsters that can
>hit or capture enemy units for them.  Why would any place try to do
>that?

Because you allow them to fight! This is not how places work in most games.
Check out advances.g or 3rd-age.g.

Hans




Hans Ronne

hronne@pp.sbbs.se



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