Seasick Games Development Blog

Unity and simple waypoints

Unity again! Yesterday I tried to make my player gameObject to follow specific waypoints. I have published the code at GitHub. Get it and Do What The Fuck You Want with it. I always wanted to release code under this license. Finally ^^

Code explained

It isn't much code, so it is easily explained. The UnityScript file contains two classes. First we will have a look at the Waypointer.

The Waypointer class has two public attributes

• speed ... The speed with which you gameObject will move
• scale ... The scale of the waypoint hitbox. It is needed to tell if your gameObject reached a waypoint

As you can see, the class also has a private attribute - queue. It will contain a Queue object. This object is basically a "First In First Out" list. We can add waypoints on top of the stack, and remove them from the beginning if your gameObject reaches a waypoint. Since this Queue object isn't imported in Unity by default, we need to do this our self.

In the Update function we are doing only one thing: Get to the first waypoint in the queue. Ok, it is a little bit more. We have to check if there is a waypoint, and we need to look into the direction of the waypoint. Here you have the chance to improve the performance of the script. It isn't necessary to set the rotation of your gameObject everytime - we could set it once we remove a waypoint (given that there is another waypoint in the queue).

There is also a function for adding new waypoints. As you can see, this function isn't called anywhere. You have to call this function when you want to add a new waypoint. That way you could use this UnityScript not only for your player gameObject - you could use it on any gameObject you like. Think about several selected soldiers ... Of course your collision detection between them has to be way smarter - atm there is none ^^

I called this method from another component. With this component I can click anywhere onto the screen, and a new waypoint is added. Have some code ...

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#pragma strict
 
function Update
{
  // Check if a new Waypoint should be added
  if(Input.GetKeyDown(KeyCode.Mouse0)) {
    var playerPlane = new Plane(Vector3.up, transform.position);
    var ray = Camera.main.ScreenPointToRay (Input.mousePosition);
    var hitdist = 0.0;
 
    if (playerPlane.Raycast (ray, hitdist)) {                
      var targetPoint = ray.GetPoint(hitdist);
      gameObject.GetComponent(Waypointer).AddWaypoint(ray.GetPoint(hitdist));
    }
  }
}

This AddWaypoint function will create a new gameObject with a BoxCollider. The public attribute scale will be assigned to the scale of the colliders transform. Also we will set the position and mark the collider as trigger. This way your gameObject won't bounce of it. After that we just enqueue the collider.

One important thing: We are also attaching the second class of this script to the collider. The Waypoint class. This class only has a OnTriggerEnter function which will check if the colliding object (normally your gameObject) has a Waypointer component on it. If so, it will use this component to tell it, that your gameObject has hit a waypoint.

And we are back in the Waypointer class. When your gameObject hit a waypoint, we just check if it is the first element in our queue. If so, we will remove it from the queue. Your gameObject will move on to the next waypoint.

Downsides

At the moment there are a few downsides to this approach:

• It is possible that this isn't working on your iPhone. I didn't bothered confirmed it yet, but Unity on the iPhone is only supported to a specific .NET compatibility level. Anyway - this has been a great opportunity to get into the .NET classes.
• It will only work on plane terrain - or at least it will look odd on bumpy terrain.

Improvements?

There is enough space for improvements.

• You could add a default prefab which will be used instead of the default collider. This way you could place something visible (and good looking) onto your screen.
• As mentioned before - you could tweak the performance a little bit.
• Add the ability to remove waypoints. Have a look at the Queue or implement your own FIFO list in pure UnityScript.

Unity and Mono/.NET compatibility level

Unity uses mono for all its magic. You can even import some .NET classes and use them in your scripts. It doesn't matter if you are using UnityScript, Boo or C#.

I haven't got into this topic very far, but you can set the API Compatibility Level in your projects settings (in Unity 3.5 you will find it in Player Settings > Other Settings). For me there are currently two entries

• .NET 2.0
• .NET 2.0 Subset

You can see on this page which features are supported in which level.

Unity: First steps

So I wrote yesterday evening about unity. After I published the post, I started to make a little Jump'n'Run. I think it is a good way to get to know unity, because it covers a wide range of needed features:

• Camera movement and controll
• Controlling "the player"
• Collision detection (unity does all the heavy lifting for you)
• Triggering death and finishing a level
  • Loading new levels on success
  • Reloading the level on death
• Collection points while running through the levels
• Animation (I animated the "coins" to bounce up and down)

What did I learn from this?

• When you want to do an animation on a prefab ("template" for assets) you need to create the animation on it, but you can only changes the values on an existing GameObject. Furthermore I noticed, that I needed the prefab to be contained into a parent. Otherwise the animation will work with absolute values, and all your GameObjects which inherit from this prefab, will be in one place (at least if you have a positioning animation). With a parent, the positioning will work relative to the parent. Took me a while to figure this out .
• The community is great, and seems to be very noobie friendly (as long as you care to search first)! Every question I got was asked before, no need to ask for myself
• Controlling the character takes a lot of time to tweak. And as you can see, I didn't managed to do it the right way. The controls are still a little bit blury.
• There isn't realy much coding.

Today I tryied out the building options - As you can see I attached here a build of the web player. Control your "character" with WAD (yeah, there is no S ), jump with space. It is a bit small, but it demonstrates how quickly you get something to show with unity.

There is surly enough space to polish this up, but it wasn't ment to be a finished game. Just something to learn from.

Next up ... maybe I'll try a breakout clone. I'm sure there is something to learn from

Unity 3D … My next challenge

Again ... no posting for a longer period. Yes, I'am kinda lazy Dispite my lazyness I manage from time to time to get my focus on some things. This time it is Unity 3D. You may be familiar with it - it is "just another" game engine.

But this one is special. Not only there is a free license for it, you can build your games for Windows, Mac, Linux (with version 4) and the web. If you are willing to pay, you can even build for Android, iOS, PS3, Xbox 360, Nintendo Wii and Flash. Pretty awesome right? But wait there is more! There are no anual fees or royalties per title!

Unity will make all the heavy lifting for you

• Rendering
• Lightning
• Terrain
• Physics
• Audio
• Networking

The editor itself is very user friendly. Not sure yet, but for coders maybe a bit too friendly I'm used to use my Keyboard a lot - with Unity I need my mouse more often than usual.

A killer feature is the ability to start the current scene you are working on directly from the editor. You can even tweak some attributes and make changes while playing.

Unity also comes with a asset store, where you can purchase things like models, materials, audio, scripts, particle systems, editor extensions or even complete projects.

I'm looking forward to create somthing I can publish again