Stockfall is an asynchronous online-multiplayer game where one player is randomly selected to act as an undercover traitor. Instead of hacking PCs, searching for hints and planting the bomb the traitor will try to sabotage the other players with traps, ambushes and their most useful tool: A different perspective.

Unlike the other players who play the game from a third-person view the traitor can switch freely between the normal perspective and a top-down view granting the traitor the ability to plan ahead and lay out a plan to victory.

Development time: 3.5 months
Roles: Programming, audio coordination

It reached the finals of The Rookies 2017

Each of the four players starts the game on an elevator not knowing who will be chosen to act as the traitor.

Shortly before the match starts one player will be assigned the traitor role which grants the abilities to switch to a top-down view, knockout unsuspecting player and seeing the PCs the 'normies' have to hack in order to progress. By picking up traps and setting up ambushes the traitor has all the tools to sabotage the operation.

Placed inside shelves and locked behind doors are traps like flashbangs or mines and hints that give the normie team some information about the whereabouts of one of the security PCs they need to hack.

The Team behind Stockfall:
Character Art & Animation by Carl-Christian Gehl
Character Concepts by Rohan Duong
Environment Art by Eric Heung
Sound and Music by Damiano Picci
and Philipp Hagmann

One of the most complex tasks during development was making sure that the scene would transition smoothly between third person and top-down perspective. To prevent worse performance in top-down compared to the default view we made or generated LODs of almost every mesh in the entire scene and even changed the quality of some specific materials whose details one would not be able to see from such a distance.

To allow dynamic culling of the upper floors while in top-down mode I sorted every actor in the scene into floors which were switched on and off depending on the floor the player pawn was currently standing in. While zooming out the floors above the player would be culled after a very short duration and while zooming in the upper floors would be made visible again a few meters away from the camera's final position making the cull process not visible to the player.

A visualization of how everything above the player is completely culled:
Each actor could be made interactable over the network by deriving from a central base actor class. Separated events for cosmetic callbacks on clients, logical callbacks on the server, notifications when the progress has changed and many more exist and can be easily extended with either C++ or Blueprints. There is support for multiple players interacting with a single object if so desired.

Everything related to interaction could be overriden and adjusted starting with visual feedback based on progress or whether there was a pre-condition for using an object. This for example was used for the minigame the player would have to solve prior to opening a lock or hacking a PC.

While the system was relatively straightforward to implement it had to account for a lot of edge cases like the interacting players getting knocked out while solving a minigame and of course the procedure of client prediction for aforementioned minigames or even the progress value itself.
During development I created a small app that would update the game automatically when we made a new build. This way we were able to play with people remotely without having to send them the current build over and over again. It was a simple WPF application that connected to my personal server and fetched the newest build.

To support this tool I added a custom build step after the Unreal Engine packaging that took the build, sent it to another tool which would zip it up and store it on the server automatically.