Edwin Teoh
Security Surge is a single-player 3D puzzle game. You play as, Surge, an anti-virus to save your computer from virus corruption located in an unknown source by heading to each of the 5 different components of the motherboard and rescuing the DATAs in trouble.
Use each unique DATA to your advantage as you build bridges, teleport and open locked gates along the way.
But you're not alone! Viruses roaming around the environment will chase you down if it sees you, corrupting the DATAs you are carrying.
The project was developed over a period of about 6 months with a team of 8 consisting of 6 programmers and 2 designers.
Roles
-
Setting up OpenGL backend
-
Debug boxes
-
Mesh rendering
-
-
Asset Management
-
Animations Programming
-
Custom compiler to separate fbx into mesh, skeleton and animation clip
-
Interface with editor
-
Details on Contributions
As mentioned earlier, the API and backend of the debug draws were set up by me. The debug drawing utilizes batch rendering that renders multiple lines that form a polygon in a single draw call. Although it was not planned, this proved extremely useful when testing our custom physics engine.
Once game assets have been created by the designers and are ready to be tested in the game, I used an importer called assimp to load the assets from their fbx files and store them in the engine and game.
The process is similar for animations where I will also be using assimp to load the assets. It was also around this time when the loading of the assets between levels was becoming a bottleneck. So I implemented an asset manager and the asset browser on the editor side.
It was about this time when we realized the fundamentals of animation retargeting which is playing different animation clips on the same mesh. Each animation file fbx file contains a mesh, a skeleton and an animation clip, and if the animation used the same mesh and skeleton, we could potentially swap out animation clips to cycle through the different animations we had.
Animation Programming Keypoints
Early development of the animation system tested together with 3Ds Max. However, 3Ds max had a history of having issues with the skeleton structure of the bones and so we swapped over to Blender to add keyframes to the animation.
At some point, the designers churned out many animations to test within the engine. However, they would have to wait several hours for me to finish classes to help them import the files into the engine. I wanted to reduce this wait time so I implemented an animation window to import and view if the animations were playing correctly quickly.
Some animations are only needed to be played once, some are on a loop. Additionally, our C# scripting of the engine need to interact with the animation system. So I introduced a state system on the UI side of the animation system. The designers or programmers would be able to quickly add an animation state and the C# script can control the state as the backend instructions are exposed to the C# scripts.
Content Browser and Asset Management
Every engine would have some form of Content Browser and Asset Management system to manage the game's assets. We have our own Content Browser where we can do the following
-
Import Animation Assets
-
Import FBX meshes
-
Delete previously imported assets
When we import new assets into the engine, it gets pushed through a compiler that converts the asset into a format unique to the engine. This helps us be less reliant on 3rd party libraries like Assimp or Soil during runtime. The converted asset is then stored inside the content browser.
Credits
Aloysius Quek Wei Jing - Producer
Lee Yan Yi - Co-Producer / Designer
Nazul Izuan Bin Abdul Hadi - Design Lead
Ryan Ong Kok Chin - Tech Lead
Irfan Hidayat Bin Rosland - Physics Lead
Benjamin Wong Zi Feng - Engine Lead
Jeroen Tan Yi Xu - Graphics Lead