244 replies to this topic

[Pureon]

Brilliant, I'll check it out

[Mythos_Ruler]

quantumstate, on 17 December 2011 - 10:11 PM, said:

I have just committed the last set of features before Alpha 8. See http://trac.wildfire...changeset/10755 for a list of the significant changes.

Garrisoning is disabled for now because of the issues it was causing and the defence should generally behave a bit better now, it seemed to have a few quirks before.

Updated. Playtested. Got AI warnings regarding troop strengths and such. And qBot never did raid me or attack me in force.

[infyquest]

Playteseted the new Code, too many Forts are being placed.
There is a build limit for Forts, Instead a scout tower needs to be placed,
If only the spot is near a verz important attack route then place the fort.
I will check other scenarios when I have time

[Pureon]

Very enjoyable It built defenses in front of the civilian buildings, it defended very well, it built a lot of fortresses, it attacked in a number of locations, it used the new Persian units effectively, generally it put up a strong fight. It didn't expand as much as it could, but the oasis map didn't have many resources outside it's starting base, which probably explains that.

infyquest, on 18 December 2011 - 12:19 AM, said:

Playteseted the new Code, too many Forts are being placed.
There is a build limit for Forts, Instead a scout tower needs to be placed,
If only the spot is near a verz important attack route then place the fort.
I will check other scenarios when I have time

I didn't mind the large amount of fortresses - however it did look like it was exceeding the build limit. Perhaps it builds too many defenses now and should attack more/earlier, but that could be something to work on for Alpha 9.

As Mythos said, debug warnings should be turned off. I did receive a few other warnings though: http://pastebin.com/0fS0dcmE

But overall, great

[quantumstate]

Mythos_Ruler, on 17 December 2011 - 11:08 PM, said:

Updated. Playtested. Got AI warnings regarding troop strengths and such. And qBot never did raid me or attack me in force.

I have simplified this code a bit, basically it raids for the first 6.5 minutes and then attacks as previously after that. The raids are random, it is possible that no raids happen at all, though I increased the probability a bit so that should be rare. I forgot to disable the debug messages before committing, they are disabled now .

infyquest, on 18 December 2011 - 12:19 AM, said:

Playteseted the new Code, too many Forts are being placed.
There is a build limit for Forts, Instead a scout tower needs to be placed,
If only the spot is near a verz important attack route then place the fort.
I will check other scenarios when I have time

There was a bug in he check for building limits, <= instead of <. It builds forts on the most important (shortest) attack routes first and then just keeps going after that. Also I slowed the fortress building rate a bit.

Edit: Pureon: I have added another check into the attackMoveToLocation code, Hopefully this will stop the error you got, it seems to be a bit persistent.

[infyquest]

i know why it builds fortresses, coz its in the two lists the advanced building lists and the separate list for fortress.
We might need to remove it from advanced list

[infyquest]

added a config.js file http://pastebin.com/vCrGg2t4
need to modify the rest of the code, check it out

[quantumstate]

infyquest, on 18 December 2011 - 02:18 PM, said:

i know why it builds fortresses, coz its in the two lists the advanced building lists and the separate list for fortress.
We might need to remove it from advanced list

The advanced building list will only ever build one fortress. Have you observed the warning about build too many fortresses since my last commit? I should have fixed it there. The defensive building code is designed to build up to the build limit of 10 fortresses (at least on open maps) but it will take its time doing so.

[infyquest]

see the new config.js file and please post your comments

[quantumstate]

infyquest, on 18 December 2011 - 02:27 PM, said:

see the new config.js file and please post your comments

The config file is a good idea which we should implement. This should allow us to do nice things like making aggressive and defensive versions of the bot which can by easily switched between.

One thing to consider is that a lot of properties which should be configurable should also be dynamic. One possibility is allowing some functions to be defined in the config file. Making the config file too complicated does cause problems though.

[Pureon]

Some more warnings and bugs I found just now (using latest svn qbot):

WARNING: JavaScript warning: simulation/ai/qbot/attackMoveToLocation.js line 93 reference to undefined property this.path[0][0]
 
WARNING: JavaScript warning: simulation/ai/qbot/attackMoveToLocation.js line 93 reference to undefined property this.path[0][1]
 
WARNING: JavaScript warning: simulation/ai/common-api/utils.js line 3 reference to undefined property b[0]
 
WARNING: JavaScript warning: simulation/ai/common-api/utils.js line 4 reference to undefined property b[1]

WARNING: JavaScript warning: simulation/ai/qbot/attackMoveToLocation.js line 216 reference to undefined property this.path[0][0]
 
WARNING: JavaScript warning: simulation/ai/qbot/attackMoveToLocation.js line 216 reference to undefined property this.path[0][1]

ERROR: JavaScript error: simulation/ai/qbot/attackMoveToLocation.js line 93 TypeError: this.path[0] is undefined ([object Object],[object Object])@simulation/ai/qbot/attackMoveToLocation.js:93 ([object Object],[object Object],[object Array])@simulation/ai/qbot/military.js:586 ()@simulation/ai/qbot/qbot.js:103 ([object Object])@simulation/ai/common-api/base.js:92 @:0
 
ERROR: JavaScript error: simulation/ai/qbot/attackMoveToLocation.js line 93 TypeError: this.path[0] is undefined ([object Object],[object Object])@simulation/ai/qbot/attackMoveToLocation.js:93 ([object Object],[object Object],[object Array])@simulation/ai/qbot/military.js:586 ()@simulation/ai/qbot/qbot.js:103 ([object Object])@simulation/ai/common-api/base.js:92 @:0

This treasure is very close to the AI's starting base on Peloponnese, but it caused some lag.


The AI managed to get stuck sending it's attack force towards my base. This caused a lot of lag. Not sure what can be done to prevent that.

[Android_]

Looking forward to playing against qbot in the next release . Does it cheat by the way and if yes, in what way?

[historic_bruno]

Android_, on 20 December 2011 - 12:12 AM, said:

Does it cheat by the way and if yes, in what way?

I don't think AIs can cheat yet, they have the same abilities as a human, although they can be faster and multitask better

[Android_]

Hehe sure that . In the Age games the AI at 'hard' level or above would get resource bonuses if I remember correctly; I meant stuff like that, or no LOS restrictions etc. Good to know qbot doesn't need any of this apparently .

[historic_bruno]

Android_, on 20 December 2011 - 01:12 AM, said:

no LOS restrictions etc

This is true, they don't have LOS restrictions yet, so they can attack buildings and units not yet explored, which I think is mostly a technical issue rather than a deliberate cheat. My hope is that our AIs get good enough so as to be competitive with our best players, without cheating, and then we can let them cheat if needed for an extra challenge (and dumb them down for easier levels).

[quantumstate]

I would say that it uses the no LOS to cheat a bit at the moment. Basically it uses it to measure your army strength and uses this to affect how many troops it trains and when it attacks. There are no resource benefits though.

Pureon: I fixed the first one by stopping qBot for trying to gather those kinds of treasure. The second is more tricky, I might be able to sort something out so it can recover after a period of time, I will see.

[historic_bruno]

Pureon, on 19 December 2011 - 11:37 PM, said:

The AI managed to get stuck sending it's attack force towards my base. This caused a lot of lag. Not sure what can be done to prevent that.

I've had something similar happen to me during a game, so it's not only AIs. The siege units in formation cause pathfinding nightmares, for one thing, and formations generally are garbage when there's only a narrow path (as over a cliff). The best thing would be to have no maps with narrow passes for now, including cliffs.

[quantumstate]

Pureon, on 19 December 2011 - 11:37 PM, said:

Some more warnings and bugs I found just now (using latest svn qbot):

WARNING: JavaScript warning: simulation/ai/qbot/attackMoveToLocation.js line 93 reference to undefined property this.path[0][0]
 
WARNING: JavaScript warning: simulation/ai/qbot/attackMoveToLocation.js line 93 reference to undefined property this.path[0][1]
 
WARNING: JavaScript warning: simulation/ai/common-api/utils.js line 3 reference to undefined property b[0]
 
WARNING: JavaScript warning: simulation/ai/common-api/utils.js line 4 reference to undefined property b[1]

WARNING: JavaScript warning: simulation/ai/qbot/attackMoveToLocation.js line 216 reference to undefined property this.path[0][0]
 
WARNING: JavaScript warning: simulation/ai/qbot/attackMoveToLocation.js line 216 reference to undefined property this.path[0][1]

ERROR: JavaScript error: simulation/ai/qbot/attackMoveToLocation.js line 93 TypeError: this.path[0] is undefined ([object Object],[object Object])@simulation/ai/qbot/attackMoveToLocation.js:93 ([object Object],[object Object],[object Array])@simulation/ai/qbot/military.js:586 ()@simulation/ai/qbot/qbot.js:103 ([object Object])@simulation/ai/common-api/base.js:92 @:0
 
ERROR: JavaScript error: simulation/ai/qbot/attackMoveToLocation.js line 93 TypeError: this.path[0] is undefined ([object Object],[object Object])@simulation/ai/qbot/attackMoveToLocation.js:93 ([object Object],[object Object],[object Array])@simulation/ai/qbot/military.js:586 ()@simulation/ai/qbot/qbot.js:103 ([object Object])@simulation/ai/common-api/base.js:92 @:0

I'm pretty sure I've finally removed the source of these errors. They seem to have been a bit troublesome though, if the happen again I may ask someone else to try and sort it out for the sake of my sanity .

[feneur]

Just saw the "Observer-Oasis" map and decided to see how JuBot and qBot played against each other. qbot won, but it took 40 minutes (I used the warp time feature at times ). I think it would have been much quicker if qBot had used siege weapons earlier. JuBot didn't really survive that long if you look at actually being able to strike back, all its units were lost long before that, so it was more that it took a long time before qBot actually managed to destroy all its buildings (and because it sent a lot of troops after my observer camel instead of finishing off JuBot in the end-game =) ). That it took a while before qBot actually built any siege is probably a good thing in most games as the enemy is likely to be more offensive, but there was another thing that was a bit confusing. Instead of taking down a building completely qBot destroyed it partly, but then moved on to the next, which really doesn't do much harm. Not sure if that's a bug or just a feature gone wrong in this case =) But overall I'd say qBot seems to manage its economy really well, and is pretty good defensively once it gets going. The area that needs some work atm imho is attacking buildings, at least from what I could see in that game

[k776]

qBot could take advantage of destroying city centers and cutting off the territory. Then every building slowly loses health at once.