Ah, the honeymoon stage. Eventually, Fargo will realize that the "easy implementation" will dramatically spike in difficulty.
Yeah, coz he's never produced a game before, yeh? It'll totally come as a shock to him that they're complex things.
I don't like this interview much either, particularly citing page-counts as if that means anything other than "we're progressing well", but if we're going to criticize, it should at least make sense, not just be for the sake of criticizing.l
My name may not be featured prominently on the back of an Interplay CD, but I've traced the steps he's going through - writing a Fallouty quest/dialogue system, over many months - and there are no shortcuts in that area. His statements show that his current attitude toward implementation is disconnected from reality.
I recognize this, because mine was. Most everyone who starts writing an ambitious RPG thinks that they can do dialogue/quest branching with a mostly linear series of if-then statements. Or, in worst case, a clearly traceable tree with these obvious branches.
They are, of course, wrong. Even utterly retarded shit like Bioware dialogue(flat structured/same outcomes) and quests(controlled by linear hubs) has a complex internal structure that took serious manpower to maintain.
And Fallout-style structures? A nightmare. It only looks simple on paper, which is where Fargo's still at.
These are the problem areas with Fallouty quest/dialogue design:
- The quest/dialogue variables/triggers/references create a crumbly sandcastle of codependencies. Even with tools, it is challenging to introduce changes. Without automation, it is only possible when you have the kind of teams that Fargo worked with before - sizeable ones. You could offload menial everyday tasks to the software equivalent of those low-wage Disney animators who drew the stuff between the important keyframes.
Changed the location of the macguffin? They'll take care of NPC speech now saying it is in the shed instead of the bedroom. And go over a few dozen script triggers that checked for its presence in the bedroom closet.
Currently Fargo does not have the luxury of offloading such tasks. With a small team, they have to be really, really automated with some serious tools, tools which go beyond token editing and into the territory of intelligent compilation.
- Maintaining sync between documentation and in-game implementation, within an engine that is still being written, is a nightmare. One constantly affects the other, and there's a slew of microupdates bouncing back and forth every day, because the engine never exactly fits the written word. Document dictates changes to the engine(the quest goes like this!), then the engine strikes back (it can't be done this way, so the quest has to be altered!) and dictates changes at the document. Then you realize the document has the same codependency issues as the engine data itself, and changes to documented quests and dialogue affect their brethren...
The correct solution is to use a tool that keeps track of documentation in sync with its implementation in-game. Otherwise, see the aforementioned manpower problem.
I don't know how long it's been since Brian Fargo gotten his hands dirty with actual code, and especially code that involves the kind of mechanics present in Fallout, which, as he previously made clear, he aims Wasteland 2 to be like.
The design, from a narrative perspective, is just a lot of if-then statements. So we can just write our hearts out and it will go in easily.
... but he sounds like he doesn't get it yet.
OR, he understands everything, and already changed his mind about making it Fallouty, instead going for the kind of "procedural non-linearity" that the games he mentions - GTA, Sim City - represent. With a story that is explicitly told to you, rather than being made by you. One that's being measured in "pages".