The team at Survios have been building VR games for years, across most major platforms, and today at XRDC cofounder Alex Silkin gave a talk about why the studio builds its own tech for each game — and why you should too.
The core takeaway of his talk was that VR devs should try (wherever possible) to build flexible, extensible codebases that make it much easier to do multiplatform VR game development. If you’re aiming to do multiple VR games, it pays to start with the assumption that you’ll be re-using and iterating on your core systems.
And while it can be tempting to house them in one big chunk, Silkin says Survios has learned to break things up into modular components which can be brought into a game during development and modified at the team’s discretion.
Survios itself has launched a slew of VR games across PlayStation VR, Oculus Rift, HTC Vive, and other platforms, though Silkin highlighted the studio’s recent multiplayer pirate-’em-up Battlewake as a prime example of how the studio has been able to re-use and build upon the systems its built for each of its games.
“One of the most fundamental pieces of tech we developed, even back in the Unity days [before Survios became an Unreal Engine shop] was the interaction system,” said Silkin. “It’s fundamental to how you interact with the world…it’s how we set up the associations when the player interacts with the world.”
Recycling your game systems for fun and profit
This interaction system has been part of multiple Survios games in one form or another; from Raw Data to Battlewake. As another example, Silkin highlighted the weapon system Survios created for Raw Data; The system was built to be modular and portable, so it could be used for all the game’s guns, as well as its autonomous turrets.
Survios’ weapon system includes components like firemode (burst, automatic, charge shot, etc.) and damager (whether the weapon is hitscan, or projectile-based, or volume-based like a flamethrower), and Silkin says those components continue to show up years later in games like Battlewake.
By the same token, the damage system Survios built for Raw Data has been expanded and extended since the game’s debut. Originally built to let the game do things like track health on a per-limb basis or trigger hit reactions, Silkin says the team has since expanded upon it and made it more modular . (think: tracking health on a per-limb basis, allowing for custom health-like variables like armor, hit reactions, etc).
The team also built in support for melee combat in Raw Data, and so when the time came to start work on its VR boxing sim Creed: Rise to Glory, it already had a strong foundation to build on.
“We did some melee in Raw Data, but it was very simple; your hands were kinematic, they would essentially just go through the enemies,” said Silkin. “So we really wanted to polish that up, particularly the impact of your punch, and the collision detection of the hands.”
So the team kept working with the melee weapon system from Raw Data, building collision spheres into the player’s hands and using inverse kinematics to shift character limbs appropriately.
“So if you blocked, an the enemy tried to punch you, the sphere would hit, and the IK would offset the hand,” said Silkin. “That really added some physicality to the combat.”
“We also wanted to make the act of getting punched more real, more immersive,” said Silkin. The team had already designed enemy robots in Raw Data which would charge the player and “knock” them back; so they grabbed that system and tried to build a similar mechanic for Creed.
“If you get punched too hard you get knocked out of your body; it gets consecutively harder [to get back in] if you get knocked out,” said Silkin, explaining that the Survios team was able to build out a unique feature by re-using the Sprint Vector traversal system in a canny way.
Where possible, make your systems modular
But having Sprint Vector and Creed using so much of the same code was a problem because most of it was tied up in a single Survios plugin. This led to a lot of extra effort required to pull out or modify components, as well as some wasted time as team members went back and forth about the best way to do so.
“We realized that all these assumptions were constantly getting broken, and teams were constantly arguing about what is the right way to do things in the base level,” said Silkin. “So instead we decoupled things into independent plugins with abstraction layers.”
Plus, the team created a sort of template which serves as an example of how to configure these systems for a game, creating a low-key unified philosophy of game design that anyone in the studio can access when starting a new project.
“People are free to hack together these classes from there,” said Silkin. “This is when we started our Great Pluginification.”
To shed light on how the Great Pluginification is going, Silkin showed an example of how the old Survios components plugin has now been broken out into 37 separate plugins (that get as granular as SVRDamage, SVRAnimation, SVRLoadScreen, etc), with more in the works.
“They all live in their own separate module, so theoretically those subsystems can be completely swapped out in a game if the team needs to,” said Silkin.
And as one of Survios‘ most recent releases, Battlewake is built on this system and incorporates a lot of the studio’s lessons learned to date. It’s also influencing future projects already; Silkin shared the example of Battlewake‘s Damage Decal Composition system, which efficiently applies damage decals to in-game ships and is already being repurporsed in other Survios games for things like displaying damage on characters.
“When we’re picking projects, we’re trying to choose things that will let us develop tech that we can use for future projects,” said Silkin. “Definitely try to break your systems into decoupled, modular blocks…it might means there’s more maintenance and boilerplate code connecting things, but over the long term its gonna make it easier for you to manage.everything.”