archive by month
Skip to content

the importance of bugs

Here’s a little story for anyone who doubts the importance of fixing bugs: Randomhammer’s last 4 games were all decided by bugs.

4. Versus IceBot, Randomhammer rolled terran and went vultures. The vulture attack almost broke through IceBot’s wall, but IceBot got its bunker up and managed to keep 1 marine alive long enough to get in. Randomhammer’s hard-coded switch to tanks was late and its tactics were weak, and IceBot was soon winning. The hostile tank push started, then—IceBot crashed, game to Randomhammer.

3. Oleg Ostroumov crashed at 5 SCVs, before the game was properly underway.

2. Hardcoded crashed on start.

1. Versus zerg ZurZurZur there was at least a game. Randomhammer again rolled terran and this time went for a vulture drop. ZurZurZur sent 4 hydralisks across for a poke, where they met Randomhammer’s small force of marines and vultures, whose purpose is to keep the enemy occupied out front while the drop happens in back. It worked; ZurZurZur’s forces were far out of position, and the vultures killed all but 1 drone before being cleaned up. Then Randomhammer fell into a production freeze and did not produce another unit for the rest of the game, allowing ZurZurZur to slowly recover with its 1 drone and win.

There is a sub-theme here: Crash bugs are the worst. You crash, you lose. Randomhammer could have defeated ZurZurZur on points if it had better vulture micro, even with the production freeze. (It couldn’t have won outright, though, because there were sunkens that existing forces could not have brought down.)

Steamhammer has no known crashing bugs. I went on campaign and exterminated them. Its last crashes due to fixable bugs were in April, and its last recorded crashes on SSCAIT were in May and appear to have been due to bugs in the infrastructure, not in Steamhammer. Some of the bugs I fixed are obscure and their triggers have never occurred in real games. For example, Steamhammer has never had a unit mind controlled, as far as I have seen. The normal unit validity check done on every frame should catch mind controlled squad units and workers before Steamhammer tries to send them orders—though it hasn’t been tested, so I don’t promise it’s correct. But I noticed a loophole: The scouting worker is not in a squad and is not treated like a regular worker. It is controlled directly by ScoutManager, which does not run the validity check. I left a comment in the code where I fixed it. How many years would it have been, do you suppose, before somebody mind controlled the scouting worker and brought about a crash?

Trackbacks

No Trackbacks

Comments

PurpleWaveJadien on :

I think you said it best yourself: Features don't always add Elo; bugfixes always do.

Arrak on :

Tscmoop did in fact at one point have a dark archon build which played several games against my bot. It mind controlled some units, and the AI was still trying to send orders to them, triggering an assert somewhere indicating the unit did not belong to the player. It did not crash, however, and eventually it correctly updated the unit's ownership and stopped sending commands.

Jay Scott on :

Ah, that sounds like asserts in the Micro class. When they fail, micro commands are not issued, so no illegal commands are sent to BWAPI. At least that’s the theory. Theory also says that the validity check should have caught it first, though....

Jay Scott on :

I tested mind control, and found that my flash diagnosis was right: The argument checks in Micro failed, and no commands were passed on to BWAPI. Apparently there is a window of several frames where the validity check passes but Micro’s check correctly catches it. It is a simple fix—though the main effect of the fix is to reduce silly beeping.

Antiga on :

There is a quite well known crash bug (more of a timeout) within steamhammer / UAB. It caused me to abandon SH as possible for the base of a protoss bot. Basically once supply / the game reaches the midgame the pylon placement system freaks out trying to calculate placement and uses all the resources causing the bot to drop on timeout. Spent a good 20/30 hours trying to fix it and never could.

All the SH / UAB protoss bots are affected by it which is limiting protoss under it to rush strategies only for now.

Jay Scott on :

Yes, that is not a crash bug but a problem causing the frame time limit to be exceeded. Not that the end result is any better. :-( Steamhammer has mitigations to reduce the problem, but the final solution will be a building planner.

krasi0 on :

Yeah, crashing bugs are the worst kind. Even those that crash towards the point where the bot is actually losing the game. Such bugs only waste viewers' time and bring annoyance. Bot development is not just about AI, it's also about good software engineering. A software engineer / developer that allows for crashing bugs to live undisturbed in a software product should be ashamed of themselves :P

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Form options

Submitted comments will be subject to moderation before being displayed.