Hello everyone and welcome to the post-mortem for Citadel. 

  Citadel was a very important project for me. First, it was my first attempt at designing a rogue-lite game. Prior to this all my games had been designed to play out in very specific ways with a very linear game design philosophy to give the player a specific experience. Second this was my first time leading the design process with a team of more than 4 people. Our team of 11 meant that I had a very different job from the smaller teams I was used to. I had to spend a lot less time hands on with the project. While normally in the past I would be a secondary programmer or a primary level designer while also leading the game design there wasn't enough room for me to be fully involved with these aspects of the game. Instead, I had to dedicate much more time to ensuring quality, discussing with my team, and using the little bit of time I had on the project to do work alongside my team for things that would get into the game.

  I learned a lot on this project and think that it has only resulted in me being a better designer and team leader. Let's get into it.

2D Art

  This was my first project being able to work with a dedicated 2D artist. Prior to this I had understood there to be a very specific pipeline for work that you wanted to take from start to finish with things like concept art and UI artwork. You had to start with references, then you moved into concepts, then into rough draft, and then a final draft. From the final draft you could either implement it into the game (if it was meant to stay 2D art) or from there was moved onto 3D art for the modelers to work with. We tried to use this pipeline for our modelers early and it was extremely unnecessary.

  This is not to say that this pipeline is a bad thing for development, but for our team it was extremely unnecessary. With our extremely tight deadline work period of a mere 13 weeks from start to finish and a very strong modeling team it was entirely unnecessary for us to have a final line-art colored version of our character concepts.

  If my producer and I had just recognized that our 3D artists did not need finalized, clean line work and could go off of nothing but concept work then we would have been able to move out of character artwork several weeks sooner. This extra unnecessary work meant that we weren't able to have every aspect of our UI finalized. We wound up missing out on a good UI indicator for the health and mana bars that would have made the game look much better. 

3D modelers

  The 3D modeling team that I had put together was a very good choice by me. I think that my modelers did an excellent job working together. Originally in my design I had imagined a much more cartoony style with much brighter colors. This wound up not playing well into the strengths of what my artists were able to create. Instead of trying to force the game to look the way that I had imagined it initially, I decided to make a pivot into playing into the strengths of my art team. Given the short amount of time that we had to work on the project I think that this was 100% the correct call. If our game had a longer development time, a wider team, or an already established game that we were developing DLC for then I don't think I would have made this decision. I believe that when you have such a wide variety you need to keep that consistent art style so that you don't throw off the players when they see models that from numerous modelers that feel like they have very different styles to them. 

  Making the decision to have one modeler do all of our character modeling and the other modeler doing the majority of our games decorations helped to make the game look more uniform as well in my opinion. It was always going to look more uniform having our modelers specialize in one section as opposed to having each modeler do half and half. I believe that it would have simply made our game look a bit more disjointed as one of our modelers has a very specific style for their models that would not 

  I think that I would make the decision to play into this strength again. It changed the tone of the game drastically but this tonal shift was okay as we had not moved onto animation or to audio.

  The one thing I would change if I had to go back and do this again is making sure that our walls were the first thing textured. I allowed decorations to be done before critical set pieces and this 

Animation

  Our animation was mostly a smooth process. I learned a surprising amount animation on this project as I have had only small amounts of practice with it in the past. The biggest hiccup we had to overcome came at the start of the project. During the transition between the creation of the rig and its implementation into Maya the names of bones got switched on the rig.  We aren't quite sure what exactly caused this to happen and we also weren't aware of it when it did happen. We didn't realize this problem had occurred until trying to bring the animation into our Unity project itself.  

  When trying to bring in our first animation we had uncovered an issue where the engine was telling us that the bones were not able to match up between the animation and the rig we were using a base. This took us about 2 weeks to figure out. Once we were able to figure it out we were good for all of our humanoid IKs but we ran into the same issue with Squiggmar and the Seraph.

  Because of the non-humanoid nature of these models we actually had to come up with a work around. We couldn't base them off a humanoid IK and the generic IK wasn't enough to make it work. Instead we had to actually have the animation itself come in with its own model and swap out the models as the animation was needed. This wound up working great for us, but I learned how much of a pain it can be to animate non-humanoids. I will likely avoid non-humanoid creatures for my upcoming small projects as a result as I do not feel strong enough as a developer to try to figure out these tools properly.

Level Design

  From a level design perspective I think that I made some critical mistakes in my initial planning for the process. I had envisioned that we would need so many levels that creating annotated maps for all of them would be too much of a waste of time. On top of that our rooms were denoted with a possible 12 openings to allow the player to navigate the castle through different parts of the grid. As an example, a room with 2 entrances, one in the top left corner and one in the bottom right corner would be named E2LT-RB to show off the number of entrances and where the entrances were at a quick look. I had wanted us to have multiple variants of each of these rooms so that if a player had a room with a middle left entrance and a middle right entrance it wouldn't always be the exact same layout and would allow for more variety. This caused me to have our producer set up workflow in a way that did not work on a fundamental level for roguelike level design early on. I will go over this specific issue later in the programming section.

  Moving on further from here we had an issue about 3 sprints in around week 5. Our level designers had been working through the levels and placing white cube prefabs in the levels to show exactly where walls would go. These would be replaced later when we had access to our wall model and textures. Unfortunately, I had relied too much on my game design document talking about the way I wanted the levels to be set up that I stopped checking the hierarchy in unity after it had been done correct for the first 2 weeks of work. 

  I had created prefabs for the players to use that would work for just about any scenario that the designer could have wanted, whether this was a single block that would take up a 1x1 square, or a 24x1 block made up of 24 squares that would go from one edge of the room to the other. These prefabs should have been enough for the designers to use whatever they needed, but we wound up having scaling used that I did not catch. While this looked fine with the plain white cube, it was immediately clear that these levels had to be redone entirely as the problems could not be easily solved. This wound up causing a lot of headache for me and my level designers as we had to spend a full weekend doing nothing but fixing the finished work. This could have preventable if I had gone through and checked each individual block before pushing in each piece of work.

  Additionally, we learned later on how hard it was to test specific rooms in a randomly generated room set. We solved this by creating a unique Unity scene that was set up with our A* pathfinding system, our UI prefab, and a player model. This helped the later levels be more easily tested when it came time for final polish as we could get in there and test all of the jumps, hallways, drops, enemy placements, etc. and make the fine tuning needed.

Programming

  I definitely don't know enough about programming to feel like I could have specifically give my programmers better suggestions on how to handle the more difficult things like AI scripting. However there were a few things that I think could have been handled better from a design standpoint that I did have some control over.

  Circling back to the aforementioned level design issue, one of our programmers had a functioning random map generator working very early on in our production process. We weren't able to properly use it fully as we did not have the room variety needed. When designing work I had imagined that us having multiple varieties of the same room entrance would create a better player experience. However, I should have ensured that we had a very specific set of rooms first (specifically all possibilities for 2 entrance rooms) before trying to create second, third, and fourth variants of one room. By having our game have one of each room type early on we would have been able to test the system in its entirety much earlier on and have a better experience overall with it. We would have been able to have the system work like an entire 7x7 grid with each spot being filled and making the castle have more variety and excitement.

  The irony of "having less variety early will give us more variety later" is not lost on me.

  When it came to our player controller it seemed like it was off to a good start. Our little test room was working well with it, the player was able to get through the platforms, and it all kind of meshed together.

  Then it got into the castle.

  It was very clear that there was some issues with our player controller. The camera was super jittery, the player was able to walk through walls, jumping was extremely inconsistent. We tested a wide variety of solutions but it felt pretty clear that the controller just needed to be revamped. Coming into the last weeks of production I informed our executive producers that we were rebuilding the player controller from the ground up. They were justifiably skeptical.

  But it worked out great. 

  Not only were platforms more responsive, the jump was more controlled and was consistently hitting the peak height I wanted it to be at. 

  Our enemies never quite got to where I wanted them to be as I learned fairly late into production that the A* pathfinding system did not allow the enemies to handle jumping up blocks to work the way I was hoping it would. The goal was to have enemies be able to see small ledges and make controlled jumps based on those jumps. From here, enemies like goblins were going to be able to figure out the path they needed to take to chase the player up several levels by jumping from one ledge to another. This was not achievable by us in our time so I had to have the enemies jump ludicrously high or they would get permanently stuck in small pits and not be able to navigate the map at all.

  Squiggmar also looks a little strange visually during the encounter with him.  Currently the tentacles point horizontally along the x axis that they move towards. I had wanted the tentacles to swipe across the room while they were pointed towards the camera along the z axis. We ran out of time unfortunately to make the tweaks to Squiggmar and make proper adjustments to damage done or visual appearance. 

Non-Job Specific

  During the process I realized that the clicker elements to the games progression system was just not working properly. I definitely would not include it if I were to try and make this game as a rogue-lite again. While the clicker was (arguably) the more successful part of the game in the end and received the most positive feedback, I believe that both the clicker elements of the mines and the rogue-lite elements of the castle would have been more successful if they had been their own game entirely. Trying to merge them together created a fairly imbalanced gameplay state as well as its own slew of complications with github merges erasing data.

  While this is more on the production side, I think this was the most important lesson I learned. I gained a better understanding of what I can handle as an individual. In previous projects and games the small team meant that in the event of a necessary build for playtesting I was able to work on it mostly solo with perhaps one other person with me to get it ready. The smaller team also meant I spent more time working with the code so I was more familiar with how certain properties were working. 

  That was not the case with this project.

  I learned very early on that it was not sustainable for me to try to tackle builds for this game the same way that I had for 2 years. I did 6 consecutive 60 hour weeks on this class project alone trying to be the "one man army" I had been cultivated to be from previous experiences. After talking with my team about how unsustainable that was we agreed to meet up over the weekend when builds were going to be brought together. This wound up not only producing a better build, but also resulted in me having significantly less on my plate and being able to work on things that were important for other projects, have time to relax, and take on more work that actually needed to be done for this specific project.

Biggest Project Takeaways

1) Trust your team to be able to help you with important deadlines. You cannot do it all yourself.

2) Pre-production is critically important for getting a proper player controller ready before any level design is started.

3) Use that same pre-production period to figure out the minimum viable amount of levels/models/weapons you need to properly test functionality of your game as early as possible.

4) Recognize the size of your team and amount of development time available when it comes to determining what goals are feasible and what goals are not.

This project was a major eye opener for me. It may not have accomplished all the goals I had set out for, but given the amount of time and resources available I am proud of the project overall.  I think my team did the best they could given the hybrid learning style, the short amount amount of time, and the overall lack of familiarity with brand new systems and jobs they had not been accustomed to.