• Genre: 3D Third-Person, Open World, Walking Stealth Simulator
• Engine: Unity
• Development Period: March 2024
• Role: Technical Producer / Associate Game Designer / Art & Development Support
• Team Size: 6
• Platform: PC / Itch.io
• Status: Released
• Planning: Miro
• Tools: Unity, Visual Studio, Github Desktop, Blender 3D

The team consisted of a Technical Producer, Game Designer, Level Designer, Lead Developer, 2D Artist, and Sound Designer. However, as with many short development cycles, most team members had to extend beyond their primary specialties and support other areas when needed. This flexibility allowed us to share responsibilities, overcome resource limitations, and keep development moving toward the deadline.

Unfortunately, this project was not documented as thoroughly as our other works, so there is limited material available to showcase its development process and visual progress. Nevertheless, it was a valuable experience for me from a production perspective. I took a more supportive role, coordinating the team and departments, tracking progress, communicating with team members, identifying where additional support was needed, and helping allocate resources accordingly. Despite the tight seven-day timeframe, we were able to maintain our momentum and successfully complete and submit the project within the deadline.

This was where I started working closely with the Lead Developer and other departments to establish practical restrictions on the proposed mechanics and content. Our goal was to keep everyone aligned and ensure that the project remained achievable within the seven-day timeframe. For a project with such a short development cycle, we needed to focus on a small set of clearly defined and achievable features, which meant making compromises and cutting many of the ideas generated during brainstorming.

While the brainstorming continued, we also began defining the core gameplay and development process. Before the second day began, we had agreed on the main features and created the necessary tasks, allowing the team to move quickly into development.

The team immediately started building the foundations of the project. This included preparing the GDD, implementing the basic gameplay mechanics, creating animations, developing ideas for sound effects and music, and working on character customisation.

At the same time, I closely monitored the needs of the other departments, particularly sound design and music, to make sure they received the necessary information and assets as early as possible. This allowed them to begin their work without having to wait for other parts of the project to be completed.

However, we started encountering technical issues as the core systems were being implemented. To accelerate development, our Lead Developer suggested using the Unity Asset Store package Poly Art: Rabbit as the foundation for our main character. The team agreed with this approach, as the package provided a ready-made character structure that could also support character customisation. However, integrating our planned systems with the package assets became one of our first significant implementation challenges.

A similar issue emerged with the Wwise implementation in the following days, when conflicts began appearing between the project and the Wwise GitHub integration. As these technical problems started affecting the team’s progress, I gradually expanded my role beyond production and began providing technical support to help identify and resolve implementation issues.

I worked closely with the Level Designer to establish a manageable level size and ensure that the environment remained within the scope of the project. Meanwhile, the Lead Developer was dealing with issues involving animation flow and transitions between different animations. We were also still experiencing conflicts with the Wwise implementation during merges, which began creating frustration and disagreements between the Lead Developer and Sound Designer.

By this stage, the team was already feeling the pressure of having completed one challenge and immediately moved into another demanding seven-day development cycle. In such short development periods, technical problems, fatigue, and disagreements can quickly affect team morale and productivity. This was where my role as a Producer became particularly important. Rather than allowing the disagreements to escalate, I spoke with both the Lead Developer and Sound Designer to understand the underlying problems and worked with them to find solutions that would allow development to continue.

Some of the technical issues we encountered were new to me at the time as well, so resolving them became a valuable learning opportunity. It allowed me to strengthen my technical knowledge while also gaining more experience in managing pressure, resolving conflicts, and keeping the team focused on delivering the project.

As some team members completed or reduced their workloads, we used the additional capacity to playtest the game together, identify remaining problems, and discuss practical solutions. This allowed us to approach the final stages of development more collaboratively and address issues before they became larger problems.

Alongside the technical difficulties, however, the team was still experiencing disagreements between members. This became an important learning experience for me, as it reinforced how important soft skills are alongside technical abilities in game development. I was able to help ease the tension and bring the team back together, but the experience also showed me how important it is to consider communication, collaboration, and interpersonal skills when building a development team.

Disagreements are inevitable in collaborative projects, particularly under tight deadlines and high pressure. What matters is how the team handles those differences and whether everyone can remain focused on the shared objective: delivering something together. With this philosophy in mind, I continued providing technical support while also actively working to maintain team cohesion and keep everyone focused until the project was completed.

However, by the end of the fifth day, one of our key team members unexpectedly had to leave the project due to personal reasons. With only two days remaining, this created a significant risk to our ability to complete and submit the game on time. At the time, I was responsible for building the main menu while continuing to coordinate the team and track development progress.

Due to the sudden loss of an experienced technical member and the limited time remaining, I immediately stepped in and took over their responsibilities. Although I was not as experienced with those systems as the team member who had left, I took the initiative to work directly with the parts of the project that were unfamiliar to me. The situation required me to quickly adapt, learn what was necessary, and provide the technical support needed to keep development moving.

With the submission deadline approaching, I prioritised the issues that could prevent the game from functioning or being submitted over lower-priority quality-of-life improvements. This allowed us to focus our remaining time on stabilising the project, preparing the final build, and getting the game ready for submission.

The project also helped me grow beyond a purely production-focused role. As technical problems emerged with the character systems, animation, and Wwise integration, I began providing more hands-on technical support to the team. When one of our key technical members had to leave shortly before the deadline, I stepped into their responsibilities despite not having the same level of experience with those systems. This pushed me to learn quickly, work outside my comfort zone, and prioritise solutions based on what was essential for the project rather than what would have been ideal under normal circumstances.

Perhaps the most important lesson, however, was the importance of communication and team cohesion. The pressure of a seven-day development cycle, combined with technical difficulties and fatigue, led to disagreements within the team. Managing these situations taught me that production is not only about planning tasks and tracking progress; it is also about understanding people, resolving conflicts, maintaining morale, and keeping everyone focused on a shared objective. I became more aware of how important communication and interpersonal skills are when building and managing a development team.

By the end of the jam, I had developed a stronger understanding of how to balance scope, technical requirements, and team dynamics under pressure. I also became more comfortable taking initiative when unexpected problems arose and adapting my responsibilities to whatever the project required. Most importantly, the experience helped me evolve from someone primarily focused on coordinating development into a more versatile Technical Producer who could support both the people and the technical side of a project when needed.