The OODA Loop and the Half-Beat
I have to leave my two cents on this topic.<p>I spent a good amount of time writing situated agents in persistent worlds (aka bots for things like everquest). My experience was that the tighter the feedback loop the less the bots would get stuck in weird places. So when I first was exposed to the concept of OODA, it was very clear to me that the concept mapped very neatly to the work I&#x27;d done. All the bots I&#x27;ve written got better essentially the more frequently I applied the OODA loop.<p>You&#x27;ll also find if you read the literature on situated agents, that robots got much better much faster once scientists started building them to react to the world, as opposed to the early days where it was assumed they&#x27;d need to build these massive models of the world for the robots who would then need to spend massive amounts of CPU time trying to decide what to do next.<p>What I think the article may be missing, when it talks about half-beats, is that ideally you really want to iterate over your OODA loop as fast as possible, so that you can make <i>more</i> decisions than your opponent. The first step is often to define your Action in the smallest timestep that you can. So if your opponent thinks one step is their smallest action. You should really be trying to define the smallest action as a half step. Now you can potentially make 2 decisions in the same amount of time. Then do this for each stage of the OODA loop. Find a way to Observe faster. Find a way to Orient faster. Find a way to Decide faster (even deciding to defer deciding until the next OODA loop).<p>At the end of the day, your sample rate and your real time deadlines dictate a lot about how an agent can act. And don&#x27;t get me wrong, a good algorithm will always trump a high sample rate, but don&#x27;t underestimate just how important a high sample rate is when talking about an OODA loop.