If you’ve done any VR development, one of the key things you should know is that FRAMERATE is crucial!  Get ready to learn how the Lab Renderer can help you keep that framerate high.

Dipping under 90FPS will quickly make your game nauseating and ruin the fun.

Even if you have the most entertaining, exciting, innovative, other adjective game, if you can’t stay over the target frame rate consistently, your game will suck.

If you’re working in Unity, my original recommendation would have been to keep your vertex count low, bake as much lighting as possible, and limit yourself to 1 or 2 real-time lights where they really give a big payoff.

A few weeks ago though, Valve did something amazing and released their custom renderer for VR as a Unity plugin.

As the name implies, this is what they used to build the VR title “The Lab“, and I’d say was integral in making it look as nice as it does.

The Lab Renderer

The description on the asset store page doesn’t do it justice though, so I want to cover the performance gains I’ve seen by switching to this plugin for VR projects.

Benefits

Real Time Lighting

With Unity in a typical VR game, most lighting is baked.  In fact, most games in general use quite a bit of light baking.

If you don’t know the difference yet between baked and real time lighting, I’d recommend you give this article a read:

UNITY 5 – LIGHTING AND RENDERING

It’s long but worth your time.

The reason most lighting is baked though is purely for performance.  Ideally, given unlimited performance, real time lighting for everything would be great.  With the lab renderer, you get much closer to this.

In my previous VR games and experiments, I’d come to accept a limit of 1-3 real time lights being active at a time.

The lab renderer however supports up to 18 real time lights with little to no performance hit.

In my most recent VR game Armed Against the Undead, prior to switching to the Lab Renderer, I couldn’t have more than 1 real-time light enabled at a time without my FPS dipping below 90.

When using baked lighting, I was stuck waiting for light baking every time there was a change, in some cases waiting for 15-60 minutes, which as you can imagine can completely break the flow of work.

Once I made the switch, I was able to immediately turn off all baking, enable many more lights, and even make the lights all destructible!

Anti Aliasing

This comes straight from the Lab Renderer page, because I don’t think I could state it better…. but essentially, you get fast MSAA

   Single-Pass Forward Rendering and MSAA

Forward rendering is critical for VR, because it enables applications to use MSAA which is the best known anti-aliasing method for VR. Deferred renderers suffer from aliasing issues due to the current state of the art in image-space anti-aliasing algorithms.

Unity’s default forward renderer is multi-pass where geometry is rendered an additional time for each runtime spotlight or point light that lights each object. The Lab’s renderer supports up to 18 dynamic, shadowing lights in a single forward pass.

Framerate

The key reason you should look into using the Lab Renderer is FPS.

In my experience, the FPS gain from the lab renderer is around 50%.  This could of course vary drastically from project to project, but the difference I’ve seen is huge.

For Armed Against the Undead, the FPS gain is enough to take the game well over 100fps on an NVidia 970.

To demonstrate the difference, I’ve copied the existing project and built a side by side comparison of the game using both the standard and lab renderers.

I’ve added screenshots of both, so you can see there’s no real difference visually, but the FPS gain is huge.  I’ll let the screen shots speak for themselves..

The Standard Shot

The Lab Shot

Negatives

While the Lab Renderer offers some great performance gains, there are a few downsides that you need to take into account before making the switch.  Some things just aren’t supported yet, and I don’t know when / if that will change.

Shaders

To take advantage of the Lab Renderer, you need to use the “Valve/VR_Standard” shader.  If you have your own custom shaders, this may be an issue.  If your project is all setup with legacy shaders, you’ll need to manually convert them and make your assets look right again.  While I haven’t had a hard time doing this, I have to admit I’m not an artist and ‘close enough’ works fine for me.  But if you’re very picky about the art, this may be an extra time sink or in some cases a breaking change.  That said, if you’re using the standard shader for everything, the conversion is practically automatic and works great.

In addition to this, your general full screen shaders won’t work either.  If you have special full screen shaders you really need, you may be able to figure out a way to get them working, but in my experience none have worked so far.

Terrain

The unity terrain uses it’s own shaders, not the standard shader.  From what I’ve seen so far, there isn’t an easy way to make the lab renderer work right with terrains.  There are of course tools that convert terrains to meshes, and if you already have one that you like, that may be a good solution.  If your project makes heavy use of the Unity terrain system though, and you can’t easily swap that out, the Lab Renderer may not be right for it.

Getting Started

So now that you know the benefits, and can accept the drawbacks, it’s time to start implementing.

Luckily, doing this is easy and only takes a minute.

 

Commit your current project to source control!

If something goes wrong, or you find a drawback/issue you didn’t expect, you’ll want an easy way to revert.

GIT – You should be using it

If you’re not using any source control, read my article on Git and set it up before you do the conversion.  It will only take you 15 minutes and will prevent a ton of pain going forward.

Find your camera and add the “Valve Camera” script to it.

If you’re using the [CameraRig] prefab from the SteamVR Plugin, add this to the the (eye) not the (head)

Disable Shadows

Shadows are handled by the lab renderer, so you need to disable the built in system.  When you want to adjust shadow settings, look at the “Valve Camera” script you added above.

In your project settings, you need to turn off shadows.  To do this, open Edit->Project Settings->Quality

Set Shadows to “Disable Shadows”

 

 Update your materials to use the new shader

Use the Menu item “Valve->Convert Active Shaders to Valve”

Wait…

This will convert all of your materials using the Standard shader over to use the “Valve/VR_Standard shader“, and could take a while if you have a large # of them.

Optionally, you can use “Convert All Materials to Valve shaders”, that will find everything in your project, not just your open scene.  I recommend the Active ones first because it’s usually a lot faster and will give you a good idea of how things are going to run.  If your system is fast though, just select the All option from the start so you don’t need to do it later.

Setup your Lights

Find all of your lights that you want to be realtime (In my case that was all of them), and add the “Valve Realtime Light” script to them.

When you add this, take a look a the options available.  You may not need to modify anything right now, but it’s good to know what you can do with them.

Debugging

 

After you’re setup and running, you may find your performance isn’t as high as you expect.  This could be caused by some materials not being correct.

The automatic update of materials works great to catch things using the standard shader, but if you had some legacy ones you missed/forgot, they could be causing less than optimal performance.

Luckily, Valve already thought of this and added some helper options to the “Valve Camera” script.

With the game running, enable the “Hide All Valve Materials” on your “Valve Camera“.

Everything using the correct shader will disappear and only things that still need to be updated will be visible.

Swap those over to the “VR Shader” and check your performance again.

Start Now

My final recommendation is to start using the lab renderer today.  Don’t wait until your project is complete as the task will become much more difficult.

If you start early, you can tune your game for the performance available, and avoid the pitfalls of using something that’s incompatible.

If you want to learn more about the Lab Renderer, you can check out the steam forum here: http://steamcommunity.com/app/358720/discussions/0/

And if you have any feedback or tips you’d like to share, please comment or email me.

If you haven’t heard it already, check out this discussion on Unity3D & VR/Vive development.

1310 Building Virtual Reality Apps for Vive VR in Unity3D with Jason Weimann

 

The hosts of the show, Richard and Carl have a wide variety of experience and brought some interesting points to the chat.

If you haven’t heard them before, the show is about programming in general with a slight leaning toward c# (aka the best Unity language).

 

Today I’m happy to announce an early alpha build of Armed Against the Undead.  The game is available now to anyone who owns the HTC Vive, but only for the next 48 hours.  I’d like to get 100 people in and some feedback so the project can be moved to the next phase and become what the players want.  If you have the HTC Vive and want to play, sign up here:

The alpha signup has expired.  If you really want to play though, sign up to be notified when the next alpha test starts so you don’t miss out.

Note: When you close the game, it will pop up a survey to get feedback.  I know it may be annoying, but please fill it out so I can work to make the game as good as possible.

Game Description

The game takes place in the depths of a dead city.  Your goal is to get out alive….  There are lots of weapons and even more zombies..

Game Modes

The game has 2 distinct modes and more are planned for later.

 

Survival

Player Health: 1 (it’s survival)

This mode is exactly what you’d expect.  Stand in one place, shoot zombies, and try not to die.  The zombies (and other monsters) come from all directions.  Occasionally, you’ll get new weapons to fend off the beasts.  One hit and you die!  Survive as long as you can and beat the top score.

 

Story

Player Health: 20 (no you can’t heal)

Story mode takes you through the city, fighting your way out.  You’ll progress through different areas collecting new weapons along the way.  You can choose your path, save the humans, search for an easy way, or go find some better weapons down a back alley.

In this alpha build, only one path is available for testing.

Protect any humans you come across, they’ll bring you nice new weapons.  Make it to the subway and escape alive!

 

Weapons

Armed Against the Undead has Armed in the name!  There are over 20 weapons available to destroy the undead horde with.  For the alpha, the following weapons are unlocked and available.

Pistol

Damage: 1

Rate: Slow

Shotgun

Damage: 10

Rate: Very Slow

Chainsaw

Damage: 5 per second

SMG

Damage: 1

Rate: Medium

Flamethrower

Damage: 1

Rate: Fast

Minigun

Damage: 1

Rate: Very Fast

 

Tips

• Aim for the head.  Zombies die from 1 shot to the head every time.
• Shooting zombies in the legs can slow them down (they’ll start crawling if you hit them enough).
• Use the shotgun for up-close encounters.  It’s range is small, but it kills just about everything in a single shot.
• Listen for the growls.  If a zombie comes within 9 feet of you, it will growl, and you’ll have a second or two to shoot it.
• The chainsaw needs to be IN the zombies to cut them, but kills stuff quickly and doesn’t use ammo.
• Don’t forget to use the Grip to reload.

Get more ammo for your weapons by shooting at the ammo box (with the weapon you want ammo in)

Do you have your Vive?  Are you looking at SteamVR?

Are you ready to start building fun games and experiences in Unity?

Read along for some basic setup steps and a couple useful tips!

The SteamVR Plugin

If you’ve created a new project, the first thing you’ll need is the SteamVR Plugin.

This plugin has everything you need to get up and running, including some sample scenes.

The [CameraRig] Prefab

The SteamVR team has done a great job at making it easy to start out with the Vive.

Once you’ve imported the SteamVR plugin, you can find the [CameraRig] prefab located in the SteamVR\Prefabs folder.

Create a new Scene

Delete the Default Camera

In a new scene, drag the [CameraRig] prefab into your hierarchy.

Now hit play again and enjoy the boring blue skybox.

If you don’t see anything, check your error log.

You may have a message saying:

VR: OpenVR Error! OpenVR failed initialization with error code VRInitError_IPC_ConnectFailed: "Connect to VR Server Failed (301)"!

If so, you need to launch SteamVR.

To do that, open steam and click the SteamVR icon in the top right corner.

Once it’s started, go back to Unity and click play again.

If it still fails to start, post any error message you see in the console into the comments below so I can address your problem.

An Empty World

Looking around and replacing the controllers

 

If all is working well now, you see the skybox and nothing else, until you turn on your controllers…

Turn them on and you should immediately notice they appear in-game.  The triggers should adjust as you press them, and the trackpad should light up as you touch it (just like in the SteamVR Tutorial).

The controllers are available because of the [CameraRig] prefab.  If you expand it out in the Hierarchy, you’ll see the “Controller (left)” and “Controller (right)” children.

In the image shown here, I’ve turned on only the right controller, so the left is still deactivated (dark grey).

When you’re in play mode, the “Model” child of the controller creates children for the different components.

No Controllers? – Important fix for Unity 5.6 and SteamVR

Update: this is fixed and not needed as of SteamVR 1.2.2, this fix is no-longer needed.  Upgrade to 1.2.2 and skip this section! 🙂

If you’re using unity 5.6 and the current version of the SteamVR plugin, you’ll notice that the controllers don’t actually turn on.

Until the SteamVR plugin is updated, you’ll need to implement this quick fix to get the controllers updating properly.

Select the Camera (eye)

Add the “SteamVR Update Poses” Component to it.

And done..  Now the controllers will track again

Replacing the Controllers

One of the questions I get quite often is “how do I replace the controllers with a [sword/gun/hand/random other thing]?”

As you may already expect, you can simply add the thing you’d like to replace the controller with as a child of the “Controller (right)” or “Controller (left)” GameObjects.

For this example, we’ll replace the controller with a shotgun (like I did in the Zombie shooter game)

First, I drag the shotgun model under the “Controller (right)” GameObject

This ‘works’, but there’s a bit of a problem.  While the shotgun will move around with the controller, it won’t be aligned correctly.

Now there are a variety of ways you can fix this, but the simplest one and the one I recommend you use is to make a new GameObject for the Shotgun and have the model be a child of it.

With the “Controller (right)” GameObject selected, click GameObject->Create Empty Child

You should see this

Rename the new “GameObject” to “Shotgun”

Move the “Shotgun” model (in my case named DBS) to be a child to the “Shotgun” GameObject

Fixing alignment and position

Press play and go to your Scene view.

Because we can’t see the controller without hitting play, these changes must be done in Play mode, follow along to see how to keep those changes once you’ve left play mode.

In the Scene view, adjust your weapon model to be aligned with the controller how you want it to be (some guns for example hold at a different angle than the shotgun pictured below)

While still playing, look to the Inspector to copy the transform values

Stop playing, the gun will reset.

Now go back to the model for the gun (child of “Shotgun” in this example) and use the Paste Component Values menu option.

When you play again, your gun (or other object) should be properly aligned and move with your controller.

Once it looks right, disable the “Model” child of the “Controller (right)” GameObject.

You can delete it, but disabling it gives the same effect and allows you to easily re-enable it if you decide to make adjustments to your handheld items.

That’s all you need to get started!  You should be able to look around, place objects where your hands are, and get to building stuff!

Serious about VR?

If you really want to get started with SteamVR and build your own game today, my Professional VR Game Development course can jumpstart your project.

 

Using the Valves – Lab Renderer for VR

Getting started with SteamVR Controller Input

 

 

 

 

 

HTC VIVE Game Challenge

This week, I’ve decided to start a new VIVE challenge.  Each day, I’ll be creating a new Unity game developed specifically for the HTC VIVE.

I’ll spend a single day on each game (really about 4-6h of a day), creating the base gameplay and polishing up the experience a little.

After each game is complete, I’ll post the results here with a gameplay video and some thoughts on how it worked out.  I’ll also provide a download link for any current Vive owners to try it out and see how the experiences turn out.

 

Game 6 is ready now!

VIVE – StackEm Quick

This time, I wanted to mix it up a bit.  If you’ve seen the other games I’ve done this week, you may have noticed they’re pretty art heavy and take full advantage of the Asset Store.  While that’s a lot of fun, and can make games look great visually (great for a 4-6h prototype), I wanted to do something this time that used NO art from the store that you can DOWNLOAD and build yourself.

In StackEm Quick, the goal is to copy the randomized stack of colors as many times as you can in 60 seconds.  Each time you match the required pattern, you’ll score and a new pattern appears.  It’s intense when the timer gets low and you have to stay calm to keep your blocks from falling over.

Source Available

Again, the source for this project is available in the download.  Just use the normal download form below and you’ll get the game and the Unity project delivered to you immediately so you can play or tweak it all you like.

Result:

 

I’m very happy with how this one ended up.  At the beginning of the day, I had no idea what I was going to build.  Well… I had a few ideas, but none of those worked out.  This one started with me not really knowing how it would end up, and resulted in something that the family was fighting over not wanting to give up.  Picking things up and generally manipulating objects in the VIVE is a lot of fun and an interaction that should be focused on heavily.

Implementation:

This project actually has more code than any of the previous.  The main gamestate is controlled by the “GameStateManager” class.  In a larger project, this logic would need to be split out across a variety of classes/state objects, but ours is small so it’s all right there.  Interactions with other objects each reside in their own classes to keep things relatively clean.

 

GameStateManager

This class is responsible for the core game loop.  It deals with the timer and tells all our other components what to do and when to do it.  There are 2 properties on this component, “Round Duration” is the length of each round in seconds.  ShapeLocation is the area to spawn our shape the player must copy (the white platform).

Blocks

Those 4 blocks on the floor are placed in the scene.  They’re cubes scaled to 0.5 on all axis with a “MoveableObject” script attached.  The “MoveableObject” script has an Enum field defining the color.  This is used by the “ShapeComparer” to make sure you’ve stacked in the right order.

Hands

The hands are used to pickup blocks.  They’re attached to the Controllers of the [CameraRig] and have a single property for “Pickup Radius“.  This controls how far away the sphere can be from the box to pick it up.  When the player pulls the trigger, the Hands call a PickUp() method on the nearest block within the “Pickup Radius“.  When the player releases the trigger, the box is released and drops using normal Unity physics.

 

 

 

Invisible Walls

To avoid players dropping their cubes off the edges (or knocking them away by trying to release 1 inside another, I’ve added some invisible walls.  These are done with cubes where the renderer is turned off.  There are 6, they block stuff from falling, that’s all.hich case we don’t need to do

Shape Factory & Shape Comparer

These classes exist to create a random shape and then to compare the shape the player has built against it.  They were initially planned to create a variety of different shapes (think T, L, etc), but it turned out that building straight piles was the most fun and easiest to explain.  Building other shapes would have required the ability to stick blocks together and take them apart (which you may notice some remnants of in the code).  So for now, the random shape generation is done by taking all the available shapes, picking a random order, then spawning them in that order.

 

UI

 

The UI here has a ScoreBoard script that’s called by the GameStateManager when the ShapeComparer returns true.  It also has a timer that’s updated every frame by the “GameStateManager”.

 

Up Tomorrow: ????

 

HTC VIVE Game Challenge

This week, I’ve decided to start a new VIVE challenge.  Each day, I’ll be creating a new Unity game developed specifically for the HTC VIVE.

I’ll spend a single day on each game (really about 4-6h of a day), creating the base gameplay and polishing up the experience a little.

After each game is complete, I’ll post the results here with a gameplay video and some thoughts on how it worked out.  I’ll also provide a download link for any current Vive owners to try it out and see how the experiences turn out.

 

Game 5 is ready now!

VIVE – Baseball – Pitching

Today’s game is an extension of another I’ve done.  If you haven’t seen the Vive Baseball – Home Run Derby game, check it out after you read this.  Also please go check it out on Steam Greenlight and give it a vote.

Since I posted the batting game, I’d had a variety of recommendations for things to add.  One of those things was pitching.  I decided this time to see if I could add that functionality as a new game mode within my challenge time limit.

 

 

Result:

This one is fun but exhausting.  That could be just due to the fact that I have the arm of a programmer, but it’s already sore from testing.  I think it turned out pretty good though and will be a fun new mode in the Home Run Derby game.  It needs a bit of polish still, but I could definitely see it turning into a head to head game where one person pitches and the other is batting.  It could even eventually be extended to a full scale multiplayer VR baseball game if the demand exists.

It is a bit hard though in it’s current form, but like I said, it could just be my lack of physical skill.  I think in the next iteration, I’ll add some difficulty settings that help guide the ball in the right direction.

Implementation:

Some of the implementation was already done, like the HomeRun indicators and fireworks, but the majority had to be created new for this project.

 

Pitching

The Right controller has a “Hand” object attached to it.  While it doesn’t render, it does hold the ball and handle releasing & respawning of the ball.  To spawn a ball, you hold down the trigger.  Once the trigger is released, the ball is released.  This is done by having a follow component on the balls.  They follow the hand until I trigger a Release() call (when the player releases the trigger).  At that point, I also set the velocity of the ball to match the velocity of the hand.

 

Strike / Ball Areas

Before starting this project, I already had a component called “BallTriggerArea“.  This was designed to play the HomeRun/Foul sounds in the batting game.  For this though, I needed a particle effect to play in addition to a sound, so I extended the class with a new one “BallTriggerAreaWithParticle” and attached that to 3 box colliders that you can’t see in the game.  When the ball enters one of the areas, it sets a bool on the ball saying that it’s been called (strike/ball), plays a sound, then plays a particle at the balls current position.

 

 

 

Swing Area

To get the granny to swing, I’ve added another invisible collider (see a pattern here?).  That collider tells her to swing the bat and sets a bool on the ball that it’s been swung at.  Later, in the Strike/Ball areas, we check that bool to make sure we don’t have her swing and play a “Ball” sound effect.  That’s why the “StrikeZoneBallTrigger” is used for on the “BallTriggerAreaWIthParticle” script.  If the goes through the swing area, all ball trigger areas tell the strike one to play instead of themselves (unless it went through strike, in which case we don’t need to do anything different).

 

AI Batter

The Granny model is available on Mixamo.com along w/ the swing animations.  For her, I added a bat made by my buddy Frank and a script that starts her swing animation by setting the “Swing” trigger on her animation controller.

 

AI Baseball Bat

The last component is the bat.  The script here listens for OnTriggerEnter, and when a ball enters, it plays a hit particle & sound, then launches the ball up and out.  No real physics are done here like they are in the batting game.  We just make her hit it hard and far in a semi-randomized direction.

 

Up Tomorrow: ????

 

HTC VIVE Game Challenge

This week, I’ve decided to start a new VIVE challenge.  Each day, I’ll be creating a new Unity game developed specifically for the HTC VIVE.

I’ll spend a single day on each game (really about 4-6h of a day), creating the base gameplay and polishing up the experience a little.

After each game is complete, I’ll post the results here with a gameplay video and some thoughts on how it worked out.  I’ll also provide a download link for any current Vive owners to try it out and see how the experiences turn out.

 

Game 4 is ready now!

VIVE – Candy Catcher

Initially, this was going to be an ice cream catching game.  The game play would have been to catch falling scoops of ice cream on a cone and stack them up.  Due to a lack of good ice cream art assets, a change had to be made.  I toyed around with a few other things, including kittens, but candy turned out to be the most enjoyable.

For this game, you have 2 plates.  Candy falls from the roof of an ice cream parlor where a miniaturized you stands to catch it and drop it onto a tray.  Each piece of candy you save earns a point.  Get as many points as you can within 90 seconds and compare with your friends and family.

 

 

 

 

Result:

This turned out to be more fun that I’d expected.  I thought catching things might be good, but didn’t realize how much balancing things adds to the game until after implementing it.  I’d started with a bucket, but it was pretty dull.  Going to plates and a tray to drop them on made it far more engaging.  My wife and kids all seemed to enjoy it and wanted to compete to catch the most candy.  Surprisingly though, my youngest had a really hard time catching them (he typically scores better than the others in most of the games).  Overall, I think it was a success and a good little game that shows a fun mechanic.

 

Implementation:

Not much to the implementation here, but I’ll cover it anyway.  The mechanics were very simple to add.  The hardest part was finding a theme with available art that would work.

 

Candy

The candy spawns slightly above the ceiling.  There’s a candy spawner that picks a random area within a couple meters each direction.  The candy has a high drag value so it falls pretty slow.  When it hits the plates, that drag gets reset to 0 so it can roll right off.  Each piece also has an audioSource that contains a sound effect for when it hits the plate.

Plates

The plates are attached to the Vive Controllers.  They have a mesh collider and a tag that says they’re plates.  The tag is used by candy to know when it should play it’s sound effect.  That’s all there is to them..

Spawners

You may be able to tell from the script, the spawner just has an array of Candy prefabs, a spawn time, and a randomized range.  It just runs a countdown timer and spawns a random candy from the list with the x & z position randomized from -0.3 to +0.3.

 

Up Tomorrow: ????

 

HTC VIVE Game Challenge

This week, I’ve decided to start a new VIVE challenge.  Each day, I’ll be creating a new Unity game developed specifically for the HTC VIVE.

I’ll spend a single day on each game (really about 4-6h of a day), creating the base gameplay and polishing up the experience a little.

After each game is complete, I’ll post the results here with a gameplay video and some thoughts on how it worked out.  I’ll also provide a download link for any current Vive owners to try it out and see how the experiences turn out.

 

Game 3 is ready now!

VIVE – Zombie Shooter

Zombie Shooter was my 7yr old sons first choice.  When I got the Vive, his favorite game quickly became the Space Pirates.  He’s always been a big FPS fan (mainly playing TF2), and wanted me to make one too.  Where he got the Zombie idea, I’m not sure, but it seemed like a good fit and a reasonable one to put together.

In the Zombie Shooter, you have one goal…. stay alive..
The zombies keep coming, until you’re dead.  They spawn in waves every 10 seconds with a 10 second delay between each wave.  Their spawn rates are slightly randomized as are their positions, but they come from all sides.  In addition to that, some of them like to run!

 

 

 

Result:

I really liked the result here.  After a bit of iteration, my wife seemed to really get into it as well.  If you watch the video, she went for almost 6 minutes in that session alone.  The mixing of slow zombies with fast ones adds quite a bit of intensity to the game, even though only 12% of them actually run.  My kids haven’t yet had a chance to play it though, so I won’t know the full result until after this post goes live.  I’d love to hear from others though on how you like it.

Implementation:

This game has a few interesting implementation details that aren’t present in the previous ones.  It takes advantage of the mecanim animation system and has some basic wave spawning.

 

Guns

The guns are were a little difficult to calibrate.  For them, I’ve added a mesh from a gun pack and a “Gun” script.  The script checks for the trigger pull of a controller, and when it’s pulled does a raycast using Physics.Raycast.  The Raycast actually comes from an empty transform placed at the tip named “muzzlePoint”.  I also use this to determine where the muzzle flash should appear.
If any Zombie is in front of the gun (detected by the raycast), I call a TakeHit method on the zombie.  Other than that, they have a reload timer which is adjustable in the editor and currently set to 1 second.  If the timer isn’t refreshed, I just ignore trigger pulls.

They also have a laser scope, which is actually a copy of the one from the Dungeon Defense game.  This is toggled by the grip buttons and helped my wife get used to aiming.  Once she had it down though, she was able to play fine without them.

 

Zombie

The zombies took a little longer to setup due to an issue I had with animations.  For some reason, my walk animation wouldn’t properly move the zombie using RootMotion.  In the end, it turned out that just re-importing the walk animation (deleting and re-adding it) fixed the problem.  I got the Zombie and his animations from Mixamo.com.  I believe they’re free, but it’s possible I paid for them and didn’t notice.  There are also a variety of other cool zombie animations on there, but I didn’t want to go overboard on prettying this game up right now.

When they spawn, they have a 12% chance to run.  If they fall into that 12%, I just use a trigger to switch animation states from Walk to Run.  Because I’m using Unitys RootMotion, the zombie starts moving faster without any other changes.

Aside from the animations, there’s a basic call in the Update() method that just finds the player by a tag and does a transform.LookAt().  While this wouldn’t be the best way to go in a real game, because you’d want to use proper navigation, it was fine for this quick project.  If the zombie is in “attack range” of the player, he’ll make a noise from his audio source, play an attack animation, then kill the player (restart the level) if he doesn’t die within 3 seconds.

I also have the TakeHit method mentioned above in the Zombie.  This method reduces his health by 1 (initially I was going to require 2 shots, but ended up doing away with that).  When the health reaches 0 (on the first hit), I switch his animation with an animation trigger and make him schedule a GameObject.Destroy after a few seconds via a coroutine.

Spawners

This is actually the longest script of the game.  Because of that, and because there’s been some interest in code samples, here it is:

using UnityEngine;

public class Spawner : MonoBehaviour
{
    // Note I don't use the NavMeshAgent.  I was planning to but decided to ditch it for the simpler method of .LookAt
	// I do still use this _prefab though, so the zombies have a NavMeshAgent on them.  To cleanup, I should remove this
	// but I wanted to show what I initially planned vs what actually happened.
	[SerializeField]
	private NavMeshAgent _prefab;
	[SerializeField]
	private float _respawnTimerMax = 5f;
	[SerializeField]
	private float _respawnTimerMin = 2f;

	[SerializeField]
	private float _waveDuration = 20f;
	[SerializeField]
	private float _waveDelay = 10f;

	private float _countDownTimer;
	private float _waveTimer;
	private float _waveDelayTimer;
	private bool _spawning = true;

	private void Update()
	{
		_waveTimer += Time.deltaTime;
		if (_waveTimer >= _waveDuration)
		{
			PauseSpawning();
		}
		else
		{
			_countDownTimer -= Time.deltaTime;
			if (_countDownTimer <= 0)
				Spawn();
		}
	}

	
	private void PauseSpawning()
	{
		_spawning = false;
		_waveDelayTimer += Time.deltaTime;
		if (_waveDelayTimer >= _waveDelay)
		{
			_waveDelayTimer = 0f;
			_waveTimer = 0f;
			_spawning = true;
		}
	}

	private void Spawn()
	{
		var randomOffset = new Vector3(UnityEngine.Random.Range(-1, 1), 0, UnityEngine.Random.Range(-1, 1));
		var agent = Instantiate(_prefab, transform.position + randomOffset, transform.rotation) as NavMeshAgent;
		_countDownTimer = UnityEngine.Random.Range(_respawnTimerMin, _respawnTimerMax);
	}
}

I want to note that this is not to be taken as an example of a good / clean script.  It is in-fact pretty terrible and messy.  In a real game, we’d have a state system that would handle different game & spawn states.  But as a throwaway, it gets the job done fine.  Also, if you’ve used Unity much before, please take note of and start using [SerializeField].  If you don’t know what it’s for, or why you should be using it, please read my article on the subject here.

 

Up Tomorrow: Catch Something

 

HTC VIVE Game Challenge

This week, I’ve decided to start a new VIVE challenge.  Each day, I’ll be creating a new Unity game developed specifically for the HTC VIVE.

I’ll spend a single day on each game (really about 4-6h of a day), creating the base gameplay and polishing up the experience a little.

After each game is complete, I’ll post the results here with a gameplay video and some thoughts on how it worked out.  I’ll also provide a download link for any current Vive owners to try it out and see how the experiences turn out.

 

Game 2 is ready now!

VIVE – Archery

The goal for this game was to build a semi-realistic archery simulator.  It didn’t quite turn out that way, but it’s still an interesting experiment.

Each round, you receive 10 arrows.  Your goal is to score as many points as you can by hitting both stationary and moving targets.

 

 

 

Result:

In my head, this was a lot more fun than it turned out to be.  I’ve learned that holding something in front of your head in VR doesn’t feel great.  I think the lack of peripheral vision may be the reason for this.  While it was a neat experiment, I think in the future, I’ll avoid games that have mechanics like this.

Bow & arrow pulling also turned out to be a little more time consuming than I initially expected.  While I could get the arrow to stick to the string pretty easily, making that look right and have proper limits wasn’t feasible in such a short time.  In the end, I went with making the bow play it’s normal pull animation when you touch the string and removing the restriction of holding the arrow in place.  So while in the video it may look like it’s being pulled back and released, you can just as easily tap the string and pull the arrow controller away.  I think the lack of a proper physical feedback mechanism (like a bow built for VR) makes this interaction just not quite work.

All that said, my wife somehow still enjoyed the game.  It was one of her recommendations, so perhaps that had some influence.  Or maybe I’m just not great at judging these, I’m not sure yet.

Implementation:

There are only a few components to this game.  The more advanced ones got pulled due to not working out (bow pulling)

As a side note, I do have a Giveaway going on right now for a $25 Asset Store voucher.  If you want to win, you can enter here.

Bow

This was an asset from the Asset Store for $5.  There’s also a free one available, but in the end I wanted the animation so I paid up.

 

It works by having a trigger on a box collider attached to the string.  When the trigger is entered by the right hand controller, I reload the arrow and play the animation.

Arrow

The arrow was pulled off the bow asset and the pivot point had to be fixed.  For some reason, many art assets in the store have strange offsets and pivots that make no sense, this followed that trend.  Once it was fixed though, I placed a simple arrow script and an audio source on the arrow.  The script has a single public Fire method that sets its’ parent to the root (initially the parent is the bow so it will track), then it adds some force in it’s forward direction.  Because the bow’s forward was a bit messed up, I threw in a quick hack of an extra gameObject named “DirectionalTransform” that I used to get the correct forward direction (this could have been done in max/maya too, but a lot of the time these little hacks are quicker for people who haven’t used them much before).

They also check for collision and if they hit the ground or a target/box I set the isKinematic property to true on it’s rigidbody so it appears to stick into the target.  You may notice in the video that there’s a bug when she hits the moving targets.  I didn’t think to make the arrows become a child of the target, so they stay floating wherever they hit it.  I considered fixing this, but thought it was more interesting to discuss the issue than resolve it.

Boxes & Targets

These just have a trigger collider and a “Target” script.  The target script just watches for trigger enter events.  When they fire, it increments the score and plays a sound.

 

 

 

 

Up Tomorrow: Zombie Shooter