The Develop Post-Mortem - Space Pirate Trainer

The Develop Post-Mortem - Space Pirate Trainer

By Develop

December 13th 2016 at 11:30AM

Still in Early Access, I-Illusions’ sci-fi shooter is already one of the highest rated virtual reality titles on the market. We caught up with Dirk Van Welden to learn more about the game’s inception.

Where did the inspiration for Space Pirate Trainer come from?

Back in October 2015, when I received a prototype of the Vive, it only had a handful of demos. All of them were beautiful or very good tech demos, but there was no real action in there.

Being inside of room-scale VR for the first time reminded me of those classic arcade machines that I used to play when there was a fair in the neighbourhood. I decided I wanted to shoot lasers at droids like in Galaga, and dodge bullets like Neo, because you can be anyone in virtual reality. Feeling like a superhero or villain is great, and VR can make that happen.

Arcades drop you inside of the action right away, and the difficulty curve is designed to let you survive a few rounds at least. I learned from those lessons and tried recreating that experience with Space Pirate Trainer.

Why focus on room-scale VR? Did this not limit what you could do with the game, or did it open new creative opportunities?

Positional tracking was always something I thought that was missing in VR. It is also the reason why I sick most of the time when trying out previous prototypes of other HMDs. Some of the tech demos that were included with the headset made good use of that room-scale feature, but only some of them were using it as a core game mechanic.

In the first prototype of Space Pirate Trainer, there was no shield or bullet- time at all. You just had to run around like a madman to avoid all that incoming fire. The movement and shooting of the droids is designed in such a way that you actually have to move to stand a chance.

Every VR setup will be in rooms of different sizes. Playing around?with these limitations made me implement bullet-time and the shield. Dodging was still a fun mechanic, but you could play it in smaller areas as well.

How do you keep the game interesting when it’s based around waves of enemies?

Keeping a game interesting is all about keeping the player challenged. In the first prototype we had a totally procedural setup. A great benefit of that is that the difficulty curve is almost linear and you can even adjust it in real-time. But since Space Pirate Trainer is a score-based game, adjusting difficulty depending on the skill of the player was a no go.

We created our own algorithm for the difficulty of the waves and manually wrote the recipe of all the different waves, which ultimately was a lot more interesting.

How long do you expect okay sessions to last? Did this affect the way the game was designed?

Since SPT was always designed as a pick-up-and-play kind of game, and to be used in a lot of ‘first-time VR experiences’, we did not want to let the first plays last too long. Initially, the game only lasts for about a minute.

The moment players figure out the dodging and sound-cues, they usually survive for a few minutes. Every time you play, the droids behave in a different way based on certain parameters. That’s one of the reasons SPT keeps its players’ interest.

The biggest issue we had were the skilled players. Once they had mastered the gameplay, they would usually play very long sessions and the difficulty wasn’t going up fast enough. We solved that by decreasing the bullet time effect a tiny bit every wave and ramping up the difficulty in a non-linear way.

Keeping a game interesting is all about keeping the keeping the player challenged.

Dirk Van Welden

 

Space Pirate Trainer

 

How do you make a game intuitive, in terms of the controls and the way in which players need to move around?

If you make something that works the same way as it would in real-life, there’s not so much explaining to do. To make people actually move in a VR world, they have to feel and prepare for the menace.

The droids charge up first – they light up when firing – and bullet-time kicks in when the laser is close. So we’re speaking about three cues that prepare the player for moving out of the way before he or she actually needs to. When there’s a glowing laser just a few meters away from your face, most people tend to avoid it.

What was the biggest technical challenge, and how did you overcome it??

Optimisation. Space Pirate Trainer is an arcade shooter and needs that 90fps as much as possible. Rendering something in VR requires much more GPU resources because of the wide angle and resolution. A lot of fancy details and shaders were removed or replaced by less GPU-consuming ones.

Also, testing out stuff isn’t super convenient either. The helmet is constantly going on and off your head, you play around with the controllers, record some frame data, and search for samples that are off. We’re able to do most of the tests on our desktop, but sometimes actually attaching the HMD introduces new slowdown or bugs.

Here’s another example of optimisation: the environment used to be fully 3D. All the details in the background are rendered on a spherical map that replaces all of that geometry.

The droids were optimised to use as few draw-calls as possible, since we need to render a huge amount of them. We use light-probes and almost no pixel-lights.

We also use some tricks to have HDR-like effects without actually using HDR. We’re currently working together with GPU brands to get some VR-specific optimisations in there; it remains one of our top priorities.

What tech are you using? What’s powering the game??

The main tech behind Space Pirate Trainer is Unity. I’ve been using it for almost 10 years now. We use the SteamVR and Steamworks.net plugins and Shader Forge as our shading tool. Most of the modelling and animation is done in Cinema 4D and LightWave, while we mainly use Substance Painter for texturing.

How did you make the weapons enjoyable and intuitive to use?

When scale or feel is off you can see it immediately in VR, which is why we try to have our HMD on as much as possible while developing a VR game.

Since the controllers aren’t very heavy, we tried to keep the gun models as compact as possible. We have spent a lot of work on force feedback as well. It’s subtle and most users don’t even notice it at first, but it adds more punch to the overall experience than people would think. We use the controller-input data as raw as possible. I love games that react quickly and without any delay.

The only area where we had to cheat was the Railgun. It is a charge gun, so shooting it requires you to release the trigger. Because the controllers aren’t heavy, even that tiny movement makes the gun rotate just enough to miss your target.

We solved that by “locking” the target for a few milliseconds, when your gun is still fewer than X degrees off. I removed this as a test in our private beta, and got a lot of complaints that the charge gun wasn’t working well anymore.

Shooting with a controller is a lot different to shooting with a mouse, which introduced many opportunities and problems. Most people already know that we’ve made the gunbarrel angle editable. This was a community request, due to the fact that the controllers don’t have the same angle as real guns, and those vary as well.

What advice would you give?a developer that is tackling VR for the first time?

The main thing I would tell them is to spend as much time as possible in VR during development. Try to look for new mechanics that involve unique features such as accurate positional tracking of your head and controllers.

Also, try to be unique if you want your game to sell well. We built Space Pirate Trainer because there was nothing like it out there. If you’re looking to implement new mechanics, either implement them in a way that people would assume it would work in real-life, or do the complete opposite.

Do some playtests as early as possible with people that are not too experienced with VR, because – like it or not – that will be a significant part of your target audience in the upcoming year.