top of page
Dialogue & Cutscene System
For Hickory, a narrative puzzle platformer
Play The Game
Overview
Hickory is a vertical-slice game demo of a narrative driven puzzle platformer.
For this project, I was tasked with designing systems for both the NPC dialogues and the cutscenes that occur throughout the game. To accomplish this, I created three scripts that can modularly meet either (or both) of these goals.
Above are three examples of NPC dialogue/cutscene events.
All of which utilize the same modular scripts.
Goals For The System
Narrative and Puzzles are the two quintessential elements of Hickory, so this system needed to be built to compliment these features as much as possible. This required a system that was easily modular so that it could be reused frequently throughout the project, but also included a depth of features and tools for designers to use.
Upon determining this, I transitioned to pen and paper and recorded these main goals for the system:
-
Is easily modular and reusable.
-
Must effectively present the narrative to the player.
-
Serves a gameplay purpose (helps subtly guide the player towards their next goals and objectives).
-
Provides the player with a sense of reward.
Design Process: Modularity
I knew that any variables that we would want to change needed to be easily organized and editable within the Editor. This was critical for creating a simple, quick, and repeatable process for building all of the narrative events.
The image to the right contains a visual example of how variables such as strings of dialogue, characters who should animate during a cutscene, focal targets for the camera, character poses for the UI, and more, have all been made easily accessible and adjustable within the editor.
Design Process: Narrative
Perhaps the most critical element of designing any narrative game is determining how to construct the narrative. For Hickory, I created a "DialogueManager" script, which was the primary script responsible for actively printing text to the UI. Whether a cutscene or NPC dialogue was active, they would display text to the screen through this DialogueManager. There is only ever one instance of the DialogueManager.
When dialogue should print to the UI, the script starts a coroutine that repeatedly prints characters from a string until the entire "block" of text has been displayed on the UI.
Once this process has completed, the player can press the "action" button to proceed. At which point the DialogueManager will begin the next portion of dialogue. If no remaining strings of dialogue need to be printed, the process will end and active gameplay will resume.
Any strings of dialogue that should be displayed by the DialogueManager are sent from another script, the "DialogueController". Each instance of a DialogueController is responsible for holding all of the variables related to the cutscene (ie. strings of text, character poses, and more, as seen in the earlier image of the Unity editor). Instances of the DialogueController are attached to the Game Object that should trigger the dialogue or cutscene. This can be a NPC, trigger box, or anything else within a scene.
Design Process: Gameplay Purpose
With the narrative effectively being presented to the player, my focus moved onto elements that would service both storytelling and gameplay purposes.
Through interactions between the DialogueController and another script, the "CinemachineController" (used to manipulate the camera) I created a system that would compliment the games needs.
This included the ability to change the target that the camera should be focusing on, as well as the speed the camera would pan across the screen. The orthographic lens size can also be modified, allowing for the camera to zoom in and out. These features were consistently used to create smooth visual transitions and subtly inform the player.
I am an advocate for the use of "showing", rather than "telling" in game design. Through trial and error, I have found that using visuals whenever possible helps provide a greater sense of engagement for the player. It makes them feel like they have discovered something on their own and encourages them to explore in the hopes of uncovering more!
Sure, there are times when it is extremely useful to have an NPC tell the player where they need to go next, (this method is used multiple times in Hickory) but this can often feel burdensome for players. It may also contribute to them feeling fatigued by dialogue, especially if they are players who would rather focus on gameplay.
I also wrote code that allowed for specified text within a string to be colored. This helps make important text pop when it is printed to the UI. It draws the players attention, making it easier for them to remember any progression-related information, even if they spam their way through the text. It also serves a narrative purpose, creating a different emotional subtext behind the dialogue.
Experience
Whenever I design systems, I repeatedly find that the process boils down to these repeating steps:
Research -> Experimentation -> Reiteration
Developing this system proved to be a quintessential example of this, as it was continuously expanded upon and updated all throughout the duration of the Hickory project.
Even upon completing it, I've noticed elements that could still be improved upon.
For example: whenever the camera pans to a new location or zooms in/out, the speed of the transition is constant, it does not ease in or out of it's top speed. This runs the risk of these transitions feeling rough, and could even cause minor motion sickness for players who are more sensitive to those kinds of effects.
The next time I work on this kind of project, one of the changes I will make will be to add these ease-in and ease-outs to the system.
Despite the potential improvements, I am very proud of what was accomplished during my time working on Hickory. At this time of writing, this was one of the most complicated systems that I have ever had to design. Which also made it one of the most engaging challenges that I have faced.
I really look forward to returning to this type of system someday and seeing what I can do to improve further!
Full Video Walkthrough
Software Used
Unity
Game Engine
Perforce
Version Control
Photoshop
Assets & Visual Design
bottom of page