Postmortem
Blood Tax was my first major experience with leading a team in an official capacity as a Game Designer. As class began, our group divided into two separate teams, however after 3 weeks the other team lost it's lead and only Programmer and ended up merging into a 10 person team under my supervision. I feel as though this also gave me a great deal of industry experience, meeting deadlines, listening to clients and higher ups about the direction of the game as well as implementing feedback from various playtesting sessions. Overall I'm relatively happy with where the game ended, especially with a 10 week deadline, but I wish I had more time to implement certain aspects of the game that were left on the cutting room floor, as well as go back and touch up several of the visual aspects of the game.
As previously stated production began with a smaller group of people. Myself (Lead developer, designer, and programmer) a second programmer, a level designer, a character artist and a prop artist. Our original pitch was for a fast paced medieval combat game in which you play as a peasant attempting to take revenge for outrageous taxes from an unjust king. Over the first two weeks we began prototyping the basics of combat, movement and pitchfork throwing. We went through several iterations in terms of these. Originally I had wanted the player to be extremely fast and agile, able to vault tables, slide under obstacles and evade the much clunkier knights the player would be up against. As a trade off the player would die in one hit. We had planned for any given enemy to die in one hit to emphasize a faster pace of the game but decided to give the knights additional health to give the player a sense of overcoming greater odds.
As this was going on we hit some snags with the production side of things. At the time both me and my other programmer were rather new to Unreal Engine and were having some difficulty with the gameplay. To compromise we decided to trim down on a good deal of the more acrobatic movements and excessive pitchfork combat, and focus on making the minimum viable product the best it could be. we kept a faster movement speed, a relatively high jump and the ability to throw your pitchfork. While a stab with the pitchfork could drop a knight in a couple hits the thrown pitchfork could instantly kill a knight, for the cost of your only weapon. This led to a great many risk/reward elements, as well as an incentive to learn the level layouts and where pitchforks were placed for the optimal time to throw them.
Upon focusing more on the quality of players abilities we decided to add in some additional enemies besides just the basic knights, to add more depth to the combat from an external point. Archers were added in to encourage using the thrown elements of the pitchfork and to make players focus on their surroundings in combat. We also added in elite knights, who had a more wide reaching moveset and were unable t be killed by the pitchfork directly. While deciding how to kill the elite knights we decided to add some emergent gameplay with chandeliers that could be dropped by throwing a pitchfork at them. In addition, while focusing on emergent systems we decided to add in a torch and fire mechanics. Upon throwing the torch it would ignite certain objects in the environment, allowing the players to make traps for the enemies.
At around week 3 the other team's lead programmer dropped the class. We collectively decided to merge into one team of ten. This process took a bit of time, reacclimating the new recruits onto the team and getting them up to speed. At this time we were creating the Player Zoo, to test these new mechanics. by the time we had it completed, we successfully implemented the players abilities and rudimentary fire spreading capabilities.
As time went on the original idea of a lone peasant taking on a group of knights seemed a little impractical. After a long and arduous meeting, and at the behest of our professor, we decided to take the game in a different direction. Instead of attacking a fully defended castle alone players would now be accompanied by a small militia of peasants and lead a revolt into the castle. While this would mean a good deal more work, especially with AI we believed we could complete the undertaking with the additional help from the merged members.
The next couple weeks were dedicated mostly to that AI. While we had an abundance of Programmers one was busy managing the file merging, as we did not have any access to Perforce or other Source Control softwares at the time, and the other was focusing on bugfixing and generating more flammable materials, as well as enabling the fire to spread. As such Myself and my other Programmer were working on the AI. Neither of us had tackled something like AI before and didn't know anything about Behavior Trees at the time. As such we all manually coded in each of the AI's basic functions from scratch. Hit Detection, HP, Animation Triggers and states, as well as the various environmental interactions. In the end I'm actually extremely happy with what we were able to produce on the Enemy AI side of things, especially with our limited knowledge at the time.
The Player's Companion AI, however, was a much harder undertaking. We spent a majority of our time fine tuning the Enemy AI and as such the players companions provided a unique challenge in the time allotted. While the attacking code was mostly just copied from the Knights the rest was built from the ground up. We found early on the Peasants needed some sort of follow distance to the Player as they would surround the player, making them unable to move. Before we managed to work out a solution we added in the ability to stab your allies and kill them so you could move. this proved extremely comedic, and as such we kept it in there. The AI also needed to be able to target the Knights, and this took a good while to figure out as well. In the end we managed to get the companion AI working well, but unfortunately we didn't get enough time to generate a respawn mechanic for them, so once dead, they were gone forever. However it was quite entertaining to see them mob the knights to death and as such I think their inclusion is better than if they were left out.
As production neared a close final bugfixing was underway. We managed to quash a good deal of issues we had but in the process many other things needed to be paired down in order to deliver an enjoyable standalone project. We had planned for the Peasant to be able to throw a tomato, leading a Knight to berserk and attack surrounding allies, we had also planned for more a more intricate boss, but due to time constraints we focused more on the core elements of the game. As our project neared a close there was one major hurdle in our path. We needed to add in Sound to bring the core gameplay higher. Unfortunately our sound team was finding it difficult to keep up, and as such I stepped in and completed a majority of the sound design within the final week of class. I think if I could return and only touch up one thing about the project, it would be the sound, but I feel as though it was needed, even in it's unrefined state, to add extra feeling to the gameplay.
Overall this project was a fantastic learning opportunity and gave me a great deal of leadership experience. I feel as though over the course of this I learned how to perform successfully under pressure, I learned a great deal about the delegating of tasks and how to recognize strengths and weaknesses of my team members. While the final project has only a couple instances of flammable materials and emergent gameplay elements, I feel as though the attempt was educational in the sense of exploring ideas that are often desirable in a larger context. I feel as though we created an interesting groundwork that could easily be expanded off of, and would truly shine as a unique and enjoyable play experience with a bit more polish and refactoring with my current experience.