alx-9

Here's another guy interested in the AI discussion I spent a few weeks looking through the qBot code as I'm looking to gain some more experience in this area of game development. In fact I hadn't read this thread before making a comment on the qBot thread a few minutes ago. There I also raised the issue of the AI cheating quite a fair bit, and whether this is really desirable. For example, the current AI doesn't have to do any scouting whatsoever as it basically sees the entire game world. For RTS games (or competitive games in general), I personally think thats just wrong. Another example: attacks are only initialized once qBot considers its attack force is 1.5 times stronger than the enemy's entire population. (with the exception that if the attack group becomes too large, it will send it regardless of the enemy strength). So here qBot is lowering the risk of failure and choosing to fight an unbalanced battle.

Hey quantumstate, my friend and I have been busy with other stuff, including holiday, but we wanted to thank you for the reply. Regarding the siege weapons, I think once qBot has a fortress (ie is able to produce siege weapons) it would make sense that a large portion of the attack group it deploys consists of siege weapons. Maybe even evaluate the opponent's forces, like a balance between his soldiers and defence towers/fortresses. If he has more of the latter, then focus on training more siege weapons. If his defence consists of primarily units, then obviously less siege weapons are needed. Female citizens could continue working in the presence of enemies, but I'd reckon it would be more realistic if they started fleeing as soon as the enemy attacks one of the nearby female citizens. At that point its clear the enemy is going to attack them so fleeing would be reasonable behaviour. Defensive coordination would be neat. But there might be situations where you'd rather not walk as a group to defend. For example, if the group has some mounted units, would you really want them to move at the speed of of the slowest unit in the group? We hadn't thought of the effects of focus fire, although if the ranged units go after the 'strongest' enemy I guess focus fire happens automatically. My friend and I still think patrolling behaviour would be great to have in 0 A.D. Although there is a slight problem, in that qBot 'cheats' a fair bit by using information it shouldn't have (from the perspective of a human player). If qBot can see where enemies are at any given moment, then patrolling wouldn't be the best defensive strategy - instead the AI could position all of its defensive units on the route the enemy. I'm not saying cheating is bad, as it does make it significantly easier to implement stronger AI, but I'm interested what your view is on this. Do you think in the final release of the game it would be better to have an intelligent but fair AI? Or would the 0 A.D. community not really care how the AI works as long as it provides a challenge?

Hi, a friend and I have been looking around the qBot code and making some small adjustments / trying out stuff. We've made a list of some ideas you may want to consider. Our input is based on your code from about a month ago, so perhaps you may have changed a thing or two. We invite you (and anyone else reading this) to let us know what you think of the ideas. Siege weapons: when creating an army to be sent to the opponent Civ Center, there should be more siege weapons. It would make it more challenging to defend against qBot's attacks. Right now its fairly easy to garrison inside buildings and kill off the enemy soldiers whilst they take an eternity to destroy a fortress/civ center. Garrison: related to the above, it would be great if qBot sent units into towers/fortresses/Civ Centers when under attack. That would increase their resistence to the player's attack. However, if there are siege weapons assaulting the buildings, then the garrisoned units should scramble out and destroy the siege weapons. Female evasion: female citizens should run away from enemy soldiers. Basically the sort of behaviour currently observed by some animals - I believe the deer run away from all human units? Target selection: in defence.js you assign defenders to a random enemy in the attacker's group. We thought it would be better if non-ranged units would select the nearest enemy (in the same attacking group). This would give them a better chance of inflicting some damage as you might get situations where a swordsman needs to cross a whole group of enemies to hit his randomly selected target. Ranged units on the other hand could select the strongest enemy. We used your built in getUnitStrength function to determine the strongest enemy. In case of multiple strongest enemies, just select the one who is nearest. Training units: currently you train units of which the population has the lowest amount of. I assume this assures a nice variety of unit types (no one likes to fight against an elephant spammer...). However, we thought it would be nice if the AI tried to focus on training the stronger units. We attempted to use the getUnitStrength function here too, but since this part of the code deals with templates instead of entities we weren't able to succesfully implement it. Females vs males: in economy.js, you set the limit of females in a population to one third. My friend and I debated that in the beginning of a game you'd like to have lots of females to quickly gather resources and transfer into the city phase. However once you're done building your city and have started focusing on training an army, we reckon the 1/3 limit should decrease so that qBot can create more soldiers. In other words, we suggest a flexible female citizen population limit; high in the beginning, lower after entering the city phase. Key buildings: right now you only set Civ Centers to be key buildings (in defence.js). When unassigning defenders, you send them back to the nearest key building (currently only Civ Centers). Maybe you could add fortresses to the list of key buildings? Entry points: in terrain-analysis.js, you calculate the entry points. These are defined on a block placement radius of 45 from the Civ Center. We noticed that on smaller maps, this distance is too big (for example Fast Oasis). A radius depending on the size of the map would be more suitable. Instead of 45, we divided the shortest side (width or height) of the map by 6 and it seems to give decent results: if(this.width < this.height) { blockPlacementRadius = Math.floor(this.width/6); } else { blockPlacementRadius = Math.floor(this.height/6); } Patrols: finally, we had a go (but failed) at incorporating patrolling behaviour. Our idea was that we would use the entry points as a patrolling route. A group of soldiers (probably elite soldiers) would walk from one point to the other, guarding the territory. The group could wait a set amount of time at each point (say 10 seconds) and then move on to the next entry point. Eventually qBot will build fortresses on these entry points, at which point the patrol group(s) would simply be walking from fortress to fortress. I think it would be a neat defensive behaviour, as apposed to simply standing still somewhere. Further patrolling points could be Civ Centers and other important buildings.

Perhaps another thing to consider: classify skirmish/battles depending on where they take place. A group of at most 15 versus 15 soldiers in no mans land would just be a skirmish. If either group is larger than 15, then its a battle. A group of more than 15 soldiers entering enemy territory would be a battle (ok, they haven't started attacking yet but we can expect that to happen very soon). The number 15 is just an example. The battle would end when the invading forces have been killed or have retreated and left enemy territory. In the case of fighting in no mans land, the battle would be over when either side has last 75% of its forces. Again, 75% is just an arbitrary number.