Preventing multiple AI leaders spreading recruitment evenly
Moderator: Forum Moderators
Forum rules
- Please use [code] BBCode tags in your posts for embedding WML snippets.
- To keep your code readable so that others can easily help you, make sure to indent it following our conventions.
Preventing multiple AI leaders spreading recruitment evenly
Hello all,
I've noticed that if an AI player has multiple leaders situated on different keeps, it distributes its recruitment evenly among them, rather than focusing recruitment closer to the front line.
I can't do the obvious thing of setting the different leaders to be on different AI sides, as this is a control-points style scenario with 0-moves leader units on keeps that, upon death, are replaced by one belonging to their killer. As such, a single side will invariably come to own multiple leaders on multiple keeps. This is fine for player-owned sides, but the way the AI always spreads its recruits around the map puts it at a strategic disadvantage.
I know this is a rather vague thing to ask, but does anyone know of a way to induce more focused AI recruitment in this situation? In an ideal world, I could set a priority level for recruiting from different keeps, but I suspect I'll need a cruder workaround.
I've noticed that if an AI player has multiple leaders situated on different keeps, it distributes its recruitment evenly among them, rather than focusing recruitment closer to the front line.
I can't do the obvious thing of setting the different leaders to be on different AI sides, as this is a control-points style scenario with 0-moves leader units on keeps that, upon death, are replaced by one belonging to their killer. As such, a single side will invariably come to own multiple leaders on multiple keeps. This is fine for player-owned sides, but the way the AI always spreads its recruits around the map puts it at a strategic disadvantage.
I know this is a rather vague thing to ask, but does anyone know of a way to induce more focused AI recruitment in this situation? In an ideal world, I could set a priority level for recruiting from different keeps, but I suspect I'll need a cruder workaround.
Re: Preventing multiple AI leaders spreading recruitment eve
Depending on exactly how you want this to work, there might be a variety of ways to accomplish this:
- If you know up front which leader should recruit preferentially, you should be able to use the
leader_id=
andimportance=
keys of the recruitment_instructions aspect of the [ai] tag. However, it sounds like that might not always be the case, so one of the following methods might work better. - You could put some WML code into the side turn event of all AI sides that calculates in which order the leaders should recruit and (re)set the recruitment_instructions aspect accordingly.
- You could set up an event which calculates which leader should recruit next and disallow recruiting for all other leaders of that side. This event would need to be called at the beginning of the side's turn and after each recruitment (and depending on how it is implemented, possibly also after each unit's move, in case castle hexes become available).
- Depending on how complex you want the calculations to be, I would probably do the former two options in Lua rather than WML.
- You could write a custom candidate action (CA) to replace the default recruitment CA. That's probably the most complex approach, but it would also provide the most options and flexibility.
SP campaigns: Galuldur's First Journey (1.12 & 1.14) & Grnk the Mighty (1.10 & 1.12)
AI experiments: Micro AIs (wiki, forum thread, known/fixed bugs), Fred, AI-demos add-on
AI experiments: Micro AIs (wiki, forum thread, known/fixed bugs), Fred, AI-demos add-on
Re: Preventing multiple AI leaders spreading recruitment eve
I've never dealt with Lua or custom CA's unfortunately, but the middle suggestions give me an idea. It occurs to me that trying to force or disable recruitment in certain spots would actually leave the "disabled" control points woefully open to being attacked and captured. I had never quite realised that until I saw it written down.
I might be better off arranging the control points into 'lanes', to use a familiar term, with a different AI side at the end of each. Whenever a point is captured, it would 'lock off' the previous point on its owner's side, replacing the ring of castles around the keep with impassable terrain and effectively placing it in stasis. It would force me to create more complicated 'die' events though. They would have to take into account exactly which point has been captured by which side to make sure the process went both ways and allowed for unlocking as well as locking. It would literally force the AI to recruit near the front though, and would probably help focus gameplay.
I think I'll roll with that for now. Thanks for the input, it's surprising how just having another input on the subject can give you fresh ideas.
I might be better off arranging the control points into 'lanes', to use a familiar term, with a different AI side at the end of each. Whenever a point is captured, it would 'lock off' the previous point on its owner's side, replacing the ring of castles around the keep with impassable terrain and effectively placing it in stasis. It would force me to create more complicated 'die' events though. They would have to take into account exactly which point has been captured by which side to make sure the process went both ways and allowed for unlocking as well as locking. It would literally force the AI to recruit near the front though, and would probably help focus gameplay.
I think I'll roll with that for now. Thanks for the input, it's surprising how just having another input on the subject can give you fresh ideas.
Re: Preventing multiple AI leaders spreading recruitment eve
Good to hear that my input was useful. If, in the end, it turns out that you want a custom CA after all, let me know. I can probably help with that.
SP campaigns: Galuldur's First Journey (1.12 & 1.14) & Grnk the Mighty (1.10 & 1.12)
AI experiments: Micro AIs (wiki, forum thread, known/fixed bugs), Fred, AI-demos add-on
AI experiments: Micro AIs (wiki, forum thread, known/fixed bugs), Fred, AI-demos add-on