Steamhammer and bugs

I’m pleased with Steamhammer’s reliability this tournament. I watched all 88 games, and for the first time ever I saw no losses caused by crippling bugs. There were 2 games with terrible play due to bugs, but in both cases Steamhammer recovered and won anyway. There was also a bug that occasionally caused multiple drones to be sent to fail to scout the enemy: Lose one, send another, repeat. That would lose games for sure against an even opponent, but in practice it occurs in games that Steamhammer will lose no matter what. I think I know the cause, and it will be fixed soon.

I surmise that Steamhammer is especially prone to reliability problems because it aspires to do everything. It plays over 150 opening builds of all kinds; failing to adapt to all the misadventures of the opening causes a lot of snags. I count only 3 zerg abilities yet to be implemented: Nydus canals, infested terrans, and lifting off an infested command center, all on my list for coming months. (Drop is technically implemented even though not yet used by zerg. I guess overlord sight range is not implemented either, but it’s trivial if I ever want it.) More features means more bugs; fixing bugs in defiler play was a big time sink last year.

Another source of reliability hitches is my habit of swapping in new plans as fast as I can make them. A number of Steamhammer’s internal modules are half-rewritten, stuck in the middle of a transition from an old design that is not flexible enough to a new design that is not finished enough. It would be more efficient to complete one task before moving on to the next. But then I would be making progress on only one front at a time, and it wouldn’t be as much fun. I like the variety.

Anyway, after burnishing the 2.x versions for over a year, I’ve remedied almost all of the worst bugs. It is past time to get back to major features and structural work, so that I can add a new round of bugs. To symbolize that, I’ll be calling the next version 3.0 even though it doesn’t in reality have any new feature worthy of a major version number. It will in time.

Trackbacks

No Trackbacks

Comments

Dan on Wednesday, January 8. 2020:

I definitely feel reliability and flexibility as tradeoffs. Most of PW's worst bugs are in systems that are complex because they're trying to support everything, including features i never get to fully using because bugfixing comes first.

Makes me a bit nostalgic for the first release of PW where the micro was 6 lines of code and I could hack in any features I wanted.

Edmund Nelson on Sunday, January 12. 2020:

My worst headache when working on my own steamhammer fork (never released it's a buggy mess) was working on changing BOSS to something more functional. I figured I'd assign hardcoded mining rates and unit mixtures and have the AI calculate the number of gateways/ect it needed for the hardcoded unit mixture. given a spending rate per gateway of gas/minerals

This totally failed because it BOSS was also linked to so many different subsystems that everything falls apart when you try to remove it.

The golden rule of bots is that features hurt skill in the short run and may not improve it in the long run. Look at Halo vs Iron, see how long it took Hao pan to overtake Iron?

Jay Scott on Sunday, January 12. 2020:

Removing BOSS in favor of a just-in-time production goal system is a goal for the 3.x series, so....

Add Comment

Name*

Homepage

Comment*

In reply to

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