Essentially, the talk boils down to the difference between this (page 49 of the pdf):
and this (page 50):
The two slides illustrate the exact same “facts”, but anyone who isn’t a C programmer can’t understand the line (((C_orb*)), while it’s a bit easier to parse “MagicOrb.charges = 12” (It means the magic orb has a property called “charges” which is equal to 12).
However, the big difference is that the first slide needs to be embedded in the game logic - which, as the talk points out, means only programmers can go in to add places for dialogue to get triggered. This results in a “homework assignment” for writers, where they go fill in the places where programmers thought there should be dialogue. Obviously, that’s a problem:
In a lot of games, the AI programmer looks at all the events that happen to a
character and tries to guess, “Well, for which events would this character want to say
something?” The programmer puts in code hooks for each of the sites he can think of
and then hands the writer a big spreadsheet and says, “Okay, fill out a line for each of
these events.”
Well, the problem with this is you’re basically reducing your writers to filling out a
series of mad-libs. That kind of cramps their style. It also means that it’s really the
programmers doing the writing, and the intersection between the set of good
programmers and the set of good writers is pretty small (unless you’ve got Vernor
Vinge or Ted Chiang working for you).
Also, any time the writer finds a new circumstance in which she’d want to have a line,
she has to go back to the programmer and ask for a new code hook to be added.
That’s slow and it means less stuff gets written, so we really wanted a way for writers
to decide which circumstances got lines and how finely those lines were specialized. (pdf pg 46)
So Valve ends up solving this problem with a tool for its writers. The tool strips away the complexity of programming and ends up exposing all of the facts about the world. Then the person writing the tool talks to the writers to find out how they want to edit scripts (e.g. a database program or Excel or a fancy graphical tool). This way, the writers have a tool they can use practically that gives them the information they need. The result is dialogue that is varied, interesting, and not limited by how many times a writer goes to the programmers and begs for additional writing cues to be added.
End Summary.
The idea is basically the right tools for the right job. In this case, programming tools aren’t the best tools for a writing job. The corollary is Valve has great dialogue in part because their tools allow for great dialogue to be written. It could be done the complicated way, but it’s faster and easier to do it this way.
The tools we use shape the end result. Better tools lead to better results. The trick is spending the time and effort on creating the right tools for the job.
