concept

This project was part of a Level Design course in which we were tasked with creating our own prototype. Fortunately, I was the only team member who was not a Level Designer, which allowed me to assume full ownership and responsibility for gameplay and mechanics - spending most of my time inside the engine, programming its systems.

The project drew inspiration from games like Alien: Isolation and Dead Space. In our game, the player awakens in a damaged spaceship infected by alien spores. As the player's oxygen supply diminishes, they realize that these spores accelerate oxygen consumption. Consequently, they must navigate cautiously, avoiding these spores until they find the final key to unlock the doors leading to the escape pods.

Not only I had lots of fun programming the systems, this project also served as an excellent exercise in terms of gameplay. We conducted constant playtesting sessions with other groups, enabling me to iterate on what was effective and what wasn't. This ensured that players experienced intense pressure without feeling overwhelmed

design process

In our initial meeting we discussed how we would approach the project and quickly agreed about the game’s win and lose condition, alongside the objectives and hazards the player would run into. The player would have an oxygen meter that would slowly deplete, while certain areas where the spores were would deplete it quicker - some faster than others. Along the way the player would find oxygen pickups and keys that open specific doors. The last key found would open the final doors that represent the escape pods, thus finishing the game session.

the spores - I added vfx for player feedbak

With everything decided, I quickly jumped into the engine to start working on the oxygen system and subsequently the spore hazards - elements that constituted the second-to-second gameplay. I would then move onto the minute-to-minute gameplay with the oxygen pickups and doors and finally into minor elements such as the elevators.

oxygen system

The player’s life source was a fairly simple mechanic to program, but since the spores affect it in different ways and these were reiterated constantly, the event graph quickly became disorganized and I needed to adapt - so I collapsed it into a function.

I took advantage of this project to improve in my knowledge of interfaces. I was familiar with them and was aware they are preferred when it comes to cross-blueprint communication, but I never felt fully comfortable with them. By the end of this project, I was implementing them without second guesses on last-minute additions - as I utilized them to communicate the win condition as well as the objective system that pops up whenever a player encounters a locked door or a key.

gameplay

The good thing about having playtesting sessions is that we were quick to determine what was working and what wasn’t. One of the main things I reiterated the most was how much the spores affected the player’s oxygen. The reason for this is that playtesters would end up finishing the game with more than 80% of their oxygen - so there was no real sense of urgency or stress.

At first, I decided to just ramp up the Depletion Multiplier, making it very costly to traverse through the spores. Even with this, players would still finish the game virtually unscathed. What I noticed was that players were now more careful regarding the oxygen pickups, whereas previously they would ignore them - as they weren’t really needed. Therefore I reduced the amount of oxygen the pickups would give.

problem solving - an iterative process

Despite this, there still wasn’t a sense of urgency. Discussing it as a team, we were looking at the problem in a very zoomed-in method - the spores, the pickups, pickup locations, etc. It didn’t occur to us until later to zoom out and look at the larger picture: we could make the player constantly lose oxygen. This way, they would always have to be on the move - the sense of urgency was finally there. After this moment, I went back to the engine to implement this and consequently look into how this change affected the other systems. You can look into my iterative process above.

final section after you pick up the last key

sound design

For the sound design, I used Wwise for implementation. Since the scope of the project was small, I didn’t take the time to do more complex implementations by way of Parameters, States or Switches. Nevertheless, I did want to take the opportunity to work closely with how Wwise handles Obstruction and Occlusion. Having default values dependent on the project, I worked closely with these to make sure the sounds felt cohesive and part of the spaceship, without breaking immersion.

retrospective

Despite being a small project, there are several things that I cautiously take with me for further projects. For example, the use of delta time for our oxygen mechanic would definitely be problematic in larger-scope projects - I would rather use a Set Timer by Event node.

There are also elements that I would’ve put more care into if we had more time, such as the objective system. It felt janky to have it be programmed as a trigger box that changes the text depending on a specific key you pick up. I feel a better system would’ve made this less problematic and would also open doors for more interesting narrative ideas. If a solution solves 2 problems, then it’s a great solution.

Overall, it felt great to be scripting and coming up with solutions to our gameplay problems - further establishing my interest for these disciplines.