ZZZKBot is a bot (AI) for Starcraft: Broodwar. It is designed to compete against other bots. It is not designed to compete against humans. It uses BWAPI as an API for interacting with Starcraft: Broodwar. I am not intending to support/maintain/develop ZZZKBot in future, although I haven't ruled it out either.
ZZZKBot is a bot (AI) for Starcraft: Broodwar. It is designed to compete against other bots. It is not designed to compete against humans. It uses BWAPI as an API for interacting with Starcraft: Broodwar. See AIIDE2017_ENTRY.txt for more information about the (1.5.0) version that was submitted for the 2017 AIIDE Starcraft AI competition.
I am not intending to support/maintain/develop ZZZKBot in future, although I haven't ruled it out either. See BUGS.md.
In the longer term, I am more likely to start a new project than simply keep modifying the ZZZKBot project. I.E. with a different primary goal than just a Zerg bot that beats other bots in competitions. E.g. beating humans, or playing as other race(s), or a bot that can play Broodwar & SC2, or a bot with much less hand-crafted logic, or write a bot properly from the ground up. The approach I used to write ZZZKBot was to code it in the quickest possible time, at the expense of quality / attention to detail.
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.
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.
See LICENSE.txt.
See AUTHORS.md.
See BUGS.md.
See CHANGES.md.
See INSTALL.md.
See THANKS.md.
Date | Rank | Prize Pool | Winnings | Result | Event | Type | Category |
---|---|---|---|---|---|---|---|
2017-10-31 | N/A | Lost 0:1 vs Stork, won 1:0 vs two amateurs |
Sejong University showmatches (press, details) | Man-vs-Machine | Full game | ||
2017-10-09 | 1/28 | 83.11% | AIIDE2017 (details, press) | Bot-vs-Bot | Full game | ||
2017-08-24 | 1/20 | USD 1000 | USD 500 but ineligible (not a student or young professional) | 82.06% | CIG2017 (details) | Bot-vs-Bot | Full game |
2016-12-18 | 4/45 in round robin phase, quarterfinalist in elimination phase |
88% (i.e. 4th) in round robin phase, elimination phase: lost 0:2 vs Iron in Quarterfinals |
SSCAIT2016 (details) | Bot-vs-Bot | Mixed division (i.e. non students) | ||
2016-10-14 | 2/21 | 85.05% | AIIDE2016 (details) | Bot-vs-Bot | Full game | ||
2016-09-23 | 4/16 | USD 1000 | USD 0 | 53.08% (4th) in final phase, 69.18% (7th) in qualifier phase. Note: weak because outdated (submitted old AIIDE 2015 version) |
CIG2016 (details) | Bot-vs-Bot | Full game |
2016-01-30 | 4/42 | 84.44% (i.e. 4th), Elimination phase: lost 2:1 vs KillerBot in Semifinals, lost 0:2 vs Stone in Bronze match |
SSCAIT2015 (details, history) | Bot-vs-Bot | Mixed division (i.e. non students) | ||
2015-11-17 | 2/22 (or 1/22?) | 87.83% (officially announced as a statistical tie for 1st place), lost 0:2 vs Djem5 in man-vs-machine games |
AIIDE2015 (details, report, history) | Bot-vs-Bot (plus misc man-vs-machine games) | Full game |
Date | Rank | Prize Pool | Winnings | Result | Event | Type | Category |
---|---|---|---|---|---|---|---|
2015-09-02 | 1/14 | USD 1000 | USD 500 | 81.03% | CIG2015 (details, history) | Bot-vs-Bot | Full game |
Writing a Starcraft bot is a good fit for my interests in problem solving, programming, software engineering, game theory, AI and machine learning, strategy games (Starcraft in particular), and competition. It's a lot of fun, and bot-versus-bot games are often farcical.
For my competition survey answers about developing Starcraft AIs, see the text files such as competition_survey_AIIDE_2017_ZZZKBot.txt. Here are some general thoughts on the status and future progress of Starcraft AIs:
The state of Starcraft AI at the time of writing (7th November 2017) is that it is still very narrow AI, even just within the game of Starcraft. By that, I mean that Starcraft bots currently still use a non-trivial amount of hard-coded logic and list/definition of features designed by humans just to enable a machine learning (ML) algorithm to be applied effectively (as opposed to the deep learning algorithm used by DeepMind's AlphaGo Zero program), and no one ML algorithm is being used yet to perform every kind of task that a player needs to perform in Starcraft in order to be able to be able to play the full game and be successful competitively. By "tasks", I mean tasks like micromanaging individual or small groups of combat units, making more combat units and workers and buildings, deciding what the composition of your army should be, deciding what buildings to construct and where to place them, deciding what path each unit should move in, scouting to see what the enemy is doing and making use of that information, making more bases, harassing the enemy's bases, managing large battles, deciding where to attack and defend, special tactics, and decision making relating to long term strategy.
On a general note, I think it is a pity that so many bots and libraries are developed with the author's intention for it to be used by other botters as a preferred library/framework to use for basic functionality, only to end up hardly being used because others perceive it as being too difficult to call or incorporate or copy-and-paste in their bot (due to the lack of inherent modularity in BWAPI bots, and compatibility problems). Some notable exceptions are terrain libraries (BWTA then BWTA2 and BWEM are widely used) and Java wrappers (JNIBWAPI then BWMIRROR and BWAPI4J) and base bots (see an interesting family tree of some bots here). I think a few of the reasons so many people write basic functionality for other bots to use are because:
BWAPI does not force everyone to implement a interface whose runtime target (DLL or EXE or e.g. use a protobuf-like protocol for control) can definitely be run/wrapped by other bots as part of their bot out-of-the-box without ever needing to recompile it. E.g. so the authors of MegaBot could trivially have implemented a wrapper that simply dynamically calls the pre-existing DLLs for Skynet/NUSBot/Xelnaga (and many other Protoss bots) and that is all they need to do. Or if BWAPI migrates to a later version of Visual Studio that uses a different toolset version, avoid the requirement to need to recompile all bot/library source code in order for it to be compatible. Imagine how fast progress would be if everyone could easily include the runtime targets of other bots as part of their own bot (with some way of avoiding interference between sub-bots, e.g. some bots write to the same file paths unfortunately). You could train a true "Mega"/"Meta" Bot that can run all bots (including all races, and all bots regardless of whether they would otherwise have been DLL or EXE or DLL client or Java bots) and learns how to pick sub-bot according to opponent race and/or map size and/or map hash and/or starting location (and/or opponent player name if the rules allow it). The interface could also enforce some logic to sandbox sub-bots (so they can't interfere with each other) and control each sub-bot's understanding of how it is being run within another (meta) bot, e.g. expose the results of games where this sub-bot was used, and expose the results of games where other sub-bots were used - similarly to how MegaBot tracks this info.
Unfortunately, if you implement BWAPI's client-server model (BWAPI::Client class) it doesn't just implement a sub-bot - it also prevents you from wrapping the sub-bot within a (meta) bot, because it implements the logic that connects to a game and starts a game. It would be great if everyone had the ability to just produce a sub-bot. If some people want to prevent their bot from being run within other bots, personally I don't mind them being able to do that, but I suggest that by default, it should not work that way. I.E. the default/recommended way of writing a bot should be to just implement a sub-bot (i.e. similar to a BWAPI::AIModule (like a DLL, not like an EXE/JAR) or a BWAPI::Client (like a DLL, not like an EXE/JAR), but abstracted via some kind of protobuf-like interface that means it can run on a remote different operating system (i.e. programming language agnostic and operating-system agnostic and doesn't matter whether a sub-bot requires Windows XP or 7 or 8 or 10 or Linux or Mac or whatever)).
BWAPI does not allow bots or sub-bots to use earlier versions of BWAPI. BWAPI version 3.X allowed this to a certain extent, but this feature was scrapped (I don't know why). I realize that backwards-compatibility may not be a good idea for competitions (because old bots may unintentionally "cheat" by making use of game state information they shouldn't have been allowed to see) but it would be handy. I also realize that it may not be easy to enable BWAPI to start a (meta) bot that uses BWAPI 4.2.0 but may call sub-bot(s) that require BWAPI 4.1.2 / 3.7.5 / 3.7.4 etc. I'm not sure how to solve this - it may require a more disruptive design change in BWAPI to solve it unfortunately.
I like the inherent modularity of libraries like BWSAL/BWSAL2 and the approaches to modularity such as having individual managers (ProductionManager, GathererManager etc) that cooperate in a more modular fashion. Unfortunately, it wouldn't be useful unless BWAPI is changed to work more in the way I described. The more modular bots are, the easier it is to call or incorporate or copy-and-paste logic from other bots. One project I've been thinking of attempting for some time is a recommended protocol for bots/sub-bots and/or individual modules to interact, including a more sophisticated arbitration system than BWSAL/BWSAL2 (or define various policies that enable users to control what kinds of control/arbitration approaches their bot supports).
Some differences are: