The Design Philosophy of Battletech, Part 3
Last time, I talked about one of the two primary storytelling mechanics in Battletech, the event system. Today I’d like to explore the entire ecosystem of the encounter, the contract, and the mission.
When I built The Company, I envisioned the simulation portion of the game as a wrapper around an arbitrary gameplay black box. What that means is that the simulation is meant to be content-neutral. When the game hands off control to the ‘combat’ or ‘mission’ portion of play, it doesn’t know what it’s handing off to, or what will happen during that period. It just knows what values to send to the mission part of the game, and what values to expect in return.
The intent was to allow for creation of an unlimited number of games built on the same basic simulation structure. I sketched out variants that included space fleet battles, rock bands, and magical high schools. (None of these alternate games were ever created, of course; the content-creation expense of making one of these games is, like I mentioned in the previous essay, prohibitive if there isn’t a lot of interest.)
Secretly, I always hoped that the game would do well enough that I’d get to hire engineers to build out a real turn-based battle game. The Company relied on narrative and clever content design to make its mission gameplay interesting, but fundamentally it was just a block of text you read, describing a battle. I had a vision of a game that would hand off your soldiers to an isometric, Final Fantasy Tactics style battle.
When I was pitching my particular vision of what Battletech could be, that was the context of my pitch. I wanted to make a simulation wrapper around a turn-based battle game. I wanted to use this as an opportunity to create the game I’d wanted The Company to be.
So, did it work? Well… yes and no.
Maps
In addition to design principles, I brought a fair number of aesthetic impulses to the project. One of those was naturalistic terrain. I had a clear mental image of a line of massive robots cresting a hill, silhouetted against the twilight sky and the fires behind them, with their running lights picking out details of their armor in the gloom.
Map design wasn’t obvious; the source material was strictly hex-based both in terms of mechanics and aesthetics. We’d eventually return to mechanical hexes, for reasons of clarity in the player experience, but I was absolutely dead set against aesthetic hexes. I wanted that ridge-line with the mechs coming over the crest of the shoulder of a mountain. I wanted it to be organic; my mental image had them uneven in height, turned slightly to cover many angles and approaches.
(I’d been watching a lot of Shack Tactical ARMA videos around this time, and ARMA map design was absolutely on my mind when thinking about how Battletech should look and feel on the ground. There’s something deeply satisfying about watching an evolving tactical situation that’s emerging from the little details of the terrain itself.)
The conflict in creating maps, of course, is between ‘good gameplay’ and ‘attractive art’. It’s a conflict that’s rooted in tools and the divergent goals of the designers and the artists. My notion for how to solve this conflict was to address it at the tools level. Artists would create the tools, the building blocks of map design; designers would use those building blocks to assemble interesting and fun maps.
This didn’t really work as intended, and the details of why and how it fell down aren’t actually interesting, so I’m going to skip all that with the summary statement: ‘Eventually, we got to a point where our process was robust enough to allow us to create an attractive, playable map in a day or two, and to polish that map to shippable quality art in about an additional week.’
Making maps was my favorite part of building Battletech. If you’ve played it, you’ve played on my maps. Of the story maps, I created maybe a third of them; of the side mission maps, I created about half of them. And if you played that very first PvP map, the one with the river in the center, where the fight always ends up being a brutal slugfest over the water? That was the first map I ever made.
A feature I requested, and that our tools developer Chris Eck implemented, was the ability to turn on and off elements of the map at runtime. I called them Plots, and we mostly used them to create facilities in various locations around a map. Need a small base to raid or defend? Turn on a plot containing that base. This was a compromise between design wanting to be able to toggle everything at runtime, and art wanting to be able to polish the map as it would actually appear to the players. Plots gave us a limited number of variants to work with, and the art team could polish each of those variants to look like it actually fit the environment around it.
There were a lot of things left by the side of the road, though. Here’s just a few of them, and why we cut them (spoiler alert: we always cut them for time).
- Fire. There’s a design document complete with a link to a simulation for how fire should spread from one hex to another, how it should affect visibility and heat for mechs, and how to intentionally start fires. Cut for art complexity.
- Weather. I wanted weather to affect performance in a variety of ways. We achieved something related with biome effects, like lunar making it nearly impossible to vent heat, but I had also imagined things like lightning strikes and hail.
- Alien biomes. We started exploring mushroom forests and crystal plains, among other things. When I was writing the planet descriptions for the various locations in the Reach, I had a lot of strange ideas for fun places to fight over. Cloud seas, fungal drifts, deep rifts, asteroid fields… I really wanted to emphasize the SF nature of the game, and move strongly away from ‘Earth but with robots smashing it’ aesthetics. Biomes were probably the single largest art expense we had, though. Mechs and weapons and… well, really anything else was minor by comparison.
- Explorable maps. I wanted to create maps with interesting features to discover. This one was cut for a pretty straightforward reason: mechs move slow as hell, and moving your team around to find interesting hidden places was really boring. This is also why we shortcut to extraction, even in missions with an extraction zone, once you’ve accomplished all the goals and killed all the enemies. We never solved ‘make moving around fun’, and settled for ‘make moving around not intolerable’.
- Bridges. You’ll notice that at no point do we have a narrow bridge across a canyon, where you can walk under or over the bridge. This had to do with the challenge of making mechs path across the same location on two different elevations; Andy Seavy, the engineer responsible for it, was also the engineer responsible for literally everything good and fun in the world and so his time was more valuable than my dream of bridges. Still a little sad though.
Encounters
One level of abstraction up from the map is the encounter. I have a confession about encounters: I designed them almost from the ground up knowing they would suck.
I was the lead designer on a pirate-themed MMO, and one of the systems we created on that game was the ‘standard encounter’. The notion was that there was a finite number of possible scenarios in which you’d take to the sea and engage in ship-to-ship battles. You could ambush someone, or get ambushed, or get in a chase, or run a blockade, or a stand-up fight, or whatever. We made a list of those, and we implemented them. The designer could swap in different text, different actors, different spawn points and optional objectives.
The thing about this is, though, that it’s not very interesting after a dozen playthroughs. There aren’t any surprises. The battles become rote. We got a lot of complaints about that; in mostly positive reviews of the MMO, the two things people disliked were the sameness of the encounters, and the swordfighting (which is a whole other story that involves a wide cast of characters and bad decisions, all of which is too much to dig into here).
And yet, knowing that, I proposed it anyway. Trevor, a HBS designer who had also worked with me on the pirate MMO, called me out on it: ‘You’re putting standard encounters into the game.’
Guilty. But look, here’s why I was pretty sure it would work.
First, Battletech’s gameplay took place on varied and interesting environments. We’d learned that moving the spawn locations even a small amount would change the entire battle that followed, even leaving all other terrain identical. Where the clashing forces actually met was the largest influence over the experience that followed. If one side has cover or superior firing positions, if one side has forest for concealment and defense, if one side has access to water or is forced to fight on two flanks… the same map, with a fifty meter adjustment of the spawn location, can be unrecognizable.
The pirate MMO, by contrast, had water. Islands and so forth weren’t really useful as part of battle gameplay; at best, they forced you to occasionally come around through bad windage to bring your guns to bear again.
Second, the combat gameplay in Battletech was fun. There was a period, as I mentioned before, where we thought it possible we’d be shipping just the battle game and nothing else. No simulation, no mercenary company, no context. (As the sim game was my baby and my dearest love, this was a pretty dark time for me.) The work we’d been doing up to that point had been entirely focused on the battle gameplay. My directive to the team was: it should be genuinely compelling and fun to simply play a battle in our game. Everything beyond that was icing on the cake.
The pirate MMO, on the other hand, was a ship-to-ship combat game that had unreasonable focus on realism in its early DNA, before I came on board, and it was slow and it was boring. There were no moments of inherent excitement. Ship combat was about patience and long-term planning. It was more like chess, and here’s the thing about chess: if you have to play a chess game every time you get into combat in a video game, you’re going to quit in frustration.
So between exciting terrain and exciting combat, I had reasons to think that this time the standardization of encounters would work out, or at least work out better than in the pirate game. And if they weren’t great, it’s fine; they were just context for the real meat, which was punching the arms off an enemy mech.
So here’s how encounters worked. For each piece of content — like, for instance, ‘ambush convoy’ — we’d create a master encounter that contained all the logic. This logic was, for the most part, built out of C# scripts behind the scenes, organized into what we called ‘chunks’, and I’m taking full credit for making ‘chunk’ a technical term in Battletech. All master encounters lived in a testing and staging map. To make Ambush Convoy available on a real map, a designer would copy the whole thing and all its chunks over to the real map.
Every part of the encounter — the player spawns, the enemy spawns, the route the convoy would take, the convoy escape zone, the player evacuation zone, and so forth — was an object on the map that could be dragged into position. For some encounters, like ‘Defend Base’, some specially tagged buildings were required, and those were usually part of the plot system, as described above. The designer tagged the buildings appropriately so that the encounter scripts could find them.
Now the real map had a real encounter on it. In the future, any piece of content that tried to spin up an Ambush Convoy could potentially do that on this map.
What’s not present in these encounters is any kind of player-facing text, aside from the absolute minimum of labels on buildings and locations. If you played it, you’d get placeholders for everything from your briefing on landing to the notice that you’d won and could evac at your leisure.
Here’s the problem: even as streamlined as the process of putting one of these things on a map was, it was still a lot of specialized work. Only a handful of designers knew how to do it; I was not one of them. None of it was hard but all of it was skilled labor and given the same designers were also writing player-facing text, making maps, writing events, and tuning and balancing the mechs and the battles… skilled labor was in short supply.
My target had been to implement every one of the encounter types, four times each, on every map. You’d see the same Ambush Convoy encounter maybe once every 100 ambush convoys, maybe once per 1000 missions overall. We fell short of that, both because we didn’t have the time, and because it turned out that the whole modular swiss-army-knife approach to encounters had a lethal flaw:
The encounter logic ended up needing to be embedded in each map’s Unity scene.
They got big. They got really, really big. They were too big for us to work with. Our nightly builds would sometimes still be running well into the next day, and our ability to react to problems slowed to a crawl. If someone broke a build, we were likely out of action for days.
So we had fewer, and we didn’t have nearly as much weird variation, and we dropped our plans to give every encounter a dozen bits of optional surprises. For the most part, what you saw was what you got.
In the future, I’d like to build an encounter system with about a year of preproduction to really polish out the creator-facing tools. I feel like there’s a killer feature still out there waiting to be built, where procedural content and hand-crafted encounters meet and have beautiful babies.
Contracts
To make the step from an encounter to an actual mission with real content, we apply a contract to the encounter. A contract gives the player-facing details: who are the enemies? who are the allies? why are you doing this? It also includes all the in-mission pop-up dialogue. If there’s a smart-ass remark from one of your people, that remark lives in the contract. The contract can override almost any aspect of the encounter, though in practice I used very little of that vast power.
I got into trouble occasionally for using the word ‘I’ to talk about work I’d done, and I got into the reflexive habit of always saying ‘we’ even if it wasn’t appropriate. (And if you think that’s a reasonable thing to do, fuck you; we can have a conversation later about how that forces marginalized voices into silence.) In the case of contracts, though, I will always say ‘I’ because I wrote every single one of them. If it was a generic, non-story contract, I wrote it. If it was bland, it’s because I wrote a fucking lot of them.
Much like events, it turns out that writing a single contract is easy, but writing a dozen of them in a day is not, and writing 80+ of them is really really not. You can see where I was inspired and where my inspiration ran dry; the differences between, e.g., The Professional arc or The B-Team arc and, well, almost anything else… are stark.
Contracts, of all the systems I’m describing here, pretty much worked exactly like I wanted them to. I built a simple markup language to make writing them easier, more available to anyone else besides me (though in practice nobody else really ever had to use the markup language, with only a few exceptions); I wrote a parser in PHP that converted the marked-up contracts into JSON that was usable by the encounter system. Contracts had a nice simple flow to them; there was a checklist of stuff to configure, and when you’d done all the things on the checklist, you had a piece of game content, ready for testing and deployment.
I’d still change things, of course; I’m a designer. It should have been simpler for new contract authors to get up to speed. There weren’t a lot of tools for inspecting contracts we’d already created — if we wanted to avoid overlapping concepts, for example. And, as always, we didn’t have enough writers. Contracts were, from a data standpoint, cheap as hell; each one was a tiny little JSON file. The only thing stopping us from shipping 10 or 50 times as many contracts, from ensuring that you never ever saw the same one twice, was writing bandwith.
If it seems like I keep coming back to this problem in particular, it’s because it’s a pet peeve of mine, and has been for my entire time in the industry. Writers are, relative to engineers, inexpensive to hire (or contract). More writing and higher quality writing is a slam dunk for improvement to the game per dollar spent. And yet… and yet on Battletech I struggled to get even one more writer brought on board; I fought for almost a year and ultimately failed. And I just imagine what we would have shipped if we’d had a dedicated writer building contracts and events, instead of… well, me, and one of the other designers.
Missions
How do these things all fit together into a mission? We went over the process a dozen or more times, tweaking it and adjusting it, so my recollection of the specific pathway the game took to make a mission will probably be flawed. But, well. Here goes.
First, the game takes the whole deck of available contracts. Not in that deck are any contracts recently chosen; those are still in the ‘discard pile’. (This is a metaphor we used, not something that actually appears in-game.) Every contract for which the requirements are not met is set aside. That means that contracts that are part of the main story, or a flashpoint, or require a prerequisite, or have other special tag requirements, are set aside. They aren’t discarded; they’re just put to one side and will be returned to the deck when we’re done.
We look at the difficulty of the current location, and set aside any contract that doesn’t match that difficulty. ‘Difficulty’ is a weird concept in Battletech, because in contracts it doesn’t actually mean how hard the content is going to be. That’s determined by the game system, and derives from the current star system’s skull rating. In contracts, ‘difficulty’ means ‘scope of content.’ If you’re going to scare some farmers who are considering taking up piracy and banditry, that’s ‘easy’. Not because the fight is necessarily going to be trivial, but because that’s the kind of work low-tier mercenary companies do.
Later, when you’re more well-known and respected, taking contracts in some of the nastiest and most dangerous parts of the Periphery, that kind of work will be beneath you. The contract where you’re trying to stop a whole civil war via a strategic strike on the armory of the planetary militia? That’s more your speed, and would probably be ‘hard’. It’s the kind of work high-tier mercenary companies do.
Next, the game system randomly chooses a map which is both appropriate to the planet you’re orbiting — the planet’s classification will restrict which biomes can appear, so that deserts are unlikely to have oceans, or moons have jungles — and which has the encounter the chosen contract is implementing. So if the contract is a Defend Base contract, and you’re in orbit over a moon, the game will try to find a map with the Lunar biome and the Defend Base encounter. (There is always at least one such map for every biome and encounter combination.)
By combining the map, the encounter, the contract, and the difficulty of the star system, the game creates a mission.
The game then provides the contract’s player-facing bits to the mission selection screen, and Bob’s your uncle.
Many, many whiteboard diagrams were required for us to hammer out these details, and even now I have trouble holding the whole structure in my head. It was a tangled maze of corner cases, missing features, desired functionality, conflicting plans, and incompatible long-range visions. I think I burned every last bit of social capital on making this system work, and making it accessible and usable. I wanted anything I could talk people into, to be put into plain, human readable text. I wanted editing and testing the pieces to be accessible to the end user, even without a promised editor.
Back at the beginning, I said that I wanted to make games that were tools with which you could tell your own stories. The contracts and missions were a part of that, because I didn’t just want you to tell stories about the Reach, or about the Argo. I wanted you to have the tools, eventually, to tell any kind of story you wanted in this universe.
Next Time
I’m either going to talk about constructing the setting, or the combat mechanics. The former, I can speak authoritatively on because my name’s right there in the official, Catalyst-published sourcebook for the setting. The latter… I can’t, and for various reasons, which might be an interesting story itself. I guess we’ll see what feels motivating to me when I get back to this series!
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.
