University
Game
Date
Duration
Team Size
Producer, Tech Lead, Sound Designer, Level Designer
The Untold Story of Vísdómír is a first-person exploration game set in an abandoned town where the player has to piece together its history through clues, spatial observation, and careful navigation. One of the ideas that immediately drew me to the project was that the world should be explored without heavy UI guidance or quest markers, which made the layout and atmosphere much more important than in a more conventional objective-driven game.
This project was part of the Game World Design course, and I specifically chose it to get out of my comfort zone. This time I wanted to focus on production and game design. I think it is very important to understand how people from different backgrounds work in order to achieve better communication and therefore improve my work as a game programmer. My main role was producer, a role I had never taken on before. Through the book A Playful Production Process by Richard Lemarchand, I learned most of my producing skills. My other major role was tech lead, which meant shaping the workflow, keeping the scope realistic, and making technical decisions that supported smooth collaboration for a small student team. On top of that, I also took on sound and level-design responsibilities, so this project became a very direct exercise in combining organization, technical planning, and creative worldbuilding.
Producer was the role I wanted to learn the most on this project. It was new territory for me, and I deliberately used the course as a chance to get better at planning, scoping, and communication instead of only focusing on implementation. The report makes it clear that my main goal was to keep the project manageable and give the team enough structure that we could work calmly instead of constantly reacting to chaos.
Across the project, my producer responsibilities included:
During ideation, I focused on helping the team move from a broad concept to something we could realistically execute. I set up the practical work environment with Discord for communication, Notion for collaborative writing, Miro for brainstorming, and Google Drive for file sharing. At the same time, I started planning the different phases of the project using the course Gantt chart as a base.
In that phase, my role was not just administrative. I also helped guide the direction of the game. The team agreed on a first-person town exploration concept with simple mechanics, and I assigned design tasks around the core player experience, town layout, and the clue mechanic. The final narrative direction, including the oppressive knowledge-controlling society, emerged later in ideation, but one of my important contributions was making sure the project kept converging instead of endlessly branching into more ideas.
Pre-production was where my producer role became the most concrete. Based on the production framework I had been reading, I treated the key deliverables as a game design macro, a project schedule, and first mechanical prototypes rather than an unrealistic full vertical slice. Because our team was small and our time was limited, I deliberately pushed for multiple focused prototypes instead of pretending we could build a polished slice at that stage.
I scheduled tasks around the map layout, clue placement, narrative integration, the town-square board mechanic, and the first playable version of the controller and core features. Using information from the narrative and clue layouts, I helped organize the different areas of the map and turn that into a clearer macro structure for the game.
I also created the production backlog and organized the work into three two-week sprints. As part of that process, I estimated the workload for each task and quickly noticed that the art side was under much more pressure than the rest of the team. That was a real eye-opener for me. In many student projects, I had previously seen teams drift into a crunch phase without noticing the problem early enough. Here, the task estimation helped me spot the bottleneck in advance, and I was able to respond by looking for simpler and more reusable asset solutions before it turned into a bigger production issue.
Once production started, my work shifted from setup to rhythm. Because the backlog had already been structured well, our meetings became shorter and more focused on bottlenecks. I used the sprint setup to keep work visible and held retrospectives at the end of each sprint so everyone could present what they had done and where the project needed adjustment.
I also wanted the game to stay iterative rather than becoming a plan we were blindly following, so I scheduled us into the university playtest events during production. The first playtest was especially valuable because it gave us direct feedback on movement, the size of the town, and even the narrative through a paper prototype.
In post-production, my focus was on consolidation and polish. We had completed around 80% of the game during production, so this last phase was about analyzing what was still missing, bringing the remaining pieces together, and continuing to iterate on the level design. Because we had already started the documentation earlier, finishing the Game Design Document mostly meant completing missing chapters and updating sections that had changed during development.
Looking back, this is probably the part that best reflects what I learned as a producer: good production work is not only about schedules, but about giving the team enough clarity that the final phase can be spent polishing the game instead of still fighting the project structure itself. A well-structured production process led to less stress, and I definitely value the work of producers a lot more after this project.
My tech-lead work was closely connected to the producer role, but it had a different focus. Here the goal was to make the technical foundation simple, reliable, and well suited to the team. Since the project was a 3D first-person exploration game with relatively straightforward mechanics, I recommended Unreal Engine 5. The built-in first-person template gave us a working baseline immediately, and the engine also fit well with the asset-pack-driven workflow we needed for a small student team.
For collaboration, I suggested Git and GitHub because I was already comfortable with both, and I helped set up a GitHub Kanban board together with another teammate. Our branching model was intentionally simple: each task lived on its own branch, and all tasks, not just code, went through review. I handled merges and conflict resolution centrally, which kept the process much easier to manage for the rest of the team.
One technical choice I especially liked was using Actor Components to modularize gameplay logic. On a project like this, the biggest technical risk was not algorithmic complexity, but people stepping on each other's work. Components helped keep the code cleaner, while sublevels did the same for level design by making ownership of world areas much clearer.
A core design choice behind Vísdómír was that the player should not be handheld through the town. Instead of relying on objective markers, the environment itself had to carry orientation, story, and curiosity. That pushed us toward a world structure where clue placement, sightlines, and area identity mattered a lot. My role in production was to protect that idea from over-scoping, and my role in design was to help make the spaces readable enough that exploration stayed engaging instead of becoming frustrating.
For the soundscape, I looked at games like Outer Wilds, Firewatch, and Dear Esther as references for how ambience can shape the player's sense of place. I leaned into wind, footsteps, environmental creaks, and location-specific 3D audio rather than a heavy musical layer. The goal was to reinforce loneliness and make the town feel physically present, while also giving the player subtle feedback about materials, interiors, and nearby spaces.
I also liked this approach because it matched the narrative tone. The game is built around uncovering something hidden, so a sparse soundscape supported that much better than constant musical emphasis would have. Small sounds, such as touching paper or interacting with a locked door, lead to better readability of player interactions.
On the level-design side, I worked on the natural environment, especially the outskirts around the town. I also designed the farm area, which was built to communicate a sudden evacuation and the attempt to erase evidence of a failed experiment. Overgrown fields, abandoned tools, empty pens, and hidden traces of disposal all serve the same purpose: they let the player read the history of the place directly from the environment.