This Feature is part of my ongoing course in advanced adventure, encounter, and campaign design: True Scenario Designery. If you haven’t been following it from the beginning, use the True Scenario Designery Course Index to catch up.

This lesson continues a long-ass thing about Scenario Structure.

More Shapey Goodness

Welcome back, aspiring game makers and game marquesses. Have I used that one before? This come up with funny ways to say ladies and gentlemen at the start of my features was a fun idea until I realized I’d have to do it eleventy hundred dozen of them.

Anyway…

The topic is still Scenario Structure. I taught you that Scenarios have Structures and that those include both Gameplay and Narrative Structures. I also told you that Gameplay Structure comprises the Scenario’s Shape, Flow, and Progressions.

For the last few lessons, I’ve been covering Scenario Shape, and that ain’t gonna change today. The title should have been a frigging giveaway.

I first showed you how Scenarios are nested chunks of game that form a sorta hierarchy thing. The hierarchy runs down from Campaigns to Arcs, then Adventures, then Scenes, and finally Encounters. Do you remember that crap? Next, I gave you a language for describing the Shape the gameplay takes in each of those Scenario Elements. I described Linear Gameplay, Branching and Pyramid Gameplay, Labyrinthine Gameplay, Hubbenspoke Gameplay — called Hübbënßpökë in the original German — and Open Gameplay — called Eldenzelda Gameplay in some circles and Effing Ubisoft Gameplay in others.

Those of you with wisdom and maturity rarely seen in our hobby even got to learn how loose and abstract and nebulous all this crap really, actually is. You know that nothing here is as definitive as it is and if you take it so, you’ll constrain yourself and make crappy Scenarios and you’ll shame yourself, your house, and the entire Game Mastering community to the point that, if you don’t commit ritual Sudoku, I’ll come Sudoku you myself.

Do you remember all of that? Especially that last part? Because I am not screwing with you. I will do it. I own my own sword, I’ve killed before, and I will kill again.

Before I move this whole thing on to Gameplay Flow, I want to absolutely beat the topic of Gameplay Shape to chunky salsa. So today, I’m going to talk even more about how Square Scenarios go in the Square Hole and how Arch-Shaped Scenarios also go in the Square Hole if you draw them right.

Really, I want to talk about how some of these ideas translate to Encounters. But, to do that, I’ve got to discuss what those Gameplay Outlines — the little flowcharty shape thingums I showed you last time — are really about.

Sticks and Lines and Arrows and Shit

Let’s say I showed you this Gameplay Outline flowchart thing…

What is that really about? What does it actually represent? What are the boxes? What are the arrows? What are the… other arrows? They’re supposed to be lines, but I keep accidentally making them arrows. Pretend there are lines between the boxes, not arrows. What are those non-arrow lines?

Actually, they can be arrows, but that’s a Flow thing; it’s not a today thing.

First, what shape hole do you think that Scenario goes in? That’s right, it goes in the Branching Gameplay hole. Very good.

Second, though, what Hierarchical Scenario Level are you looking at? That’s right, that’s a trick question. There’s no frigging way to know whether that’s a Campaign Outline or a Scene Outline or an Adventure Outline or even an Encounter Outline. Except you can tell by looking at it that it’s probably not an Encounter. At least, I can tell. Maybe, by the end of this lesson, you’ll be able to tell too.

Of Squares and Square Holes

When you’re looking at a Gameplay Outline like that — or when you draw your own — what, actually, are the squares you’re arranging and joining up? What do they represent?

It shouldn’t frigging shock you to hear me say, “It depends.” But the dependsiveness of it is more complicated than you probably think.

Part of the dependsiveness is obviously down to that whole Hierarchical Level thing, right? If you’re mapping a Campaign, those boxes are probably Arcs or Adventures, whereas if you’re mapping an Adventure, they’re probably Scenes or Encounters.

Actually, my finely honed True Scenario Designery instincts tell me the boxes in that example Scenario Outline ain’t Arcs or Scenes, just as they told me that Outline ain’t showing an Encounter. There are clues, but you’re gonna need some practice to spot them yourselves.

Let’s say I outlined a Campaign in that example. Those boxes are likely Adventures. The first Adventure might entail defending a town from a sudden Imperial attack. While defending the town, if the heroes recognize that the Empire is trying to steal the Water Crystal from the temple’s vault, they might prevent its theft. Otherwise, the Empire gets away with it.

If the heroes have the Water Crystal, they might undertake an adventure to determine its true purpose by exploring the Ancient Water Crystal Forge, but they’re ambushed by the Empire, and either they get captured or they escape with the Water Crystal.

If the heroes lost the Water Crystal in the town attack, they infiltrate the Imperial Stronghold in an attempt to recover it. They’re too late, though, because it’s not there anymore. The heroes can discover that it’s been taken to the Place Where Leviathan Is.

If the heroes follow the Empire to the Place Where Leviathan Is, the Imperial General frees Leviathan, and the heroes are forced to fight and kill it. Likewise, if the heroes got captured, they are imprisoned at the Place Where Leviathan Is and must escape and confront the Imperial General, who frees Leviathan, and the heroes must kill Leviathan.

If, however, the heroes retain control of the Water Crystal and learn its true purpose — it binds the imprisoned but surprisingly peaceful sea spirit, Leviathan, to the bearer’s will — they can beat the Empire to The Place Where Leviathan Is, free Leviathan, and destroy the Water Crystal, setting the beast free. Then, when the Imperial Fleet attacks, Leviathan smashes it while the heroes confront the Imperial General on his ship in the tempest and kill him.

Or whatever. I don’t know. I’m just spit-balling what that diagram might represent if it were actually an Campaign and I’d played Final Fantasy II on my SNES recently. The outline might look something like this…

• Adventure 1: The Imperial Attack
• Adventure 2a: Infiltrating the Imperial Stronghold
• Adventure 3a: Leviathan is Bound
• Adventure 2b: The Ancient Crystal Forge
• Adventure 3b: Imprisoned at the Summoning
• Adventure 3c: Freeing Leviathan

Do you see, by the way, why Scenario Outlines are so much better than lists and narrative descriptions? If I’d have labeled the Outline, that whole plot would be clear. But, in my defense, I drew random boxes as an example. I had no idea I was going to give it a plot until I was writing this draft.

I probably don’t have to spell out how that Outline could show a bunch of interconnected Encounters in an Adventure. That’s much easier to imagine, so I can skip pulling another plot out of my ass. Besides, my proctologist has recommended I stop pulling things out of my ass for reasons my brand team has told me to absolutely not spell out.

So, moving on, then…

There’s actually a whole other way to see those boxes, though, regardless of the level of Scenario you’re outlining. Instead of thinking of them as Encounters or Adventures or other specific kinds of Scenarios, you could just think about them as Gameplay Challenges, couldn’t you?

Think about it.

Goals and challenges are pretty central to the whole Scenario thing, aren’t they? A Scenario is a goal with a challenge in the way. Everything else — outcomes and dynamics and context — all hang off either the goal or the challenge like corpses on a hanging tree. Even my example was pretty fixated on the goals and the challenges, wasn’t it?

Challenge is what makes a game a game, so if I’m diagramming the structure of a game, I should probably show the Challenges, right?

That said, these outlines don’t always tell us much about the Scenario’s own major element of Challenge, do they? Remember, I called those Macrochallenges. Big, emergent Challenges that can succeed or fail separately from the Microchallenges shown on the Outline. But the Scenario Outline also isn’t completely silent about Macrochallenges. There are patterns. Branching Scenarios and Labyrinthine Scenarios tend to be about navigating the Scenario somehow. Either finding the exit or finding the best exit. Notice how much in my example was contingent on the players figuring shit out so they could arrive at the good ending? Solving a mystery is an abstract kind of navigational challenge. Meanwhile, the central challenges in Linear Scenarios and Pyramid Scenarios tend to be more performance-based. The classic example is getting through a gauntlet of challenges with enough resources to beat a big boss.

But that’s an aside. I’m just such an amazing, sexy gaming genius that even my asides are major revelations. So I don’t know why people give me so much shit about how much I write. I cram a lot of ideas into every lesson.

Anyway…

The point is, you can look at the Scenario Elements shown in a Scenario Outline as lower-level Scenarios, or you can look at them as Microchallenges. Either way works. Sometimes one perspective is better than the other. It all depends on what you’re focusing on. Technically, there’s no real difference. If every Scenario Element is a Scenario and every Scenario has a Goal and a Challenge and all that crap, then does it matter if you label Scenario Elements as Scenarios or call them by their Challenges?

No. The answer is no. Except…

Is it really, truly true that every Scenario Element is a Scenario and therefore has Goals and Challenges? Really really? All the time and forever? Could you ever imagine drawing something on a Scenario Outline that isn’t, technically, a Scenario?

Oh, look, everyone whose asses didn’t get kicked out last week is raising their hand right now. Shut up. We’re pretending last week didn’t happen.

Let’s imagine that the example Outline is an Adventure, not a Campaign or Arc, for a minute. Let’s say it starts with the mayor of the town asking the heroes to confront an octogenarian aristocrat that — surprising no one — is actually a soulless undead abomination. To start the adventure, the mayor suggests two possibilities. First, he says there’s a hero buried in a mausoleum in the haunted graveyard with a Sword of Undead Octogenarian Aristocrat Bane. Second, he says a number of the octogenarian aristocrat’s minions have repeatedly tried to kidnap a specific maiden from town. They always come under the cover of the new moon and — again, surprising no one — tonight just happens to be the night of the new moon.

The scene in which the heroes meet with the mayor and accept the quest and learn about the sword and the maiden and all that crap? That’s not really a Scenario, is it? There’s no Challenge and not even a real Goal in the Gameplay sense. You, the Scenario Designer, have a Goal. That’s to tell the players, “This adventure’s about killing Dracula. Here are two things that might bear fruit to start with. Either go steal a sword from a crypt or go stop a maiden from being kidnapped. Your call.”

If it’s not a Scenario, it doesn’t belong on a Scenario Outline, does it? Because it’s not gameplay. It’s basically just an interactive version of the little blurb in the front of a board game’s instruction manual that tells you what the game’s about and how to win.

But, without that scene, the gameplay can’t happen. Moreover, the players will make a decision that shapes the gameplay. So it really does belong on the Scenario Outline, doesn’t it?

Honestly, there’s no right answer here. I could draw either of these Outlines and be correct…

Which one I draw is a choice I make as a True Scenario Designer. These Outlines are just tools I use to plan Scenarios. I can use them however I want. I can draw what I want, write what I want, and leave off what I want. It’s just a visual way to map out how I see the Scenario Gameplay playing out. If I’ve got two arrows coming in and going to two different Scenario Elements, I know I need to show the players two entrances at the start of the game. If I’ve got a box labeled ‘Quest Giver’ with two lines going out, I know I need a scene that starts the adventure and points them in two different directions.

The choice might be just down to how I like to work, or it might make a meaningful statement about the design. Putting the mayor in his own box means I think of that scene as part of the gameplay. That might let me stick some foreshadowing in there or maybe even a die roll or two to get some extra information. That ain’t really gameplay, but it’s interactive. Meanwhile, if I leave the mayor off the Outline, that suggests I consider that meeting to be the fluff text that starts the adventure. I just want to give the players a chance to pick a door and start playing.

Thus, those boxes could be anything. They could be Scenarios or they could be Microchallenges, but they could be Decision Points where the players make an important choice, but there’s no gameplay apart from the choice. Of course, those Decision Points might feed the Macrochallenge, but they might not. Likewise, the boxes could just be Interactions. Places where the players just, you know, interact with something.

What matters is that the Scenario Designer thinks whatever it is is significant enough to affect the gameplay in some way, even if it’s not actually gameplay itself. As long as the Scenario Designer is focused on gameplay, it’s fine if some Scenario Elements aren’t entirely gameplay by themselves. It doesn’t matter if everything’s all Goals and Macrochallenges and Microchallenges and Gameplay Dynamics as long as everything is somehow about those things.

Meanwhile, if there’s a bunch of stuff on my Outline that isn’t gameplay, maybe I need to rethink what the hell I’m actually doing. Am I even doing Scenario Design anymore or am I just building a level?

And the Lines?

I can probably skip the long-ass speech where I walk you to the conclusion that the lines aren’t really anything, but they could be. They just tell you that the game’s action can move from one Scenario Element to another in the normal course of play. If the action’s in this room, say, it can go to that room or that other room. If the players finish this adventure here, they must move on to the next one. The lines could be hallways, adventure hooks, leads in a mystery, or even just represent the passage of time in an event-based Scenario.

There’s a lot of Gameplay Flow crap here, so most of this is a story for another time.

Consider this Scene that takes place in town…

Obviously, the town’s an Open Scene. Most towns are. They’re filled with locations and encounters that the players can freely move between. Of course, you can also build a Hubbenspoke town. You can even model a big city as a Freeflowing Linear Hubbenspoke Sequence, but that’s a story for another day.

Maybe that’s a good homework assignment. Try to draw what the crap you think I just described.

Meanwhile, notice that I subtly highlighted something on my little diagram. What the hell is that line?

Clearly, there’s a Scenario Element that can’t be freely accessed from the Open Scene but instead is only accessible through some other, specific Scenario Element. It could be something as simple as a cellar under a building, right? You can’t get into the cellar from anywhere except the building. But is that really all it is? Probably not.

Consider that there is definitely an inn somewhere in that Scene, right? Fantasy roleplaying game towns always have inns. Those inns have rooms, right? Bedrooms and kitchens and private dining rooms and wine cellars and stables, right? Would I draw all those on my Scenario Outline? Hell no! I’d just draw one box, label it ‘The Sword and Maiden,’ and give it rooms and people when I’m actually building the bits and pieces.

That suggests that, if that box-with-a-line I called out really is just a cellar beneath a room, there’s something significant about the fact that it can’t be accessed from the street. Or that it contains something significant. Something gameplay significant. Maybe it’s locked, and there’s a challenge to finding the key. Maybe the kidnappers locked the victim in the cellar, and the heroes need to get past the thugs in the building above to rescue her.

Maybe the line’s more abstract than a stairway or key with a challenge in the way. Maybe the box is a hidden black-market shop. From the outside, it looks like any random storeroom or warehouse or whatever. Black market shops ain’t big into branding and signage for a variety of reasons. In theory, the heroes could find it by entering every building in town, but they won’t. Instead, they need to learn that the shop exists and where it exists. Then it’s accessible. The location is gated behind the challenge of learning that it exists.

The important point is that the lines between the boxes represent significant gameplay connections, right? Well, that can be true sometimes, but, unfortunately, sometimes a line is just a line.

Imagine I’m outlining a Labyrinthine Dungeon. Just a dungeon crawl. I’m drawing lots of boxes and lots of lines. Does every line between every box really represent actual, significant gameplay? Probably not. Probably they’re mostly just hallways between rooms. In fact, I probably have to specifically label the ones that are keyed to gameplay somehow. I have to label the locked doors and the hidden passages, right?

This just goes back to the whole contextual tomato bullshit I told y’all last time. Context changes everything; it even changes what the symbols on your maps mean.

Guess What? The Arrows Are Abstract Too!

I probably don’t have to spell this out, but I’m gonna. Everything above goes for those little arrows on my Outlines, too. The ones that actually are arrows, not the lines I keep misdrawing with arrowheads that I’m too lazy to fix.

Unless you’re a complete asshat, you’ve probably realized the little in-pointing arrows represent the start of the game action, right? Well, what they actually represent in the actual gameplay varies depending on the scale of your Outline and how you actually intend to start things out. An in-pointing arrow can represent the point at which a Campaign starts or the beginning of an Adventure, but even that’s kind of vague. The arrow itself could represent the incitement or the hook or whatever, or it could just point to the Scenario Element in which the incitement or hook is introduced.

Meanwhile, an in-pointing arrow could simply represent the gate to town or the door to the dungeon, or it could just represent the heroes’ arrival thereto. Many in-pointing arrows, in fact, are just the ends of out-pointing arrows from previous Adventures, Scenes, or Arcs. As I demonstrated above, in-pointing arrows can just highlight which Element the Game Master should start running at.

Similarly, out-pointing arrows just show where Scenarios end. In theory, they’re Scenario Outcomes, but, in practice, they aren’t always and don’t have to be. Sometimes, the Scenario always ends at the same place, but the actual Outcome depends on what happened on the way. How many people did the heroes save? How many treasures did they recover? How many friends did they make on the way? A Scenario Outline with a single out-pointing arrow does not imply the Scenario only has one Outcome.

Some Scenario Outlines don’t have any out-pointing arrows at all. It just doesn’t make sense when you’re planning the Scenario to put an arrow pointing out. Remember that Pillage the Dungeon adventure I talked about months ago? The one that provided an example of a can’t lose Scenario with multiple, graded endings? I probably wouldn’t bother with an out-pointing arrow because there’s no place in the gameplay where the action pops out of the adventure. The players just decide they’re done at some point.

And finally, as noted above, out-pointing arrows can just show you where the Scene or whatever connects to the next Scene you’ve outlined on some other page in your notebook.

Outlining Encounters for Maximum Gameplay Goodness

If you paid attention in my last few lessons, you probably noticed me drop a few hints that you can use these same Structure ideas and planning tools to plan richer, fuller, gooder Encounters.

If you haven’t paid attention, then why the hell are you even here? What’s wrong with you?

One thing I’ve hinted at is that Encounters have shapes just like other Scenarios do. Most of y’all don’t know that, though, because most every Encounter can be fit into the square hole, so most everyone just crams it in there.

This ain’t a point I’m going to belabor today. I just want to highlight the idea that Encounters can have shapes. There’s a time for detailed Encounter Building in Scenario Design, but it ain’t the top-level planning phase. So this is not a today thing, but the day it becomes a today thing, I’m going to show you how you can use these same outlining tools to plan an Encounter.

Right now, though, I just want you to know that you can think about the Structures, Shapes, and Outcomes of Encounters and, even though you’re not doing detailed Encounter Buildery at this stage of the True Scenario Designery game, it doesn’t hurt to keep ideas in the back of your head for later.

I also want to make another point about Open-Ended Creativity Challenge Horseshit. I’ll get to that in a second, though. First, walk with me…

The boxes on Scenario Outlines can represent anything from full Scenarios to individual Microchallenges on down to single Interactions, right?

And the lines on Scenario Outlines can represent anything from connections between full Scenarios to halls between rooms to the possession of knowledge down to specific approaches to a Scenario element, right?

And the arrows pointing in and out of Scenario Outlines can represent anything from incitements and initial leads and outcomes to doors into and out of a dungeon or room, right?

Can you imagine how, maybe, those facts would let you outline an Encounter the same way you’d outline an Adventure? More easily, in fact, given that most Encounters are much less complex compared to Scenes, Adventures, and Campaigns? Most Encounters won’t have more than one to three boxes and the requisite numbers of lines, arrowed and unarrowed.

Picture a combat Encounter between the entrance and the exit of a room. Isn’t that just a Linear Encounter with a single box, an inflow line, and an outflow line? Given that, how might you diagram an ogre you can either combat or stealth through? That’s kind of pyramiddy, isn’t it?

Or, maybe, you’d draw it like this…

That looks like one of those Divergenconverge Encounters I suggested might be a shape, doesn’t it?

How might you outline an Encounter you can either interact or combat if each approach opens the way to a different Outcome? That’s a Branching Encounter, isn’t it?

Let’s get fancier. Imagine an Encounter where you absolutely have to combat the Crystal Guardian because you need its Crystal Heart for reasons, and it’s really hard to get a heart out of something without violence. Imagine that the room with the Crystal Guardian has multiple entrances. Your approach depends on the path you took through the dungeon. If you come in by the main door, the Crystal Guardian attacks. If you enter via the balcony, though, you can drop the Crystal Chandelier on the Crystal Guardian, which stuns it and buys you a surprise round plus a convenient elevated position. If you enter via the secret side door, you can safely approach the Crystal Crystal and smash it, weakening the Crystal Guardian. Either way, you’re fighting, but the approaches change the gameplay.

Personally, I’d call that a Pyramid Encounter, and I’m very smart and always right, so that’s probably the right thing to call it.

In my module, The Fall of Silverpine Watch, I included two examples of Open Encounters. Both come as the heroes escort Oona the merchant on her horse-drawn cart on the road through Silverpine Forest.

In the first Open Encounter, the horses are spooked by a snake sunning itself in the road. Oona is thrown from the cart, smashes her head, and ends up bleeding out. Meanwhile, the cart is stuck in the mud by the side of the road, and the panicked horses are damaging their harnesses and hurting themselves in their attempt to break free. Meanwhile also, there’s an unnoticed snake in the road that might bite someone. And then meanwhile also too, some of the heroes might have gotten hurt when the cart careened out of control. They might need help. You could diagram that Encounter as an Open Encounter puffy cloud with a box labeled ‘Help Oona,’ a box labeled ‘Calm the Horses,’ and a box labeled ‘Snake, A Snaake, It’s a Snaaaake!’

Later, the heroes encounter a corpse in the road, and they’re free to investigate the scene and discover information from the body, the road, and the brush beside the road. Again, it’s an Open Encounter with several intractable elements. In fact, the hidden backpack is technically one of those elements connected via a gameplay line to one of the boxes in the Open Encounter.

When I was designing the module, I was actually thinking in these terms. This ain’t me describing my intuition in terms of Scenario Design. I deliberately chose to build Open Encounters and then thought about how the action would flow through them. I didn’t draw diagrams because I see this shit in my head and because they weren’t super complicated, but I could have outlined them.

As I said, though, I’ll have a lot more to say about this crap when it’s time to stop planning and start building. Because, remember, all this shit about Scenario Outlines is just you planning the things you’re gonna build. The Outline actually shows you what gameplay you’re gonna have to build and how you have to fit it together. It is useful to keep this crap in your head at the planning stage, though. That’s not just so you don’t have to come up with good ideas later, but also so that you’ve always got an eye toward varying the Shapes of your Encounters. If every Encounter is just a single box with an arrow coming in and an arrow going out, you’ve built a boring-ass Scenario.

Which brings me to my closing point…

The Difference Between Non-Linear Gameplay and Open-Ended Creativity Bullshit

A few lessons ago, I brought up Open-Ended Creativity Tests. Do you remember that? That’s what smarmy, self-important Game Masters mean when they say, “I don’t create games; I create problems.” It means they can’t be assed to design playable games, so they just throw shit at their players and blame the players when they can’t play it. It’s dropping a too-powerful dragon in a room and saying, “If the players don’t recognize they’re outclassed and come up with a way to escape, it’s their own fault their characters die.” It’s dropping a river across the players’ path and saying, “The players have to find a way to cross the river or else the game just stalls there, and that’s their fault for sucking so bad.”

See, in some communities — especially so-called old-school communities — this is what people think roleplaying games and player agency and open-ended gameplay are. That’s because the people in those communities are elitist, mouth-breather fuckwits.

Roleplaying games are what they are. They’re open-ended by nature. Game Masters know that. They know it’s their job to make the open-ended happen. Game Masters who don’t know that are doing it wrong. That’s not the fault of roleplaying games, but rather it’s the fault of the suck ass Game Masters doing it wrong.

If there’s an ogre in a room, even if it’s not explicitly stated anywhere in the module text, the players can decide to parley or sneak or whatever. It’s the Game Master’s job to decide what’s possible based on the information they have and their own best judgment and to resolve the players’ actions. Thus, every Encounter, Scene, Adventure, and Campaign always has an assumed, “… or any other reasonable approach the players conceive of and attempt to execute,” built in. The players can try anything. The Game Master can adjudicate anything. That’s what a roleplaying game is. That’s the Game Master’s job.

Your job, as a Scenario Designer, is to design a Scenario that is not just playable, but also challenging and satisfying and engaging, even when the players aren’t brilliantly creative MacGuyvers. Because most people aren’t, and even the ones who are, they aren’t all the time. Thus, you’ve got to deliberately design Encounters to invite different approaches or give the players choices.

You absolutely can just drop an ogre in a room knowing full well that if the players want to sneak past instead of fighting, the Game Master can handle it. But there’s a difference between doing that and deliberately building an Encounter like the one I outlined above that invites the players to choose between fighting and sneaking and gives the Game Master the tools to handle both. Bonus points if that choice impacts the Adventure beyond that one Encounter.

This, again, is something I’ll come back to when we start doing Actual Encounter Buildery, but do take note of how just seeing that Outline of the Sneak or Fight Encounter made you think differently about what that Encounter might look like. Note what questions the Outline raises. How do you tell the players sneaking is equally as viable as fighting, here, for example? How do you handle the transition from sneaking to fighting if the ogre spots the heroes? What might be different in the next Encounter because the heroes chose to sneak or fight in this one?

That’s the true value of all this outlining shit. It’s not about following a process or a formula. It’s not about categorizing and defining things. It’s not about getting things right. It’s rather about how drawing a Scenario Outline makes you think about your design and how what you think about your design shapes how you draw your Scenario Outline. And how all of that affects how you build the shit you’re designing when that time comes.

And now we’re ready to move on from Scenario Shape.