December Update

I’m back from my hiatus and working on CRustAIcean again! Say thank you to schooling breaks! In the last few weeks I’ve tackled a handful of minor issues regarding the basics of running a custom AI for BAR, as well as re-working my plan for rolling forward.

Minor Updates:

BAR Version Update

I started out by updating my code against the most recent BAR SpringRTS version, which didn’t have any major regressions as far as I could tell, so that was as simple as changing some numbers and reworking my build process slightly so future updates are easier to manage and build. Yay!

AI Installer Update

A more significant change came in the form of changing the way I load in the custom AI’s. Apparently I am just extremely unobservant because BAR has options for loading unofficial AI’s that don’t require the NullAI hack. What I had been doing is spoofing the NullAI’s identity to BAR while loading my own (and this is what the installer handled), but now the process has been updated to allow for both to exist independently, and for CRustAIcean to appear as itself in the menu. To see custom AI’s, simply:

1. Create the empty devmode.txt in the BAR data folder to enable development options as specified in the BAR README
2. Open BAR, go to the Developer Settings, and disable “Simplified AI List”

This can also be accomplished by editing Beyond-All-Reason\data\LuaMenu\Config\IGL_data.lua so that the simpleAiList setting is false. (this is what the AI installer does)

spring_ai_rs Updates

A minor change was made within spring_ai_rs’s code that allows multiple init functions for an AI, just like any other function (update, enemy_unit_created, etc.). This allows for more overall consistency in programming expectations.

A more significant change needed to occur when I realized that during a test I did downloading and installing an AI through the installer, the AI failed to run within a BAR game!!! I had not noticed this before, and it was incredibly confusing as it didn’t crash or throw any kind of noticeable error. When I built and installed the exact same AI with the exact same code from my compute it worked fine!! This took a good week to sort out, and I discovered that the MSVC-compiled version was what worked, but when compiled on linux or with MinGW then the AI would not start. Come to find out, this is because of an issue with linkme, a library I use within the ai_func macro to register it with the BAR system and reduce a significant amount of boilerplate that isn’t important to AI development. I switched over to using inventory for this job instead, and everything worked great! One the user-side nothing changed, thankfully.

CRustAIcean’s Future

So before I took my hiatus I had managed to cobble together a basic implementation of a trainer using the Burn Framework. This set of deep-learning tools is extremely well put together and has made this project actually achievable, and I am grateful to the community for answering my dumb questions quite promptly.

Initially I had been trying to emulate the modelling from kimbring2’s, attempts to remake the AlphaStar AI using a python implementation. Burn was able to do basically everything detailed in this repo, but I had definitely made mistakes somewhere because my training never resulted in any progress no matter how long I took. I tried different combinations of input and output data and different replays to train off of but couldn’t get anywhere near converging on a consistent answer. Very frustrating!!! Then school started so I took a break.

After a few months of breathing I have decided to change tactics a little bit and am splitting up the massive AI into smaller sections that can each be trained independently during the supervised training stage, and then sewed together into a single AI and trained as a single AI during the unsupervised learning stage. It would look a little something like this:

With this new plan in place I (temporarily) stripped down the input data to only this list of currently built units and the frame number, made the output the build goals for the frame (what the target number of each unit type would be) and was able to converge on an answer!!! Consistently!!! With multiple fake and real replays!!! So I think this is definitely the direction to move in. Moving forward I am planning to add a memory layer into the AI, train the AI on a larger number of replays, and then integrate the results into CRustAIcean as its build goals (instead of the random decision making it currently does). At that point I will work on the process of unsupervised training (likely an evolutionary algorithm of some sort).

You can find progress on the trainer through the CRustAIcean links at the top of the blog or by going directly to https://gitlab.com/Neek-sss/spring-ai-runner. If you are interested in contributing or borrowing ideas for your own project(s) feel free to do whatever you want with my Spring-rs or CRustAIcean-related code. It’s open source for a reason. =>