Project Type |
Game developed for a studio during my placement year |
Main Software Used |
Unreal Engine 4, Perforce, Rider for Unreal Engine, Trello |
Languages Used |
C++, Blueprints, C# |
Primary Roles |
Technical Lead, Character Programmer |
Main Skills Developed |
Unreal C++, Perforce, Team Working, Communication and Self Organisation Skills |
In my placement year I worked for a studio with seven other students and developed the online game 'VCR' - an asymmetrical 'Dead by Daylight' inspired survival game featuring ghosts and a camera crew designed to hunt and record (or maybe even vanquish) the ghost.
I worked predominantly on the player controllers and several environmental objects that the player can interact with.
I worked predominantly on the player controllers and several environmental objects that the player can interact with.
Trailer
The above trailer highlights several gameplay aspects and gives an overall taste of the game.
Game Loop Explanation
There are two main phases - normal and frenzy.
In the normal phase, the camera crew hunt the ghost.
Meanwhile, the ghost disguises as objects and collects frenzy points from remnants.
Once the ghost has enough frenzy points, it can transform into the frenzy ghost!
During this phase, the ghost hunts the camera crew and tries to kill them.
If it finds them, it can possess and kill them!
The camera crew must hide and get footage of the ghost while it is in frenzy form. They can also complete minigames to weaken the ghost.
Eventually, either the camera crew films the ghost enough to banish it...
Or they can gather cogs to build a weapon and vanquish the ghost.
If they fail however... the ghost will kill all of the camera crew!
Technical Highlights
The most technical aspects of the game were related to the networking, and the issues this introduced at high latency, such as unresponsive character movement and fatal errors.
To solve these issues, I researched and discussed networking related topics with my team and taught the other programmers how to properly replicate data, how to react to replication via RepNotify, when and how RPC calls should be used, as well as the importance of assigning ownership of objects. Additionally, we split the programming into several sections (player controller, minigames, environmental effects etc) so that each person could work on individual aspects and combine them once ready, and I built an interaction system so that actors in the environment could be configured automatically (with aspects such as ownership handled automatically if desired). This process streamlined the process of new gameplay mechanics being created, and ensured that all programmers were aware of how the networking should be implemented to reduce issues.
However, as mentioned, unresponsive character movement was a major issue for a large duration of the project. This was due to how I was processing movement on the server and replicating it back to the clients, but wasn't including any client prediction, meaning that a player with high latency would press the button to jump or sprint, but would not see the effect for several seconds, which vastly reduced the responsivity of the game. To solve this, I created derived movement component classes for the characters (inherited from Unreal's Character Movement class) and implemented custom compressed flags to allow for proper prediction of moves by the client. This allowed the client to move the character while waiting for it to happen on other player's instances due to the latency, therefore resulting in immediate effect on the local player's instance regardless of latency.
Overall, these processes allowed many networking issues to be minimized.
To solve these issues, I researched and discussed networking related topics with my team and taught the other programmers how to properly replicate data, how to react to replication via RepNotify, when and how RPC calls should be used, as well as the importance of assigning ownership of objects. Additionally, we split the programming into several sections (player controller, minigames, environmental effects etc) so that each person could work on individual aspects and combine them once ready, and I built an interaction system so that actors in the environment could be configured automatically (with aspects such as ownership handled automatically if desired). This process streamlined the process of new gameplay mechanics being created, and ensured that all programmers were aware of how the networking should be implemented to reduce issues.
However, as mentioned, unresponsive character movement was a major issue for a large duration of the project. This was due to how I was processing movement on the server and replicating it back to the clients, but wasn't including any client prediction, meaning that a player with high latency would press the button to jump or sprint, but would not see the effect for several seconds, which vastly reduced the responsivity of the game. To solve this, I created derived movement component classes for the characters (inherited from Unreal's Character Movement class) and implemented custom compressed flags to allow for proper prediction of moves by the client. This allowed the client to move the character while waiting for it to happen on other player's instances due to the latency, therefore resulting in immediate effect on the local player's instance regardless of latency.
Overall, these processes allowed many networking issues to be minimized.