In the GI interview you said you’ve been reinforcing the bad habit of reactivity as “a lot of special cased scenarios to test rather than true systematic reactivity”.
Do you think “special case-y” reactivity is inherently bad, or did you mean the fact it pretty much dominates the genre and you wish you’d done something different?
Also, what are good examples of true systemic reactivity?
This one he ended up answering
here.
In several interviews you mention a style guide you wrote, and it sounds immensely useful. Is that a general guide available somewhere or something specific from a previous project?
On the Style Guide thing, there's been a lot of random discussions about it lately, I may end up posting one for a specific project (although it would include general ones/rules as well). I've written about 5-6, I think, and they date back to the Black Isle days when we first used them to standardize text (we kept iterating on them, so they've grown over time and depending on the project).
It's one of the Creative Leads jobs to write the guide so every writer knows the conventions, hopefully before they start writing - and QA can use it as a testing plan for text bugs.
[This was before he released the Overfall guide]
What is the one advice you wish you’d known earlier in your career?
[I sent the following later]
Actually, ignore that, I was reading an older interview with you and you had already answered that.
"If you don't have something nice to say, keep your mouth shut", if I recall correctly.
"If you don't have something nice to say, keep your mouth shut." I'd clarify this is that this should never prevent you from making an informed, polite critique. I may have mentioned this in the Design Lessons presentation but it's the difference between "opening doors in your games sucks dick," vs. "I'm used to the Door Open/Action command always being mapped to the A button on the controller, so whenever I hit a door in your game, I have to mentally switch to the B button to do it, which feels counter-intuitive for a game of this type." If that makes sense
I used to work with a lot of people that were afraid to speak out because they'd be seen as troublesome, but I always tried to encourage them a well-thought critique isn't being an asshole, it's being helpful and the end state of the game and its success depends on everyone weighing in. (Forgive typos, it's late)
On the converse of this, devs also need to expose themselves to brutal critiques and then attempt to drill down to try and figure out what the problem is that's causing the player's frustration (that's part of a dev's responsibility). Past the bile, you need to recognize someone was frustrated or disappointed - try and figure out why.
You said in one interview that you don't always write lineraly. This reminded me of GRRM's argument about "gardeners and architects". He says gardeners know roughly where they want to go, but flesh out the story as they go along, while architects carefully design and outline the story and the plot beforehand. He never said it, but in some interviews I get the impression that he believes being a gardener is better for a story.
Ironically, his failure to anticipate problems with the middle of the story caused him to delay the end of his magnum opus for more than 10 years already.
Do you believe in this distinction? If so, how would you define your approach?
I'm a high-level architect for major story beats in the first month, but those beats are often the choice (gardener) moments. I do agree that sometimes making a game storyline too rigid prevents future opportunities for great content, and it can also make the player's experience restrictive, too. Ideally, I prefer to do critical path story touchstones, and then let other writers and area designers flesh out the material surrounding it to support it.
I
n two cases, you were effectively the Project Director, Lead Designer and Lead Writer at the same time, which means no one above you in the team's hierarchy. Still, at the end of the day, there's a story you want to tell and work very hard to put in the game.
How do you deal with so many aspects of the game's development at the same time without having the story suffer for it?
Let's say you're in the late development cycle. You decided to split the game in 5 major portions, but the 3rd ends up much shorter and/or below the quality of the rest. How would you handle that? Salvage and repair what you have, cut that part and try to connect parts 2 and 4 with a few changes, or rethink the whole section?
I would evaluate if the "shorter" portion is still good (longer isn't better), but if the quality is sub-par, I would likely cut it - players (including myself) are more likely to forgive a shorter, better experience than a longer, uneven one... and one could argue that in today's game space it's "lulls" in content that cause people to step away from the game and never revisit it. For example, there would have been areas I would have advocated cutting in F2 (including sections of my own areas) to improve the experience.
One quick question: I found this list of tips for PS:T in an archived version of the game's original website:
http://planescape.outshine.com/official.planescape-torment.org/oldnews/chris_1208.html
I've always assumed it's from you, but it seems to be listed under posts from the "Artists". Was that you or is that another Chris from the team?
If I had any doubts it was me, they were dispelled by #4 (running was my trumpet call).
Only other artist Chris, was Chris "Wu-Tang" Jones, who didn't write this - he's doing some other KS project now, I think?
Also, in another interview you said you were willing to write more stuff for D:OS2 if they wanted. Did that happen? Some people were speculating that you got your role expanded, since you're doing the media tour with Swen and all
Divinity: The agreement was story reviews (which I've done about 6+) and writing the origin story (background, not dialogue, but I think dialogue's on the table if we want).
