Kari: Stranded on the Shores of Vanaheim is an Action-Adventure game in Vanaheim, one of the nine worlds in Norse Mythology and home to the Gods of Nature.
The player takes control of Kari, a young viking girl who stranded here due to a storm and now has to find a way home by finding new parts for her boat. But things are not as simple in the realm of Gods.
The game heavily focusses on a Narrative and Visual Journey, as Kari wanders through three distinct areas searching for what she needs to succeed.

Game Bio: Kari is an Action-Adventure game built in Unreal Engine 4
Genre: Fantasy/Mythology
Highlighted Features: Combat-Free, Time-Based Health

Technology Used: Visual Studio, Perforce, Jenkins, Jira, Unreal Engine 4, FMOD studio 2.0, Firebase
Platforms: Windows

Release Date: July 14, 2020

My Roles: Narrative Designer/Writer, Level Designer

Playtime
6-10 Hours

Development Time
1 Academic Year

Team Size
29 Students

Foreword

Kari: Stranded on the Shores of Vanaheim was written almost entirely by me as the only team member with the Writing role, resulting in over 600 unique dialogue lines and over 20 quests to engage with in the game.
I had some help preparing a few quests before we hit production, but due to the nature of our custom database I was responsible for the implementation of each dialogue line, item description, and quest log entry that made it into the game.
In addition to that, I was also responsible for each character’s placement in the world, their quests, and dialogue functioning properly.

This gave me a lot of experience in game writing and in narrative design implementation.

Pre-Production – Level Design

Since I was already working closely to the environment team concepting the settlements, I also worked on each town’s concept and layout for in the game.

For the Coastal settlement, I was a part of the entire process:
After basic sketches, I made multiple block-outs to discuss with the art team before moving forward and doing a basic pass and handing it over to the set-dressers.
I made the sketches and block-outs for two more settlements, but when the workload on the narrative side became too much for me, I delegated their development over to my peers.

Besides the settlements, I also was responsible for the Tutorial level, which was the first playable level that ended up in the final product. The design team was swarmed in work so I worked out the sketch, the block-out, and then the gameplay in a single day before once more handing it over to a set-dresser.
From Thursday to Friday we had a playable level, and on Monday we had the tutorial level set-dressed.

Pre-Production – Narrative

With our characters selected and settlements mapped out, I began working out the Narrative.

I prepared a Slideshow to gather all Narrative in which included items such as: The Hero’s Journey; the rules of writing dialogue; a link to the tech design document; the quest summaries; and other relevant elements for the team.

Linked to each quest summary page was a document in which the script of the quest gets expanded on. I prepared 16 Quest documents, and with the help of another designer we wrote block-outs for each quest.

We utilized a narrative pipeline we set up, verifying each other’s work and adding comments where necessary to assure quality and consistency.

Each document’s script was adhered and updated until we hit polishing during our production.

Narrative Implementation

Once each quest had their block-out script written out and approved, I started the implementation phase.

For implementation, we used Firebase as an angular framework for our database. I ported every line from the script into the database and linked them up properly.

Working in the database came with a lot of issues. Including: memory leaks, code breaking, missing features, and a bottleneck effect for others that needed the database since only 1 person could work in it at a time. But despite all those delays and hurdles, I managed to get everything we wrote in, alongside a bunch of extra NPC dialogue we missed to foresee in pre-production.

When most of the dialogue was in the playtests and feedback required me to also go back in and clean up a lot of the lines in the database directly, leading to various documents going out of date due to the time pressure caused by these issues.

Despite all of the above, to get the narrative from the database into the project was straight forward and simple, as with only the click of a button to synch the database and engine up, everything was immediately updated. I could then immediately test out the changes in editor, without having to relaunch or recompiling the editor.

Further Reading

To find out more about the database and the massive improvements it has gotten since Kari’s Development, please consider visiting Valencio’s Portfolio page on StoryTime. It is the evolution of what I worked with, and has greatly improved in User Experience since.

https://vamidicreations.nl/portfolio/storytime/