This week we wanted to share a bit about our writing process.
As we’ve said before, we like to work from writing first. But usually we have to start somewhere, and that usually happens in the inspiration stage.
When we decide what we want to work on next, we start brainstorming the kind of story we want to tell. Narrative is what drives our inspiration for any given project, so if we can’t think of a story we want to tell or are able to tell, then we move on to something that resonates with us before anything else.
For Psychroma, we knew we wanted to make a pixel side-scroller with psychological themes. We also knew we wanted to set it in the Cyberpunk future. We thought it would be interesting to take the classic haunted house idea and add a new cybernetic twist to it. We thought of some of the horror media that inspired us most and took themes from them. one example is The Haunting of Hill House – the haunting of each character has a directly personal relationship to them and their insecurities and fears. We love the idea of “personal ghosts”, and so we aim to include that in the story of Psychroma.
As well as taking inspiration from horror media, we also looked at Cyberpunk/retro-futurist media that really inspire us. One miniseries that came up a lot was Netflix’s Maniac. We were intrigued by the premise of a pharmaceutical trial involving mind-altering drugs and a senscient A.I. going terribly wrong. The inclusion of mental illness and it’s effects on interpersonal relationships was the theme that gave the series a heart, and we wanted something along those lines for Psychroma. Finally, the imagery and set design of the show was visually unique in a way that we want to replicate in our design philosophy – the soft pinks and muted greens of a retro-future 80s that never happened.
After we have an idea of the themes we want to explore, we set to brainstorming the elements that make up a story – things like the setting, the lore, the characters, the conflict/mystery, and the resolution.
In the past we have worked from the beginning and settled on the ending after months of outlining and writing drafts. This time however, we knew we needed to include a mystery element to the story to help drive the player to the conclusion. Therefore we needed to work backwards and settle on a resolution that would feel narratively satisfying first. Working backwards allows us to see the elements of the mystery and plan how to dole out the information the player would need to solve it, as well as edit the pacing of the overall narrative.
With Raptor Boyfriend, one of our biggest mistakes with the writing was focusing too heavily on narrative details and jumping ahead to the story beats before we really knew the overall story we wanted to tell. This time around, we wanted to make sure we kept a lot of writing loose, do more first pass writing and focus on solidifying the overarching elements before jumping ahead to outlining. This meant a lot of in-person discussions and ideas possibly being thrown away. We had to learn to be okay with not going with every idea we had for the narrative.
By this stage we have solidified a lot of the story elements and are now ready to start planning the story beats we want to hit and think about things like pacing, scope and narrative details such as character dynamics and tone.
We do the majority of our outlining during in-person writing meetings. We like to work closely together at this stage because it is a very critical step to getting the first draft writing together as well as planning the gameplay and level design. With Psychroma, we have to think about the outline as a living document that not only represents story beats but also serves as a rough guideline for the programming. Every story beat we want to include there also has to be represented in the code in some way, whether it be a room, a character animation or a dialogue choice.
We are still striving to keep things loose with the understanding that we may have to do several passes at the outline. We also have to break down the outline of the overall game from the prototype outline, since we know we can only focus on a small slice of gameplay before going into the scope of the full game. For the prototype outline, we ended up re-writing it 3 times!
After writing a pretty loose outline that we are all happy with, we then assign homework for the lead writer (Rowan) to start getting a more detailed breakdown of events together, solidifying our work and creating a kind of roadmap to start building out the code and writing dialogue. This is the part where we start utilizing tools like Twine and Arcweave, which are super helpful in terms of throwing together a quick text-adventure version of the prototype. This step helps us make decisions about pacing and how it would feel to play through the events in a non-linear fashion, which will then affect coding.
Now we are down to the nitty-gritty. There is often a lot of work to be done at this stage, which requires it to be delegated to the team’s homework. Here we focus a lot on tone, character dynamics and consistency. We almost always need to take several passes at dialogue writing with editing notes from other team members before we are satisfied, so we have to keep the writing flexible.
So far Rowan works on first pass dialogue using a casefile system that Titus set up, so that moving the dialogue into the game script is seamless and easy for the coder. As well as moving dialogue into the script, Titus builds out the shell of the prototype, which includes the rooms and the events strung together in the order they occur, often with interactable objects based on the level design and grey-box designs for any gameplay or narrative events that we still need to get together in the polish phase.
With our other projects, we were very adamant about getting the writing to 3rd pass before putting it in the game, but since we are working on a fast-track schedule for the prototype, we will need to get all first draft writing directly into the game script as soon as it’s done. This can be very nerve-wracking for us, since we are concerned about whether we are getting across what we intended or not, and therefore presenting an inaccurate depiction of the game. We will have to work on reminding ourselves that we will go back and change what we need to after we get some feedback from pitching the prototype.
This is the stage where you can start to see the light at the end of the tunnel in terms of writing. We’ve discovered from Raptor Boyfriend that you could be editing right up to the day before release and even afterwards!
Editing is usually a shared task that we all try to contribute to, since we all strive to reach an agreement on the final product of each element of the game. This stage can often be the most difficult, since it usually occurs during the final parts of development and the team starts to feel the effects of burnout. To mitigate any conflict or tension, we want to tackle the final edits in ways that will be easy to change or implement, and also will have little effect on the other elements such as gameplay, level design or animation. Keeping final edits to simple verbiage changes or single lines changed is the best way to do this. It may require the writer/editor working closely with the build, even going into the script and making small changes here and there. Because of this, build-sharing will have to be a part of our workflow process, something we didn’t have access to while working on Raptor Boyfriend. For now though, the prototype won’t need too much build-sharing to put together.
Thanks for reading! We hope you find this insightful/interesting.