The AI demands for this project were intense. I needed to create an AI system that handled a large number of unique units, each with multiple attacks and abilities. This system also had to be flexible enough to allow for designers to make large changes after I moved on from the project and it had to be lightweight enough to handle large unit counts on mobile. In addition to all that, each unit had to control similar to an action game character when selected by the player.

The first issue to solve was how to create a complex system complex enough to handle the large variety in unit behaviors, abilities, and attacks while keeping things flexible enough to allow for rapid large design changes after testing. Due to the contract, I had to limit the amount of code changes needed during testing as I would only be on call for light bug support by that time.
To accomplish this I used a combo of the concurrent and hierarchical state machine methods to create a fully modular system that could easily be changed just through simple editor input. The system ended up using multiple layers of root scripts each of which had a number of related behavior scripts underneath them. No piece aside from the base root was required to function so designers were able to mix and match the different behaviors to change them to their hearts content.
The attacks and abilities were also broken up into smaller module components, allowing for complete reworks of characters without any programming needed.

In order to keep the system as lightweight enough to run on mobile, rather than using a standard update method I setup a tick system in the Unit Root. This had a set amount of time between each AI update call. This time period was varied between each unit to be sure that all of the units didn’t update at once and potentially cause a slow down. Only a few specific functions were allowed to run every frame.

In order to scare off lag on mobile, the biggest optimization I made was to the AI’s update system. Rather than have each unit run through it’s decision process every frame, I created a tick system which allowed me to tell the AI how often it was allowed to update. To keep all the AI from updating at once and possibly causing a slowdown, I staggered each unit’s tick times. With the exception of some time sensitive functions, everything in the AI system ran on some sort of tick.

The final large issue with this system was allowing the player to take over any unit and have direct control over attacks, movement, etc. like in an action game. To do this I implemented a behavior enumerator. When a unit was in PlayerControlled mode, it would have a different set of speed, attack time and other variables so that the player would be able to make quick maneuvers and feel as if they’re controlling an action game character rather than an RTS unit.

Towards the end of the second SparkXR project we hit a huge problem. We were nearing the ship date and our VR game was only hitting 10fps in some places!!! That was way below what we needed with Steam’s recommendation being at 90fps minimum for VR. So for the next several weeks I jumped into optimization.

Our first issue to solve was to get seamless loading working so that we didn’t have large hiccups in the game. Initially I tried loading each level in separate small parts via playing through multiple times while adjusting the timing that each part loaded/unloaded to avoid any hiccups. However this became too much to handle while changes were still being made to the main game so instead we opted to keep the loading hiccups and design ways to cover them up.

With that solved, the general framerate still had to be improved. I started with the high tech solutions hoping they would solve our problem without having to make any noticeable changes to the experience. I implemented screen resolution changes, occlusion culling, position triggered object loading/unloading, Unity’s new SRP Batching system, changing the headset update rate, Single Pass Instanced rendering and several other methods. Most of this helped but it wasn’t anywhere near enough to hit our targets.

At the end of the day, the biggest fps boost I made came from simply going through everything in the game and optimizing as many individual objects as possible. This meant changing individual render settings, optimizing geometry and shaders, removing all unnecessary objects, adjusting light render settings, removing unneeded objects, combining/lowering the res on textures, optimizing particle systems, nitpicking on every single piece of code, and thousands of other menial tasks that slowly pecked away at my sanity.

Thankfully all those small bits started adding up and we got to a shippable framerate! We even got to 120fps in some of our heaviest hit areas! And to boot I made almost no noticeable changes in the experience. It was still a cutting edge VR game!

The two games Guardian and Juicing the Crescent(JTC) needed character controllers that were able to interact with different types of gravity forces. Guardian had a stage where you flew around a planet while JTC was focused on traversing the inside of the moon. Between camera controlls, weapons aiming, and abilities things got complicated quickly.
The two games Guardian and Juicing the Crescent(JTC) needed character controllers that were able to interact with different types of gravity forces. Guardian had a stage where you flew around a planet while JTC was focused on traversing the inside of the moon. Between camera controlls, weapons aiming, and abilities things got complicated quickly.

The code needed for both projects was essentially the same. I first angled the camera’s down to be facing the right direction then applied player controlled camera rotation to that. The weapons aiming just grabbed the camera rotation while the player movement used the camera’s rotation to orient itself. It was a nightmare of math junk but in the end it made for some awesome gravity gameplay!
The code needed for both projects was essentially the same. I first angled the camera’s down to be facing the right direction then applied player controlled camera rotation to that. The weapons aiming just grabbed the camera rotation while the player movement used the camera’s rotation to orient itself. It was a nightmare of math junk but in the end it made for some awesome gravity gameplay!

During my time at SparkXR we were on a tight production schedule. To help with this I tried to create designer friendly script modules whenever possible. In addition to not requiring a programmer to make changes, having complex event sequences be split into several simple components made debugging a lot quicker.

I did this using Unity’s Event System and by splitting the scripts into small, simple tasks. By stacking these scripts up in the inspector you could create complex behaviors without needing any code.