On April 12 2015 23:50 FFGenerations wrote: whats the air like there? you said its overcast but is it hotter than UK, more humid, tropical air, or what? i am from UK too
It has been a little bit more humid than the UK. The weather today felt a bit like what I'm used to in summer in the UK though. I'm told it's going to get a lot more humid over the next few months. Not looking forward to that to be honest. Apparently there is a short rainy season at the end of May/start of June where its going to rain non-stop for a couple of weeks.
To be honest I quite like the rain, it makes me feel relaxed and at home. It was a bit annoying over the last couple of weeks because I wanted to do sight-seeing stuff, but I think by the time it gets to rainy season I'm going to be looking forward to some more rain.
On April 13 2015 02:38 solidbebe wrote: Really nice blog, it was a pleasure to read.
You said you wrote some AI for brood war, I would be very interested in seeing how you did that!
I might do a separate blog about it if I get back into it. Basically you use BWAPI which is an API for C++. You make an AI using C++ and compile it into a dll. You then run BW using ChaosLauncher's BWAPI injector. BWAPI interrupts BW between each in-game frame and allows your AI to pull any in-game information like unit positions and stats and things like resource counts and supplies (my one plays with fog of war on so it doesn't have an information advantage over it's opponent). Your AI can then issue a bunch of commands to its units based on the current state of the game. Once the AI has finished for that frame, the queue of commands that your AI wants to issue is passed back into BW and executed. Then 1 more frame goes by and BWAPI interrupts the game again. This means you can't have your AI doing some enormous calculations because it will really slow the game down. So as well as all the other challenges of making an AI; you have to make sure you create one that is fairly lightweight.
I entered my AI system in the AIIDE and CIG StarCraft AI tournaments last year. I came 9th out of 18 in AIIDE and 9th out of 13 in CIG if I recall correctly. Not the best results ever but it was my first attempt and I had never used BWAPI, Visual Studio or C++ before starting the project. I'm not sure if those events are running again this year but I've made a lot of changes to my AI from last year already and will enter it in some competitions again if possible.
Well my system is split into a bunch of separate managers. So I have like ArmyManager, WorkerManager, BuildingPlacer, ProductionManager etc. Every frame, each manager calls an update method where any new units are added/dead one deleted etc.
At the moment it starts the game by following a scripted build order, but its really easy for me to change this build order before a game, or change it so it does a different build for each matchup or a different build based on the map or whatever other condition. The build order is a queue of structures/units/techs that need to be created. Each frame ProductionManager reads the start of the queue and checks if we have met the conditions to create this thing (check if we have enough money and necessary tech/production etc) and if we do then production of that thing is started and removed from the queue.
After the scripted build order runs out the AI basis its future macro decisions on a set of goals that I have specified. For example it has an early game goal to get 3 hatcheries and 20 drones or something like that. If its build order queue is empty then it will compare what it currently has to the next goal that it needs to achieve. So if it only has 15 drones and 2 hatcheries then it will add 5 drones and a hatchery to the production queue. Once it meets a goal it moves on to the next goal; so the mid game one is to get another hatchery and a lair and a spire and some more drones or something like that.
It stores information about its opponent as well. So if it sees an enemy base then this location is saved so it knows where to attack later. If it sees an enemy unit then it stores that too so it knows what kind of composition its enemy has. It decides whether its going to attack or defend by comparing its own army supply against what it knows its opponent has. If it thinks it has a large enough army to attack then it does. But then if it attacks and sees the enemy army is larger than it expected it will just retreat and make more units until it thinks it can attack again. If the enemy army is getting close to its base then it will prioritise making units and static defense over making more workers or tech.
Attacking is pretty simply done at the moment and it doesn't really have any micro (except mutas). Basically when it decides it wants to attack, ArmyManager just cycles through the pointers for each army unit we have and tells them to all attack a location (probably by a base that we scouted earlier).
I've also been working on some code for muta harass but it's still a big buggy. To be honest the whole thing is pretty buggy at the moment; it's half code that I used from my bot last year and some new stuff I've added this year. As I said before I was learning C++ while working on it so some of it is a horrible mess.
My bot last year played protoss (its zerg now) so some of my descriptions above won't really match the bot that I entered in the competition. The one from last year's main focus was reactive unit compositions. So basically it would store information about its opponents units like I mentioned before, and then translate this information into a unit composition.
So if its opponent has 8 marines and 2 tanks then it will save it as 80%Terran_Marine,20%Terran_Siege_Tank. It then looked these compositions up against a table and found the closest match. The table included a bunch of enemy compositions and which protoss composition would do well against each one. It would then pull the protoss composition from the table, translate this into a set of instructions resulting in the production of that set of units.
If it decided that in order to counter its opponent it needed 30%Protoss_Dragoon,70%Protoss_Zealot then it would create a build order which made 3 dragoons and 7 zealots. It would do this by feeding the goal of 3 dragoons and 7 zealots into a build order generator. The build order generator would find a way to produce those units and then return it as a set of build order commands which could be fed into the production queue. If it didn't have the required tech for something then the build order generator would factor that in too. So if it decides it needs an observer then the build order generator would return a result including a robo facility and an observatory.
Last year I used David Churchill's build order generator from his UAlbertaBot AI. But I found it had some bugs when playing as zerg and didn't really work so I've made my own one this year. It's pretty crude and not as good as his one but it works ok for the moment.
I actually arrived in the first week of July when I went over, and after the first weekend there I decided to just not go out during the day anymore until autumn. :|
It was one of those open-the-door-and-get-hit-by-a-wall-of-suffocation types of ridiculousness. Instantly start sweating (and I don't even sweat easily).
Thankfully my dorm had air conditioning on all day and night.
EPT
