Released v3.2, a small bugfix release. Most notably this fixes the occasional Spring lockup when playing against C.R.A.I.G. on easy, and also made medium and hard a bunch easier by setting hard limits on the number of factories it will make.
Play only on the maps listed in the first post, on other maps it will play much worse!
There is a mod option to set the difficulty now, the default is medium.
The downloaded file goes into your mods folder.[/b][/size]
Supported maps ([color=red]red means not yet included in the latest game package):
Battle for PlanetXVII-v01
Comet Catcher Redux
On other maps the AI will play, but not as well as on one of these supported maps.
v3.1 -> v3.2
* Fixed spring lockup (infinite loop) when all base buildings where limited
and the base building algorithm reached end of the queue.
* New constructor syntax used in configuration. (UnitArray, UnitSet, UnitBag)
* Moved unitlimits out of buildorder.lua into it's own file: unitlimits.lua
* Default difficulty level changed to medium.
* Waypoint editor changes:
- Brush size in waypoint editor is now in world coordinates.
- Loads from LuaRules/Configs/craig/maps as fallback.
- Only need to hover over the waypoint when pressing M to delete it.
* S44: Huge nerf because of the complaints it was too hard
- Now in all difficulties all factories are limited.
- Barracks: 3 on easy, 3 on medium, 4 on hard.
- Vehicle yard: 1 on easy and medium, 2 on hard.
- Tank yard: 1 on easy, 2 on medium, 4 on hard.
- Supply depot: 1 on easy and medium, 2 on hard.
* S44: Supply depot is now used to spam halftracks.
* S44: Fixed buildorder for Russia. (now commissars can't clone themselves)
* Added waypoint profiles for:
Very cool. Kinda funny we suddenly have 3 people making AIs… of course, Tobi comes in and makes one in a half hour after the other guys spend a week… no offense.
Could definately all work together.
Just thought I’d make some suggestions of how the AI could improve. This isn’t build-orders but rather behavioural type stuff. Stuff like:
Attacking and capturing flags (IMO, we need to change flags so that they can be attacked when not held by you; as you capture them, the flag itself will become friendly and attack orders on it drop. This way, you can have a group of infantry ordered by a player to attack flags in succession; they’ll hover around the flag, not actually attacking it, until it turns; then drop the attack order and move on to the next - this could also be used for AIs).
Grouping-up units for larger attacks (ie issuing Fight orders globally for all combat uits every 3-5 minutes to give time to build up forces, rather than have auto-Fight towards enemy as soon as they’re built).
Using/being aware of ammunition state; when a vehicle runs out of ammo it withdraws it to nearest resupply unit to fill back up. Then it is sent back to attack, or waits for next attack wave.
Deploying ammunition suppliers around the map, particularly near where fighting is occuring.
Using specialist units, ie Commandos and Partisans, in special ways; building Partisan Shacks in far-away parts of the map, sending Commando teams to raid behind enemy base, etc.
Using Scouts with “Skirmisher” behaviour; stay near enemy but do not engage, move away if get too close. Same with snipers, except they can engage.
So, you decided against adapting an existing AI after all . Now I have two efforts to check out ! I guess other people just recognised the same low hanging fruit as me .
Configs where exactly the way I had wanted to go as well ! Though of course I had enough efforts just getting it working, as Zvero pointed out . How open are you to collaboration Tobi (though I’ll instantly admit what I’ve done so far is a mess) ? In relation to that, the thing I had in mind next for my “hack” AI, was to try to modularise it, I was thinking it should be possible to have the functions (or groups of functions) seperated out in such a way that you could reuse considerable parts for other Spring games - requiring at minimum the exchange of configs, but (as most have a different resource system), usually also some of the modules. Guess I should better just try putting together what I’m talking about, so people can see what I mean .
Just didn’t make anything public in the mean time, but past sunday I was already trying to get some basic framework up. Thanks for the other suggestions, saves me actually typing a TODO list
Yeah, couldn’t really be arsed to work in C++, and KAIK didn’t understand anything more about the mod after I replaced platoons with single units. Besides that I had “making somewhat big LUA project” on my TODO for a long time anyway…
I have the advantage that I know the Spring code, I actually had my IDE open all the time and checked how LUA methods worked and which arguments they expected by reading Spring’s sourcecode. (Suppose I should document what I learned from this and send it to spliff…)
Open. I’m using git for source control, I’d prefer to stay at that. I can push the repo to github.com in the weekend, if anyone wants to check it out.
I see what you mean, it’s one of the things that took me quite some time: finding out how to do object oriented (modularized) programming in LUA.
I’m not sure how much / whether you looked in my code, but if you do you’ll see that I split the AI in multiple files with reasonably clear responsibilities. There is buildsite.lua for example containing all the code for building placement, team.lua for handling of a single team, and main.lua for dispatching gadget callins to the active AI teams. In the near future I want to extract base planning from team.lua (it’s taking up the biggest part of it), and then add other “modules” like a flag capper / combat module, or whatever it will be called
Anyway, I welcome all improvements, currently in particular (improved) build orders for all sides (but these can be done by non coders of course), and am definitely open for collaboration.
If you’d like, Tobi, I’d like to give you SVN commit access. That way you can test things out without building a build, and we can test it out with you. I plugged the release you made into our SVN and Journ and I spent far too many hours last night messing around with it, modifying the build orders and adding support for Germany, and then having a few funny games of AI vs AI (Germany vs USSR was epic, eventually turned into enormous tank war as Germany built 6 Tank Yards O.o)
I think that would be practical yeah, though I think I’ll still prefer to use git for the ‘master copy’ of the AI. (Not in the least because I might very well try to let it play some other mod too sometime ) I can easily reintegrate changes made on SVN back into my local git repository, assuming you guys won’t do huge rewrites / file renames there.
Anyway as you say it would be easy with testing stuff so I don’t have to upload huge numbers of .sdz files.
My sourceforge username is tobi_v (heh, old account is old…, didn’t use it for a long while)
Configurable reusable eh ? Just up my alleyway, great! No, still haven’t looked into it I’m afraid, will do so when I’ve finished painting my roman Army.
Guess I’ll have to look into Git then - I’m on Linux, so that should be okay, but there’s no lazy/visual GUI for it, is there ? Not that I’m afraid of the command line, but a vGUI is nice at times. Edit: good of you to put it on Github!
This is already possible it seems (in SVN), but attack orders do not get dropped when the flag is captured. So it doesn’t make flag capping that much easier…
The idea I have for flag capping at this moment is to build a connectivity graph of all flags. For each flag, I’d get K nearest neighbours / all nearest neighbours within radius R and use Spring pathfinder callouts to figure out whether the flag is connected to this neighbours. (Connected being defined as: pathfinder finds a path, and pathfinder path is at most 50% longer then euclidian distance between the flags, for example.)
Then there’d be some kind of squad manager LUA that basically lets flag capping squads operate as independent agents. A squad which is near one flag would regularly check the connected neighbour flags and have some hardcoded decision rules to decide what it should do. For example, if the flag has 2 connected neighbour flags, and both are neutral, it could randomly move to either of them. If one of the flags is friendly already, however, it could decide immediately to move to the neutral flag. In the same way it could decide to engage towards enemy flags, or maybe even retreat if there are (much) more enemy flags nearby then friendly flags.
If flag capping in this way works decent, it might even be an idea to allow non-flag waypoints to be configured for a map. This might even allow the AI to intentionally attack enemy from 2 directions: squad A goes over waypoints X,Y,Z and squad B goes over waypoints X’,Y’,Z. I think the waypoints would have to be configured for each map by hand tho: I bet it’s computationally not feasible to calculate them in LUA at runtime, and also I wouldn’t know how to build anything at all which could place them in a sane way…
EDIT: or, now I actually took a look with this in mind at some maps, maybe it would be saner to skip generating this flag connectivity graph, and just make it configurable per map.
There’s already some system Flozi designed to create Flag profiles for maps so it wouldn’t be a stretch I’d imagine to do the same for AI “flag graph”. Particularly seeing as we don’t have too many maps atm specially-made for S44, and as new maps are made they can be added for support… yeah…
It’s up to you how you want to do it but it seems like a good idea to get more challenging behaviour from the AI if we can give it semi-detailed attack plans based on maps – probably perform much better (combat-wise) than any sort of sandbox AI behaviour. And if you make the framework for it “easy enough” I’m sure several of us would be able to design and impliment strategies (by easy enough I mean easy enough for us non-scripters to understand), that could take a workload off you.
v1.1 -> v1.5
* Added configurable unit limit using gadget:AllowUnitCreation callin.
- Construction vehicles are limited to one per AI team for each side.
- Advanced engineers are limited to four per AI team for each side.
* Base building improvements:
- Base builders of different types assist each other.
- Buildings in base buildorder aren't skipped anymore when units get stuck.
- Current build isn't interrupted anymore when units get stuck for a moment.
- Current build isn't interrupted anymore when builder is reclaiming features.
- Current build isn't interrupted anymore when a unit of same type dies.
- Base builders take closest buildsite, instead of random one.
- Base builders still take random buildsite if previous build was interrupted.
- Speed up building placement algorithm by bumping segmentLength up.
* It doesn't stall on Command (metal) anymore.
v1 -> v1.1
* Plays all sides now, credits to Journier for adding build orders.
I just defeated it -barely- US vs US by playing defensive and then towing a packhow to its flank and blowing up all its factories. Even if its just throwing hordes at you, its very tough - just as I was fairly comfortable with my BARs in supply range holding back the endless riflemen, a greyhound popped up, and if I hadn’t had a packhow around it would have ended me.
Attackers from unexpected directions are it’s big weak point at the moment; a lonely flanking gun did loads of damage just because the focus was straight towards my HQ.
The other bit is much harder (and surely already on your to-do list somewhere), but flag capping would make it feel must less ‘cheat-y’ because gaining flags would make a difference - in my most recent game, I owned all the flags on the map but the one next to the AI’s HQ, but I was still drowning trying to keep up with it. Perhaps it should just get a lot more resources from capping flags than a human player (or have flag capping behavior as the ‘basic’ level and then the current ridiculous hard level for the ‘so you think you’re tough’ players).