Game Designer – Digital Tales

Overview

Venetia 1100 A.D. was a narrative driven game. The player wears the clothes of Rainardo, a young amanuensis monk who needs to solve the mysteries that envelop the city of Venice.

Set in the XII century, Venice is not the romantic city we all know, but a dark and swampy place, with many wooden houses that would often catch fire.

This project was scrapped just after I left Digital Tales.

I worked on:

• Level Design 
  • Layout schemes
  • Implementation in Unity
• Event Timelines
  • Flow charts
  • Timeline depicting the exact moment and durations of events
  • Implementation in Unity
• Dialogue structure optimization (more details here)
  • Faster to write for the writers
  • Reduced duplication of content
• Main game mechanics

Gameplay

The gameplay is very story focused. The player can move around the city of Venice by controlling the main character with a side view camera. There are some platforming elements but they are not the main focus.

Everything happens in real time. The length of a playthrough is 4 in-game days (~12 minutes a day), after which the game restarts. The player can see the NPCs moving around the city and can learn what they are doing and act accordingly.
With each playthrough the player can learn new information about the mysteries, the plot and about what happens in general in the city.
Multiple playthrough are needed to complete the game.

There are 4 main mysteries. To access the True Ending the player needs to complete all 4 of them in a single playthrough. It sounds hard but once the player has all the information needed, solving each mystery is quick and easy.

Information gathered in previous playthrough is stored in a journal.
The fact that the character retains memories from a previous playthrough is explained by the fact that the story is not unfolding in real time. We are actually witnessing Rainardo, in his old age, who is writing his memories of those days and is trying to recollect what happened. What we are playing is basically what happens in his mind while he writes.
After a Bad Ending we can see him complaining about his memory because that’s not how the real story unfolded, so he needs to try again.

Dialogue Data Structure

The feature I worked on and that had the bigger impact on the development of the game is the structure of the dialogues.
The game uses Ink as a base framework to handle the story. Due to the real-time nature of the game it had a few shortcomings though. I won’t go into the details of how Ink was implemented in the game (we had a complex system that mostly used the Tag system in Ink) but I will focus on the how the dialogues entities were created.

The player could meet the same character in different places and times. This would make the dialogue options different for each of these combinations (i.e. “What are you doing at the market Segrado?”). There are dialogues that can be accessed at any time though, usually based on previous information or items collected (i.e. “What can you tell me about this book?”).
Using a linear entry-point -> dialogue choice -> end structure would be a nightmare. It would mean a lot of duplicated content and lots of chances to make mistakes.

The structure I came up with may look a bit more complex at first, but it saves a lot of time in the long run.
It features a big main conversation node (called “Main”) where all of the normal dialogue options are stored. Each of these options is locked behind a condition, meaning that, unless the condition is satisfied, the dialogue option is NOT shown to the player.

The Main is accessed through different entry points. These entry points are unique based on the location and the time at the moment (i.e. “Segrado_Day1_Morning_Market”). These entry points may feature custom greetings, but their main purpose is to set variables in the dialogue system. These variables enable the dialogue options that are SPECIFIC to that entry point (i.e. if we take the previous example, this entry point could enable dialogue options about the Market).

After setting these variables, the system goes to the Main where the first thing it does is to set the Global Variables. Global Variables are based on parameters that are NOT specific to the entry point (i.e. “Day1”, “Item collected”, “Information gathered”, etc…) and these enable these generic dialogue options. This is important because we may find the same character (i.e. Segrado) in two different places during the same day (i.e. the Market and the Church). It wouldn’t make sense to ask him about the Church while he is at the Market, but it does make sense to ask him about what he did the previous day or about a specific item currently in the player’s possession in both instances.

There are some specific entry points that lead to special dialogues. In these cases the player can’t access the general dialogue options but they are limited to the options of that entry point. These are used in very specific situations, like when the player is caught in a fire inside a house and needs to escape. It would make no sense that they would ask about another character’s morning, they are limited to dialogues regarding the fire and how to escape.

The flow of the system looks like this