All posts in "Virtual Reality"

Using the Valves – Lab Renderer for VR

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.The Lab Renderer - Low FPS Stats

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 Lab Renderer - Asset Store Screenshot

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

Using the Standard Renderer

Using the Standard Renderer (79FPS)

The Lab Shot

Lab Renderer - Using Lab 110fps

Using the Lab Renderer (110FPS)

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.

The Lab Renderer - Valve Camera

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

The Lab Renderer - CameraRig - Eye

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
Disable Shadows

 

 Update your materials to use the new shader

Use the Menu item “Valve->Convert Active Shaders to Valve”The Lab Renderer - Update Materials to Valve Shader

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.

Lab Renderer - Valve Realtime Light Script

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“.The Lab Renderer - Hide All Valave Materials

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.

Continue reading >
Share

VR discussion on .Net Rocks

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).

 

Continue reading >
Share

Armed Against the Undead Alpha

02
Days
03
Hours
40
Minutes
26
Seconds

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

Armed - Survival ScorePlayer 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

Armed - Save the InfectedPlayer 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!

 

WeaponsArmed - Grip To Reload

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

Armed - Pistol and Shotgun

Chainsaw

Damage: 5 per second

Armed - Chainsaw

SMG

Damage: 1

Rate: Medium

Armed - SMG

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.Armed - Save the Infected

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

Continue reading >
Share

Getting Started with SteamVR and Unity 5.6 [Updated]

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.

If you’re looking for info on SteamVR with previous version of Unity, it’s been archived here: http://unity3d.college/steam-vr-unity-5-4-beta/

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.

Start Today!

 

Using the Valves – Lab Renderer for VR

Getting started with SteamVR Controller Input

Continue reading >
Share

7 Vive Games – The Retrospective

My experience building 7 Vive games in 7 days

When I first received my Vive and tried out the sample projects, I was hooked.  My mind was immediately racing with all the possibilities for this new format. I’ve done VR work since the DK1 shipped, but this was revolutionary.  Day 1, I started trying thing’s out in Unity and was blown away with how well it worked.

I had a couple ideas and quickly got to work on the first.  This was going to be a remake of Rampart in VR.  You would pick up the walls and drop them in place, then use the controllers to aim and fire cannonballs.  Within a day, I realized my design was far from optimal and I needed to rethink my plans.

Rampart

Next, I decided to write a getting started tutorial.  I’d done previous VR tutorials and classes with baseball themes that were a hit so I started the conversion to room-scale.  Within a few hours, I had a working prototype where you could swing a bat and really feel like you were in the game.  This was great, I knew I had to push forward with the Vive.

While I was working on the baseball game, my mind kept wandering to all the other things that could be done.  On the way to a family trip to Disneyland I was talking to a good friend about how great the Vive is. (it’s close and these trips happen monthly, in fact I’m writing this in the car on another trip back).  While talking to him, I decided it be great to prototype a bunch of games.  A few minutes into the conversation, I’d decided to challenge myself and build a game a day.

I told my wife the plan, and it was locked in.

Workflow

The first thing I needed to do was build a plan.  I had to come up with a few ideas for games I thought might be fun.  Luckily, there were plenty of friends and to bounce ideas off and I had a flurry of great ideas coming in.

I needed to have a release schedule.  Since it was going to be 7 days, I knew there was some risk of slipping, so I immediately decided to pad my releases by a day.  A game built and recorded Monday would go out on Tuesday.  I’d also tried to have a simple game idea that could be built safely in 2hrs or less in-case things went drastically wrong.  To my surprise, the 2h game idea was a total failure, but everything else worked out great.

The games

Before going into the lessons learned, I want to give a quick rundown of the different games that were built.

Dungeon Defense


The first game I built was a dungeon defense game where you ruled over a little dungeon that was being invaded by goblins.  In this game, your goal is to prevent the invading goblins from stealing gold from a few scattered chests placed throughout the scene.  To do that, you’d shoot at them from above with some magic wands.  Initially, I’d considered building this as more of a tower defense game, but I quickly came to my senses and remembered that building a basic tower defense game would require quite a bit more work than could be done in 4 hours, let alone doing it as a VR experience.

The driving force behind the theme of being giant and ruling over a tiny dungeon or world came from a demo I saw at the first Occulus connect conference.  They showed a small cartoon town with a lot going on that you could view from wherever your head would fit.  I thought that was a great experience and wanted to follow along while adding some interaction.

Archery


VIVE - Archery

VIVE - Archery

Archery was an idea championed by my wife.  The gameplay here is simple, you have 10 arrows per round, you shoot targets and get points.  Targets further away or moving are worth more points. Your left hand holds the bow (sorry I’m right handed), and the right hand pulls the string and arrow back.  Once you’ve aimed, you pull the trigger and the arrow launches away.

Zombie Shooter


Zombie - FullScreen

VIVE - Zombie Shooter

This was probably my favorite of the set.  It’s a straight forward game where zombies come from all directions and your only task is to stay alive.  You’re equipped with 2 shotguns that automatically reload every second.  The real thrill in this one comes from having a variety of zombie speeds.  I’ve seen plenty players focus on a single area, forgetting to turn around, then be startled when zombies are at their back.

Candy Catcher


VIVE - Archery

Candy catcher is a fun goofy game where candy falls from the ceiling.  You have 2 plates to catch the candy with and a tray to drop it into.  Each piece of candy you drop into the tray is worth a point.  The initial concept for this was going to be catching ice cream scoops, but good ice cream scoop art was hard to come across.  In the end though, the ice cream shop with the fun music and colorful candy turned out to be pretty entertaining.

Baseball Pitching


Baseball Pitching Image

Pitching was something I wanted to do so I could add it as a feature in VR Baseball … Unfortunately, it didn’t work out and wasn’t fun at all.  Nobody really seemed to enjoy it, including myself.

That said, VR Baseball itself is quite a bit of fun.  Hitting a ball is a blast.  Attempting to throw one.. is not.

Stack 'em Quick


Stack 'em Quick Image

In this game there are 4 colored blocks.  In front of the player, a copy of these 4 blocks will appear in a random order.  The player’s goal is to pick up the blocks from the ground and stack them in a matching pattern.  When you complete a match, you score a point and a new combination is generated.  This was actually a lot of fun and one of the most popular games I built.  The gameplay is simple, but the challenge is really exciting.

Dungeon Crawler - Hack & Slash


Hack & Slash Image

One of the most requested things during this week was a sword fighting experience.  Having already built a basic dungeon defense game on day 1, I thought I’d re-use some of that work and build a fun hack, slash, & casting type game.  To move the player along, they float on a ‘magic carpet’.  As you move, goblins come around corners and start attacking you.  Your controllers are swords that you swing, tearing through the goblins with ease.  There are also a few weapon replacements you can pickup throughout the experience. In total, this game lasts a full 10 minutes, though it starts feeling repetitive and slow after the first 2.

What I learned

During this week, I learned a lot about VR development, and more specifically the Vive.  I’ve done a large variety of VR projects in the past on the Oculus DK1, DK2, and GearVR, but this was something totally new.

HTC Vive

The HTC Vive is an amazing device.  If you’ve never tried room scale before, I implore you to go find an opportunity to do it.  Room scale experiences are a huge change from any previous VR games I’ve played in the past.  It’s hard to explain how big a leap it is in text or words..  For me, the jump to the Vive is equivalent to the jump from Google cardboard to an Oculus device. Controller tracking was available previously with devices like the Razer Hydra, but they pale in comparison.  The Vive controllers are a near perfect input device, working well as a bat, gun, hand, sword, and more.

Unity integration with the Vive is even more noteworthy.  The job the Valve team has done integrating the Vive with Unity is nothing short of incredible. To convert a game to be Vive compatible, you literally only need to import the SteamVR asset pack and drop in the [CameraRig] prefab. This simple action gives you full room scale tracking for both the player and the controllers. Customizing your game from here can be as simple as adding a child gameobject to the controllers and disabling the ‘model’ that renders the controllers by default, which is exactly what I did for most of the games produced.

Room Scale

Room scale as I mentioned is amazing, but it requires a big shift in mindset when developing games.  There are many opportunities for really interactive experiences and a few gotchas to watch out for.

Great Things

  • Moving around! – Experiences where the player had to actually move physically were a big hit.  The one that stands out the most in this set was Stack ’em Quick.  In this game, people were running all around the play area picking up boxes, carrying them to another part, and stacking them up. They’d duck down low to pick up the boxes, and reach up high to put them on top.  I think the full use of room scale and movement is what made this game stand out as the second best.
  • Swinging the arms – You’d may be be surprised to learn that many people actually get tired or exhausted playing some room scale games.  Even my wife who’s extremely fit gets worn out after 10-15 minutes in some of the more intense games.  Of course like anything, how tired you get depends on how intense you play, but many of these games are so engaging that people get really active while playing them. Archery & StackEm were both games where people tended to get very immersed and exert themselves.  VR Baseball is another example where swinging a controller as a bat wears people out much like a real batting cage.

Cons

  • In-game Player Movement – Unfortunately, movement is a bit more complicated when you’re dealing with a room scale setup and a standing player.  Game 7 is a good representation of the challenges presented.  When moving a standing player, movement at any real speed is very disorienting.  Rotation is far worse!  Turning the player at even the slowest speeds can make them fall over or get VR sickness.  If you try the Slash & Hack demo, you’ll see that even rotation at a 1-2 degrees/second is not fun.

General Virtual Reality Performance – FPS!

I can’t stress enough how important it is to remain above 90 fps when building a VR game. That number may seem really high, and it is, but it can’t be avoided. 60 fps used to be the standard for high end PC gamers, but in a VR game, 60 will make you sick.

You have a limited budget for vertex count in your VR games.
Use that vertex budget on things that are close and very visible (hand held items like weapons).

Visual Effects, Trees, and Anti Aliasing

One of the ​issues I ran into a few times before realizing what was going on was a terrible effect when I'd put trees in a game.  If you look at the games above, none of them actually use trees at all.  When I'd put them in, I would inevitably end up blinded & sick from light flickering through the branches.  It turned out that the biggest cause of this was the default quality setting in Unity that I was running in.  Without anti-aliasing turned on to at least 4x, trees were unbearable.  Even with it enabled, many trees still look terrible.  If you plan to have a forest or just a bunch of trees in your game, make sure you test them out right away, and look for trees that don't flicker and blind your players.

Asset Store & Mixamo

Without the Unity asset store, this project would not have been possible. All the games other than #6 relied solely on cheap and free assets from the store. There are some important things to take into consideration when finding assets for VR projects though.

Many of the assets on the store look great but perform terribly.  There were a few assets I purchased for these projects that ended up not working out due to excessive poly/vertex counts.  Currently, there’s no easy way to find out how things will perform without either emailing the asset providers or downloading and trying them out.

One thing that worked well for me though was searching for mobile/optimized keywords when finding assets.  Assets designed for mobile tend to be highly optimized and have little to no impact on framerate.  You do however have to find assets that also look good in VR.

Favorite Assets Used

BitGem Dungeon Builder Starter - I used this for the first and last games.  While it didn't say in the description that it was mobile ready or optimized, it ended up performing better than anything else I'd tried.  The pack and included demo scene looked great in both 3rd and 1st person views.  If you want to build a VR dungeon game, I'd highly recommend you give this asset a try!

Goblin Piker – I also re-used the goblin piker in both the first and last games. This was an asset I was very impressed with.  I wanted something cartoony looking that would fit well in the Dungeon I was using and this was a perfect match.

Mixamo!

If you haven’t checked out mixamo.com yet, do it asap.  It’s a site with great character models and a giant variety of animations.  And right now, it’s all FREE!  These models and animations used to be pretty expensive, but they were recently purchased by Adobe, and until they get a pricing system setup, they’ve made all the assets free to everyone.  The Zombies in game 3 were sourced from here, and there are countless other amazing models you can get there.

Mechanics

This may be the most interesting part of the retrospective.  Building 7 games allowed me to try a large variety of mechanics and to not worry about total failure.  Because of that, I got a good amount of insight into what was fun and what was ... "less than fun".

The Fun Stuff

Picking things up
Of all the mechanics I explored, this one was probably the biggest surprise for me.  The feeling of actually picking up objects in Stack 'em Quick, made that game a real joy to play.  Even though you're not actually closing your hands, just pulling the trigger to grip something, then moving and releasing it somewhere else is very enjoyable.  I should note that I've played other Vive games with similar mechanics, and every time, I've felt far more immersed just due to this simple mechanic.  If there's one mechanic you should definitely include, it's this!

Shooting
This may seem obvious, but shooting stuff never gets boring.  The way the Vive controllers are designed, they work equally well as pistols or shotguns.  Aiming and pulling that trigger is something everyone who played seems to really love.  It's also a very easy to pick-up mechanic that doesn't need to be explained.  I should note though that aiming in VR can be difficult at first.  In the Zombie game, I actually added a simple laser sight to make it easier for people to get started.  (I actually just added the laserpointer script that valve provided with the SDK on a child object and aimed it the right way)

God Mode / Little Worlds

The first game I did had a big gods eye view with little minions below.  As I mentioned before, hovering over a miniature world is oddly satisfying.  Everyone who played this in front of me ended up bending down to their knees to look closer at the little goblins walking around.  Now I'm not sure what the best experience will be for this type of game, but I have no doubt that someone will crack this style and make a game-changing product.  And in typical Valve fashion, the only thing you need to do for this to work is increase the scale of the [CameraRig] prefab.

360 Degree Gaming
The only games the really featured things to do from all sides were the Dungeon Shooter and Zombies (hack & slash to a lesser degree).  For Zombies, I'd say this was a key feature.  Being surprised by things from behind made this game so much more intense.  Eventually, players learned to keep watching their back, but inevitably they'd get distracted and surprised again.  It's also important when doing these kind of experiences to make good use of audio cues.  While they may not notice the Zombie running up behind them visually, they'll definitely realize it when they hear the footsteps and a loud growl.  This is such a great mechanic that I've decided to make it a key part of my next Vive game.

​Room Scale
I mentioned this before, but it's worth repeating.  Making the player move around the room really adds a lot.  While I don't expect this to be really common just due to the limited room space many players have, I think it should not be overlooked.  Actually walking across a room to pick something up adds more immersion than anything else.

The Bad

​​Turning Players

I was shocked at just how bad a feeling it is to have your camera rotate while you're standing still.  In the hack & slash game, my original design was to move the player around with the touchpad.  Within a few seconds of testing, I realized this was a terrible idea.  Moving forward with the touchpad was a bit disorienting and I almost fell over.  Turning was SOOOO much worse.  When I started, I had the turning bound to the headset with forward movement bound to the touchpad.  At the first turn, I had immediate VR sickness that didn't fade for at least an hour.  From here, I tried a few tweaks, and eventually ended up with VERY SLOW controlled rotation and movement on a flying carpet.  Even though the movement is abysmally slow, it's still somewhat nauseating.  Perhaps someone else will find a way to conquer this problem, but to date, I've found no fun way to do it.

Throwing Objects / Releasing the hand
The baseball pitching game seemed like a great idea before I actually tested it out.  The problem I ran into was that when you throw a ball, you instinctively want to open your hand and release that ball.  Throwing a ball by releasing your finger from a trigger just doesn't feel right.  I think throwing something from the end of a long stick may be a bit less un-natural with the Vive controllers, but a basic ball just isn't fun, and almost nobody could do it successfully.

However this doesn't mean you can't throw anything, there are plenty of great ways to throw objects, it just feels bad throwing balls specifically..

Hitting Controllers together
With archery, this was a real problem.  Everyone who played would put the right controller up to the left and smack them together.  After that collision, they'd smack themselves in the face with the controller while pulling back the string.​  A big part of this was changing the in-game representation of the controllers into something that didn't physically match the device held in the players hands.  Of course, even if we show the controllers, I've still seen plenty of people smack themselves in the face while trying to bring things up close to their eyes for inspection.

Sword Fighting
Unfortunately, sword fighting on the Vive is not an easy problem to solve.  The biggest issue here is that there's no physical requirement to swing a sword and nothing that prevents the player from simply wiggling the controller back and forth as fast as they like.  A real sword requires force, strength, and control... but a light weight controller can't really reproduce this.

Update: A couple of games have figured this out, and made it a lot of fun.  But it took time and work to get it right.

​Conclusions

I hate to conclude this post at all, but I fear if I write for as long as I really want, nobody would make it to the end.  I have to say that building these 7 games was one of the most exciting experiences I've ever had and while it was a bit exhausting, it was worth every bit.  I also have to reiterate just how impressed I've been with Valve and HTC.  The device works amazing, and the software & support are the best I've ever had the pleasure to work with.

If you take away only one thing from this article and experience, let it be experimentation.  When you decide to build your own VR game, don't build out an elaborate design and plan from the start.  Try everything!  Take every little idea you have and put a day or two into it.
See how things feel in VR.  You'll be surprised at what fails and even more surprised at what's a giant hit.

Downloads - Get the Games now!

If you'd like to try out these games yourself, you're in luck!  They're all freely available for download right now!

Thinking about building your own VR game?

After building these 7 prototypes, I went full in and built 6 full games for the HTC Vive & Rift that are selling on Steam now.  If you're considering building a VR game of your own and want to get a head start on the process, give my VR Game Development course a test run.

 

 

 

 

 

Continue reading >
Share

VR / VIVE Games – Day 6 – StackEm Quick [Includes Source]

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.htc-vive-steam-vr-logo

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).

StackEm Quick - GameStateManager

Falling Object

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

StackEm Quick - Player Hand

The hands are used to pickup blocks.  Pitching - CollidersThey’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.

StackEm Quick - Camera Rig

 

 

 

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.  StackEm Quick - Invisible Walls SceneThere are 6, they block stuff from falling, that’s all.hich case we don’t need to do

StackEm Quick - Invisible Walls

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: ????

 

Continue reading >
Share

VR / VIVE Games – Day 5 – Baseball – Pitching

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.htc-vive-steam-vr-logo

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
Pitching - Camera Rig Pitching - Colliders - SceneView Pitching - Colliders Pitching - PlayerPitcher Script Pitching - Swing Area

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.Pitching - PlayerPitcher Script

 

Falling Object

Strike / Ball Areas

Pitching - Colliders

Ball Trigger Areas with Colliders Visible


Pitching - BallTriggerAreaBefore 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.

Pitching - Colliders

 

 

 

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: ????

 

Continue reading >
Share

VR / VIVE Games – Day 4 – Candy Catcher

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.htc-vive-steam-vr-logo

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.

 Zombie - Spawner

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
Falling Object

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.

Falling Object

PlatesCamera Rig

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

Object Spawner

Object Spawner

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: ????

 

Continue reading >
Share

7 VR / VIVE Games – Day 3 – Zombie Shooter

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.htc-vive-steam-vr-logo

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.

Zombie - Spawner

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

Zombie - GunZombie - Gun

Zombie – Gun

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.Zombie - CameraRig

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.

Zombie - Animation Controller

Zombie – Animation Controller

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

 

Continue reading >
Share

7 VR / VIVE Games – Day 2 – Archery

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.htc-vive-steam-vr-logo

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)Scene View

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.Archery - Hierarchy

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).

Archery - Bow InspectorArchery - Bow Inspector

Archery – Bow Inspector

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

Moving Target

Moving Target

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

 

Continue reading >
Share
Page 3 of 4