• Genre: 3D First-Person, Horror Game
• Engine: Unity
• Development Period: Jan 2024 – Feb 2024
• Role: Lead Unity Developer / 3D Animator / Associate Level Designer
• Team Size: 10
• Platform: PC / Itch.io
• Status: Released
• Planning: Miro
• Tools: Unity, Visual Studio, Github Desktop

I joined the Themed Horror Game Jam #16 and immediately began looking for a team to work with. Before the theme was announced, I used the time to prepare and practise the technical skills I expected to need. Once the theme was revealed, I immediately began implementing core gameplay systems, including the character controller and AI.

As the most experienced Unity developer on the team, I was assigned the role of Lead Developer and became actively involved throughout the development process. This required close communication with both the Producer and Game Designer to coordinate technical requirements and ensure that the development work aligned with the project’s direction.

After the first week, I divided my responsibilities with another team member, a Junior C# Programmer. I took ownership of the core gameplay systems, including the character controller, basic inventory system, FMOD integration, interaction systems, animation, and character rigging, while my colleague focused primarily on AI development.

During the first two weeks, we made significant technical progress. However, as development continued, the project’s scope began to become a major issue. The Game Designer placed a strong emphasis on polishing and refining details, which resulted in the team spending too much time on the first level and significantly slowed our overall progress. By the second week, I communicated with the relevant team members that we were falling behind the schedule and that our expectations and scope were becoming unrealistic for the remaining development time.

Unfortunately, we were unable to bring the scope under control effectively, and too much attention remained focused on details at an early stage of development. The resulting pressure eventually led to the team becoming overburdened, and despite our efforts, we reached the deadline with a buggy and unfinished game that could not be completed as intended.

Although the final state of State of Sarah was far from what we had originally envisioned, the project became a major learning experience for me. It was my first practical experience of working in a game development team, taking technical ownership, communicating across disciplines, and seeing firsthand how uncontrolled scope and premature polishing can affect an entire production. These lessons became particularly important in the game jams and projects that followed.

My priority was to establish the essential components required to make the game playable as early as possible. Alongside this work, I also began developing the initial AI systems while my colleague, who was supporting me on the programming side, took responsibility for implementing the inventory system.

While these core systems were being developed, the rest of the team began ideating and blocking out the game. This allowed us to work in parallel, with the gameplay foundations being established while the level and overall game design were taking shape.

By this point, the team had completed the initial blockout of the first scene, so I began working simultaneously on my development scene and the first playable scene. This was also when some of our first significant technical and production challenges began to emerge.

One of the first challenges involved integrating FMOD into the project for the Sound Designer. I had limited experience with audio middleware at the time, so implementing and troubleshooting the integration required additional research and development time. While working through these technical requirements, I began to recognise that our overall progress was falling behind the original schedule.

Part of the issue was the relationship between the project’s scope and our expectations for the final result. As a relatively inexperienced team, we had ambitious plans that were becoming increasingly difficult to deliver within the available timeframe. Once I recognised the growing schedule risk, I organised a meeting with the relevant team members to discuss the situation. We agreed to rescale the project, but even after reducing the scope, the remaining workload was still substantial for the team’s experience level.

We also encountered challenges in the art pipeline. Some of the assets being delivered required additional optimisation or adjustments before they could be integrated effectively into the project. I therefore began working more closely with the art department to establish clearer technical requirements, including appropriate formats, scale, and delivery expectations, with the goal of reducing integration issues and unnecessary iteration.

At the same time, we were spending significant development time refining details in the first part of the game before the core experience was fully established. This created additional iteration and required us to revisit areas multiple times, further affecting our schedule. Rather than attributing these issues to any individual, I saw this as a broader production problem involving scope, prioritisation, and the team’s limited experience working together.

Despite the increasing workload and schedule pressure, I continued working on the core systems, including additional hours when necessary, to keep the project moving toward the expected outcome. By the end of the second week, however, it had become clear that the combination of technical challenges, integration work, scope, and iteration was significantly slowing our overall progress.

By this stage, we had a playable version of the game. Players could explore and interact with the first level, and the basic inventory system had been implemented. For the first time, the core gameplay loop was beginning to take shape and the project was starting to feel like a functional game rather than a collection of individual systems.

However, there were still a significant number of issues across both the levels and gameplay mechanics. As a result, I began taking on additional QA responsibilities, testing the systems and levels, identifying problems, and helping determine which issues needed to be addressed.

At the same time, we continued spending a considerable amount of development capacity refining smaller details while some of the broader systems and content still required work. This created additional iteration and made it increasingly difficult to maintain the original schedule. Although the project was showing substantial visible progress, the amount of work required to bring all of the systems together and reach a stable final state continued to put pressure on the team’s capacity.

The extended period was largely spent on playtesting, bug hunting, rushed iterations of the second and third levels, and completing the remaining animations. As the deadline approached, however, it became increasingly clear that we would not be able to bring every part of the game to the same level of completion. By the time we reached the final submission, the game remained incomplete and contained bugs and technical issues that prevented the experience from being completed as intended.

The first level was comparatively polished and stable because a significant amount of time had been invested in refining it during the early stages of development. However, this also meant that the later levels and remaining systems had considerably less time available for development and refinement. The imbalance between early polishing and overall production progress ultimately contributed to the unfinished state of the project.

I had identified this risk during the second week and raised concerns about our schedule, scope, and the amount of time being spent on early-stage refinement. Although we attempted to address the issue by rescaling the project, we were unable to reduce the scope sufficiently to recover the lost time.

Despite the outcome not meeting our original expectations, we continued working together and delivered the project in the best state we could achieve within the circumstances. We ultimately treated the completed build as a portfolio piece and, more importantly, as a valuable learning experience that exposed the consequences of premature polishing, insufficient scope control, and not having enough development capacity to support the project’s ambitions.

One of the biggest lessons I took from the project was the importance of establishing a realistic scope from the beginning. We entered the project with ambitious expectations, but as development progressed, it became increasingly clear that the amount of work required was greater than what the team could realistically complete within the available time. I recognised this risk relatively early, raised the concerns with the relevant team members, and worked with the team to rescale the project. However, the reduction in scope was not enough to fully recover the time already lost, particularly as significant development effort had been spent refining parts of the game before the overall experience was sufficiently established.

This experience taught me that polishing individual elements too early can create significant production risks. A highly refined first section does not necessarily move a project closer to completion if the remaining systems and content are still underdeveloped. In future projects, I became much more focused on establishing a complete playable foundation first, then iterating and polishing once the full scope was under control.

The project also strengthened my ability to work across different disciplines. As the Lead Developer, I was responsible for implementing core gameplay systems, supporting animation and character rigging, integrating FMOD, assisting with lighting and level development, and taking on additional QA responsibilities as problems emerged. Working across these areas helped me understand how decisions in one department can affect the work of others, and how important clear technical requirements and communication are when multiple disciplines are working in parallel.

Another important lesson came from the technical and integration challenges we encountered. Working with unfamiliar tools such as FMOD, supporting the art pipeline, and resolving issues between different parts of the project required additional research, communication, and iteration. These challenges reinforced the value of establishing technical requirements early and making sure that assets and systems are prepared in a way that allows other departments to work efficiently.

Most importantly, State of Sarah changed the way I approached game development. The project showed me that technical ability alone is not enough to deliver a successful game. Development also requires realistic planning, prioritisation, communication, risk management, and the ability to recognise when a project needs to change direction. I learned to pay closer attention to schedule risk, team capacity, dependencies between departments, and the difference between what would be ideal and what is actually achievable within the available resources.

Although State of Sarah was ultimately delivered in an incomplete and buggy state, I consider the experience an important foundation for the projects that followed. It gave me my first real exposure to the challenges of multidisciplinary development and showed me where I needed to improve both as a developer and as a team member. The lessons I gained from this project directly influenced how I approached scope control, planning, communication, and technical production in my later game jams and projects.