“Navigate an eerie asylum and forest as you solve twisted puzzles, uncover your traumatic past and survive the embodiment of your trauma.”
My Contributions
I was responsible for creating the Player movement and all of its interactions with the world such as grabbing and climbing. Through playtesting we received a lot of contradicting impressions which, to me, became the most interesting part about iterating on the movement, since finding a balance between slow and snappy was difficult for our game.
The idea behind making the movement slow was to make the chase scenes more intense as the player wants to quickly run away from the monster but your character builds up speed pretty slow, which results in a “lean right to go faster“ feeling for the player. In retrospect the movement might have been slightly too slow and after watching multiple people play the game after its release date it’s something I reckon can be improved upon. I believe the annoying slowness could be fixed with a minimum walking velocity but this was deprioritized as my team and I felt that the movement was good enough. If I were to revisit the game today, this is most certainly the first place I’d start experimenting on once more to make sure that if the movement is slow it’s for a good reason.
Physics
I was also responsible for developing a fast and robust Physics system to enable our physics driven puzzles. I followed a Box2D talk from 2006 by Erin Catto titled “Fast and Simple Physics using Sequential Impulses” combined with spatial hashing using two grids, one static and one dynamic to speed up lookup. After blood sweat and tears this is what the result looked like.
I also implemented joints for us to be able to move objects in a more natural manner especially up and down slopes which looks something like this.
Now there is still an issue with this implementation that is you can get stuck in between box colliders which are side by side. This problem haunted the project for a long time until the level designers merged all of the hundreds of colliders into as few colliders as possible. There are still places where you can stand inside walls because of the collider edge. I think this issue could be resolved by checking the amount of overlapping you did with the box the previous tick to offset collisions of the next tick. So if you’re (-0.5, 0.0) into a wall, that would be the offset on other colliders. However the issue was easily “fixable” by the level designers and at the time, I had no idea how I would even start fixing the issue.
Particle System
In our game we wanted to have a lot of particles to make the world less static. For this purpose I created a particle system capable of simulating thousands of particles.
(10000 particles running at <1ms)
The particle system was just a simple object pool of particles getting updated one by one. It was mainly used for ambient particles floating around
(Black ambient particles floating around)
The particles had a number of possible settings such as shape, velocity, start and end size as well as randomization ranges for all of these variables. This gave the artists and level designers the fine grained control they needed to make the game as pretty as it is. I believe the particle system was pretty well made for this game and it did its job perfectly. If there was anything to improve it would probably be adding more settings but it wasn’t needed for this game so I’m incredibly happy with the system.
Continuing on the note of making the scenes less static, I was also responsible for the parallax effect as seen below.
This is simply a multiplier on how much the affected sprite should move in relation to the camera. It’s really simple to position as well. It calculates how much it’s supposed to move from a reference point where the sprite is at its reference point if the camera is at the exact same location.
The reference point is imported directly from the scene and then the position is corrected to match where the camera actually is. Every frame the sprite with this parallax component checks the distance from the reference point to the camera and multiplies its parallax factor with the resulting vector to get its new position from the reference point.
It served its purpose but it would’ve been nice to have calculated the parallax factor from a reference FOV and a distance from the camera as I think it would be a little bit more intuitive but my solution worked well enough for our game.
Post Processing Effects
(Vignette)
(Film grain)
Camera Movement
I gave the level designers the possibility of creating camera zoom and move regions dependant on the players position within the box keeping the resulting zoom afterwards which allowed level designers to specify the exact zoom level for our cinematic scenes.
Morbid Games
Programmers
Alexander Emland
Frederik Bjerno
Liam Sjöholm
Gabriel Beloqui
Simon Henriksson
Artists
John Almviken
Lovisa Österman
Emil Nilsson
Hedvig Karlsson
Animators
Soon-Ie L. O.
Agnes Bok
Level Designers
Nora Ekeblad
Kristian Sistig