Thread:Talk:BeepBoop/Energy Management & Firepower Selection

You know, your description of using score estimation based firepower selection, reminded me that back in 2010 I was working on a thing akin to that for some versions of Midboss. The latest version of the code I have (1s) unfortunately had to be pulled from the rumble (skipping turns), and I don't recall to what extent 1q.fast had similar fanciness, though I think it had some still...

but in any case, I never released the code to that before, and posted it here now for interest's sake: Midboss/Score-Estimation_based_Firepower_Selection

I find it interesting to compare what I built back then to what BeepBoop is doing.

It had some score estimation formulas that were pretty similar to BeepBoop's.... but what really made it slow is it performed that score estimation formula absurdly many times per tick. Rather than be content with some continuous-time estimate based on average rate of damage, it did brute force prediction of discrete future waves, all the permutations of hits/misses, for up to 30 waves into the future (though with caching to effectively re-join alike branches, since 2^30 would get silly), only performing the sort of score estimation BeepBoop does at a depth or minimum probability limit.

I'm not sure how much extra going for simulating discrete branching possibilities with discrete waves gained me, but the idea was that it this would give it some more interesting emergent 'cleverness' around the precise timing of things or amount of energy left for firing toward the very very end of the round. Boy did it chew up CPU though.

The fact that BeepBoop is using a form of score estimation in it's firepower selection, tempts me to some day go back to try to refine what I had started back then, so thanks :-)