DESIGN: AI Improvement discussion

[Solver]

Personalities are indeed already in CtP2, but I agree that we should try to enhance them if possible, to really make their reactions differ more.

As for killing tech trade, I wouldn't agree. One of my favorite parts about Civ is being able to get a nice juicy tech deal. After all, many technologies can realistically be sold, in form of schemes, graphics, etc. Although technologies such as Democracy or Philosophy can hardly be... they're more of concepts than actual things.

[MrBaggins]

Juicy deals are a problem though. Having easy tech trading devalues human research, and focuses the game on economics and military issues.

This leads us to consider making tech trading very difficult. If its difficult enough, to rarely happen, though... why not just scrap it, and include a better mechanism?

[centrifuge]

Kind of along those lines, it is too easy to get a diplomatic victory with CTP2, simply by threatening war against the AI in order to make it sign peace treaties and alliances after the first meeting with them.

This is certainly something for the future, after other bugs have been worked out, but it needs to be addressed in order to make the game play more robust and challenging.

[MrBaggins]

More AI thoughts: Army Definition

An issue with CtP2 AI, is, among other things, a problem dealing with naval invasions, and problems utilizing specific units like missiles, and to a certain degree airpower in general.

Part of the issue is a very flat design in definition of how armies, navies and airwings are constructed.

Units are catagorized in flat catagories. The catagories are hard coded.

Improving army behavior and coordination is important, but also important is flexible definition. Thoughtful, reactive and flexible construction of armies is important.

Army construction is obvious to seasoned CTP2 vets...

For instance, to defend, mix good defensive units, like phalanxes, with ranged units like archers. Movement rate is unimportant for a garrison, although troop types should be evenly distributed across these catagories. You might consider some counter bombard artillery if you know your enemy will field artillery.

With an attacking force you may wish to have strong flanking units, and siege units are a consideration too, but you might, as a human player, chose to build fast (without bombard) and slow (with flanking) stacks, for different purposes.

Adding in special units, and considering settler escort, and so on and so forth add much complexity.

That doesn't begin to address varied naval tasks such as Strike/Bombard groups, Sub hunters, Transport Convoys, and Carrier groups, or air wings.

CtP1 went a long way in introducing flexible and intuitive ways to define how armies get constructed (and CtP2 is a step backwards,) but we have the opportunity to improve on even that system.

The following is an example of how an example army definition might be made.

{garrison_early}
SIZE_MIN    1
SIZE_MIN_REC    2
SIZE_REC     4
SIZE_MAX    4
1:8:UNIT_LEGION
1:6:UNIT_PHALANX
1:4:UNIT_WARRIOR
1:2:UNIT_ARCHER
2:8:UNIT_ARCHER
2:6:UNIT_LEGION
2:4:UNIT_PHALANX
2:2:UNIT_WARRIOR
3:8:UNIT_LEGION
3:6:UNIT_PHALANX
3:4:UNIT_WARRIOR
3:2:UNIT_ARCHER
4:8:UNIT_ARCHER
4:6:UNIT_LEGION
4:4:UNIT_PHALANX
4:2:UNIT_WARRIOR
{end}

The first line describes the identifier of the definition, then the SIZE lines define the absolute minimum and maximum, recommended minimum and optimum size of the unit. The other lines are the actual definition of the units that should be used.

The first number is the "troop number". All the "1's" define the how the first troop should be chosen, then the "2's" the second, and so on, til the max is reached.

The second figure, after the ":" is the priority. A higher number is a higher priority.

Lastly, there is a unit identifier after the next ":".

In the example, an early garrison is defined, with a minimum of 1 and maximum of 4 units specified. 2 is a recommended minimum number of units and 4 is an optimum.

The first unit is preferrably a defensive units, with reducing priority for less capable units. Lastly, if no substitute is available, an archer is specified.

The second unit is reversed, with preferrably a ranged unit, then a defensive unit, in reducing priority.

Thus you can specify both best case and less optimal solutions for army definitions, with limits too.

---

thoughts? comments?

[Gilgamensch]

MrBaggins,

sounds like a nice idea , BUT

1.) What about inland cities? They shall have a lower priority, so the priority itself should be more a variable, which could/would be changeable according to location/needs.
2.) Do we want to include 'automatic' upgrades to never units?
3.) Depending how the enemy, espacially the human attacks, this should be taken into consideration as well. Like archer's don't help a lot against catapults, as they can bombard.

And just a thought, shall we not be able to introduce it as a one-liner, just kind of a table:

Unittype	Warrior	Archer	continue
Warrior
1	2
Archer
1	2

I hope you understand my idea. This we actually could put in a txt file, making it easier to mod...........

[Peter Triggs]

When the AI is tasking it's units, it prepares a big list where it matches it's armies against possible goals. It then does a number of passes through this list, depending on the difficulty level that's been chosen, and executes some of those matches. Here's where this is done:

   cycle++;
   sint32 diff_cycles = 0;
   if (g_theGameSettings->GetDifficulty() == (LEVELS_OF_DIFFICULTY - 1))
	diff_cycles = 2;

       if ( cycle < Scheduler::s_max_match_list_cycles + diff_cycles)
       {
	g_gevManager->AddEvent(GEV_INSERT_Tail, GEV_ProcessMatches,
						  GEA_Player, playerId,
						  GEA_Int, cycle, 
						  GEA_End);
       }

Both LEVELS_OF_DIFFICULTY and s_max_match_list_cycles are set at 6 elsewhere. By increasing the number of passes that the AI makes through its list, we can make it do more things. Azmel2 once remarked that he wished that he'd exposed this possibility. Well, now we've got the chance. Any suggestions?

[Gilgamensch]

Peter,

I would need more information before being able to comment further. I haven't got anything installed of it, so don't know what is reffering to what .....sorry........

[MrBaggins]

Gilgamensch>

The principal I was explaining wasn't the entirety of how the AI constructs its armies. Its the way that an AI designer hints how the types of armies he uses should be constructed.

Another AI file would describe and give different preferences for different "missions" or "tasks" that get created. City garrioning is an obvious and necessary mission. I'd contend that you should be able to conditionally specify different Army defintions to different tasks, based on game state information, such as state of diplomacy, general threat levels, geographic situation, or myriad other issues.

As far as upgrades, I don't think they will drastically effect the system: units can be upgraded, but their essential capability; ranged attack, good defense or so on, shouldn't be destroyed in the process. How the army is initially constructed is important, in my mind, and it would only be improved by upgrades, so the AI wouldn't me crippled by the process.

Peter> Obviously we have to start by playing around with the existing AI.

The exact point you made about the hard coded bidding iterations, was in the back of my mind. Perhaps we should make it an exposed constant. Play testers could muck around with it, and report?

[Colwyn]

Make armies smaller!

You can make the AI 1000% better by making the stacks smaller ie say 6 units max.

This would have a profound impact on the game by reducing the all or nothing scenario with unit locations.

Think of it this way how much harder is it to attack a nation with units spread out along the border compared to defending one location! The AI can never compete with humans when playing with less "stacks".

CTP2 needs combat on fronts not scirmishes where the human can easily outmanouver the AI. For fronts we need spread out units and that means disallowing large stacks so we have 10 armies of 6 units(max) rather than 5 of 12.

[Gilgamensch]

Originally posted by MrBaggins
Gilgamensch>

The principal I was explaining wasn't the entirety of how the AI constructs its armies. Its the way that an AI designer hints how the types of armies he uses should be constructed.

Another AI file would describe and give different preferences for different "missions" or "tasks" that get created. City garrioning is an obvious and necessary mission. I'd contend that you should be able to conditionally specify different Army defintions to different tasks, based on game state information, such as state of diplomacy, general threat levels, geographic situation, or myriad other issues.

As far as upgrades, I don't think they will drastically effect the system: units can be upgraded, but their essential capability; ranged attack, good defense or so on, shouldn't be destroyed in the process. How the army is initially constructed is important, in my mind, and it would only be improved by upgrades, so the AI wouldn't me crippled by the process.

MrBaggins,

don't disagree with it. My idea was mainly like yours, but slightly changed.

Instead of being hardcoded, I was thinking of using a txt-file with the stack infomormation in it. This would offer (for me) 2 advantages: 1.) You could change it easily later (like for mod's scenarios) 2.) it would be far more flexible.

And all what I suggested, was to put it in this txt-file, in kind of a table, comma-telimited. that was all. So the computer could read it, which units to stack and which ones not. I was a bit lazy to complete the table..........

So it should like this in the txt-file:

UNIT_WARRIOR,1,2,3,4,0,0,(continue as needed for all units),12,1,6,6,X,X,......(max in stack)
UNIT_HOPLITE,1,2,3,3,0,0,0,0,0 (........),12,12,6,6,X,X,.....(....)

This would mean:

for WARRIOR:

Take Warrior (1) if nothing else available or existing.
Take Hoplite (2) if available or existing.
Take Archer (3) if available or existing.
Take Catapult (4) if available or existing.
If the value is 0, this would mean, don't use it together with this unit. This might also be a good way to 'teach' the AI, what to stack and what not to stack..........

The numbers would also specify the base priority of what to use.
The numbers behind the first bracket, would indicate the maximum number to be used against the unit.

So 12 Warrior maximum if only Warrior available.
Maximum of 6 Warriors together with Hoplite.
Again maximum of 6 Warriors together with Archer and so on......

But as the first part would describe the priority to build for stacking, we shall never really have anymore Warriors after Hoplite......

For production-queues:

We might be able to use this information as well. Check the stacks, what is missing and choose according to the priority.

let me know what you think (I hope I did it clear enough )

[MrBaggins]

You should note, Gilgamensh, that ANY change I'm considering, if it isn't process, but is data, or condition, will be in a human readable, and modifiable text file. This is the only way to ensure the ultimate modifiability of the AI engine. Important since there will be play testing plus changing needed to get a new system to work optimally.

[Gilgamensch]

OK, also what I head in mind

But how you think about this suggestion?
I shall be doable, but I think we have to 'throw' out the old system for it........

[MrBaggins]

There are some limitations to the system as is. Not least being its largely hard coded nature. I'd really don't see any technical reason why it can't be something better, ultimately.

Having said that, its a long term project, and I'd be happy with just tweaking the existing AI that we have to start with.

[child of Thor]

with reference to tweaking the current AI, has anyone looked at/tried this kind of thing.

We know the problem with the city caps - the player can ignore them if he/she wants too(using improvements,workers etc the penalties can be more or less negated), but the AI seems to stick close to the defined boundary.

The Mods have added various penalties for the player going over the city cap, but still over time the balance seems to go against the AI nations.

Is it possible to either make the AI ignore the cap or maybe better would be a larger cap, either set or dependant on how the player is doing? Finding the balance would be key - ICS for the AI hopefuly isn't the answer, but a way to unshackle the AI might improve the mid to long term game for the player?

What about making a settler unit more expensive(like much more expensive) as the player reached his/her current city cap?

Not very subtle i know, but could be comparitvely easy to impliment? just wondering if this had already been attempted/looked at during the previous mods?

Enjoying this discussion(even the stuff going over my head ), and as this may be the new CTP2's main feature(AI improvement), i hope it continues with some good implimentations

[MrBaggins]

Well.. until I have a viable compilable source, I can only theorize, but I haven't forgotten any of the prior discussion on AI.

The AI needs to deal better with happiness on a more city level than it is. Those entertainers are life savers. It needs to do that, AND optimize the balance of happiness/production at the empire level.