Grace

[Ace Rimmer]

Worst 2 or 3...

1. The biggest by far is your handling of navy. I agree with the numbers and have my naval code set to pretty much the same (reacting to distances of 10, etc), but if I remember/read correctly you have your BB's charge ahead while the carriers sit back. This might work out some of the time, but against any experienced player Grace will lose her skirt.

There are a number of easy ways to combat this method of fighting and a number of reasons it leaves you weak. You're at a disadvantage in radar (you're blind) while the player can just move back pulling your BB's away from any air support and kill them while they can't see. Your carriers can not provide good fighter support because half your fighter fuel will be spent just getting to the front line. There are more, but in general CV's and BB's working together (closely) are much more powerful than BB's and CV's working apart, even in the same theater. (the sum is greater than the whole)

2. Having all Bombers up at all times. While on the surface might sound good, it only is once the major fleet battles are finished and you're on anti-sub patrol (and you're the 'winner' of the aforementioned fleet battles. . This is like putting all your eggs in one basket. You're asking the enemy to come in and kill as many bombers as they can grab. My thoughts would be to have the bare minimum up for protection and conserve the rest or mass groups of them together for either A. striking cities and/or B. fleet combat.

Of course, I haven't seen Grace in action, so the above is based only on your description.

Also, if you were to see what I call 'code', you'd feel much better about yours. I never heard of Lua till BotCon was announced, and I don't 'know' any language other than English (some might say not even that one ).

Lastly, I want to see your code not for the methods (implementation of strategy/tactics) or theory, rather to see relevant examples on how to 'properly' create and access tables, write functions, order processes, etc. I would imagine if your code is a knock-off of what the kool kidz wear, mine would be what you found at the landfill under piles of steaming rubbish, after years of neglect.

[Barbarossa]

SMC are you still working on your Grace bot? If so, you mind I ask if you are developing it in LUA or C++? If C++, are you using the Visual Studio 2008 IDE? I'm trying to compile the default Original4 ivai.dll bot just to get it working in the bot enabled version of Defcon but so far no success.. I've tried both the author's instructions in his api kit .pdf and also the ivai.vcproj file included in the introversion_ai_bot_v0.9 but alas no cigar. I don't get any errors at compiling but runtime when I use the bot that I compiled it crashes to desktop with error code 3. I'm never used Visual Studio before so that might be the problem, but in any case I can't figure out what I could be doing wrong.

[smc]

Thanks for those comments Ace. Number 1 is easy to adjust, at the moment Battleships seek a point halfway between friendly carriers and enemy ships. That can be easily changed to 10% of the way there, or a constant amount. What you're saying makes sense, so I'll have a play around with it. For the second - yes, I am planning to have them do useful things rather than just mill about The intention is to keep them alive rather than have them go down with their carrier, or get nuked on the ground. I'll keep it in mind though.

Barbarossa, Grace is still under active development. I'm writing in Lua and I've no real experience with Visual Studio, so I'm afraid I can't help you. Good luck though.

Lately I've been doing a lot of dull stuff to make Grace work better and the code cleaner. Perhaps one interesting thing is the code to improve fighter's performance - I think I'm about 80% of the way there:

Code: Select all


function ActivityFighterIntercept(this_task_group)
-- loop over all units in task group
-- if not already attacking and enemy within 20 then reset movement target to force re-targeting

for _, id in pairs(this_task_group["units"]) do
   local close_units=GetClosestUnits(id)
   
   if close_units[enemy_team_id]["dist"]["Sub"]<20 or close_units[enemy_team_id]["dist"]["Fighter"]<20 or close_units[enemy_team_id]["dist"]["Bomber"]<20 or close_units[enemy_team_id]["dist"]["Carrier"]<20 or close_units[enemy_team_id]["dist"]["BattleShip"]<20 then

-- avoid doing it every tick - screws up fighter movement
      if GetCurrentTargetID(id)==nil and GAME_TIME>EXTRA_UNIT_DATA[id]["time"] then
         EXTRA_UNIT_DATA[id]["time"]=GAME_TIME+5
--clear movement target to force re-targeting
         SetMovementTarget(id,UNIT_DATA[id]["longitude"],UNIT_DATA[id]["latitude"])
      end
   end

end
end



This resets a fighter's movement target whenever it doesn't have a target and there are enemies nearby. Which means that it re-targets a new enemy as soon as it kills the previous one. This still relies on the default DEFCON behaviour to pick the target, which is a bit flakey to say the least. I got very frustrated writing this - the "60210" style unit ids that GetAllUnitData() returns do not seem to be what DEFCON is using internally and you can't set an Action Target to one of them. Trying SetActionTarget(my_fighter, enemy_fighter) only sets a movement target.

I think there may a way around this by repeatedly clearing and setting a movement target until you get the action target you want, but it's a bit of a pain to implement and I decided to go with the above - for now at least.

[Ace Rimmer]

I implemented this very thing in my bot for fighters and it does wonders in mass combat. No human can compete with constantly re-targeting fighters (this is what I do in games myself).

Code: Select all

avoid doing it every tick - screws up fighter movement

I had the problem of doing it every tick though, even though I tried various things to prevent it.

One thing you might consider though, if a fighter auto-targets another fighter (for example) and there's bombers in the area, manually target the bomber (i.e. check the fighter's current target against available targets).

In most cases of naval combat where multiple unit_types are involved, a ranking should be something like:

Fighter vs Bomber: Highest
Fighter vs Carrier: High
Fighter vs Battleship: Medium
Fighter vs Fighter: Low

Now, at the beginning of the engagement, Fighter*pre-determined Number of available carriers to launch vs pre-determined number of enemy units might make Fighters vs Carrier much more important. That is, if you can spare the fighters and you encounter an enemy carrier (that isn't blocked by too many BB's), then go straight for the carrier with (swarm) fighters and ignore other units.

Edit: On a side note: watching fighters do Zero Radius Turns (R) and stopping mid-flight is pretty awesome.

[smc]

Have you improved your code to target specific units? Or are you still using the default targeting?

Fighter vs Fighter: Low

Not sure about this. While I agree that bombers and carriers are priority targets... if you don't kill his fighters, his fighters will kill your bombers and carriers. I think targeting priorities are a function of the situation and current force balance... which I think is also what you are saying in your "go for the carrier" example.

I suspect that, eventually, there will be a arms race in bot vs bot combat measured in tenths of a second response. Perhaps bots will slow the game down to give themselves more processing time, just like humans - "[BOT][Grace] Speed FFS!"

Edit: On a side note: watching fighters do Zero Radius Turns (R) and stopping mid-flight is pretty awesome.

Seriously? They limp around like three-legged dogs! I put the 5 second delay in so I wouldn't have to look at them...

[Ace Rimmer]

Have you improved your code to target specific units? Or are you still using the default targeting?

Fighter vs Fighter: Low

I haven't messed with ships/planes in a long while, but I do see some old code I wrote to set a fighter's target manually. It might not have worked though, I can't remember.

Fighter on Fighter combat is pointless with the following exceptions:

1. The enemy is attempting to scout your ground units.
2. The enemy has more fighters than your anti-fighter force can deal with (BB's severely outnumbered by enemy fighters)
3. Your bombers are not protected by BB's/Silo AA. (e.g. on a bombing run and away from your navy/close to enemy territory)
4. There are no other targets around.

In standard naval combat, fighter vs fighter is crazy stupid. If I send 12 fighters straight for one of your carriers and we have a decent ratio of units, you have two choices:

1. Defend (kill the incoming fighters while possibly retreating your ships)
2. Attack (reciprocate by sending your own swarm of fighters against me)

#2. is nearly always the best option when two equal forces meet. Then it comes down to chance + whomever has the better fleet formation/position.

#1 puts you at an immediate disadvantage because what will you do with the second swarm of incoming fighters? Or, the bombers I just had time to get airborne and/or maneuver into place because you're swatting flies?

Of course, this doesn't account for every single situation. For example, if I send a swarm at you and I lose radar on your ships and you can keep me blind, you can nullify the swarm fairly easy, This is a limited situation though.

[smc]

Okay, assuming all that is true in human vs human play, is it still true in bot vs bot play? Observing Grace against the CPU it seems that Auto Re-Targeting (ART) fighters perform perhaps 2-3 times as well against bombers as normal fighters. The ratio in fighter vs. fighter combat won't be as high because they take longer to kill another fighter (based on the chance-to-kill chart in RB's thesis - table 3.3) so they get the benefit from quick re-targeting less frequently. However, there will still be a fighter vs fighter advantage in bot combat that might change the optimum use of fighters in naval combat. We will just have to try it and see...

As an aside regarding your point 3. - I'm planning to implement anti-fighter nuking by my bombers. ART fighters are too powerful against bomber swarms otherwise.

[Ace Rimmer]

Okay, assuming all that is true in human vs human play, is it still true in bot vs bot play?

Who knows. Of course, I'm trying to program my bot to play like I would if I could micro-manage and calculate things in terms of tenths per second.

As an aside regarding your point 3. - I'm planning to implement anti-fighter nuking by my bombers. ART fighters are too powerful against bomber swarms otherwise.

Definitely. The tricky part will be determining exactly when it's acceptable to do so. Also, you'll need to be able to alter course for nuke avoidance (nukes from yourself and nukes from others).

Speaking of asides, your code up there really makes me want to get a look at proper use of the language. If my code was me trying to speak English, it would look like the chimps on 2001: A Space Odyssey.

[trickser]

Fighter on Fighter combat is pointless with the following exceptions:

3. Your bombers are not protected by BB's/Silo AA. (e.g. on a bombing run and away from your navy/close to enemy territory)

Or your carriers.

It's actually a common situation in human games. Everyone will sacrifice his battleships before carriers. When there are only carriers left, you have to kill the constantly recreated fighters with your recreated fighters to lose nothing that doesnt reappear.

This is also the reason, why I think battleships are underrated. Its more important to have a balance of all units. Or the other way around, if you can take away one unit type of your opponent, its a big advantage.

But this is maybe not the right place to discuss this.

[Ace Rimmer]

Probably not.

Question: Will Grace be able to wait for Defcon4 before placing units, and perhaps even wait till moments before Defcon3 before placing units (based on Radar intel)?

[smc]

Ace - that's the plan yes, but I'm not going to tackle deployment seriously until I get the high level strategy working.


In other news, Grace is complete to 0.4.0 and the code can be found here: http://code.google.com/p/gracedefconai/

Known issues:

1. Grace will only work with one and only one CPU enemy
2. Several functions handle the map seam incorrectly
3. Grace assumes that limited information is set
4. Units frequently get stuck on coastlines
5. This is development code, it is messy and all parts are subject to radical change
6. There is an infrequent run-time crash bug in the Airbase launching code

Please post any other comments or other issues found below.


Coming up by 0.5.0 is sub nuking, subs in combat and anti-sub patrols by carriers. Grace's high score so far is -42. I'm looking forward to her bettering that...

[Ace Rimmer]

Thanks for the code!

While I haven't had time to do any kind of digging (to see how it all functions), I have loaded Grace to see her in action and have a couple of comments (as requested.

1. Bombers should keep their distance. It appears that bombers which are sent out to fight go straight for their target. Is this because you SetActionTarget or SetMovementTarget to the enemy unit's x,y?

2. Try to avoid allowing ships to navigate to within a certain distance of each other. That is, avoid having the exact/very close x,y for more than one ship, else you'll end up with 'splash damage' (ships that die because something else dies on top of them. I haven't tried to figure out the exact radius, but 0.5 is probably close to it. Splash damage can occur when a fighter gets shot down over a surface unit (Radar, BB, CV, Sub, etc) (and a bot should be able to take advantage of this as well, e.g. send fighters to enemy radar at defcon 3 to provoke enemy AA to shoot down fighter over it's own Radar). It can happen for ships as well, CV1 gets killed by bombers and causes CV2 to be destroyed even though CV2 never took fire.

3. You have task groups, and that's great, but why not break it down even further? You ships seem to move very chaotically, and a human player would (should) be able to overcome this easily. What I mean by 'further' is have a task_group leader and other task_group units become followers mimicking the leader's movements according to the enemy.

3a. Your ships also move around in circles, which is not good. Because they are constantly adjusting course, they end up performing doughnuts. This gives the enemy a hidden advantage. Donuts are bad for you.

If you haven't watched my bot in action, you can see me trying to overcome #1 and #3 by keeping the bombers angle of attack at 90 degree of the enemy and having ships play 'follow the leader' based on proximity, current movement, ect.

Video, with naval/aerial nuking.

[smc]

Thanks Ace,

1. Yes - bombers in 0.4.0 are on default behaviour - launch and forget - this is improved in 0.4.0+ (see below).

2. I'm already doing this to some extent, though perhaps could strengthen the avoidance behaviour. The main problem though is that the travel formation has not been coded, so there is an enormous reshuffle when task groups switch from travel mode to fight mode. This is handy when you are debugging the movement routines as it gives you an large and obvious change of state to examine, but it does lead to a lot of chaos and some ship overlap.

3. I'm kind of thinking along these lines - see below (I wrote the post below on the train home this evening before reading your comment). I understand that Grace's ships not being as concentrated as a human player's would give the human an advantage, but chaotic motion as a bad thing in itself? Not sure I buy that without a supporting argument...

3a. Apart from the effect on my waistline , what's the problem? Might this even be an advantage - harder to naval nuke units in constant motion?


--


Hey all,

As the code is available I thought I'd share Grace's development philosophy:

Encode intelligence locally, maximise emergence
Running code > beautiful design
Refactor heavily, refactor often
Get to Grace 1.0 ASAP, success is defined by beating the CPU reliably and challenging intermediate human players
Learn stuff, have fun

Grace is at 0.4.5 (I'm planning to update the published code every decimal point revision, so you can't download this yet). Sub combat has been added - though as an intermediate player I'm not really sure if subs have a place mixing it up in the middle of a balls-out firefight between battleships and carriers, at least until they are empty of nukes. Still, it's nice that they know what to do if needed.

Bomber launching by carriers has also been added, with a set of rules that make the bombers orbit the carriers, staying within about 8 long-lat degrees. They land when fuel runs low, and are immediately re-launched into the orbit pattern. You can get an idea of the bomber motion from their trails. They remind me of the "squiddies" from the Matrix films...



(I'll soon be coding the rules to turn this convoy of ships into a better travelling formation.)

Even without any fighter launching (except auto-retaliation) these behaviours butcher the CPU in naval combat. As soon as CPU ships appear in radar they are attacked by the orbiting bombers, and don't often last long enough to shoot down any of the bombers or attack Grace's ships directly.



This is where I hear Ace's disembodied voice telling me "...but that will lose skirt to an experienced player", and after looking at his youtube footage (linked in his post above) of [BOT]Midnight I think I understand what he's on about. To be honest, I think he's right. However, the dynamics of unit manouver in Grace are defined by a series of rules which are chock-full of adjustable constants. It is easy to tweak these to get radically different behaviour.

To illustrate what I mean - here's a selected pic of a bomber orbiting a carrier, chosen at the moment when its range is just at the radar range of the carrier.



With the correct selection of rules it should be possible to keep the bomber here - or at least within a long-lat degree or two - permanently, oscillating back and forth around a optimum point. If you similarly tightly couple each carrier to each battleship in the task group you will get something that looks and fights a lot like [BOT]Midnight appears to. For a multi-carrier and multi-battleship line in a stand-up fight the "optimum point" would be become a "optimum line" just behind the line of carriers and the bombers would travel up and down it. But I haven't yet done the trial and error rules adjustment necessary to make it happen.

Next up is sub launching... I'm optimistic that Grace will get at least one win against the CPU by 0.5.

[Ace Rimmer]

3a. Apart from the effect on my waistline , what's the problem? Might this even be an advantage - harder to naval nuke units in constant motion?

Well no.

Against a human player, the Donut Effect (R) will be exploited because the human player will establish radar and hold the line while your ships are being singled out for execution. Your ships will lose the advantage of extra-ship support (e.g. BB's covering escaping carriers). Let's say your ships veer off just at the moment my ships come into radar and have a squadron of armed bombers in the air, that little DE (R) could send your ships just out of range of my vulnerable bombers long enough for them to empty, go naval, and start killing your ships. Plausible you say? More like probable. The point is when it happens to me it's usually at the worst possible time and causes problems.

Against my bot, the same thing would happen because even though my ships will react to yours, they do it together and only get tangled up in the DE (R) rarely. Therefore, my bot would 'hold the line' and use superior immediate numbers to kill your single ships.

Lastly, naval nuking isn't really that effective when a human does it in most cases, at least human vs human. The biggest reason to do it is to disturb movement or prevent movement, not really to kill ships. Now, versus a bot that can effectively predict impact spots and stay out of that radius as well as launch with a much better kill ratio (actually hit ships), it 'might' be helpful. Either way, slim benefit vs big disadvantage.

[smc]

So... after a slight (ahem) break Grace is under development again.

I'm currently coding sub launches, and after a strange game with 7.5m total deaths Grace got her first victory over the CPU.

Still, a win is a win