Dev Blog Postmortem - Shapeshift Dungeon

Hello hello, and welcome to the Shapeshift Dungeon design postmortem! It's both incredibly exciting and sad to see the development of this project finally come to a close. So much time and hard work has been put into this project in such a short amount of time, I'm kind of at a loss of what to do with myself now that it's over!  In this postmortem blog, I will break down the top 3 greatest design successes and failures of the game, and see what I could have been done better to enhance the game using the same resources in a semester and the power of hindsight.

What went right?

#1: Pre-Production

During the pre-production stage of the game's development (even before I pitched the game) I knew that I wanted to meet several criteria to optimize the chances of success. I knew from the outset that I wanted to become the designer on a project, and that I would be working with a team of about a dozen students over a single semester. With that in mind, I set about brainstorming various ideas with some key goals in mind: to create a roguelike (my personal favorite genre), to make it small enough in scope that it could reasonably be produced within 4 months, and to have a unique hooking mechanic that made this roguelike different from anything else you can play. From this set of constraints, I landed on the idea of a 'one room roguelike', where the entire game takes place within a single room that changes over time. From there,  I came up with the idea of the shapeshifting tiles to achieve this changing over time effect, and created a demo scene to test it. And thus, Shapeshift Dungeon was born. 

By considering all of my constraints during the design process, I could be fairly certain that the core gameplay was within scope  and could be achieved within a single semester. Having a simple and achievable core game loop was critical in the game's success, both from a production and player engagement standpoint. From this core design, I created a 30+ page game design document complete with reference images and an easy to navigate table of contents for the team to reference when needed during production. This GDD helped answer a lot of questions before they needed to be asked, and saved both me and my producer Arjun a lot of time later on.

#2: Player Feedback

Throughout production of the game I have done everything I reasonably can to collect and respond to player feedback in order to find problems and oversights with the game's design and improve upon them. We had at least 4 methods of collecting this feedback, which I will break down individually and how it affected the game's production.

      Google Forms: Each new build of the game came equipped with a new Google Feedback Form that was linked to from the game whenever you died or paused, so that players could easily access the web page and provide written feedback to our questions. The long-form questions were almost always more useful than the checkbox or slider value questions. In particular, I think these questions were some of the most useful that we asked:

These open-ended questions allowed the play-testers to provide us with clear information on what they felt were the best and worst systems in the game, and the adjustments that they wanted to see. Also asking "Any other feedback you would like to provide?" at the end of the form was extremely helpful in allowing testers to provide more detailed feedback with the stuff they wanted to talk about but didn't find room for elsewhere in the form.

      Level Reviews: From the very first build I wanted players to be able to  provide immediate feedback on the level they just played so that our level designers could make more fine-tuned adjustments. After some searching, I came across this Unity Answers post about sending emails in-game: https://answers.unity.com/questions/433283/how-to-send-email-with-c.html?_ga=2.5.... Implementing this with a bit of UI allowed play-testers to quickly send us emails, providing a Player ID, level rating, some written feedback, and some other info about the current state of their run.

This system was a bit cumbersome, as we then needed to sort through typically over 100 emails each build to compile and analyze the feedback, but the time investment to do so was very much worth it. With this process we got some highly specific and informative feedback to make changes on, that not only improved the current levels but also gave the level designers a better blueprint for making new levels.

      Unity Analytics: This was implemented in our third build and was set up to send a variety of playtest data anonymously over to Unity's servers, where it would take a day to process and update and them we could display this data in graphs to see how players were actually playing the game. This turned out to be our least useful method of collecting feedback, as Analytics is not a very fine precision tool and is just really clunky and difficult to use. Even trying to use the built-in level completion filter to see where most players were dying/quitting didn't work out, as there was a minor error in the code early on that introduced some garbage data and there was no way to remove that garbage data once it was there. There IS however at least one metric that Analytics has been extremely helpful in tracking - Stat Potion Upgrades. It's important that players take the 3 stat upgrades relatively equally, and not just take the same upgrade each and every time. Analytics provided the easiest method of tracking each time a player took one of these upgrades, and showing if they were relatively balanced or not. Initially, speed was the worst upgrade option and was taken less than 15% of the time, but after some adjustments it is now much better. The health upgrade is now taken the least, but it's actually quite powerful if you take it a lot, so I think it's good right where it is.

      Watching Players in Real-time: Due to COVID-19, production was entirely remote and being able to actually watch someone play through the game and provide real-time feedback was a rarity. However, this was ALWAYS the best form of feedback when it could be done, and definitely helped shape the game as much or more than any other form of feedback. A good example is seeing the streamer Vimlark play the game during the final sprint of the game, and seeing all the little frustrations he encountered. The enemies were too hard to find, the charge attack could go over the heads of enemies and miss them, and some items were just not intuitive or fun to use.

After Vimlark's playtest, a minimap was added to the top right of the screen (I had been contemplating this for a while but his playtest cemented its necessity), the charge attack was adjusted to be able to move down stairs, and the items were given more visual and auditory cues to make them punchier and feel better overall. Being able to watch back the recording of the video also helped determine the source of some bugs he encountered as well, such as the Skeleton enemy's hitbox getting stuck on when attacked at a specific point in its animation. 

Getting all of these different forms of feedback, compiling them into an actionable list, and then addressing them individually was extraordinarily helpful and something I would highly recommend to any game dev team.

#3: The Team

Just as important as the game's design and adjusting to the feedback we received, was the ability to actually produce the damn thing in the first place. Shapeshift Dungeon as it stands, would really not be the same game without the hard work and passion of every single person who worked on it. I can name any individual person on the team and tell you the many features or assets that would not be in the game if it hadn't been for that person's work. I really don't need to say more than that, I'm thankful to have had such a consistently awesome team to work with!

What went wrong?

#1: Scope

Even though I had designed the game from the outset to be within the scope of a single semester, I simultaneously over-scoped a lot of things such as the quantity of monsters, items, and maps in the game. I put a lot of extra pressure both on the team and on myself in trying to do way too much. The original GDD had 10 unique monsters, about 30 different items, and a minimum of 30 maps planned out. While 2 of these enemies were cut almost right away, it wasn't until after our fourth build that we cut another monster (actually 2, but we brought the worm back thanks to our modeler Chance who helped with animation), 10 items, and focused on map adjustments & decorations rather than creating more new maps. 

Even after all of these cuts, there was still a lot of time spent crunching away at the game each weekend to catch up to where we needed to be to get everything in the game. I don't necessarily regret the crunch hours that I put in, but I do think that it was unfair for me to expect that level of time-commitment from my team and I would definitely make adjustments if I were to do it again.

#2: Lack of Artistic Background & Direction

Throughout production I have had to act not only as a designer and a programmer, but also as an art director. 2D and 3D art tasks needed to be created based on my design, and then later verified by me. I consistently had a difficult time with this role, as I do not have the artistic background necessary to accurately describe my vision to others, or to provide the best feedback to modify and improve an art piece that does not meet my vision or standards. It was a constant learning process for me to provide constructive criticism when needed, and when to say that a particular art piece is good enough and should be put into the game. One important thing that I learned in this aspect was to ALWAYS test things out in the game before approving or denying them. As an example, a barrel model that was made and moved 'To Verify' seemed to have a good wood texture but was lacking in detail (and I said as much). However, after putting it into the game I realized that with the game's lighting and camera angle, any fine details were lost anyway and did not matter, and the texture that looked good up close became a blurry mess once it was far away. Similarly, I thought that the texture for the un-shattered barrel and the shattered barrel looked too different and needed to be adjusted to look more alike, but after testing it I found that the texture swap was pretty much seamless as is.

My original feedback was backwards from the changes the barrel actually needed, and a quick test revealed that fact quite easily. I still feel like I have much to improve on in this area, but I am much more confident about it now than I was at the start of the semester!

#3: Last minute calls - breaking from the board

A personal failure of mine that led to confusion and anxiety was my decision to make last minute changes before a build was due, and not updating the Trello board or otherwise notifying team members who would be affected by the change. For instance, the addition of the robed mage boss in the final sprint was poorly planned, if at all, and the design of how the boss acts was modified a number of times without ever updating the tasks on the board involved with it. This meant that when it came time for Alexis to create animations, she was presented with tasks for an idle, an attack, a teleport, and a death animation. Up until the last minute, I wasn't sure if we even needed a death animation or what that animation might look like, so it was eventually just cut. But I had also created a second attack for the mage, so a task needed to be added for that. There are numerous other cases in which this sort of thing happened, and it was my failure to follow the plan and communicate changes as they came up that resulted in confusion for others on the team.

What would I do differently?

With the knowledge that I have now, if I were to do this over again (or just for any future projects!), I would first and foremost make sure that my role as a designer is fulfilled before moving on to programming tasks, and be a bit quicker to verify/deny tasks on the board. There were a number of times that my team was relying on me to test out their assets and provide feedback before moving on, and I didn't give them the priority they needed. Tasks in 'To Verify' should be dealt with as soon as possible to keep everything flowing smoothly and not leave team members in limbo, or working on new tasks only to have to go back to the old one again.

I would also make sure to set better defined and very reasonable goals for build due dates, and make sure to update the Trello board as I'm working. This would prevent a lot of the last minute changes/adjustments that happened near the release of each build. This is also just a nicer way to work, since I wouldn't have to try and keep track of every individual thing I did and then update the Trello board all at once with a bunch of tasks later.

Finally, I would attempt to spread out my crunch time rather than just working extra hard in the last few days beforehand. Working like this was fine for the most part, but meant that I would discover problems when it was already too late to do much about them. By working at a more even pace and starting earlier, I could have discovered these problems and brought them up to team members well before the build was due.

All in all, Shapeshift Dungeon is fun to play and cool to look at, and I would consider its design and production process to be a success. I am really ecstatic to have been a part of this process. It was an awesome learning experience and incredible portfolio piece for everyone involved, so much so that I worry I won't get to work on anything this cool in a long time! Regardless of what the future holds, I'll always look back on this project fondly and enjoy showing it off to others when I can. 

Thanks for sticking with us till the end!

- Sky, Shapeshift Dungeon Designer & Programmer