CAGD 377 Postmortem

  377 Postmortem

Sprint 7 Work Completed

Ladder and Jackhammer Models

I started the final sprint by working on some of the models we needed in the game scene. This includes the ladder and jackhammer model. These were made low-poly to fit the style of the game.

Shop Icons for Various Tools

Next, I worked on finishing off the icons that are on the shop screen. I went back and brightened up all the previous icons as they were a little dark. They were also already made to be buttons in Unity, so changing them to have the ability to display text when pressed was easy thanks to our programmer. One thing I would've changed looking back is erasing the inside of the nuke icon while still keeping the basic outline; similar to the other icons above.

Pause Menu

I also went back and updated our pause menu as it was using some outdated assets and didn't fit the theme of all other menus in the game. I used assets from the previously made menus.

Stats Menu

Feedback from previous playtests indicated that players wanted a way of keeping track of their stats, so I added a new section to the main menu where players can check the most relevant stats. Our programmer enabled its functionality.

Shop Screen Tutorial

Feedback also indicated that we needed to give players some form of tutorial to introduce the premise and teach the basics. I created a few slides that gave the player information on different aspects of the game, such as the image shown above. This tutorial section was also added to the main menu. I had to reorganize it to make room for the two new buttons, but it turned out well.

Development Successes

One of the things that went right was the core gameplay loop being engaging to most players. Our game was built with the idea of being a rogue-lite as part of the forefront. The game can't be completed unless you interact with rogue-lite elements. This meant we had a very strong foundation to build off of. Most players seemed to find the gameplay loop addicting. One of the biggest compliments we got wasn't verbal, instead it was the player quietly continuing to play the game in front of us. In fact, some players even returned to the game after first playing it.

Another thing that went well during development was the addition of a modeler to our team. This was completely by chance, but having a modeler allowed us to polish the art for our game. This made it far more presentable than just having a basic tech prototype look. In terms of team management, this added a bit more work for me, but was well worth it. They made a very good addition to our team.

Another thing that went well during development was getting bugs fixed quickly. Our programmer was very proactive with bug fixing and fixed mistakes the same day they were noticed. This made it easy to publish builds that worked well and were polished. This meant feedback would be more oriented towards core parts of the game or new features that would add to it.

Development Failures

One of the things that went wrong during development was not properly updating our design doc. Members were using outdated information due to core sections of the doc not being up to date. We'd often discuss changes in class and not note them down for reference later. This means of communication leaves us vulnerable to implementing outdated features. Thankfully, we communicated often enough to not run into too many instances like that, but for the future it would be best to keep things up to date.

Another thing that went wrong was communication. For the most part, communication went well and we were able to get a cohesive idea of what we were doing. As a producer, I should've taken more initiative to check in at least once every day to see how progress is coming along. I was on top of the Trello board and verified cards relatively quickly, but communicating where progress was would've given me a better idea of where we were at and would've encouraged members to get their work done earlier. Along that line, I also could've given members a rough schedule of when certain items should be done by, but that may also be overstepping my position.

Lessons Learned

One of the lessons I learned is to, and I know this sentiment has been echoed a million times, playtest early and often. This let us refine our game into something catered towards players. Play tester feedback made our game into what it is today. We've adjusted speed, menu screens, enemies, and blocks all based off player feedback.

Another thing I learned is that organization is incredibly important for efficiency. Sometimes I'd have to help navigate a team member to a certain file I just uploaded because it was buried in some random set of files. Having a clear organizational structure would remedy this confusion.