Military Operations is a game of mobile warfare in World War 2 at an operational level. The word “operational” means you are not commanding a handful of platoons taking a few streets in some unnamed village during a battle that lasts a few hours, but something bigger, much bigger. Think battalions, regiments, and divisions, or even a full corps fighting a battle lasting many days over an area of thousands of square kilometers, but without abstracting the units or the terrain. Instead every unit is modeled down to the vehicle & soldier level and the battlefield is created with details as accurate as the real-world maps it is generated from.
Readers of books like Heinz Guderian’s “Panzer Leader” know that during these battles details, timing and often coincidence and luck determined the outcome. But most operational wargames available today are abstracted to such a degree that it is not possible to find a gap between 2 divisions and pierce the front by advancing up a single road or capturing a single undefended bridge and then pushing entire divisions across, leaving it up to the subordinate commanders to sort out the mess on the other side.
Let’s have a look at some examples of reality versus operational wargames. On the left, an actual German planning map of Case “Blue”, in this case the drive by 2nd & 4th Panzer Armies towards Voronezh on the Eastern Front in 1942. On the right, a hex and counters wargame depicting the same area, taken from Gary Grigsby’s War In The East.
Drawing shapes on maps is one thing, the actual fighting another. When you get down to the details, things start too look very different from the depictions above. The following shots show a German Panzer unit advancing in France 1940. Next to it a shot from another hex and counters wargame with more detail (meaning more hexes & counters), this time from John Tiller’s Panzer Campaign France ’40.
Wouldn’t it be cool if you could play the game in the same manner as the shots on the left show? Draw lines of advance on realistic maps and then seamlessly zoom in and see a column of one of your units moving along the road towards their objective in 3D. We really liked the idea so we started thinking on how to realize it.
Can it be done?
The answer to this question depends on how we wanted to approach it. So first we had to define the basics of our initial approach:
Modeling Time: Turn-based versus Real-time
The enemy does not politely wait for you to move all your units before moving his own. Timing, speed of action and sheer coincidence have a profound impact in how a specific battle plays out. This, as well as our professional experience with real-time simulation software, all pointed towards real-time as the underlying system.
Modeling Space: Discrete versus Floating point
Determining how to represent space is something every computer game has to do. Operational wargames often go for hexagons or grids, but those bring with them a host of other decisions a designer has to make that impact almost everything else. How large should a cell be? Big enough to hold an entire city or small enough to hold a single soldier? How do you translate real-life data like weapon ranges into a number of cells (if at all) and what rules do you need to introduce to avoid a-historical ways of playing the game because of the abstractions?
The creation of the map also becomes a laborious process of converting real-world maps into cells and hand-correcting things that automation cannot handle. How do you solve the fact that in your Market Garden scenario, 3 major rivers are so close, they are covered by a single hex?
Our approach is to turn it around: we start with a full planetary model and import real-world map data into it. Digital maps nowadays are very detailed: every road, most buildings and even bridges, patches of trees and fields of grain are in there. This is where our working experience in the field of navigation software comes in handy. Almost every step of this process is automated and we can select a level of detail that is “good enough” for our purpose, leaving out smaller or less important details as needed or add even more detail than available using procedural generation.
Modeling Units: Groups versus Individuals
Unit abstractions are usually tied to the spatial abstraction level. If the hexes are 50 km across, modeling units at the company level will give you huge stacks of counters. But what happens if you have no hexes? Then it is still possible to abstract units and the Command Ops Series is an example of hex-less system with units represented at the company level.
Just as with space, here we chose the opposite route and take the highest level of detail for a unit: an individual soldier or vehicle and start from there. A full-strength World War 2 panzer/armored division consisted of between 15,000 and 25,000 personnel and vehicles/guns so that gives us a starting number to work with.
After some back-of-the-envelope calculations we decided that the game engine should be able to simulate a battle between at least 2 full-strength divisions which translates into 50,000 entities. Since the focus of the game is mobile warfare in World War 2, these units would need some space to maneuver in.
Historically, divisions could advance almost 100 km in a single day after a breakthrough, so our battlefield needs to be at least 150km “long” to account for the division’s “rear area”. The end result is a squared area budget of 150 by 150 km for a minimum battlefield area of 22,500 km2.
So here we have our specs: 50,000 entities fighting in an area of 22,500 km2 in real-time. Now we can start answering the question asked earlier: Can it be done?
Comments and reactions to this blog entry can be made on our forum.Share: