News - Blog: Developing procedural dialog in a game about tech support

News - Blog: Developing procedural dialog in a game about tech support - Printable Version

+- Sick Gaming (https://www.sickgaming.net)
+-- Forum: Sick Gaming Community (https://www.sickgaming.net/forum-1.html)
+--- Forum: Lounge (https://www.sickgaming.net/forum-8.html)
+--- Thread: News - Blog: Developing procedural dialog in a game about tech support (/thread-84984.html)

News - Blog: Developing procedural dialog in a game about tech support - xSicKxBot - 05-29-2018

Blog: Developing procedural dialog in a game about tech support

<div style="margin: 5px 5% 10px 5%;"><img src="http://www.sickgaming.net/blog/wp-content/uploads/2018/05/blog-developing-procedural-dialog-in-a-game-about-tech-support.png" width="646" height="363" title="" alt="" /></div><div>The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community. The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
<hr/>
Tech Support: Error Unknown is a rapid paced puzzle game in the vein of Papers Please. Presented entirely through a computer interface, the player is contacted by customers through a chat dialogue interface where they try to establish what the customer’s problem is and offer solutions relevant to the situation. The genre blends quick execution with detective work to interrogate customers and understand situations properly.
Over the course of a game, a player will interact with 200 to 350 different customers, many of which will have similar problems such as their phone not turning on, a broken screen or simply trying to change the wallpaper. Interactions generally involve between 10 to 20 lines of dialogue on the customer’s side.
Because of the fast paced nature of the game, I avoided using a text parser in favor of a macro system offering a series of questions and solutions. New options gradually unlock over the course of the game, but every unlocked option is available to the player at all times during a conversation, meaning the customer must be able to account for every comment and react accordingly.
<img alt="" src="http://www.sickgaming.net/blog/wp-content/uploads/2018/05/blog-developing-procedural-dialog-in-a-game-about-tech-support.png"/>
Having such a wide range of dialogue options pushed me to create a system that would merge various tricks to make conversations flow naturally and as uniquely as possible. I also purposefully limited the choices available to the player, to ensure that most responses would be applicable to more than problem, even if they’re not always the correct answer. Towards the end of the game, the player access to over 25 replies, to which customers must be able to react in a natural and unique fashion.
Dialogue is always presented as the customer reacting to something the player is saying or doing, so the the first step was to write basic dialogue for each of those situations. In some cases, lines are reused for similar situations, like when the player is offering a solution which is inconsequential to the problem. However, even wrong paths often lead to unique dialogue options, like the customer asking why the player wants to track their phone through GPS when all they want is to change the wallpaper.
Once all the situations were established, I added multiple lines of dialogue for each case, to avoid having the same replies from happening when the same problem occurs. A customer calling concerning their phone being corrupted might answer “When I tried to start my phone, it gave me a garbled mess.” or “My phone won’t start, and it says something about corruption”. Some customers might dodge giving a specific answer altogether and simply respond “My phone doesn’t work correctly”. This variety also keeps the player on their toes and rather than simply memorizing the solutions to a series of replies.
Problems may also be re-contextualized to provide a wider range of replies. If a phone got wet, the customer might explain that they’re clumsy and dropped it in the pool, or that it was raining really hard. In some cases, the customer may not fully understand what the solution presented means, leading down a different solution free for the player.
All of the dialogue lines are listed in a Open Office spreadsheet, which I then convert to a JSON file loaded by the game. Statements can have several dozens of replies to choose from as a baseline, ranging from a single sentence to a small monologue, and changed on the fly as the customer becomes more irritated or the player asks the same questions again.
<img alt="" src="http://www.sickgaming.net/blog/wp-content/uploads/2018/05/blog-developing-procedural-dialog-in-a-game-about-tech-support-1.png"/>
Once a line is selected, the system determines what variance to add to it. Sentences are broken into chunks which are interchangeable, allowing for different expressions to be used. In the case of “I already told you, I cracked the screen on my phone”, the customer could instead start the sentence with different expressions: “Like I told you”, “I just mentioned it! Once again,” or “Are you even listening? I already said that”.
Customers also have individual traits which influences their speech patterns. Emojis might be added to the responses to add some flair, or the customer might use shorthand for quick dialogue, where forget becomes 4get, you’re becomes ur, and so on. Some may even add typoes to their dialogue, with the frequency varying between different customers.
All of these variations not only serve to make sentences feel distinct, but also add a lot of personality to the customers themselves. The procedurally generated insults allow for memorable quotes like “you contemptuous piece of trash” or “worthless donkey”. They can even use more common swear words if the option is toggled on.
 
<img alt="" src="http://www.sickgaming.net/blog/wp-content/uploads/2018/05/blog-developing-procedural-dialog-in-a-game-about-tech-support-2.png"/>
Tech Support also employs a series of unique characters with their own dedicated dialogue to spice up the conversations. These are split between story characters and specifically crafted customers, who blend in among the procedural characters until a dialogue is established.
These characters will always appear on the same days and have the same problems, which allows for more carefully crafted dialogue and requiring less variation. It also allows me to craft a story around these characters which makes them pop more and adds credibility to the dialogue system.
Having about 10-15% of conversations be unique characters makes the entire dialogue system feel more fresh,
<img alt="" src="http://www.sickgaming.net/blog/wp-content/uploads/2018/05/blog-developing-procedural-dialog-in-a-game-about-tech-support-3.png"/>
A substantial amount of time was spent crafting the dialogue and breaking them down to make them go a longer way. Because the dialogue system and investigation was a pillar of the game’s design, making conversations flow naturally is a priority.
Locking the player’s reactions to dialogue macros helped limit the scope of the game but also allows for faster and more intense game play. The pacing also makes it easier for responses which do sound very similar to be mostly ignored as the player becomes doesn’t have time to break down how the reply is made, only focusing on the meaning itself.
The rate of a new conversation for every play minute was always going to be a challenge to make every response unique, but by virtue of a few tricks, a few thousand lines of dialogue were pushed to become a lot more.
</div>