Difference between revisions of "Thread:Talk:BeepBoop/Energy Management & Firepower Selection"

From Robowiki
Jump to navigation Jump to search
m (reword)
m (reword)
Line 1: Line 1:
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...
+
You know, your description of using score estimation based firepower selection, reminded me that back in 2010-2011 I was working on a thing akin to that for [[Midboss]]. I'd commented on it some I'm sure, but don't think I ever described it in great deal, nor shared the code. I find it interesting to compare what I built back then to what BeepBoop is doing.
  
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]]
+
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 one key difference made is far far slower. 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.
 
 
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.
 
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 :-)
 
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 :-)

Revision as of 11:14, 23 June 2021

You know, your description of using score estimation based firepower selection, reminded me that back in 2010-2011 I was working on a thing akin to that for Midboss. I'd commented on it some I'm sure, but don't think I ever described it in great deal, nor shared the code. I find it interesting to compare what I built back then to what BeepBoop is doing.

Posted it here now for interest's sake: Midboss/Score-Estimation_based_Firepower_Selection

It had some score estimation formulas that were pretty similar to BeepBoop's.... but one key difference made is far far slower. 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 :-)