There’s two parts to this, what I do and how I do it. All the code is available on Github if you would like to use it.

Components as States

The basic principle in my approach to state machines is to encapsulate each state in one or more components on the game object. There are two reasons for this

1. As a component, each state has full access to all the standard messages and other features of Unity’s API.
2. The state of a game object exists intrinsically in its components, so the natural way to change a game object’s state is to change its components.

I started off with the idea that each state is a component of the game object that the state machine exists on, which is clean and simple, but more recently I wanted more flexibility so now each state can comprise multiple components, and the components don’t have to be on the same game object as the state machine (although usually they are either there or on a child game object).

To implement this I have a single custom state machine component which manages the states, adding and removing components when entering and exiting states, and not much else.

Why it’s not straightforward

There was always a little wrinkle in this plan — components can’t exist outside of the game object on which they are created, so you can’t remove a component from a game object and then add it back later, removing it destroys it. It’s often desirable to maintain the internal data of a state when exiting it and re-entering it later so destroying the state component when exiting the state and creating a new one when re-entering it won’t work on it’s own. Over time I’ve used two different solutions for this.

When I first used components as states I was using Unity 3.5 and to keep things simple I would disable and enable components when changing state. The components for all the states existed on the game object all the time, and all but the current state were disabled. This works in most cases — the update methods don’t run on disabled components, and the OnEnable and OnDisable methods will be called when entering and leaving the state. However some specific messages are still received on disabled components - OnCollisionEnter for example - so I had to be a bit careful with this technique.

When Unity 5.3 was released it included the new JsonUtility class which provides a standard way to serialise objects, so since then I have serialised and removed components when leaving a state and deserialised and added them back when entering a state.

There is still a slight annoyance with this technique - it’s not possible to deserialise a component when creating it, instead you have to create a new instance and deserialise the old data into the new component. Because of this you have to avoid using the Awake and OnEnable methods in the state components because these methods are called before the deserialisation. The only initialisation method you can use in each state is the Start method, but I can work with that.

The Implementation

The implementation is quite simple, consisting of a single StateMachine component and a custom inspector to make it easier to use. The code and a simple example is available on my Github repository.

The StateMachine component has two configurable public properties, an array of states and the name of the initial state. Each state in the array has a name and an array of components for that state.

There is another public property which is the name of the current state, and a public method ChangeState(string) which takes the name of the new state as the parameter. On the surface there’s not much more to it than that. You could add more features but I’ve never needed them.

The StateMachine component also contains a bunch of private methods to handle the serializing and deserializing of the components and, like I said, there is a custom inspector for the class to help with the configuration.

To use it

1. Drop the StateMachine class on a game object.
2. Add all the components for all the states into the scene and configure them how you wish.
3. Configure the states in the StateMachine instance with the names of the states and references to the component instances for each state.

When you enter the scene the components for all the states will be serialized and those not associated with the initial state will be removed. If you call ChangeState on the state machine then the components for the old state will be removed and the components for the new state will be added.

A component can be used in multiple states. If a component is in both the old and new states it is unchanged, it is not removed and re-added.

That’s all. If this is useful for you do let me know, and if you implement any improvements to it I would like to see them.

Have fun making your games.

using UnityEngine;
using UnityEditor;
using System.IO;

public static class ScriptableObjectCreator {
  [MenuItem( "Assets/Create/Instance" )]
  public static void CreateInstance() {
    foreach( Object o in Selection.objects ) {
      if( o is MonoScript ) {
        MonoScript script = (MonoScript)o;
        System.Type type = script.GetClass();
        if( type.IsSubclassOf( typeof( ScriptableObject ) ) ) {
          CreateAsset( type );
        }
      }
    }
  }

  [MenuItem( "Assets/Create/Instance", true )]
  public static bool ValidateCreateInstance() {
    foreach( Object o in Selection.objects ) {
      if( o is MonoScript ) {
        MonoScript script = (MonoScript)o;
        System.Type type = script.GetClass();
        if( type.IsSubclassOf( typeof( ScriptableObject ) ) ) {
          return true;
        }
      }
    }
    return false;
  }

  private static void CreateAsset( System.Type type ) {
    var asset = ScriptableObject.CreateInstance( type );
    string path = AssetDatabase.GetAssetPath( Selection.activeObject );
    if( path == "" )  {
      path = "Assets";
    } else if( Path.GetExtension( path ) != "" ) {
      path = path.Replace( Path.GetFileName( AssetDatabase.GetAssetPath( Selection.activeObject ) ), "" );
    }
    string assetPathAndName = AssetDatabase.GenerateUniqueAssetPath( path + "/New " + type.ToString() + ".asset" );
    AssetDatabase.CreateAsset( asset, assetPathAndName );
    AssetDatabase.SaveAssets();
    EditorUtility.FocusProjectWindow();
    Selection.activeObject = asset;
  }
}

To use the script, just add it to a folder called "Editor" inside your Unity assets folder.

The script isn't as sophisticated as ScriptableObject Factory but I prefer it because it is quicker to use - just right click on a class and choose Create->Instance.

Everything is a MonoBehaviour

The first principle of working with Unity's architecture is that everything should be a MonoBehaviour. Which means everything should be a component on a game object. Even the stuff that doesn't represent a feature of a specific game object, like code that initialises the scene or code that saves the current game state - just create an empty game object, call it something sensible like "scene controller" or "services" and add these components there.

If your code is a MonoBehaviour then Unity knows about it, the Unity editor knows about it, and the tools that Unity provides will work with it. If your code is not a MonoBehaviour then it sits outside of Unity's knowledge and ability to manage it and you can't configure it in the Unity editor.

(Scriptable Object is an exception to this but you probably don't need that.)

The editor

There is one disadvantage to making everything a MonoBehaviour - you have to work with two IDEs. The first is your coding tool - usually MonoDevelop or Visual Studio - and the second is the Unity editor. You can't spend your day entirely inside your coding tool of choice, you have to mess with the Unity editor as well. But that's okay. You create the components in your code editor and you configure them in the Unity editor, just like you would any other asset.

Inversion of Control

All of which is an introduction to my real reason for writing this article - a lot of developers new to Unity struggle with inversion of control, or more precisely the apparent lack of it. You may come from any programming background, but if you are used to having a dependency injection container or service locators you may well regard Unity as inferior and you may even decide to create a dependency injection container for it. Before you do, take a look at what Unity does out of the box.

In common use inversion of control falls into three categories -

1. Service locators
2. Dependency injection
3. Events

Unity has tools for all of these. Some of them may not look like the tools you are accustomed to but they have much the same goals and produce similar results.

Service locators

Unity's service locator is the Find… methods of the Object class - FindObjectOfType and FindObjectsOfType. These methods will find the components in the current scene that match a particular type, and if you followed my advice above then all of your code is inside components of some object or objects in the scene. So if, for example, you have a component called "ScoreService" that submits scores to your server, just call FindObjectOfType<ScoreService>() to locate it.

Some developers complain that the find methods are slow, but

1. They will rarely impact the performance of your game
2. If they do impact performance, use dependency injection instead

Dependency injection

You know that thing in the Unity editor where you drag one game object onto a property of another to provide the component instance for that property. That's dependency injection. It may feel a bit strange configuring it in the editor, but it's a lot easier to understand than the pages of code or XML used to configure most dependency injection containers.

Unfortunately configuring dependencies in the Unity editor is so easy you won't feel as smart as you did when you used Spring or Robotlegs - even your designers can configure this dependency injection.

Events

There's three ways to handle callbacks into an object.

1. SendMessage

Unity has had the SendMessage method since the dawn of time. It works but is less than ideal because it requires matching a string in the caller to a method name in the callee, which requires setting global rules about the naming of methods (or losing any benefit of SendMessage over just calling the method directly).

2. Actions

If you code in C#, you get Actions for free as part of the language. Actions are delegates that don't return a value and as such are great for event dispatching. Unfortunately, the Unity editor doesn't understand them so they have to be configured in code, but that's what you thought you wanted anyway isn't it.

3. Events

Since the introduction of Unity's new GUI in version 4.6 Unity includes an event system that can be configured in the editor - so if a game object dispatches an event you can configure the listeners for that event inside the editor rather than in code. It feels odd at first, but if you embrace the idea of building your components in a code editor and configuring them in the Unity editor then, as with the dependency injection, this will make absolute sense. Try it.

Conclusion

Unity has it's own tools for managing inversion of control. They are unlike the tools in most web frameworks but they do the same job and in some cases they are even easier to use.

The first game I wrote in Unity was a struggle as we broke all of the above rules to code the game the way we did with other tools. With my second and subsequent games I follow the Unity patterns and I build games faster and have more fun doing it.

Every time you play Freak Factory you lose, eventually. You may prolong the game, you may get a high score, but eventually you will lose. Losing is inevitable and every Freak you make reduces the space you have, reduces how much game you have left. While you play it the game doesn't get harder, it gets less. With every move you make you see the end approaching.

But the end doesn't matter. The game isn't about the end, just as it isn't about the start. It's about all the bits in between. What Freaks are you making? What score will you achieve? What inspired, lucky or surprising moves will you make? Will you remember this game?

And then there's the obvious stuff. After they are born in the machine, the Freaks do two things - they move and they grow. Life.

A friend's son said he didn't like that they're called Freaks, because they're not Freaks, they're lovely. I said Freaks can be lovely too. I asked him which is his favourite Freak, he said "Archer, because sometimes he feels sad and he doesn't know why." Not just any Freak, a depressed one.

Freak Factory appeals to all demographics. It has a 4.9 out of 5 rating on the iOS store. Some of our most avid players are seniors and some of our most avid players are young children. It's a game for generations to play together.

A friend tells me he loves it because he's better than his teenage children. It's the only game where he gives them tips. Another friend slugs it out with his teenage daughter. His best score is 88, her's is 93. For now. That'll change soon.

Freak Factory doesn't require fast reactions, it requires planning, thought, a steady mind. It's hardest to play when you're distracted. So much can go wrong.

Some shots in Freak Factory exhibit "sensitive dependence on initial conditions". Which means a small change in your shot will cause a big change in the outcome. Which also means "it's easy to mess up". The problem with many plans.

You'll never get a perfect game. If you restart every time you make a mistake, every time your game doesn't go according to plan, then you will never finish a game. The theoretical maximum score is a few hundred, but the practical maximum is about 150. My best is 118.

Getting a high score means accepting your mistakes, discovering the new opportunities they present, making a new plan. John Lennon sang "Life is what happens to you while you're busy making other plans". So is a big Freak in the middle of your factory.

Sometimes you decide to be cautious, and sometimes you go for the big shot, the wild shot, the exciting shot, because it might just work. Because games exist to be explored, to be played. Because life should be interesting.

Play Freak Factory here.

• Develop Brighton, 16 July 2015

In this session I presented seven important lessons that I learnt as a choreographer that are still important to me as a game designer. I accompanied each lesson with the story of how I learnt it and an example of how it might apply in game design.

The slides from the presentation contain very little information but they are here in case you're interested.

I remember as a choreographer at dance school showing my choreography teacher my first dance piece. I'd spent a term making this dance, working with three dancers who were studying with me. This was extra-curricular activity but I wanted to make this dance and I felt good about it. So, in search of praise I asked my choreography teacher, Ingegerd Lonnroth, to look at it.

We gathered in a dance studio. I started the music and the dancers danced. I watched the dance and I watched my choreography teacher, my gaze flicking between the two. Then, unexpectedly, my chest tightened and my stomach flipped. This dance was not good. Specifically, the section I was watching was not good. And I was acutely embarrassed. How had I not seen this before? I looked across at Ingegerd but she was impassive. Had she noticed?

When the dancers finished Ingegerd said something supportive and encouraging, to them and to me. Then she said "Show me again the section about a third of the way through, starting from the upstage right corner." Yes, she'd noticed.

I learnt two things that day.

1. That Ingegerd is a very perceptive critic, a skill I made full use of during my time at dance school.
2. That it is very difficult to see what you have made the way the audience will see it.

When I look at a dance I've choreographed or a game I've designed the tendency is to see what I want to see, to see the work as I intend it to be, not as it is. Faults are ignored as my imagination smooths them over and delivers to me the experience that I expect, because I expect it.

My tool for overcoming this hazard is in that early experience with Ingegerd. Show it to someone whose opinion matters to you. Watch it with them. Imagine what it looks like for them. Imagine what they are thinking. Don't wait for them to tell you, don't rely on their feedback. Empathise and feel it for yourself.

In theory you can do this without the other person there but it is hard. I find that their presence, watching the dance or playing the game, and my anxiety over their reaction helps me to empathise, to see the work as it really is.

With my new game, Freak Factory, I have shown it to numerous people. Family, friends, other developers. In many cases I watch the screen over their shoulder, imagining what they are thinking and feeling, and I smile as my chest tightens, my stomach flips, and I add another issue to my to-do list. It's not traditional user testing and for you it may not work, but it helps me a lot.

Before I became a game developer I was an independent contemporary dance choreographer with my own dance company. And in my 14 years creating dances, and a further 14 creating games, I've experienced all sorts of collaborations. For me, there are three key ingredients to a good collaboration.

Skill

All collaborators should bring skills to the project that wouldn't otherwise be present. There's no point collaborating with someone if you're better than them at everything. A collaborator is your equal. You respect and value each other's skills and by working together you make something better than either of you could make alone.

Understanding

All collaborators should understand what you are making. The game is the reason you are working together. You must agree on what the game is and who it is for so you can all focus your skills on delivering that experience to the players.

Trust

All collaborators must trust each other. Without trust there will be no collaboration - the untrusted collaborator will be watched and controlled and any influence they might have over the game will be blocked.

I recall one dance production I created where the costume designer showed me designs that I hated. So I stopped working with her. It wasn't her fault, I should never have asked her to work with me because I didn't trust her.

But there was another dance production where the costume designer showed me designs that I hated and I continued working with her. We even went with her designs that I hated, because I trusted her. And when I saw the finished costumes they were fantastic, perfect for the dance. That's why I needed a costume designer.

And now

These three ingredients, skill, understanding and trust, went through my mind back in March when Brian Roberts sent me a visual design for my new game. I hadn't asked him to do this, I had planned for my first game as an indie to be small and manageable. Simple graphics, simple sounds, interesting gameplay. Build and learn, I thought, I'll find collaborators for the next project, after I've had time to get to know the indie scene in London. This would be my game.

But I showed a prototype of the game to some friends in the pub and Brian sent me an email later that night - "Sorry I didn't say goodbye. Really like your new game so I thought I'd have a (slightly drunk) blast at some graphics." Attached was a picture of the main screen of the game, reinterpreted as an industrial space in which slightly cute, slightly scary creatures are created, and you, the player, are the one creating them. It was great.

(Here's a tip - if you see a game you want to work on, ask the team creating it - they may say yes.)

So I spent a sleepless night deliberating.

I have never created a piece of art without collaborating. In dance you usually have dancers, composers, costume & set designers. Then as a game developer I've never made "my" game, I've always worked on other people's games. Which is why I quit my job - to make my games.

I intended to make this game alone, and now Brian wanted to collaborate on it.

Because I knew Brian, I knew he had the skills. From the graphics he sent me, he clearly understood the game. But collaboration works two ways - I would be giving Brian the power to influence my game. It wouldn't even be my game any more, it would be our game. That's why the trust has to be there.

By the morning I had decided and I sent Brian an email - "I like that a lot. Do you want to talk about doing all the graphics for the game?" We got together, had a great conversation and Brian became the visual designer for the game. And it has been great working together. The game has benefited from his designs and from his feedback. It's a much richer visual experience and it'll be released soon.

Here's the video trailer featuring the final graphics.

So there we are, my ingredients for good collaboration - Skill, Understanding and Trust.

Freak Factory will be out on 27th July 2015 on iOS & Android. You can read more about it on the game's website.

A New Name

The game now has its final name and art style. The name is Freak Factory. What were bubbles are now little critters called Freaks, and what was a simple box is now a factory in which you make these Freaks. And if you don't keep them contained they will escape and the game ends. Trust me, it all makes sense and looks wonderful.

I didn't design the graphics, that was Brian Roberts who I used to work with at Stick Sports. There's a little story about how we ended up working together on Freak Factory, which I will tell you next time. For now suffice to say I'm very pleased to be collaborating with him. The graphics he has made are really excellent.

Trailer

The best place to see the new graphics is in the trailer for the game. Here it is.

Release Date

The game is nearing completion and we are planning to release it next month. I'll post more detailed information as the date approaches.

How to charge for your game is sometimes very simple and other times very hard. With Bubble Pack I have always known that I want the initial download to be free. There are two reasons for this

1. For my first game I want the low barrier to entry that free provides.
2. It's too easy for someone else to make a free clone of this game.

However, I also don't want to use advertising in the game. Advertising on mobile is horrible - a preponderance of shitty looking adverts that make your game look cheap and nasty. Most advertising is not the sort of stuff I want to present to people who play my games. If I could fill the game with high quality brand advertising I'd be happy, but instead we get clickbait and ads for other people's games.

Free and no advertising leaves me squarely in the free-to-play space, not necessarily the most comfortable place to be. What I really want to do is an old-fashioned try-before-you-buy model. So here's the plan…

• The game will be free to download.
• There will be a single non-consumable in-app-purchase.
• There will be an energy system - a limit on the number of bubbles you can play with at any time.
• When you run out of bubbles you can wait for them to refill or pay once to remove the limit.

And that's it. I have tried to ensure the game can be played for free forever, but the energy system must necessarily be a little annoying or no-one will pay. Please forgive me for that. My goal is for an honest, simple model of one payment to get the full game. If the game is good enough, maybe I can significantly beat the normal 4% conversion on free-to-play.

I added the number of bubbles the player has to the wireframes, and an overlay for buying the game.

First I tried letting the player set the power at which the ball is thrown. Unfortunately, this made the game far too easy whilst also making the controls more complicated, so I ditched that idea.

I also tried removing each bubble after a period of time. The lifespans of bubbles got longer as the game progressed, starting at fifteen moves for the first bubble. So after it had been in play for fifteen moves, the first bubble would pop, opening up more space in the game area for other bubbles. Because the lifespan increased during the course of the game, the game got harder and harder.

This meant it was possible to recover from a bad mistake early in the game, but it also made the early part of the game boring for good players because the bubbles you placed then would be gone later in the game so didn't really matter. So I dropped this idea too and returned to the pure game.

But I did make a lot of smaller adjustments.

I tweaked the power of the shot until it gives the player lots of interesting options.

I can think of a number of strategies to try to get a high score and I'm unsure which will be the best, and that's good.

I have also repeatedly tweaked the pace of the bubble to make the game a little faster, a little faster, a little faster, a little slower. The game is still calm, but there's less waiting around for a shot to finish.

I added markers around the edge of the play area to help the player with targeting.

I made the direction targeting for the bubble into a line to make it clearer (some testers were confused that the dots indicated the size of the bubble when in fact they were much smaller).

I also added a second line indicating the direction of the previous shot, which makes planning your shot based on what happened last time a lot easier.

These small changes make it a little easier for a beginner player to improve, but to get a great score still requires good spatial planning and reasoning.

When playing the game the control rests squarely with the player. There is no randomness or erratic behaviour in the game to ruin your plans. When you succeed it is your success and when you fail it is your mistake, which leaves every player thinking they can do better next time.

My best score so far is 62. My scores are quite erratic ranging from about 30 to the aforementioned 62 - it's easy to make a mistake and ruin your well laid plans. :twisted: