Procution Blog Postmortem

Hello everyone, and thank you for joining us for the final production blog for Steel Specter.

I'm Daniel Lee, and I’ve been the producer throughout this project. In this final blog post, we’ll reflect on our development journey. Steel Specter is a fast-paced first-person shooter for PC, featuring a unique hacking mechanic that lets players take control of enemy bodies to gain new weapons and abilities. We appreciate you taking the time to look back with us on everything we’ve built.

What Went Wrong

When we first started the project, we tried to develop the entire game based on our design documents. However, as we went along, we realized that it was difficult to lead the development process using just the documents. There were parts in the documents that were unclear, so we had to revise and clarify them before we could properly move into development. Also, since it was our first time managing a team with more than 10 people, there was confusion about how to divide tasks and who should be responsible for what, and it took time to figure out the role assignments.

Starting from Sprint 2, we began working on the Body Frame models, and all of them were completed during Sprints 3 and 4. This process took up too much time, which caused a lack of models necessary for level construction. As a result, the level designer had to continue working with a temporary prototype using Unity’s Terrain system for a long period. Since terrain-related models started being created late, it also took a lot of time for the one level designer to place the actual models into Unity. During this process, the level designer ended up being overloaded with too much work at once, but at the time, we didn’t fully realize how serious the issue was.

Another problem was how we created task cards in Jira. We split the modeling tasks into separate cards: “modeling,” “UV work,” and “texturing.” On the surface, it looked like we were breaking the work down in detail. However, in reality, it made the modelers feel like they had more work than they actually did, which ended up reducing their focus and efficiency.

What Went Well

Dividing tasks into smaller parts may have backfired for the modelers, but I think it worked well for the programmers and the level designer. The programmers implemented their assigned features one by one without disrupting the overall development flow. Through this iterative process, they were able to identify bugs easily and also reduce conflicts that could occur when merging their work. The level designer, too, was able to easily decide how to modify the level based on player feedback using the prototype build as a base.

Every team member did their best in their respective roles, and as a result, each of them produced high-quality outcomes in their areas. The animation team created excellent rigging and various animations for the robots and their movements. The programmers successfully implemented all the core gameplay elements and integrated them into the game without any major bugs. The 2D artist created digital-style UI and simple icons that matched the overall atmosphere of the game. The modelers produced impressive and diverse robot models as well as a variety of props related to the game environment, which enhanced the visuals of Level 1 and the tutorial significantly.

Regular meetings also greatly contributed to the success of the project. The programmers, level designer, and lead designer held daily meetings via Discord, providing feedback on each other's work and making sure the game stayed true to its original direction and core loop. Thanks to this gradual but steady pace of development, we were even able to implement the Stagger System—something that wasn’t part of the original plan. This system added more variety to the combat experience for players and also further reinforced the game’s core concept of hacking into enemies.

What I Would Do Differently

One regret I have is that we set the initial development pace too slowly. We waited for the 2D artist's concept art and tried to build models based on it, but that ended up delaying the creation of the robot models early in the project. Next time, I plan to start modeling right away using reference images, even without finalized concept art, by deciding early on what kind of visual style we want. Also, while the model team is working on the robots, I’d like to utilize the animation team more effectively by assigning them additional tasks, such as creating environmental models, since they don’t have much to do until the main models are ready.

Another thing I would change involves how I assigned tasks to the modelers. Instead of breaking down each step like modeling, UV mapping, and texturing into separate Jira cards, I would give them a single card per model. When I split the work into too many cards, it made the modelers feel like they were doing more work than others, which in turn slowed down the overall development process. I think having just one card per model would help both with morale and efficiency. Additionally, I would make sure not to assign the same type of task to every modeler. This time, all of them ended up working only on character models, which meant that environmental props and other assets were barely made. That workload was pushed onto the level designer, who ended up having to do too much at once.

Regarding the level designer, I realize now that I made a poor decision. At one point during the project, our level designer had to switch to another group. When the professors suggested that we bring in a level designer from that group to replace them, I declined the offer. At the time, I thought our project was already far enough along that a new designer would struggle to catch up with our flow. But in hindsight, I think bringing someone new in could have actually helped. Originally, we planned to finish up to Level 2, but since we only had one level designer who focused all their effort on the tutorial and Level 1, Level 2 had to be cut. We ended up adding an endless mode instead, but it felt more like a temporary solution. So in the future, if we run into a similar situation, I won’t be so quick to reject suggestions to bring in extra help.

What I Would Do Next Time

In the future, I plan to hold regular full-team meetings so that more team members can participate. Until now, certain information was only shared among the programmers, the level designer, and the lead designer. I believe that if this information is shared with all team members, everyone will have a better understanding of the overall development progress, and they will be able to quickly recognize and respond to any areas. As a result, the overall efficiency of development will improve.

What I Learned

One of the biggest things I realized during this project was how important the pre-production phase is. When documents aren’t clearly organized, team members can easily get confused during development, and communication gets tangled, which eventually leads to lower work efficiency. So next time, I think it’s important to clearly define roles and documentation from the beginning, and regularly check that everything is still on track as development progresses.

Another major lesson I learned was about schedule management. I really felt how setting vague or late deadlines for asset creation and implementation can directly affect the next stages of development. It’s crucial to set clear deadlines early on and make sure all team members understand how those deadlines fit into the overall development timeline.

And finally, I strongly felt that the whole team needs to be aware of the project’s development status. That’s why I now believe it’s much better to have regular full-team meetings to share progress and quickly talk through any missing pieces so we can solve them together.

Sprint Overview

During the past Sprint 7, I assigned a total of 614 points to my team members, and 607 of those were completed. We finished almost all of the assigned tasks, and the remaining ones were categorized as “Wish” cards, so I believe we effectively completed everything we planned. I want to thank my team members for doing their best on every task. I also want to express my gratitude to everyone who has followed our production blog up to this point.