New Java AI, HughAI

[hughperkins]

I've added links for E323AI, CransJavaAI and my (planned ie doesn't do anything yet) ClojAI to the wiki list.

Hi Ato,

Clojure sounds very interesting. Kind of Haskell-like it seems? I might give it a quick play, I find playign with FPs quite fun, albeit my productivity with them is quite low

I'd be quite interested in playing with your AI, from a dev poitn of view, at some point, maybe now, maybe later, not sure

Hugh

[hoijui]

P.S. Ohyeah, found this in the log, no idea what I did to do that :)

Ok, it looks like probably a unit was killed off, and then the pack coordinator didn't realize that for some reason. Don't suppose.... if you still have it... could you paste the entire log into pastebin, or attach it to a message please?

Hugh

No ide aif this may apply here, but just in case you do not know.. cause this caused quite some confusion already:
when an enmey unit dies out of your view and out of your radar range, you wil not get an enemyUnitDied event for it, except you have cheat events enabled.

[hughperkins]

No ide aif this may apply here, but just in case you do not know.. cause this caused quite some confusion already:
when an enmey unit dies out of your view and out of your radar range, you wil not get an enemyUnitDied event for it, except you have cheat events enabled.

Hi hoijui,

Definitely worth pointing out. However, in this case, the units in question are friendly units.

I'm sure the problem is fairly simple to solve, but it's easier to have the whole logtrace in order to check easily.

Hugh

[ato]

Clojure sounds very interesting. Kind of Haskell-like it seems? I might give it a quick play, I find playign with FPs quite fun, albeit my productivity with them is quite low

Yeah, it shares a lot of features with Haskell (lazy sequences, immutability, multimethods, nice concurrency stuff), but it's dynamically typed (although it does support type-hinting for performance) and runs on the JVM and plays nice with Java code which makes it a bit practical for some tasks. Don't take my code as a good example of Clojure style though, I'm still pretty new to it and I'm still experimenting with the best way to design ClojAI. I'll post here when ClojAI can actually do something interesting.

[hughperkins]

New release of HughAI:

Highlights:
- it beat E323AI v 2.12.0 just now, one game won out of one game attempted, I didn't try too many times though in case it was a fluke
- ECMA (=Javascript) console added
- threatmap used for targeting with main tanks
- also, the main tanks decide whether to attack based on the threatmap, rather than just on whether there are five of them or not (seems a little more sensible )

Bug fixes:
- corrected an issue with non-square maps

Please see top of thread for link to new release.

[hughperkins]

Latest git version can beat AAI now with maphack turned off, both playing as ARM, on SmallDivide, BA 5.96.

I'll post the replay and stuff when I have more bandwidth.

[1v0ry_k1ng]

hey, does this AI use configs? if it does (that seems like a logical reason for it to only play BA/arm), I dont mind doing some configs for you (if i can understand the syntax of your config files anyway :p)

[cranphin]

The only Issue I see/have with the console is that on XP and with 0.80, which seems to have introduced issues with alt-tabbing out of fullscreen on XP, it makes the console take the forecround, and thus the fullscreen dissapear, which then nearly locks up everything XD

I've added an option to my config file to make the gui possible to be disactivated, but perhaps the easiest thing could be to have it disactivated by default, and then to have a spoken command to make it appear?

Possibly :) Does sound nice for people who'd have the same issue, since it can really mess you up ^_^
The easy way around is to run spring windowed anyways tho, that solves such things :)

Wow, you ported KAIK in it's entirety! That's very cool. Maybe I'll take a look. Depending on how it looks I may look at extending / tweaking KAIK rather than extending / tweaking HughAI. I'll take a look and see which seems to be the easiest path to me.

Errr... the downside of that is that this is a very flat from old optimized c code port, expect performance issues and all sorts :) Also the way KAIK is built, you're rather locked into the way it works. My opinion 'd be I much prefer your current work, since it seems a lot fresher and more Java-ish :)

Can you give me a list of the points you feel are outstanding in getting it to run more or less as well as the original KAIK?

Good question XD
Performance is high on the list :)
Also need to carefully look at any bugs made in porting, right now I feel that KAIK wins more, not sure why, but tiny mistakes can have that effect (feels like mine doesn't spread out as much initially, not sure XD)
And there's probably still places where it will crash spring (using a -1 id will do that for example :) ), or crash itself (nullpointer exceptions and such). Takes time to hunt those out :)
Also, KAIK has issues, there's code that doesn't work very well, or spams lots of warnings/errors, I'd like to solve those, but I already found out that's a very very slow process of 'fixing' something, then fixing whatever your 'fix' broken, and lots of very carefull testing to figure out what the AI is doing XD

P.S. Ohyeah, found this in the log, no idea what I did to do that :)

Ok, it looks like probably a unit was killed off, and then the pack coordinator didn't realize that for some reason. Don't suppose.... if you still have it... could you paste the entire log into pastebin, or attach it to a message please?

Sorry, it's long gone :)
Shouldn't be hard to reproduce tho, managed on the first try with only a short game :)

[hughperkins]

hey, does this AI use configs? if it does (that seems like a logical reason for it to only play BA/arm), I dont mind doing some configs for you (if i can understand the syntax of your config files anyway :p)

Hi 1v0ry_k1ng,

Yes, it is config based, at least maybe 95%, maybe there are a few places where there are unit def names hard-coded in the code, but it's dead-easy for me to shift those into the config once I notice them, or if someone points them out to me.

There are two config files:

AI/Skirmish/HughAI/0.1/<mod name>_2.xml -> main config file, mixture of general configuration options, and some unit name preferences.
AI/Skirmish/HughAI/0.1/<mod_name>_workflows/default.xml -> workflow file: decides what gets built in general

I'd hesitate to get you to generate config files at this point though. The whole config bit is a little up in the air and not really stable at the moment, so your configs might not last very long... maybe not more than a day or two...

Anyway, so ...

- in the general config file (<mod name>_2.xml ) , there are the names of units that certain controller classes will tend to take over:
reconnaissanceunitnames => the units that will be used as scouts. They will be assumed to be vehicles for now, with a maximumslope value of at least config.maxvehicleslope, if that makes sense?
offensiveunitnames => the units that will be used as tanks, to attack. They will be assumed to be vehicles, with a maximumslope of at least config.maxvehicleslope

- other values in the general config file that off the top of my head could be important:
maxvehicleslope => the maximum slope on the terrain which vehicles are assumed to be able to traverse
... err.. well.. you can basically see which bits have unit names and stuff

- anything with a name like 'somethingsomethingmarkerunitname' is the name of units that will be drawn onto the terrain as part of debugging. If they don't exist in the mod, you might get exceptions, at least whilst running in debug mode, otherwise they're not too important, don't affect gameplay at all

- right, the workflow is the fun bit, this is where you get to say what gets built and in what order. For example, the BA default workflow looks like the following , at least few lines:

Code: Select all

<listitem priority="2.0" quantity="1" unitname="armvp"/>
<listitem priority="2.1" quantity="2" unitname="armfav"/>
<listitem priority="2.0" quantity="10" unitname="armstump"/>
<listitem priority="2.0" quantity="10" unitname="armsam"/>
<listitem priority="1.95" quantity="4" unitname="armmex"/>
<listitem priority="1.95" quantity="4" unitname="armsolar"/>
<listitem priority="1.9" quantity="3" unitname="armcv"/>
<listitem priority="1.8" quantity="1" unitname="armmstor"/>
<listitem priority="1.8" quantity="1" unitname="armavp"/>
<listitem priority="2.0" quantity="3" unitname="armbull"/>
<listitem priority="2.0" quantity="2" unitname="armmart"/>

So, the units get built in descending order of priority, according to what can be built. So, for example, if armbull (the level 2 tanks) have a higher priority than jeffies, they will be built before jeffies, but only if there happens to be a level 2 factory, otherwise first the jeffies will be built, and then once there is a level 2 factory, the armbulls will be built.

The unitname is the unit that will be built, and the quantity is the number that should be alive before looking for the next down on the priority list.

If 10 armstumps were built, but 5 were killed, 5 more will be built before building other things further down. HOpefully. IN theory. That's how it's supposed to work anyway I think.

The whole config thing is fairly up in the air, so if you've got ideas on how you'd like to see the config files look, go ahead.

Hugh

[hughperkins]

Errr... the downside of that is that this is a very flat from old optimized c code port, expect performance issues and all sorts :) Also the way KAIK is built, you're rather locked into the way it works.

Ok.

My opinion 'd be I much prefer your current work, since it seems a lot fresher and more Java-ish :)

Thanks!

[hughperkins]

game vs E323AI v2.12.0, with the correct config

Ok, so apparently, by default, E323AI doesn't come with quite the right config straight out of a git ccmake build, so I needed to do a rematch with the appropriate config.

It was close. Verrrryyy close. I thought I'd lost. It was down to 3 tanks each, but the other guy had a factory, but then .... his workflow stalled! and then... for some reason he was standing in range of at least one of my samsons, and then he just exploded :-DDD

http://manageddreams.com/hughaireplays/ ... df.tar.bz2

I feel it was too close to call really, neck and neck, maybe E323AI had a slight edge despite losing ultimately by a fluke. I'll probably do several matches and see how they fare over several games.

[1v0ry_k1ng]

[quote="hughperkins"]
- right, the workflow is the fun bit, this is where you get to say what gets built and in what order. For example, the BA default workflow looks like the following , at least few lines:

[code]
<listitem priority="2.0" quantity="1" unitname="armvp"/>
<listitem priority="2.1" quantity="2" unitname="armfav"/>
<listitem priority="2.0" quantity="10" unitname="armstump"/>
<listitem priority="2.0" quantity="10" unitname="armsam"/>
<listitem priority="1.95" quantity="4" unitname="armmex"/>
<listitem priority="1.95" quantity="4" unitname="armsolar"/>
<listitem priority="1.9" quantity="3" unitname="armcv"/>
<listitem priority="1.8" quantity="1" unitname="armmstor"/>
<listitem priority="1.8" quantity="1" unitname="armavp"/>
<listitem priority="2.0" quantity="3" unitname="armbull"/>
<listitem priority="2.0" quantity="2" unitname="armmart"/>
[/code]

So, the units get built in descending order of priority, according to what can be built. So, for example, if armbull (the level 2 tanks) have a higher priority than jeffies, they will be built before jeffies, but only if there happens to be a level 2 factory, otherwise first the jeffies will be built, and then once there is a level 2 factory, the armbulls will be built.

The unitname is the unit that will be built, and the quantity is the number that should be alive before looking for the next down on the priority list.

If 10 armstumps were built, but 5 were killed, 5 more will be built before building other things further down. HOpefully. IN theory. That's how it's supposed to work anyway I think.

The whole config thing is fairly up in the air, so if you've got ideas on how you'd like to see the config files look, go ahead.
[/quote]

that system sounds like it will scale badly later game- ie, later game it is not possible to have enough of any given unit. an AI that simply stops building stumpys is going to be doing it wrong.

what you could have in each workflow thing is a timemultiplier= for quantity values that multiplies the desired number of units by the ingame time. ie, stumpys have time multiplier increase of 0.2 (where it starts at 1) per min so that in 10 minutes the optimal number of stumpys has risen from 10 to 30.
likewise, you can have negative time multipliers, so jeffys, while important early game, ie, 10 at game start, decrease by 0.2 per minute, so that by the 10 minute mark the quantity value is 0

this would also allow you to control the speed it builds economic structures, defences etc

[hughperkins]

Yeah, you're right. We have a threatmap now. Possibly the choice of units could be based on things like:
- total metal production
- total friendly unit 'power' (there really is a value called 'power' in each unit's definition)
- total known enemy unit 'power' (combine with those fast reconnaissance aircraft, and this could be quite accurate)
- total known enemy metal production (again, can be determined quite accurately with good aerial reconnaissance, ie location of each mex, type of mex, and consulting the (known) metal map for the map

One other point that is related that is up in the air is the extent to which we have a single central workflow, responsible for deciding what gets built, and the extent to which the various high-level controllers - Offense, Reconnaissance for example - get to express their preferences.

Advantage of delegation to high-level controllers such as Offense and Reconnaissance: it's generally a better strategy for programming, easier to maintain, I can't think quite how to express it. I mean, Reconnaissance knows exactly what it wants, so why not just trust it to request the right thing?

The tricky bit is how does one judge whether to allocate units to Offense - which says it needs tanks badly - or to Reconnaissance - which is crying out for spy planes, and so on, so there probably does need to be some central arbitater somehow anyway.

Advantage of central controller: really easy to modify, high visibility over what will get built and when. Fairly easy to swap one workflow out and another in. Either randomly at the start of a game, or perhaps reacting to the type of units built byt the other: one workflow might be graet if the other has lots of air for example.

What does a human do? It's hard to say... I mean, I personally, well I'm not that great at RTSs , but I think that what I do is:

1 at the start of the game, there is a very precise order for building the first couple of mex, solar panels, factory
- but sometimes one might rush, and modify this
- or on some maps one might rush to get out a bomber
- etc...

2 then I will tend to focus all my resources on building attack units, and resource extractors
- the exact quantity and type of attack units to build will vary, and depend somewhat on what the other guy is doing

3 then attack

4 then tech up for a bit
- the exact time will vary, and depend somewhat on what the other guy is doing
- the exact technologies chosen will vary, and depend considerably on what the other guy is doing

5 then go back to step 2.

It might be nice if at least the way of describing what to do to the AI allows such a playstyle to be written down understandly and clearly somehow... anyway that is kind of what I am aiming for, and the config structure will naturally ideally reflect that somewhat over time.

[ato]

The tricky bit is how does one judge whether to allocate units to Offense - which says it needs tanks badly - or to Reconnaissance - which is crying out for spy planes, and so on, so there probably does need to be some central arbitater somehow anyway.

Yeah that's something I've been wondering about. How to allocate resources (both in terms of metal, build queues and actual units). I was thinking about a budget type system. Allocate say 50% of resources to spend on economy-building, 10% on reconnaissance and 40% on offense on average over a long-term period. (Have to figure out some good actual numbers through experiment). However short-term it doesn't make sense to be spending resources on scouts or radar towers when there's tanks charging through your base. So make the budgets flexible in special conditions, if you're under serious threat, military budgets temporarily ges a higher allocation, but later once things have calmed down a bit the other budgets get paid back what was borrowed from them.

[hughperkins]

Yeah, I tend to anthropomorphosize in order to figure out how something should work.

Like, for example, I imagine hierarchies in a large corporation like layering in an application, and that helps me figure out how corporate hierarchies work but it works backwards too I feel, from real world things into classes and stuff.

In this case, we'd likely have some fairly high level commander, let's say the president for the sake of argumment, with the head of the air force, the army, the navy, maybe some commando forces, sitting around telling him what to do. They're all saying they're the best, build more ships! build more tanks! build more jet planes! How does the high-level commander choose? Now, I'm starting to think as I write here. Possibly he has some military advisers? Maybe several? They disagree. How does he choose between what the military advisors say? Past successes? Convincing arguments? Some mixture of the two?

Obviously, in an AI, convincing arguments will tend to be very canned, but they're not impossible, like for example:

Code: Select all

enum Reason {
   AttackImminent,
   AttackUnderway,
   ...
}

Backing off a bit, and coming into the question from another angle: in the real world, no decision is made with perfect information, and no decision is perfect. What we want are:
- decisions that are reasonable, and take into account strongly what the enemy is doing
- decisions that mix it up a bit. Imagine if you played paper-scissors-stone, and always played stone, you'd after a while have a 100% probability of losing. If you choose randomly, now you have a 50% chance of winning the game.

Hugh

[hughperkins]

New release, 20090921.

Changes this release:
- can now play as core. parallel configurations in both core and arm are now possible, and both an arm and a core configuration come by default.
- java console now displays any compilation errors and exceptions in the gui, rather than only in the underlying spring console

Please see the top of this thread for download link.

[Umrug]

Insta-crash on frame 1. BA 7.01, Barren.smf

Infolog:
[ 0] Player UnnamedPlayer (auto)-paused the game for letting Skirmish AI HughAI initialize for controlling team 0. The game is auto-unpaused as soon as the AI is ready.
[ 0] SkirmishAI0: Reloading ai from E:\games\Spring\AI\Skirmish\HughAI\0.1\UnderlyingAI.jar ...
[ 0] SkirmishAI0: ai 0 initing..
[ 0] SkirmishAI0: Creating new cachefile for mod Balanced Annihilation V7.01
[ 0] SkirmishAI0: cleaning map...
[ 0] SkirmishAI0: ... done
[ 0] SkirmishAI0: Hugh AI initialized v0.0012, team 0
[ 1] UnnamedPlayer paused the game
[ 1] UnnamedPlayer unpaused the game

<end of infolog>


AI log ends in
INFO: *TankController Initialized*
0 ms INFO: registerGameListener TankController2
0 ms INFO: registerGameListener WorkflowController
0 ms INFO: CSAI registering voicecommand unpauseai
0 ms INFO: MainUI.registerbutton Reload AI
0 ms INFO: UnitCreated()
0 ms INFO: Ownership.unitcreated 961 Commander
0 ms INFO: csai.unitfinished 961 Commander
0 ms INFO: UnitController.NewUnitFinished Commander 961
0 ms INFO: UnitController.AddUnit: unit id armcom Commander
0 ms INFO: BuildTree: unitadded
0 ms INFO: BuildTree: ... 43 Commander
0 ms INFO: BuildTree: ... not seen before ...
0 ms INFO: UnitController.AddUnit finished
0 ms INFO: orders count is : 0

[hughperkins]

Hi umrug,

There is nothing in this log that shows a crash, everything in the bits you've posted is normal. Why do you feel that the AI crashed?

Hugh

[hoijui]

niice it can play core now, good work!

Umrug, maybe spring crashed, and the error is in infolgo.txt?
if so, use pastebin.com or attach as file.

[1v0ry_k1ng]

ok, so did some testing.

firstly, on the two machines I tried it on (both with wildly diffrent specs and slightly diffrent java versions) it crashes 100% of the time when a player is defeated, either itself or another faction. it is also impossible to quit the match without the crash freezing spring up requiring it to be manually closed. it leaves no clues as to why in the infolog.

attacking behavior seemed good when it actually happened, although most the time units just gaurded the commander irregaurdless of hughAIs undefended base being attacked and events elsewhere on the map.

the commander seems to be the weakest element of the AI, simply walking around building and often walking into defences/other commanders and exploding

the config system (priorities and number of units) needs an overhaul imo, it just isnt flexible enough. the current build order needs work: should make 3mex-->2 solar-->factory, currently it makes metal extractors last resulting in stall. it also builds stumpies too early, resulting in E-stall.

as a rule, the commander should really just be lab assisting after the first 5 mins, using cons to expand