On Alan Wake 2, I had several areas of the project I owned while also marking the start of my consulting on the internal dialogue tooling and systems.
In some ways, this was far too much for one person to own, but I think it speaks both to the scrappy nature of Remedy and my tenacity.
For all of these system and several others I had to maintain robust debugging views, but will not cover that on this already oversized page.
Gameplay conversations
An unobtrusive conversation system which lets players move around freely at all times. The basics were already designed when I started the project, so the focus was system creation, owning the implementation pipeline and close collaborations with Narrative Animation and UI.
Biggest challenges:
-
We had to descope the system from allowing players to leave while conversation dialogue was running as we didn’t have the tooling or time to handle dialogue continuations.
In the end we decided to confine the player to the "choice radius", the range at which choices are displayed, during dialogue. No player expressed an issue with this but I’ll always imagine the ambitious ideas we once had!
-
Transitioning characters from AI locomotion or to/from non-conversation idles; handling players coming and going; item exchange animations. The lack of tooling for all this meant everything had to be high-wire act between narrative Lua and animation timelines.
-
This was a challenge for all systems and always required careful thought about what needed to be saved and when.
Triggered dialogue
The meat and potatoes of the dialogue in Alan Wake 2, triggered dialogue is any dialogue played in response to player action, position or story development (outside of NPC combat barks and cinematics). I split this into two streams of dialogue: the Queue and the Hub.
Dialogue Queue
The queue is for any player-facing dialogue. We only ever want one piece of critical path dialogue to play at a time, and the queue ensures this dialogue is played as defined by dialogue priority and order of its queue addition. The queue ensures dialogue relevance, salience and persistence, so that only dialogue which is appropriate in that moment will play and will never play again.
Dialogue Hub
The hub is for any other dialogue which plays but is not essential for player comprehension of the story. Generally this is NPC chatter which might overlap with narration or a PC conversation. The hub also ensures relevance, salience and persistence of the dialogue.
Due to the overlapping nature of the Queue and the Hub, I would put them both in the same system in the future, but this wasn't possible in the time constraints of the project.
Biggest challenges:
-
We didn’t use timelines for this dialogue as our lead wanted to use a solution which would not require localisers to match dialogue lengths exactly.
This meant we had to use dialogue chains, a system which calculates the duration of a dialogue event and will fire the next in the chain after that period. It's a horrible Frankenstein's system built on top of a dialogue bark system which had perhaps the worst UX I have ever experienced.
I believe we lost more time on this than we would have spent on matched localisation.
-
Triggered dialogue relied on an old, arcane dialogue system which no coder at the company was familiar with any longer and this meant that often start and end callbacks (the events from C++ which drive the system) wouldn't fire. This was more of an embarrassment than a challenge but, as you can imagine, in a game whose logic is so often driven by the completion of dialogue, this was a huge blocker at times
-
Making a relatively non-technical, user-friendly Lua template for all narrative designers to add animations to dialogue chains; ensuring timing, transitions and attachment of animations at the correct times and across saves
-
Dialogue pacing is everything and so triggered dialogue required many different timing techniques to ensure dialogue played when and how we want. Concepts like playback delay, minimum delay, countdown, expiration duration and completion loop became essential grammar in our dialogue Lua script
Ambient dialogue
Non-critical path NPC conversations which play when the player is within a large radius around them. Only one ambient dialogue conversation plays at a time but, optionally, a group's conversation can be triggered instantly when the PC enters the radius for the first time.
Biggest challenges:
-
Ensuring the Ambient dialogue logic ran nicely alongside Triggered dialogue, Gameplay Conversations and other systemic dialogue systems was a balancing act.
-
Playing animations based on ambient dialogue was tricky as it used the same dialogue chain system as the Triggered dialogue system above, meaning no timelines and no ability to scrub through dialogue. The data also had to be contained in Lua, in a format that was approachable and maintainable by non-techie narrative designers
Generic dialogue
The generic dialogue system contains two sub-systems: reactions and prompts.
Reactions
Reaction dialogue is player character dialogue in response to common PC actions, such as failing to open doors, going out of bounds, or an incorrect answer to a puzzle. The system makes sure this dialogue is not played too often and is only played when relevant. Contained in the Reaction sub-system is the PC combat bark logic, which ensures individual player combat lines are only played once per encounter, only when relevant and not too often.
Prompts
The prompt stream systemically plays player character suggestions to push the story forward, prompting players to engage with whatever is relevant to the current mission (e.g. case board, profiling, plot board etc.).
Biggest challenges:
-
Ensuring that Generic dialogue played in an immersive but unintrusive way was difficult and required a lot of playtesting and fine-tuning.
Prompts in particular had to be played with great restraint.
-
Similarly to Ambient dialogue, Generic dialogue logic had to run nicely alongside Triggered dialogue, Gameplay Conversations and other systemic dialogue systems.
Other features, systems and responsibilities
Generic animation
I made a generic system for any narrative, level or mission designer to play simple animations on the player character (e.g. scared reaction, phone call animations, pass under obstacle etc.).
Before this, every animation required an object placed in the level to hold the animation components, and a bespoke script calling the required animation. Eventually I had to take matters into my own hands.
Echo scenes
A wonderfully thematic piece of design I got to implement in close collaboration with a VFX artist. Players have to align two halves of an eclipse to unlock story elements. A surprising amount of maths was required to calculate all the values to determine alignment position and rotation.
Complex setups
Alongside the thousands of setups and dialogue lines I implemented, I specialised in complex setups involving interlocking features and systems. For example, walk-and-talks with AI NPCs, confined areas with many Gameplay Conversations dependent on each other, puzzle hints (this was the most complex as we wanted to be helpful but avoid a God of War situation).
Onboarding
The tools were old and byzantine, the pipeline was convoluted, and the setups were long and tricky. Part of why I kept refining and simplifying how we implemented narrative content was because I had to be the one to onboard new team members or trusted externals.
The onboarding process began with a long presentation and then lasted for several weeks.
The trauma from these tools has borne fruit as much of these issues have now been resolved with a new engine version and tools.