2018 IEEE CIG StarCraft AI Competition * Required Register Registration * Only submit if you agree to releasing your source code and data. Additionally, bots might be used for studying StarCraft AI. Agree Participation as entry * If you have no plans for submit to future CIG StarCraft AI Competition, we'll participate your bot in future competition as a entry. In this case, we'll announce. But there's no reward, regardless of the result. Agree Participant Information Seed Number * Please input any "Natural Number". We will use this number as Random Seed. 75520378 Entry Name * Only alphanumeric characters are allowed (no spaces or strange characters etc). Case sensitive. E.g. ExampleBot. The Entry Name will be used as your bot's in-game player name (and same case-sensitivity). Please don't include version info in this field. ZZZKBot Contact Person (First, Last) * Chris Coxe Contact Email Address * chris(dot)coxe(at)gmail(dot)com Team Members (First, Last) * For people working together as a team entry, all past and current team members must be disclosed. You must write a list of their first and last names (or full names), and mention any other individuals/labs/organizations/etc that have contributed significant changes to your source code since the date of last year’s CIG competition submission deadline (or last year’s AIIDE submission deadline if you or your team submitted any entries), e.g. git pull requests or merging changes between your repositories. Working together on versions of projects that your bot uses that were already publicly-released versions such as already released versions of Randomhammer, Steamhammer, CommandCenter, UAlbertaBot, TorchCraft, BWAPI/OpenBW-related libraries, FAP, JFAP, SparCraft, BWEB, BOSS, BWEM, BWTA, BWAPI4J, BWMIRROR is not a problem though. Chris Coxe Affiliation(s) * If you have an affiliation, you must disclose it. If you are not affiliated, write "Independent". Independent Dept/lab(s) of Affiliation(s) (if applicable) Nationality(s) Australia and Britain Occupation(s) * e.g. Undergraduate, Graduate, Postgraduate student, Researcher, Software Developer/Engineer, Hobbyist. Software Engineer/Developer CIG Cash Prize Eligibility * Refer to awarding policy at https://cilab.sejong.ac.kr/sc_competition2018/?page_id=785, i.e. Student or Young Professional or Public. Only pick Student or Young Professional if you are eligible. Public Bot URL https://chriscoxe.github.io/ZZZKBot/ Personal URL https://www.linkedin.com/in/chriscoxe Affiliation URL Bot Information Recommend to check "Rules (https://cilab.sejong.ac.kr/sc_competition2018/?cat=11)" Race * Zerg Terran Protoss Random Zerg BWAPI Version * ver 3.7.4 ver 4.1.2 ver 4.2.0 ver 4.2.0 File Type * DLL ProxyBot DLL Using File I/O * Use Non Use Use Additional information Questions come from "AIIDE StarCraft AI Competition Registration Questionnaire" How did you become interested in StarCraft AI? * I have always loved the game of Starcraft. I have been interested in Starcraft AIs ever since I first heard they existed via posts on the slashdot forum. The main post I recall was a link to an article about how the Berkeley Overmind bot won the 2010 Starcraft AI competition - at the time of writing (29th September 2017) you can see it as a series of articles now at: https://arstechnica.com/gaming/2011/01/skynet-meets-the-swarm-how-the-berkeley-overmind-won-the-2010-starcraft-ai-competition/ Writing a Starcraft bot is a good fit for my interests in problem solving, programming, software engineering, game theory, AI/ML, strategy games (Starcraft in particular), and competition. It's a lot of fun, and often farcical. How long have you been working on your bot? * Since July 2015. I usually only work on my bot just before a competition deadline... About How many lines of code is your bot? * Currently 5990 lines total (for everything including comments and blank lines etc), i.e. 5888 lines in C++ files and 102 lines in the vcxproj file. There is also some basic documentation in TXT files. Why did you choose the race of your bot? * When I started writing the bot I wrote a simple strategy that used very early aggression as all three races. I was surprised how effective the initial zerglings were, even against some existing strong bots. Since then, I've decided to stick with Zerg rather than switching to Protoss or Terran or Random. I'd like to write a Random race bot, but it would require much more development time and computational resources to properly test it. Did you use any existing projects as the basis for your bot or do you use any of them in your bot? E.g. Randomhammer, Steamhammer, CommandCenter, UAlbertaBot, TorchCraft, BWAPI/OpenBW-related libraries, FAP, JFAP, SparCraft, BWEB, BOSS, BWEM, BWTA, BWAPI4J, BWMIRROR. If you have copied other bots/projects or used IP/files/source code/logic/techniques etc from other bots/projects, you must write a list of which of them you have used/copied/wrapped/modified/etc (and which versions of them). * It's only based on BWAPI version 4.1.2's ExampleAIModule project. I still haven't got around to using any libraries (not even BWTA2/BWEM for terrain info). If you made changes to any of them (rather than simply using versions of them that had already been publicly released), write a list of which you changed, and why, and a summary of what you changed. * I modified BWAPI version 4.1.2's ExampleAIModule project to implement my bot, then subsequently upgraded to use a later version of BWAPI. What is the overall strategy/strategies of your bot? Why did you choose them? * No strategy changes since the AIIDE 2017 version. Paraphrasing my old answer from https://github.com/chriscoxe/ZZZKBot/blob/master/competition_survey_AIIDE_2017_ZZZKBot.txt: Same "Wu Wei" approach as previous versions, i.e. tailor some simple rushes (all 1-base build orders) and the number of defensive sunken colonies to some opponents based on their in-game player name. The rushes are: 4-pool, speedlings, hydras, mutas (and may decide whether to muta rush based on the enemy's race if they picked Random race), or neither. Then tech to either mutas or guardians, and all rushes eventually transition to trying guardians after enough rush units have died). After it has started teching it makes zerglings. After it eventually transitions out of guardians, it starts making other tech buildings and research/upgrades and some other unit types. However, the game has usually ended by that point, and it tends to spend all its resources on mutas and zerglings rather than other unit types like ultras, because of the kludgy way that unit types are prioritized. In addition, it also uses some special logic if the enemy is expected to forge fast expand ("FFE") or is expected to worker rush, although the logic for the latter does not work very well versus very many opponents. The reason for the simplistic overall strategy/approach is because it was only intended to be a throw-away proof of concept bot, but because it was good at winning games against other bots (and for fun), I have kept updating it for competitions. I.E. extracts: "A simple throw-away proof-of-concept cheesy kamikaze 4-pool bot implemented in a short amount of time to reach low-hanging fruit.", "Has some simple logic for scouting, targeting and resource-gathering. Apart from targeting its micro is very limited. Stays at 9 or 10 supply for several minutes of in-game time then techs straight to mutalisks or guardians (on only 1 base... soon runs out of gas...) in an attempt to finish off static defences of idle opponents, and mutalisks in an attempt to destroy lifted buildings.", "Originally implemented in a quick and dirty fashion so releases would be ready for the CIG & AIIDE 2015 Starcraft AI competitions.". There didn't seem to be much gain in adding much logic for transitioning out of the 4-pool strategy to other units because if 4-pool fails you are probably going to lose very quickly if the opponent is any good. I decided to continue kamikaze'ing zerglings to keep up the pressure in case it slowly wears down the opponent or in case the opponent makes a bad decision to transition out of their strategy. I did, however, add logic to make it transition after a frame number threshold to mutalisks then guardians in case all that is left of the enemy is static defence or lifted buildings. There is only so much you can do to improve the 4-pool strategy though, so I added a speedling build order which I hoped might be more effective against some opponents. In this strategy, it only starts sending zerglings out when the metabolic boost research finishes, then not long afterwards it transitions to mutalisks, then transitions to guardians if any mutalisks die. I also added a muta rush and a hydra rush. As I said, apart from targeting its micro is very limited - I still haven't worked on it. Combat units simply keep attacking something. I didn't get around to adding any logic to make them kite or retreat or regroup or avoid dangerous threats to themself like static defences. Do you incorporate learning of any form in your bot? If so, how was it accomplished? * Yes. Apart from three small bugfixes to the learning algorithm, there are no changes to the learning logic since the AIIDE 2017 version. Paraphrasing my old answer from https://github.com/chriscoxe/ZZZKBot/blob/master/competition_survey_AIIDE_2017_ZZZKBot.txt: Starting in the CIG 2017 version, ZZZKBot records game info to persistent file I/O via opponent-specific append-only binary (DAT) files in the read/write folders. However, the CIG 2017 version doesn't make use of this information. Starting in the AIIDE 2017 version, at the start of each game, ZZZKBot uses the number of wins and number of losses from the DAT files in some simple hard-coded logic to learn/experiment which strategy parameters to use for the current game. The scenario criteria that are considered which vary in this competition (apart from the opponent and whether they are Protoss/Terran/Zerg/Random race) from least specific to most specific are: the number of start positions in the map, the map hash, my start location. The strategy parameters that are decided are the type of rush to use (see the last question), the special flags for whether the enemy is expected to forge fast expand or worker rush, and the number of defensive sunken colonies to build (which may vary according to race if the enemy is Random race). If it won the last game in the most specific scenario that matches the current scenario, it will always use the same strategy parameters. Alternatively (i.e. if it is known to have lost the last game in the most specific scenario that matches the current scenario), if its win rate is >= 80% or it has lost 4 or less games total (i.e. in all scenarios vs that opponent & race) it will use the same strategy parameters as the lost game, otherwise it will either pick a different combination of strategy parameters that has won at least once in a less specific scenario that matches the current scenario (if the expected win rate is good enough of a randomly selected (but weighted by win rate) combination of strategy parameters, excluding the strategy parameters combo that we just lost for) otherwise it will pick a combination of strategy parameters at random according to some probability weightings I have pre-defined. Unfortunately there are bugs in this logic (in the AIIDE 2017 version) that cause learning to be unnecessarily slow vs Random race bots, and sometimes (but thankfully quite rarely) causes it to pick a combination of parameters that were not designed to be used together which cause the bot to get stuck waiting and never building a sunken colony before doing anything such as building more drones/buildings/combat units or attacking, so it becomes extremely passive and probably loses the game. Do you use any interesting AI techniques or algorithms in your bot? If so, which? * No changes to this since the AIIDE 2017 version. Paraphrasing my old answer from https://github.com/chriscoxe/ZZZKBot/blob/master/competition_survey_AIIDE_2017_ZZZKBot.txt: The only inter-game learning is the logic to pick a combination of strategy parameters based on the outcomes (i.e. binary win vs loss) from previous games - see the last answer for details. Idle workers (and workers that have just returned minerals/gas to the base and are now/still a mineral gatherer) are allocated to unallocated mineral patches near the starting base using a greedy search algorithm which is based on the best worker's total distance between the base and an unallocated mineral patch (most important) plus distance from the worker to that mineral patch (less important). When there are no more unallocated mineral patches available, any remaining idle workers are all simply allocated to the mineral patch that is closest to the base (which will probably make workers bounce around between mineral patches somewhat, although they may settle after a few trips). Most of the decisions in the bot are achieved by simple hard-coded prioritization of the various considerations involved. E.g. the decision for which enemy unit to target is simply distance-based spiral searches with a hard-coded maximum distance threshold specified (via calls to BWAPI's getBestUnit() and getClosestUnit() functions) using simple heuristics mainly based on an ordering of attributes, with units that are in mutual weapon range first, threatening enemy units next, and an ordering of the various enemy unit attributes such as isPowered(), unitType() (the ordering of the various unit types is hard-coded), an estimate of enemy unit life force (a kludge based on HP, shields, armor, defense matrix points if it is defense matrixed), then a bunch of other ordered enemy unit attributes such as whether it is constructing a building. Another example is the decision for which unit to build/train next - a simple ordering is used (i.e. a kludge mainly just the order the various unit command calls appear in the source code) with some heuristics based on what type of rush we are doing, what tech buildings we need, how many drones we have, how many drones have died, how many of the rush unit type have died. Tech transitions are mainly triggered based on how many of our units of a particular unit type have died, or in some cases a hard-coded frame count threshold. Uses randomization for strategy parameters combo selection in some cases, and also for each scouting unit's target position after all possible enemy start locations have been scouted and there are no known (landed) enemy buildings (and being more likely to select a target position that is not currently visible than a position that is already visible). For the various maps and possible start locations, I also dumped the tile positions of creep around a zerg base at the start of the game and use this data (it's now hard-coded) when scouting against a Zerg or Random race bot to help guess their start location. What do you feel are the strongest and weakest parts of your bot's overall performance? * Paraphrasing my old answer from https://github.com/chriscoxe/ZZZKBot/blob/master/competition_survey_AIIDE_2017_ZZZKBot.txt: Strengths: It's a cheesy N-trick pony. All it can do is some simple 1-base rush builds, with little or no follow-up. Its only strength lies in the fact that many existing bots are vulnerable to cheesy builds like this. It may be able to learn which type of rush is most effective. Weaknesses: apart from targeting, combat micro is almost non-existent - the only logic for combat micro is whether to wait at my base after morphing (only used in some types of rush while waiting for some tech to finish), or attack (almost all other scenarios), or defend my base (very rare). Also, it never expands. It would be useless against humans - it was not intended to be tested against humans - but it is effective against various other bots. If you competed in previous tournaments, what did you change for this year's entry? * Compared with the last publicly released version (1.7.0 on GitHub which is currently on SSCAIT), the only noteworthy changes are three small bugfixes to the learning algorithm, learn plasma map independently to the other maps, and re-added/added tailored iniital strategy parameters against some opponents. None of the underlying strategy logic has changed at all. Have you tested your bot against humans? If so, how did it go? * I haven't tested it personally, but Sejong University tested some bots including mine against http://wiki.teamliquid.net/starcraft/Stork and some amateurs in showmatches in October 2017. Mine lost 0:1 vs Stork, and won 1:0 vs the two amateurs. Links: https://www.technologyreview.com/s/609242/humans-are-still-better-than-ai-at-starcraftfor-now/ https://cilab.sejong.ac.kr/home/doku.php?id=public:starcraft_human_vs_ai Any fun or interesting stories about the development / testing of your bot? * Here's my old answer pasted from https://github.com/chriscoxe/ZZZKBot/blob/master/competition_survey_AIIDE_2017_ZZZKBot.txt: Before I started writing a competitive bot, while I was tinkering with BWAPI for the first time, I wrote a bot just for experimentation purposes. It identifies all allowed unit commands for all my units every 3 in-game seconds and issues one out of all of those commands at random. For commands that take arguments, it picked argument value(s) from among the allowed argument values at random, e.g. it only issues a build command for buildable locations. It was able to issue every possible command in the game that was allowed at that moment, including all spells and abilities. It was useless competitively of course but it was interesting to watch it on full speed playing against itself, especially if I helped it by making a few extra workers for it at the start. It would slowly build its base up (including gathering minerals, making a refinery and gathering gas), train units, research/upgrade, and have strange skirmishes with enemy units. When playing by itself, at some point it would inevitably wipe itself out by attacking its own buildings with workers or zerglings or marines or air units or whatever. On test maps where you start with lots of late-game units it was interesting to watch it cast all kinds of spells and abilities etc on its own units and enemy units, load and unload units, lift and move and land Terran buildings, nuke/storm itself, make hallucinations, mind control critters etc. Any other projects you're working on that you'd like to advertise? * Support/donations/sponsorship or perhaps even job offers (would be my dream job!) to write or help write a "proper" Broodwar or SC2 bot that actually uses some sophisticated AI/ML techniques (perhaps alongside minimal hard-coded logic?), possibly eventually using more appropriate hardware would be helpful, i.e. via https://www.paypal.me/quatari or alternatively add me in LinkedIn but be sure to mention it's about Starcraft AI otherwise I may ignore connection requests (https://au.linkedin.com/in/chriscoxe) or contact me at chris (dot) coxe (at) gmail (dot) com. So far, I've been working on my Starcraft bot sporadically just before competition deadlines just as a hobby, using simple techniques to reach low-hanging fruit against other bots, using my existing personal hardware, but I have been following the Broodwar and SC2 AI scene and papers closely and have a lot of ideas for more sophisticated (and resource-intensive...) AI/ML techniques I would like to experiment with in a bot and would love to work on something more serious/useful/ambitious in Broodwar/SC2 AI. Any other description about your AI bot It is designed to compete against other bots. It is not designed to compete against humans.