
Game Name
Weavers of the Night
Engine
Unreal Engine 5.5
Dates
Jul 2025
Players take on the role of Cyrus, a researcher who has come to this desolate town in search of their lost research colleague, Blanche. This game was made over 21 days for the Classic/Static Camera Horror Jam. This game heavily utilizes fixed camera angles, tank controls, and an interaction system
Design Documentation
Draft Map

Level Progression
Below are a couple of in-progress and final iteration images that show the implementation of backgrounds

Campsite Blockmesh

Campsite Final

Walkway Blockmesh

Walkway Final

Hut Blockmesh

Hut Final
First Iteration
Second Iteration
Post-Mortem
What Went Right:
01
Design Pipeline – I was happy with my design pipeline and schedule. This was the fastest I’ve been able to design and produce levels/features as a solo designer and was glad I was able to be a reliable teammate as I met most deadlines for myself and got the first block mesh done early for the team artists to review.
Final Assets – I was very happy with the turnout of the scenes that did have completed backgrounds. When the illusion worked, I thought the game looked phenomenal and the final art assets also helped to set the creepy atmosphere and tone of our game world. It also was not nearly as time consuming to line up once we started working out the kinks with layering the backgrounds over the 3D models.
02
03
Jam Constraints – I was happy with my design around the constraints of the game jam. This game jam was focused on the fixed camera angles of classic horror and this constraint made me hesitate to participate. This was something I had never done and worried the design challenges would take up all my dev time in the jam. In the end, I was very happy with the functionality of my fixed camera angles and even found myself really liking some of the framing I was able to find for certain scenes. This happened to be a good learning experience for working with in-game camera transitions as well as tank controls and I won’t hesitate to try new ones in the future.
Proactive Team– The team members we had were also enthusiastic about the jam and that was good. We had quite a bit of members at first but as our numbers dwindled down we had a committed few that produced a lot of different pieces of work that made it in the game in some way or form. There weren’t moments where we had to really bother someone to get their work done as everyone was trying to produce good work, and that felt obvious in our communications.
04
05
Collaboration – Lastly, I was happy with my collaboration with so many different aspects of artists/designers. This was one of my first experiences really collaborating with game artists, sound designers, and writers so it was nice to see what each aspect needed of me as the game designer. This also helped to improve my communication skills as I was heavily conversing with each member discussing vision and implementation. All these experiences should help to serve me as I take on more collaborative projects in the future.
What Went Wrong:
01
Emergencies – When planning and scheduling the game production, you are supposed to set aside plans and time for emergencies. This was something we didn’t do in the rush of game jam production and we suffered multiple real-life emergencies that made some team members unavailable for a time or the rest of the jam completely. Had I planned to be feature complete ahead of time, or set up a contingency plan, I may have been able avoid these issues or alleviated the stress.
Time Differences – Our game jam team didn’t take enough time to communicate in the beginning. Many of us signed up for the jam very last minute and formed a team and from there were in a full sprint of production. We worked mostly asynchronously on our horror game idea but often would miss each other with different time zones and responsibilities. Discussing shared working hours could have been beneficial to planning the overall vision of the game synchronously and could help to decrease time waiting for a response
02
03
Scope – We also had an issue with over scoping our game. We had a lot of great and grand ideas but by the time I was able to get those ideas into the engine, we were running out of time to get in the core loop of our game and making sure it was complete and scary. This was something I should have been more cautious about, especially as the lead programmer/designer. With each project I undertake, I get a little closer to understanding the extents of my ability and what I can provide for my teammates, at the same time I want to remain ambitious to continue learning.
First Horror Game – Being my first horror game, I was unfamiliar with the systems I should be prioritizing and designing. Although I got my core systems complete, I wish I was able to give more development time to the horror elements of my game like jump scares, sound effects, roaming enemies, and overall atmosphere. I hope to next time plan my game to be feature complete ahead of time, allowing me to go back and focus on adding in these systems and sounds that add so much to the horror genre and feel.
04
05
Feature Planning – Lastly, we should have spent more time researching how to implement pre-rendered backgrounds. Although we all conducted some feature research separately, we never came together and planned of how to create and set these backgrounds up. This led to the first drafts of our backgrounds being unusable as we quickly learned the issues in our original design ideas. We lost a lot of time to re-doing backgrounds that could have been done right the first time, and that was due to not giving enough time to researching the feature in the design phase. Next time, I’ll make sure to spend more time on research and design phase as well as brainstorm with the relevant teammates when tackling an unknown feature like this. I also will make sure to focus on clarity when communicating as that cost some time as well.