So yeah, this is the 2nd blogpost I've ever written. Technically it was the first, but I forgot about it in the first few weeks of the new kid, and just now realized it was sitting here. Waiting to be posted, so why not.
Given the free time I have, it may well be the last, but I often have snatches of time between new child feedings and more often than not I find myself thinking about things I want to commit to writing and then don't.
So I've been reading several books about warfighting, which is kinda comical given my occupation as a guy with soft hands who types instead of pulling a trigger. But when you make games, you want to at least steep yourself in as much of the information as you can. It helps you. It inspires you. It can depress you. Mostly, it orients you.
Anyway I was struck by a lot of the parallels between "new" principles in warfighting and the "new" methods and processes we're using to make games. I think we could - and in many cases are- already doing things this way in game development. But there's a lot to learn!
The old way of waging war was pretty straightforward. You had soldiers. You lined these dudes up and hopefully the weight of numbers and technology fell on your side. You would attrit the enemy down to what became an unsustainable loss position and he'd either retreat, surrender, or be wiped out. It's not to say that tactics and strategy had no place in this type of warfighting. They simply were aligned to a certain kind of leadership and a certain kind of expectation in battle. Symmetrical forces clashing.
Coupled with this old methodology was a very rigid chain of command, which led to operational inefficiencies and bottlenecks, where people often would wait on other, more senior officers words to act.
Why am I even talking about this? Why am I not talking about design?
Well.. we are talking about design. We're talking about some companies I used to work for, companies friends used to work for.. that were hierarchy driven, centralized, slowmoving. Where people would wait for their boss to give them the green light. Where shit could not move ahead unless the big guy gave the thumbs up. Where people had limited if any operational autonomy.
So this is where it gets interesting to me. Maneuver warfare is about decentralizing leadership in order to allow those closest to the battle to operational autonomy to the troops so that they can make tactical decisions themselves instead of waiting on some General in his airconditioned hangar to pass them the word. In the modern day battleground of asymmetrical warfare and instant communication and urbanized regions, the ability to act quickly, decisively, and flexibly has become much more important.
The principles of maneuver warfare are fascinating to me. They sound like design principles. They also sound like agile development.
Speed. Concentration. Tempo. Surprise. Momentum. And the ubiquitous enemy of all these things is Friction, which can be loosely summarized as the collection of all things that conspire to fuck up an offensive: enemy fire, location, weather, sickness, supply, etc.
So what am I to do with all this? So what if game dev and maneuver warfare are similar? Is that going to make my games magically better?
To Be Continued
