The Design Philosophy Of Battletech, Part 2

Image for post
Image for post

The Event System

In the previous essay, I talked about creating a bond between you and your pilots. There are two points of interaction between you and them: the missions, which I’ll talk about in a future essay, and the event system. Of the two, the event system was the one I cared about. It’s the one I wanted to drive most of the storytelling, and its failure hurt badly, and continues to hurt even now.

So let’s talk about what it was meant to do, and what went wrong, and what could have been done differently.

If youve played any Paradox game, you’ve seen the event system. While you’re playing, a window pops up with a piece of art, a short text description, and a choice. When you pick one of the options, you’re given some additional text describing the consequences of your choice, including any gameplay ramifications.

In general, events concern a specific person, a member of your court; if it’s Stellaris, they may involve a planet you’ve discovered or an alien species you’ve just encountered. They’re story snippets, fragments of a larger narrative. Your ruler’s spouse may be having an affair! Your heir may be tempted to do something cruel or criminal! Your scientists have gone rogue and set themselves up as gods on a primitive world!

The best events have follow-ups, picking up the narrative thread some unknown distance down the timeline. Through them, you can tell entire stories, subplots woven throughout the main story of the game, little slices of life. The small details are meant to make the characters involved feel like real people who have lives outside their handful of statistics and their performance in battle.

Events can drive game systems, as well. In The Company, I used events to force retirement, death from old age, sickness and recovery, and unlocks for some of the rare unit types, weapons, and character options.

For events to work, they need to have a few features: they need to be random, they need to be small, and they need to be story-driven.

Randomness is what creates the illusion of a world that exists beyond the confines of the game. You can’t predict when events will appear, or which ones, or in what order, or who will be targeted by them. Your playthrough will therefore be unique, with a story that no-one else has experienced. Each of your characters will have their own tale, a unique combination of events and outcomes that only they’ve been through.

For an apparently-random mix of events, though, you need to have a lot of events, and for a few reasons, we didn’t. Our event library was perhaps a tenth of what it was meant to be, and as a consequence, players were seeing the same events over and over, both across multiple playthroughs and within the same playthrough. Once a pilot had gotten the idea to improve her mech, she’d revisit that idea over and over and over until you were sick of reading it. (I’ll get to the ‘why’ in a little bit.)

Events should be small because they’re not meant to take the place of battle gameplay. That means that an event can’t escalate into a firefight; an event can’t drive the capture of a pirate vessel, or launch a deployment. The event system was meant to fill the spaces between missions, rather than take the place of the missions. An event involving Behemoth should tell you more about who she is when she’s off-duty, when she’s not in the cockpit.

As well, small events lend themselves to randomness. When there’s a bad batch of rations, or there’s a space parasite loose on the ship, it doesn’t really matter where you are or what you’re doing. Those kinds of story-snippets work as B plots regardless of the context.

Events need to be stories, primarily, and not a means to achieve some gameplay goal, so that you can feel free to choose whichever option makes the most sense to your understanding of the characters involved. One of the guiding principles of event design was that no option should be a priori wrong. You might have a preference, but there wasn’t meant to be an obviously correct choice. If you know in advance that an event can either give your pilot a bonus to piloting or a penalty to piloting, you’ll always choose the former; if we obfuscate that outcome, you’ll just reload a save and pick the other choice.

As well, all we had to work with was a few hundred words of text, a single image, and one or two characters. Your interaction with an event was always a single click; another guiding principle was ‘one event, one choice’. No events had multiple steps, branching paths, or any sort of gameplay embedded in them. This meant that any given event had to make you care entirely on the strength of the text and the story snippet. You had to want to engage with the pilots who brawled in the mess hall, or the engineer who wanted to tinker with the damaged mech, and the only tool we had to make you want to do that was the story itself.

For all that, the event system was extremely powerful. Mechanically, it worked like this: first, the game determined that an event would happen. Then, an event would be randomly chosen from all the available events that the current game state qualified for. That means that if an event requires that you be in orbit around a planet, and you’re not, we’d ignore that event. Then, having found an event, we’d select a primary target, generally a pilot, and where the event required it, a secondary target. In both cases, the event could ask for specific qualifications: high Gunnery skill, the presence of the Military tag, or any other property of a pilot.

The power of the system was embedded in the requirements: what you qualified for, what your pilots qualified for. For instance, we could create an event where you buy supplies from a shady merchant on a planet. If you do so, we add the ‘Infested’ tag to your company; this hidden tag meant that something else had come aboard in the cargo. Later, another event might require the ‘Infested’ tag be present. When chosen, that event would continue the story of that shady cargo; perhaps space slugs were now loose on your ship, or all your pilots were sickened by some mysterious ailment. The follow-up event would then unset the ‘Infested’ tag, so that other possible follow-ups would no longer be allowed. One initiating event, many possible outcomes. You wouldn’t know, if you’d already seen that event, what sort of chain of stories and outcomes might result.

Or take pilot tags: a pilot might be tagged as having a criminal past. We could involve that pilot in all sorts of criminal schemes and opportunities. We could have old rivals track her down and threaten her. We could potentially set tags in combat — if a pilot delivered the killing blow to a VIP, for instance — and then follow those tags up with events where the VIP’s relatives come hunting her, demanding recompense.

An event outcome could set a tag on a pilot, or more than one pilot, and then later events could key off that tag, reinforcing the choice you made and establishing the pilot as having a particular kind of story. Is she hotheaded? Is she a cold-blooded professional? Is she running from a dark past? Is she a former noble with unresolved obligations? Does she have contacts across the Periphery?

In early designs, we set aside dozens of events for these sorts of follow-up stories. We could have events that worked off personality traits, Successor State or Periphery origins, and other elements of a pilot’s uniqueness. We could create events for only Kuritan hotheads, for example.

In practice, we didn’t do that, or at least not to the degree we’d anticipated.

I can’t say for certain that players found the event system disappointing. Weirdly, nobody comes up to me and says ‘I loved Battletech, except for the events. They were stupid.’

But I found it disappointing, and I still do. Whenever I see someone talking about an event, I feel a pang of… guilt? Sadness at the missed opportunity? Irritation that we had all the tools we needed and still couldn’t deliver? However I characterize it (and it depends on my mood and how charitable I’m feeling), it’s a Bad Feeling.

Events, for the most part, didn’t matter. They were filler. I was okay with their status as filler, because the core gameplay was solid and it was able to keep players engaged and excited, but I wanted more. I wanted to turn pilots into people, and I fell short.

The primary cause of this shortfall was resources. We went through a period in the middle stages of development where we weren’t certain how much of the campaign game we’d be able to ship at all. We made a lot of hard choices, and one of those choices was to scale back the content for events.

The thing about choices like that is that once you’ve made them, it’s very hard to un-make them. Once your plan involves 100 events, instead of 200, you’re now allocating resources based on those 100 events. If you get more resources, you don’t expand that number; you look for critical problems and you apply more resources to those problems.

And the 100 events aren’t a problem exactly. You came to terms with the smaller number. You convinced yourself that you’re okay with it. You’ve moved on. A new hire can be tasked with something you’re not okay with. A new hire can be used to patch over holes that are threatening to sink the project. A disappointing feature is lower priority than a broken feature, or a missing feature.

I tried several times to bring additional writers on board, and every time the process stalled out as the scope or focus of the project changed. “We need more programmers” was an easily-argued case; “We need more writers” wasn’t. After all, our writers were very very good, and they could just work harder and longer, right? Content was, ultimately, fungible and divisible. You could have less of it if necessary. You could replace some content with other content. You could say: if 100 events was already a compromise position, how bad would it be to have, say, 90? What if that meant we’d get a new weapon in the game, or a new mission type, or a new map? What if it meant a feature we’d planned to cut for lack of test time could be restored?

So every special-case event was cut, with only a few exceptions. Multi-stage event chains were, for the most part, cut. Events that keyed off rare tags or character backgrounds were cut. What resources we had needed to be put into the content with maximal return: events that would be seen by the most players, that would have the most consequential game outcomes.

There was a secondary cause, though.

When I planned the event system, I had a particular kind of content in mind: little slice-of-life stories, things like a pilot teaching the crew how to make a local dish from her home, or a pilot comforting another after a loss, or a confrontation about who’s sleeping with who, or a Davion pilot getting into a heated argument with a Taurian pilot. Small stories to fill in the gaps. The kinds of things you can write a lot of.

One evening, in a late meeting, I was talking senior studio people through some of the ideas I’d been considering, and I was brought up short. “We can’t do that. Because where’s the commander in that story?”

So I explained: “The commander isn’t involved in this story. It’s just a little below-decks kind of event, something to add texture.”

“Well, who’s making the choice?”

“You are. The player. You’re making the choice of what kind of story you’d like to see happen. The event says ‘Glitch finds a puppy stowed away. Does she report it to Darius, or does she keep it?’ and you, the player, decide what kind of person Glitch is in this circumstance.”

“But the player is the commander.”

“No, the player is the player. The commander is the player’s avatar.”

And then the word came from on high: every single event had to be from the point of view of the commander. Every choice had to be the commander’s choice. The player could have no agency over the story except as expressed through her character.

This was nearly a death-blow to the event system, and I fought it for the rest of that evening. I was nearly fired over it, because I knew it was wrong and I simply could not convince the studio leads that it was wrong. This was a notion of almost religious character: the player is the commander. The player’s choices are the commander’s choices. There is no game or story agency without the commander.

(A casual examination of the battle gameplay makes this argument weak, at best, because presumably when you move Glitch into position to take a shot, it’s Glitch doing the moving, and Glitch deciding where to stand, and Glitch taking the shot… but that’s a digression into diegesis and narrative dissonance that isn’t really worth exploring here.)

So most of our event planning had to be scrapped to fit this new requirement. This wasn’t all that much lost work, honestly; a handful of events, a few guidelines that needed revision, a few meetings to establish the new direction and tone.

What we lost was the slice-of-life. We lost the notion of the ship as a community, functioning even when you’re not present. For an event to be written, we had to first answer the question: what’s the commander’s role here? Why was this brought to their attention? Who brought it up, and where? Why wasn’t this handled at a lower level of the chain of command?

Suddenly all the silly little events, the food fights and romances and rivalries and pranks and below-decks humor, were gone. Instead we had the cadence of Darius giving the commander a daily briefing, of the bridge crew bringing up their concerns, of the commander making calls from on high, away from the emotions and the lives that were tangled together in these moments.

Yeah, we scaled back our ambitions after that.

Honestly, I understand why the decision was made, and I understand the intent. But the point of disagreement, for me, has always been this: the commander is not the main character of the story. The mercenary company is the main character of the story. The people aboard the Argo are, collectively, the main character. The community is the main character.

There’s a pretty strong precedent for this kind of storytelling; it’s the heart of most Star Trek post-TOS, and is the fundamental principle of both DS9 and its long-lost twin, Babylon 5. We’d intended to mine those rich veins of storytelling for our events. In the void left by their removal, we fell back on events we knew we could execute well, quickly, and without crossing the new narrative boundary that had been set.

Regardless, the event system could have still worked. We didn’t have the manpower and a large portion of our intended content had been declared off-limits, but there was still plenty to work with.

But we didn’t. Our design team was heavily triaged, trying to fill in unanticipated gaps in our content, our missions, our lore, our maps and encounters. I stepped up to write some events… and then I had to reprioritize to write missions instead.

The lesson, the most important lesson, from the whole event system debacle: writing is hard. If you’re asked to write 200 words of interesting story-snippet, you can probably do that in an hour. Less, if you’re a frequent writer. But if you’re asked to come up with 30 different story-snippets and then write 200 words for each of them, one after the other, sustaining the same level of energy and excitement and storytelling sparkle, you’ll quickly discover that writing content does not scale linearly.

In a perfect world, even given the restriction on the kinds of stories I was allowed to tell, we’d have a team of writers rotating between missions, lore, and events, staying just long enough to make a few exciting bits of content, moving on to the next area before they could burn out.

I’ve spent a lot of time talking about my disappointment, but I want to be clear: what we shipped was good by any objective standard. The events are funny and clever, they’re filled with little character moments and drama, and they work to elevate the pilots from numbers to something more like characters — or even people.

I just wanted more, and it hurts that I couldn’t get it.

Next Time

I’ll talk about the maps, the encounters, the missions, and the contracts! The second most over-designed system in the game, this strange hybrid of procedural and hand-crafted content filled a whole region of space with content, some of which was even pretty good!

Battletech is property of Topps, Microsoft, Catalyst, HBS, Paradox, etc. I don’t own any of it, nor do I represent any of those entities. I’m only talking about my own experiences as the lead designer of the 2018 computer game.

Written by

game designer and professional trans person. i made battletech (2018). she/her. @persenche on twitter.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store