Chapter 6. Wow. Now that was a doozy. Tons of code, a new model, rigidbodies, hurling things, instantiating more things. Just wow. Lots to take in.

We started off with rigidbodies. Rigidbodies are objects that Unity’s Nvidia PhyzX will run physics simulations on, in our case a coconut. We make this coconut exactly 1 kilogram (2.2 pounds for the yanks) and shape it into an elongated oval. Then we get to the fun part, HURLING things! We build a gameObject that’ll spawn a new coconut everytime you throw one, just so you’re never empty handed. We check the players input and everything he lets UP on the leftmouse (or left ctrl) the coconut will be thrown forward with a force of 25.

You’ll have to bear with me, there is a lot of code in this chapter, so a lot of oversimplification.

Now, obviously we can’t just let the player throw everything around everywhere (like in the hilarious, HILARIOUS earlier demo)  because it bogs down the machine to be running 250 different coconuts physics. So alas, we both limit WHERE the player can throw, and how long a coconut may exist in this world. We do so by establishing that unless the playercollider is touching the mat portion of the minigame platform, he cannot throw. To destroy the coconuts we simply use a script that sets them to destroy after 5 seconds. Poor things.

So now we add the actual game play. A target shooting game to win one of our batteries. We make some targets, and set them to fall over if they come into collision with a coconut object. When that happens they’re triggered to play their falldown animation, and increment a hidden counter to see if all 3 targets are over. After a few seconds they pop back up, decrease the counter, and so on and so on. When the hidden counter reaches 3 (aka, all 3 targets are knocked over) then we go ahead and spawn a fantastic battery.

Like I said, it’s a very technical chapter. Hard to put into plain english. I can only hope you gathered half of what this chapter entailed from that summary. As usual, questions can be asked in the comments, on my twitter, or at my email.

Here’s the demo:

Click here for chapter 6 demo!

p.s. I also figured out how to convert .X models to .FBX, that’s what the other building is. Also started just cel shading a few objects for kicks. Also, no idea why most things are set up as fullbright, I blame the sun as being too strong but I need to set the settings weird just to get the Unity Editor to run on my ancient video card, so bear with me.

Wow, this is a lot to take in from just one chapter. We’re going to be adding a collection aspect to opening the door, a hud for the player to see what he needs, and some text hints if he’s just plain dumb.

Here is probably the most important piece of code I had to add this past chapter. If you run into an object tagged as ‘battery’ then:

1. Let the game know you picked it up by increasing your charge level.
2. Play a Sound to reinforce to the play that he picked a battery up.
3. Get rid of the battery.

From there it’s just a simple series of if statements (I haven’t found the Unity case statement yet. Ug.) telling the game to draw on the hud as we collect the batteries.

GUITexture is just the unity class for.. well.. gui elements in the form of textures. There is also GUI Text which we use to display text to the player, as seen in this chapter in the form of the ‘hint.’

Ok well enough of that. I guess if you have any questions, then comments are open, twitter is on the side, and my email is in the corner. Here’s this chapters demo. The goal is: Try to get in the outpost.

New features! Click here for demo.

Last time we looked at opening the door using collisions. Hey, that’s cool for some people! You aren’t wrong to do that! Or maybe you are, because raycasting uses up a bunch less CPU power. Where a collision is checking the players whole gosh darn capsule to see if it’s hitting, the raycast sends out one itsybitsy point in 3d space (a line actually) and checks that instead.

Here’s the only code we had to change:

Not too shabby, eh? First we establish a variable to hold the name of whatever the ray is hitting. Then we actually cast the ray 5 meters in front of the player. If the tag of whatever our ray hits is the same as our door, then it’s going to go ahead and play the opening animation and sound.

And even though I was nay-saying collider detection earlier it still definitely has its place. This ray will only ever hit in front of the player. What if he walks backwards over an armor or health pack? Boom, collision detection will allow him to pick it up. They both just have their own place.

So here’s the ray caster demo, try it alongside the collision demo and you’ll almost immediately see a difference.

Our door's collider is now much smaller. Click for demo!

Chapter 4 is when we actually get our hands dirty with some of that basic coding we learned in chapter 3. Our primary task is to get the door to the outpost open, and to do that we need to use scripting.

Part one of the chapter has you doing this via direct contact with the doors collision box, part two deals with drawing a ray. Both are relatively simple to perform and function differently from each other, so I decided to break the post up into 2 parts so that people could see the difference in action.

So, have a look at this code.

Firstly, we call a function to check if our player (ControllerCollider himself!) hit the door. We do this by passing the tag of the last object his collided with and then checking whether or not that was the door in question. If it is, and if the door isn’t already open, then go ahead and and open it. We pass a few vars to a Door function (which sound to play, set whether the door is open or shut, which animation to play, and to what to play it) and boom goes the dynamite, the door opens.

Here you can see the doors collision box. Click to try it out.

You may have noticed the blog went dormant. Yeah. I don’t know what to say. I lost my motivation for a while BUT IT’S BACK BABY HA HA YEAHHH. Lets all calm down a bit and discuss what that means.

It means I’m going back to that tutorial book and not going off to make some stupid awful game before I’m educated on exactly how to do that. Putting the carriage before the horse isn’t exactly the best Mission Statement I’ve ever heard.

So here we are, back to chapter 2 of the book. I’m going to do a MINIMUM of 2 of these per week, make sure you contact me if that doesn’t happen. I may be dead, nay, I must be. This time I’m doin’ it right.

Chapter 2 of the book involves mastering the terrain editor of Unity. Since the last time I blogged about actually using Unity, Unity3 has been released. Fortunately the editor remains mostly unchanged as far as the basics go. We are tasked with making a basic island, volcano, putting trees on it, planting grass, cuing sounds, making the sun, and inserting a player.

Click me to be taken to the demo! (4mb Unity Webplayer)

If you have any questions involving how these tasks were performed then you’ll find I have added my twitter information to the side bar of the page. Feel free to contact me!

Here is the first entry I suppose: HELLO WORLD (IN UNITY!)

A simple terrain, skybox, cube, light, camera, and a GUI text component. Basic stuff, childs play at best. This is step one boys and girls, a month from now compare this most basic demo to what I’ll be putting out!