Remnith is a chaotic FPS where enemy units feed off of the energy of every shot that isn’t lodged directly into them. The more you miss the stronger they get. Challenge enemies in over 25 arena battles spread over 3 levels with the choice of 5 difficulty levels. Arm yourself with gigantic multi-barrel energy cannons, refine your accuracy and dismantle machines piece by piece before can they have a chance to evolve any further.
 
The game was released in 2017 on the Oculus Store, Steam & Game Jolt and can be played on the Oculus Rift, HTC Vive & PC. I worked with Joshua Salvador on programming while also acting as the team leader. Level design was done by Nicholas Adams and 3D modeling and the story was done by Roman Moskvichev. There wasn’t a set game designer as all of us took part in the design of the game. Remnith was the first game I’ve worked on that was made to be released and took 2 years to complete. I learned a ton from working on this game just due to the scale of it and the fact that I had release in mind.
 
Coverage for the game can be found on VR Games For and VR The Gamers.
 

If I had to choose one aspect I really enjoyed working on it’d probably be the enemy attacks. Remnith was built upon scalability in attacks so it allowed for virtually any badass attack we could think of to be implemented. Just sketching out attack ideas and then actually trying to code them in was incredibly fun. It was an amazing feeling when the attacks worked just like how I imagined after proper implementation.

 
The pillar attacks were the most flexible/modular attacks. After I created the first pillar attack that randomly rose pillars around the enemy I started coming up with a bunch of other attacks that utilized them. The way pillars work is that they take in one position anywhere. Based on that position a raycast is sent downwards to find the closest point on the ground. Then after that I call on Unity’s navmesh feature to find a spot close to that point.
 
This way I can make sure pillars are only spawned in places where the player can stand. This also avoids pillars spawning on top of tiny details. Once the pillar is spawned it’s first shifted down below the terrain and a warning is spawned just above that point. Once the warning disappears the pillar rises up quickly through a coroutine and damages anything touching it. Once it stops, the ability to damage is also disabled. It’d be pretty horrible if the player were to just walk into a static pillar, fly back and then die. Below is the base script and an example of one pillar attack variations where pillars gradually spawn outwards from the enemy.
 

 
One of the most satisfying attacks to make were the Turret Barriers. These were barriers that floated around the Flying Enemy and would fire projectiles at once. The cool part about these projectiles was that they fired in a specific path to make things more dramatic. First they’d fire straight outwards slowly. Once they reached a certain point they would start turning towards the player and accelerating in speed. After that the projectile charges at max speed towards the player. If the player didn’t dodge by this point he’s pretty much dead. What really added to this attack were the particles that left trails making the path visible.
 

Because the game had to be completed for release, bug fixing and optimization were stressed. In an assignment it would just be embarrassing having a slow buggy game but releasing a game like that would be a disaster. Overall I’m extremely proud of the work Roman and Nick did in terms of the art, because of this I aimed to optimize the game in a way that had a minimum effect on the visuals.
 
I applied a lot of standard optimizations like changing the level of detail of models and tweaking properties such as the viewing distance to cull off excess rendering. To further optimize things I came up with some of my own methods such as dynamically changing the viewing distance and lighting quality based on where the player was and where they were looking. This was done with the intent of having the optimizations dynamically change based on the level rather than annoying Nick to change parts of the level to reach a set frame rate.
 

 
I also changed up some of the enemy attacks such as cutting out attacks that were too far for the player to reach or see and moving more attacks in the view of the player to make it seem like the whole map was surrounded. In general I found myself changing amount for accuracy, size and speed to optimize attacks without affecting their difficulty. Finally, one of the last features I decided to implement were separate graphics settings for VR and desktop mode. Although I managed to get the game running fairly fast enough in VR, I couldn’t figure out a way of further optimizing things without noticeably changing the graphics. Having separate settings gave me the ability to default the graphics in VR to prioritize speed with average graphics while desktop mode prioritized graphics with average speed.