ZIEF Postmortem

This was a hard production cycle. Designing for this game and being a part of leading this team has taught me many hard lessons and put me through a lot of growth as a designer. There were many cuts that had to be made, systems that had to be designed quickly, questions that had to be answered that I hadn’t even considered before, and an understanding of what is communicated and what isn’t communicated as you talk to people. The world of game development is a crazy but also satisfying place to be. Sometimes it’s a chaotic whirlwind of things needing to be made and others it’s a euphoric and triumphant feeling of accomplishment when pieces align just right. I learned a whole lot from this experience in a lot of different areas of development and design so I’ll split it up into what I thought were the biggest, most important things I learned.

Pre-Production Design VS Production Design

Coming up to this project I’ve worked on a few other projects where I was in charge of designing mechanics, systems, combat, various player interactions etc. In all of those projects, there wasn’t a designated deadline for things to be done. Need a puzzle mechanic? Sure, give me a week and I’m sure I can conjure up something with a great feeling. Overarching system for a tabletop RPG but with no dice? Sure, a month or two of bouncing ideas off of people and testing and it came together. Need it in a weekend? Or a day? Now that’s where the struggle comes in. 

Suddenly all this creative freedom and time to ruminate on mechanics interactions and implications has to be highly condensed and prioritized for what will most likely work the best generally. This results in mechanics that are generic, that could fit into a lot of games, and that have been shown to be generally good. I don’t like designing systems like this. It bugs me in the back of my brain like a puzzle piece that isn’t supposed to fit but does, and you know it’s wrong but it works. I don’t think this is true of all designers though. I imagine that designers with more experience than me are able to contemplate many of these factors in a faster time than I do and can make well crafted and intuitive designs under stricter time constraints. I think general experience in design plays a big factor in being able to make these snap decisions that actually end up turning out well for the game as a whole as when you’ve interacted with more systems, more games with successful mechanics, you get a better sense for things that will work in the long run and the short run. I myself am not there yet. I still need time for my designs to feel like they’re really working for me, to figure out the base and what additional layers I’m able to add on top to make a wonderfully complex and fun game to play.

One thing that I noticed as I’m looking back on the project is what I’m going to call “design drift”. This was that, as the production got going and we got deeper and deeper into it, my vision, my design for the game slowly shifted and altered around the challenges the game was facing production-wise. I don’t think this is uncommon, and I don’t think that it is entirely bad either. Game development needs to be flexible at its core because so many things often have to be cut, rehashed, can’t be done, won’t get done in time, the problems go on and on. However, what I had an issue with was that my vision for the experience that the game would give to players drifted. This kind of drift I think is bad, as it leads to the game having a Frankenstein of feelings, or aesthetics as it’s professionally termed. These aesthetics often will clash with each other if they are not purposefully created to be together and it makes the game’s impact that much less for the players as they’re being mentally pulled in different directions by the design itself. I noticed this when it came to stealth versus the action in the game. What I originally had in my head was a much more stealth oriented game that had good gunplay to fall back on. Once we had the gunplay made and the stealth wasn’t completed yet, my playtesting of the game led me to work more towards the action that was in front of me. If I had committed to either the sneaking, stealthy aspects of the game or committed to the actiony, shoot-lots-O-zombies aspects of the game, I think the end product would’ve been a lot more compelling and fun to play. Rather, the more half and half the game ended up with, where the stealth has no supporting mechanics but is a prevalent theme and the action has some moments but isn’t given enough juice to prop up the experience, leaves me wishing that I had either a fleshed out phased detection system or a minigun on a helicopter for hordes of zombies.

One way I know all this rushed design could’ve been alleviated is with more time in pre-production. In that phase there’s a lot less people waiting on my decisions and my deadlines can be much more relaxed, more in line with what I feel I can accomplish. Additionally, it allows me to think more clearly on the mechanics I have and what other mechanics I could use to flesh out a game's systems in a way that’s rewarding and fun to play. As well, I think this also would’ve made my producer’s job a lot easier as he would be able to have a more complete vision of the game and more to pull from when he’s making cards for our team members. Of course, this being a school project, not knowing if I was going to get my game picked to be made, and not having an experience like this before, I don’t think I would’ve been able to do much better than I did when it comes to pre-production as it just had to get done, even if my vision didn’t quite fill out 7 sprints for everybody.

Lead Designer not Lead Producer

Something I think I struggled with throughout this project that I can only now look back on and diagnose was that my thinking was too involved with the pipeline and the production process. I naturally like being efficient. I don’t like setting goals for other people if I’m not sure they can reach them or providing a vision for something that way out-scopes what people can handle. While I think these considerations are good to have and helps keep a producer and designer talking well with each other, I went too far and decided to not go forward with design decisions before my producer even had a chance to see how it could fit into the pipeline. I stepped on his toes by saying “No I don’t think we have time for this” or “No I don’t want to spend too much time with that, better to focus on something else” when I should’ve let him do his job and look at the work to be allocated and see if we can. I should’ve kept to making my designs solid and fleshing out systems and not dismissing them before we even had a conversation about it. Even if they would end up being out of scope, not technically achievable, any number of production specific problems, my producer is experienced and talented at his job. He would’ve known those things just looking at the schedule and that would’ve sparked a conversation for us to have about it. Then I could look for other mechanics to fill that hole or ways the game’s design could pivot to work with what we’re able to do.

Team Communication

This project has also taught me a lot on what it means to be a good communicator with people. I always thought that this was mostly about being able to articulate thoughts in a way that people can understand. And yes, this is definitely part of it, but really only half of it I’d say. The other half is just talking to people in the first place. This is talking to the modelers to see if they understand the theme they’re going for, the texture resolution, and the scale of the objects they’re making. This is talking to the programmers to make sure that they’re working on separate scripts and that those scripts can effectively talk to each other. This is also talking to the level designers to tell them things you learned during the playtests and things they need to incorporate into the next iterations of their levels so that design goals are met. I always thought of communication in terms of me answering questions for other people or explaining things I had designed, but not in terms of keeping up with where people are at or checking in midway through a task to make sure they’re on the same page. Looking at this project in hindsight has taught me that communication has both active and reactive aspects and that sometimes being a good communicator is just asking how someone is doing with their task.

As another note to this, I also learned what being a good communicator means when you’re co-leading a team. Specifically with the modular set that we had built, the modeler would come to me to ask about things I wanted in the modular set, I’d give him my answer, and then forget to also tell my producer the things mentioned. Then my producer would feel confused when he’s being asked to make cards for all these other pieces that weren’t on his radar before and have to quickly write them in. Or I would tell the level designer he should have so many variations on a building and forget to also tell my producer. It was simply something I wasn’t used to having someone that I needed to be in lockstep with for the course of the production who basically needed to know everything I knew down to the smallest detail. Having been through the repercussions of not telling my producer absolutely everything I’m telling other people to do, I know the importance of taking the time to have those quick talks so that we’re on the same page.

In Conclusion

This experience has been a huge learning curve and a huge learning experience for me both in my design and in production. Working with a 13 person team on a project makes you understand first hand why every team post mortem on anything includes “Communication” somewhere and how things can so easily slip through the cracks if you’re not completely on top of things. I was able to experience exactly what kinds of pressure are on a designer when decisions have to be made in the middle of production vs in pre-production, and I was able to more completely understand what the role of a designer is vs a producer and why each role needs to keep to their strengths for the project to flourish. I’m incredibly grateful to have had this experience making a game from scratch with so many wonderful people, and I hope this bit of insight was helpful to anyone reading this in the future.