Purgatory Punch-On


Battle it out as spectres possessing ordinary items in order to escape purgatory and move on to the afterlife!

My 2nd final year university project initially slated for display at PAX Australia 2020, Purgatory Punch-On is a multiplayer brawler where you play as a ghost with possession and phasing abilities.

The effects of COVID-19 resulted in many of the opportunities that is provided by the course to not be available, including the presentation at PAX and receiving regular feedback from others.

I am taking part in this capstone from a software engineer's perspective, as opposed to a designer's perspective last year in Get the Fog Out. Although the outcomes for the software engineering capstone are geared more towards more traditional software engineering, our supervisors were considerate of the more flexible approach required for game.

My contribution can be defined broadly as a gameplay programmer, however more specifically I was responsible for UI functionality and input handling. I also contributed to the attempted network programming. Due to the lack of game networking knowledge within the team, the programmers shared the responsibility for handling and implementing the netcode.


Liam Dunstan - Gameplay & UI Programmer
Sarah Howarth - Lead Programmer
Michael Nuttall - Graphics & Audio Programmer
Jake Trenton - Producer / Designer
Nick Frangos - Audio Lead / Animator
Tabitha Leimonis - VFX Artist
Liam Stafford - 3D Artist / Designer
Jac Trang - 2D Artist
Jake Plant - Composer

1 / 1


We made the game in Unity 2019.3.2f1, which focuses heavily on a component system for all of the objects in the scene. We decided to build on this and develop a modular system for the designers to be able to easily play around with different unique weapon types. We created components that could be paired together, such as WeaponMoveable, Shootable, Melee, and much more. These components had exposed variables, with which designers could adjust values and create many different weapons based on a few basic types. The players themselves were also designed modularly, in case the designers wanted to mess around with different options for the players.

This was easily our biggest challenge, and ultimately our biggest shortcoming. We were working on a multiplayer-exclusive game during the COVID-19 pandemic, in the toughest lockdown in the world. We had one of 2 options: 1) add AI functionality so players can play single-player, or 2) add networking functionality so players could play together remotely. In the end, the game was intended as a multiplayer experience, resulting in our decision to pursue networking.

Between the 3 engineers, we had no real understanding of netcode. In the leadup to this decision, one member did already start identifying possible networking solutions. We settled on Mirror after deciding we would go with netcode, and we set out a plan for what needed to be done. We all took the time to learn about the system and work out what functionality needed to run server-side and what needed to run client-side. We always knew it'd be difficult, and we set ourselves a timeline of about 4 weeks to get the entire game functional via networking. We knew it'd be difficult and there were more than enough issues that arose. However, we overcame most of them and achieved quite a bit.

We were able to get players all joining, swapping characters, and moving to the main game scene in the first week. We had all of the clients loading the levels able to move around together, updating on each other's screens perfectly, after a lot of debugging. We were able to keep on track, although we were putting in more hours than usual to get it working in some occasions. After a week and a bit, we did a re-plan, checking what we'd planned still matched up with what we had since learnt, and updating what needed to be updated.

Then came our biggest hurdle. Possessing weapons. We had it reasonably planned out, or so we thought, but it would not work out the way it should have. We had issues getting the possession to sync properly between clients. We had a weapon getting possessed on all clients, but the position would not update. The Network Transform component just didn't seem like it was doing its job properly. We spent nearly 2 weeks working on possession, but it just would not work. We hit our deadline for functionality and we still didn't have possession working, let alone actual game completion.

At that point, we called it. We had other tasks to do, including overall bug fixing, and we knew any further work was a waste of time. We put netcode aside indefinitely, although we were positive it wouldn't be touched again. We discussed what went wrong, what it cost us and decided that, despite it being a failure, it was a good learning opportunity. We learnt a few things about networking, we learnt how to deal with issues that were blocking us. We knew it was a risky venture, but we also knew we had enough time to try and get it working and not lose out completely if it didn't end up working. We set out a timeline, a plan to tackle the issue, and achieved what we could to the best of our abilities.