For a while now, some of you have been asking when we’d be transitioning from preproduction to production. With Wasteland 2’s recent early beta release, you may be aware that the inXile team will be spending more time on that game to get it done right—one of the fundamental benefits of Kickstarter is that we have the direction from our backers to emphasize quality over punctuality. This decision impacts Torment because most of the production team (e.g., programmers, artists, animators, etc.) will be moving onto Torment later than originally expected, which means we’ll be in preproduction for a longer period of time.

Believe it or not, this is the best situation from the perspective of Torment. When you’re in production with a large team, trying to incorporate any new idea can result in a lot of wasted work and confusion. (An “idea” in this sense could be many different things: an improvement to how conversation data is authored that enables a new type of dialogue reactivity, a new technique for handling shadow-casting lights in environments, a major change to an existing companion that improves the overall party dynamics, etc.) So when considering the new idea, you either accept this negative impact or discard the idea.

With a small preproduction team, the negative impacts have a smaller effect and the values of the ideas are more about the benefits they provide. Fewer people also means fewer miscommunications and greater flexibility both to experiment and to iterate. The closer you can get to your final design and technology before you are creating content at a rapid pace, the better the final result will be. So extra preproduction time is very beneficial, as long as you that time includes prototyping in-engine and iterating on the design instead of expanding the game’s scope.

We approached our preproduction aware that we might begin production later. On a traditionally funded project, you can ultimately be forced to make some decisions that you know are bad for the overall project to meet a specific schedule, but because we are free from external milestones, we can flexibly adapt, keeping our focus on the overall quality of the final game. It can be challenging to think that far ahead, but it’s even more challenging if you have rigid short-term goals binding you.

It’s true that if you just extend preproduction without any making any other changes to your plans, you’ll go over budget and over schedule. But the productivity improvements you gain through a longer preproduction period make up for the added cost of having a small team in preproduction for longer. (This is one reason, for example, that expansion packs are much cheaper to make than full titles – the development cycle for the original title is effectively part of the expansion’s preproduction.)

We’ll let you know if we ever determine that Torment’s release will be delayed beyond the first half of 2015. Thus far, our extended preproduction has been a very good thing and at this time I don’t anticipate it will push us out of that release date window.
​

As the Creative Lead on this project, it’s my job to make sure we don’t settle for “good enough” on the story. To that end, we took the original story, examined its component pieces, and reassembled it in a different (and better) configuration. We kept all the elements we described in the Kickstarter—all the characters, all the items, all the *everything* except the fine details of the narrative. This was a reorganization of our elements in a way that is more focused, clearer, and more entertaining.

Which is to say, our original story was good, but now (if I may be immodest for a moment) I think it’s pretty great. With the combined talents of Adam, Kevin, Chris Avellone, Tony Evans, Nathan Long, and George Ziets, it had better be.

Anyway, as I was saying, much of what we were doing was hammering down the last stray nails of the upgraded story and making sure that we are ready to bring our outside writing talent to bear on a number of different areas at once. We now have a unified set of documents that will bear the combined scrutiny of some excellent writers, effectively share our vision for the story, and help us gauge the player’s experience throughout. These are our Story Spines.

That sounds a little creepy and maybe a bit murder-y, so let me explain what I mean: a spine is a firm through-line of the story, the pieces on which the rest of the experience hangs. The first and most important is the PC’s Spine. This is the narrative of the game as experienced by the PC (and thus you, the player), from the very beginning of the game to the end, laid out from point to point. We took our design doc and stripped out all the extraneous details and the information that the player might never know—even if this was information that would inform the motivations of the other major characters in the game, if the player didn’t know it at the time, we moved it to where the player would learn it or removed it from the PC Spine altogether.

Doing this exposed some potential problems in the plot of the game, and it was invaluable to us in making sure we have written a whole and cohesive through-line for you to experience. We did the same thing for other major characters in the game: what’s their history? What do they know, and when do they know it? What are they trying to achieve at any given moment in the story?

We had these spines written and ready for the meetings we had in November, with significant input from George and Tony. Then we borrowed the talents of Chris Avellone and Nathan Long to tear them apart, and we rebuilt them again—faster, stronger, better. After making sure we had all these details fully ironed out, we had several more meetings, in which I gave a summary of the improved game to a variety of teams, starting with Brian Fargo and Matt Findley. After that first meeting, Brian said (and I paraphrase): “This is awesome. This is the story for this game. Go.”
​

As you may recall from our talk about dialogue, skills work differently in Numenera than in most RPGs. In Numenera, skills don't define what you can do, but they do make success more consistent in related tasks.

Instead of designing with skills in mind, we design the tasks first. Anything you want to try to do – lie to an Oorgolian soldier, activate a long-dormant intelligence, manipulate an unfamiliar beam weapon, or dodge the lethal bite of a steel spider – is considered a Difficult Task. Every Task is assigned a difficulty level, a stat the Task is based on (Might, Speed, or Intellect), and an optional skill (or skills) that can apply. (In the tabletop game, difficulties range from 1 to 10; unmodified difficulties from 4-6 are tough (> 50% chance of failure), and difficulties of 7 and up are impossible without the modifiers discussed below).

Skills have four levels (Inability, Untrained, Trained, and Specialization). Training in any applicable skills lowers the difficulty by a step and specialization lowers it another step. (And as you might imagine, inability increases the difficulty, though inability is something you have to specifically choose through perhaps your descriptor or focus, and some skills don’t go lower than untrained). You'll notice that tasks at the highest difficulty are impossible even with specialization. Either multiple skills would have to apply to such tasks, or there must be another way to lower the difficulty.

And there is. In Numenera, another way – at higher levels, the primary way – to reduce the difficulty of a task is Effort. You can apply Effort by using points from your related Stat Pool (Might, Speed, or Intellect), up to a maximum Effort level determined by your character’s Tier (or level). Each level of Effort you spend lowers the difficulty by one more step. (There’s another stat called Edge that reduces the cost of using Effort, making lower-level tasks easier or even free as your character advances, but that’s a topic for another time.)

What this means is that anyone can have a chance of success at most tasks, if they're willing to spend their resources on Effort. Characters with applicable skills do not have a monopoly on related tasks, but they do have two advantages: they conserve their Stat Pools (saving Effort for the tasks that really matter) and they have a greater chance of success at previously impossible tasks.​