On AI and its peculiarities

[Manric]

Playing against the AI, or simply watching it play as observer, we not only learn a lot of its inner workings, but also discover curious facts, like the examples that follow.

MEMORY LOSS. The AI has not much difficulty in finding enemy bases shortly after the start of a game. It sends explorers in two or three directions which, if not intercepted, get there all right. After they are duly killed, the AI sends a few more fighting units to the same spot, and keeps doing so all the time if the enemy does not move. But, if the enemy sends out a group of warriors and there is a battle somewhere in midfield, the AI forgets the location of the enemy base, and it may take it a lot of time and effort to find it again. For a human mind this loss of memory is puzzling (although easily understandable by those with some programming knowledge). However, it should not be difficult to provide the AI with the ability to remember key points on the map once they have been first discovered. 

THE RAT TRAP. Suppose a map where a natural barrier (trees or mountain) forms a cul-de-sac. If the CPU army is lured into it in such a way that their units and the enemy's are on sight but divided by the barrier, it can be kept there indefinitely. The AI is not clever enough to go back and find the correct path to the enemy, but keeps instead its whole army moving to and fro against the barrier to no avail. Experimenting with such a setup I have been able to wipe out enormous CPU armies with a few long-range weapons, with very little harm to my own faction.

THE WHEEL OF DOOM. A powerful CPU army has found an enemy base and attacks it with all its might. In a short time, all enemy buildings and units are destroyed. What now? The usual procedure for the army is to get back or scatter away randomly, but, in some cases—-fortunately infrequent-- the AI exhibits this curious behaviour: all units seem to want to get to the centre spot of the former enemy base; they collide with one another, they move frantically up and down, left and right, never at rest, always in a perpetual motion, forming a sort of alive ball-like monster, oblivious of the fact that there may still be other enemies on the map. This is what I have come to name “The wheel of Doom”. If attacked, they repel the attack killing all foes, but get back immediately to the wheel. Any new unit produced by the CPU base hurries also to the wheel, which keeps growing and growing. I have watched one of those monsters for over one hour, never deviating from this behaviour, until its sheer size was too much for my equipment and the game froze. Now, two questions arise: Why does the AI behave like that? And, why does it happen only from time to time? (My guess would be about one in ten).

[Omega]

in some cases—-fortunately infrequent-- the AI exhibits this curious behaviour: all units seem to want to get to the centre spot of the former enemy base; they collide with one another, they move frantically up and down, left and right, never at rest, always in a perpetual motion, forming a sort of alive ball-like monster, oblivious of the fact that there may still be other enemies on the map. This is what I have come to name “The wheel of Doom”. If attacked, they repel the attack killing all foes, but get back immediately to the wheel.

Interesting. I noticed a similar behavior once, but it had a definite cause: a size zero unit was still "alive" in the base (an example of a practical size zero unit is the energy produced by the energy source in the dark magic faction). A size zero unit cannot be attacked, yet the AI still knew it was there, so hoarded around the location of the unit, unable to attack it, but unwilling to leave. However, I am under the impression that the size zero issue was fixed ages ago, and not sure if it could be related to what you're seeing (although the behavior you describe is exactly the same as the size zero issue had). Can anyone confirm that this was fixed in MegaGlest? I couldn't find anything from a quick forum search.

[Manric]

Quite right. A very good hint: this behaviour is indeed caused by some amount of a resource left behind after all buildings are destroyed. I have now been able to reproduce it at will. The resource must be one that is produced directly by a command from a unit. For example, if we get food not by producing a cow, but by ordering a farm to produce food. Some factions also produce oil or other exotic resources in this way. Thus, the resource has to be defined in the faction as a unit, and, yes, it has size zero. And, as a resource, it would disappear with the building that stores it, but, as a unit, it can survive after all buildings are destroyed. And the winning side goes quite mad! 

[tomreyn]

My understanding is that there should never be any structures or units of size zero. And that creating such is considered a modding error.

Edit: Actually you can have size 0 units but those have to use allowEmpty=true. Nothing a forum search couldn't find.

[Manric]

[allowEmpty] does not solve this particular problem. I suppose it is because in a zero-size unit [cellmap] is false, and any following attribute is ignored.

In any case, this little discussion will be of some use to future modders: now they know that zero-size units should be avoided.

[Omega]

In any case, this little discussion will be of some use to future modders: now they know that zero-size units should be avoided.

That's really not a solution. Several game elements depend on the usage of size zero units. For example, if you want to have an energy source "produce" energy, it would have to make a size zero unit, as MegaGlest does not have a command to generate a resource by itself. As a result, you'd have to build a million energy sources, versus building one or two and producing energy from them. As well, size zero units have uses in scenarios, where they can be used to mark a location on a map (give them a sight to mark a location on the minimap, or even add a model, such as a flag, to show a location). So there really needs to be some working method of ensuring that size zero units don't muck up the AI. If you ask me, we should just skip the whole "allowEmpty=true" bit and have the AI always ignore size zero units, for compatibility (as factions such as Dark Magic would be broken otherwise).

But are you sure that allowEmpty isn't working, and that you're not just using an older version of MegaGlest? I don't think allowEmpty is in the last stable release.

[Manric]

But are you sure that allowEmpty isn't working, and that you're not just using an older version of MegaGlest? I don't think allowEmpty is in the last stable release.

I do not quite know if my MG version is the latest: it is Windows 3603 revision 3080. In any case, allowEmpty is here safe and sound, and works nicely in the case of a resource produced directly by a building, provided we have some cellmap:

      <size value="1" />
      <height value="0" />

      <cellmap value="true" allowEmpty="true" >
         <row value="0" />
      </cellmap>

(The unit <animation> is pointed to an empty model).

If such units are produced during the game, some amount will probably linger behind after all buildings are destroyed, but it will be ignored by the AI, and the game may end happily. 

[tomreyn]

You're using the latest stable release. I'd recommend that, as a modder, you always test against the MegaGlest release you will make your mod available for (and declare it to be compatible to) as well as the latest development snapshot. That's to prevent situations where your mod stops working, or works differently than expected/intended, after a new MG release.

For those who find it too complex to build MG themselves, there are now, thanks to Treba, nightly snapshots for Windows (Linux users are often knowledgable enough to know how to compile software, and it's easier to script it, there, too, and OS X users are, as usually, and for a reason or two, on their own).
 

[Manric]

Thanks for your advice. I only want to clarify that I am not a modder, and do not pretend to become one. All I have done is experiment with the game using other people's mods and occasionally post my experiences to share them with the community.

And, as a conclusion for this annoying zero-size subject, I think we can safely agree in that there is no need to have units with size zero. A fake size-something unit like the one described above will do the trick.

[Omega]

And, as a conclusion for this annoying zero-size subject, I think we can safely agree in that there is no need to have units with size zero. A fake size-something unit like the one described above will do the trick.

You don't understand, a unit with a completely empty cellmap isn't any different from a size zero unit. They're treated the same in game, just with a messier XML, to make it a little harder for the reader to see how the unit works. AllowEmpty should work fine with an empty cellmap tag (eg, no <row> children). I still think the effects of "allowEmpty" should be applied to all size zero units, however. It would not break any existing mods, to my knowledge.

[Manric]

Yessir, you are right. The game engine gives no error if we have size zero and cellmap true. I thought it would, but it doesn't. Surprisingly, it even allows defining rows. So, it is irrelevant whether this fake unit is size zero or size something. The crucial part is the command: 
      <cellmap value="true" allowEmpty="true" />

BUT if we try this:
      <cellmap value="false" allowEmpty="true" />
then the ominous Wheel of Doom comes back.

[titi]

softcoder needs to comment on this, but it will take some time because he is "offline" at the moment.