• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.

HBS_TheBaron

Recruit
1 Badges
Feb 27, 2018
4
2
  • Harebrained Schemes Staff
Hi everybody! My name is Andrew McIntosh, and I’m the Principal Writer of BATTLETECH. Today I’m going to introduce you to some of the techniques that I employ when I sit down to write a Flashpoint. This isn't intended to be an exhaustive tutorial so much as it is a brief window into the process, but if a comprehensive guide is what you're looking for, Amechwarrior's got you covered. Seriously, check out his guide, it's a fantastic resource: https://forum.paradoxplaza.com/forum/index.php?threads/flashpoint-authors-guide.1153590/

Before I go any further, I should probably mention that this Dev Diary may include minor story spoilers for Flashpoint and Urban Warfare. You have been warned!


Flashpoints, Defined
Okay. So. What is a Flashpoint, exactly? At its most basic level, a Flashpoint is a Combat Encounter sandwiched between a pair of Group Conversations for the purpose of context.


Flashpoint_Linear (3).jpg

A Linear Flashpoint.


A Linear Flashpoint like the one above is basically just a glorified procedural contract, with no branching and no decision points. As a component of a larger campaign, it's great, but as a standalone story structure it leaves a lot to be desired.

For a self-contained story, you’re probably going to want to add more depth in the form of additional missions, a decision point, and branching. By adding a branch in the second group conversation, a pair of new missions, and a third group conversation, we arrive at what we refer to as a Short Split:


Flashpoint_Linear (2).jpg

A Short Split Flashpoint.


Short Splits are the most common form of Flashpoint, and for good reason: they’re focused, they have decision points to enable branching, and they’re short enough that they don’t overstay their welcome. For a new designer learning the ropes, a Short Split is a great place to start.

To the best of my knowledge, there’s no actual limit to how long or how complicated a Flashpoint can be. If you want to try your hand at designing a 10-mission structure with 5 branching decision points, go to town! Just be aware that the longer and more complex you make your Flashpoint's structure, the longer it will take to write, and the more onerous testing it will be.


Workshopping a New Flashpoint
Now that we've established what a Flashpoint is, let's talk about writing them. When I sit down to author a new Flashpoint, there are a few questions I like asking myself to guide my thinking:
  • Is there a particular type of story that we haven’t told yet in the BattleTech universe, or a new spin that I can put on a story concept we’ve already explored?
  • Are there canonical elements of BattleTech lore that we haven’t explored, but should?
    • Example: The Baying of Hounds from the Flashpoint expansion, which delved into some of the fallout from Morgan Kell’s sudden departure from the Kell Hounds.
    • Special thanks to Bishop Steiner for his invaluable assistance in developing this story!
  • Is there a compelling moral or tactical choice that I’d like to write a scenario around?
    • Example: Hearts and Minds from the Urban Warfare expansion, which interrogates how far the player is willing to go to complete a contract.
  • Is there an unexplored story tone or sub-genre of military science fiction that would be fun to play around with?
    • Examples: Tournament of Champions and One Man’s Trash from the Urban Warfare expansion. These Flashpoints lean into comedy to provide tonal breaks from heavier, more serious content like Hearts and Minds. They’re also a ton of fun to write!
In the course of working through these questions, I’ll typically fill a brainstorming document with story seeds and character ideas. The goal at this stage is to stay loose and high-level rather than getting bogged down in the details.

When I’m satisfied that I have a solid idea for a potential Flashpoint, I’ll move on to the Outline stage, where I try to break a story concept down into a series of distinct beats. These beats are then mapped out using the tools at my disposal: Combat Encounters and Group Conversations.


Combat Encounters
Combat Encounters are the building blocks for your Flashpoint's gameplay. Because of this, it’s critical to ensure that the major beats of your story are compatible with the encounter types available to you. The last thing you want is for your combat missions to feel like filler because the gameplay is at odds with the narrative.

Most Combat Encounters are flexible in some respects, but quite rigid in others. Escort quests have predetermined routes. Capture and Destroy Base encounters revolve around building plots that are baked into the map, and enemy spawn points are always set on the encounter level.


ContractTypes.jpg

You’ll be building your Flashpoints from the same encounter types found in procedural Contracts.


As a general statement, the most effective Flashpoints have narratives that can be divided into a series of Combat Encounters in a natural and unforced manner. Because of this, the crux of your narrative should probably revolve around things that your protagonists can do in their BattleMechs—blow up buildings, eliminate enemy units, that sort of thing.

By contrast, stories that revolve around more subtle action—detective work, exploration, et cetera—don’t line up very well with BattleTech's core gameplay. You can certainly explore these ideas in group conversations if you like, but if what the player is actually doing during the combat game winds up feeling incidental to the plot, your Flashpoint will probably suffer for it in the long run.


Group Conversations
Group Conversations serve as your primary tools for wrapping your Flashpoints in context. They’re also how we introduce player choice to the game by way of decision points.


DoubleAgent.png

A Group Conversation with branching dialogue and a decision point.


Group Conversations can do a lot of things, but there are a couple of conventions that we've traditionally followed when writing them:
  • Conversations are dialogue-only, with no descriptive “GM text.”
    • This decision was born of the animated 3D crewmembers that the camera focuses on in group conversations. Each of these characters loops a simple idle animation that cannot be changed, and it was found during early prototyping that descriptions of actions or body language that were out of sync with these idle animations felt out-of-place and jarring.
  • On the whole, we’ve leaned against plot points that feel impactful to the point that a player would expect a major shift in an Argo crew member's behavior as a consequence.
    • We made this decision because, by design, Flashpoints can be played in any order.
    • Retrofitting every Flashpoint to account for a major decision that may have been made in a previous Flashpoint is a cool idea, but it’s way out of scope for a studio of our size.

As an independent designer, you don’t have to adhere to these conventions, but if you want your Flashpoint to play nicely with ours, you probably should.

Now that we’ve looked at some of the limitations that we need to work around, let’s take a look at the tools that we do have to work with:
  • While we can’t make our characters emote, per se, we can use italics or ALL-CAPS to communicate intensity and excitement.
  • We can also cheat in some light introductory descriptive text by way of the Viewscreen.
    • By convention, whenever a new image appears on the Viewscreen, it is accompanied by a line or two of text in brackets to set the stage for what the player is seeing.
    • Example: [The Liao MechWarrior scowls into the Viewscreen, her brow furrowed in disgust.]
    • We can use this sparingly to cheat the restriction against using GM text in dialogue.
  • We can differentiate our characters through tone and dialect.
    • Professor Mencius Horvat from Tournament of Champions was intentionally written as a big, broad character. His conversational style starts out somewhere between "purple prose" and "okay, this is actually getting kind of uncomfortable," and by the time Calamar Gigante arrives it tilts fully into comedy.

Horvat2.png

Go big or go home.


Now that we've gone over the building blocks of a Flashpoint, I have a couple more pieces of knowledge to drop on you. Without further ado:


Focus=Quality, or the value of Keeping It Simple
As a rough estimate, I'd say that about 90% of the problems I've run into in the writing of Flashpoints can be boiled down to a single ur-problem: unnecessary story complexity. TOO MUCH STUFF.

It pains me to say that. Really, it does. I love deep, complex stories with interwoven plot threads, multiple point of view characters, and all that jazz. But Flashpoints aren't very well-suited to delivering story complexity in a satisfying way, and in my experience, the more complexity you're wrestling with, the clunkier your delivery is likely to be. Group Conversations that go much longer than 11-12 clicks can slow the pacing of your Flashpoint to a crawl, and delivering exposition through interrupt dialogue in Combat Encounters is even worse.

I'm not saying that you can't write a super-complex Flashpoint, but if you find yourself hitting a brick wall in the development of your story, I'd suggest that you take a step back and examine what's there. Is there a B-Story that you can cut, or turn into a Flashpoint of its own? Are there side characters that don't need to be there? In the words of the Lord Commander, "Focus=Quality," and that applies as much to Flashpoint writing as it does to anything else.


Writing=Rewriting, or the Importance of Iteration
As Hemingway once said, "The only kind of writing is rewriting." That's a thing in game writing, too. A line can look very different in the editor than it does in-game. Art, music, and UI elements can completely alter the way that a piece of dialogue reads. You want an example? Take a look at Darius.

When I wrote Darius's combat barks—you know, the lines about "reinforcements on their way," etc.—it was with the intention that he come across as a hyper-competent mercenary operator. Unfortunately, because of a few bugs that were present at launch, some of that dialogue got triggered at the wrong time. Okay, a lot of that dialogue got triggered at the wrong times. And as a result, Darius would repeatedly deliver fantastically incorrect tactical information with an air of utter confidence.

I probably don't need to tell you how that worked out.

Now, I'm sharing this story for a reason: the way that you write a character isn't necessarily going to line up with how that character is received. In writing Flashpoints, you won't have to worry about the specific issue that hit Darius, but it is important that you review and revise your content. Is there a line that doesn't read the way you want it to? Be willing to edit it or throw it away. You can always revisit it in your next Flashpoint.


Wrapping Up
I could probably fill another 10 pages with anecdotes and stories about Flashpoint development here at HBS, but in the interest of keeping this thing manageable I'm going to wrap up here. That said, if there's enough interest I'd be happy to follow this up with another Dev Diary later down the line.

For now, I hope that you've enjoyed this brief window into the development process, and I can't wait to play some of the Flashpoints that you, the community, come up with!
 
Last edited by a moderator:
  • 2Like
Reactions:
Outstanding Dev Diary! :bow:

Great insights into the process of making FLAHSPOINTS. Even a shoutout to @Amechwarrior. : )
 
Excellent Dev Diary, thank you! It is cool to see how Flashpoints are structured, and I love reading the tips and tricks of it.

As a side note. I poke a bit of fun at Darius, but it is all in fun :). I like the crew of the Argo, and they each have a personality that really comes through.
 
Great post! I'm totally backing up what the post says about FOCUS=QUALITY and keeping it simple. The biggest take away after I completed my FP is, keep everything short and sweet. If I were to do it again, the opening convo of "The Raid" would be much shorter.
 
So for people looking to dip a toe into the water of flashpoint creation, and the expansion and official modding support dropping in a couple weeks... is now a bad time to start?

Are there any tool improvements or format... things incoming that might make me regret starting now or make things so much easier that I might wish I had just waited for them?
 
Thank you for the interesting Dev Diary!

I don't think I'll be authoring any flashpoints any time soon, but it's interesting nonetheless to see how you guys put them together :)
 
Fantastic Dev Diary! It's always a joy to look into the design process for parts of the game.

I did have a thought on flashpoints, but I suspect it would involve some extra work on the coding side of things, so I don't know how feasible it would be. In several of the existing flashpoints we have moments where the decision is about which part of a multi-stage mission the player will complete, with allied forces completing the other stages in the background. In every one of them, those background missions get completed flawlessly and it all comes down to the player experience as the deciding factor.

What if those allied forces weren't always so successful?

I'd love to see something where the game engine plays out those other battles behind the scenes and the results inform the next actions of the player. Say, two bases had to be destroyed to clear the way for the player to capture a spaceport in order to escape the planet, and the player takes one while the allied NPC lance takes the other. Depending on the lance loadout and skill of the NPC lance, they could succeed, fail, or succeed with losses that prevent the full lance from joining the player lance in the final base capture. It could result in a variable-length FP deployment, where the player has to go destroy the damaged, but now alerted and reinforced, second base to clear the way after the allies failed before moving on the base capture at the end.

In the end, I suppose it boils down to your comments on keeping it simple and the desire to make a deeper, more complex experience. (Although, if the idea is feasible, you're welcome to it.) :)
 
@Wayward Son, I think I see what you are getting at...

Failure can be Fun, as long as it isn’t the end and what comes next after Failure is both interesting and filled with Mechs. : )
 
@Wayward Son, I think I see what you are getting at...

Failure can be Fun, as long as it isn’t the end and what comes next after Failure is both interesting and filled with Mechs. : )

Exactly! And that a little randomness can keep a flashpoint both interesting and re-playable. Battlefields are chaotic places by nature, so letting that affect the ongoing strategy of the engagement adds realism and moral choices. ("We have intel that the allied mechwarriors were captured and are being held/moved! Do we go rescue them, or continue on the primary mission?")