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.

Some time ago I found this amazing video on game mechanics design by Will Wright, creator of The Sims franchise, SimCity and Spore, talks about game design principles. I like this because it really gave a lot of perspective in my game design experience. I like the way he connects the concepts and the way he uses metaphors to explain them. In particular, the definition of the possibility space for the player helped me as I started involving myself with game design.

I think it’s worth sharing, and by the way, I really think this video is much much better that the TED talk he gave.

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.

This is an post I made some time ago on my personal blog, and I wanted to share it here:

Are you a going to become a game developer???
I want t be a game developer.

As simple that statement is, there are a lot of issues involved:

• Am I an artist? A coder? A game designer?
• What kind of games do I want to develop? Casual games? Hardcore games? Mobile games?
• How much experience do I have? A year? A released AAA title? Several flash games on the net?
• Do I have a demo reel? Can I show some of my work in a released title?
• These 4 simple questions should be answered to truly fulfill the minimum expectations of a gamedev studio:

Am I an artist? A coder? A game designer?

You need to be one of these, like it or not. Conceptual artists are ok if you are very talented. Sound designers, well, we can count them as artists. These 3 are the main branches of the development of a game: Art, Technology and Game design, and you need to be talented in one of these 3. If you just like to play video games, well, go play somewhere else.

What kind of games do I want to develop? Casual games? Hardcore games? Mobile games?

Casual games? Ok, go grab Unity3d , Flash, or even DXStudio .
Hardcore games? Learn every single dark corner of C++ and 3D libraries, or become the god of texturing or rig animation. You will need to SPECIALIZE! That’s it, become a superhero of whaterver you want to be. Be the best out there.

How much experience do I have? A year? A released AAA title? Several flash games on the net?

Experience is a huge deal. Every studio out there is asking for talented people with 2 years of experience in the industry. How are you supposed to do that? Make casual games! Start small and grow up. Find some friends and start modding other games (Valve’s games are great for this). If you are a coder, write some 3d or AI libraries (whatever you like), show the world what you can do.

Do I have a demo reel? Can I show some of my work in a released title?

You’ll need one of these. The idea is to FINISH SOMETHING! If you are building 35 games at the same time on not a simple one is finished, nobody will want to hire you. If you are an artist, pack you stuff together and build a sample video (demo reel). If you are a coder, make a COMPLETE game. Even simple games like a tetris remake counts, but make sure it is complete. Studios will want to hire people that are capable of finishing things. If you don’t believe me , just go and check out the Duke Nukem Forever story and you will understand why this point its so important.

Hope this tips help someone.

Last month Walter Rottenberry came to Guadalajara to teach us about the very basics of game development. As usual, let me share my notes:

AI:

• Tips from Steve Rabin in “Game Programming Gems 2″
• Use event driven behavior rather than polling
• Reduce redundant calculations
• Centralize cooperation with managers
• Run the AI less often
• Distribute the processing over several frames
• Employ AI LODs
• Solve only part of the problem
• Do the hard work offline
• Use emergent behavior to avoid scripting
• Amortize costs with continuous bookkeeping
• Rethink the problem

Game Theory:

• Prisoner dilemma
• Types of challenges
• Implicit vs explicit
• Perfect vs imperfect information
• Intrinsic vs extrinsic knowledge
• Pattern recognition

Level design:

Level designer responsibilities:

• Create terrain
• Create the rooms
• Add props
• Add triggers
• Look great
• Make it work

Technical limitations:

• The platform
• Affects how the level should be built (not the level itself)

Main factors:

• Memory
• Processing power and frame rate
• Level performance
• Polycount
• Lighting
• AI
• Media format
• Target and minimum specifications

GPUs take care of the eye candy in the game
Special effects consume a lot of processing power instead of RAM
Performance:

• Fast moving games require faster frame rate
• Level designer should be aware of strain on GPU and not frustrate for that

Polycount:

• What really matters is the number of polygons seen on the screen at any given moment
• Contributors
  • Too many characters in a single space
  • Special effects (smoke, falling leaves, fire, a black hole, etc)
  • Emmitters need to be watched closely
• Use LODs (Level of detail)
  • Characters: 3 LODs
  • Objects: 2-3 LODs
  • Environments: distances vary depending on level and game

Lighting:

• Lights and shadows both pulls on the GPU
• Dynamic lights are cool but expensive
• Traditionally had static lights
• Lights and shadows can be baked into textures

Game metrics:

• Happens after the player metrics are known
• Properties of the main character are the biggest factor
• Examples:
  • Height and width
  • Walk and run speed
  • Jump distance
  • Jump height
  • Interaction distance (how far the player needs to be from an interactuable object to interact with it)
• Character metrics
  • The visual size is different from the collision size
  • Use collision volumes
  • Make doors and corridors slightly bigger than realistic proportions
• Warning: Beware the game designer who gives you a ballpark figure for vital game data
• Get hard data before creating the level
• Level designer should decide the movement speed and jump metrics

Tips:

• FaceFX for facial animation
• Use cell diagrams (also called bubble diagrams) for gameplay

Thank you Walter. This was very useful.

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

Last month I had the pleasure of finding a new friend in the gamedev community: Ian Masters, a senior game programmer at Sidhe Interactive, creators of the Speed Racer game for Nintendo Wii and Sony PlayStation 2.

While he was in town I managed to compile a list of game development facts and tips. Here they are:

Programming:

• Everybody creates their own internal technology to build games. They modify engines and create frameworks for internal use.
• The technical director is the responsable of selecting technology like the game engine.
• Developing a game engine from scratch could take years and it’s not recommended.
• The most used languages in game development are : C++, Lua and Python.
• It’s common to have a prototyping team.
• Use source control (SVN, mercurial, etc.)
• Have all your projects into a solution, prefer that to link against static libraries (including third party code).
• Have your engine’s source code in your source control system so you can modify it and the changes will propagate.

QA:

• Unit testing is very important (specially for math libraries and core functions).
• Regression testing is important too.
• QA team is different from playtesting. QA test QA, playtesters test fun.
• No QA guys in multidisciplinary teams.

Art:

• Conceptual art should be delivered as soon as possible before programming start (at least a month ahead).
• Work on iterations.
• Artists hate naming conventions.
• It’s not easy to convince the artists to follow naming conventions (normally you need a producer to talk to them).
• Having a lead artist who follows naming conventions is crucial.
• Try to integrate audio as soon as possible. Audio is not a luxury.
• Post effects are often decided between the post effects coder and the art director.
• Camera effects are often decided between the camera scripters and the designers.
• Have metrics with the export tools (poly counts, texture sizes, bone count, etc)
• Should present a visual target.

Design:

• They can’t account for everything.
• Design document should be as detailed as possible.
• Design document should be a live document.
• They define tunable properties.
• Normally use XML files for tunable properties (exported from spreadsheets for extra awesomeness).
• There are co-designers (scripters).

Production:

• Producer’s work is to assure work is being done and cycles are running smoothly.
• Wikis are awesome.
• You can manage a whole project documentation using exclusively a wiki.
• Procedures, knowledge and project management all fit into a wiki.
• Multidisciplinary teams are a great way to work.
• Have a list of features that need to be tested on the prototype.

Recommendations:

• Scrum is the way to go.
• Use Scrum properly.
• Scrum meetings in the mornings.
• Put scrum plans on the wiki.
• Create tickets on Trac or a similar tool.
• Keep things visible and transparent.
• Read a lot. Be proactive and an active learner and problem solver.
• Try to work as close as possible with artists, programmers and designers.
• You need a published title to get into the industry. To get that title you need to be in the industry. Indie titles are a good way to break into it.
• Prototype as soon as possible.

Hope that helps, and a big “Thank you” to Ian for his time with us. I learned a lot.

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.

Programmers tend to think in the Object Oriented Programming paradigm all the time. We create complex class hiercharies that describe every single entity on the game. Thats what we learn at school, we are programmed (deeply into our firmware) to do that, but there is a whole world of different pradigms and approaches we can use, and the scripting languages are bringing the dynamic style into the game.

Functional programming can be great for game scripting, Lua has beeen a very popular game scripting language for a very long time, and a bunch of game engines uses it (including CryEngine 2.0 and Gamebryo LightSpeed). The ability to attach properties and functions into an object at runtime, for example, is incredibly useful to create high level game logic and even artificial intelligence.

We can talk about dynamic languajes and their benefts here, but I want t focus on Mixins as the modern approach to game entity description:

Mixins are chunks of functionability that can be applied to game objects. You can think of them as little pieces (building blocks) that you use to create a complex game entity. The most basic mixin every game entity is the entity’s transform which defines its position, rotation and scale. Each game engine implements entity’s transform in a different way, but the concept is the same.

Mixin complexity can vary from a simple mixin that lets you name an object (holds a string identifier), to very complex mixins like the one that provides characters the ability to use pathfinding to navigate the scene.

Each engine handles mixin agreggation in it’s own way, some engines even let you use multiple inheritance with mixins. Please note the difference between mixin inheritance and mixin agreggation:

• Inheritance:
• Mixins can be inherited
• You can have mixin class hierarchies just the same way you can with normal classes

• Aggregation:
• Game objects agreggate a number of mixins to aquire their functionability
• Mixins are agreggated (added to game objects) to create entity model descriptions

For example: A mixin called BoomerangTarget provides the ability to be the target of the player’s boomerang. BoomerangTarget is a child of another mixin called Target which provides the generic ability of being a target of a player’s weapon. At the same time, an Enemy agreggates the following  mixins: Actor, BoomerangTarget, SwordTarget. Actor lets the enemy play animations, BoomerangTarget is the mixin desvribed above and SwordTarget provides the ability to be hit by a sword. SwordTarget mixin is also a child of Target, thus, both BoomerangTarget and SwordTarget share the basic functionability defined in the Target mixin.

A lot of game engines are using Mixins these days. Mixins have become the standard way to represent game object functionability.

Seth out.