top of page
FEAR OF THE LIGHT
(2024)
Nominee of Best Design
Swedish Game Awards 2024
Nominated as one of the top three games among over one hundred submissions in the competitive Best Design category. [link]
Winner of Best Tech
Futuregames Awards 2024
Winner of Best Tech among 60 games from Futuregames campuses in Stockholm, Karlstad, Boden, Skellefteå, Umeå, Malmö, and Warsaw. [link]
Nov 7th 2024
Steam Release
Released on Steam after half a year of continued development with:
-
37,000 library additions
-
3,000 players
-
56 min average playtime
-
88% positive reviews
Game Description
Fear of the Light survival horror game where light is scarier and more dangerous than darkness. Use your radar, EMP, and other tools to stay out of the light, sneak around dangers, explore the quarantined ship, and find a way to escape. But be careful, monsters are hunting you and are aware of your every mistake!
Genre / Tags
Survival Horror
Stealth
Singleplayer
Sci-Fi
Space
Atmospheric
First-Person
Exploration
Highlighted Design Tasks
Gameplay Loops
Player 3Cs
Player Tools & Abilities
Encounters
Telemetry
Steam Integration
WORK HIGHLIGHTS
Highlights of tasks I did and the design and work processes behind them 🌟
PRODUCT OWNER / DESIGN LEAD
Highlights from the design of the core concept and intended experience of the game. Also includes the Miro board.
Product Owner / Design Lead 🤗
Designing the Overall Concept & Experience 📝
The game was centered around the theme of self-judgment and pressure, especially related to other people, and the feelings of anxiousness they induce. I started by summarizing and clarifying the game concept; for example, what genre it was, who the target audience was, how the gameplay would work, what the intended mood was, what the setting was, etc. For every aspect, I tried to make it synergize to deliver on the intended theme and player emotions. Once I knew clearly what the game was about and how it would function, I planned out the design pillars for the player experience.
GAMEPLAY & SYSTEM DESIGN
Highlights on the design intentions & processes behind the gameplay and system design.
Gameplay & Systems Design 🎮
Core Gameplay Loop & Progression 🔁
We set out to create a systemic stealth survival horror game, rather than a combat-focused or cinematic one. To make light tense and dangerous, we made enemies detect you and become more aggressive whenever you stepped into it.
I designed the core gameplay loop around two phases: preparation and execution. Together, they build and release tension. In preparation, players observe their surroundings—enemies, objectives, and pathways—to form a plan. In execution, they carry it out but must adapt to emergent threats. Every system ties into these phases to create dynamic, horror-driven encounters.
Horror Dilemmas 🤔
We settled early on the concept of a horror game where light was scary, but in pre-production, we encountered two dilemmas:
1) Combat Encounters?
Combat builds anticipation and tension, especially in survival horror with limited resources. However, to make light truly scary, we needed to limit the player's control over it. Making it a core mechanic led us to favor stealth instead.
2) Systemic vs. Cinematic Horror?
Scripted encounters can heighten tension in stealth horror, but since light is a dynamic, physical, and interactive element, we favored a systemic design approach instead.
References from systemic an cinematic games, with and without combat.
An enemy investigating the area after the player steps into the light.
Two aggressive enemies searching for a player with many strikes.
Core Mechanic
Enemies & Light 😈
Stepping Into the Light 💡
The core concept of the game was that light was more dangerous and scary than darkness and you wanted to avoid it. We designed it so that whenever you stepped into the light, enemies would come to investigate, and become more aggressive overall.
Enemy Aggression 😡
Enemies had a random chance to come and investigate the area close to the player. Behind the scenes, you got a strike every time you stepped into the light. The more strikes you got, the more likely and persistent enemies would be to investigate you. While simple, this system created escalating tension and difficulty throughout the experience and the illusion of intelligent enemy AI. Isak, our Tech & System Designer, did great work in creating this original system
Strike Cooldown ⏳
While the strike system created an escalating tense experience, it was unforgiving. Strikes never reset or cooled down, which made the game difficult and frustrating to players. Player deaths and the constant presence of enemies also dissipated tension. Since the experience of tension was more important than difficulty, I added a strike cooldown mechanic where strikes decreased over time if you didn't re-enter the light. The more strikes you had, the faster they decreased.
Code: Strikes Cooldown Logic 💻
The strikes cooldown logic ran on Event Tick (other logic was also run there, but for simplicity, this graph focuses on the cooldown logic). The strikes only cool down when the game is not under the "fake pause" state – a state that stops enemy movements while the player is using data terminals. The Time to lose strike variable is a float curve with an exponential pattern making the cooldown time to lose a strike faster the more you have.
Core Loop
Two Stealth Phases 🌓
After researching stealth loops and mechanics in other games, I designed the core loop around two stealth phases that you cycle between.
Preparation Phase 🔍
This phase is all about observation and information gathering. For example, exploring the area, identifying risks and points of interest, observing enemy behavior, and so on. You can do this from a safer distance. Based on your learnings, you then plan your approach and objectives. Observation and planning would also help create anticipation and tension for the execution.
Execution Phase 🏃♀️
This phase is about embracing tension and danger and executing your plan. However, in the preparation phase, you have limited information, and while executing your plan, enemies will also be seeking you out and there will be traps in the environment. Thus, you'll have to adapt, and as you do, you'll initiate a new cycle of preparation and execution.
Core Loop Diagram
Diagram of the core gameplay loop and the two stealth phases of preparation and execution.
A player seeing a keycard and making a plan to get it (preparation phase; anticipation). They then EMP the light and quickly run to pick up the keycard and escape before the light turns back on, the moths return, and the enemies behind them catch up (execution phase; tense).
Phases & Tension ⛓
The purpose of the phases was to build and release tension. Switching back and forth between the phases naturally creates high intensity and low intensity moments.
The preparation phase is safer but helps build anticipation for the execution, and then building the courage to embrace danger and follow the plan makes execution more tense.
Examples
Preparation Phase 🔍
The player observing the room and the enemies' movements, making plans, and awaiting a good moment to sneak by.
A player browsing logs and looking at the map to plan their next objective and route.
Examples
Execution Phase 🏃♀️
The player quickly EMP-ing a lamp and navigating the shadows to escape investigating monsters.
An observing player quickly escaping a new enemy by running through the shadows of the fan, narrowly avoiding both enemies.
Emergent Gameplay 🌱
The core loop and stealth phases are enabled by the emergent interactions between the systems in the game, namely the interactions between the player, tools, enemies, and level. We tried to design each of these elements to encourage interactions between them. Overall, the interactions add an element of unpredictability to the gameplay and give rise to emergent tension and personal scenarios.
System Interactions Diagram
The interactions between the core systems of the game that enable the emergent gameplay.
Emergent Gameplay Example
An enemy walks into a motion sensor, which turns on a lamp that lights up the player, leading to the enemy killing them. Hover for sound.
Gameplay Loops & Objectives 🥅
The core loop permeates the gameplay short-, medium-, and long-term. No matter the time horizon, players will be cycling between the preparation and execution phases. When I designed the gameplay loops, I kept this in mind and tried to keep the objectives as intuitive and diegetic as possible since we had decided to keep the narrative simple, explanations at a minimum, and wanted to keep players immersed in the tension and atmosphere of the game. I tied objectives and progression directly to physical objects and challenges on the ship. For example, finding a key to unlock a door to progress to the next area.
Short-term Loop 🚶♂️ | Medium-term Loop 🗝️ | Long-term Loop 🚀 | |
|---|---|---|---|
TIME FRAME | Second-to-second gameplay | Minute-to-minute gameplay | ~45 min (a complete playthrough) |
OBJECTIVE | Survive and stay out of the light. | Find keycards and unlock new areas. | Learn what happened on the ship and find a way to escape. |
GAMEPLAY | Use tools and abilities to avoid the light, and to sneak around, lure, and escape enemies. | Navigate the area and locate keycards and data terminals. Maintain and recharge your battery level. | Explore the ship, read logs, and find a way to unlock the escape pods. |
A player picking up a keycard and unlocking a new section door at a data terminal. The keycard was placed in an encounter to onboard players to the EMP tool and the moth behavior.
Keycards 🔑
Sections of the ship were quarantined and locked. To progress, you had to find keycards to increase your clearance level and unlock sections at their nearest terminal. This provided intuitive and immersive objectives while letting us plan for interesting encounters.
Placing keycards in the level was a challenge. On the one hand, we wanted use the keycards to create challenge and tension, encourage exploration, and direct players. On the other hand, we didn't want players to risk missing them. To resolve this, I:
-
Made them glow with a recognizable positive color.
-
Made them detectable with the radar tool.
-
Collaborated with the level designer to place them where they provided interesting encounters while still being easy to spot from a distance.
I coded and implemented the doors, the keycards, and the data terminal unlocking logic.
Code: Automatic Doors 💻
I implemented the doors in the game. Here is the event graph, including the logic for opening, unlocking, animating, and saving the doors. Unlocking doors is done from data terminals through an interface.
Silhouette of Jackie in a mirror – the only time we get a glimpse of them.
Onboarding
In our ideation workshops, we decided as a team to We had two dilemmas: 1) should we include combat or not? and 2) should we lean more into systemic or cinematic horror?
Making Light Scary 😱
A main challenge in the game was to turn players' intuitions around to build anticipation and tension around light rather than darkness. To do this, I designed, implemented, and collaborated on the following:
Immediate Feedback ⚠
I collaborated with the UI and sound designers to implement immediate negative feedback when you step into the light, including a HUD warning, a sound effect, and enemies roaring. This helped in making stepping into the light tense and impactful.
A player stepping into the light. Notice the HUD warning, light vignette, warning sound, and monster roar. Hover for sound.
Motion Sensors 🤸♀️
I added motion sensors that turn on nearby lights if you walk into them, which creates jump-scares as well as anticipation when you see monsters turn lights on in the distance.
Monsters walking into motion sensors that turn on the lights in the distance, creating anticipation and tension.
Enemy Behavior 🔦
When enemies investigate your presence, they will flash the area around them, which helps build anticipation and mechanically gives you a reason to hide and avoid them.
Monsters investigating the player's presence and flashing the environment around them.
Encounter Design 🤫
I created encounters that would build anticipation around light or encounters that would prompt the player to make mistakes that would make them scared of it, e.g. walk into motion sensors.
The first time we see and hear the monster. Notice how it walks towards the light.Hover for sound.
Gameplay & Systems Design 🎮
3Cs, Movement, and Navigating the Darkness 🚶♀️
I designed the 3Cs (Character, Camera, Controls) and movement abilities of the player. I focused on immersing the player in the horror, making the experience feel close-and-personal, and encouraging timid player behavior and high-intensity moments.
For a game that is about avoiding the light, one of our biggest challenges was making the darkness navigationable. I was responsible for figuring out how dark the game would be, how the darkness would be achieved, and how we would make it navigationable. I did rapid prototyping of different lighting and set-ups and collaborated with artists and other designers to make the ship easier to navigate and encounters more memorable.
3Cs Design 🦸♀️
As a gameplay & systems designer, I focus more on loops and progression, but in this project, I also did the 3Cs design.
Camera 🎥
We didn't have resources to create custom character animations or well-developed player narrative, so we made the game in first-person. We figured this would also immerse players and bring them closer to tense enemy encounters.
I also experimented with PC-based FOV values to enhance these effects and induce a sense of claustrophobia, but decided to go with the values that felt the most natural and comfortable for players to use, as not to create frustrations and distract them from the gameplay.
We added head-bobbing and breathing sounds to immerse players further in the horror, increase the perceived intensity of encounters, and make the experience feel close and personal. For accessibility, we made the head-bobbing toggleable and added camera sensitivity settings.
Player standing still and observing. Notice the head bobbing.
The player using their hand-held radar and looking down at their legs.
Character 👩🚀
We felt like the scenario of a lone survivor in a infested and broken ship was enough for players to immerse themselves in the character, so we left the protagonist's backstory up to the players imagination.
Since the game was all about light, we wanted the player to have a shadow, so we added a 3D model to the player. We also wanted to make UI and tools diegetic immerse the player and tie them physically to the world, and the model allowed us to add hand-held tools to the player.
Overall, I tweaked the player movement values to make them slower, build tension and encourage careful and timid player behavior.
Controls 🕹️
There were a lot of mechanics in the game and I wanted interactions to be smooth to not interrupt the horror experience, so I tried to keep the controls as intuitive as possible by adhering to conventions among similar titles. I collaborated with the UI/UX designer on this, and together we also implemented button prompt pop-ups for all interactions.
I initially made crouching a hold action. I wanted to make it feel intentional and was thinking that holding the button would increase sense of tension. However, players ended up spending a lot of playtime crouch, so for accessibility I made crouch toggled instead. In contrast, running was a hold action since we wanted to make it situational and risky action, rather encouraging players to rush through the game.
For accessibility, and to accommodate player preferences, I also added customizable key bindings for the Steam Release. I made UI button prompts adapt dynamically to selected bindings and to gamepad vs keyboard controls.
The player picking up and using the EMP. Notice the button prompts and instructions.
The player crouching to hide from a monster.
The player walking to a motion sensor and panickily running away, only to run into a new one. Hover for sound.
Movement Abilities 🚶♂️
Crouching 🧎
Crouching is a staple mechanic in stealth games. In ours, it makes you move slower and helps you hide from the light and investigating enemies. Mechanically, all it does it make decrease your visible area compared to standing up. However, even though enemies don't have any perception of noise, players still have a preconceived expectation that crouching makes you more quiet, so most players crouch when sneaking around enemies. We tried to encourage this to slow players down and increase tension in close encounters.
Running 🏃
We added running to increase intensity and encourage panic and mistakes in intense encounters, e.g. accidentally setting of a motion sensor or getting discovered by an enemy. I made the running only marginally faster than walking to increase the tension in these encounters, especially since we only had walking animations for the enemies.h was great.
Jumping 🦘
Jumping is such a natural and reflexive action for many players that the inability to so can make them frustrated and break immersion. Because of this, I initially included jumping without any real gameplay purpose to it. However, this just crated frustration since players tried to use jump to get around obstacles and solve problems where it was ineffective. Ultimately, I removed it. This limitation to your abilities actually helped induce anxiety and tension as well, which was great.
Navigating Darkness 🧭
Since the game was about fear of the light and most of the game would be about navigating the darkness, it was essential to quickly determine how dark the game would be, how it would be achieved, and how it could be made navigationable. This would have significant impacts for both artists and designers.
Prototyping Questions ⁉️
Based on my experience with Unreal, dependencies between disciplines in the team, the game concept itself, and personal research of navigating my apartment in the middle of the night, I came up with prototyping questions. For example:
-
How dark can the darkness be without being frustrating to navigate?
-
How can the darkness be achieved? Global illumination, exposure, settings, lights, distance fog, etc? How bright should the lights be?
-
Does the player need guiding lights? If so, where should they be placed and how strong should they be?
-
Is a flashlight needed or appropriate? How strong should it be?
-
What color should lights be?
-
What factors are the most important for environment art in making the darkness navigationable? Color value, material roughness, silhouette, etc?
Rapid Prototyping ⌚
To make quick iterations and test different configurations of lighting setups, I created a testing level environment and tool where I could quickly toggle between different setups with the keyboard.
Toggling between different lighting configurations. First between different guiding lights setups, then between different flashlight intensities, ranges, and sizes, and finally comparing two versions of the heat visor shader.
Show Guide Lights By Index Method 💻
This method was used to toggle between different guiding lights setups. The lights were just boxes with an emissive material that were tagged by their placement on the walls (e.g. "Bottom", "Top", "Middle", etc.) The method gets all the lights in the scene by their given tags and toggles them on and off. Since the scene was only used for these lighting tests, performance was not an issue and this setup allowed for quick prototyping.
Rapid Prototyping Iterations 🖼️
Lighting prototyping test 2
Lighting prototyping test 2
Lighting prototyping test 1
Lighting prototyping test 1
Lighting prototyping test 2
Lighting prototyping test 2
1/2
Prototyping Insights 👓
-
Complete darkness does not work. It's too frustrating, a complete blocker. It's necessary to see corners and silhouettes.
-
Walls, floor, and ceiling can't be too dark. Brighter values are necessary.
-
Metallic & smooth walls, floors, and ceilings are more visible and look good but makes the edges of lit up areas less clear.
-
Guiding lights are more or less necessary and are best placed at the top.
-
Guiding lights on cover are not necessary but may assist in guiding the player. Use sparingly.
-
Variance in color value (dark/light) for cover assets placed in the room helps in seeing contours and navigating the space.
-
Smooth & metallic materials are generally more visible.
-
-
Flashlight is helpful for navigation, especially within larger rooms.
-
A short range, with a 33° cone, and strong intensity is best. The short range enhances tension.
-
May still require guiding lights in large rooms.
-
Results & Implementation 💡
Complete darkness was frustrating for players to navigate. In the end, I collaborated with artists to add emission textures and guiding lights to the environment and to adjust material parameters like roughness and brightness. I created master materials for all environment assets. I also added a faint point light to the player so that you'd notice when you bumped into walls and cover.
A player navigating the darkness without any tools. Notice how the wall is slightly more visible when you walk close to it because of the faint light emitted by the player.
Remaining Challenges 😓
Making the darkness and ship easily navigationable remained one of our biggest challenges throughout all of the development. Players got lost, accidentally backtracked, and lost their sense of direction.To resolve this, I:
-
Collaborated with our level designer to make paths within areas clearer, to make the level design, lighting, and asset usage less repetitive, and to add choke points and one-way valves.
-
Collaborated with the environment artist to make standout assets with clear profiles.
-
Crafted encounters and challenges to make areas more memorable.
-
Collaborated with the UI designer to improve the UI of the map and the UX of doors being unlocked, quarantined, or compromised.
-
Worked with the sound designer to add more unique sound profiles to areas of the ship.
-
Added clearer feedback about objectives and progression, e.g. through audio broadcasts that confirmed your progress.
-
Adjusted tools (e.g. the Heat Visor) to make the environment more visible.
-
Added brightness and graphics settings.
Code: Environment Master Material Shader💻
I made all the shaders for the game. This is the graph for the environment master material we used for e.g. the floors and most of the props. Unfortunately, variable names aren't visible in this exported graph, but the material includes exposed parameters for almost everything. For example, textures & texture adjustments, world-aligned textures, UVs, albedo adjustments, ambient occlusion, emission & animated emission, metallic, roughness, normals, dirt, surface imperfections, etc. I collaborated with artists to make sure it fit their needs and workflows. Overall, the master materials made workflows efficient, including from the gameplay standpoint, if we wanted to adjust e.g. emission strengths on all our guiding lights and props.
A room with a unique and memorable lighting setup and challenge – timing the fan to get to the other side without stepping into the light. Emergent challenge is added by monsters in the vicinity.
Notice the clear difference in the UX for the unlocked and locked doors and standout and memorable cocoon and pillar in the center of the room.
Gameplay & Systems Design 🎮
Player Tools, Interactables, and Enemy Types 🔧
I helped ideate, iterate on, and implement the three tools we had in the game:
-
Radar: Shows enemies and points of interest. Helps you plan and navigate and builds anticipation and paranoia.
-
Heat Visor: Makes it easier to see in the dark and highlights dangers and interactables. Emphasizes dangers and rewards and creates tension through a high battery drain.
-
EMP Tool: Lets you temporarily turn off lights. Helps in getting past obstacles and avoiding danger. Creates anticipation and high-intensity moments.
I also helped design and implement interactables and challenges:
-
Data terminals are central for navigation, narrative, and progression.
-
Recharge stations are used for charging your limited battery that all the tools use. They are designed to build tension.
-
Two enemy types: stationary moth swarms that follow lights and provide a puzzle challenge, and patrolling monsters that provide a dynamic emergent challenge.
-
Motion sensors turn lights on when you step into them. Build paranoia, emergent challenges, and high-intensity moments.
Three Tools 3️⃣
The player can equip three tools: a Radar, Heat Visor, and EMP tool. The player starts empty-handed and can find them around the level. There is no combat in the game; the focus of the tools is to navigate the darkness, identify dangers and objectives, and get around potential threats.
All the tools drain a common limited resource – battery, which can only be recharged at special charging stations. Limited resources are a staple in survival horror games and help create tension.
We came up with the ideas of the tools together among the designers. Isak – our Tech & Systems Designer – prototyped them, and I iterated on the designs and helped implement them.
The player detecting enemies with the radar and then using the EMP to turn off the light and sneak past them.
The radar in action. The red dots are enemies, and the cyan icon represents a data terminal.
Radar Tool 📡
This was a hand-held directional radar tool that showed the location of enemies and interactables (e.g. data terminals, recharge stations, keycards, etc.) Gameplay-wise, it lets you keep track of incoming enemies and identify points of interest, both in your current room and in the adjacent ones. It helps you navigate around dangers, set objectives for yourself, and plan your approach.
Emotionally, the purpose was to create anticipation about enemies, provide tension by providing you with objectives and the dilemma of what to prioritize, and induce paranoia since it's directional and you won't know what's behind you.
Radar Iterations 👨🔬
Initially, we had planned for a more careful and slower playstyle where the player had greater control over the environment. They would be able to use terminals to control lamps, doors, and airlocks.
The challenge and horror would come from not knowing where enemies are when you control these, making calculated risks but not knowing for sure you just put yourself in danger or reduced a threat.
The radar would show similar signatures for both interactables, people, and enemies. The original purpose of the radar was therefore more about detecting and deducing what was inside rooms before making any rash decisions.
Similar gameplay from the game Duskers, which served as inspiration for the original concept.
Heat Visor 🕶
The heat visor is a screen overlay that makes it easier to see in the darkness. It shows contours of objects in the environment and highlights enemies, interactables, and motion sensors.
While the radar lets you detect things on the other side of walls and cover, this tool is limited to line of sight. Still, it provides a more helpful tool for navigating directly in the darkness.
Emotionally, the heat visor highlights and emphasize the danger of enemies and the rewards of interactables. It also creates tension through a high battery drain.
The heat visor had a strong gameplay connection to the motion sensors. They were barely visible by the naked eye, and not detectable by the radar, but highlighted with the heat visor. This induced paranoia, where players used the heat sensor to check if an area was safe before entering.
The player navigating the darkness with the heat visor. Notice how contours are more visible when it's on, and that enemies are highlighted.
The heat visor in action. Notice the red cones (motion sensors), enemies (orange), and interactable recharge station (blue).
Challenge: Button Spamming ⚠
Initially, players optimized their heat visor usage by spamming the toggle button to turn it on and off and use less battery. We discovered this through telemetry and playthrough footage. The strategy distorted the experience, broke immersion, and encouraged aggressive behavior. To fit it, I added a battery cost to turning on the tool, nerfing the strategy.
Heat Visor Implementation 💻
For simplicity, especially when integrating the tool with the others, the heat visor is implemented solely through a shader on a 3D plane in front of the camera. I coded the shader.
Early in development, I collaborated with the artists to establish a common color language for the game. Summarized, enemies and dangers were associated with warmed colors like orange and tools, UI, and interables to blue-greenish colors. This permeated all aspects of the game, including the highlighting colors for the heat visor.
Code: Heat Visor Shader 💻
This material was placed on a 3D plane in front of the player camera, applying the heat vision effect to everything behind it. An alternative was to make it a post-processing material instead, but this in-scene approach was more coherent with how we implemented the other tools, making the implementation easier and more maintainable. The shader uses custom-depth stencil passes to apply different effects to different props depending on which stencil value is applied to them. I made custom effects for props, interactables (e.g. data terminals and recharge stations), enemies, and motion sensors. Unfortunately, variable names didn't get exported with the shader graph.
EMP Tool ⚡
The EMP is an extension to the hand-held radar tool that allows you to temporarily turn off lamps. Doing so lets you sneak past in the darkness. It can also lure enemies away; moth enemies will always search out the strongest light, and will switch light if their previous one is turned off.
Emotionally, the EMP creates high-intensity moments of timing and running past an EMP:ed light before it turns on again. It also has a very high battery consumption and needs to be used sparingly.
Original Idea 🤔
Originally, what lead to the EMP idea was that we wanted some way for players to manipulate lighting. Initially, we thought about flares, flashlights, and lamp wall switches. However, since the game was about fear of the light, we didn't want the player to have too much control over the light. In contrast to the other ideas, the EMP helped reinforce the fear and power dynamic since it's used to disable the light, rather than turning it on, and since it's temporary and creates anticipation for the light being turned on again.
Player Feedback 💥
Among other things, I implemented the feedback for using the EMP (the light flickering, VFXs spawning, sound playing, etc.) I thought the flickering was important to sell the effect and to create anticipation for the high-intensity moment of running past the EMP:ed light.
The EMP in action. Notice how the moths move away to another light when it's turned off and return once it's turned on again.
The EMP feedback. Notice how the light flickers and then sparks in anticipation when the tool is used. Hover for sound.
Code: Lamp Flickering and EMP Events 💻
I implemented the logic for flickering lights and the EMP-ed light events. The EMP turn light on and off events are triggered from elsewhere.
A player switching between the radar and the heat vision to keep track of enemies and motion sensors. Notice their different battery drain rates.
Battery System 🔋
To add tension all tools drained battery – a limited resource that could only be replenished at charging stations. Isak – our Tech & Systems designer – designed this system. I adjusted the drain rates for each tool depending on what behaviors and emotions we wanted to encourage:
-
Radar: Low drain. We wanted players to use the tool a lot to encourage paranoia.
-
Heat Visor: High drain. Didn't want players to overuse the heat visor since it was powerful for navigation. Moreover, since it was powerful and players wanted to use it, we also wanted the high drain to contribute to tension.
-
EMP: Very high drain. To emphasize the high-intensity moment of using the EMP, and to not make it too overpowered, it drains a lot of battery.
Recharge Stations ⛽
We wanted to place recharge stations around the map. That way, we could pace and balance the limited battery with encounters, and create chokepoints or points of interest.
I designed them so that the player had to look at the station while charging, or the action would be interrupted. This meant that they would have their back towards the room, which would create tension and emergent horror scenarios with the monsters patrolling around and searching for you.
A player charging their battery at a recharge station. Notice how they have to look at the station and turn their back to the room and enemies arrive while they're charging. Hover for sound.
Tool Comparison 🔢
Here is a table for comparing the different tools, the intentions behind them, and how they work in the game.
Radar 📡 | Heat Visor 🕶 | EMP ⚡ | |
|---|---|---|---|
Description | A hand-held directional radar that shows the location of enemies and interactables (e.g. data terminals, recharge stations, keycards, etc.) | A visor that makes it easier to see in the darkness. Will show contours of objects and highlight enemies, interactables, and motion sensors. | Extension to the radar tool that allows you to temporarily turn off lamps. |
Gameplay Function | Lets you keep track of incoming enemies and identify objectives and points of interest, both in your current room and in the adjacent ones. | Makes it easier to navigate the darkness and notice dangers. Essential to avoid stepping into motion sensors. | Turning off a lamp lets you sneak past in the darkness. It can also lure some enemies away. |
Emotional Purpose | Create anticipation about enemies and tension by providing you with info about objectives and dangers, and the dilemma of what to prioritize. | Highlight and emphasize the danger of enemies and reward of interactables, and to create tension about quickly draining battery. | Create high intensity moments of timing and quickly running past an EMP:ed light before it turns on again. |
Battery Drain | Low | High | Very High |
Player Challenge | Look around to be aware of your surroundings. Balance risk and reward. | Using it sparingly and maintain your battery. | Time the lights and be careful with the battery. |
Introduction | Early game | Mid game | End game |
Preparation Phase | Identify objectives and dangers and their locations in your current, and adjacent, area. | Get a better view of the layout of the area and locations of motion sensors and points of interest. | Get to better and safer points for observation. |
Execution Phase | Keep track of objectives, enemy locations and movement, and discover dangers and points of interest. | Navigate the darkness and motion sensors, and highlight visible enemies and interactables. | Get past lights without being discovered and lure away enemies. |
Data Terminals 🖥️
I collaborated with Astrid – our UI/UX designer – to design and implement the data terminals. These were diegetic interactable data terminals that were placed around the level. They had three gameplay functions:
1) Override Doors 🚪
Given that you found the appropriate keycard, terminals could be used to override quarantined doors and let you progress to new areas.
2) Navigate the Map 🗺
The terminal had an interactable map of the ship that you could use to get an overview of the area, establish your footing, and plan your route and objectives.
3) Read Logs 📚
Each terminal had a collection of data logs. These contained lore, information about enemy behaviors, helpful guides, and hints about points of interest. They were the main way the narrative was delivered. They weren't necessary to progress, but helped to immerse and guide the player.
A player browsing logs, navigating the map, and overriding a new area.
Code: Terminal Interact Event 💻
I collaborated with Astrid – our UI/UX designer – to design and implement the terminal. The terminal itself was a child class of an interactable class with an interact event that was triggered when the player interacted with it. Among many other things, I coded the interact event for using the terminal. It e.g. unequips player tools, switches input, toggles widgets and player visibility, transitions to a fixed camera view, and calls the event that stops enemies from moving while you're using the terminal.
A player overriding the first door. Notice the log with instructions for players that need them, and the notification on the security tab.
Challenges ⚠
-
The UX of the map. Astrid and I collaborated on icons and controls to make it intuitive to understand and use.
-
Awareness about the override. Some players struggled to find the override option needed to progress. We did our best to highlight the tab, add helpful logs, and create an onboarding encounter. In the Steam release, I also added a prompt that appeared for struggling players.
-
Player safety. Initially, players could be discovered and killed while using the terminal. This was to put players in a vulnerable position and keep them on edge while using it. However, players spent a lot of time reading logs and interacting with the map and got frustrated by deaths and interruptions. In a Steam patch, I made it so the game was essentially paused while you used a terminal, but added an option for disabling it for players that wanted full immersion.
Enemy Types 😈
Moth Swarms 🦋
Moth swarms are drawn to light. They always move to the strongest visible light source in their vicinity. If it's turned off, they'll move to the next best option. If the player steps into a light or gets too close to them, they will attack.
The purpose of the moths was to, in contrast to the patrolling enemies, have a more stationary enemy that provided a puzzle challenge, where the player could lure them around by manipulating lights. Once they discover you, they would also continue chasing you into the darkness until you built up enough distance, which would create high-intensity panicky moments. The stationary and patrolling enemies also create interesting emergent challenges when combined in the same scenario.
The biggest challenge with the moths was communicating and balancing damage. I iterated on and implemented various feedback (damage vignette, sound, etc.) to make it clear when and how they hurt the player. In balancing damage, perceived danger and tension were more important than actual challenge, but at the same time, the damage had to be high enough that you couldn't just run through and ignore them.
Moths moving between lights once one gets turned off, and then returning to the strongest light again when it's turned back on.
Moths discovering the player and chasing them around into the darkness.
Two aggressive monsters investigating the area around the player.
Big Boi Monsters (BBMs)* 👽
These monsters patrol around the environment and search for the player. They have a random chance to investigate the area around the player, which increases when the player steps into the light. Their main purpose is to keep the player on their toes and create emergent horror scenarios and challenges. Read more about the strike and aggression system in the Gameplay Loops section.
Isak – our Tech & Systems designer – designed and implemented the enemy AI. I did tweaks to the strike system and worked with feedback to make important moments scarier, e.g. the enemy kill-cam/jump scare and making the enemy roar once it discovers you.
The randomness in the enemy behavior builds emergent scenarios, and with more enemies added, those increase further. I collaborated with the level designer and tried to introduce more enemies in the level where they would prompt the most interesting encounters and to an extent that wouldn't overwhelm the player.
*actually the official name within the team xD
Motion Sensors 🤸♀️
I designed and implemented the motion sensors for the game. When you step into one, they turn on adjacent lamps, lighting you up. The sensors are barely visible by the naked eye, but you can see their radius with the Heat Visor tool. Their purpose was to:
-
Make players more aware and paranoid about their environment.
-
Create high-intensity moments, surprise, and fear of the light.
-
Add a challenge that didn't directly hurt you, but that lit you up and attracted enemies.
-
Create anticipation and emergent scenarios by turning lights on when enemies walk past.
Originally, we wanted to do this with other enemy types: larva mines that sprayed you with fluorescent liquid, glowing enemies that chased you and kept you in the light, and so on. This would enhance the narrative, atmosphere, and monster fantasy, but with our big monsters, we didn't have resources for any other ones. The motion sensors were a quick alternative that fulfilled the same function.
A player accidentally walking into a motion sensor. Notice that they are visible without the Heat Visor, but are much easier to see with it. Hover for sound.
Code: Motion Sensors 💻
I implemented the motion sensors. We use a cone mesh that's only visible with the heat vision for triggering overlap events. When actors like enemies and the player trigger the overlap, surrounding lights turn on. When all actors end the overlap, the lights are turned off again after a delay. The lights and motion sensor communicate via an interface. The same interface is used e.g. for lights controlled by timers. Also, notice that Steam-based telemetry is implemented for the sensors.
The game getting saved by a terminal, and then getting saved again by a trigger as you trigger an accident that blocks your path back. Hover for sound.
Saving 💾
We didn't want players to save manually since we felt it would dissipate tension. We tied saving directly to progression, making the game save when you unlocked a new area. This centralized interactions around the data terminals and timed the saves with progression and challenges. It also created tension between save points.
Additionally, we added triggers that saved the game when you walked into them. I added these e.g. at the start to make the first enemy encounter less punishing, and for a surprise encounter when your way back gets blocked.
Filip – our programming lead – created the save system and I implemented the saving and loading logic for most of the actors in the game.
Gameplay & Systems Design 🎮
Encounters & Data-Driven Design 😨
I designed many of the encounters in the game. Significant ones were:
-
Start of the game. Introducing the enemy and building tension and a sense of danger to establish the horror, induce fear, and encourage a timid playstyle.
-
The timer challenge. One room has timers that toggle lights randomly with moths moving between them. Thanks to telemetry and playtesting, we realized it was frustrating for players, leading me to do a full redesign of the encounter.
-
Onboarding. I designed most of the onboarding encounters for the different tools, enemies, and challenges. Some that underwent significant iterations were the moth & EMP onboarding and the first enemy encounter.
-
Cocoon anxiousness. I created a scenario to build anxiety around monster cocoons, which we could leverage to add tension to other encounters and areas of the ship.
Thanks to the telemetry data we got through our Steamworks integration, I made improvements to the game and encounters that increased median playtime by 50%.
Establishing Tension 😥
Challenge ⚠
Initially, players rushed through the game, which reduced the tension. I identified that this was because of how the start of the game was designed.
In our first version, the player started by walking through a straight corridor with broken ship sounds and VFXs to establish tension. We also onboarded the crouch action by making the player crouch under a pillar.
However, the long straight corridor made players impatient, so with the lack of apparent danger, most of them ran through it. They then kept this pace throughout the whole experience.
Solution 👩🍳
I designed a scripted encounter to establish a sense of danger and collaborated with our level designer – Douglas – to adjust the space to slow players down and make them more paranoid.
We replaced the corridor with a room with twists and turns. Moreover, when you crouched under a fallen pillar, I created a scripted event where an enemy roars and walks past you. This:
-
Established a sense of danger and a reason to be careful.
-
Conditioned players to associate the crouch action to hiding.
-
Hinted that the enemies were attracted to light.
These actions helped make players play slowly and carefully, increasing tension and paranoia, and setting up the stage for the first actual encounter with the enemy.
1) First Version
2) Updated Version
The first version of the start. Notice the straight corridor making players impatient.
The updated version of the start. Notice the enemy passing behind the window when you crouch under the pillar, and the twisted layout of the new room.
The scripted encounter in the updated version where the enemy roars and walks past when you crouch under the fallen pillar. Notice that it walks towards the light. Hover for sound.
Timers & Data-Driven Encounter Design 🧪
I managed the Steamworks integration for the game, leveraging Steam's Stat system for telemetry. Thanks to these stats, I identified areas of difficulty and frustration to players and was able to fix them. In total, improvements thanks to telemetry increased median pay time by 50%.
Example Challenge: Timers ⚠
The player map was divided into three sections. Before our Steam launch, I noticed that 78% of all player deaths were in the third area. However, we struggled to identify the issue, so for the launch, I divided the stat for the third area into four sub-areas.
This revealed that the issue was a room with a unique challenge with moths and timed lights. There were four lights in the room, turning on one by one in a clockwise pattern, with moths moving between them. After discussing with playtesters, I realized it had two problems:
-
Bug: There was a bug that made moths unforgivingly dangerous.
-
Misunderstanding: Many players missed that the lights were toggled in a predictable pattern.
Player Deaths Breakdown 💀
Full List of Telemetry Stats 📃
General
Player Count
Games Started
Games Completed
Games Continued
Games Restarted
Games Reloaded from Pause
Times Quit From Pause
Times Paused
Brightness Adjustments
Difficulty
Death Count Moth
Death Count BBM
Area 1 Deaths
Area 2 Deaths
Area 3 Deaths
Area 4 Deaths
Area 5 Deaths
Area 6 Deaths
Progression
Terminal 1 Overrides
Terminal 2 Overrides
Terminal 3 Overrides
Terminal 4 Overrides
Terminal 5 Overrides
Terminal 6 Overrides
Terminal 7 Overrides
Terminal Overrides
Gameplay & Tools
Logs Read
Enemies Juked
Sensors Triggered
Times equipping radar
Times equipping heat visor
Times equipping EMP
EMP Use Count
Times lit up by lamp or enemy
General statistics of engagement, incl. red flags for rage-quits and bugs.
Statistics for difficulty and challenge by ship area and enemy type.
Statistics for progression. Let's us keep track of conversion rates between areas.
Statistics for how people play and what they engage with.
The timer room. Notice that one of the lights randomly turns off after the shortage, and the moths under the light in the distance, ready to move to the next best light if theirs turns off.
Solution ✅
Thanks to the data and the feedback, I was able to implement the following for the day one patch to reduce difficulty and frustration.
-
Moth bug. I resolved a bug that made moths insta-kill players.
-
Timer rework. Rather than turning the lights on in a circle, I made them all shortage every few seconds, and every time they did, they each had a random chance of changing their state when they turned back on. This gave players moments to time, while reducing risk and confusion, and still adding an element of randomness and adaptation. Thus, building tension and anticipation while reducing frustration and confusion.
-
Audio broadcast. I added an audio broadcast that plays when you unlock the area and warns about unpredictable power levels and shortages. This gave players a heads-up, a narrative explanation that reduced frustration, and induced tension.
Code: Timers 💻
Astrid – our UI/UX designer – and I collaborated on the first version of the timers. The timers themselves ran on a custom Tick interval rather than actual timers, and communicated with lamps through an interface. The new timer logic is under the InteractWithRandomDelays event. We could select if we wanted the new or old logic for a timer with a boolean. Overall, I designed the new event for randomness and tried to reduce the total amount of changes in the scene at any shortage to make the encounter less overwhelming.
Onboarding the Moths & the EMP 🦋
Due to the stage we were at in production, we had to onboard moths behavior and the EMP tool in the same encounter. I designed the encounter and collaborated with our level designer on the level around it.
Encounter Design
Once you enter the area, you see a keycard at the end of the corridor in the middle of a moth swarm. By this time, we have built anticipation about moths with the environment, radar, and data logs. If players try to rush through the swarm, they will likely die.
If you sneak on the side, you'll find the EMP tool in the shadows right next to the moths. Once you equip it, you get a prompt to aim it at a lamp and fire. When you do, the lamp turns off and the moths move away, giving you a chance to pick up the keycard and escape. The lamp turns back after a short delay and the moths return.
We made several iterations. Two impactful changes I made were:
-
Blocking the way back. Several players were afraid of the moths and chose to backtrack. I created a scripted event that blocked the way back, creating tension and surprise while forcing players to face the EMP–Moth puzzle.
-
Keycard placement. I made sure the keycard was visible from far away, placed it within the swarm, and moved it to an inconvenient position that made it difficult to rush through the moth swarm and encouraged players to use the EMP.
Overview of the moth and EMP area. The player can see the keycard from the start. After they pick up the EMP and use it on the lamp, the moths move to the next one, letting the player pick up the card and escape.
The accident being triggered when the player walks into the room, blocking the way back, and forcing them to find a way around the moths. Hover for sound.
The EMP moth puzzle. Notice how the moths move away to the other light once their current one is turned off, and how the keycard is placed visibly but inconveniently to the edge, making it hard to rush through.
Cocoons 🕸
To add tension to areas, I created a scripted event to make players anxious around cocoons, from which it's implied that the big monsters emerge. I did this in two steps:
1) Introducing Cocoons 🤨
At the start of the game, I placed a cocoon in a central ship area, right in from of the player when they enter. The cocoons look unsettling, this is the first one you see, and, at this point, you're already on edge since you just saw the first enemy. A discrete spotlight highlights the cocoon, making sure it makes an impression.
The first time the player sees a cocoon. Notice the unsettling look and how it's extra visible in the darkness.
2) Building Anticipation 😲
Later in the game, you'll return to this area to progress. Once you approach it, you hear a roar from the distance, and once you enter, you see that the cocoon is open. Thus, you get anxious about monsters emerging from the cocoons.
A player returning to see that the first cocoon has opened.
The fan room with the recharge station and cocoons. Notice how they're placed right next to the station to induce anxiousness.
3) Exploiting Cocoons 😰
Soon after you've seen the opened cocoon, you encounter a fan room with a recharge station right next to a bundle of cocoons. The room is tense because of the fan challenge and having to recharge your battery next to the cocoons with your back toward the entrance makes it even more so.
No monster ever emerges from the cocoons, but we continue to exploit the anticipation around them throughout the game.
Alpha Encounter 💡
The alpha build. I designed the encounter for the alpha build, where we tried to make a proof-of-concept of the game.
1) Combat or no combat?
Combat encounters can be great for building anticipation and moments of tension, especially in survival horror games with limited resources. However, to make light scary, we wanted to limit the player's control over it. We wanted to make it a central mechanic, but not a combat mechanic. Thus, stealth made more sense.
2) Systemic or cinematic horror?
In a stealth horror game, cinematic and scripted encounters are powerful tools for building tension and memorable experiences. However, light was a focus of the game, and since it's something physical and interactable, the systemic approach was more interesting.
Both of these choices also fit the best with the team's skills and resources. For example, we didn't have any animators or VFX artists permanently on the team to make the combat tense and impactful.
References from systemic an cinematic games, with and without combat.
TECHNICAL DESIGN
Highlights from the design of the core concept and intended experience of the game. Also includes the Miro board.
Gameplay & Systems Design 🎮
Redesigning the Core Mechanics ✍
For being a game about light being scary, the player doesn't interact much with it. Most of the mechanics are about navigating the darkness rather than avoiding or interacting with the light. However, golden moments for players tended to be encounters like the fan rooms where the challenge relied more on physics-driven light interactions than, for example, avoiding motion sensors.
To explore this further after our Steam launch, I made a prototype to completely rework the core mechanics and encounters to lean more into these types of natural and physics-driven interactions. I gave the player the ability to interact with physics objects and added new types of obstacles. I also built a more advanced AI from scratch that also responded to noise and other cues.
KEY TAKEAWAYS
bottom of page