Torment Kickstarter Update #38: Environment Art, and an Introduction to the Obsidian Dialogue Editor
Torment Kickstarter Update #38: Environment Art, and an Introduction to the Obsidian Dialogue Editor
Development Info - posted by Infinitron on Thu 29 January 2015, 00:04:02
Tags: inXile Entertainment; Kevin Saunders; Thomas Beekers; Torment: Tides of NumeneraThere's a new Torment: Tides of Numenera Kickstarter update today, the first one of 2015. The update begins with a short description by Kevin Saunders of inXile's environment art production pipeline and an introduction to some of their new hires. It includes this concept art of an area in the Oasis of M'ra Jolios (which some of you may have already seen, ahem):
But the meat of the update is an extensive crash course from Brother None on the use of Obsidian's dialogue tool. I'll quote the most interesting parts of it:
For a dialogue-heavy game like Torment, a good conversation editor tool is one of the most important things we have. Figuring out our conversation standards and improving upon Obsidian's already great conversation editor was one of our first priorities in preproduction. I’d like to take you through some of the basics so you'll know what we're talking about when it comes up in the future.
The two most important concepts are nodes and links. Nodes contain the text you see in the game, and they form a structure by way of one node being linked to (usually multiple) child nodes.
[...] The writer can lock or unlock conversation nodes based on whether the PC meets certain requirements. This is done with Conditionals that can check for a variety of values such as whether the party is carrying a certain item, whether someone is in the party, whether the PC has spoken to this NPC before, etc. Using global flags, we can create conditionals for virtually any circumstance we want. For example a conditional might check if the PC has read a note that provided a piece of information that he can then confront an NPC with, or a conditional can check whether the PC was nice to the NPC's father way back in the beginning of the game, or (to give an example from this conversation a conditional Colin created here) tracks how much the PC knows about different aspects of the Bloom. It can also track the PC's motivations when we provide two responses with the same text, but with one a “(Lie)” and the other “(Truth).”
Because conversation reactivity is such a high priority in TTON, conditionals are one of the most important functions in the Obsidian conversation editor. They can check for an absolutely massive amount of pre-set scripts which can be found with a very simple search function; from checking for gender to attribute scores to skill scores to – of course – Tide values, added for Torment.
[...] The last feature I want to talk about for now is skill checks — known as Tasks in the Numenera tabletop game, and Difficult Tasks (DTs) in Torment. DTs were explained in-depth in Update 27, and you'll recall that, unlike in some game systems, anyone can attempt a DT — having relevant skills (or items or other situational factors) increases the likelihood of success, but is not required to try. The difficulty can be mitigated (or exacerbated) by many factors, including: previous choices, equipment, fettles, party members' skill values, or investing Effort from the relevant stat pool.
The writer simply assigns the “Perform Task” script to the node, selects a difficulty (using an abstracted value to aid in balancing later), the attribute from which Effort can be spent, and any skills that will make the task easier. The tool then marks the subsequent nodes as success, failure, critical success, and critical failure:
The writer adds text for each node and defines their results: advancing to another quest state (including completing a quest), setting a global variable, giving the PC unique rewards for critical rolls, or even causing self-inflicted injuries for critical failures (as currently laid out this conversation has only cosmetic reactivity for critical rolls; this may change in later revisions, hence the designer note in the Critical Fail node). But failures and critical failures aren't always bad, sometimes they are just unexpected outcomes that change the way the situation plays out.
What's to stop the player from just spamming the Task until she succeeds? A writer defines a node's "Persistence" in its properties. Many nodes – including some tasks – are “once ever,” meaning they only show up once and are never again an option. Another possibility for Tasks is "none" persistence, which means they will always exist, so the player can try again if they failed. However, if you try a Task you’ve already failed, you have to pay a Retry Cost (in Effort). This gives the player decisions about when to spend their valuable Effort pool.
But you should definitely check out the full update, if only to see the full size and scope of the dialogue trees we're going to get in this game. That's a Torment game all right.The two most important concepts are nodes and links. Nodes contain the text you see in the game, and they form a structure by way of one node being linked to (usually multiple) child nodes.
[...] The writer can lock or unlock conversation nodes based on whether the PC meets certain requirements. This is done with Conditionals that can check for a variety of values such as whether the party is carrying a certain item, whether someone is in the party, whether the PC has spoken to this NPC before, etc. Using global flags, we can create conditionals for virtually any circumstance we want. For example a conditional might check if the PC has read a note that provided a piece of information that he can then confront an NPC with, or a conditional can check whether the PC was nice to the NPC's father way back in the beginning of the game, or (to give an example from this conversation a conditional Colin created here) tracks how much the PC knows about different aspects of the Bloom. It can also track the PC's motivations when we provide two responses with the same text, but with one a “(Lie)” and the other “(Truth).”
Because conversation reactivity is such a high priority in TTON, conditionals are one of the most important functions in the Obsidian conversation editor. They can check for an absolutely massive amount of pre-set scripts which can be found with a very simple search function; from checking for gender to attribute scores to skill scores to – of course – Tide values, added for Torment.
[...] The last feature I want to talk about for now is skill checks — known as Tasks in the Numenera tabletop game, and Difficult Tasks (DTs) in Torment. DTs were explained in-depth in Update 27, and you'll recall that, unlike in some game systems, anyone can attempt a DT — having relevant skills (or items or other situational factors) increases the likelihood of success, but is not required to try. The difficulty can be mitigated (or exacerbated) by many factors, including: previous choices, equipment, fettles, party members' skill values, or investing Effort from the relevant stat pool.
The writer simply assigns the “Perform Task” script to the node, selects a difficulty (using an abstracted value to aid in balancing later), the attribute from which Effort can be spent, and any skills that will make the task easier. The tool then marks the subsequent nodes as success, failure, critical success, and critical failure:
The writer adds text for each node and defines their results: advancing to another quest state (including completing a quest), setting a global variable, giving the PC unique rewards for critical rolls, or even causing self-inflicted injuries for critical failures (as currently laid out this conversation has only cosmetic reactivity for critical rolls; this may change in later revisions, hence the designer note in the Critical Fail node). But failures and critical failures aren't always bad, sometimes they are just unexpected outcomes that change the way the situation plays out.
What's to stop the player from just spamming the Task until she succeeds? A writer defines a node's "Persistence" in its properties. Many nodes – including some tasks – are “once ever,” meaning they only show up once and are never again an option. Another possibility for Tasks is "none" persistence, which means they will always exist, so the player can try again if they failed. However, if you try a Task you’ve already failed, you have to pay a Retry Cost (in Effort). This gives the player decisions about when to spend their valuable Effort pool.
