new AI_SPECIAL possibility

[turin]

Currently, ai_special= can only be set to guardian, which has behavior such that it stays in one place unless there is an enemy in its movement radius, in which case it goes to attack it.

There are often many other things you want to do with a unit.


What would be the feasibility/desireablility of implementing ai_special=:

* Sentinel. It never moves, but will attack units that move next to it.
* Static. It never moves, period, and never attacks, period.
* Roving. If there is a unit in its movement radius, it attacks them. Otherwise, it moves randomly to one of the spaces along the edge of its movement radius.

I could use all of these in various campaigns...

[turin]

* Patrol. Would set the unit to patrol between two or more locations. Would use it like this:

Code: Select all

[unit]
UNIT-STATS
ai_special=patrol
      [patrol]
      x=1,10,5
      y=1,1,7
      [/patrol]
[/unit]

This would make the unit go to 1,1 (if it did not start out there), then go to 10,1, then go to 5,7, then go to 1,1... basically, it would be like giving the unit a goto_x and goto_y that changed to the next in a loop every time it got to the location.


[edit]
I've thought of a better way some of my ideas above could be implemented. The unit could have both ai_special= and agressive= (aggressive has default "1", meaning it attacks like the normal AI attacks. "0" would mean it attacks when there are enemies next to it. "-1" means it never attacks.). You would implement "sentinel" by ai_special=guardian and agressive=0. You could also do "static" by ai_special=guardian, agressive=-1. This would also give you the possibility to have roving, non-agressive units (ai_special=roving, agressive=0 or -1), which would be useful for the neutral animals people have often suggested.

[scott]

Right now, it's easiest to just keep ai specials to one-word parameterless descriptions.

unit.cpp has "guardian_" as a hard-coded attribute of units. It's either true or false. You would either need to add another attribute for each ai you wanted to add or else change "guardian_" to something generic. I'm sure they had their reasons for doing this way, but it makes it hard to extend.

ai_move.cpp checks the value of guardian_ and if it's true, returns a destination that's the same as what it is now.

I think a wanderer would be the next easiest to implement since you can duplicate the guardian stuff but instead have it pick a random location on the map as its goal for that turn. Attacking could be set the same as for the guardian.

Guardian doesn't appear to be considered at all in the ai_attack.cpp file, so wanderer would be easier than sentinel. But, sentinel could be handled the same as guardian for movement and new code could be written to handle the sentinel in ai_attack.cpp. Too bad I don't know how to write code

Edit: static would be about as easy as sentinel, once one figured out what to put in ai_attack.cpp to govern when a unit attacks.

Edit 2: Some more thoughts from the top.

: yes you'd have to add a new bool for each 'special' you want to add.
: or else make it an enum instead. Like enum AI_SPECIAL { AI_NONE, AI_GUARDIAN, AI_CRAZY_BERSERKER, etc };
: and then remove guardian_ in favor of a ai_special_ vvariable.
: if the behaviors are mutually exclusive (i.e. something can only be a guardian OR a sentinel, not both), then I would say making it an enum as above would be better.

: I think that for user-made AIs etc we should attach a config object to each unit which contains special instructions for the AI
: for a very general approach, I suggest deprecating ai_special....
: and then making an optional section in [unit] called [ai]

: then inside [ai] all sorts of parameters can be specified
: and this is loaded into a variable, config ai_behavior_; that is found in unit.
: and then the AI can look at the config to see the behavior...
: [ai] could contain special=blah blah, and it could also contain child elements and so forth.
: this approach would be much *less* efficient, but the most general. If it turns out to be too inefficient, we can do things to make it more efficient.

[turin]

I see. Well, that's rather unfortunate. Still, I think it is worth the trouble to code at least the simpler ones, like roving. I don't program, of course, so I might be way off the mark about how hard it would be, but from your explanation it looks like it should be pretty easy to copy what was done for guardian and do it for roving.


Roving isn't the most useful one on that list, though. That would be sentinel. Having actually immobile units would be really good. Although there might be a WML hack to do sentinel and standing, I don't know what it is.


With sentinel, wouldn't it work to not change at all how moving and attacking for the unit is processed, but just make the AI think the unit has 0 moves? IIRC, this is already possible; there is a key, called something like idle_leader=yes, which makes the leader of a side always stay on the keep...


PS: Where is that quote from? IRC? And by whom?

[scott]

It's Dave from IRC describing ways to add to the list of ai_specials. I might try modifying guardian so that it gives wanderer behavior, but that might be beyond the limit of my skills. Between the 2 of us... we're pathetic.

[zookeeper]

BTW, the wandering AI behaviour would now be very easy to write in 1.1.1 WML.

[turin]

BTW, the wandering AI behaviour would now be very easy to write in 1.1.1 WML.

Really? How so?


I've done something similar in the scenario The Drowned Plains. Invisible Philosopher wrote the code probably about a year ago. But it is really ugly, and you have to have the unit on its own side...

[zookeeper]

BTW, the wandering AI behaviour would now be very easy to write in 1.1.1 WML.

Really? How so?


I've done something similar in the scenario The Drowned Plains. Invisible Philosopher wrote the code probably about a year ago. But it is really ugly, and you have to have the unit on its own side...

There was a fix recently which makes AI units always move according to their goto_x,goto_y unit variables, if you set them. Previously, manually setting goto_x,goto_y would only work on human controlled sides, but now you can use them to control exactly where an AI unit will move, too. I think this will be a very helpful fix for making AI units move exactly where you want them to at exactly the right time, which wasn't very possible before. And of course, helpful in doing a wandering AI, since you only need one event where you set those variables to random values.

EDIT: Apparently there was a bug in the implementation of this in 1.1.1. It's supposed to really work in SVN now.