Wednesday, July 17, 2013

Unity3D: Change a script's execution order dynamically (from script)

So the other day I wanted to make sure one of my scripts always ran first, to check in it's init if certain conditions have been met, and if not, do some actions.

I didn't want to rely on manually setting each scene's execution order, and if it's the first level, OnLevelWasLoaded won't get called (no idea why).

So my solution - Create an editor class that made sure that my script's execution order is always before everything else:

using UnityEditor;

[InitializeOnLoad]
public class ExecutionOrderManager : Editor
{
    static ExecutionOrderManager()
    {
        // Get the name of the script we want to change it's execution order
        string scriptName = typeof(MyMonoBehaviourClass).Name;

        // Iterate through all scripts (Might be a better way to do this?)
        foreach (MonoScript monoScript in MonoImporter.GetAllRuntimeMonoScripts())
        {
            // If found our script
            if (monoScript.name == scriptName)
            {
                // And it's not at the execution time we want already
                // (Without this we will get stuck in an infinite loop)
                if (MonoImporter.GetExecutionOrder(monoScript) != -100)
                {
                    MonoImporter.SetExecutionOrder(monoScript, -100);
                }
                break;
            }
        }
    }
}

Note: In order for this script to work it must reside in the Editor folder.

Sunday, July 7, 2013

Unity and the Singleton design pattern

Singletons are very powerful when used for managers in game, or anything in general which you know you will have exactly one of (Game manager, audio manager, for a pure singleplayer game - the player, etc)

If you are unfamiliar with the singleton design pattern take a moment to read about it (it's quite useful):
http://en.wikipedia.org/wiki/Singleton_pattern

I wanted to share my modified version of a singleton implementation I found for Unity (found here: http://wiki.unity3d.com/index.php/Singleton).

Since Unity expects MonoBehaviour class inheritance, static classes are out of the question, so a more Unity tailored solution was needed. This class ensures that when you check for it's instance, it will be there no matter what. You can later mark any class inheriting from this one as "Game static" and it will also live through all of your scenes.

using UnityEngine;
public abstract class MonoSingleton<T> : MonoBehaviour where T : MonoSingleton<T>
{
    public bool IsGameStatic;
    private static T _instance = null;

    public static T Instance
    {
        get
        {
            // Instance required for the first time, we look for it
            if( _instance == null )
            {
                _instance = GameObject.FindObjectOfType(typeof(T)) as T;
 
                // Object not found, we create a temporary one
                if( _instance == null )
                {
                    Debug.LogWarning("No instance of " + typeof(T).ToString() + ", a temporary one is created.");
                    _instance = new GameObject("Temp Instance of " + typeof(T).ToString(), typeof(T)).GetComponent<T>();
 
                    // Problem during the creation, this should not happen
                    if( _instance == null )
                    {
                        Debug.LogError("Problem during the creation of " + typeof(T).ToString());
                    }
                }
                _instance.Init();
            }
            return _instance;
        }
    }

    // If no other monobehaviour request the instance in an awake function
    // executing before this one, no need to search the object.
    private void Awake()
    {
        if( _instance == null )
        {
            _instance = this as T;
            _instance.Init();

            if (IsGameStatic)
            {
                DontDestroyOnLoad(gameObject);
            }
        }
        else (_instance != this)
        {
            Destroy(this);
        }
    }
 
    // This function is called when the instance is used the first time
    // Put all the initializations you need here, as you would do in Awake
    public virtual void Init(){}
 
    // Make sure the instance isn't referenced anymore when the user quit, just in case.
    private void OnApplicationQuit()
    {
        _instance = null;
    }
}
And later simply create the class you want to to make a singleton:
public class MySingletonClass : MonoSingleton<MySingletonClass>
{
    public void Foo() { ... }
}

Add the newly created component (MySingletonClass) to a gameobject in your scene and then you can safely call it from anywhere in your code, and assume that it was succesfully initialized.

MySingletonClass.Instance.Foo();

Notice: If you want to implement a custom Awake function for anything that inherits from MonoSingleton, you must override Init. If you create a new Awake function it will block MonoSingleton's awake function.

Tuesday, April 16, 2013

Tips and tricks collected for Unity3D game development #1

Hey everyone,
I've decided to write a post containing random tips and tricks I've found along the way for Unity3D development.

As a software engineer for over 14 years, I like to break apart each new development environment I get into - and Unity wasn't any different :)

So, here goes:


Dynamic, static and kinematic colliders

There are 3 types of colliders in Unity3D:
  1. Dynamic colliders - Used for collision detection for dynamic objects (enemies, bullets, boulders, etc) - the setup is pretty straightforward, a rigidbody is attached to a collider
  2. Static colliders - Used for collisions for anything that never moves in your level (level floors, walls, obstacles, etc) - these should only contain a collider without a rigidbody.
  3. Kinematic colliders - Used for collisions for anything that moves using code and not physics (moving platforms, elevators, etc) - these must have a rigidbody marked as kinematic with a collider.
Adding kinematic rigidbodies to kinematic colliders greatly improves performance  as moving static colliders around causes internal calculations every time you move them.
Kinematic rigidbodies solve this problem.

Everything that doesn't move, rotate or scale should always be marked static

This tells Unity that the object can be optimized for static batching - this greatly lowers active draw calls and removes a lot of calculations from the CPU.

Use Handles, Gizmos and Custom Editors

Gizmos are great to show custom logic inside the editor - for example, show the range an AI unit can spot the player (using Gizmos.DrawWireSphere for example), draw a movement path (DrawLine) and countless other scenerios.

Handles are terrific to help you edit custom properties visually on your game objects.
For example, using Handles.PositionHandle to move around a target, RadiusHandle to edit a radius for an AI unit, etc.

Custom Editors will make your life incredibly easier when used on medium-large scale projects and the possibilites to using them are endless.

MonoBehaviour's built-in properties

Recently I've used Unity's Pro profiler, and changing a class that accessed MonoBehaviour.transform about 3 times every frame - calling MonoBehaviour.transform/collider/renderer/etc is equivellant to using MonoBehaviour.GetComponent - which isn't too efficient if you use them often.

Instead, define a private property inside your class, store the required component there, and later access it directly.

Doing this, dramatically improved frame cost for that class.

In general: Don't use Unity's GUI functions

Unity's GUI functions are very costly and should be avoided at all costs.
Instead, use a 2D framework (NGUITK2DEX2D, etc) that projects all GUI into a 2nd camera, which has a higher depth and has it's clear flags set to none.

This way you will enjoy the benefits of dynamic batching, higher performance and scalable GUI on an orthographic camera.

---

So that's it for today, I hope my tips will help someone out there.
Drop a comment if you have any ideas, feedback or find any mistakes that I've posted.

Cheers.

Sunday, April 14, 2013

Hello world! (Or why you should always keep your drivers up to date)

Hello world! (Or why you should always keep your drivers up to date)

Hello everyone,
I have no idea how you stumbled upon my blog, but I'm a game developer and designer. Hi.
I've created some quasi-famous browser games, and several less famous ones for Facebook/Mobile.

I work in a small indie studio and develop several games - currently I'm mainly working with Unity3D (Which is a great middleware for quick game development).

I hope to provide useful information, weird tricks and tips and in some random thoughts and ideas regarding gaming, game development, programming and design.

For my first post - I have a completely irrelevant post to gaming, and it is more technical.
After more than a year of having network issues in my PC (single threaded downloads get cut off about 90% of the time, including streaming videos) - I have solved the issue today, making myself feel very stupid along the way.

The problem went about as the following:
  1. Downloads using browsers would almost always get stuck midway (without the ability to resume)
  2. Streaming videos would get stuck and wouldn't buffer, and I had to forward the video to re-buffer it
  3. Several games would kick me out every now and then, and I'd had issues connecting to them

If anyone has encountered this issue, the solution is so simple it brought me to tears:
  1. Google your network adapter (can be found in the device manager)
  2. Find appropriate drivers for it
  3. Download & install

Boom - that fixed it for me. I just had to share this with the world, in case I even help out another helpless soul out there, I did my job.

I'll write a few posts here, hopefully more relevant to game development.

Cheers.