John Cutter and I could just as easily have named the game Autumn Versus the Nazis. 

I’m not talking about autumn in the sense of the seasons, but rather Autumn who was John’s beautiful, tow-headed, four-year-old daughter. On almost any given day of the production, she was there with us in the office either in person, or more commonly in the form of one of the numerous metaphors we often batted back and forth as we discussed the game. For us, she was a representation of the plight of the protagonists, a kind of emotional touchstone for how we wanted players to feel while progressing through the game. Owyn was a reflection of her innocence, the boy who just wanted to learn magic. Gorath’s return to the Eledhel and his later self-sacrifice were both things that we thought Autumn would do given the same situations. By her we measured the narrative threat posed by the bad guys -- who were almost always the Nazis in our initial conversations. It would only be at the point when I got to writing things down that Nazis would transmogrify into “Nighthawks” and “Moredhel” and the various other incarnations of evil that we arrayed against our brave party of adventurers. 

But Autumn was even more than just our yardstick for the narrative of the game. She became our stand-in for the player as well, and it wasn’t uncommon for us to ask ourselves “what is Autumn expecting here?” when discussing various aspects of the design. John would go even further when he went home at night, and would often show her aspects of the interface to see how she reacted to them. The puzzle chest interface, the magic interface, moving around the world...all of them got the Autumn test first. If she wanted to grab the mouse, or she laughed, or she was otherwise engaged by what she was seeing, we felt we were on the right track. A yawn or general disinterest from her was a kiss of death. It didn’t really matter to us whether or not she understood what she was seeing, but what counted was whether or not at some instinctive level we were triggering the most primitive senses of fun. So there you have it. Absurdist as it might sound, our million-dollar game based on the license of a New York Times Bestselling author was initially designed for -- and focus tested by -- a four-year-old girl.

Junior Designer - In a picture from 2014, John with his daughter Autumn. Autumn had a lot of influence on the design of the game, even though she was only four years old at the time.

As you could see, John and I were both big believers in the power of metaphors when it came to describing player experience. We’d think of some big encounter that we wanted to happen in the game, and one of us would toss out what it should be like. Sherlock Holmes stories were favorites, and the entirety of Chapter Three’s “The Spider and the Spyglass” was envisioned as a detective story (the chapter title being a tip of the hat to “The Scorpion or the Grasshopper,” the twenty fifth chapter from Gaston Leroux’s The Phantom of the Opera.) Stories from World War I and World War II came up a lot, a product of the fact that were both interested in history, and that John had been the designer behind Wings, one of the best World War I flying games ever created. 

Our usage of metaphors as designer shorthand had grown out of a bag of tricks that John had initially picked up while working at Cinemaware, a company that was legendary for its stable of narrative games like Defender of the Crown, King of Chicago, Rocket Ranger, It Came From the Desert, and many others. John taught me that for any character / story-driven game that you develop, you should be able to reduce the core experience to a specific fantasy that has a clearly active component to it. I am a general and I command & control large armies (Command & Conquer). I am a spy and I want to sneak around enemy fortresses. (Deux Ex) I am a farmer and I build up my farm (Farmville). Everything about the game should always be informed by, reinforce, or challenge that core fantasy. 

The usefulness of the metaphor concept was such that it could also be scaled down to describe or provoke discussion of a single system or a specific encounter. I remember a long talk one morning about the biblical story of David and Goliath, and John and I’s frustration of being in D&D games when we had faced opponents with “untouchable” armor classes. The concept as a whole was preposterous, but even further, it prevented players from experiencing the joy of making the heroic one-in-a-million “impossible shot.” I invoked the “leaky shield rule” from my years of playing Starfleet Battles (a tabletop strategy game based on the Star Trek universe) which allowed some damage to always filter through the shield. Applying this same principle to BAK, we decided that it would always be possible for any adversary to be hurt, either through superior strategy and tactics on the part of the player, or just as a function of a lucky roll of the virtual dice. This in turn provoked a deeper discussion about armor, character classes, and what prevailing approach we were going to use to define what our game was. 

From the beginning, we’d always used the label “role-playing game” to describe what we were going to build, but we hadn’t explicitly lined out exactly which type of RPG we wanted to make. It would have been easy to simply clone ourselves as yet another subtly altered iteration of Dungeons & Dragons, but that came with a number of issues for us, principally concerning the typical class and level system. 

As much as possible, we wanted to keep things simple. In a typical D&D ripoff, you started up the game and were instantly bombarded with a screen full of numbers and classes and skills and races and all the usual gobbledygook that comes with those games. For John and I, this wasn’t a problem because we were both gamers, and we had lots of experience with pen and paper RPGs. Unfortunately for new players, that experience can be highly overwhelming, especially if you don’t really understand how all that accounting you do up front will translate into a fun gameplay experience. We were very cognizant of the fact that at least a fraction of our audience would be readers of Feist’s works who were picking up their very first computer game, and potentially might have limited experience with computers in general (remember that this was still at a day and age when fewer than 30% of all American homes had access to a home computer.) Whatever we did, we wanted to make sure we didn’t drive off potential players because of the complexity of the underlying system. 

Even had we ignored our concerns about game virgins, our central storytelling mechanism would have been at odds with creating a formal class and level system. From day one, our plans had always been to provide the player with a specific “pre-generated” party of characters with specific skillsets. Owyn was always going to be a magician. Gorath was always going to be a warrior. Jimmy would always be a rogue. From a narrative standpoint, their initial capabilities were tied up with their histories, and we felt that shoehorning in a class system wouldn’t serve much purpose if players weren’t going to be given the choice to create new characters. 

Of the many sage old tropes of D&D, we held on to one single idea that had its roots in traditional RPGs -- namely that wizards couldn’t touch iron or wear anything more than leather armor. Even if there wasn’t a formal wizard class, we applied this restriction to both Owyn and Patrus. This served two purposes for us. Firstly, it provided a difference in how Owyn would be played versus Gorath in combat (though my dearly loved but lunatic friend Jenn Cobb loves to play Owyn as a melee character on Twitch). Even before most games began to wrangle with the problematic issue of tankmages, we wanted each character to have a unique play style. A second problem it solved for us was a matter of the production. By limiting Owyn and Patrus to the use of staves (and by contrast keeping them out of the hands of the other protagonists), we were able to limit the variety of weapons we had to photograph for each character, which in turn helped us keep down the number of images the program had to keep in memory during combat. 

With D&D out as a guiding inspiration for our systems design, we turned to the RPG which was my favorite, which also had been born out of a love of a specific author’s works (namely, H.P. Lovecraft). Enter Chaosium’s outstanding Call of Cthulhu. 

In many ways, our goals for Betrayal at Krondor were already in line with the kind of rules that Call of Cthulhu offered. The system has no class system, but is based on the player’s choice to develop whichever set of skills they’re most interested in. New “powers” are largely developed through the acquisition of objects. Even our magical system of draining health for each spell cast was adapted from the sanity system which gives CoC its distinctive feel. I’d also had ambitions of further expanding the number of non-combat related skills for BAK as inspired by the variety offered in CoC, but the practical implementation of them would have staggered our already incredibly ambitious game. 

Setting our sights on game that would be a hybridization of a Sierra-style adventure game with the guts of a skill-based RPG, we then had a basic framework upon which to kick off production. The next trick would be pulling our team together and getting us all on the same page, assuming we didn’t kill each other first...

#BetrayalAtKrondor #RPG #Game Design #Writing #NarrativeDesign #Dynamix #Games #Raymond E. Feist #Riftwar #Chaosium #Call ofCthulhu #Cinemaware #D&D #Dungeons&Dragons #SierraOnline #StarfleetBattles #TaskforceGames #Krondor30 #BAK30