Semester in Review 

Hello there, it is Sam again and I am thrilled to announce that MARRED has finished its final sprint of development has been released! It took a lot of work to get to this point. Although we did not complete every feature and polished asset I am still impressed and proud of the development team's efforts. In under 4 months, we managed to take Jen’s brainchild and turn it into a fun, cohesive experience. 

As a team, our most productive sprints were actually sprints 6 and 7. With 133 points completed in sprint 6 and 157 points in sprint 7, our average velocity jumped from 104 points per sprint to 116. I attribute this to the fact that we were getting closer to the release date of the game and I began enforcing stricter deadlines on work. Overall the team completed 811 points worth of work during the production process with only 77 points being left over in the backlog. Based on our average velocity if given one more sprint we likely would have completed everything within our backlog. 

However, the things that were cut from the final version of MARRED had “want” or “wish” level of priority so I am not disappointed in what features did not make it into the game. Some of these cuts included the soundtrack, transitional animations, and a fully fledged save system. Every necessary feature that contributed to the core elements of what makes MARRED fun made it in. 

Besides me, the team consisted of 2 programmers, 3D artists, 2 level designers, 1 2D artist, and 1 animator. The programmers and level designers did an incredible job bringing this game together. While I already had high expectations for our programmers they still surprised me in many ways with their abilities. Jake and Josh created all of the foundational systems for the game including, but not limited to: the weapons, enemies, upgrades, and animation implemented. Our two level designers, Trevor and Jacob made a total of 7 unique levels with 4 themes and showed great perseverance during the tedious work of putting in walls of the level. While also having to design the game Jen made all of the character models and provided high-quality environment set pieces. The other 3D artists, Tyler and Payton, consistently provided quality models and textures for environments and props. James, our 2D artist efficiently produced clean UI art for the game while also remaining flexible enough to try his hand at mixing audio for the game. Finally, Abi our animator did a wonderful job with creating visually appealing reload animations and cleaning up our motion capture data for the enemy animations. Overall, each member of the team performed well in their assigned roles and each positively contributed to the finished project in a significant way. 

Postmortem:

What went right? 

Over the course of the semester, the team was very versatile and adaptive. I am not perfect and definitely made mistakes on when work was assigned which led to instances of cards being blocked. In order to combat this, there were times were I temporarily shifted people’s priorities to get cards out of blocked and everyone who went through this approached it with a positive attitude and finished the work quickly. One thing that was great was the consistency with the art direction of the game. Jen was very clear in communicating her vision and what she wanted the game to look like. This helped tremendously because our artists did not need to go through many revisions to their work. The communication between the level designers and programmers was also excellent. These individuals were the only developers who actually worked in the game engine and needed to be in constant contact with merging their changes, implementing features, finding bugs, and fixing those bugs. Stricter deadlines were also very effective in making sure that work got done in a timely manner and in time for later prototypes and the final version of the game. 

  The first playable version of the game did not have a Mac build which limited the number of remote testers we could get. Every later prototype version had Mac and Windows builds which ended up doubling the number of playtesters in each sprint. We also had two special development days for recording motion capture animation and necessary sounds for the game. Motion capture practically saved the game in my opinion. I was honestly worried about the animation implementation, but since the animation was already recorded all that was left for our animator was cleanup and exporting. Without motion capture, we do not end up having unique walk cycles and melee animations for each enemy in the game. Although all of the planned audio did not make it into the game, having a day to go around and used household items for audio did save us a lot of time. With our necessary audio pieces recorded, the things that did make it into the game were already recorded making the editing and implementation easy. Lastly, almost every build night we found at least one issue that broke the game, yet each time we were able to “put out the fire” and show off something playable that still had new features. This allowed us to take the next day to only concentrate on fixing these bugs so we can have a cleaner hotfix build. 

What Went Wrong?

Unsurprisingly, the development of MARRED was not perfect. As a producer, I could have been clearer on some Jira cards and Jen could have been more clear on sections of the GDD. While nobody felt lost, some time could have definitely been saved if a few more sentences were written out. Without a dedicated sound engineer, audio was a low-priority section of the game. However, there could have been better direction of what Jen wanted each sound to be. This led to some rushed audio clips being put together late in development because there was not a well-established plan for our enemy audio. Communication between our two programmers could have also been better. Although both understood each other's code, no commenting standard was established between the two. This led to some instances where we took longer than we should have trying to find the roots of the game’s bugs. Additionally, we had some GitHub merge issues because we didn’t create a third branch to be shared between the programmers and level designers. Luckily, this was solved early so we had no instances where we lost significant chunks of work, but if not caught early this could have been disastrous. 

Some other early mishaps include our animator being blocked on day 1 and not having texture maps and complete plans before starting. While the animation plan was to always use mocap, it was a process to get a recording session set up. Additionally, an arm rig was still needed for reload animations. This left our animator blocked because I tried assigning Abi to reload animations in sprint 1. I did backtrack and have her gather references and sketch out concepts for animations and characters, but I should have had that assigned first. While Jen’s art direction was very consistent, the two of us did not know the full range of our 3D artists' texturing ability. Due to this, I needed to assign them to work on creating concept pixelated textures so that Jen could decide if the pixelated style was something that would be something used. 

Our level designers worked exceptionally fast by giving us their annotated maps and blockouts. However, these were all completed before the walls were complete with textures. While work completed earlier than expected is a good problem to have, I needed to have the level designers work on something so I believed that it was possible to increase the number of levels in the game. This did increase the scope, but the levels were able to get done. In hindsight, I should have just had the level designers begin putting in wall models before the textures were ready because they can easily be applied later. I think this would have allowed the larger levels to be completed earlier and possibly be more polished. Furthermore, the 3 “core” levels were far too large to the point where players consistently got lost in them. We did make necessary cuts to the level, but the design should have been evaluated more closely. 

Lastly, we had so many problems with stairs in the game. Players could get stuck and not move on them and it would take too long to climb them. We tried numerous potential solutions until we realized that the best way of doing it was just to replace all stairs with ramp models. 

What Would Do Differently?

There are a few things that I would have definitely done differently if I got transported back to late August and got to produce MARRED all over again. First and most importantly, I would have placed a bigger emphasis on making sure that the essential features have polish before getting my programmers to begin developing new features. Doing this could have potentially allowed our artists to catch up in some cases. Additionally, we should have waited to implement intractable objects until they were set up with art and completed scripts. This would have allowed our earlier builds to look more polished instead of the buggy doors and crates in early versions. 

I mentioned earlier that in hindsight our level designers should have been given models to put in their level earlier to save time on polishing levels. Another thing that would have also saved significant time is having our level designers use probuilder to speed up the rate at which they can place walls in the scene. Lastly, of course, is no stairs; if we really want stairs we will just use a high poly bake instead. 

What Would We Do Again? 

I believe we made a few key decisions that made the ride that was MARRED’s development a lot smoother. As I said earlier motion capture was essential for us to have the number of animations that we wanted for the game. If the option for motion capture is available in any future project I am leading it will definitely be used. 

While modular modeling is tedious it still saved us time since we did not have to create as many environment assets. Furthermore, tying each level’s walls and other large groups of objects to their own materials also helped with cutting down on assets. Our weapons were also setup in a similar way since we used scriptable objects to create them. This made it far easier to balance them since all we needed to do was change a value or two. 

Finally, I would definitely use my same plan of splitting up work into large chunks and assigning those chunks all at once. There may have been times were the work for asset packs or systems bled into another sprint, having these defined blocks of work made it far easier to track what work was completed and what is still left outstanding. Going deeper into this idea, I also had informal roles for programmers, level designers, and 3D artists. What I mean is that I had one programmer designing combat systems, one artist primarily focus on character modeling, or texturing, etc. This made communicating expectations and assigning work much easier while also contributing to the ease of tracking the tasks being done. 

What Did We Learn? 

Game development is a messy process, I had to constantly monitor 9 other people in the present while also planning for the future. Mixed with people finishing work at different times, bugs, revisions, and other development mishaps it can easily become overwhelming and hopeless. I am proud of myself for keeping my cool the entire time and never losing sight of the end goal despite how hard it could be to connect all of the dots. 

We also learned to expect the unexpected. Emergent gameplay and bugs certainly exist, but those are regular events in the design process. Developers are still human, however, and I cannot always account for health crises, power outages, and team members going awol. In my management class last semester, we had an entire unit just on planning and contingency plans. I consider myself a very organized person but making this game made me realize the importance of backup plans because things can and will go wrong.

As a producer, it makes me happy to see more points done than the previous sprint, but I should not become so blinded by the points that I ignore the issues that still persist. While a new gameplay feature would be nice, would it really be as good another feature feels clunky and unintuitive? 

Finally, I realized having strict deadlines helps a ton. Personally, I work more efficiently when I know something needs to be done by a specific date and there are real consequences. Earlier in the semester I did not want to feel like I was being mean to my team because if they felt uncomfortable morale could drop and therefore they’d be less motivated to work. This led me to be really lenient with deadlines; as long as the work I assigned was mostly there by the end of the sprint I would be ok with it. A mostly complete rocketship will crash and burn and I soon realized this. Seeing how much faster everyone worked in the last two sprints when I emphasized that assets and sections of levels needed to be done by a specific date. I have learned that if I want to continue to lead a game development teams, there will be times where I can be friendly, but there also must be times where I step up and be the boss for the sake of the end goal of making the best game that we can possibly make.