qBot (yet another AI)

[quantumstate]

Since 0 A.D. clearly doesn't have enough AI's I decided to make a new one. It is actually a fork of testbot, but has had some fairly large changes.

I have been working on it for about the last 1.5 weeks on and off (faster progress recently since it is making me excited). I decided to announce it now because I just got it to beat JuBot for the first time on Oasis (it may well not do this on other maps).

Key changes from testbot:

- Replaced the plan manager with a new queue system which is persistent.

--- This allows predictive resource priorities so the right stuff is gathered when needed.

--- Should lead to a more efficient AI in the future since plans are not discarded at the end of a turn.

--- Does fairer priority balancing, keeping an account of resources spent.

- Buildings are demand driven

--- Houses keep up with demand and don't waste wood by having too many

--- Farms will be replanted forever (well until the wood runs out)

- The military is currently a heavy work in progress.

--- Currently it builds several barracks then spams spearmen and javelinists until it has twice as many troops as the enemy (or 60 units), then walks up to their CC and lets the troops have fun .

--- It now builds advanced units, and defence buildings. Also it defends against attacks.

More information

There is an overview of how qBot works at https://github.com/quantumstate/qBot/wiki/qBot-Structure-Overview

The Code

This resides on github.

https://github.com/quantumstate/qBot

Bug Reports

There is an issue tracker on github if you have/are willing to create and account there. Otherwise please contact me through the 0AD forums or irc.

NOTE: qBot requires a recent svn version of the game, it will not work with alpha 7

Edited October 14, 2011 by quantumstate

[Pureon]

Tested and it works as described. Keep the updates coming!

[gudo]

Nice looking bot you got there. I did some testing and it plays well. I would slightly lower the priority on food and slightly raise it for wood though. On the tests that I did with it, qBot stocked tons of food but was consistently bottle-necked by wood shortages.

As far as non-trivial changes go though, I found that placing a mill and farmstead (on the line between your civ center and your opponent's, roughly 40-45 tiles away from your own) gave the AI quite the boost, more-so than using your citizen soldiers to gather. Sure, it's not the most intelligent way to place a mill, but it's better than Jubot's method and certainly better than nothing. No clue how you'd do that though.

Speaking of Citizen soliders, I've been poking around in the code and I think I've found a way to get them to gather and build too. I'll give it a shot over the weekend and post a patch on the off-chance I get it working.

Again, nice bot. Keep up the development!

[JuliusColtranePille]

great to hear that guys!

can't wait to get finally a bot which is really hard to match!

regards,

claas

[quantumstate]

Thanks for the comments, at this early stage my planned improvement list seems to be pretty large, quite a few are "architectural" things which makes it hard to figure how much improvement they will give initially but should help later on.

Nice looking bot you got there. I did some testing and it plays well. I would slightly lower the priority on food and slightly raise it for wood though. On the tests that I did with it, qBot stocked tons of food but was consistently bottle-necked by wood shortages.

Yes this is a problem in the predictive system because houses and barracks get put into the queue just before they are needed so the prediction code can't see them far in advance. This is compounded by the economic manager never reassigning villagers. I plan to fix both of these problems fairly soon by rewriting the futureNeeds function and implementing the villager reassignment (I just need to make sure the villagers aren't being reassigned constantly wasting loads of time walking between places).

As far as non-trivial changes go though, I found that placing a mill and farmstead (on the line between your civ center and your opponent's, roughly 40-45 tiles away from your own) gave the AI quite the boost, more-so than using your citizen soldiers to gather. Sure, it's not the most intelligent way to place a mill, but it's better than Jubot's method and certainly better than nothing. No clue how you'd do that though.

This sounds like a pretty map dependent fix, I would prefer to have a better system. The jubot approach should be better in principle, I haven't looked in detail at how it works though. I don't think it is worth spending time figuring out how to do your suggestion when it will be replaced later.

Speaking of Citizen soliders, I've been poking around in the code and I think I've found a way to get them to gather and build too. I'll give it a shot over the weekend and post a patch on the off-chance I get it working.

The main complication for this is sorting out how to juggle them between the economic and military managers. I think generally the military manager should have priority and will be able to use the citizen soldiers whenever it wants them. The military manager is still is a state of flux so it might be best to leave this at the current time until it stabilises, otherwise the changes may get out of date very fast. The villager reassignment issue will also affect this.

It would be great if you do want to work on patches, it is just that I don't think that this area is a good one to look at currently, unless you plan on broader changes to the current role system.

[gudo]

This sounds like a pretty map dependent fix, I would prefer to have a better system. The jubot approach should be better in principle, I haven't looked in detail at how it works though. I don't think it is worth spending time figuring out how to do your suggestion when it will be replaced later.

Yeah, it really is pretty dumb, I wouldn't waste time on it either.

The main complication for this is sorting out how to juggle them between the economic and military managers. I think generally the military manager should have priority and will be able to use the citizen soldiers whenever it wants them. The military manager is still is a state of flux so it might be best to leave this at the current time until it stabilizes, otherwise the changes may get out of date very fast. The villager reassignment issue will also affect this.

Well, the basic idea is to spawn citizen soliders with the "worker" role. The AI should then treat them just like women. However, we'll give them a new metadata class "canattack" and start if off with "yes". The military manager will be looking for units with "canattack" == "yes" and once it finds enough, will sort them into a squad, change the role from worker to solider, clear out the subrole, and set canattack to "isattacking". Later, when the military manager is done with them, we can have it reset the units role to worker, and change canattack back to "yes". For the short term though, there should be a way for the economy manager to find idle workers and change their role to worker.

This way, citizen soldiers spawn as workers, and can be re-tasked by the military manager. When they go idle, we re-task them again as workers. Once re-assignement issues get fixed, we can remove the code that makes them workers.

There's still a bit of work to do to see if it's even do-able, but I can't see why it wouldn't work.

Edited September 23, 2011 by gudo

[quantumstate]

Well, the basic idea is to spawn citizen soliders with the "worker" role. The AI should then treat them just like women. However, we'll give them a new metadata class "canattack" and start if off with "yes". The military manager will be looking for units with "canattack" == "yes" and once it finds enough, will sort them into a squad, change the role from worker to solider, clear out the subrole, and set canattack to "isattacking". Later, when the military manager is done with them, we can have it reset the units role to worker, and change canattack back to "yes". For the short term though, there should be a way for the economy manager to find idle workers and change their role to worker.

This way, citizen soldiers spawn as workers, and can be re-tasked by the military manager. When they go idle, we re-task them again as workers. Once re-assignement issues get fixed, we can remove the code that makes them workers.

There's still a bit of work to do to see if it's even do-able, but I can't see why it wouldn't work.

That sounds pretty good in general. I will hold off doing this at the moment because of the lacking defence logic. Currently the defence works by letting the idle soldiers attack when the enemy gets within the radius (this is unitAI code). So setting them to become workers automatically would mean that there would be no defence at all with the current AI, the attackers would gradually slaughter them 1 by 1. But once incoming enemies can be spotted this would be good.

Also I have just commited a change to the resource predictions. From a quick test it seems to be allocating them a bit better and it should cope better in the future.

[UV_Completion]

I tried your Bot in a random map and it put up a lot more resistance than JuBot, nice work!

The only obvious flaw I could spot is that it builds an insane amount of units before it attacks which hurts performance a lot (it may be that not all of its attacks are that huge because I played with more than one qBot and they probably attacked each other earlier in the game). As I started an attack on its base it threw literally hundreds of infantry units at me, in the middle of an almost equal number of females. I didn't check the code but maybe you could lower the number of units it gathers before attacking a bit.. at least as long as the performance impact of large armies is so high.

Other things I noticed: One of the qBots tried to build a farmstead directly at my border (far away from its civ center). And the bot could probably build some defense towers, if only for aesthethic reasons. But I know that you just started working on it (and yet it's already quite impressive).

EDIT: Just had a brief look at the code and noticed this piece of code in military.js:

gameState.entities.forEach(function(ent) {
				if (ent.owner() === i && (ent.hasClass("CitizenSoldier") || ent.hasClass("Super"))){
					count ++;
				}
			});

And then he tries to build an army twice the size of the strongest enemy army.

I don't know Java script so I just assume that === does a comparison

But if you play with more more than one qBot this code could probably lead to an arms race between the two qBots (which explains the fact that in my game the second qBot only attacked when I had reduced the army of the other one significantly).

Edited September 23, 2011 by UV_Completion

[quantumstate]

The only obvious flaw I could spot is that it builds an insane amount of units before it attacks which hurts performance a lot (it may be that not all of its attacks are that huge because I played with more than one qBot and they probably attacked each other earlier in the game). As I started an attack on its base it threw literally hundreds of infantry units at me, in the middle of an almost equal number of females. I didn't check the code but maybe you could lower the number of units it gathers before attacking a bit.. at least as long as the performance impact of large armies is so high.

Yes, this is because you have multiple qBots. The default attack behaviour currently is to wait until they have twice as many soldiers as the most powerful enemy. So they were just sitting because the other qBots would have matched the training rate. This is because I haven't got round to implementing most of the military module. I have set a new maxAttackSize=60 as a quick fix.

Other things I noticed: One of the qBots tried to build a farmstead directly at my border (far away from its civ center). And the bot could probably build some defense towers, if only for aesthethic reasons. But I know that you just started working on it (and yet it's already quite impressive).

That sounds strange, I haven't seen behaviour like that. The current building placement code is still from testbot and is due to be replaced though (sometime, there seems to be a lot of stuff to be replaced ).

I think my idea of a really strong economic bot (lots of workers) is probably causing a lot of slowdown as well. I have lowered the max number of gatherers a bit for now.

Edit: You are indeed correct in your edit.

Edited September 23, 2011 by quantumstate

[Jubalbarca]

Speaking of arms races, expect a new version of JuBot pretty soon as well.

[WhiteTreePaladin]

Ah, nice. Looking forward to both of them.

[gudo]

Nice changes to Jubot there Jubal I just ran some tests with qBot and Jubot. Jubot certainly has an early advantage, but I couldn't seem to induce it to attack... I haven't looked very hard at the code though so I'm quite sure what Jubot looks for before starting to attack.

As far as qBot goes though, it got stuck. It tried to train lots and lots of Greek Calvary, but ran out of metal after just 10 units. qBot doesn't currently assign workers to mine for metal and it doesn't change it's plans when it runs out of resources. So it just sat around, not making anything till Jubot finally killed it.

[quantumstate]

As far as qBot goes though, it got stuck. It tried to train lots and lots of Greek Calvary, but ran out of metal after just 10 units. qBot doesn't currently assign workers to mine for metal and it doesn't change it's plans when it runs out of resources. So it just sat around, not making anything till Jubot finally killed it.

Ah, thanks for this I had been wondering why it stopped training, that makes sense now. The reason is that the worker reallocation isn't written yet so by the time gold starts being needed by the dynamic resource demand system all the villagers are allocated to food or wood.

[Jubalbarca]

Which faction was JuBot playing as, and how long did you leave it in which it didn't attack?

[quantumstate]

I have pushed an update which reallocates workers occasionally and also fixes a divide by zero error in the resource priority code, the result is that it now works correctly and doesn't fatally run out of gold. Also I fixed a typo so the maxattacksize thing actually works now.

[Pureon]

Looking forward to your AI's military improvements. After you left IRC yesterday I tried out the updated qBot, and it did what you said it would.

As you well know, there are still quite a few improvements to make to its economy, most importantly making citizen-soldiers gather resources (and therefore stop blocking access to the cc for other gatherers). If you can make this AI as aggressive as you are in a multiplayer match, then I'll be very happy

[gudo]

Just discovered a serious flaw in the latest version of qBot. I set up a random map w/4 players in free for all. Me, SplitBot, JuBot, and qBot. Shortly after the match stared, qBot sent about 10-15 women across the map to go farm off of one of JuBot's farms. It was the nearest farm to them. I think the problem is that qBot doesn't check ownership of farms, and the game permits farming of enemy farms.

Needless to say, all the women were killed (nice defensive behavior form JuBot, and the farm was on the other side of a tower >_>)

Jubal take note, I also saw your bot do this.

Edited September 30, 2011 by gudo

[historic_bruno]

the game permits farming of enemy farms

Interesting, I guess we need to check that a farm (any resource?) is either player owned or gaia before gathering from it

[feneur]

Or we could force players to defend their farms It's no big deal either way for me, perhaps it's easier for the AIs to not have to check whether a farm is enemy/defended before farming, but apart from that people should mind where they build their farms/that they defend their farms

[gudo]

Heads up quantamstate, as of r10348, the farm thing is a non-issue. Also, IsSeaCreature has been renamed to just SeaCreature.

[Mythos_Ruler]

I like the idea that farms are so easily capturable. Makes sense. It also allows a scenario designer to place Gaia farms on the map that any player can snatch up.

EDIT:

Heads up quantamstate, as of r10348, the farm thing is a non-issue. Also, IsSeaCreature has been renamed to just SeaCreature.

Errr, there was a reason we allowed the player to gather from fields they didn't own. See: The Massacre of Delphi map. So, I at least hope the change doesn't affect human players. In the end though, I think it should be a viable option to raze an enemy town and just snatch up his existing farms.

[Pureon]

I like the idea that farms are so easily capturable. Makes sense. It also allows a scenario designer to place Gaia farms on the map that any player can snatch up.

Absolutely. Farms should remain capturable by other players. AIs will need to find a better way to choose farms - nearby to cc/farmstead or anywhere within territory

[gudo]

The change makes it so that you can't farm opponents farms. Gaian farms are still fair game. Honestly, I like the change. Nine times out of ten, when I come across an enemy farm, I wan to destroy it because I'm raiding. If I've already driven off the defenders, (and so could farm) then I'm probably too busy pressing the attack to farm it. Besides, when you consider the distances you're farmers would have to travel to deposit their goods it's not really worth it anyways. Farms are only useful if you can build a farmstead nearby (meaning you have territory.) If that's the case, just expand your influence and capture it via loyalty.

[historic_bruno]

Errr, there was a reason we allowed the player to gather from fields they didn't own.

Try gathering from an enemy (non-gaia) farm some time

[Linux_Eki]

Simulated 15 minutes. Somehow bot decided that 20 women should just stand near town center. It built barracks and some houses but not any farms. Tested on build 10359 with latest qbot code taken from git.