Project Overview

Over the last year I have worked on a team to create The Krilling: Scare Feast!, as lead programmer. The Krilling: Scare Feast is a spooky silly experience, where your goal is to cure yourself by completing the Gator Ghost’s Gumbo recipe. In this Mardi Gras themed game, possess objects without getting caught and use the environment to create and collect different emotions from hotel guests. Unlock gumbo ingredients, more possessable objects, and new areas as you go. When I joined this team the idea had already been in development for quite a while and I was part of a group of programmers joining the team.

The Engine

When we initially started the project, we had all been using Unity for quite some time leading us to the natural conclusion to use Unity. This was much before the recent crisis with Unity that has caused many to drop the engine entirely, including myself.

Gameplay

What went right:

The biggest thing that went right was our unique possessable movements. Different objects that you possess control differently. For a long time, they were all mostly the same, but eventually, we landed upon making each one unique in its own way. This vastly improved the quality of our gameplay.

What went wrong:

The game suffered from lots of clarity issues as well as gameplay limitations. Lots of game mechanics lacked a concrete explanation. Things like which possessables provided which emotions or how exactly a given possessable worked. If we could go back it would be a good idea to devote more resources to these kinds of issues rather than devoting so much to content. The fun of the unique possessable movement was also limited often by other aspects of the gameplay. Mainly the map was very small and confined so certain possessables that thrived in wide open areas became cumbersome. We also had worker NPC’s that would come and kick players out of possessables to act as an adversary, but often this just led to interrupting the fun the player was having.

Design

What went right

Again the biggest design win was on the quirky and difficult-to-control possessables and making all of them unique. There were lots of other components to our game, but none of them came even close to bringing out the fun that the possessables did.

What went wrong

A large lack of focus is what really made our game struggle. Our team was made up of all students that were new to game development and our team had no full-time designer. This led to a lot of design pivots throughout the process, vague notions of what we wanted, and a lack of focus on what mattered. Our game could have been much better had we cut out the noise, focused all in on the possessable movement, and just created a sandbox area for the player to go around and have fun.

Code and Workflow

What went right

Our team had a solid level of decoupling between systems. Relying primarily on an event system to communicate between systems. This worked great when members were communicating and everyone was on the same page.

What went wrong

We often had issues in our team communication. Programmers would take a direction for a given task, and find out later that it didn’t match up with the approaches other programmers were taking on their own tasks, causing often lots of refactoring and leading to a loss of development time. A different big issue we had was with Unity scene files. In the beginning, we often had merge conflicts within the scene file that were nearly unresolvable. Over time we transitioned to a system where on a given week only 1 person was allowed to touch the scene file at all, which prevented any sort of issues with conflicts. To prevent this from hurting development time everyone else would work solely inside of prefabs that could then be later placed into the scene.

Conclusion

Overall, it was a great learning experience for all of our team members. With very little experience between us, it was a struggle to get to where we are today, but in the end, I am proud of what our team managed to accomplish. A lot of our problems I believe were rooted in the makeup of our team. With no designer to lead the design and prototyping of systems, we lost a lot of time to going in the wrong direction and lacked focus on the things that mattered. An excess of programmers often led to miscommunications and unnecessary complexity. With more programmers than we needed, we ended up losing even more time to making sure every programmer was up to speed on how things were working, and time lost to refactoring because another team member did a system in a way that did not fully connect with your own work. If we were to go back in time I am sure all of us would have an uncountable number of things that we would do differently, but that is just proof of what we learned along the way.