Ex Umbris is a dark, atmospheric mystery game where you play as the ghost of a medieval monk looking for answers.Stuck between worlds without time, you must overhear whispers of your brothers, find clues, and use your ghostly powers to discover the secret behind your death.

Genre: Mystery
Platform: PC
Engine: Unreal Engine 5
Duration: 9 Weeks
Team: 15 People
Role: Lead/ Narrative and Technical Design

My Work On Ex Umbris

I pitched Ex Umbris together with my two fellow designers, Nikolaos Joukowski and Philip Olsén, as a concept inspired chiefly by Outer Wilds, with a bit of Hitman thrown in for the NPC interactions and investigation, but with a smaller scope and a dark, heavy realistic artstyle and historical setting.Some of my main contributions were:

  • I took charge of mapping out the narrative and writing the text in the game, working alongside my fellow designers to make sure the story and clues were directly tied to the level and environment.

  • This also involved designing the monastery's schedule, including the speed of it in real time, and which rooms the player should have access to at any point in time

  • I designed and implemented the logbook, which logs and stores a summary of each clue the player finds, helping them keep track of the knowledge they are acquiring.

  • Helped in the iterative process of designing the player's ghostly abilities and movement, documenting and guiding the implementation process.

The Narrative

My main area of work in Ex Umbris was in designing the narrative of the game. With the game being mostly about an open mystery, and unfolding various threads that converge onto the murder of the player character, this was a challenging task that required a lot of iteration and discussion with my peers.The first step of the process was narrowing on a narrative gameplay vision. This involved a lot of meetings with my fellow designers to discuss both the particular story beats and how they might be delivered. This first stage left us with a narrative outline, which was purposefully quite simple, and and idea for how to deliver it.The outline was: "The abbot fell sick, had a crisis of faith and turned to paganism. The player character discovered this, and before he could expose the plot, he was murdered"

For how to map and plan it, I stayed close to our North Star reference; Outer Wilds. We as a design team looked closely at how the clues in that game interconnect, and at the wonderful mapping they use in game to show this. Clues are generally not only giving further information about the big secrets of the game, but also pointing the player toward other clues, sometimes a part of the same "plotline" but sometimes to another part of the game completely.All through writing and planning the game, I did my best to create a small scale version of this model, and took inspiration from the Mobius Digital team, who initially used the rumor map as an internal organization tool before implementing it into the game. I found this mind map approach was excellent to keep a view of the game clear.From this point onward, I worked on designing the narrative web of the game, including not only writing the text and planning the connections between clues, but also designing the mechanics that would deliver the narrative.

While the overall chain of events of the narrative was left mostly unchanged from the initial version, I did have to make many changes related to player clarity and how we were guiding them to the more important clues. A lot of clues had to be added that were easier to find, as well as some clues that reinforce some of the cues we wanted players to follow, so there would be more than one way to get information about where to find an important clue.The main change in the narrative design of the game was related to the player objective, which during the pitch stage consisted of the player finding out who their killer was and then killing them with their own knife.We quickly realized that this took away from the mystery and investigation part, and sort of required us to have the player be able to kill the monks, both in the design and implementation side. We felt this would immediately distract from the other possible interactions with the monks, as it's a very charged way of interacting with them.

This then led us to finding another ending that fit the shape of the game better. We looked at many different references, and quite liked the way Pentiment did it, where the character must acuse someone, because it was more in the spirit of the investigation gameplay, and fit with the theme of redemption.From this, I came up with the idea of having the player confront the killer during their own funeral mass, by placing the killer knife at the altar. This would cause the real killer to break down and reveal themselves.This ending was initially a lot more ambitious, involving the writing of a requiem, that you could rewrite as you found more clues, leading to the climax at the end, but sadly a lot of the progression and buildup part had to be cut due to time and technical resources.That being said, while I still don't feel it's perfect, I do think the ending fits the game a little better than the initial idea, and the ending cinematic received good feedback especially.

The Schedule

One of the most important parts of the game, both for narrative and gameplay structure, is the way time is used in the game. In Ex Umbris, the player is trapped in a time loop (something we might have "borrowed" from Outer Wilds), condemned to relive the day after their death as a ghost until they find peace.This meant each day in the game the monks will go through a schedule, performing the same actions every day, going to the same rooms, and having the same conversations. I took care of designing this schedule, as it was an integral part of the narrative gameplay puzzle, dealing not only with when and where in the day conversations would take place, but also where monks would be and which rooms would be open, meaning which places the player could access at any given point, and which places would have some risk of being detected for them.

One of the challenges I faced was how to map real time onto the game time. The time loop is supposed to take place over a day, but the time loop cannot realistically last much more than a half hour due both to scope and pacing.This mismatch between game time and real time causes a couple of issues with the schedule, especially related to travelling time, as the monks and the player move at a "normal" pace, but their real time is accelerated, so a monk travelling from one room to the other might take an hour in game time.This is something I needed to acommodate when making the schedule, and together with having a relatively short loop, it meant that for the player to have a chance of seeing any given thing, the schedule would need to have a low amount of things

I initially attempted to create a schedule semi-faithfully following research of real world medieval monastery schedules, which were quite involved, having several defined prayer times, as well as times of work, rising, and going to bed. It quickly became apparent that this couldn't really be matched with the accelerated game time, as monks could not feasibly go from place to place in the time it would require to execute the schedule.With every iteration, I realized that, similarly to the text, the schedule greatly benefitted from brevity and simplicity. This then led me to create the most simple version I could: four time slots, with an hour padding between them to account for travel. During each of these slots, each monk would be doing a single thing, and when the bell rang, they would start moving toward the next slot's position.

For this schedule, the placement of the activities was done hand in hand with the level design, as the monks were also in charge of opening and closing doors, allowing or preventing the player from accessing certain places in the world.The schedule is planned in such a way that it guides the player toward the more introductory clues, while rooms that have the more important clues are harder to access at the beginning of the day. For example, as the player wakes up for the first time, they will first encounter a conversation that mentions things disappearing from the dormitory.In the dormitory, they will find two notes, one of which mentions a monk having a conversation later, during writing hours. This tells the player that at some time during the day, something will probably take place at the scriptorium, the place where writing occurs. This room starts closed, but this note guides the player to pay attention to it, where they will eventually find clues guiding them to two more important clues.This loop is then repeated for those clues, and so on and so forth, combining the schedule, the level design and the narrative design and clue writing, to create the push and pull that drives the player forward.

Narrative Mechanics

When it came to the mechanics that popped up around the narrative, one of the main challenges that we faced was in the delivery of text. With the game being mostly about the player finding out about events that had already transpired by reading, it would naturally be quite text heavy.There was a big worry that the game would end up being bogged down to the player just going from room to room, reading some text, going to the room the text was referencing, reading some more text, and repeating until the end of the game.We felt that while this text was very important to the gameplay, the most interesting part should be what was happening between these text clues, where the player would have to think and decipher the connections between things, and hopefully find some big secrets and surprises along the way.

A big part of the whole process of creating the balance between reading and the rest of the game was in the many revisions and editing passes on the text, both by me and the other designers, but additionally, some techniques I used to make sure the text was easier to digest, and did not slow the player down too much were:

  • Me and Nikolaos, one of my fellow designers, came up with the idea of having books needing to be brought to a reading stand to be read. This made their usage somewhat of a puzzle, as they needed to get by the monks with the book without being detected to bring it to a stand, and made the clue within feel more like a reward than a task.

  • I strove to keep each instance of text as short as possible, especially in the notes. This was easier with the dialogs, as they were broken down into phrases, but notes were constantly edited down.

  • This was also the case with books, but with their usage being a little more involved, and having two pages to work with, they were allowed to be more wordy, and thus also be more valuable, as they had more info.

  • Lastly, through the many editing passes the text went through, something we identified made it easier to read and understand was the removal of many of the expressions in latin I had added for flavor. While it was a tough choice, as I really liked the feel they gave, for many people they were just a source of confusion, and their removal was noticeable in the clarity of understanding during testing.

Notably, as the text size and complexity got reduced, not only did it significantly improve the pace and mental load of the game, but it also made the clues a lot clearer, and with every editing pass, the players would understand the clues better. This probably also had to do with me getting a better feel for how to write for this game, but I think this was an important lesson during the process: The text does not need to be fancy, it needs to be readable and say what it needs to say for gameplay purposes.

The Reveal

As mentioned above, we used the books as a more involved way of getting a clue, having to be brought to a pedestal. While this worked quite well, we also thought of using the pedestals for more.We got an idea from watching The Name of the Rose, a movie that bears a lot of similarity to the game, where the characters find hidden text written in lemon, that can be revealed with a candle.This really made sense to us for a mechanic, as it's a classic mystery novel trick, and would make sense for the scholarly environment of the monastery. Since we already had mechanics involving candles, such as a scan that allows the player to see monks near candles at a distance, it made sense to use candles for more.So we came up with a mechanic where notes and books could have hidden text, which when standing on a pedestal, would be revealed when the player used their scan ability.

When scanning a clue on a pedestal with a candle on, the text is revealed

While we came up with the mechanic together with other designers, it was mostly my responsibility to integrate this into the narrative. This was in a way hampered by the tight schedule, which caused the mechanic to be implemented relatively late into the process, which in turn caused it to be less prominent than I would have loved.Nonetheless, we added hidden texts to some of the game's already existing clues, and also found the opportunity to create some new ones as playtests showed some places where further guidance could be used.Something I quickly realized was that having hidden text without context was somewhat of a waste, as the players don't really scan a clue without having a reason, so I had to make sure things pointed to the hidden text, so as to guide players to it, or alternatively make it plain that there was something hidden in the page itself, for example leaving a large break in the text.This then led to the tutorialization, where we came up with a somewhat clever trick of having the clue that guided the player through the steps have a hidden text itself, rewarding the player immediately when they understood the trick.

The Logbook

While initially I had thought the game would not need a Log or a way to record the clues the player has found due to the smaller scope compared to other similar games, every time we showed and tested the game we got feedback that it was needed, and with the amount of clues we ended up having, we thought it became necessary, so I took it upon myself to design and implement the Logbook.

For reference, I chose not to base myself off the Outer Wilds log format, as we didn't really have the time or resources to create something in that "mind map" style that I felt could work well enough, but looking at Orten Was The Case, another game in the same genre, we found something that seemed to me a lot more feasible and wouldn't really require anything but some programming time on my part.

The design itself of the Logbook was fairly straightforward, with the area that took most iteration being how to categorize each clue and how to present the clues in the log.I wanted to use the clues to give the player an idea of what their goal in the game was, and this led me to make a mission tab, and have the possibility to show a hint when a clue has not yet been discovered. This way, we could introduce objectives to the player as soon as they open the Logbook for the first time.After that, I thought of adding an introduction tab, where the first clue a player could discover would also give them an explanation for the logbook, and later on, an explanation for the monks' banishing mechanic was added. In retrospect, more mechanic tutorials could also have been added, but this was quite late into the development, and I didn't think of it in time.

A quick sequence of Logbook usage

In terms of implementation, the Logbook uses the Unreal saving functionality to store data on which clues the player has opened, which the logbook consults when opened to display the things the player has found. This save system also stores what clues the player has found and not yet opened in the logbook, so the player can easily check a clue on the log as soon as they have found it.With this implementation, the Logbook also became a save system for the game itself, as the game being on a time loop does not require us to save anything in the world, as it will get reset, so the only permanence needed is in the recollection of the actions of the player.

Learnings

Ex Umbris was a very challenging project for me, as it forced me to tackle narrative design in a level of depth that I had never done before, but I feel that despite the growing pains, we did make something that is quite special and unique for a game project.

  • In terms of narrative, my main takeaway is that the enjoyment of the mystery had much more to do with the exploration and the design of the map than with the writing of an extremely complex and detailed plot. We were making a small, contained game, not a novel.

  • This game also really taught me a lot about balancing the inspiration, and what we had researched, with what was feasible, but also what was best for the gameplay. It did not need to be a faithful simulation, it needed to be an experience that was enjoyable.

  • Lastly, this was my last project at PlaygroundSquad, and I got the chance to work with many of my closest friends for it, which is something that I will always hold dear, and it will remind me of the many lessons these wonderful people taught me.