PROBLEMS SOLVED.
NOT JUST GAMES MADE.
These aren't feature lists. Each card covers what I was trying to do, what went wrong, and what I changed because of it.
at Keywords Studios
invited for occasional paid playtests across AAA & AA titles, under strict NDA.
2025–present.
Building a Shared Design Language Across a 23-Person Team
Mayday Racers — Unity arcade racing game, 2024–2025. The design challenge wasn't the game, it was getting 23 people to build the same one.
Unity
C#
My Role was the Project Lead, I was responsible for making sure the development process went smoothly between all 3 departments.
- Establish a shared vision between all departments, all of us needed to LIKE the idea of the game
- Confer with the 3 department leads to make sure everything ran smoothly, each team would use a shared notion tracker to be kept up to date with each other
- Identify issues that could spawn from lack of communication, leadership, etc and develop a solution to fix them as quick as possible.
- Towards the contribution of the game itself, I would work on workshopping the UI of the game, conferring with each department to make sure it looks good
- A team as large as ours needed proper documentation that would be kept up to date, one that can be accessed easily by anyone should they need to
- Design decisions needed to be tested in real time as well as be understood by the team why certain choices were necassary
- As project lead, I had to make sure I would make the whole team run smoothly and not worry about my individual contribution to the team.
To start with, we needed a way for every member to be able to communicate with each other. To do this we made a discord server with everyone in it and gave everyone the suitable roles within it. This was to ensure we can effectively and quickly locate anyone if we needed to as well as see who is absent. I had organised the discord with multiple channels as well all being made for certain sections such as splitting discussion channels between each team.
To add on to that, I created the initial beginning of the Notion Wiki which would be given to everyone so they can add content to it. The leads would have admin but everyone can access and add things to it. It was imperative that we had proper documentation to look back on so our vision of the game remained consistent in all manners. Within the notion, I had also created a task list for each team to use to make it clear who was assigned to what during the project all with a timeline we had to follow to meet the project's deadlines.
On top of that, I had created the initial Git repository for the project to be stored on. This was majorly important as there would be many people working on the project and being able to branch off different versions would help smooth out the process. The tech lead would have control over the whole repository as the tech department would be the people using it the most.
Overall, my main mission was making sure the creation of the game went smoothly as project lead and help manage 3 departments of 23 people for the final goal of our vision, one we created together.
The outcome from the project was an almost finished project. We had run into a few issues regarding the communication between departments
which were sorted out closer to the end of the project, which heavily limited us for time. In order to deliver our final working product, we
would have to cut a lot of original content out from our initial plan. Our tutor's had given us feedback on our vertical slice which would carry on
towards the completion of our project, namely that we needed more collaboration and needed to ask for help more when it was needed while also managing
our time far better.
Overall our final collaboration project came out well, with a well designed map alongside a responsive player controller. More content would've been planned and implemented
had we had more time/learned to collaborate earlier within the project.
Designing Horror Atmosphere With Emphasis on Audio
The Captain's Pyre — solo PSX-style horror prototype in Unreal Engine 5, 2024–2025. Create genuine dread with focus on audio and pyschological horror elements.
Unreal Engine 5
// Beginning environment
// Example of dialogue
// Captain's Quarter's level
// On the deck level
My brief was to investigate how to create an effective sense of dread within the player utilising narrative techniques and audio.
- Create an effective narrative that would slowly build up the feeling of dread within the player
- Utilise audio and environment design to keep the player feeling on edge, making them think twice about seeing or hearing something
- For my last project, ship a full game from start to finish to showcase as the culmination of all my skills at university
- Dread doesn't come from cheap jumpscares and scary monsters, it comes from making the player uncomfortable and making them second guess their actions.
- Creating a branching narrative allows for replayability and for different ways each player can experience the story.
- Playtesting solo made it hard to feel the dread, utilising new people made it easier to understand how other people would be affected and feel.
For this project, I had to focus on making the player feel dread. Doing so I had to think of a variety of factors including art direction, sounds and level design. To start with I used a PSX style of art as it is traditionally used in horror projects due to its low res uncanny gritty feeling. For the gameplay itself, I wanted to make simple puzzles alongside a simple inventory system. So I developed a basic inventory using data tables that can easily be accessed at any point I needed to to give each item an attribute I can call whenever I needed to for each puzzle. In terms of puzzle complexity, I focused on super simple pick up and place in the correct areas to unlock the next section as I wanted to focus on the build up on the narrative.
Narrative wise, I used twine to build up the story, its visual interface helped with seeing how each dialogue bit would branch out so I can create multiple endings for the player. It also helped with the basic "Karma" system I put in place, the more good choices you picked gave you the good ending and vice versa. Implementing the dialogue system was easy with the help of an asset I used which had its own blueprints that helped with streamlining the process.
Finally, on the audio side of things. I am not traditionally an audio designer, but I spent a lot of time finding and locating the right sounds that would play in certain times to invoke the dread feeling. For example, the creaking of the ship while the waves crashed in the dark would feel quite eerie to the player.
The outcome of the project I felt was successful though lacked as much dread as I was hoping to achieve. On first playthroughs, player's would occasionally jump at the sound of something breaking or a loud bang, keeping
them on edge. But as they reached the middle of the game, that novelty wore off, as they started to expect it more. The dread feeling had worn off and they were more interested in the dialogue rather than the gameplay itself.
Overall, the inital study was concluded as a success but I had not executed it as well as I had liked. Though this had provided me with valuable information for the future if I was to attempt a similiar project again. As noted in my
GDD, I have wrote more in depth, details of the investigation and received a high mark for the submission.
Scope Under Pressure: Designing Atmosphere in a One-Week Jam
Sohvanii — PSX-style anomaly detection horror, made in one week for a university game jam. The challenge: build a complete, atmospheric experience with two people in seven days.
Unity
- Deliver a complete and fun game within the 7 days time limit we were given that followed the theme
- Make the overall gameplay loop easy to pick up and understand without the need of an arbitary tutorial
- Design an atmosphere that would create a feeling of dread within the player to motivate them to complete the night
- Deciding what to keep and what to cut given the time limit we had
- We had to quickly and reinforce the core loop as soon as possible to not take up much time
- We focused on getting things completed that we both understood first to have a protoype ready, then iterate upon that for the final game
With this game jam, me and my friend Ben had decided to create a game that had a simple element to it. You are in a room, things will get disturbed and you need to notice it quick and fix it lest you be killed by the ghost. We designed a system where each object was within a struct we can access at anytime. They would all be given a random chance to convert into the 'Anomaly version' of themselves which the player had to notice or they would start taking damage. The player had a time of 3 minutes to survive which would mean they make it to 6am to unlock the good ending. Else if they die, they unlock the bad one.
We used a PSX art style as it would be effective in creating the feeling of horror due to its gritty and low res textures. Since we had a basic level consisting of one apartment, we hadn't need to worry too much on making too many assets, but we still took the time to place them in locations that made sense for the player to notice.
We managed to complete this for our internal ARU game jam within 7 days successfully and got good reviews from our fellow students, we had used sourcetree to make sure our project was saved in each commit we made.
The outcome overall was good. We had delivered a working game from start to finish within 7 days that players enjoyed playing. We had gotten a few classmates to playtest beforehand
and iron out the major bugs but when we released it the reviews we got were good. Some players found it hard with some objects being too subtle of a change and others found it easy so we felt
that the balance had worked well in hour favour.
The lecturer who ran the jam also enjoyed it, we ended up being one of the top 3 projects being submitted due to its fun loop and simple gameplay, easy for anyone to pick up and play.
