• Clinton McCleary

Development Update - Respawn System

As mentioned in my last post, load times are significantly worse on console than they are on PC. This lead to a level streaming solution which cut these load times down to about 25 to 30 seconds per load. This works well when moving between levels but becomes brutal for the player if they are stuck and die repeatedly. There are sections of the game in this scenario where the player could end up spending far more time on loading screens than playing the game. Not a very good impression.

This was a big concern for me so as part of the porting process I implemented a respawn system. At first this was going to be an extremely complicated proposition. In thinking about it I was convinced I was going to have to rewrite large portions of logic, generate a ton of bugs and totally break the game. This is because everything relies on the level being reset upon death due to it being re-loaded. There are many things to consider. The AI needs to reset when it kills the player but so many parts of the level itself. Things like if a light is broken by the AI or not are significant things that need to be reset for fairness. So, without any real plan I sat down and started pulling apart the code. That’s when it occurred to me, I don’t need to refactor hundreds of elements in how it currently works. I need a new system that tells it how to work from now on.

So, I created the Infliction Respawn System. This system will get all the lights in the level, store their starting states and reset those states when the player is killed. I also do this for clocks, wind, visual effects, AI(s), some scripted events etc. I decided to leave the doors, drawers and other environmental interactables and not have them reset. This works with the narrative and puts less load on the respawn system. The respawn system also gets the players starting location and stores that as well as any checkpoint locations in the level. Everything is handled by this one system.

Once the AI kills the player, instead of firing the re-load level code, it now sends a message to the respawn system. The system checks if a checkpoint is active, blacks out the screen, relocates the player, resets everything allocated to it and fades from black giving control back to the player. This process takes about 5 seconds, mostly time spent on the black screen fading in and out. This was implemented and to my surprise was cleared by QA on the first try as being bug free. The player experience is 100% better and the implementation of this new system only took me roughly 10 hours (including time trying to figure out the best solution).

All of this wasn’t to abolish a lazy implementation from the original game or as part of some sales pitch for the console port. This was totally driven by the player experience, which should be at the forefront of all design decisions that directly impact that experience. If you're asking yourself "does this part of my game annoy the player?", it's time to consider what you can do to minimize the annoyance and keep the player experience as enjoyable as possible.


© 2016 - 2020 Caustic Reality

Caustic Reality Pty Ltd

ABN: 92 642 382 456.

  • Facebook
  • Twitter
  • YouTube
  • Steam