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

As a component, each state has full access to all the standard messages and other features of Unity’s API.

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 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

Drop the StateMachine class on a game object.

Add all the components for all the states into the scene and configure them how you wish.

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.

]]>https://www.richardlord.net/intergalactic-delivery-driver/blog/taking-a-break.htmlTaking A Break2016-09-12T12:00:00Z2016-09-12T12:00:00ZWorking on a long project is hard. I’ve been working on and off on Intergalactic Delivery Driver for ten months now. There were some gaps in that time, particularly the three months I spent working at King when I got almost nothing done on the game.Working on a long project is hard. I’ve been working on and off on Intergalactic Delivery Driver for ten months now. There were some gaps in that time, particularly the three months I spent working at King when I got almost nothing done on the game. Even so, the project is ten months old and sometimes my enthusiasm for it wanes. Not because I think any less of the project, I still believe it will be a great game, but because it’s hard to get up every morning and find the energy and enthusiasm to work on the same project day in and day out, particularly when there is no-one else to enthuse you. One week I may sprint along, getting lots done and making enormous progress. Another week I may crawl, achieving very little.

So I have a new plan. When my enthusiasm wanes I will allow myself a break. This break will be deliberate and will involve me working on something different. I may be a small project, a prototype, or some writing. Whatever, it will involve not working on my main project for a short while.

Which is why last week and this I am not working on Intergalactic Delivery Driver. I have bought a VR kit (the Gear VR because it’s relatively inexpensive) and am experimenting with an idea for a VR project. It’s a small project with some interesting technical hurdles and if the result is good I’ll make it available, probably for free.

]]>https://www.richardlord.net/blog/general/most-people-are-good-people.htmlMost people are good people2016-06-22T12:00:00Z2016-06-22T12:00:00ZMost of us trust most of our friends. We trust them not to cheat and lie to us for their own gain. We trust them not to steal from us or to assault us. But how about strangers? Not a specific stranger but strangers in general. Do you trust them? Do you trust the other people in your country not to cheat, lie, steal, and assault others for their own gain? Maybe you think like me that most people are okay but there’s a few bad apples. Or maybe not. Maybe there’s a group of people you particularly don’t trust.Most of us trust most of our friends. We trust them not to cheat and lie to us for their own gain. We trust them not to steal from us or to assault us. But how about strangers? Not a specific stranger but strangers in general. Do you trust them? Do you trust the other people in your country not to cheat, lie, steal, and assault others for their own gain? Maybe you think like me that most people are okay but there’s a few bad apples. Or maybe not. Maybe there’s a group of people you particularly don’t trust. A group that you think has more than a few bad apples. Like maybe politicians, or bankers, or immigrants, or muslims, or christians, or atheists, or women, or men, etc.

How much we trust strangers has a very significant impact on politics, economics and the well being of our country. Trust is the social glue that enables us to live and work together. For example, those who trust others tend to be more accepting of higher taxes. They trust their politicians to spend the money sensibly. They trust other people to use the social welfare system appropriately, not to abuse it. They trust successful people, all of whom have been helped by social policies like education and infrastructure, to give back through the tax system. Socialism is built on trust.

When the trust of others breaks down we instead expect politicians to spend our taxes looking after their self-interests, we expect successfully people to avoid paying their taxes, and we expect strangers to abuse the social welfare system to their own advantage. In such a world it’s only natural to want to pay less tax, to want less money spent on welfare, and to blame these others that we don’t trust for the problems we face.

In Britain there have been a number of incidents recently that likely reduce the trust we have in others.

The global financial crisis and the subsequent bail-out of the rich through bank bail-outs and the propping-up of asset prices

The Members of Parliament expenses scandal

The high levels of immigration from Eastern Europe

There’s probably a lot more if you think about it. In hindsight there are things that could have been handled better. But I want to speak about immigration because it’s particularly relevant at the moment.

When a few foreigners immigrate into Britain they are welcomed. We like quirky and unusual and the foreign couple living near the village pub are precisely that. We welcome them, we ask them about their homeland, their family, what they like about Britain. They become the friends of the people that meet them and are of no concern to the rest of us.

But when there are many immigrants we become suspicious. Why are so many foreigners coming to live here? It’s certainly not for the weather. What do they want? Can we trust them? In time the suspicion fades and the newcomers are treated as British (and their children of course are British), and they in turn may join us in being suspicious of the next wave of immigrants.

The European Union’s policy of free movement of people is laudable, but while it produces long-term benefit to all the nations of Europe it also causes short-term pain in this failure of trust. The EU is still trying to absorb and adjust to the immigration patterns instigated by the large number of countries that joined in 2004 (Cyprus, Czech Republic, Estonia, Hungary, Latvia, Lithuania, Malta, Poland, Slovenia, Slovakia) and 2007 (Bulgaria, Romania) and to calm down from the resulting surge in distrust and nationalist politics.

In time we will trust these strangers among us and regard them as our own. Because most people are good people. Meanwhile, this is the worst time in our 40 year membership for the UK government to call a referendum on our EU membership. This is likely a high point for the Leave vote. I just hope that Remain wins despite the trust deficit that is stacked against it.

]]>https://www.richardlord.net/intergalactic-delivery-driver/blog/refactoring-the-meta-game-in-intergalactic-delivery-driver.htmlRefactoring the meta-game in Intergalactic Delivery Driver2016-05-18T12:00:00Z2016-05-18T12:00:00ZLast week was an interesting week for Intergalactic Delivery Driver, the game I'm currently developing. The week started with a crisis in confidence as I debated whether the meta-game would work and ended with a number of changes and much greater confidence in the quality of the game in general and the meta-game in particular.Last week was an interesting week for Intergalactic Delivery Driver, the game I'm currently developing. The week started with a crisis in confidence as I debated whether the meta-game would work and ended with a number of changes and much greater confidence in the quality of the game in general and the meta-game in particular.

The meta-game has always been a difficulty within the project. The core-loop was easy, it barely feels like I designed it at all. It was born of inspiration and has felt right since the start. Yes, sometimes I do wonder how many players want to play a game that involves tilting your phone, but it works so well that it's always been worth the risk. The meta-game on the other hand is all hard graft and design. I have thought about it so much and tried so many permutations in my head, on paper and in prototypes that I am bored with it, while still trying hard to make it better. Maybe this time I am there.

When I started prototyping the game I imagined a simple level-unlock scenario, maybe with a "saga-map" like King use in most of their games. This puts all the emphasis on the core loop and lets me put all my effort into creating good quality levels for you to play. Developing those levels might lead me to introduce pick-ups, power-ups and other fun details to add joy and progression to the levels and decisions about when to use objects that span multiple levels.

But later, as the prototype developed, I decided to focus more on your career as a delivery driver. I want to use the game to comment on the idea of independence in the workplace, of working for oneself, of the importance of your personal brand, about what Tim O'Reilly calls the next:economy. With different agents and opportunities open to the player I can let you choose the direction your career takes. I can hint at what it feels like to work for yourself. I can show how hard it is to get started in this new economy, when everyone else seems to have the good contacts. How a lucky break can open new possibilities that you haven't imagined and how your career path is based as much on luck as planning. As John Lennon sang "Life is what happens to you while you're busy making other plans" (I used that line when talking about Freak Factory too - maybe there is a theme developing in my work).

Those are grand ambitions, and if I followed them literally then the start of the game would be slow, hard and frustrating and as your career developed your decisions, based as much on luck as judgement, would take you down a path that closed off whole sections of the game to you and made your game uniquely different to everyone else's. The former is clearly not a good idea and the later, while interesting in concept, means producing lots more game than any one person can play or make (although procedural generation could help). Instead, I have focused on the ideas of choice and reputation. You pick the agents you work with and you build a reputation that opens up new options for your career as an Intergalactic Delivery Driver.

All of that led me to a meta-game based around a jobs board which lists a number of delivery jobs that are available to you. Different jobs have different challenges and rewards and you choose which job to attempt next. Jobs are from different agents and as you gain reputation new agents take an interest in you and offer you work. Each agent brings with them a new type of job with new skills to develop and challenges to overcome.

All of which sounded good except that there is no hint to the player as to what direction to take. You are left alone with a list of jobs and little guidance to help you decide what to do next (see, it is like working for yourself!).

So last week I set out to fix this. The first step was to separate the jobs board into multiple jobs boards, one for each agency. This lets you see all the agencies at the start, see which are offering you work, and see what you need to do to gain work from the others. This gives you a clear set of goals you need to complete to get attention from the other agencies.

Having unlocked an agency the next challenge is to give the player direction and purpose when doing jobs for that agency. In real life it's great if clients keep offering you more work, but in the game a jobs board which keeps refilling with new jobs to do makes it feel to the player like they're not progressing at all. There are other measures of your progress - your reputation, the spaceships you own, the money you have earned, the agents that are offering you work. But when it comes to doing the deliveries, a list of deliveries that keeps refilling feels like a grind.

So what I have decided is to return back to the original plan of a level unlock game, but rather than one massive level unlock I will present each agency as a fixed set of deliveries to complete. That means that each agency will contain a set of deliveries in a particular style for you to unlock, play through, and gain three stars on. The levels within an agency get progressively harder and have a theme to tie them together based on the nature of the agency. You still get to choose which jobs to do, which agencies to develop your relationship with, and which to avoid. But you also get the attraction of completing the next level, of a clear progression through the game, and of playing the same levels as your friends.

So that's where the game is at now. I haven't thrown away the procedural generation code, instead I have adapted it to run within the Unity editor. When creating a new agency, I procedurally generate a set of levels for that agency based on the character of that agency. Then I play and manually adjust these levels to make them more interesting. This has enabled me to make 120 levels in an afternoon - 120 levels that I am now playing through and altering to make them better.

]]>https://www.richardlord.net/blog/game-design/the-choreography-of-monument-valley.htmlThe Choreography of Monument Valley2016-03-31T12:00:00Z2016-03-31T12:00:00ZThe brilliant Critical Distance have proposed "Choreography" as the topic for their March collection of Blogs of the Round Table and I think, as a choreographer turned game developer, I should have something to say on this. I pondered what to write and eventually decided to write about just one game, the wonderful Monument Valley by ustwo.The brilliant Critical Distance have proposed "Choreography" as the topic for their March collection of Blogs of the Round Table and I think, as a choreographer turned game developer, I should have something to say on this. I pondered what to write and eventually decided to write about just one game, the wonderful Monument Valley by ustwo.

Launch Monument Valley and the first thing you see is a temple with the number one inside it. The symmetry of the view gives it stability, a calm beginning to the game. But there is far more going on than this screen-shot can reveal.

Stars fade in and out of existence, the patterns in the centre of the temple grow and transform, and the temple itself gently bounces like it's the heartbeat of this game.

Through this movement the temple gently invites you to enter its portal. Touch it and the image fades and a new one replaces it.

Ida, standing on a walkway, looking around, calm and unconcerned as the breeze flutters her dress. You touch the path and Ida quickly turns and moves towards your touch. That turn is important. If you want Ida to walk this way she must first turn and face where she's going and, unlike so many game characters, for Ida turning takes time. The turn is quick, but it is real. The designers decided it was important to animate that turn, to make Ida's movement fluid.

On reaching your touch, Ida stands patiently once more. It is your turn to make some choreography of your own as you rotate the walkway to form the path that Ida requires and with that movement you discover your power to transform this world to her needs.

So you lead Ida along the walkway and up the steps to her destination. Note the gentle bounce as the control handles retract and then extend again, hear Ida quicken her pace as she climbs the steps to her goal, and then she stands at the top gazing out across the valley. A valley that she and you will explore together.

The choreography of Monument Valley isn't about how characters move or how the player moves, it's about how everything moves. The choreography is a vital part of the experience and without it the game would be flatter, duller and less enjoyable.

Of all the dance styles I'm familiar with Monument Valley reminds me most of classical ballet. The rigid discipline of the ballerina's body as she turns and jumps, her fast footwork as she chassés and coupés around the stage, and the lyrical flow of her arms atop her rigidly controlled body are replaced by the mechanics of this world, Ida's rapid steps, and the fluttering flags and flowers that suffuse most levels. The whole is a careful balance between strong mechanics and gentle lyricism.

With each level that balance shifts a little more away from the lyrical and towards the mechanical as Ida gets closer to her goal.

]]>https://www.richardlord.net/blog/unity/creating-scriptableobjects-in-unity.htmlCreating ScriptableObjects in Unity2015-11-03T12:00:00Z2015-11-03T12:00:00ZThis is a short editor script that I use for creating instances of ScriptableObject classes in the Unity editor. Most scripts that create ScriptableObjects require you to add new code for each object type. This script does not. Select any class that extends ScriptableObject and choose Create->Instance to create an instance of that class.This is a short editor script that I use for creating instances of ScriptableObject classes in the Unity editor. Most scripts that create ScriptableObjects require you to add new code for each object type. This script does not. Select any class that extends ScriptableObject and choose Create->Instance to create an instance of that class.

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.

]]>https://www.richardlord.net/blog/unity/inversion-of-control-in-unity.htmlInversion of Control in Unity2015-10-22T12:00:00Z2015-10-22T12:00:00ZMany developers come to Unity from a background in object-oriented programming and look to use the same patterns in Unity that they used elsewhere. You don't neglect what you have learnt elsewhere just because you are using a different tool but sometimes you have to apply those lessons differently with the new tool. Unity has its own idea about how you should architect a game and before you start fighting against this it is best to try working with it - you will be a lot more productive if you do.Many developers come to Unity from a background in object-oriented programming and look to use the same patterns in Unity that they used elsewhere. You don't neglect what you have learnt elsewhere just because you are using a different tool but sometimes you have to apply those lessons differently with the new tool. Unity has its own idea about how you should architect a game and before you start fighting against this it is best to try working with it - you will be a lot more productive if you do.

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 -

Service locators

Dependency injection

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

They will rarely impact the performance of your game

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.

]]>https://www.richardlord.net/freak-factory/blog/why-freak-factory.htmlWhy Freak Factory?2015-09-24T12:00:00Z2015-09-24T12:00:00ZYou may be surprised if I tell you that Freak Factory is about life, but it is.
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.You may be surprised if I tell you that Freak Factory is about life, but it is.

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.

]]>https://www.richardlord.net/blog/presentations/choreographer-game-designer.htmlLessons I Learnt as a Choreographer and Apply as a Game Designer2015-07-22T12:00:00Z2015-07-22T12:00:00ZIn this session at the Develop conference in Brighton 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.Presented at

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.

]]>https://www.richardlord.net/blog/choreography-games/seeing-whats-really-there.htmlSeeing what's really there2015-06-26T12:00:00Z2015-06-26T12:00:00ZThis blog post was originally published on the Develop:Brighton website on 26 June 2015.
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.This blog post was originally published on the Develop:Brighton website on 26 June 2015.

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.

That Ingegerd is a very perceptive critic, a skill I made full use of during my time at dance school.

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.