Castle On Wheels - Production Postmortem
Hello everyone and welcome back to Castle On Wheel's final postmortem post! In case you're just joining us, my name is Isabella Gentile and I've had the privilege of being the producer for a 16 student team from Chico State. Castle On Wheels is an RTS style game where you protect your home by taking it with you! It has been such a pleasure working together these last 4 months and we're extremely proud of the product we put out there. With that, lets move onto to some statistics on task completion.
At the start of the project, we had a point total of 1,042 distributed over 500 tasks. I'll cover issues with our scope further down in the post but in short, we ended up trimming our original game idea by a decent amount but were careful not to cut out the fun. Our team's average velocity was 107 points/sprint. As you can see in the chart above, we had a dip in our production in sprint 5 which was to be expected since this was our first sprint being fully remote. All in all, we completed 754 points or 383 user stories which was no easy feat and I would like to congratulate the team for the amazing work they accomplished in such a short amount of time.
What went right during our production?
From the start of our project, our communication with the team was strong. After learning we were going to be working from home Jake, the lead designer and my other lead, and I knew we would have to be even more on top of passing on announcements for the game and keeping in touch with teammates and checking in for progress on their tasks. When given tasks, I tried to add descriptions for the majority of tasks and if teammates had questions about what they were working on, Jake and I were quick to answer questions and clear up any confusion on the team. We used a hands on approach for feedback, especially when it was easier to show what we wanted for something versus describing it with words. While there is always room for improvement in communication, despite the circumstances, I feel like as leads we did the best we could to check in with teammates, keep the team on track and answered questions promptly.
We were really lucky to have such a large team where everyone got along and it created a positive work environment for our game to flourish. Even through stressful times, the team handled disagreements or feedback in a professional manner and we avoided any type of conflicts on the team. Our team struck a good balance between getting work done and having fun doing it! Hopping into our discord server on Tuesdays/Thursdays was the highlight of my week because I knew I'd get to spend the next couple of hours hanging out with my amazingly talented team and get some great work done by the end of the class session. It really felt like everyone on the team put in their best effort to get our game to the state is in now and I'm grateful for the team's dedication to making our vision come true.
Major Features Implemented
All of the core features in our game design document were implemented in one way or another, which is something we are extremely proud of. At the beginning we outlined that our priorities were giving the player a multi-attack castle to protect and unique behaviors for different type of enemy and ally units, as well as a UI that complimented the game's play style. For the player castle, we were able to get two different types of attacks on it: the canon and an arrow volley. When the player activates siege mode the castle's canon turns on which allows the player castle to target enemy structures. Lastly, we got to implement four uniquely themed levels that should make the player feel like they are on an adventure. In the end, our core game play features were implemented and we were able to compliment it with some player feedback such as SFX and VFX.
What went wrong during production?
Too Large Of Scope
As I mentioned earlier, the scope of our game was massive for a single semester and for a team of our size. We originally had 6 type of enemies, 6 types of allied units, 6 siege engines, 10 levels and 3 additional game modes. We ended up cutting a majority of these features in half in order to keep the game in scope. That being said, we still got to implement a good variety of our enemy behaviors, ally behaviors, and siege engines. We were able to get 4 levels completed and in the game with 1 base game mode where the main goal is to get your castle from one end of the map to the other safely and defeat the enemy stronghold.
Fluctuation in Workload
During our process, the fluctuation in each teammate's workflow led to inconsistent completed tasks for each sprint. In a survey that we sent out to the team at the end of the project, we asked the team how their workflows felt and whether or not they were too heavy or more light in nature. A majority of our team stated that workflows felt manageable but the variation in work was hard on them. For the future, I will definitely keep in mind the point value for cards as well as the amount of cards and how these tasks/workloads span across sprints to try to equalize them. In the end, I learned that when teammates can predict how much work they are going to have, they will have an easier to allocating time for their assigned tasks and will minimize the stress of heavier workloads overall.
Complexity in AI/AI Overhaul
The systems that we wanted to have in place for Castle On Wheels were demanding for our programmers and they did a great job with the AI overall so kudos to them and their programming prowess. However, that doesn't go to say we didn't run into our fair share of bumps in the road. In the beginning, we tried to have an AI system where each unit had a "brain" and the player was able to micro-manage each individual unit. We struggled to get this system working without causing extreme lag in the game. Around sprint 3 we gathered up our programmers, sat in a circle and tried to talk through the issues we were currently having with the AI and how we could solve them. There were several changes that came out of this meeting, including an overhaul of the previous AI system. Another major change we had was splitting the work between 2 programmers, one for allies and one for enemies. Eventually we added a third programmer to take over the siege engine AI and our last programmer worked on our camera, the castle, and implementing animations closer towards the end of development. I strongly believe that that meeting was a turning point for our game and our game wouldn't be what it is today without it.
What did we learn?
In truth, I could write an entirely separate blog post on everything that I personally learned through our development process. This experience overall has been so special and we really got to grow and learn as a team. We learned that communication was one of the key factors to our success and more specifically, realized our shortcomings when it came to writing detailed tasks or making sure everybody has the references they need. We also learned to make sure that any changes to the game were getting communicated to each department that that specific task would be affecting. Next we learned the importance of the prioritization of tasks and realized, too late in some cases, that if we evaluated our priorities earlier and more often, we could have gotten more in the game. For instance, a fully functional upgrade store ended up falling through the cracks because getting our core game play loop in the game took priority. Scope is one of the most important things we learned throughout this process and even though we knew in the beginning we weren't going to be able to get everything in, it was imperative to learn just how much work can get completed in 4 months and how long each task throughout each discipline takes.
I can't thank the team enough for their effort on the game and it was really special to see everything come together in the end. I will hold this experience close to my heart for the rest of my career and will miss each of my team mates dearly. Thank you to Jeff, Dan and Sam for giving me direction and help when I needed it and also giving us the space to learn how to overcome obstacles on our own. We are all better problem solvers for it. Lastly, I would like to thank Jake, our lead designer, for having such a fun concept for the game for us work on. You made my job easier by having your idea completely fleshed out and it was a pleasure working on it with you each step of the way. From everyone on the Castle On Wheels team, we thank you for following us on this production journey and I hope you all get a chance to check out the game! Stay safe and game on.
-Castle On Wheels Team
Get Castle On Wheels
Leave a comment
Log in with itch.io to leave a comment.