Working on a large action RPG, we had pickup recordings for a non-playable character (NPC) with a handful of lines. Now, pickups are done for various reasons, including: change of script, e.g. to clarify something that was flagged in testing as confusing; to correct pronunciation, often for a game-specific word; to work with a gameplay change; or for incorrect performance.
In this case, it was the latter. The script was reviewed. The setting was clear from the quest name: 003_Castle_dungeon_prisonerB. From the dialogue lines, we could see the character was being held against their will and pleading with the player character to be released. From the player character’s lines, we could also see the player had the choice to let them go immediately, question them first, or just leave them there. This meant the NPC character had different responses to the player choices – relief, agitation, or desperation. So far, so good.
The lines had been directed and performed as if the character was being held captive, with escalating levels of stress for the various player choices. So, what was the problem?
These pickups were being recorded a good few months after the initial session and video was now available for context. The engineer cued it up and suddenly it was clear. The captive wasn’t just locked up in a dungeon; they were chained by their hands and feet to a wall and let’s just say not wearing a lot. This character wasn’t just stressed; they were speaking under humiliating and painful circumstances. The performance definitely had been underplayed.
The lines were re-recorded and satisfactory for the client. But as the dialogue lines had not changed, this was a preventable pickup session. So, how could the session have been avoided?
First, let’s look at what was working:
We knew our setting, a dungeon. This was both in the Scene description and Quest name*.
We had character descriptions for both the Hero and the Prisoner, which had been provided separate from the script.
We had some direction, e.g. “whispered”, “meek”, “screaming”.
And finally, the lines that branch off of the different player choices (“Cut chains and lead to safety”, “Question first”, “Keep moving”) were clearly separated.
*Note for actors and directors: A lot of information can also be built into filenames, so if you’ve not been provided a lot of direction and context, take a look at the filenames, they may give you some clues.
Now, let’s look at what was added to the pickup script: context.
Context should be provided in its own column and usually summarises what’s going on in the scene that’s relevant to performance. This may be action (e.g. fighting elbow-to- elbow, surrounded by comrades), circumstance (e.g. in empty field, no one else in sight), environment (e.g. shouting across a noisy & rushing river), or personal circumstance (e.g. helmet is cracked, with precious oxygen hissing out, on-screen display shows she has 40% remaining air).
While direction can guide the actor on the performance required, context can give them the Why – that important ‘motivation’ you hear actors talking about. For instance, in the last scenario, where the character is running out of oxygen, a line without any additional information, such as “All good here, I’ll meet you on the other side” could be read in a multitude of different ways, including upbeat and with confidence. Given the direction, “false confidence”, it may be performed as a junior, unsure of next steps. But given the same direction and the context that her equipment is failing, the performance could be far more moving and dramatic.
In our RPG example, lines such as “No, I am a prisoner, like you”, “You … are not a guard”, and “Here, have this” could be read in a number of very different ways without context. With the context, it’s much more clear.
And with the addition of the scene’s context, it could be argued that the line, “You … are not a guard” might need a second read (an ‘alt-take’) with more of a tone of relief rather than the surprise the direction column has suggested. This is where your performance director and actor can make interesting choices in session, based on the context and the rest of the character performance they’ve been working on. Perhaps this character is more likely to be relieved but then aloof, even in dire circumstances.
But the main point here is that without the additional context, the lines could be performed incorrectly, which, once combined with the visuals and actions of the characters in-game will really be confusing for the player.
Now, a handy reference video can cover a lot of this – we can see the field, the comrades, the river, the cracked helmet and visual read-out. But your pipeline may not allow for the voiceover recordings to wait for cinematics to be ready. Also, your budget may not allow for the time it takes to play a lot of reference files in your recording sessions. In most cases, having your writer take some time to provide context – which they themselves will have needed to write an effective script, will allow the actor and director to both be more prepared for the recording session and provide a convincing performance.
A few more basics for script setup:
Script in spreadsheet – it’s the format that allows for data analysis (e.g. line and word counts, which aid in good scheduling) and good tracking from pre-production through post and QA.
One type of information per cell – some writers like to put the directions next to the dialogue line but that skews the word count (see above) resulting in over-scheduling and inflated costs.
One column per type of information – keep this consistent across any additional spreadsheets.
Unique ID number – every single line of dialogue should have a unique number that never changes, even if the script does. This allows for script updates and pickup lines to be tracked correctly. This should also be separate from the filename, which may change based on game design, character reassignment, etc. For example, in the script sample below, the line was initially assigned to the incorrect character. During pickups, it was reassigned to the correct character. The line now has the corrected character name, which in this case has also changed the filename. But the unique ID number has remained the same, telling us the reassignment is correct.
Consistent character names – NPC names are especially susceptible to being inconsistently labelled throughout a script, as they are often a mix of character type and a number. It is so easy for the label to be changed slightly by different people contributing to the script prep. “Astronaut 1”, “Astronaut_1”, and “Astronaut_01” may look similar enough to you, but could be assigned to three different actors if not caught in time. Once those files are in game, your Astronaut 1 suddenly has three different voices across a couple of scenes.
Established script change protocol – Whether a line is added, amended, or reassigned to a different character, there should be a way of flagging this. Simple solution: add another column. If the script is small, just write in a note, e.g. “Luna Beach now called South Lunar Beach”. If your script is larger and may be put through checks with an automated system or set of formulas**, a simple code system everyone is aware of could be useful, e.g. PUP = Pickup Performance, PUC = Pickup Change (in game), NEW = new line, NA = no longer needed.
**Wondering why formulas may be used on script prep? Check out my previous post about reducing human error.
In general, the more pre-production, clarity, and consistency you can give your assets, the more smoothly your recording sessions will run. It’ll save you time, money, and support great performances. And that’s the goal here, right? For those performances to enhance the game you’re making.
