As I said on a previous post, it is very common for Unity3d developers to come up with the idea of a game object in their scenes that will hold components that will act as singletons, right?

Normally we want this game object to be there from the beginning, make some initialization (such as finding entities in the scene) and then be ready to handle our requests. Also, we would like this game object to be persistent so we would like to call DontDestoyOnLoad(this); on it. This approach works very well if you have a single scene in your project as everything is running on the same context, but if you have multiple scenes, say, multiple levels in your game, things can get complicated. Suppose you have a component attached which purpose is to find the most used entities in your game (such as the player) and cache them, allowing other components to access them with a static variable. The problem with multiple scenes arises if you change scene and don’t update the references to your cached game objects.

I’ve using a slightly different approach that threats the whole system as a FSM (Finite State Machine). Let me exaplain:

The first idea is to create a static class that will hold a reference to any manager we have in the game, for example:

[RequireComponent(typeof(GameManager))]
[RequireComponent(typeof(ScreenManager))]
[RequireComponent(typeof(AudioManager))]
[RequireComponent(typeof(MissionManager))]
public class Managers : MonoBehaviour
{
    private static GameManager gameManager;
    public static GameManager Game
    {
        get { return gameManager; }
    }

    private static ScreenManager screenManager;
    public static ScreenManager Screen
    {
        get { return screenManager; }
    }

    private static AudioManager audioManager;
    public static AudioManager Audio
    {
        get { return audioManager; }
    }

    private static MissionManager missionManager;
    public static MissionManager Mission
    {
        get { return missionManager; }
    }

	// Use this for initialization
	void Awake ()
    {
        //Find the references
        gameManager = GetComponent<GameManager>();
        screenManager = GetComponent<ScreenManager>();
        audioManager = GetComponent<AudioManager>();
        missionManager = GetComponent<MissionManager>();

        //Make this game object persistant
        DontDestroyOnLoad(gameObject);
	}
}

As you can see, we have a bunch of things that will let us access those Managers easily, as easy as:

Managers.Audio.Play(transform.position, clip); 

Obviously, those components (like the AudioManager) must be attached to this game object in order for this to work. The idea behind this managers is that they will be “always ready”, like a system service, and that they don’t have any dependencies with any particular scene. For example, the AudioManager is able to play sounds in any scene and situation.

There are other types of managers, those that rely on a particular scene or state in order to work. There is also the problem of the global game state. Introducing your awesome GameManager class:

public class GameManager : MonoBehaviour
{
    private GameState currentState;
    public GameState State
    {
        get { return currentState; }
    }

	//Changes the current game state
	public void SetState(System.Type newStateType)
    {
        if (currentState != null)
        {
            currentState.OnDeactivate();
        }

        currentState = GetComponentInChildren(newStateType) as GameState;
        if (currentState != null)
        {
            currentState.OnActivate();
        }
	}

    void Update()
    {
        if (currentState != null)
        {
            currentState.OnUpdate();
        }
    }

    void Start()
    {
        SetState(typeof(GameplayState));
    }
}

And it’s loyal companion, the GameState abstract class:

public abstract class GameState : MonoBehaviour
{
    public abstract void OnActivate();
    public abstract void OnDeactivate();
    public abstract void OnUpdate();
}

Those classes make up a simple FSM system for the different game states in your game (paused, playing, menu screen, etc.). You should inherit the GameState class to provide your custom states. A state is also a component attached to a game object that is responsible for activating/deactivating each game manager that is dependent on that particular state. For organization, I suggest you attach your states to game objects with the name of the state that are childs of the manager game object, like this:

Manager object distribution

This way, you can have sub-managers attached to this child objects and everything is perfectly organized.

Hope you find this useful. I will post more information about this soon.

You know, sometimes very simple code has to be written again and again by lots of different people to solve the same basic problem. I think playing audio is one of such cases in Unity3d.

You have the audio components: AudioSource (attached to your sound emitter) and AudioListener (attached to the main camera). Now, the problem is that audio clips are represented by the AudioClip class, and each AudioSource can have a single AudioClip playing at the moment. That is sometimes ok, but other times, you want your game object to be able to play a number of different sounds, maybe at the same time (Think of a character playing footsteps sounds and maybe saying something at the same time).

Since it is very natural to have one manager object in your scene acting as a singleton, I’ve written a component that can be attached to such manager. The work of this component is to play almost any sound you want to play in your game. The code is very simple and self explationary.

// /////////////////////////////////////////////////////////////////////////////////////////////////////////
//
// Audio Manager.
//
// This code is release under the MIT licence. It is provided as-is and without any warranty.
//
// Developed by Daniel Rodríguez (Seth Illgard) in April 2010
// http://www.silentkraken.com
//
// /////////////////////////////////////////////////////////////////////////////////////////////////////////

using UnityEngine;
using System.Collections;

public class AudioManager : MonoBehaviour
{
    public AudioSource Play(AudioClip clip, Transform emitter)
    {
        return Play(clip, emitter, 1f, 1f);
    }

    public AudioSource Play(AudioClip clip, Transform emitter, float volume)
    {
        return Play(clip, emitter, volume, 1f);
    }

    /// <summary>
    /// Plays a sound by creating an empty game object with an AudioSource
    /// and attaching it to the given transform (so it moves with the transform). Destroys it after it finished playing.
    /// </summary>
    /// <param name="clip"></param>
    /// <param name="emitter"></param>
    /// <param name="volume"></param>
    /// <param name="pitch"></param>
    /// <returns></returns>
    public AudioSource Play(AudioClip clip, Transform emitter, float volume, float pitch)
    {
        //Create an empty game object
        GameObject go = new GameObject ("Audio: " +  clip.name);
        go.transform.position = emitter.position;
        go.transform.parent = emitter;

        //Create the source
        AudioSource source = go.AddComponent<AudioSource>();
        source.clip = clip;
        source.volume = volume;
        source.pitch = pitch;
        source.Play ();
        Destroy (go, clip.length);
        return source;
    }

    public AudioSource Play(AudioClip clip, Vector3 point)
    {
        return Play(clip, point, 1f, 1f);
    }

    public AudioSource Play(AudioClip clip, Vector3 point, float volume)
    {
        return Play(clip, point, volume, 1f);
    }

    /// <summary>
    /// Plays a sound at the given point in space by creating an empty game object with an AudioSource
    /// in that place and destroys it after it finished playing.
    /// </summary>
    /// <param name="clip"></param>
    /// <param name="point"></param>
    /// <param name="volume"></param>
    /// <param name="pitch"></param>
    /// <returns></returns>
    public AudioSource Play(AudioClip clip, Vector3 point, float volume, float pitch)
    {
        //Create an empty game object
        GameObject go = new GameObject("Audio: " + clip.name);
        go.transform.position = point;

        //Create the source
        AudioSource source = go.AddComponent<AudioSource>();
        source.clip = clip;
        source.volume = volume;
        source.pitch = pitch;
        source.Play();
        Destroy(go, clip.length);
        return source;
    }
}

As you can see, this class is basically 6 overloads for the Play function. Basically we have two types: the type that takes a transform (emitter) as parameter and the type that takes a Vector3. The only difference is that if you provide a point (Vector3), the sound will be played there, but if you provide an emitter, the sound will be played where the emitter is, but will also follow the emitter as it moves (e.g. the engine of a passing car).
Hope you find it useful!
By the way, I’m planning on creating on tutorial on how to create Manager systems. By that I don’t mean simple components like this but rather the best way I have found to create such a Singleton object with those components, and how to integrate that with your game when you have multiple game states and game scenes (with potentially different managers). More on that soon.

Last year I had the pleasure of working on Oken, a game that was supposed to released this January. It is a classic sidescroller with a couple of interesting game mechanics that got canceled. A canceled indie game project, here is the story:

Lune and I decided that we needed to create games ASAP, indie games. We knew that we weren’t going to create the next GTA, but we wanted to create, to be able to show something we have done, something to be proud of. We started Oken out of an old idea back in my days at 3dmx. We had a project there called PreyInsight (please look here, all the art is Lune’s), we always liked the idea of creating a game  of a tiger, so we redesigned the idea from scratch, created our main character and decided to create a game. We invited 3 of our students to join the team, Carlos for the art department (guided by Lune); Alan and Adrian for programming (guided by me) and the Dorian, our sound designer/composer.

The Oken team:

• Lune (http://lunecheetah.deviantart.com/)
• Alan Gaspar
• Adrian Gil
• Carlos Junior Ramirez
• Dorian Mastin (http://www.dorianmastin.com/)
• Daniel Rodríguez ( that’s me! )

We also had the help of  Netic (Ernesto Ruiz Velasco, http://netic-ck.deviantart.com/) who created some 3d assets for the game. Great job!

All the assets I am sharing here were already shared on the Facebook page for the project. You cannot imagine the amount of artwork created by Lune and Carlos for this game (enemy concepts, 3d models, millions of textures, even powerpoint presentations), but I think it’s their choice if they want to publish them (and where). Of course this space will always be open for them.

Dorian created awesome music for this game too! Please listen to the Oken Menu Theme. He also created ambient sounds for the first level, among other great sound assets.

The game was being developed using the Unity3d game engine, a great software for game development. We decided to use it because it was cheap (now it’s free) and because we knew it very well. We created great code too, including a character state manager system and a camera interpolation system (yes, we will be sharing the code with the world very soon).

So, the interesting question is: Why is Oken canceled?

It is difficult to answer.

I’ve been thinking of this for a very long time now. I can only think of one think that wen’t wrong: Our people skills. Lune and I were trying to get things done, we wanted to create a great game. Nonetheless, I believe we were unable to provide all the support the team needed as we were full time workers and Oken was only a hobby project. The team slowly loosed it’s energy, it’s will, and it’s professional perspective. We let personal stuff get in the way and at the end, it was impossible for us to work on this game. We decided that our friendship was more important, so we paused the project. A couple of months later I wanted to start developing again, but the the team was way to busy on other stuff (great stuff, like the short film Junior is preparing).

This teach me a lot.

I now want to share how the game looked like in it’s final stage. We made 2 builds, the first one is a test level designed to test and tune Oken’s movements, the second it’s our first level (on a early stage, it needed a lot of tunning).

Oken movement test level

Oken first level

(Move with arrows, attack with “z” (early combat implementation))

Please note that the game was never optimized for the web and that it really is in a very early stage. Still, you can see that the movement of the character works great. Oken was supposed to have combos and the game mechanics included an “aura system”.

All of our work behind the game can be seen on the public Assembla site for Oken. As you can see, we created a lot of documentation for the game (we were going for the real thing!). The wiki contains detailed information about the game mechanics and there are some visual assets there too!

It is very sad that Oken didn’t really worked out as we expected, but, the story won’t end there. Every single member of the Oken team is working on new great stuff. While Lune has a lot of projects (too many to list them here), Carlos is working on that short film, Adrian and Alan are working on the adaptation of their game Amnesia to the Unity engine, I am working on another game for the web with a couple of friends (new team). The game is gonna be announced on this blog very soon.

I hope the story of this project is useful to someone else. We need to always remember that the technical issues of a project can always be solved, but what really destroys projects is the lack of communication and time. The people needs to feel great working on the project, they must be motivated, and it’s everybody’s job to keep it that way. Never forget about the people you are working with.

This is how the tool looks like

Hello. I’ve been working on a set of four tools to aid in the Unity3d development. After using Unity for a while I encountered the classic problem of needing to copy the position of an object over and over. This led me to create the “Copy” tool. I’ve found a similar script on the Unify community, but I wanted to extend the tool. It is now possible to copy position, rotation and scale of any axis you want. Also, the values apply to all objects selected in the scene.

After that, and inspired by the tools I found on the Gamebryo Lightspeed editor, I created the Randomize and Add Noise tools. Those tools work almost the same, the randomize the position, rotation of scale of any object selected (or all objects selected). The difference is that while Randomize sets the absolute values for position, rotation or scale, Add noise adds a delta to the current value of the transform. This is useful for example to randomize the Y rotation of all the trees in your level, or to make a bunch of boxes look more natural by not being perfectly aligned.

Finally, after been learning Autodesk 3ds Max, I created the Align tool inspired by a tool in that software. It basically takes a source transform, just like the Copy tool, then uses it’s collider and the collider of the object (or objects) selected to align it. You can align for example, the minimum point of your selection with the maximum point of your source (what you are aligning to) to place an object over another. It let’s you align using the minimum point, maximum point, the center of the object or the pivot point on both the selection and the source. You can align on all 3 axis.

To use these tool, all you need to do is download the script file, and add it into a folder named Editor in your project’s Asset folder. Once compiled by Unity you find the new functionality in Window -> TransformUtilities, or simply press Ctrl+t (Cmd+t for Mac users)

Developed by Daniel Rodríguez (Seth Illgard) in January 2010

Download TransformUtilities!

Hope you find them useful, and please let me know how can I improve theses tools.

Coroutines in C# work the same way that they do in Javascript (UnityScript), the only difference is that they require more typing (they have a slightly more complicated syntax). You should see the blog post on Javascript coroutines first.

Here, I present the differences:

Coroutines must have the IEnumerator return type:

IEnumerator MyCoroutine()
{
	//This is a coroutine
}

To invoke a coroutine you must do it using the StartCoroutine method:

public class MyScript : MonoBehaviour
{
    void Start()
    {
		StartCoroutine(MyCoroutine());
    }

    IEnumerator MyCoroutine()
    {
        //This is a coroutine
    }
}

The yield statement becomes yield return in C# :

IEnumerator MyCoroutine()
{
    DoSomething();
    yield return 0;	//Wait one frame, the 0 here is only because we need to return an IEnumerable
    DoSomethingElse();
}

Remember that we need to return an IEnumerable, so the Javascript yield; becomes yield return 0; in C#

Also, since C# requires you to use the new operator to create objects, if you want to use WaitForSeconds you have to use it like this:

IEnumerator MyCoroutine()
{
    DoSomething();
    yield return new WaitForSeconds(2.0f);	//Wait 2 seconds
    DoSomethingElse();
}

Happy coroutining

I’ve been working with Unity3d for some time now and I couldn’t really make good use of the coroutines because I was unable to truly understand them. After some time playing with them and making some experiments I realized their true power. I couldn’t believe what I was missing! So, a couple of fellow game devs asked me to explain the concept to them. I decided that a blog post was the perfect way to do it and, at the same time, share this with everyone.

Coroutines: Special type of functions(in the programming sense) that allows to stop it’s own execution until certain condition is met.

A coroutine looks like this (on javascript, the C# version is here):

function MyCoroutine()
{
	DoSomething():
	yield;                         //Mystery here
	DoSomethingElse();
}

When you invoke this function (start the coroutine) it will behave just like any other normal function you have ever seen, until it reaches the yield instruction.  The yield instruction explained: The yield instruction works like a return statement in the sense that it stops the execution of the function and returns control to the code that invoked that function. The main difference is that the yield instruction lets you delay the execution of the code that is after it (in the last example, the DoSomethingElse() statement).

function MyCoroutine()
{
	DoSomething():			//Do this immediately
	yield;                          //Return control to the caller
	DoSomethingElse();		//This will be executed one frame later
}

void Start()
{
	MyCoroutine();
}

What happens if you have more code after the MyCoroutine call? Let’s see an example with some prints:

function MyCoroutine()
{
	print("This is printed second");
	yield;    	//Return control to the Start function
	print("This is printed one fourth, exactly one frame after the third");
}

void Start()
{
	print("This is printed first");
	MyCoroutine();
	print("This is printed third");
}

You can control when do the code after the yield instruction will be executed. It depends on the parameter of the yield instruction, according to the following table

Nothing: It will wait one frame
Another coroutine invocation: It will wait until the invoked coroutine finishes execution
A WaitForSeconds object: It will wait certain amount of time

Confused? Here are the examples:

function MyCoroutine()
{
	DoSomething():				//Do this immediately
	yield WaitForSeconds(2);   	//Return control to the caller
	DoSomethingElse();			//This will be executed 2 seconds after
}

void Start()
{
	MyCoroutine();
}

function MyCoroutine()
{
	DoSomething():				//Do this immediately
	yield MyOtherCoroutine();   //Go and execute MyOtherCoroutine!
	DoSomethingElse();			//This will be executed after MyOtherCoroutine finished execution
}

function MyOtherCoroutine()
{
	DoStuff():				//Do this immediately
	yield WaitForSeconds(2);   	//Return control to the caller (in this case the Start function)
	DoMoreStuff();			//This will be executed 2 seconds after
	//MyOtherCoroutine finishes execution here
}

void Start()
{
	MyCoroutine();
}

As you can see, coroutines are very powerful and easy to use once you understand how they work. I will post some usage examples and the C# version of the scripts on this post soon.

Today I was invited to the UVM University to give a workshop on game development using Unity3d. For that purpose I created a small presentation that you can find in pdf format here: Introduction to game development and Unity3d.

It is a very basic introduction, but I hope you like it.