Carl von Clausewitz, in has seminal work, On War, (Book 1, Chapter 7) originated the phrase, “Friction of War”:
“Friction is the only conception which, in a general way, corresponds to that which distinguishes real war from war on paper. The military machine, the army and all belonging to it, is in fact simple; and appears, on this account, easy to manage. But let us reflect that no part of it is in one piece, that it is composed entirely of individuals, each of which keeps up its own friction in all directions.”
I knew that if General Staff: Black Powder were to be an accurate simulation, and not just ‘war on paper’, that the friction of war would have to be calculated into the command / orders chain. One part of this – the distance the couriers will travel from one headquarters to the next to deliver their orders and the time it takes to travel this distance – can be calculated with reasonable certainty (I’m using the rate of 10.5 kilometers per hour for a horseman, I’m not an expert but this seemed reasonable, and it’s easy to change if somebody has a more accurate value).
Another example of friction of war is factored into the delaying of the arrival of orders is Leadership Value:
The other value – and it is arbitrarily set – is the cost of ineptitude, incompetence, lack of motivation, and sloppy staff work. In the above scenario (Ligny) Napoleon’s Leadership is set at 93%:
I understand that Napoleon may have been feeling a bit under the weather during the Hundred Days Campaign. You can set his Leadership Value to anything you want in the Army Editor (above).
Did I set McClellan’s Leadership Value too low? He was amazingly incompetent. Note below:
The combination of McClellan’s and Ambrose Burnside’s Leadership Values results in almost a half hour delay in transmittal of the orders (remember after receipt of the orders, Burnside has to send couriers to his divisional and battery commanders, too and their Leadership Values effects the delay before their unit executes the order). After factoring the time it would take for a horseman to travel the distance between McClellan’s headquarters to Burnside’s headquarters (14 minutes) the earliest that a unit could be expected to respond to the original order from General Headquarters would be forty-one minutes later (and, in reality, a bit after that because of that unit’s Leadership Value).
I have spent some time at Antietam and studied it at length and this delay of about three-quarters of an hour between the time McClellan wanted to issue an order and the men of Burnside’s IX Corps moved out seems if anything, too optimistic of a timetable. In fact, as I write this, I think I need to increase the penalty for poor Leadership Value. McClellan and Burnside couldn’t possibly have got units moving in less than an hour.
As I have begun playtesting General Staff: Black Powder I found the delay between issuing orders and wanting to see something move now was a bit disconcerting. It shouldn’t have been. I’ve read enough military history to know that battlefield orders were often transmitted the night before and moving units around during the battle could be a risky proposition. Some armies, however, were less afflicted with these problems than others, and that I would attribute to ‘leadership value’ which also encompasses the army’s general staff.
If you don’t want to use General Staff: Black Powder as a simulation that inserts a calculated delay between orders and execution, and would rather just move units instantly, there is ‘Game Mode’:
Game Mode has the same maps but uses simpler icons and rules. I originally envisioned Game Mode as a way of introducing wargaming to a new generation (I wanted to write it for the XBox). Anyway, it’s included with General Staff: Black Powder.
Lastly, I know everybody is waiting for news about when can I get my hands on the game?!!?!! My friend, Damien, wasn’t able to work on finishing it using Unity so I’m finishing it up using MonoGame. As you can see I’m pretty far along and I think I will be playing the first ‘actual game’ (that is a simulation from start to finish) within the next couple of weeks; maybe sooner. After that, probably at least another month of fixing bugs, but then I’m hoping to set up a Beta download for all the early backers via Steam. We have a space on Steam but I haven’t even begun to build it out. Obviously, I’m just one guy, I’m working as fast as I can, but I think this is all good news. Also, I’m working on a video to show everything off.
As always, if you have any questions or comments, please feel free to contact me directly.
I was wondering when we might see some video of gameplay. Even if it’s still rough, I’m sure I’m not alone in wanting to see some features.
I just purchased screen capture and video editing software specifically to make a gameplay video. Again, I apologize, but I’ll get to it as soon as possible. I’m thinking of just making a video while I do live narration. No fancy production techniques.
One more question: Is the time couriers takes to deliver orders affected by terrain factors? Also, will enemy obstruction and interference affect the delivery of couriers’ orders?
As you can see, the A* optimal least weighted path algorithm, takes advantages of roads (which are terrain). Couriers mostly stick to roads and only cut across fields when it makes sense.
This is all fascinating, and I’ve been waiting for a wargame to seriously try to model all of this.
One question though: Not all orders were immediate “Do this now and only this” … Troops might have had standing orders or conditional orders (“Get across the river by noon unless outnumbered”) to give guidance in the absence of direct control from HQ. Can this be modeled as well?
Units also would occasionally act on their own (e.g. Sickles at Gburg) or refuse to move based on the local commander’s judgment. So what about units getting orders transmitted, receiving them in X time, and then disobeying them?
I forgot to post a screen shot that shows how you can set the time when orders are executed. I’ll add it to the blog and link to it here:
OK … still wondering this: If you’re modeling order transmission delay, I’d think you also have to model what happens with the unit while they’re waiting. They don’t just sit there, or blindly follow previous orders. (I know, sometimes they do exactly that for various reasons, but you can’t *count* on it, for good or ill.) They may react to enemy movements, try a new path of advance because of resistance, or do something absolutely insane and unpredictable.
Apologies if you’ve already addressed this elsewhere in your blog … I just discovered it, so I haven’t absorbed the whole thing yet.
Units will react to events near them. But, I don’t want them doing ‘insane and unpredictable’. That would just be very upsetting to the user.
.NET and managed languages come with their own type of friction… They can be a bit slow too.
Not to mention the learning curve. The Editors (Army, Map and Scenario) were written in .NET WPF. The actual game is C# MonoGame. The launcher (where you select scenarios, rules, etc.) is, believe it or not, WPF.
Will it be possible in the future to simulate the use of drums, bugles, or banners to command nearby troops on the battlefield? Because i think the couriers wasn’t the only way to deliver orders on the battlefield in the age of black powder.
When commanders get closer to units the time to send orders get correspondingly shorter. That’s why it’s important for the commanders to visit all the troops.