The simulation engine driving Military Operations models every vehicle and soldier as separate entities. This means that each entity runs code for things such as sensory input, decision-making, path-finding, target selection, ammunition consumption, damage modeling and so on. Because we have to stuff everything into a fixed amount of memory and make sure the code finishes its work in a fixed amount of time, we need to introduce some abstractions.

Take ammunition supplies, for example: in reality there were many kinds of ammunition and you could not simply take a mortar round and put it into an anti-tank gun and expect it to fit, let alone work properly. We could try and take this into account and model it, but it would mean a lot of extra information to store in memory and a lot of extra code to make sure the right type of ammunition gets delivered to the right unit.

In this particular case, we decided against modelling ammunition types in full detail and instead opted for a generic “ammunition” supply type. Because supply and logistics are very important, the game does account for the weight of ammunition. If you have a supply truck carrying 1 ton of ammunition, that ton can be converted into rifle bullets or artillery shells depending on weapon type being resupplied from it. A bullet weighs just a few grams, 1 ton of them would mean thousands of bullets. Artillery shells on the other hand can weigh over 10kg a piece, so 1 ton of ammunition would just allow you to resupply 100 artillery rounds. If you want to precede your offensive by a long artillery barrage, better make sure you have enough trucks to get the required ammunition in place.

This is a typical example where realism takes a back seat over performance considerations.But sometimes it can go the other way and doing things realistically can improve performance instead.

Take the way games model combat readiness: most RTS games model this by having them at “full alert” and “ready to fire” at all times; turn-based games either don’t model it at all, or use some abstract value for “readiness” and let that have an effect on the many die rolls that decide who wins or loses. In Military Operations, having each and everyone scanning their environment for threats with their weapon at the ready requires a lot in terms of performance. This part of the code is actually one of the current “hot-spots” in the engine. But how does readiness actually work?

As part of the ongoing research effort, I happened to come across the book Fighting by Minutes by Robert R. Leonhard and in it there is this very interesting chapter called “The Anatomy of Surprise: Delaying Detection”. In it, Leonhard writes:

“To begin with, it is important to understand the most pervasive and yet frequently ignored axiom of warfare: military forces are perpetually unready for combat. That is, the natural state for a military unit— from an infantry squad to a contingency corps— is unpreparedness.”

A few paragraphs later he explains what triggers units to get prepared:

“… when, if ever, do military forces shake themselves out of unreadiness and get prepared for fighting? In other words, if forces are perpetually and naturally unready, what causes them to become prepared? The answer is simple: the detection (or anticipation) of a threat. When a threat is detected, the unit stirs itself and attempts to come to full battle readiness before the threat can harm the unit.”

Surprise, he argues, is when a unit is being attacked when not ready for combat. Causes for this could be the failure to detect an approaching enemy altogether or detecting the enemy too late to allow enough time to get ready to fight. This effect exists at all levels of warfare from the tactical to operational to strategic. Because of the scale and duration of the battles we model, some of which will last several days, a realistically modeled unit will not be at full battle readiness for the entire duration of it. The unit will also do other things like resting, sleeping, eating, maintaining its vehicles and equipment and all other kinds of non-combat related activities.

By including this behavior into the simulation we can actually improve performance by not running some code. One of the most performance-heavy pieces of code in the simulation is the sensory input simulation for each of the entities. If an entity is in combat, it needs to identify threats and targets, select which one to engage and aim and fire at it. For this the engine needs to figure out who is near who, whether are they friend or foe, are detected or not and all kinds of other checks. If this needs to be done for tens of thousands of entities every frame, we would need to abstract this system a lot in order to get the desired performance. But if we take readiness into account, we can keep it more detailed since not everyone will be in contact with the enemy at the same time. In reality, just as in the game, at every moment a large proportion of your soldiers will NOT be at full battle readiness or in combat, but they will be doing something else. A lot will be “unready”, some will be “getting ready” and others will be “getting unready” after a fight.

The fastest code is code that doesn’t need to run at all 🙂 (or, less frequent as in this case).

Comments and reactions to this blog entry can be made on our forum.