In your recent Kickstarter update, you talked about your work on area design. You mention how you divide planned content into the A, B or C priority, in order of importance. Can you tell us more about the procedure behind this?
George Ziets
It is fairly common to classify content in this way (at least at the studios where I’ve worked). The goal, essentially, is to ensure that the most important content the stuff that is critical for the player experience to make sense gets created first. Different studios define A, B, and C content a little differently. For us, A means that a particular piece of content is critical and will be implemented no matter what. A basic guideline is that if we create only the A-priority content, but we do all of it, then we feel the game will still be great. B content is lower priority, but we assume we will make it, and we include it in the production schedule. C content would be nice to have, but we assume we will *not* make it, and we don’t include it in the schedule. However, if we find that we have a little extra time, we can consider implementing the C content later.
Having said all that, let me give you an example of how it happens in practice.
In my initial design pass on the Bloom, I didn’t worry too much about prioritizing content. My goal was to generate as many cool characters, locations, and ideas as I could. (If I start prioritizing things too early, I find that I focus too much on the content that I *think* is going to be A-priority. when in fact, priorities often change over the course of development. A location that I assumed would be B- or C-priority might become so interesting that we shift content around to make it A.)
Once I had a fully developed zone brief with lots of interesting content, I started looking at everything with a more critical eye. Was a particular piece of content required to tell the main story for the zone? If so, it became A-priority. I also wanted to make sure that the player had multiple solutions to the main storyline quests, so any content that offered those alternative solutions also became A-priority. This meant that the A content could, if necessary, stand on its own – it didn’t rely on us creating any of the B content. This meant that we could more easily cut the B-priority content later if that became necessary. (When you do cut content, you generally create some extra work because it impacts things you’ve already implemented. One way that prioritization can help, if approached in this way, is by making it easier to make certain cuts with minimal impact on what you’ve already done.)
Sometimes I made priority decisions based on location. For example, some of our side content had little bearing on the player’s particular story, but it helped fill out an A-priority location, so it got marked as A-priority too.
Everything else became B- or C-priority. But B vs. C is still a difficult choice. As I mentioned above, we assume that we won’t be making the C content, so when we designate something as C, we’re preemptively cutting it. This can feel a bit cruel to your lovingly-crafted characters and locations, but after you’ve been working in games for a few years, it becomes a little less painful. Sometimes.
In the Bloom, I started with a total of twelve locations ((scenes)), the largest of which was the Vast Interior. (If you saw my Kickstarter update, the accompanying blockouts depicted an earlier version of the Vast Interior.) Eight of those scenes contained some amount of main story content and were marked as A. Two others were not imperative for the story but further developed the narrative for the zone, so we marked them as B. Two more were really cool, but we (Colin, Adam, Kevin, and me) all agreed that they would cause the least damage to the zone if cut, so they were marked as C.
In some cases, we liked (or needed) specific elements in the C-priority scenes so much that we relocated them to other parts of the Bloom. For example, Chris Avellone liked one of the cyphers I’d designed for a C-priority scene and wanted to incorporate it into his companion’s arc. So that cypher received a last-minute reprieve and will now be moved to an A-priority scene. In another case, Jesse and Colin had a great idea that would extend one subplot in the Bloom (and provide us with a setting for one of our Meres), which led me to add a new B area. It was a natural extension of the original design, but not an element I had originally chosen to include.’‹
InXile chose turn-based combat for Torment: Tides of Numenera, largely because of the Crisis system, as I understand it. This seems to have certain implications for encounter and area design. For instance, in the post-combat vote update, Kevin Saunders mentioned how a bigger focus on ranged combat could alleviate some of the encumbrance of turn-based combat. Could you tell us more about how to design areas with Crises and turn-based combat in mind, as opposed to RTwP?
Jeremy Kopman
One of the main goals of the Crisis system is to offer the same breadth of choices and possible actions as you’d have in a tabletop RPG. In a tabletop game, if you find yourself in a stand-off with a mercenary squad on a dock you might ask your GM if your character can to attempt to operate a gantry, sending its load of logs crashing down on your opponents. In a TTON Crisis set in a similar area (just an illustration, mind you, not an actual area in the game), you’d be able to use character Skills related to machinery or deft movements as assets in a similar attempt. Or you could use an esotery like Flash to cut the gantry’s line remotely at the cost of some Intellect Stat Pool points. In addition, the space might be laid out so that knocking down the crane blocks a door into a tunnel that would have allowed characters to unlock it with a successful Task and pass through without engaging the mercenaries directly. Meanwhile, a more socially-oriented character could first lower the gantry slowly to the ground, then use their linguistic skills to convince the mercenaries to steal the load of lumber instead of attacking. Or you could go for a tactical assault and use the crates and machinery on the dockside as cover and hiding spots.
Crisis areas are laid out to support all of these options (though it’s important to note that every play style may not be perfectly suited to every Crisis; in some cases, a particular style might be very difficult to employ and encourage you to use unfamiliar options, but no play style will be favored over another across the game). As a result, Crises occur in complex areas that are large enough for such tactical decisions, and often with many paths that can be opened or closed with interactions like those described above.
As to the question about the pacing of the turn-based gameplay, besides just an emphasis on fewer, but more carefully designed encounters, we’re investigating several possibilities to refine the flow to ensure that it doesn’t drag. One such possibility is a class of character abilities we’re calling Defensive Maneuvers. These are off-turn actions that the player can activate, spending Stat Pool points to set up triggered attacks, counters, and other reactions. The simplest of these function like an Attack of Opportunity (or the Overwatch/Ambush actions in XCOM/Wasteland 2). Others allow the PCs to counterspell esoteries, heal party members who fall below a threshold, or redirect an attack on an ally. These abilities keep the party active even on an NPC’s turn. We’re working on the UI to make them as intuitive and fast to use as possible.’‹
