Sanctum Infernum - Week 10

This blog post has been adjusted as part of a resubmission assignment.

Hello everyone and welcome back to what will likely be the very last devblog for Sanctum Infernum! It's been a wild ride developing this game, with a lot of ups, and a hell of a lot of downs (we'll get to that though). For the moment this last 'unofficial sprint' had a fair bit of activity involving me, so let's get into it

Leads meeting

We used this leads meeting to sort out what we wanted to do in our last few days of working. After some discussion, we opted to form an unofficial sprint that would be volunteer only. This ultimately resulted in the work this sprint being done exclusively by leads however, as everyone else spent this time likely doing their other projects or even their own blogs.

Regardless, we then spent some time deciding what we were going to do for this sprint. In terms of what I had to do, I was assigned with helping the art lead with fixing the boss' animations, helping audio in any way that I could really, and fixing up the game over screen to respawn the player instead of taking them to the main menu. I was also tasked with fixing a lack of invisible walls in the slums (something which was fixed before that I had accidentally broke).

Getting to work

The week started off spectacularly when I still couldn't get audio working. By this point I was getting quite stressed about it and decided to ask for outside help by just asking a simple question in my university discord server. Someone who had experience with audio had caught wind of this and contacted me directly to ask more about it. I explained how things had gone and before I knew it he began rushing to get involved. I hadn't contacted the POs about this due to that rush and I was rightfully reprimanded for doing so.

Despite that hiccup, things in the audio department started to actually get sorted again thanks to the help from outside. For one, Wwise was back on the table and its implementation was being assisted by someone who knows how to properly use it and most importantly, it no longer became my job to implement. I could safely leave it to the audio people who know more about what they're doing with it than I ever could.

That left me with my other tasks, plus a few more tasks that were initially unplanned but we'll get to those. For now, I needed to add in the boss' animations. With the animations themselves fixed on the model, all I had to do was make sure the code would let them work. To achieve that, I tried to copy how the animation chart(?) looks from the melee enemies

This meant that I wouldn't need to change any code for the boss and you know what, it mostly works, admittedly the animation sometimes gets stuck and the boss itself is slightly in the ground and by the end of the week with the deadline right in front of us I didn't have time to fix it properly.

Next up I fixed the game over screen to include two new buttons, one will reload the scene you're currently on and the other will quit to the main menu, replacing the original system that would just wait a few seconds and then send you to the main menu.

Since I was rapidly working on a lot of features this week, it gave me the opportunity to really play the game and notice a bunch of things that are missing or just not well designed. Easily the most prevalent issue I had was with movement speed so I implemented a sprinting feature where the player can hold left shift to move a bit quicker, which also takes advantage of the running animation that was previously unused.

Next up is the dungeon boss, which is a rematch with the boss from the slums, only this time now that you have the shotgun, you can actually stand a chance against it. The boss is located in the throne room at the end of the castle. It functions identically to how it does in the slums, though beating it will allow you to safely leave the castle and enter the endgame slums that was added last sprint.

Finally I focused heavily on optimising the game. For so long, the game (especially areas like the dungeon) ran terribly even on fairly powerful computers. The largest culprits were the dungeon map itself, the enemy models and some particle effects. I managed to achieve a much more stable framerate by replacing the old enemy models with some updated ones by the Birmingham art lead and implementing occlusion culling.

Occlusion culling is the tactic of not rendering whatever can't be seen by the camera, including objects that are behind a wall that is currently being rendered. We all had assumed in the past that it was already enabled, however as I learnt during this week, you need to add an OcclusionArea component to the camera, set all the walls, floors and ceilings to be occluder statics and then bake those objects. But hey after all that the framerate had more than doubled what it was originally, and for the first time since early on, the game was actually playable.

After these additions, I waited for audio to do their thing with Wwise, apparently they were still having some issues with implementing some audio but as time was running out we needed to just take what we had. I merged everything into the main branch on GitHub and then left it to the Birmingham product owner who added in some post production effects that ultimately cut the framerate back down... Oh well, this did however mark the completion of the game and it is now set to release at any moment, it could even already be out by the time this blog post is finished.

Reflection

This has been a tremendously large project that frankly went out of control very quickly. Now, I don't blame that on the leadership, or any member of the team at all for that matter. I mainly blame this on our circumstances, being thrust into a team where half the members are 103 miles away from us and then being told you need to essentially create a AAA vertical slice. I think it was too much, and the sheer amount of communication issues that sprung up simply because of our distance I wouldn't even be able to count on both hands. We are people that clearly work better in person, or with people that we already know well enough so adding in people from miles away that no one had any form of attachment to only served to hinder everyone.

One of the ways we had tried to alleviate some of our distance issues was through assigning two leads to each department, one from Guildford and one from Birmingham. This is a good idea but because of Birmingham not having any programmers at all, it meant that I the programming team only had 1 lead, me. I believe that this only did further damage to my ability to collaborate and communicate with the team members from Birmingham especially as it became more and more clear that my ideals clashed with theirs frequently (looking at you, Playmaker).

Being the programming lead for this project was stressful, too stressful given as I had ended up neglecting certain physical health issues I suffer from, which only made them worse and made things like attending meetings and having the energy to do work a lot harder for myself. In regards to communication, I already have a disorder that hampers my ability to communicate with others so being put at the forefront of this large team was bound to be a bad idea. Unfortunately, I wasn't given the choice on being programming lead due to other people's insistence and the lack of enthusiasm shown by the other two programmers to take the position.

I think that we could've probably been able to go with our original idea if there was some proactiveness shown in the beginning with setting up Unity and GitHub, these were things that I said I could do incredibly easily however I was not given the opportunity to do so until week 3.

I was also still getting to grips with using these industry standard tools for planning and organising tasks like Jira and Confluence. My usual style of making games up to this point had primarily been me just throwing ideas at the wall, experimenting with them and just seeing what works. Somehow that had worked up to this point but it is clear that if I am to move into the gaming industry, I will need to learn these tools properly and in that regard this project has been valuable in learning how to do so.

Overall, there's nothing that can be done about the state of the project now. Really, the fact that we have something at all now is a bit of a miracle and I am impressed with everyone for what they did manage to do despite the constant BS that was getting thrown at us. I am also impressed with my programming department for being able to put up with me being their leader, I think I'll always appreciate that.

I don't really have much more to say, thank you once again for reading these blogs, and perhaps I'll see you again when I develop a new project in the future, good bye for now.