Jumpstart Apocalypse

I usually have quite a few side projects at once that I work on simultaneously. Bots, Websites, little games and the occasional command-line scripts. But the last half-year (about) I have been dialling it down and consciously halting any impulses I have to start up another little side project. This is because our Uni is wrapping up its second and last year which means we work on one big project.When it came time to pick teams back in July I had no idea what teams existed and what games they were planning on creating. My teacher, however, told me I should join this group making a VR zombie shooter. I expect this has something to do with me being one of the only programmers that own a VR Headset but I’m thankful I do. Because the people I got to work with made those months more than bearable.It has truly been a fun few months working on this game with the people at Tasty Biscuit and I learned a lot, so I decided to write up my experiences working on the game.

Making the game

This project was quite challenging because of all the new systems I had to work with. Our lead programmer took over the task of player interactions so i decided to do AI and the Utility classes. This includes but is not limited to Object Pooling and Scene Management which were some of the easier tasks I had.The biggest challenge I faced the entire project long was maintaining our git repository and ensuring everything worked in our Version control. At first, we were all using a single git repo that one of our designers owned but we soon moved it into a separate organisation that everyone was a part of. The next challenge was faced when we introduced Git LFS to keep all of our meshes and images in LFS storage. It was completely fine until a few weeks later when one of our designers complained that he couldn’t pull from the remote. as it turns out Github is limited to not only 1GB of Storage but also 1GB of bandwidth which is completely absurd in my eyes. The immediate quick fix would require us to pay so I started searching for an alternative, which I ended up finding. Gitlab is another public git server that operates similarly to GitHub. Although it has a few disadvantages it does have a significant advantage. 10Gb of LFS storage and unlimited transfer. This, of course, was the solution but as we already had the project in GitHub and I set up an automatic build action with GitHub action. I found the solution while digging further into the LFS Rabbit hole..lfsconfigini[remote "origin"] lfsurl = [email protected]:Organisation/Project.gitWith this .lfsconfig file, git knows to query GitLab if it needs to pull any LFS files and pushes them to the provided URL. This allowed us to have both the benefits of our code on GitHub as well as the 10GB+Unlimited Transfer of GitLab.As well as the Git I was also in charge of the Enemies and their AI. Meaning I had to create the behaviour from scratch. This posed a few challenges as I had never really done AI before and especially not in 3D with fully rigged and animated meshes. However, after a bit of experimenting, I settled on a solution that worked with every AI. Each Enemy inherits a Base class and overrides its virtual functions to give them all unique behaviour while keeping a maintainable class hierarchy. One of the things I think I did quite well this project was my “backend” (more like utility classes). All the code that didn’t have any direct impact on gameplay but instead just existed as tools and data structures. The biggest of which was my Object pool which allowed objects to be recycled. Usually, in unity, you create and destroy GameObjects but this approach can be slow when the GameObjects have a lot of components on them such as a fully rigged character. This loss of efficiency is not as Impactful as one might think but since the game is VR we have to take extra caution to make sure it runs smoothly. So I added a class that would manage Inactive class instances returning them when needed and collecting unneeded ones. As well if somehow the Pool runs out of instances it can spawn new ones as it goes so it ensures that there will always be one available. The Scope of the game kept changing as we tried to adjust to the time we had left and one of the features that were on the cutting table was the Dismemberment system. It seemed like it might be a little too much work for what it was worth. But I decided I wouldn’t let such a great feature be left behind and sat down to whip up a small prototype.Didn’t quite work as planned to begin with but after a bit of bug testing, I had created some of the cleanest code I had written. Most of the other core systems I put a lot more thought into I had to redesign or fix later on in the Project but the Dismemberment held up to the bitter end.

Conclusion

Reflecting back on the Project I’m glad my teacher told me to join this particular team. It was an absolute blast getting to work with them all. I found myself getting along well with my team members and us forming a friendship even though we had only ever communicated face to face. In hindsight deferring the year might have been a wise choice seeing as we suffered (and are still suffering from) a global pandemic. But it’s hard to want to have skipped the year when I have had the privilege of enjoying Team TastyBiscuit’s exquisite company.