Logo
Remnith

Remnith


 
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 is available on Steam, Game Jolt & the Oculus Store 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.


C#

The main programming language I used to code the game.

JavaScript

I modified JavaScript components bought through the Asset Store and converted a lot to C#.

Cg/HLSL

Created shaders and modified purchased ones.

Unity3D

The engine used.

HTC Vive

Worked with the Vive and SteamVR’s SDK to add support for the game.

Oculus Rift CV1

Worked with the Rift and the OVR SDK to add support for the game.

Oculus Touch

Used for motion controller support with the Rift.

Oculus Rift DK2

Originally worked with the DK2 to develop and test the game for VR. Switched to the CV1 afterwards.

Git

Used Git with Bitbucket for version control.

Visual Studio

The IDE used with Unity.

Blender

Used for modifying and creating models and textures.

Photoshop

Used to create and modify a lot of graphics and textures.

Illustrator

Used to create and modify graphics. Also used for pseudo code and problem solving.

Audacity

Used to modify and mash together sound effects.

Vegas Pro

Used to create promotional materials such gameplay gifs.

Google Sheets

Used to manage all tasks and financial information.

Google Apps Script

Created scripts that managed all tasks and suggested the most important and efficient ones to do next.

Tableau

Used to graph progress on the project based on information in Google Sheets.

AHK

Used for automating work. For example, created a script to automatically go through Woovit’s search engine and collect hundreds of influencer contacts.

Microsoft Excel

Originally used to manage all tasks and financial information. Switched to Google Sheets afterwards

Microsoft Project

Used to manage progress and stages of the project.

Xbox Controller

Used to add controller support to the game.

PHP

Language used when working with the game’s website.

HTML

Language used when working with the game’s website.

CSS

Language used when working with the game’s website.

Aptana Studio

IDE used when working on the game’s website.





Sketching & Coding Attacks

programming122

 

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.

 

Pillar Attacks

2017-03-09_143448

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 damage is as well. 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 variation where pillars gradually spawn outwards from the enemy.

Curving Laser Beams

remnnithbeam

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.

Optimization

 

2017-03-09_132752  

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 affect 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 on the minimum specs and 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.

 

Images

1

ss_08fc85043282fe6675369468bd5633d4449a728e.1920x1080

ss_2b169fc8229b07886a6f4d030c3599d33d221b82.1920x1080

ss_781a30b1ed90b603929181b72e06f5d3f07e7bfd.1920x1080

ss_e85069bf1dabf3e51e0f06e1cc35e8bf13760d40.1920x1080

  • The Little Guy