Unity’s own message passing system can be leveraged to achieve this effect, but there are a few problems with it. First, sending messages is hierarchy-dependent. You either need a reference to the object you wish to send the message (event) to, or you need a reference to that object’s parent object. This is not loosely coupled. Secondly, it’s not statically type-safe.

There have been several solutions to this problem (for example, FlashBang’s messaging system or this one on the UnifyCommunity wiki). These still lack type-safety, and won’t quite do.

Here is my event system implementation. It looks quite a bit like the event system in AS3:

using UnityEngine;
using System.Collections;
using System.Collections.Generic;
 
public class GameEvent
{
 
}
 
public class Events
{
    private static Events eventsInstance = null;
    public static Events instance
    {
        get
        {
            if (eventsInstance == null)
            {
                eventsInstance = new Events();
            }
 
            return eventsInstance;
        }
    }
 
    public delegate void EventDelegate<T> (T e) where T : GameEvent;
 
    private Dictionary<System.Type, System.Delegate> delegates = new Dictionary<System.Type, System.Delegate>();
 
    public void AddListener<T> (EventDelegate<T> del) where T : GameEvent
    {
        if (delegates.ContainsKey(typeof(T)))
        {
            System.Delegate tempDel = delegates[typeof(T)];
 
            delegates[typeof(T)] = System.Delegate.Combine(tempDel, del);
        }
        else
        {
            delegates[typeof(T)] = del;
        }
    }
 
    public void AddListener<T> (EventDelegate<T> del) where T : GameEvent
    {
        AddListener<T>(del, false);
    }
 
    public void RemoveListener<T> (EventDelegate<T> del) where T : GameEvent
    {
        if (delegates.ContainsKey(typeof(T)))
        {
            var currentDel = System.Delegate.Remove(delegates[typeof(T)], del);
 
            if (currentDel == null)
            {
                delegates.Remove(typeof(T));
            }
            else
            {
                delegates[typeof(T)] = currentDel;
            }
        }
    }
 
    public void Raise (GameEvent e)
    {
        if (e == null)
        {
            Debug.Log("Invalid event argument: " + e.GetType().ToString());
            return;
        }
 
        if (delegates.ContainsKey(e.GetType()))
        {
            delegates[e.GetType()].DynamicInvoke(e);
        }
    }
}

To use this thing, first we declare a GameEvent subclass. This event can carry with it all of the parameters needed by the objects listening for the event.

public class SomethingHappenedEvent : GameEvent
{
	// Add event parameters here
}

Registering to listen for the event looks like this:

public class SomeObject : MonoBehaviour
{
	void OnEnable ()
	{
		Events.instance.AddListener<SomethingHappenedEvent>(OnSomethingHappened);
	}
 
	void OnDisable ()
	{
		Events.instance.RemoveListener<SomethingHappenedEvent>(OnSomethingHappened);
	}
 
	void OnSomethingHappened (SomethingHappenedEvent e)
	{
		// Handle event here
	}
}

And finally, to raise the event, do this:

Events.instance.Raise(new SomethingHappenedEvent());

The cool thing about this implementation is that it’s type-safe (listener registration errors will be caught at compile time, and no casting of events or event arguments) and it doesn’t require listening objects to implement a special interface or use Unity’s built-in message passing system.

The interface for this system is almost identical to that presented by Mike Mittleman at Unite 08, and I’d wager our implementations are similar. If you really want a rundown of the benefits and pitfalls of event-driven Unity development, I suggest watching his presentation on Unity’s website.

There are several approaches to solving this problem – the naive approach being lots and lots of conditionals. Finite state machines approach the problem by objectifying state and state transitions. More recently, with the growing popularity of higher level languages like Lua, Python, and C#, coroutines have become a popular choice for mitigating the complexities of managing state.

I have implemented coroutines in C, and it’s turning out great. Here’s how to do it!

First, let’s look at a more traditional approach to state management – the ‘finite state machine.’ Each game entity might keep a state object that implements an interface like this:

class IState
{
	virtual void Enter() = 0;
	virtual void Update() = 0;
	virtual void Exit() = 0;
}

This rather simple approach should be familiar. It’s been my experience that managing state this way has a tendency toward ‘state explosion.’ Consider the following pseudocode:

// WalkTo state
void WalkTo::Update()
{
	while (!IsAtDoor())
	{
		WalkToDoor();
	}
 
	OpenDoor();
 
	actor->ChangeState(new WaitForDoor());
}
 
// WaitForDoor
void WaitForDoor::Update()
{
	while (!IsDoorOpen())
	{
		Idle();
	}
 
	actor->;ChangeState(new EnterDoor());
}
 
// EnterDoor
void EnterDoor::Update()
{
	EnterDoor();
}

Here, we want an actor to walk to a door, open it, wait for it to open, then walk through. To accomplish this, we have to write three states for the actor plus two (not shown) for the door. You can see how easily this can get more complicated.

Ideally, we want to be able to write something like this:

void Actor::WalkThroughDoor()
{
	while (!IsAtDoor())
	{
		WalkToDoor();
		Sleep();
	}
 
	OpenDoor();
 
	while (!IsDoorOpen())
	{
		Idle();
		Sleep();
	}
 
	EnterDoor();
}

If you have been working in Unity3D or UnrealScript, this might look pretty familiar. Both of these environments provide some kind of coroutine system, as does Lua, Python, and other higher-level languages.

If, however, we are writing our game in C or C++, we’re out of luck. Neither of these languages comes with built in support for coroutines. We could use threads, but synchronization would be a serious problem, and the number of coroutines you could have in your game (which potentially could be quite a lot) would be limited to the number of threads the OS supports. You could also use the dark magic that lurks in setjmp.h, but it is notoriously difficult to use across different platforms.

The solution I will present takes advantage of a somewhat controversial feature of the C switch statement: if a block in a switch is not terminated with a break statement, the flow of control will simply continue executing code in the next block. This anomaly, and the fact that it’s legal to jump into the middle of a loop in C were the basis of Tom Duff’s famous serial copy optimization, known as “Duff’s Device.”

An extremely detailed breakdown of this coroutine implementation by Simon Tatham can be found here. The implementation I arrived at is almost exactly the same as Simon’s, and looks like this:

#include 
 
#define COROUTINE_STATIC_BEGIN static int srcLine = 0; switch(srcLine) { case 0:;
#define COROUTINE_STATIC_END(value) } return (value)
#define COROUTINE_STATIC_END_VOID } return
#define COROUTINE_STATIC_YIELD(value) \
	do {\
		srcLine = __LINE__;\
		return (value); case __LINE__:;\
	} while (value)
 
#define COROUTINE_CONTEXT_PARAM void** contextParam
#define COROUTINE_CONTEXT_BEGIN struct ContextTag { int line; int sleepTimer; int sleepTime
#define COROUTINE_CONTEXT_END(x) }* x = *contextParam
#define COROUTINE_BEGIN(x) if (!x) { x = *contextParam = malloc(sizeof(*x)); x->line = 0;} \
								if (x) switch (x->line) { case 0:;
#define COROUTINE_END(value) } free(*contextParam); *contextParam = 0; return(value)
#define COROUTINE_END_VOID } free(*contextParam); *contextParam = 0; return
#define COROUTINE_YIELD(value) \
	do {\
		((struct ContextTag*) *contextParam)->line = __LINE__;\
		return(value); case __LINE__:;\
	} while (0)
#define COROUTINE_YIELD_VOID \
	do {\
		((struct ContextTag*) *contextParam)->line = __LINE__;\
		return; case __LINE__:;\
	} while (0)
#define COROUTINE_SLEEP(time) \
	((struct ContextTag*) *contextParam)->sleepTimer = 0; \
	((struct ContextTag*) *contextParam)->sleepTime = time;\
	do {\
		((struct ContextTag*) *contextParam)->sleepTimer += game.deltaTime;\
		COROUTINE_YIELD_VOID;\
	} while (((struct ContextTag*) *contextParam)->sleepTimer < ((struct ContextTag*) *contextParam)-&gt;sleepTime)
#define COROUTINE_STOP(value) do { free(*contextParam); *contextParam = 0; return (value); } while (0)
#define COROUTINE_STOP_VOID do { free(*contextParam); *contextParam = 0; return; } while (0)
#define COROUTINE_CONTEXT void*
 
#define COROUTINE_ABORT(context) do { free (context); context = 0; } while (0)

These macros set up the switch statement and the labels which act as the reentrance points of the coroutine. The macros come in two versions: regular and static. Static functions are those which don’t need any values saved between calls or that the data is function static. The regular version assumes that you have some data that needs to persist between calls. The context macors create a small heap-allocated object that stores your data.

One caveat with is code is that while it’s perfectly valid C and C++, you have to turn off Edit and Compile when compiling in Visual Studio. Studio does something strange with the __LINE__ macro when Edit and Compile is turned on.

With these macros, you can write code like this:

int myCoroutine(COROUTINE_CONTEXT_PARAM)
{
	COROUTINE_CONTEXT_BEGIN;
	int i;
	COROUTINE_CONTEXT_END(ctx);
 
	COROUTINE_BEGIN(ctx);
	for (ctx->i = 0; ctx->i < 10; ctx->i++)
	{
		printf("%d\n", ctx->i);
 		COROUTINE_YIELD_VOID;
 	}
 
	// Sleep for 30 ticks
	COROUTINE_SLEEP(30);
 
	printf("finished sleeping\n0");
 
	COROUTINE_END_VOID;
 }
 
 int callingFunc()
 {
	COROUTINE_CONTEXT context;
	context = 0;
 
 	do
 	{
 		myCoroutine(context);
	} while (context);
 }

Now, this might not be as pretty as, say, Unity3D’s C# coroutines or UnrealScript’s state blocks, but functionally it’s about the same. Using this coroutine implementation has sweeping implications on your C or C++ game code. Every actor in your game can behave as if it has its own thread, without the headaches of synchronization.

Try it out!

Working

David McDonough, Jack Cooke, and I polished off a 1st place win at Rosetta Stone’s first annual 36 hour game jam in Harrisonburg Virginia on Saturday.

The requirements for the game were given out beforehand, and were very open-ended: make a game that “teaches.”  Coming from Firaxis, we decided to make a strategy game, and settled on a “virus” theme.  We liked the idea of a virus strategy game because we could abstract things visually (simple shapes with cool shaders – no characters to animate).  The simulation aspect of the game play could also be very simple, and amounted to little more than three numbers driving a physics-based steering system (like this).

Each of us had some basic knowledge about how vira spread in the body, and we really didn’t go out of our way to do any additional research.  One of Sid Meier’s 10 Rules of Game Design (we’re not really sure which one this is – he changes the order all the time) is to “make the game first, then do the research.”   This may sound a bit strange at first, but it makes sense.  If the game isn’t fun, it doesn’t engage the player and loses the ability to teach.  If the simulation is to detailed or esoteric, the player can’t easily grok it, and  you lose them.  Civilization is a great example of this.  It is built from the assumed historical knowledge of the average gamer (unless you fire up the Civilpedia).  The game doesn’t teach by relaying historical facts, rather it does so by allowing the player to engage in a simulation that, while not historically accurate, illustrates very clearly the dynamics of industry, diplomacy, war, and culture.

The game we ended up with at the end of the day is called Pathogen.  It features game play that is very similar to Phil Hassey’s Galcon with a 3D play surface.  You move your swarm of vira from cell to cell, expanding your population and avoiding autoimmune cells as you go.   Before each level, you load out with three “mutation cards” which give you power-ups as you hit certain population milestones.  The game is very simple, but illustrates well the balancing act a virus must perform when successfully infecting it’s host.

What Went Right:

Planning

We knew the prompt for the game jam ahead of time, so we had quite a bit of time to plan for what we were going to make.  When we got there, we had a very clear development schedule and asset list, so there weren’t any surprises.  David, who is a producer at Firaxis, was very on top of things as per usual.  He broke down the game into manageable hunks – usually punctuated by a meal, which served as an excellent motivator.  The only thing missing was Hansoft.

Pathogen

Scope

You never really finish a game at a game jam – there’s always something more you want to do, but we scoped our game very well and stayed true to it.  Again, good planning ahead of time and real world game production experience helped us stay true to our original goals.

Unity

The Unity Engine played a huge part in our success.  The engine made it very easy to prototype and iterate quickly.  Unity virtually eliminated the need for an asset conditioning pipeline – regardless of what we threw at it, Unity just worked.  With Unity, there was also never a “make a build” step to our design process.  The game was always live, and we could see changes we made instantly.  While we probably would have created an awesome game without it, it certainly could not have been the game we made with it.

Sleep

For a 36 hour competition, it was tempting to go in thinking we would stay up for the whole thing.  We had the foresight, however, to work sleep into our schedule.  Even short naps did wonders for productivity.  We knew we were going to have to pull a very long night to get the game done, and we opted to do it later in the project rather than burn out with a long stretch at the very beginning.  We worked four hours the first night, slept for six, then worked until the end of the jam, taking naps occasionally.  We all got extremely tired at times, but it wasn’t as bad as it could have been.  We really should have brought pillows though.  Sleeping on the floor was not fun.

What Went Wrong

The white board

Source Control

One of the down sides of using Unity, and there aren’t many, is that the indie version does not support source control – no Perforce or Subversion.  With two people coding at the same time, the project would inevitably start to branch, and we would periodically have to manually merge all of the changes.  Unity projects don’t like to be moved around – especially from PC to Mac, so often a merge wasn’t just merging source files, it was reconstructing whole levels and prefabs.  In the future, it might make sense to at the very least source control the code (I think you can do this) to make merging prefabs and levels in Unity easier, and perform the merges more often.  OR Unity could include source control support in the indie version.  Preferably the latter.

Iteration Time

The game shipped with three complete levels, which was great, but we didn’t really have time to balance and test them.  As a result, the game is almost impossible to lose.  This is probably better than a game that’s impossible to win, but because the levels were so easy, some of the cool systems we put in to progress and upgrade the player (like virus mutation) weren’t really needed to win.

Jack’s Laptop

Developing the steering behavior

It was loud.  Really really loud.  Lucky for him, he won a new one!

Overall, there was very little negative to say about our experience.  Rosetta Stone did an awesome job putting this game jam on. The accommodations were great.  There were volunteers to answer questions or get something for you if you needed it, and there was food and drink available pretty much all the time.  Everyone we met was really cool, too, and we hope to see them again next year!

Also, we were on TV!

http://www.whsv.com/home/headlines/81078462.html
http://www.whsv.com/home/headlines/81098512.html

Cell noise, otherwise known as Worley noise,  is actually a visualization of a Voronoi diagram: given a random scattering of points, color each pixel on the surface relative to the distance from the closest randomly scattered point.  Cell noise appears all over nature, it looks great, and is easy to compute!  A cell noise function can give us a volume of noise, which we can sample in a fragment shader, giving us seamless patterns on any object – no UV mapping required.  Cool!

I’m going to base this implementation off of a very nice one I found here.  To get started, we need a way to generate our randomly scattered points.  Normally, we would accelerate this sort of thing with a look-up table of some kind, which in GPU land means a texture.  Hop into your favorite image editing program and make a texture that looks something like this:

And here’s the shader:

Shader "Miller/CellNoise" {
	Properties {
		_Color ("Main Color", Color) = (1,1,1,1)
		_SecondaryColor ("Secondary Color", Color) = (1,1,1,1)
		_Random ("Random Noise", 2D) = "white" {}
		_Intensity ("Intensity", Range(0.001, 10.0)) = 1.0
		_Size ("Size", Range(0.000, 10.0)) = 1.0
		_Offset ("Time", float) = 0.0
	}
 
	SubShader {
		pass {
			Name "Noise"
 
			/* // Enable this if you want addative blending
			ZWrite Off
			Tags { "Queue" = "Transparent" }
			Blend One One
			*/
 
			CGPROGRAM
			#pragma target 3.0
			#pragma vertex vert
			#pragma fragment frag
			#pragma fragmentoption ARB_fog_exp2
			#include "UnityCG.cginc"
 
			uniform float4 _Color;
			uniform float4 _SecondaryColor;
			uniform float _Intensity;
			uniform sampler2D _Random;
			uniform float _Size;
			uniform float _Offset;
 
			struct v2f {
				V2F_POS_FOG;
				float3 noisepos;
			};
 
			v2f vert(appdata_base v) {
				v2f o;
 
				PositionFog(v.vertex, o.pos, o.fog);
				o.noisepos = v.vertex;
 
				return o;
			}
 
			float4 getCell3D(const in int x, const in int y, const in int z) {
				float u = (x + y * 31) / 20.0;
				float v = (z - x * 3) / 30.0;
				return tex2D(_Random, float2(u, v));
			}
 
			float2 cellNoise3D(float3 xyz) {
				int xi = int(floor(xyz.x));
				int yi = int(floor(xyz.y));
				int zi = int(floor(xyz.z));
 
				float xf = xyz.x - float(xi);
				float yf = xyz.y - float(yi);
				float zf = xyz.z - float(zi);
 
				float dist1 = 9999999.0;
				float dist2 = 9999999.0;
				float3 cell;
 
				for (int z = -1; z <= 1; z++) {
					for (int y = -1; y <= 1; y++) {
						for (int x = -1; x <= 1; x++) {
							cell = getCell3D(xi + x, yi + y, zi + z).xyz;
							cell.x += (float(x) - xf);
							cell.y += (float(y) - yf);
							cell.z += (float(z) - zf);
							float dist = dot(cell, cell);
							if (dist < dist1) {
								dist2 = dist1;
								dist1 = dist;
							}
							else if (dist < dist2) {
								dist2 = dist;
							}
						}
					}
				}
 
				return float2(sqrt(dist1), sqrt(dist2));
			}
 
			float4 frag(v2f i) : COLOR {
				float2 dists = cellNoise3D((i.noisepos + _Offset) * _Size);
				// float4 c = ((_Color * dists.x) + (_SecondaryColor * dists.y)) * _Intensity; // Add the terms for a different look
				float4 c = ((_Color * dists.x) * (_SecondaryColor * dists.y)) * _Intensity;
				return c;
			}
 
			ENDCG
		}
	}
 
	FallBack "Diffuse"
}

You can animate the texture by changing the _Offset parameter over time. It looks great!