KickStarter BATTLETECH - turn-based mech combat from Harebrained Schemes

[razvedchiki]

not sure, roguetechs nexus page doesnt contain a proper changelong for some good reason im certain.

 

[rashiakas]

last time I played RT it had no limit, but you paid dropship cost per ton.

 

[thesheeep]

last time I played RT it had no limit, but you paid dropship cost per ton.

So in order to be profitable, you'd kind of have a money limit, which translates to a tonnage limit?
One step too complex, IMO, but it sounds like it would work.

 

[rashiakas]

Well in fact its better then the tonnage limit, because intel isnt always accurate as well, sometimes it pays off to bring more tons if the mission sounds like it might be harder then the intel suggests.

 

[Shadowfang]

Hey guys, i didn't finish Battletech because i couldn't stomach the boring and cringy storyline and the gameplay wasn't strong enough to make me endure it.
Are there now any new updates or mods that would allow me a story free playthrough in a sandbox kind of way?

Everytime i see it on my shelf i feel regret and i wish to change that.

 

[DeepOcean]

Hey guys, i didn't finish Battletech because i couldn't stomach the boring and cringy storyline and the gameplay wasn't strong enough to make me endure it.
Are there now any new updates or mods that would allow me a story free playthrough in a sandbox kind of way?

Everytime i see it on my shelf i feel regret and i wish to change that.

Rogue Tech, with it, feels like a complete sandbox Battletech game, HOWEVER, the shitty barebones mechanics and awful performance cant be fully fixed. It fixed many of the issues of the game and expanded the content alot but as I said, it isnt a magic bullet and you need to fiddle with the difficulty options as it is an unbalanced mod because of the amount of content added. There are other mods people recommend like Battletech commander, advanced or extended but I didnt test them.

 

[Cael]

A polished turd is still something I won't want to touch.

 

[udm]

So I heard from Roguey in the CP2077 thread that Kiva is no longer with HBS. What's the scoop on that?

 

[Agesilaus]

If you want to play robo pokemon in a colourless gameworld, I would recommend Battletech Advanced 3062. I find it entertaining, although it gets tiresome. The game engine sucks, but it's not like there's a lot of competition for turn-based battletech; just appreciate the mods and go blow up some robots so you can build new ones with the salvage.

 

[Roguey]

So I heard from Roguey in the CP2077 thread that Kiva is no longer with HBS. What's the scoop on that?

https://rpgcodex.net/forums/threads...arebrained-schemes.122265/page-6#post-6869662

I searched kiva's tweets from September-November 2019 and didn't see any official announcement about leaving, so it was a layoff/firing.

 

[udm]

https://rpgcodex.net/forums/threads...arebrained-schemes.122265/page-6#post-6869662

I searched kiva's tweets from September-November 2019 and didn't see any official announcement about leaving, so it was a layoff/firing.

Good to hear about Kevin, but shame about the overall change at HBS. I did think they were doing great with Dragonfall and would have liked to see more from them.

 

[almondblight]

I always wonder if Dragonfall's success was because it was a smaller team of talented people who had leeway on what was originally planned to be a small project (which is why they would have put their art director in charge of it). It was originally a short DLC that was going to be released 3 months after Returns, but they decided to put more work into it after the negative feedback that Returns got.

The other two Shadowrun games had more people working on them and the leadership of HBS was more involved, but they turned out worse.

 

[lightbane]

No idea about Hong Kong, but supposedly even the worse Shadowrun game is better than this, which is not that hard to believe.

 

[Infinitron]

Hmmm, last month Mr. Kiva wrote a three part series of articles about the making of BattleTech: https://persenche.medium.com/the-design-philosophy-of-battletech-b17163718905

The Design Philosophy of Battletech

I do a lot of my design work by gut. I intuitively grasp whether something is going to be fun or not; whether something is a good idea or not; whether something is going to be worth the time to develop or not.

In the moment, I can’t explain why something feels right or not, but that doesn’t mean there isn’t a lot of thought and analysis behind each design decision. I’ve just done that analysis well in advance, building a kind of foundation of good design practice, experience of game systems and mechanics, and conversations about what is and isn’t fun.

So it’s often not until well after the fact that I’m able to articulate the reasons for some of my ideas. This is frustrating for me, because it makes it hard to argue for what I know to be the right answer to a problem, and frustrating for the people I work with, who want more to go on than ‘Kiva feels it really strongly’.

I’m far enough away from both Battletech and my frustrations and anger about it that I think I can start to explain why some of the things in the game are the way they are.

The First Principle: A Game About People
I didn’t want to make a game about robots. Frankly, the Battletech IP was my least favorite part of the project, and I nearly turned down the job because of it. Robots don’t interest me, people do.

I gave a talk many years ago at a game conference about whether games are art. My conclusion was that they aren’t art, but they could be. The reasoning isn’t really important here, but the central thesis is: games become a distinct art form when they learn to leverage their unique properties, those elements that make them distinct from paintings or movies or novels or television. The art form of games is interactive experiences.

So when I make games, I’m not looking to tell you a story. That’s better done in other media. I’m not looking to show you a cool movie or an exciting cinematic. I want to give you an experience you can only get from games. I want to give you the tools to tell your own stories, with my game as the context for those stories.

I used to make jokes about wanting to make you care enough about your pilots that you’d be devastated if they died, and I got a reputation for pilot-murder, but the truth is that I didn’t care if they died, specifically; I just wanted you to care about them. I wanted you to feel like you’d followed these people, these complex messy people, through their adventures and their hardships. I wanted, at the end, for you to look back at your roster (and your memorial wall) and think about who those people had been, and remember moments of amazing success and crushing defeat.

My favorite moments of games like XCOM were always those where a soldier became a person — when they elevated themselves above the rest of the team and made me notice them. My favorite moments of Crusader Kings were always those where I learned something new about who the people in my court were — when their weird quirks and personalities shaped the course of the game in unexpected ways.

I like games where afterwards I want to tell other people the story of the people in my game.

Battletech is a game that was designed, from the first, to be about the people on your ship. The people you hired, trained, fought with, and mourned. Battletech was never the story of Kamea Arano, or Darius, or Santiago, or any of the other named NPCs. It wasn’t even really the story of your commander (something I’ll return to later). It was the story of Glitch and Behemoth and Medusa and every other weird misfit you hired to drive those big stupid robots.

Every time I’ve read someone talking about how they’d always save-scum to save Glitch, it’s made me smile. She’s not unique; her stats are mediocre and her voice acting can be found on dozens of other pilots. But for whatever reason she mattered to you, and that mattered to me. It’s what I wanted from the game; it’s why I made it.

I’ve told people before that the heart of Battletech is really a romance game, and while that’s a simplification, it’s basically true. Battletech began life in my brain sometime around 2008 as a concept for an anime high school sim. It evolved through a number of incarnations, becoming a pitch for a Harry Potter casual game, the inspiration for the Bakugan game I designed, and a Facebook game I created about dark fantasy mercenaries. The thread that links all these things together is the same: you shepherd a group of people through hardships, and in doing so, you learn and shape their stories.

Spoiler

The Roster
On the Argo, the barracks is always bigger than the mech bay. This is intentional. You have more capacity to hire and maintain pilots than you do ’Mechs. From a practical standpoint, injuries are brutal and will take your pilots out of the action long after the robots have been repaired and readied for battle, so you need extra pilots available to pick up the slack and keep the company in the black.

But truthfully, you have more pilots than robots because I didn’t want you to associate a specific pilot with a specific robot. That turns the pilot into a piece of equipment on the robot, not a person. That strips away the pilot’s distinct individuality, and replaces it with their stats and skills.

When Glitch is out with an 80-day injury, and you have to slot some chump named ‘Pamcakes’ into the Vindicator instead, you stop thinking of Glitch as the particular robot with the big gun, and start thinking of her in the medbay, out of action, while Pam racks up kills in ‘her’ robot. When Glitch comes back, you’re now trying to decide between her and Pam when you go out on a mission, because they’re both good and you’ve gotten used to both of them being around.

When you hire a new pilot, it’s always cheaper to hire a rookie and train them yourself. This isn’t by accident. I want you spending time with these people, thinking about who they are and where they’re going. I want you to be guiding them, because when you level their Gunnery you’ve got a commitment to that specialization in a way that hiring High McGunnery from the hiring hall doesn’t provide. And if that pilot ends up in the medbay, you’ll feel every one of those decisions about experience investment and you’ll think about every mission you’ve taken them on to get them a few more points.

Every pilot you hire has a lifepath. I spent way, way too long on this system, and it’s easily the most overdesigned system in the game — eclipsing even the Plot system that allowed maps to be re-used in almost any context. I sunk that time into the lifepaths because I believed (and still believe) they’re the absolute minimum necessary feature set for me to convince you the pilots are people.

I don’t know if anyone outside of the forum hardcore ever explored the complete extent of the lifepath system. Every pilot you ever see that isn’t a special backer pilot has their own unique life. The jumps from one career node to another are non-random; every transition tells another story, of promotion and demotion, of failure and triumph, of crime and prison and escape.

Once, I hired a woman who started as a criminal, joined a pirate crew, was captured and sent to prison, joined the Canopian navy after her sentence was over, and then jumped right to ‘pirate captain’. My narrative for her was that she never stopped being a pirate; she just bided her time until the right moment, and then seized the ship she was assigned to and returned to her pirate comrades triumphant and firmly in command.

She was a person. When I hired her, she felt like someone who could be the main character of her own game. But she was just one of eight pilots I had around, each of whom had their own comparable story (though none quite as extensive as hers; the lifepath system could spit out green novices as well as leathery veterans).

The lifepath gave every character a handful of tags which served as narrative hooks for the event system to use to continue their stories. A criminal would be caught up in criminal stories, figures from their past, black market opportunities, and so on. These tags and their effects were, for a few reasons, never really explored to their full potential; I will probably explain why, and what I did to try and address that, and what the (fairly dire) consequences of that attempt were, in a later post.

The Medbay
We went around and around about injuries and how they’d work. I tasked another designer to figure out how pilots could take damage, how often they’d take damage, and what the consequences in battle would be. Meanwhile, I tried to develop the simulation side of injury and recovery, treating combat as a black box. In retrospect, this was a mistake, but frankly we had too much to do and not enough people to do it, and I couldn’t possibly tinker with every piece of design myself.

In my plans, a pilot coming back from battle with ‘minor’ injuries would be stuck in the medbay for weeks, at least. If the injury was enough to make a difference in battle, it had to be something serious and nasty — a broken limb, a severe burn, a concussion. I hoped for moments where you’d have to consider whether you could dump an injured pilot off at a nearby planet and replace them, rather than carry them through a hundred days of downtime. If I’d done my job right, of making you care about these pilots as people, you’d find that choice wrenching and difficult.

Major injuries would always have a serious risk of death. I didn’t want you to ever be comfortable letting your people take hits. If you came back with any injury that knocked your pilot out completely, I wanted at least a 50/50 chance you’d be saying goodbye to them shortly. This, like so many systems meant to be driven by events, was mostly notional; I couldn’t push our focus towards evolving the event system any further than I had.

Initially I had the idea that really serious injuries, if you survived them, would permanently damage you in some way. Perhaps we’d lower your stats, or perhaps (this one was weirdly popular but never made sense to me) you’d develop some kind of psychological affliction that would impact you in battle in some unspecified way. I mostly discarded this idea for the simple reason that it wasn’t fun.

Remember, the point of all this was to make these characters feel real, and to get you invested in their stories, and get you to follow their adventures and tell other people about their lives. If I broke a character mechanically, made them less useful, made you less likely to keep them around and take them on missions, their story would end prematurely. What I wanted was for you to take that battle-scarred veteran out of the medbay and shove her back into the pilot seat, whether she wanted to go out again or not. I wanted the process of recovery from injury to be a process you eagerly anticipated the end of.

Most of the brutality of the injury system was stripped away, though you can still get some of it back through the difficulty settings. I ended up loading a lot of the more player-unfriendly ideas I’d had into those settings, actually. I know the kind of fun I like to have, and I also know that it doesn’t necessarily work for everyone. I’ll probably come back to those difficulty settings, and the compromises they represent, sometime in the future.

End of Service
In The Company, my Facebook game that was in many ways Battletech 0.1, soldiers would grow old and retire (or die). Old soldiers would request retirement; middle-aged soldiers would want to get married and leave service. And a soldier injured frequently enough might get sick and die; even a brush with disease could leave a soldier vulnerable to a wide array of lethal events that might crop up, without even considering the potential of their death in battle.

I couldn’t let your pilots die of old age; we weren’t passing that much time. The Company’s timescale was ‘seasons’, while Battletech’s scale was ‘weeks’ or even ‘days’. We initially planned to track age and increment accordingly but we cut that when I realized: what would we ever do with that information? How could we use it in a way that was fun?

In The Company, you could see an old, experienced soldier’s retirement coming. He was the backbone of his squad, a veteran in his 50s with twenty years of campaigning under his belt. You could start planning his replacement, looking through your roster for someone who you could put in as his second-in-command, ready to step up when Sarge finally retired (or died).

That wouldn’t work in Battletech, because the population scale was entirely different. The Company had potentially 200 soldiers available at a time, and organized them into 8-person squads. Battletech has, for most people, somewhere between 6 and 10 pilots, with four on the field at a time.

Still, I needed to ask: what happens when someone needs to be replaced? The obvious catalyst is death, but I also wanted less brutal ends — pilots might decide to retire, or join a different company.

When you level up your pilots, there’s a combination of stats that generates a title for you. This has no real effect, but I love it and insisted on it for its flavor. There was a practical purpose, though, which had to do with losing pilots.

If you’d developed Behemoth into a Guts/Piloting character, with the consequent title of ‘Brawler’, you could have a second Brawler you’d leveled as a replacement. Knowing that label and what it meant for the available abilities and traits of the pilot, you could quickly slot in a new Brawler into her ’Mech and pick up the slack immediately. In theory (though I suspect no-one ever did this) you could have a complete set of specializations — all twelve possible combinations — and a backup set of twelve more pilots with the same specializations. (This is, in case you’re curious, why there are 24 berths total in a fully-upgraded Argo.)

Ultimately I didn’t get the kind of pilot turnover I’d been hoping for. I think the game just wasn’t lethal enough, and losing a pilot was never the storytelling beat I wanted it to be. In retrospect, I’d probably emphasize non-lethal ends to careers; a happy ending for Glitch might be retirement to colonial administration, or marrying the girl of her dreams and raising grapes on Coromodir. Making those sorts of story-endings would probably go a long way towards making players feel positive towards pilot turnover.

Next Up
Next time, I’ll talk about the event system, why it exists, why it failed, and what could have been done differently.

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.

https://persenche.medium.com/the-design-philosophy-of-battletech-2-1132a0eb388

The Design Philosophy Of Battletech, Part 2

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.

You’ve Seen This Before
If you’ve 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.

Making Events Work
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.

Spoiler

Scope and Ambition
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.

What Went Wrong
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.

It’s Not About You
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.

What Could Have Been
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.

https://persenche.medium.com/the-design-philosophy-of-battletech-part-3-cd00de340c59

The Design Philosophy of Battletech, Part 3
Maps, Missions and Contracts

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.

Spoiler

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.

 

[Agesilaus]

Battletech is a game that was designed, from the first, to be about the people on your ship

Then it was an absolute, abject failure.

I might read the rest later (doubtful), but Battletech is just a series of tactical battles with no significant C&C or character development/interaction. The gameplay is limited to controlling mechs in turn-based battles so you can collect more mechs and try out new designs. If you follow the campaign and flashpoints then there's some cinematics and limited, bland dialogue to go with it. There hasn't been a battletech pc game "about the people" since Crescent Hawk's Inception.

 

[Cael]

Design Philosophy of the HBS Game:

1. Trannies!
2. Trannies!
3. Muslims!
4. Stronk female!
5. More trannies!
6. Kill whitey!
7. Kill all men!

 

[Roguey]

Highlighting the parts that stuck out the most to me:

I’m far enough away from both Battletech and my frustrations and anger

Someone was fired.

the Battletech IP was my least favorite part of the project,

Kevin in 2016:

I’ve been a fan of BattleTech since 1987, when it competed for table time among my friends with Traveller and Gamma World. I’m a historian by education, and by far my favorite thing about BattleTech is the enormously detailed future history of the setting.

Battletech began life in my brain sometime around 2008 as a concept for an anime high school sim. It evolved through a number of incarnations, becoming a pitch for a Harry Potter casual game, the inspiration for the Bakugan game I designed, and a Facebook game I created about dark fantasy mercenaries.

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.

Senior studio guy was right and Chris Avellone would agree. Everything should revolve around the player character and you shouldn't be able to make role playing choices for NPCs without the PC's presence.

I have a confession about encounters: I designed them almost from the ground up knowing they would suck.

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.

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.)

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.

Kiva likes to talk a lot about having imposter syndrome and yet is unable to come to terms that it's the voice of accurate self-assessment. Just one more delusion for the pile.

 

[Nutria]

Part 1, about focusing on your squad members in the same way that X-Com does, I think actually made a lot of sense. It worked well for me in this game. I cared about who was who and was forced to make some tough choices about when I had to abandon a mission because I wasn't willing to risk my people's lives.

Part 2 seemed kind of muddled to me. In a game like Stellaris you can make the decision for someone else in a random event because you're playing as an entire civilization. That's a weird perspective for the player to be in, and it works sometimes, but not every game is like that.

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…

This is a good point, and I'd love it if we'd see more games that try to model command & control, but until you can design that system and make it work, you don't really get to criticize others.

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.

This is a really good point and something to keep in mind for anyone who wants to make an indie game with lots of text in it. You have to write the parts that you have no inspiration for too.

Part 3 is about generating missions appropriate to the context you're in, something I thought this game did very well. Which makes it all the more weird that there's a rant about "marginalized voices" being silenced and a lot of defensiveness about who made what parts of the game. It's worth reading because if nothing else, she would hate to know that Codexers are actually listening to her "voice".

So in sum, I would say there's a lot of good information in here, especially if you're trying to learn how to make games on a less than AAA budget. But it seems to be more focused on one person defending their role in making the game than answering my main questions, which are why you're limited to 4 mechs with no supporting units and why it's so goddamn inefficient and slow.

 

[Roguey]

This is a good point, and I'd love it if we'd see more games that try to model command & control, but until you can design that system and make it work, you don't really get to criticize others.

Combat isn't role playing which is why it's permissible to play low-intelligence combatants like a tactical genius.

 

[Hellraiser]

This is a good point, and I'd love it if we'd see more games that try to model command & control, but until you can design that system and make it work, you don't really get to criticize others.

Combat isn't role playing which is why it's permissible to play low-intelligence combatants like a tactical genius.

TBH I prefer to look at it as grunts obeying the big-dicked alphaness charisma of the commander/leader to the letter. Grunts are there to follow orders and shoot, they don't need to have more INT than just enough for that.

 

[almondblight]

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.

This is a really good point and something to keep in mind for anyone who wants to make an indie game with lots of text in it. You have to write the parts that you have no inspiration for too.

I mean, chances are if you're finding something uninspiring and a slog to write the player is going to find it a slog to read as well. I think that's part of the problem, Kiva talking about wanting 200 events in the game, and needing to hire more writers sounds like the problem a lot of games have with writing bloat. You want some one who's good at thinking of interesting events, and simple and succinct writing is preferable to someone trying to force "witty" and "humorous" lines in. You want events that are there because someone thought they would be cool, not because someone is trying to throw something together to reach an arbitrary number of events. 40 good events is better than 40 good events and 160 filler events.

I also don't understand how requiring that the commander makes the decisions was a "death-blow to the event system," since that's how most games handle events. Most with more interesting and impactful events than the ones in Battletech. This whole thing reads like HBS decided to put in charge a design lead (who didn't seem to have much prior game experience) that wasn't interested in making a Battletech game but was trying to make their own dream game instead.

Also:

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.’

Trevor King-Yost who was the design lead for Dragonfall and Hong Kong. His Linked-In is interesting, after the Shadowrun games he worked on systems design for Battletech (under Kiva from what I can tell) but left HBS during development, then after a year returned to HBS as a senior designer/lead designer.

 

[Cael]

This whole thing reads like HBS decided to put in charge a design lead (who didn't seem to have much prior game experience) that wasn't interested in making a Battletech game but was trying to make their own dream game instead.

The fact Kevin went on rants in twatter screaming about ungrateful players who didn't appreciate his genius in putting his tranny and diversity agenda into the game didn't clue people in on that?

 

[Galdred]

Actually, the commander problem is an issue for both battle brothers, XCOM and Battletech, because he is not really a character. He is the only character without stats and without gameplay.
XCOM 2 tried to make him special, but that fell flat.
King Arthur also used the"Kiva approach" and it worked rather well (most events involved one Knight off the round table and you played as him and not as remote Arthur).
I think it is better to either give a character to the commander (like the imp Merc in Jagged alliance 2, even though he is not technically yourself, he feels awfully close) or completely abstract him, but making him the only statless character while trying to make him central to the plot is a bit schizophrenic indeed.

So either approach would have been flawed IMO.

It is an old problem that already existed in party based RPGs.
In Darklands, you could play after all your initial characters had retired, but being the remote commander of a party of 4 made even less sense.

 

[oldmanpaco]

Every time you assholes bump this thread up I remember I backed this shitshow on KS.

 

[Roguey]

It is an old problem that already existed in party based RPGs.
In Darklands, you could play after all your initial characters had retired, but being the remote commander of a party of 4 made even less sense.

That's not a problem. You're playing all of them, there is no central character.