Good night friends,

Welcome to the final design blog and postmortem for Card Garden. As always, for an overview of the details of how we worked, my wonderful producer has written a production postmortem available here. Sprint 7 was very exciting and closed off every feature for publishing. We furnished all of our levels with polish by adding post processing, particles, animals, and audio. We also finished upgrading our UI, implemented animations, added a third level, and focused on fixing bugs and balancing in our game. As a designer at this stage, I was full time playtesting our game, identifying issues, and then relaying them to my producer so that I could fix them or they could then be delegated to whomever was needed to fix them if I could not do so. While we did not have to crunch for Card Garden, these last few weeks in the semester have been some of the most memorable and most enjoyable parts of game development. Everyone felt the pressure of the oncoming deadline and it was genuinely magical to see people working simultaneously together and in constant communication in our online asynchronous environment. 

One of the most important skills in design is to identify a target audience and to make content for that target audience. Although this post mortem is an assignment, I know that I deeply valued going through past post mortems from other teams when I was first selected as a designer. So my target audience is fellow future designers. Our more professional post mortem is our production postmortem which better reflects the presentation we gave. This will be a little bit less structured because things weren't necessarily so binary as to have worked or not worked. Most things did a little of both.

The first and most important thing that helped us as a group was our Designer-Producer dynamic. Coming into this class, I had a lot of reservations about myself as a designer and an newfound ambition to be a producer but no real practical knowledge of the separation of the roles. I didn't really know anyone in the program so when chosen as a designer and told to make a team, my choice of producer was scary. I asked about all of the viable candidates and chose the one with a background in art since my own skillset has a weakness in art. That was by far my best decision I've made the whole semester. Not only was she a phenomenal artist and the most ameliorative person I know, but we also shared a mentality for how we wanted this project to go.

Simply put, we are both people who want things to be done properly. We are both process oriented people who want the best for our team and a similar list of priorities. The team is more important than the game. The game is more important than each other. Each other is more important than ourselves. Regardless of your designer-producer dynamic, one thing is extremely important. Like any relationship, it only works if you make it work. You have to look out for each other, be willing to accept the other's flaws, and be willing to compromise. As a designer, I often felt it was my role to be as ambitious as possible. As a producer, hers was to be realistic and reel me in. I proposed more features for this project than would fit in a AAA development budget. For each of them, Alex heard me out, we walked through the total amount of work required to accomplish them, and we figured out where in our list of priorities they would go. Naturally, the vast majority of it had to be cut and I had to accept that. So I did. But I also pushed for some of those features when we found ourselves with extra development time while scheduling our sprints. We met several times a week for extended hours refining the design of the game and our plan of action. Playtest feedback, team member's schedules, and our own vision changing would all come together to help us in our iterations of the project. Regardless of what the state of our game was, Alex was my number one ally throughout the entire semester.

The second thing that was really impactful was knowing our own team's skillset. As mentioned, I didn't really know anyone from my team prior to taking this class so most of my team selections came from professor recommendations. We were given nine team members in three roles. Three 3D artists, three programmers, and 3 level designers. We chose to divide them up into individual roles within those teams and that worked out really well. One artist each for environment, buildings, and characters. One programmer each for our card system, our grid, and our AI. And one level designer for each level. This system worked out really well for us.

For the 3D artists, I chose a low poly modular pieces nature aesthetic for our game partly because I knew every member of this program had taken CAGD 230 and done each of those components in assignments. Every modeler we had was more than capable of mastery in this art style. That was the safe decision I had to make because they needed to get started on assets while I was still doing documentation. In hindsight, I would like to have explored taking a risk on a more unique art style, but I know the safe choice was probably the best choice in this particular circumstance. Despite this, we still had a lot to learn at this stage in setting up a production pipeline and setting clear scale and where to set pivots. I had a hard time making choices here early on because I felt like I didn't know as much as the artists, but the reality is that the designer needs to be fully knowledgeable about all parts of the development process. My final choice was that we were using 2 meter by 2 meter environment tiles with top left pivot corner pivots with a set of references for how detailed to make the textures and a standard set of materials to be shared amongst the artists to maintain a similar style. Was that the perfect choice? Absolutely not - our grid tool had to place them in parent objects with centered pivots for easier use and some 2x4 models had issues that had to be manually resolved. Was it the correct choice for the moment? Absolutely. Without making that choice, we would have been set behind in development and had conflicting styles that would have hurt us long term. My advice from this is that if there is a field you don't feel comfortable in, you need to work to get comfortable with it fast. Understand the steps they take to do their work, understand their technical limits and preferences, and be willing to make a choice.

For the programmers, I was a lot more comfortable in my understanding of the work and what kind of resources were required to make our game functional. I was able to help my producer significantly with this group as programming was not her strength and I even did a lot of the game's programming myself when I could. However, even in a field where I felt knowledgeable, I still came into this group with some apprehension and assumed that these people, each of whom were dedicated programmers, were far above me in programming knowledge and skill. Even though they all had taken computer science courses I hadn't, the knowledge required to program a game of this scope comes primarily from core object oriented principles and not much else. Everything we needed to know is covered in the CAGD 380 Game Scripting elective. But because I placed the programmers on a pedestal and assumed them to be several levels of knowledge above my own, I definitely let them get away with things I should not have. We started the semester with having them be responsible for creating class maps for their core features. Even if you are not a programmer and don't know how to evaluate a class map, they're a great tool to help you hold your programmers accountable and to keep them to a standard. We let them give each other criticism and it fostered some really good discussion on how to connect the various systems of our game. However, one programmer chose not to use object oriented principles for a core feature of our game. When asked why, he replied that he would rather do it the way he is comfortable with and he chose to do things the quicker and dirtier way that was not very scalable. By his own admission at the end of the semester, he submitted low quality work and got away with it. As a lead, this is where you have to make a choice. Do you hold them to a higher standard or let them work within their technical limitations? I chose the latter and it was the wrong choice. Know your team, but also know the reality of the role. My advice from this is that if there is a field that is a strength for you, own it. Your strengths are part of why you are in a leadership role to begin with. Don't lower your standards for people unless something really is out of their reach. If anything, the members of that role should be held to the highest standard because you can verify the details of their work with more confidence.

For the level designers, we had a very different set of circumstances. We were given three level designers for a game that did not require full use out of them. Because we had chosen to go with a very tools-centric workflow, which I highly recommend, they did not have a lot of work to do early on as the tools weren't made for them yet. We started them on annotated maps and paper prototyping and discussed some theory principles with them that would be applicable to our game, but they needed work to do. An external issue led to us having very few collab seats and each of their levels required entirely different assets which created a bottleneck in their work. So we put them to work on particle effects, which turned out to be skill they were surprisingly proficient with. The details of this work is covered in the production blogs over the semester, but the lesson to be learned here is to make the best use of your resources. The enemy in game development at this level is time. We all have several classes worth of work to take and student life tends to overlap with crunch culture innately. But if you have someone who isn't working on something, give them something to do. For us, it was an easy transition because the tool remained the same. The level designers were comfortable with Unity and we got some amazing work out of them. We had to redesign a lot of the visual feedback of our game to be delivered through particle effects rather than UI elements which was great because they delivered information to the player in a more endemic way. Make adjustments to the tools you have available to you. We tried briefly to do shaders but they were not in our skill set. Particle effects were. Whatever hidden talent your group has, make the most of it. 

The third thing I'd like to discuss is to understand the amount of work you are signing up for. All game development classes emphasize that being a lead is more work, not less. This is absolutely true. But it does not have to be excessive. Midway through the semester, I attended a CGC meeting where the topic of discussion was on burnout. I realized during that discussion that as students and as leads, we have a lot of freedom to determine our own scope. We chose our games and features can be cut or added accordingly to fit them. I originally wanted so many systems for our games that could interact in tons of different ways. But we did not need all of those to make it a good game. We only needed a few and to make them as good as we possibly could within the time limit. Those are the decisions that matter most as a designer. Not just what is the game. But how do we make it as fun as possible? That often comes down to implementation and iterating on the implementation will consume your days. It is extremely important to be fully aware of your scope and to communicate with your producer about how things are actually going. If a team member is struggling with a task, evaluate the necessity of the task and whether or not it is assigned to the right person. We cut a number of features that our team members were struggling with because we realized we could rapidly adjust our scope to something that better suited our skillset. A team with momentum will make a better game than a team without and scope isn't something you'll get right in the first iteration of the documentation. It's something to be managed and to be iterated on. Plan your scope around how much your team is actually able to give you and not what you want from them. That's why we do burndown charts.

Another adage we hear in our game development classes is that the team needs to see the leads doing work. I did not realize the true value of that until this class. One of our commitments to each other as leads is that we wanted to minimize crunch as much as possible for our team and avoid it completely if possible. We achieved that this semester by doing a lot of work ourselves. For many sprints, especially in the second half, I was doing just as much, if not more, programming work than some of our programmers were. Alex, in addition to her producer duties, was likewise doing a lot of art work for us that helped us keep on track. We never asked people to stay up late and generally set a deadline for our team to submit their work by 5pm one or even two days prior to the actual class deadline. Any work remaining that had to be done after that was work we had to do ourselves and the only crunch hours were done by both leads together. My normal day this semester was to work from when I woke up until I go to bed, with room for breaks for things like food, cleaning, and a full night's rest, averaging 12 to 16 hours of work. My definition of crunch changed to be days that excluded room for breaks and took away from sleep. As a lead, you do not have to commit to this crazy schedule. However, you will have to be willing to commit extra hours yourself to your project. Do what you have to do to make it work, but don't just jump into doing extra work for the sake of doing extra work. Let it come naturally and if your scope is right, it won't be a problem.

Penultimately, realize the awesomeness of the people making your game, yourself included. CAGD 495 is the highest class most of us will take. It is the culmination of all that we learned in university and proof that we are prepared to work in the industry. All of the people here have different backgrounds and a passion for making games that brought them this far. Cherish that and make the most of the human connection of it while you can. Everyone working on the team wants to make the best game they can, and while there might be bumps along the way, the real value of this class is more than the final result. The value is the  experience of working on a larger team like this, working in more stratified roles, and the connections we make along the way. The people you worked with will be level designers you'll look up to in the industry. They'll be 3D artists who will be industry experts in a few years time. They'll be programmers who've made the coolest new titles yet to come. The team members you have will amaze you and really show how much they want to be in this industry.  Likewise, you'll have done the same. You made it this far because you can do it. And you'll continue to be able to do it again long after this class is ended.

The final thing I would like to address is the doubt that I felt at the beginning of the semester in my first blog. If you need this, as I did and still do, I'm going to start by repeating what I said at the beginning. I suppose all that I can offer you is that it is okay to feel this way. It is a part of the process. And if you are fortunate enough to be blessed with an amazing group of people for your team, cherish the moment and take solace in that they have enough faith in you to work on the game of your own design. A single project and a handful of words won't make the doubt disappear. That's okay, too. 

Thank you,
Arjun Gambhir
Game Designer