the economics of bot development
In yesterday’s post, LetaBot commented “Pretty easy to hold as long as you pull back [hurt workers].... After all, you can outproduce the opponent.” Of course the details are more complicated than that; you have to get your workers to coordinate to some degree, at least pulling the right number to fight. But in substance, it’s true. The worker rush is not a sound strategy and can be defeated every time. Worker rush bots so far (Stone, then a LetaBot version, now PurpleTickles and Yuanheng Zhu) have found new wrinkles and scored wins against top veterans, but actively developed veterans quickly patch their defense skills and recover.
Even so, it can make sense to play a worker rush, as an option against some opponents. As PurpleWaveJadien also commented, in a round robin tournament “getting an additional win versus weaker opponents is as good as getting an additional win versus stronger opponents (and easier).” The worker rush makes sense because of the economics of bot development.
Think of it from the point of view of a new bot author. Your creation is freshly uploaded to SSCAIT and it doesn’t have many skills yet, but it does win sometimes. What should you work on next? It depends, but probably basic macro and micro skills will lift your elo rating the most. It’s a cost-benefit analysis; for a given development investment, seek the bigger benefits first. You can put effort into worker defense later, when it becomes a bottleneck skill.
Worker defense in Steamhammer (such as it is) had a bigger benefit than I expected, which means I likely put it in later than I should have. But Steamhammer was already an above-average bot by then, in the top third or quarter of the rankings. For a below-average bot, the benefit is probably small; you will lose most games to stronger opponents by being overrun with too many units because you didn’t keep up in macro, or by mismicro or misreaction due to missing skills. The basics are a better investment.
But as long as many bots are missing defense skills, other bots will exploit the missing skills. They’ll play worker rushes or whatever else is easy for them to code and more difficult, or not yet worth it, for their opponents to respond to.
As long as we have a steady stream of new bots, rushbots and other cheap exploits will make economic sense.
Comments
krasi0 on :
Of course, a major breakthrough would be able to change all that, but either I am myopic (similarly to the other bot author) or that breakthrough is somewhere far beyond the horizon.
MicroDK on :
Meanwhile, smaller breakthroughs are happening... N00byedge has developed a new combat simulator FAP (https://github.com/N00byEdge/Neohuman/blob/master/FAP.cpp) that bftjoe has already integrated into his SH zerg fork (https://github.com/bftjoe/bftjoe-bot/tree/new-combat-sim/Steamhammer/Source). And I am planning to test it this weekend. :) Rumors say that FAP is faster and handles many more unit types. Also bftjoe says it makes better decisions.
Jay Scott on :
MicroDK on :
From my short periode of testing I get the same result as with SparCraft, but it should support more units like bunker and spore. Medics are not yet supported. And in much simpler code! Dureing this weekend I will test to see if FAP is faster with many units. It should not have the 100 units limit though.
Jay Scott on :
MicroDK on :
Jay Scott on :
PurpleWaveJadien on :
Joseph Huang on :
The #ifdef part is just due to better contexpr support in VS2017 that he is using, but VS2013 needs the other code. Perhaps it gives a slight speed boost?
Joseph Huang on :
Jay Scott on :