Hello and welcome to the final Production Blog for Entoworks! For this postmortem, I’ll be looking at what went well in development, what could have gone better, and what I learned from this experience. For those of you tuning in for the first time, Entoworks is a lightweight turn-based strategy and tactics game where players are challenged to best utilize their team of up to three entogear (robot bugs) to beat the enemy entogear on a variety of unique maps. Over the course of Entowork’s development, our team of 17 developers completed 966 points worth of work. I’m very proud of what my team accomplished and excited to show off how production went!

What Went Well

Although our project had some issues with scope, I feel that we were able to pivot and complete the project with a good result. I’ll be explaining in more detail our problems scoping later on, but at the end of sprint 4, we realized that development was going a lot slower than we initially expected. At this point, we had a serious talk with the team and re-evaluated expectations. Entoworks was initially planned to have a robust upgrade system so that the player could customize their entogear to best take on each challenge presented to them. We attempted to work on this system for four sprints with some success but eventually realized that we only had a half-built upgrade system and a half-built combat system without any finished deliverables. I talked with my designer about what I felt was possible considering the velocity until now and we decided to get rid of the upgrade system. We also tweaked the combat system to make it more manageable, removing some of the finer details about how projectiles worked and level hazards. 

Although this was disappointing, I was able to keep my team encouraged by assuring them that we would find a place for any work not currently part of the new design. We added models from scrapped biomes to ones we were keeping and were able to repurpose upgrade UI as battle UI. Although it was a change we were hoping not to have to make, it was a possibility that was accounted for and with the new scope of the game, we were able to finish with ample time for bug testing so that we could make a more polished, slimmer game.

What Went Poorly

Since this was my first project working as a producer and I had never worked with a team larger than five people at this point, I was unsure what a team of 17 could get done. As pre-production was cut down to a day and a half, I struggled to learn a new software, Jira, as well as create a sizable backlog for 17 people over 7 sprints. This led to multiple sprints where I felt consumed by the backlog and was unable to get a good look at what we would be able to achieve over the full project. This was partially because not all of the user stories for the project had been inputted so sprint statistics were heavily skewed.

Additionally, I spent most of my time with Vivan, our Lead Designer, reading through and understanding the GDD when I should have had Vivian working on the ALR much earlier. I wanted to be entirely clear on the design of the game before starting to write any user stories, however, I spent too much time dissecting the GDD and did not give myself enough time to write those stories.

Since I was unable to keep up with the demand for user stories from my team, it caused some scope creep. Our team had about the same amount of people in every department but while our environmental modelers could complete 10 points a sprint, our programmers might spend just as much time on 6-8 points. Therefore, we had to widen the scope for the modelers and this inevitably caused the scope for the programmers to widen as well. In addition, due to Vivian’s simple tile-based level designer, levels were being completed and tweaked quicker than we initially imagined. Because of this, we decided to add many new biomes to the game so that the modelers and level designers would have plenty to do. The scope was already too big for the programmers, as we would soon find out, so I had to learn how to use models and levels effectively in a way that would allow the level designers to create a lot of levels and the modelers to create a lot of models without giving too much more work to the programmers. We eventually settled on a happy medium with three biomes and randomized levels.

What I Will Change

One challenge the team faced during production was sharing assets. I set up a shared Google Drive for teammates to transfer assets between each other, however, I did not make it mandatory nor did I make it very robust. Multiple times throughout the project, a modeler would need to create a UV sheet with multiple people’s models on it and would end up blocked by the required model(s) not being in a place they could access them. Had I checked more thoroughly that these assets were available on the Drive, we would not have experienced as many blocks throughout the project. In the future, I will make having assets in a usable format accessible to the necessary people part of the user story verification process. Additionally, I will set up a more robust asset-sharing pipeline so that uploading assets to Google Drive, or a similar software, and finding those assets later is simpler.

What I Will Do Again

As strategy games are usually fairly complicated, I had my designer create a simple paper prototype for the team to play before kick-off. I felt this helped everyone, especially our programmers, get a feel for what the game would look like and made explaining mechanics down the line easier.

Halfway through production, I started requiring each team member to playtest each new build. I felt that this was a great way to hold everyone accountable by seeing what gets into the build and what features and assets look like during gameplay. It helped keep the team focused on what game we were creating and kept them excited when more and more of their work entered the game each sprint. Therefore in the future, I will continue having the team playtest each sprint to help us all keep the same vision for the game.

What I Learned

I learned a lot throughout the production of Entoworks, including how to scope. I was scared to lose the upgrade mechanic in the game because I thought it would ruin the fun, however, I learned that no matter how important a feature may seem, if the scope is too wide it will never make it in. That was a hard, but important lesson that I will not take for granted on future projects. 

I learned a lot of communication skills throughout the development of this project and better ways to be more clear with my team. Listening is the most important skill that I have as a generalist in a room full of experts and I learned how and when to take decisive action versus spending the time finding better solutions. I feel very fortunate to have had the opportunity to lead this amazing team of people and want to thank my team for all the incredible work they did these last 15 weeks.

On behalf of my team, thank you for checking out Entoworks and we hope you have fun!