2016 and 2017
Now that the new year—wait wait wait, how did it get to be February already? Well, I’ll go ahead and ignore the mistake in the calendar. No need to file a bug report, I’m sure they’re on it.
2016 brought big progress in BWAPI bots. Killerbot by Marian Devecka finished #1 in SSCAIT 2015 with a 96% win rate in the round robin, seeming nearly unbeatable. But even after late updates, it landed #6 in the SSCAIT 2016 round robin with 85% win rate. The 5 bots that finished above it had all seen updates repeatedly during the year.
Iron brought hyperaggression and amazing micro. Krasi0 fixed crashes and weaknesses and became more aggressive. Sudden sensation Bereaver put together a variety of skills in a balanced package to reach the top ranks. ZerGreenBot showed us the first skilled overlord hunting and the first skilled reaver drops, both of which were then picked up by Bereaver and Tscmoo protoss. Zia gave a taste of zerg variety with opening learning. Even ZZZKBot by Chris Coxe, less heavily updated than the others, proved that it is still possible to beat many opponents with prepared strategies. Overall, the meta shifted somewhat away from rush strategies toward macro play, though rush defenses need to be strengthened further before the shift will be complete.
In 2017 I see progress speeding up further. The community is larger and more active. I see people in the chat talking about their plans for new skills. Openbw is preparing new tools. Bots are playing an ever-wider range of strategies. The level of play is higher, and bot authors are adapting to it in a virtuous cycle of improvement. 2016’s top Krasi0 and Iron are updated, and so is Tyr by Simon Prins. Many of the fresh bots popping up during the post-SSCAIT surge are starting out stronger than new bots did last year (except for Bereaver, of course). I think both AILien and my own Steamhammer are at risk of becoming top bots and having to work to stay there, and the new from-scratch bots like McRave and ZurZurZur are improving rapidly and may catch up.
Even today’s entrant “Newbie Zergrush” is causing trouble for one opponent after another with its simple nonstandard opening of 8 hatch 7 pool (at least against protoss and terran; it played differently in its one game vs zerg so far). That rush gets zerglings over a minute later than 4 pool, but with 2 hatcheries the numbers grow fast and it seems that many bots were caught sleepy-eyed. XIMP did not add cannons or send defenders in time, and Krasi0 was surprised by the timing too. Steamhammer, by the way, knows a similar opening of 9 hatch 9 pool 9 gas, which gets the first lings 2 seconds later (seriously!) and also researches speed and boots up a stronger economy with greater chances to transition later. Steamhammer only plays it versus zerg, though. Now I’m thinking I should have enabled it versus protoss and terran too.
In 2017 I predict multiple bots with new skills of taking island expansions and carrying out doom drops. For Steamhammer I also plan deeper map analysis so it can do things like backdoor attacks when the map allows it. The tactics and strategy in bot play will grow more complex, and everybody will be scrambling to keep up.
Trackbacks
No Trackbacks
Comments
Jay Scott on :
toriak on :
Jay Scott on :
AIL on :
It is one thing to lose against the huge established Bots with massive effort put into them like it is the case for Leta, Iron or Krasi0.
But losing to a Stock-UAB with a new, gimmicky build, really triggered that: "This cannot be, I must defeat him!"-mentality in me.
And it shows the shortcomings in UAB, when it comes to defending.
I told it to open pool first, I told it to scout early, I told it to put up sunkens, when it sees the lings incoming and I told it to not try and expand under those circumstances.
Now the problem is to get it to not mess up the unit-controls.
Per Default UAB does not know how to regroup when the Squad is assigned to defending. And just changing that does not produce the right results for all scenarios. Whatever I did, there's always something wrong.
And it's not even a single issue, it's a bunch of them combined.
SparCraft gets fed by units near "closestToEnemy" but by default that's "closest to Squadorder.getPosition()", doesn't really work well with defending.
The next question is: What to do when the units have already gathered at the Defense-Location and still think they are gonna lose?
Want to know what happens? Watch the latest Ailien vs. krasi0 game. They just sit there and let themselves be killed by units that outrange them. Would have been a thousand times better to just engage in an probably unfavourable fight in the middle of the map and then rely on faster reproduction-rates. A simple A-Move of the Ultra-Muta-Ling-Comp could have achieved so much more than backing-up till there was no where else to back up to.
So I tried to mess with that and this made the units suicidal against NZR, where staying at the sunken and only attack units that come into it's range would have been the right thing to do.
SparCraft is great when it comes to determining the outcome of small clashes like 4 zealots vs. 12 lings.
But when it comes to bigger decisions, you need more than that. Avoiding a confrontation to do damage elsewhere often is what should have been done instead. Or fighting a slightly lost fight anyways but recover faster.
Macro, Micro, everything in vain, if the decision-making about where to send the units is not on par.
I think I need to conceptualize and realize a completely new approach to handling my units, when I want to compete on level that exceed the UAB-shuffle.
Jay Scott on :
AIL on :
Now the drone-defense is handled directly by the worker-manager and the drones don't change their state there.
The good thing is, that they are now behaving Stone-prove by doing the following:
Only attack non-moving targets that are within 50 radius and go back to work immediately if target begins to move. Stone likes to micro and try to lure out drones from the defense.
Well, no luck for you Stone!
The other thing I do is to put up a pool asap when any unit is near my base. Including SCVs.
So in my test-games against Stone I lost only 1-2 SCVs before I had Zerglings out, that just mopped up the SCVs.
The not quite fortunate side-effect is that the pool is also put up against anyone else who just happens to scout my base. But on the other hand: If they planned to go macro heavy, they now need to worry about the early lings.
I also found the bug that caused my whole Idea against NZR not to work. I basically just forgot an else, which made code always run, that should only be run, when no enemy was known.
Winrate against it is not at 100% yet because there's some other bugs. One of those involves building-workers being killed after the fix that caused the multitude of same buildings. Also there's a small chance my scouting-worker doesn't see the early lings and then it's also doomed.
Have not been able to really tackle the issue of being outranged when defending near a sunken.
What is kinda interesting is that one of my main-feature of randomized openings is more and more watered down by the reactive play to the different kinds of rushes. So the randomness kinda only applies for as long as neither I nor my opponent have scouted each other.
Oh, and NZR now also has a 1-base-muta-build with 7 or 8 sunkens. I might need to implement Spore-Colony logic in order to deal with that.
Jay Scott on :
krasi0 on :
A more general approach would be (given that DChurchill hasn't updated UAB since Aug 23, 2016) that you two (AIL and J Scott) should team up, create an UAB fork on Github and clear up all of the remaining issues there, so that newcomers could benefit from your mutual advance and the tons of work done during the last few months. The current statistics are of more than 50% of the bots playing on SSCAIT right now being UAB based bots, so you can imagine what an impact such an endeavour would have.
Jay Scott on :
krasi0 on :
Jay Scott on :
Jay Scott on :
AIL on :
The whole macro-code with all the conditional things tucked into, for example, is fundamentally different from UABs opening-book-approach.
A lot of stuff in other places is intertwined with that.
Of course there's also a lot of parts which could be put back into UAB-base.
Worker-Micro, Overlord-Scouting including Overlord avoidance-micro, Targetting-Priority-Changes, and maybe strategic targetting too.
Then there's a lot of stuff where it's questionable whether changes I made are an improvement or not.
The way I distribute workers to get a more equalized saturation for example, which so horribly failed in one of the games against NZR, constantly sending drones to the besieged expansion.
I also think that catering to potential forks requires a lot more care about the things I try and would slow down my progression tremendously.
Jay seems to be making well-thought out and planned changes keeping the code well-readable and structured. I don't really plan much and even if I do, I let myself sidetrack by other things that suddenly change my priorities.
Most of the time it's like this: I see AILien do something stupid in a game, and I want to fix it immediately. Sometimes it's easy, sometimes it's not and oftentimes my "fixes" produce side-effects, that lead to other problems.
My bigger long-term plans, which are not really well-thought-out in the first place, are being pushed back.
That being said, I surely can send Jay my code-base from time to time to sift through for useful feats but I don't plan to implement my changes in a way to make them a solid and well-structured enough base that would make for a good starting-point to fork from.
krasi0 on :
Overall, I'd say that Killerbot by Marian D. has been mostly a disappointment given the former expectations.
Additionally, I anticipate a long and bloody battle for dominance throughout the year between Igor's Iron and my bot while having to deflect the brutal pounces by the hordes of other mid and high tier bots. Not to forget the nasty surprises by the likes of Newbie Rush X who aim for a bite of flesh, too.
GG! GL & HF! :)