GENRE
Puzzle / Platformer
CONTRIBUTION
Gameplay Design
Core mechanic
Puzzle design
Player movement
Programming
Sound design + FMOD
TIME
4 Weeks
(2023)
TEAM SIZE
10
ENGINE
Unity
tenebrosity
First Person
PC
Online Co-Op
10 - 15 minutes
Tenebrosity is an online two-player co-op puzzle platformer.
concept
For our second Game Project in Futuregames, we had the mission of making a co-op game with the theme of “symbiosis”. Since our programmers had the experience, we decided to make an online puzzle adventure game about two cult members who are trying to escape the cult.
My main role for the project was sound designer and composer, but I still took on other tasks that my fellow designers couldn’t work on due to illness or unavailability while spending time focusing on the gameplay elements
game pillars
Puzzle / Exploration
Puzzles are the main challenge the players face, with the addition of the danger of the darkness.
Communication
Force communication between the players, make them talk to each other.
Fear & Tension
Make an unease atmosphere; something might happen at any minute.
design process
While focusing on ways to make a symbiotic game, we reached an agreement that we wanted a dark game that would bring tension with its lack of light and uneasy environment. Thus the idea of controlling light sources and having them be a safe haven was one we wanted to explore.
While a lot of ideas were discussed for the player’s abilities, we were advised by one of our mentors to focus on two mechanics - if we had those nailed on then we could progress further.
That’s when we decided to have one player control the light sources and the other control objects via telekinesis.
While we originally decided on asymmetrical gameplay - both players would have different abilities. The more we worked on the game, the more questions were raised on how to not make one player less engaging than the other.
To solve this, we realized making the game symmetrical would be better since then we could force the players to act in asymmetrical ways by making the level separate them.
player movement
An important part of the gameplay was that the darkness would make the player freeze and unable to move - which would require for the other player to come and unfreeze the other one with a light source. Therefore the movement couldn’t be slow and sluggish - it had to have speed and be able to move from one light source to the other (since these were able to be manipulated but for a limited amount of time).
early development build
During the early level design process, the areas that were tested were relatively small - so the player speed would allow for fast traversal - but we wanted to keep things eerie and tense.
To solve this, the levels were expanded into larger areas and thus the player movement was ideal to traverse these areas with platforming elements.
final build
game loop
communicate
To decide how to solve the problem
observe
Enter new area and observe the environment
solve
the puzzle and advance forward
puzzle design
One of the designers had the task to design one of the puzzles, but fell sick and couldn’t continue for a few days. Since time was of the essence, I had their permission to keep working on it. The bare bones of the puzzle consisted of having the players separated, and having one do a task that depended on the other one’s information to complete it to succession. One player would have 3 levers with different colors and the other player would see 3 items with the same colors and they would need to coordinate.
First blockout of the level and puzzle
Since we were using a shader that only allowed the camera to be rendered using a limited color palette, the idea of having three different colors wouldn’t cut it, so I decided to replace the 3 colors with 3 different symbols.
Then, the player with the levers would communicate to the other player which lever/symbol they’re pulling, while the other player would notice the respective symbol rotate (to indicate that one was pulled). At the same time as a lever is being pulled, a spotlight will turn on momentarily on a specific symbol as feedback. This would indicate the correct order the levers would need to be pulled in order to activate the exit door.
Final result with the symbols.
sound design
Regarding the sound design, I’ve had experience using FMOD and everything was going ok implementing sounds via FMOD Studio and via code as well. But since this was a bigger project, I’ve encountered issues with the amount of resources FMOD was utilizing. Therefore this was my first time working with FMOD’s Profiler in order to see the resource distribution and how it affected the buffer size, helping me determine what was causing performance issues.
It was a challenge to determine which events needed instance limitation but I gained a lot of knowledge in this area, which will help me be more cautious of resource management in the future. Even after the completion of the project, I contacted FMOD’s customer service to make sure that I learned the optimal ways to manage resources so I could keep them in mind for future projects.
In this video, it can be seen how I used a variety of over 15 individual sounds - with FMOD's Multi-Instrument - to achieve variation and colour on the use of the three levers.
For my VO part, I used iZotope RX, pitch shifting and reversed reverbs to achieve an ominous and evil character.
what i learned
Playtesting!
We spent so much time as a team focusing on making the mechanics work and systems function with each other that we put playtesting on the back seat. As a result, we ended up with a game that worked, but it was not fun.
After the end of the project, I asked some friends to playtest the game, one of them was very adamant about how the movement of the player was super fun and how they loved to jump around with it. Knowing this earlier in the development process would’ve helped to know where to focus on the development of the game - perhaps on the platforming elements of the game rather than the puzzle.
I am now much more conscious of how important is to constantly playtest - within the team and with external people - in order to grasp if the game is fun or not and what is properly communicated to the player. This would’ve also saved us a lot of time while we were debating what to keep or remove.