Progress
Significant implementation progress has been made since last post, so I will outline here the work that has been completed, and it’s connection to the project’s design, after which I will outline the approach to narrative design I will be taking in the design of the project.
Water Material
Given that the entire game will take place on a plane of water, and the player will not have the ability to leave the boat, the water material for scrimshaw will play a great part in the visual pleasantness and effect of the game.
Given my experience with HLSL and Shader graphs in the past, I began by collecting information on what effects I wanted to have in the water, and the paramaters I would want to have access to in order to manipulate those effects.
Firstly I wanted to have depth based colour blending with objects close to the surface showing in a lighter variant of the deep water colour. This is in order to make the water appear murky, as rather than using simple depth based opacity, the objects below the water still retain the colour of the water itself
I also wanted foam to form around objects intersecting with the water, and have a texture that distorts to make the formation of the foam appear more natural. Finally I wanted to have surface normals, with multiple blended layers, that ebb and flow to give the open water areas of the game a more appealing texture, and have reflected light appear more natural.
In my research into water shaders, I came across a shader by Alexander Ameye for URP in Unity that fit all of my requirements and was free. It also included foam shadows, general surface foam and textures, displacement waves, caustics, and planar reflections. truly the full package.
After loading and installing the package, I edited the shader graph to allow for interaction with Linear Fog, and removed the cap on some of the parameters to allow for us to “destylize” the water moreso.
After adjusting the water parameters, importing our own foam maps, and normal maps for the surface normals, and applying the water colours, the result is as below:
While I’m very happy with the water’s appearance and reactivity to it’s environment and lighting, the default material had depth based opacity to it that would allow for objects underwater to have their albedo show through. After manipulating the material and editing the shader graph, this transparency was no longer visible, likely due to the strength of the other effects we added such as refraction, strong surface normals and smoothess, and planar reflection strength. This could be resolved either by applying a final pass to show object transparency after the other effects are applied, or to reduce the strength of some of the other effects on the surface.
Something to be looked into at a later date as I am happy with the current state of the material, and can avoid any of the drawbacks by maintaining the underwater elements to more ambiguous shapes, rather than using it to hide haptic clues and affordances.
Dockables
A big part of scrimshaw, is dockables. The player will dock at a variety of locations, and interact with characters, shops, objects and other events. The dockable areas will also provide a repireve from the more fast paced action of the game, and therefore the haptics around the action of docking, and the locations of the docks need to be carefully considered.
Firstly, I had to extend the CameraRig script to allow for other objects to take control of it from the player. Firstly I created methods for disabling player control of the Rig’s rotation, and move it to a new location. I used the existing Rig’s fluid motion to the benefit of this new method, just changing the tracking target and rotation when necessary, and returning it on undock.
I then created the structure for docking. First a DockSpot script, with a trigger area, that enables a DockRegion when entered. Upon entry, a popup appears to indicate that the player can dock.
Docking takes control of the player camera and locks it into a predetermined position for the best angle of the dock region. This also enables any DockInteractables associated with the region.
When an iteractable is enabled it can be highlighted by mousing over it to reveal an outline, and selected to perform it’s behaviour, this script is Inheritable and has virtual methods for all basic functions.
Dock interactables will include characters to converse with, shops to purchase items from, minigames, events and decisions for the player to make.
Dialogue
As the system for beginning conversations was implemented, I decided that a logical next step was to implement the system for having conversations.
After deliberating, I decided that I wanted to have conversations lock the player into whatever they were doing, and take their full attention. This is so as to include information in conversations that a player needs to track independently. This does also force us to conduct player conversations in locations that are “safe”, which could potentially mean long stretches of time where players do not interact with characters.
Firstly, I created a Scriptable Object for dialogue. The way that I chose to set up the Dialogue process is to have a stage by stage set of “lines” to be said, with associated names and pictures to go along with them. This also allows me to extend the system later with things like emoticons and audio for each line. The way that I chose to set it up was to have a number of lists, each containing one part of each line, so that I could create them in the inspector: A Portrait Sprite, A Name and a Dialogue Line.
I then created a function for loading the Dialogue object into the Dialogue UI, locking it from further loads for the duration, and locking the player out of other actions while the dialogue is playing. The function then creates a coroutine and begins playing the dialogue.
The dialogue step is loaded into the UI, and the text for the line begins displaying one letter at a time. This is to draw the players line to reading the dialogue, and control the pacing of the line. Pressing G while the dialogue is displaying will display the whole line, and once the line is displayed pressing G again will move the script on to the next line.
Once the dialogue ends, the UI is deactivated, and a message is sent to the EventDistributor that the Dialogue was had. This is so as to alert any listening scripts to perform actions based on that dialogue. In the example below, the gate is alerted that a conversation was had at that gate, triggering it to open, and for the DockSpot to be deactivated, forcing the player to exit into the realm.
The UI could use a lot of work, and I need to have my own sprites for the final design, but the system is extremely extendable to include new features, and the EventDistributor framework for alerting events makes it easy to load dialogue into characters PriorityQueues, and trigger any other needed events after dialogues have finished.
Narrative Design
Now on to design principles that I need to highlight and explore in the construction of the narrative of this prototype. Scrimshaw’s narrative will be long arcing over the entire game, following a standard structure (Heroes Journey/3 Act). This overarching narrative will be underpinned by many smaller personal character journeys, mini narratives, and other stories to weave the main themes together.
This is sadly not possible in a short linear prototype, so other options need to be explored to provide a similar experience to the planned final product. In brainstorming with my team (Of 2) I thought of a couple of potential approaches:
- Microbranching Narrative: Create a short narrative expeirence with multiple decisions players can take, and adapt the narrative experience to the approach that the player takes. This would involve plotting potential routes players may take, and designing the potential narrative branches from them. The final story would end similarly for any choices the player takes, with the journey being the key to the unique experiences.
- Repetitive Branching Narrative: A short simple branching narrative that can be played out multiple times to achieve different endings. The key to this structure is multiple meaningful and diverse endings, depending on key choices set up at the start of the narrative and made throughout the course of the game. The story can then be replayed with different decisions made in order to achieve a different ending.
- Linear Narrative: Appearing to be the simplest of the three, the real difficulty is making a linear narrative appear to have meaningful choices, and provide players with a unique experience based upon those choices. The benefits of this approach are that the narrative can be carefully planned, it does not prevent me from making any narrative decisions in the final project as I can control the “events of the past” that a player takes, and that it is pretty straightforward to design.
Given the time constraints, the most sensible approach I have come up with, that also allows me to express the narrative ideas that I want to explore in this prototype would be a mix of the approaches.
The narrative I have planned will have the player assisting in the establishment of Shurrick, a new settlement in The Locker. They will have to collect scrap throughout the locker to meet a quota of materials needed for Shurrick’s construction. Throughout the journey, the player can make stops at different locations and will be given choices that may impede or assist in their journey, through characters in the realm. There will be two endings:
- The player collected enough materials for the continued construction of Shurrick.
- The player did not collect enough materials for the continued construction of Shurrick.
While that seems simple, I believe it could work based upon how players reach their ending. If a player has the materials to complete their objective, but instead chooses to give those materials to a passing traveller in need, or drops materials for consumables, hoping to find those same materials later on, the outcome will play differently emotionally than if they just failed to acquire the materials through lack of preparation or by neglecting to collect derelict as they voyaged through the realm.
I’m hoping this will provide a significant reason to replay the game as well as meaningful decisions that the player has to weigh up each time they play through the prototype.
Further study needs to be done into the implementation and features of this design choice, but I’m confident that I’ll be happy with the outcome. The real test will be in the playtest.
Till then, I will be posting more about the design of the system, as well as other features that I will be implementing along the way.