Posted On: 2020-04-20
One of the interesting quirks of writing for a game is how the writing and the game state intersect with one another. Game writing is constantly interpreting and expressing the game world's state; from a quest-giver that reacts to the player skipping an optional objective to characters shouting when they reload during a firefight, a game's writing is constantly connected to the game world in which it inhabits. As developers, the best approach for how to connect these two together is not always self-evident, so I thought I should write a bit about my own process to identify what works for my project.
As an independent developer working on both the writing and the game's code, I am in the interesting position of both including game state in my writing and also building the supporting systems that allow the writing to access the game state in the first place. As such, I find myself in a bit of a pickle: if my designs for accessing game state are too narrow, then I lose time both on the writing side (getting stuck) and on the development side (changing the design to be more robust). Conversely, if I over-engineer the design, then I, again, lose time on both sides (time spent developing and testing the over-engineered system as well as time spent using an overly-complex system as the writer.)
As with any development situation where I am unsure what the optimal scope is, I am creating a small prototype first, to get a sense of what data I need to access and what data I shouldn't bother with. Similar to the Magic Training Prototype, I am trying to stay on-script for this: the closer I am able to match what the game's actual script will be like, the more accurately I will be able to assess its various state needs. Unlike my previous prototype, however, I don't expect that I will be able to share this one: I am trying to test a sample of data from across a variety of the game's situations and contexts, so it assumes familiarity with a lot of omitted information.
As I work through these tests, I am finding a few additional benefits, as well as some downsides. The biggest of these - which fits both categories - is that this is pushing me to work through communicating using the various characters' voices. As I figure out which gameplay elements are relevant for each conversation, I am also trying to work out how the relevant characters express themselves in those conversations - and, along the way, discovering which characters are currently difficult for me to write. While knowing which characters are difficult to write is important, it is slowing down the prototyping process, and those difficult characters are less likely to accurately reflect their dialogue*.
Another side-effect of creating sample dialogue is discovering opportunities for improvements in tools and productivity. By practicing the process, I can watch for places where tooling improvements could lead to improved writing productivity. More importantly, I am seeing places where inaccuracy and human error could result in logic or behavior issues in the system, so I am also able to flag those as needing additional tooling support.
As a quick example that fits both rather nicely:
game state is stored in variables with arbitrary names (such as $HelpedTheFarmer). When I later use that variable, I find I sometimes have trouble remembering the exact variable name (I might put $AidedTheFarmer instead.) Having tools that help me keep track of the various variables currently in use would both improve my productivity and the system's accuracy*.
While it still remains to be seen exactly which pattern I will use for connecting game state to writing, starting with a prototype will should help ensure that the pattern I pick will reflect the reality of my needs. Along the way, I am finding opportunities to improve both my own skills and the tooling I use, so this is yielding benefits even beyond the original intent. Hopefully reading this has been helpful for you, whether you find find yourself in a similar situation, or perhaps merely as something of interest.