AI : Army Movement

[Maquiladora]

I like the frenzy levels in AoM, but the war trigger when a human "gets on top" isnt as fun IMO. I know that in most mods human catch up is slowed by crippling the human with constant war, and the AI getting lots of resource bonuses to compensate for its badly managed cities.

Eventually though the human catches up, the city rings keep growing and the AI cities continue to overlap and its resources stop increasing, or the human simply has more cities at this point, and then the AI bonuses cant compensate anymore.

Better AI settling and terrain development would help the AI most to compete (grow) longer, then AI building choices, and then advance choices.

AI civs ganging up on the human is fine too, but each AI and personality should do it in a realistic way. Like ganging up every AI from all corners of the planet to attack the human, because hes in the lead, it feels artificial and unfun IMO.

I also like the idea of merging weaker civs idea, perhaps when the land has been taken up, basically when it becomes hopeless for two smaller civs close to each other to compete globally, they may aswell become one.

[Ekmek]

Originally posted by Fromafar
AI takes 30-40 minutes to do its turn in my game. Everything was normal initially, but then pollution levels have risen and there was a global flood. After that, the AI started to take ages to think.

This is one of the major problems that are left in the game. Whenever the AI has to use transports to reach a goal, the goal matching process takes an enormous amount of time.

Fromafar

If I understand this right the problem is that AI has to think each turn and its not storing ideal spots to reach a goal.

Would a way to solve this be if we have the game store all the continents at start up and also store a coastal city when its built. Then we have an array that the AI can cycle through if it determines if its a good time to do a sea invasion? so when the AI sets targets it goes to a few predetermined spots? If we build such a list of spots I think it should be somewhat large (10 to 15) so the human cant fortify all the possible landing points.

[BureauBert]

Turn Lags

I don't have an idea on how to optimize the cross-water scheduling process. I just want to take the opportunity to draw your attention to some old "turn lag"-reports (#1 - last issue in this report, #2 - similar experience with later build, #3 - possible improvement with rev630 build) from my part. I am not sure if they are related in any way though. From several playtest reports and discussions in the past I got the impression that changes in the source code affecting unit pathing in any way tend to cause that kind of trouble.

[Martin Gühmann]

Originally posted by E
If I understand this right the problem is that AI has to think each turn and its not storing ideal spots to reach a goal.

That isn't the problem E, once a goal is set and the units are assigned, the AI executes it by just moving the units. Well the goal is reconsidered, but that's it.

Originally posted by E
Would a way to solve this be if we have the game store all the continents at start up and also store a coastal city when its built. Then we have an array that the AI can cycle through if it determines if its a good time to do a sea invasion? so when the AI sets targets it goes to a few predetermined spots? If we build such a list of spots I think it should be somewhat large (10 to 15) so the human cant fortify all the possible landing points.

The continent stuff is in, the game knows that a target location is on another continent. And you don't need to put the coastal cities into an array, the cities are already in an array with all the other cities, and I doubt that it is a huge slow down to get the coastal cities out of it every turn. Anyway I wouldn't use the coastal cities as landing spot for an invasion, because those cities should be more fortified than those regions without cities.

But indeed all the boats should land at the same time.

But the problem is that this is a huge task.

Now back to the problem, the slow AI turns. The problem here is that there is a lot of code you have to understad in order to make the fix. Therefore I have no idea how much code has to be changed. Whether it is just a problem in one line of the code or a huge part.

One reasion why it could be so slow is that the AI trys to find a suitable boat and fails and trys a lot of times again. Espeacilly if you do it for several units again. Maybe we need here a list of transporters, telling us which transport to use. But for now everything is speculation. Unless someone trys to understand the code.

-Martin

[Ekmek]

when I compile I get this warning:

ctp2_code\robot\pathing\CityAstar.cpp(195) : warning C4800: 'int' : forcing value to bool 'true' or 'false' (performance warning)

bool CityAstar::FindRoadPath
(
	MapPoint const &    start,
	MapPoint const &    dest,
	PLAYER_INDEX        owner,
	Path &              new_path,
	float &             total_cost
)
{
	m_alliance_mask     = 0x0;
	m_pathRoad          = true;
	m_owner             = owner;

	total_cost          = 0.0;

	sint32  nodes_opened    = 0;

	return FindPath(start, dest, new_path, total_cost, false, NODE_VISIT_COUNT_LIMIT, nodes_opened);
}

Could this be contributing our long turn problem?

[Fromafar]

Hardly. But if you want to be sure: change false to FALSE (or better, the type of the parameter in FindPath from BOOL to bool) to make the warning go away, and try again.

Like Martin said, the main problem isn't the pathing. It is just that the situation requires some extra levels of logistics.

When you have a target at the same landmass, you can just order your armies to go there. When the target is not at the same landmass, you have to order both the armies and some transports to go to a embarkment point, load the armies into the transports, and cross the water, before your armies are able to reach the target.

How many transports do you need to reach the target?
How many transports do you actually have? Do you need more?
Do you have other (more important?) targets that require transports?
Can you get the armies and sufficient transports roughly at the same time at the rally point?
Are just some of the issues the AI would have to compute.

[Martin Gühmann]

Originally posted by E
Could this be contributing our long turn problem?

Not at all E, if it was such simple I would have already done it.

Probably a bool instead of a BOOL may be a little bit faster - if at all since it is smaller. However using a bool is standard c++ since it is a builtin type and BOOL is just a typedef of an int. And the other advantage is that it is type secure. In comparision to bool you can abuse BOOL as a normal integer which is also done in the code. So an automatic replacement of BOOL against bool is not practically.

Back to the transports, even using BOOL instead of bool in the algorithm from the performance there shouldnt be a big difference. The problem is the algorithm used for finding transports. Maybe it is something like this:

for each unit that needs transport do
    for each unit available do
        if unit is transport do
            use it as transport
            break
        end
    end
end

Now lets asume we have a lot of units which need transport. And that we have lot of units, but no transports.

The algorithm above waste a lot of time, well it checks every unit whether it is a transport so far everything is ok, but then it does it for every unit that needs tranport. The algorithm does it again and again although it is clear that the result does not change from iteration to iteration. So you could do the transport check just once per turn and store the found transports somewhere.

In fact the algorithm above has a quadratic worst case running time that is worse than linear.

Here would be a better solution:

for each unit available do
    if unit is transport do
         store in transport array
    end
end

for each unit that needs transport do
    if transport available use it
end

And probably the problem is more complex, at least I hope the programers did not do such an approach. But of course such a structure could also be hidden in the code.

However the consequence of the quadratic algorithm is if you increase the number of units by two the algorithm needs for times longer to compute the output. If you tripple the input the compuation time gets 9 times longer, for an n four times bigger than the original one it becomes 16 times longer. You see the time for compution needed grows quadraticly. In the other function computation time doubles if you double the input length and tripples if you tripple the input lenght and so on. You see a linear algorithm is much nicer than a quadratic algorithm.

-Martin

[Ekmek]

good stuff Martin, I'll probably have to reread it a few time

If we create an array for transportunits once the unit is built and remove it if killed would that help the process at all.

that may just leave the long calculation part to calculating transport capacity which I guess would be long if done each turn. Unless we create a total player transport capacity value array once a unit is built and subtract from that value everytime a unit loads or unloads. The only problem there is assigning transports because each unit has a limited value.

[Martin Gühmann]

Originally posted by E
If we create an array for transportunits once the unit is built and remove it if killed would that help the process at all.

Actually so far everything is speculation, so what helps most at first is to understand what is really going on inside that black box.

And by the way unfortunately this doesn't frees you from rereading my last post again, especially since you seem to prefer quadratic algorithms even linear ones can be used easily.

-Martin

[chadhogg]

Actually so far everything is speculation, so what helps most at first is to understand what is really going on inside that black box.

Has anyone tried running the code through a profiler? I've never attempted such a thing with a GUI-based application, but it might give you a very good idea of where exactly the bottleneck in the code is, if not how to eliminate it.

[J Bytheway]

Originally posted by chadhogg
Has anyone tried running the code through a profiler? I've never attempted such a thing with a GUI-based application, but it might give you a very good idea of where exactly the bottleneck in the code is, if not how to eliminate it.

Under Linux at least I'd know how to do that, but the Linux version is so far behind the Windows one it probably wouldn't be informative.

[Ekmek]

I did a bit of playtesting and granted it was for my Cal2Civ mod, but the issue probably affects the main game too.

Basically, I noticed that the barbarians will camp outside a city and not attack the city. Is this related to personalities.txt?

PERSONALITY_KAHN {
  DefaultStrategy STRATEGY_MILITARIST_DEFAULT

  FullAttackStrategy       {  Strategy STRATEGY_ATTACK            Priority 250  }
  BuildupStrengthStrategy  {  Strategy STRATEGY_DEFEND            Priority 75   }
  SeigeCitiesStrategy      {  Strategy STRATEGY_SEIGE             Priority 200  }

[Martin Gühmann]

Originally posted by E
Basically, I noticed that the barbarians will camp outside a city and not attack the city. Is this related to personalities.txt?

No, it isn't. Did you use the debug AI army text to figure out which goal the AI units were asigned?

-Martin

[Ekmek]

Now that you provided a button I'll do that

[Martin Gühmann]

Originally posted by E
Now that you provided a button I'll do that

I didn't provide a button I just added the text to the army manager window. But you can switch on it by using the chat window. The command is somewhere in the source code. You should be able to find it. The only thing after activation you have to do is to play a turn, since it doesn't update the army texts automaticly.

By the way if you want a button than it belongs onto the cheat editor, since it is a cheat.

-Martin