Somniphobia
Creative Director | Systems Designer | Narrative Designer
Overview
Genre: Survival Horror, Rogue-Like
Engine: Unreal Engine (5.2)
Platform: PC
Production length: ~8 months (September 2023 - April 2024)
Team size: 10 (3 designers, 7 programmers)
Full team credits: Liam Binford - Programmer || Nathan Fallon - Art Lead, Designer || Jordan Fowler - Designer || Aaron Hansen - Quality Director, Programmer || Michael Haynes - Producer, Programmer || Gabriel Hoefler - Creative Director, Designer || Caleb Kissinger - Programmer, Animator || Zach Marshall - Programmer || Haoran Wang - Tech Director, Programmer || Dong Ta - Audio Director, Programmer
Somniphobia is a survival horror game about a man trapped in a recurring nightmare. In order to escape, he must confront his fears and regrets to get to the heart of the dream and stop it, before he wakes up and must repeat the cycle.
Somniphobia blends classic survival horror genre features like fixed camera angles and resource management with rogue like mechanics where Item and enemy placement and spawning, enemy health, certain effects and events, and even the map layout are all partially randomized.
Somniphobia was made as an academic project at DigiPen Institute of Technology for the GAM300 and GAM350 classes, in which a team of students develop a 3D game over the course of two academic semesters. The classes are meant to give students the experience of creating a game with a team by emulating the game industry on a smaller scale. This is achieved through allowing students to hire and fire team members, requiring leadership/management positions such as the Producer and Creative Director be fulfilled, etc.
Roles and Responsibilities
Creative Director
As the Creative Director I had many responsibilities to carry out both for the game and the team. I was in charge of keeping a coherent vision for the game, and was the one who did much of the initial concepting and design for the game, such as concepting mechanics and establishing the narrative themes and design pillars.
Being the Creative Designer carries a lot of responsibility, especially since I had the final say in most things. So, it was important for me to be a good leader and spokesman for the team. Much of my time was spent directly working with team members, both designers and programmers. I made sure to always involve the whole team in important decision making so that everyone’s voice could be heard. I always did my best to be available if anyone on the team needed support, had a question to ask, or wanted to run something by me.
Systems Designer
As the Systems Designer it was my job to create and improve the core mechanics of the game. During the beginning of production, I concepted out the systems and wrote the initial design documentation. As production moved forward I would regularly change or tweak mechanics, most often in response to feedback gained from testing. This often involved both editing documents and going in engine to edit Unreal Blueprints.
Being the Systems Designer meant working closely with the programmers. One of the ways I did this was, while writing design documentation, I would do my best to make it details and very programmer friendly. Meaning that I would give specific examples, use technical language, bring up edge cases, and make recommendations of how something could be implemented in the code
Narrative Desinger
As the Narrative Designer it was my job to form the narrative experience of the game. As we were a student team on a tight schedule making a mechanically heavy game, it would have been reasonable to not worry much about the game’s narrative. Instead, I used many techniques to make sure the game had a cohesive narrative experience.
I believe very strongly that narrative themes are perhaps the most important part of forming a narrative. Because of this I established the themes early. Much of the game, from the mechanics to the environment, were built to reflect the themes. Plot was delivered to the player through suggesting a backstory and events by using the environment, item descriptions, enemies, short win and “death” cutscenes, and brief introduction text.
Lessons Learned
The Importance of Design Pillars
Summary: We established design pillars at the start of development. This proved to be a good decision as we would reference them if we weren’t sure a feature.
Early on in production we decided that we needed to establish design pillars that we would follow. As the creative director, I thought about it and wrote out the design pillars that the game would be built around. As a team we discussed and tweaked them a little bit. After that we printed out several copies and put them up around our team space.
This proved to be an incredibly valuable tool. Whenever something new was being designed or if something was being changed, whatever it was that was being added or changed had to stick to the pillars. Anything that didn’t fit into the pillars was scrapped or changed. I found myself cross referencing the pillars often.
One of notable examples of a time I changed something due to the pillars was while I was designing how shooting the nail gun weapon would work. I had designed a critical hit system where the longer you aimed at an enemy without shooting, the more the accuracy of the gun would hone in, and then when it is fully locked on there would be a noise and visual effect. If the player fires within a small window after the noise they would deal extra damage. I was planning this out for a while, but I was thinking about the pillars and cross-referenced the mechanic with them. It fit with the “Urgency” pillar since you would be sacrificing time. However, it did not fit with the “Ordinary man in a hostile situation” pillar as it felt a very gamey and made the main character seem experienced in combat, which is the opposite of what we wanted. So, I scrapped the idea.
Having these pillars was incredibly useful at making sure our team was focusing on a cohesive vision for the game. The value of having clear pillars that are physically visible was made abundantly clear to me, and it is something I intend to do in all projects, even solo ones.
The document we printed and hung up.
Here is a short video that gives an overview of the combat system and the work I put into it. It also includes some specific examples of changes made and how the systems work internally.
Tense, Fun, and Fair Combat Design
Summary: I learned many valuable lessons about combat design, such as how to balance difficulty (especially in a survival horror game) and how combat should control.
One of the most major things I did as system designer was designing the combat systems. This was definitely a challenge, but one that was very interesting and fun to work through. Since our game uses fixed camera angles, a standard third or first person combat scheme would not work. Of course, we had a good amount of inspirations to draw from, but we made sure that no mechanic was added just because another game did it.
While creating the combat I had a few goals in mind. Since Somniphobia is a survival horror game, the combat had to be tense and play into the resource management aspect of the genre. This was done by making the system slower than other games, causing the player to have to think about their actions and allowing enemies to draw near. Resource management was worked in because the ranged weapon uses ammo and the melee weapon uses stamina.
The combat had to be fun obviously, and while “fun” is a nebulous and often unhelpful word, to me this meant that the combat had to be enjoyable for players and not be actively frustrating. This specifically was quite difficult due to the nature of the game, the combat had to be difficult and thoughtful but not so much that it became frustrating. This was a fine line that play testers often crossed while testing. Many changes and tweaks were made to make sure the game stayed on the good side of that line, a major one was having the player to lock onto enemies instead of having to manually aim.
Making the combat fair was very important as, while playing, the player will have a delicate balance of resources. These resources will influence how they handle combat, be it melee, ranged, or by running past enemies. To make the combat fair, enemies had to be balanced correctly to be difficult and frightening, not too difficult or too easy. The spawn rate of items such as ammo also had to be carefully honed in, statistics I calculated and data from play testing were both extremely helpful here.
Designing the combat system for the game gave me an intensive crash course on combat design. I learned many lessons about it including focusing on the goals set out for combat, and to not overcomplicate things, especially if they don’t need to be that complex.
Designing Rogue-Like Mechanics
Summary: We were new to making rogue-like games. Along the way I learned about balancing spawn rates, creating a sense of progression between resets, and more.
No one on the team had made a rogue-like game before, so it was a learning experience for everyone as we threw ourselves head first into it. In the end, I personally think Somniphobia has a good blend of rogue-like mechanics including restricted level layout generation, item drop rates, enemy spawn rates, and more. Getting to that point however, was a challenge that we had to work through.
As a designer, I learned several lessons and skills relating to the genre. These include tweaking spawn rates of enemies and items so that they feel right to players and so that the player doesn’t get too many items, creating a sense of progression when most of a player’s inventory is removed between runs, making rooms and encounters that work no matter where they are or which entrance is the one the player came through, etc.
One of the major lessons that the entire team learned about this genre is that you have to be cautious with scope, as it can get out of hand fast. We had a few different styles of level randomization that we were considering. During a team meeting, everyone discussed and we chose a style where nearly the entire level would be made of premade rooms that were randomly laid out. For the first half of production this was what was being developed. At the start second half we realized that, although we were fairly close, it was unrealistic to continue with this goal. So we started thinking about alternatives, keeping in mind the impressive code we already had as well as the limitations of the code and design.
One day I came up with a method that I called “hub and path”, I quickly scribbled this into an MS Paint drawing to explain to the team. In this style, certain parts would be guaranteed and not random, these were the hub room, boss room and leadup, the tutorial rooms, and the end rooms of each path. But the two paths that come off of the hub would consist of pre made rooms that were randomly put together.
A crude image I made to illustrate my idea for a “hub and path” style. The ‘H’ is the hub area. The ‘P’ rooms are the path end rooms. ‘B’ is the boss room. Everything circled in orange is the randomly generated layout.
A top-down screen shot of a generated layout.
