Designer Postmortem - The Warfront From Intercepts

Hello Everyone,

Welcome to the postmortem and the final design blog post for The Warfront from Intercepts. We got a lot done in preparation for the launch and the full game can be downloaded now. This includes (but not limited to), adding the final art assets to the game, having battle simulations play out, squashing some final bugs, and tweaking the difficulty. As always, if you want to know more about the production side of things, check out Natalie Hoffmann’s Producer Postmortem Blog. 

During this last sprint, we needed all hands on deck to get in the previous minor features we wanted and polish wherever possible. This meant I was helping out wherever we could like programming, making VFX, making the trailer, etc. I didn’t get to playtest much because all of it took too much time and we believed that the bugs and missing features took priority, but we were able to tune the balance of the game based on the last sprint’s playtest. Overall, this last sprint was a bit more chaotic than the last sprint, but I still feel like I got a lot done and a build we are proud to launch.

What went right?

As for the project as a whole, let's talk about what went well. I felt like the amount of things that got in the game was great. All the artists were amazing and made really great stuff for us. This includes the vehicles, the props, and the stages. All of it was cool to look at when it got done. Furthermore, all the features the programmers were able to get were amazing. During development, we quickly realized how many dependencies our game had between all the features, so getting all of that we got in was great from the core loop, invisible ink/encryption, battle simulation, and more. I felt the playtest went well too. There was always a lot of excitement for future features based on the playtests and we always came away with a lot of good feedback on how to improve our game and usually helped us see what we should focus on for the upcoming sprints. Finally, I felt I accomplished my goal of making a fun strategy game with a focus on information being obscured in interesting ways. A lot of friends and playtesters liked playing the game and trying to get as much information as they could before time ran out. Overall, I feel like there was a lot of success for the project.

What went wrong?

As my own worst critic, let's talk about what went wrong during development. I think there were 3 main problems that shot me in my own foot: scope, preparation, and verification. All of these, plus a few miscellaneous problems, caused a bit of chaos during development that led to a lot of bugs and rushed features.

When it came to scope, we thought we were going in under scope and started to scope up. However, due to that, we quickly found ourselves in the opposite problem with being over-scoped. Furthermore, we also didn’t realize all the dependencies for the game. All of this added up to the point where we had way too much work, especially for the programmers. This led to a lot of cuts to features I wanted like more dynamic difficulty and different infantry types. However,  playtesting and communication with the producer and team did help a lot when it came to what needed to be axed and what needed to be focused on. I feel like figuring out the scope of features is still something I need to work on, but that’s something that comes with experience.

When it came to preparation, It felt like we needed to do a lot more of it at the start, especially for our programmers. In the beginning, we had a general idea of what we needed to get started on and how those features should work. Furthermore, I thought the game design doc (GDD) I made helped explain a lot. However, we had a lot of problems with bugs and features needing to be redone due to the scripts not working well together. Also, while the GDD did help explain what the feature should do, there wasn’t a lot on how the developers should go about making the feature. We should have spent a lot more talking and making diagrams for these systems and requirements so that we didn’t face these problems. To alleviate this problem, I spent a lot of time talking to teammates and updating the GDD with what they needed explained

Finally, I needed to do a better job of verifying the work that was sent to the producer and me. Often during development, we find ourselves in this dilemma: do we verify the work quickly to add it to the prototype to test it now, or do we just wait for the next build to test with the next feature? I ended up pushing for the former a lot since otherwise I would be playtesting a build too similar to the last build that I would just get the same results. This led to us rushing to get features into the prototype that we just verified with only basic testing. As you can imagine, this left a lot of bugs and some features being janky. While I did get better at properly verifying work, we also spent a good amount of time fixing bugs because of it.

There were some other smaller problems that I felt got in the way of development. My background is primarily programming, but art has always been a weak spot for me, so I struggled a lot when it came to answering the artists’ questions. Also, I felt I shot myself in the foot with the genre of paperwork simulator/strategy that really limited who my target audience was for my playtest. Some aspects of my GDD weren’t helpful due to my lack of experience (especially in art), but that’s why the GDD is a living document. Finally, while this isn’t really about the project, being a lead designer for this class and being a producer for another class was not the smartest idea. I ended up being stretched thin at times. Overall, I felt I made a lot of mistakes during the development of this project, but these are mistakes that I learned a lot from.

What did I learn and what would I change for the future?

So what have I learned from this project and what would I change for the future? I wonder if the professors are sick of hearing this answer, but COMMUNICATION is probably the most important skill to have and improve. Going into this project, I had never led a group this size for anything, so my communication skills were lacking. However, as time went on, I found myself more confident in leading and talking to my team. From checking in with everyone to always being available on Discord, I was able to more effectively answer the question and help with any problem that arose. We communicated a lot on how to fix the bugs. I talked a lot with the artist about what they needed to know for their tasks. If I could do this project again, I would take the whole first sprint to just plan and talk about how we should go about everything. However, that isn’t all that I have learned. I can’t understate how important communication is.

Another thing that I learned was how to better balance trust and control with my devs. A lot of time, I wanted to just trust my devs with tasks without getting in the way since they would be the ones making it and would likely be more knowledgeable about what they were making. For example, I was hesitant to make suggestions to the artists since they were the ones with the art experience. Another example would be when a dev would go about a feature in a way I didn’t expect. However, this added to the problem of me not preparing as much as I should have and verifying things prematurely which led to a lot of bugs. So over the project, I slowly learned when to trust my dev to do a task and when to step in and try to communicate with the dev for a different approach. The biggest one is for features that others need to build off of. One example would be the stages for the battle simulations. I knew I could trust my devs to make each stage and making them look good, but I did need to make a document to make sure they were all on the same page when it came to size and what they should consider when laying things out. In the future, part of the preparation will be dedicated to making sure all of the features will work nicely together to set up requirements. Besides that, the devs should be trusted to get it done. Obviously, plans might change, but that is what communication is for. Overall, I learned when and where to trust my devs with a task and when to make sure everyone was on the same page.

Overall, This was an amazing experience that I learned a lot from. There were a lot of mistakes, but I had to learn to avoid them one way or another. I also learned a lot that I can take with me for future projects now that I’m graduating. I hope everyone who plays our game has fun. I’m very thankful for the team I got to work with who killed it. Finally, I’m thankful for my peers and professors who have taught me a lot.

Until Next Time,
Justin Lam
Game Designer