Mar: #9 Have the End in Mind…Know the Designer’s Vision and Embrace it

With now having a quarter century of military time under my belt, I’m well-versed in the notion of Commander’s Intent. In short, it’s the explanation as to why someone must do something before assigning it to them It’s fairly obvious that the more the recipient understands what’s happening, the better they can work within any constraints and without the need for constant communication. There’s a bit to unpack here before I turn my attention to a Developer’s work.

First, designers and developers find one another based on myriad factors from appreciation for their work (designer) to timeliness and efficiency (developer) and everything in-between. In this way, the Commander’s Intent is much easier to communicate as you have only two individuals invested from the beginning (or near the beginning). Second, constraints come in many forms: technical, financial, etc. It’s good to have those conversations early-on about, say, costly components, when the designer really wants to make the game as affordable as possible. Finally, don’t confuse “constant” with “regular” wrt communication. As a designer, I certainly want to check-in with my designers from time-to-time so we remain on-course. There are countless military metaphors which I can use…but I’ll refrain.

How, then, does this relate to the work of a developer? For me, it’s about embracing the designer’s vision, and moving out smartly to meet it. Does this always work…not at all, but better to find out sooner than later if it’s not a match made in proverbial heaven. I’ll share with you two vignettes that come from personal experience in the development space during the past few years. As you might have guessed, one was highly successful and one was fraught from almost its inception. Interestingly, both designers were working on titles for Compass Games. Let’s begin with the one that failed to meet the objective.

Around five years ago, after having worked on several dozen war games for Decision Games’ two publications, Strategy & Tactics and Modern War, one of the principals at Compass Games reached out and asked me if I would work with a designer who was in the throes of playtesting his new title, set during World War I. The backdrop for the story was exhilarating…the nascent Royal Air Force flying sorties against the growing threat of German Zeppelins. It was 2015, so if everything went well over the next few years, the marketing would’ve been great, as it coincided with the 100th Anniversary of the Great War.

Unfortunately, things did not start-off particularly well and spiraled out of control within about eight months. I certainly take responsibility for some of the failings, but it was clear that the designer wanted someone to playtest the game, as-is, with no questions asked. As I tell current clients in the interview stage, if you’re looking for someone to “rubber stamp” your idea, I’m not your guy. Three things caused our amicable break-up. First, the rules; second, the map; and finally, the counters. The rules, while only 32 pages, spent nearly half of its length describing the nature of zeppelins; how to operate them in different weather conditions; and the general principles governing lighter-than-air flight. While they proved comprehensive, they were not at all intuitive and the game bogged down with references to numerous charts and tables, making for an unpleasant experience. Second, the maps were dark…I don’t mean Brass Lancashire dark where it’s the height of the Industrial Revolution, I mean pitch black in some areas and slightly less black in others as the zeppelins attacked only at night. I liked the concept, but not the dark hues everywhere. Third, and finally, were the components…the counters, especially ones used for rain, mist, fog, wind, and a few others lost in my memory. Each of these had an impact on operating the zeppelin and it took a rather protracted period of time to accomplish anything. In short, we had a number of discussions (sure, call them arguments) about these key elements of the game. In the end, I enlisted the help of the publisher, Compass Games, but we remained at an impasse. The designer wanted to change nothing, which completely obviated the need for a developer.

Almost six months later, Compass Games contacted me again and this time, to work with Ernest Copley, a designer I admired from his first opus, The War: Europe 1939-1945. It’s a masterful work, which pays homage to a number of highly successful monster-war games which preceded it. We started our conversation with me asking how I can best serve in my capacity as developer and ernie (yes, he signs all of his correspondence this way) responded by stating that he wanted a Lead Developer to play test scenarios, proofread/edit all work, and be a sounding board for his ideas, as this new title, which would serve as a companion to his first hit, The War: Pacific 1941-1945 dealt with some very big issues, including the expanse of the Pacific Ocean, the difficulties associated with land-based combat with hexes nearly 100 miles across, and the use of fleets and carriers, unseen in the European Theater of Operations. During the past few years, I’ve taken leave from work to host him at my house for three-day long stretches to playtest scenarios and have spent many, many hours finessing the words of the now 125-page rule book, 32-page Examples of Play booklet, and the 40-page set of a dozen different Scenarios. Did ernie accept all of my recommendations and edits? Absolutely not. But, what he did do was share his insights and the “whys” behind his decisions.

Throughout the months ahead, one of the main themes to come through my writing is the fundamental importance of communication and how that affects the entire relationship enterprise…be that in terms of assessing a problem, communicating feedback, or simply collaborating with one another. If you’re a developer or designer, how has understanding the intent or sharing that intent with the other played out in the process?

Leave a Reply

Your email address will not be published. Required fields are marked *