I have been meaning to write this post for a while now and since I have spent most of this month back in the UK visiting friends and family I don't have all that much to share technically so I thought it was about time I got this post done.

Over the course of my 23 years of coding I have had a number of what I call "Code Epiphanies". These are moments in my coding career where fundamental changes in how I code have taken place.



Like most, I started my coding career writing simple scripts, for me it was the odd bit of HTML, JS, PHP and AS. It was simple imperative code, usually all contained in one file. "When this is clicked do this, then do this" etc.

This way of coding served me well. It took me all the way to University at which point I encountered Java and I started to write larger and larger programs. I now started to struggle as I noticed that I had many more classes and objects but no way to easily tie them together.

For a simple (contrived) example, suppose I have a "Player" object that wanted to let the "PlayerManger" object know when the player had died. I would do something like the following:

[code lang="java"]
public class Player
{
public PlayerManager manager;

    ...

    private void Die()
    {
        manager.OnPlayerDie();
    }

}
[/code]

The "manager" variable would be set from the outside by whoever created the Player. It looks simple but I found as I had more objects and managers I was getting horribly bogged down as I had to keep hold of references to PlayerManager in parts of the code which werent even remotely related. It was causing my code to become complex and hard to manage.

Thats when I had my first Code Epiphany, I discovered the Singleton. I no longer needed to pass my unrelated objects around, I could just access them directly within the player:

[code lang="java"]
public class Player
{
...

    private void Die()
    {
        PlayerManger.GetInstance().OnPlayerDie();
    }

}
[/code]

This was an incredible revelation to me as it opened my eyes to how important good architecture is as your program gets larger.

As the years went by however I started to notice issues with my Singleton based architecture. Although it was okay for quick projects that weren't meant to last very long I noticed that as a program got bigger and bigger Singletons were becoming more and more of an issue. For example I found that I couldn't easily swap out the PlayerManager for a different sort of PlayerManager without breaking a whole bunch of code, for example I couldn't do the following:

[code lang="java"]
public class Player
{
...

    private void Die()
    {
        IPlayerManger.GetInstance().OnPlayerDie();
    }

}
[/code]

Singletons I also found were making my code very rigid. I was finding it hard to abstract parts of my code out into separate reusable libraries that I could use in future projects. With Singleton references all over the place it was becoming a bit of a spaghetti nightmare.

It was around this time that Flash was starting to become really big and I found myself doing more and more AS code. It was also around this time that frameworks were starting to explode in the Flash world. I remember experimenting with a whole bunch of them: PureMVC, Cairngorn, Swiz etc, before I came across Robotlegs.

Robotlegs was (and still is) a great MVCS framework. It creates clear separation between the different layers of your application; Models, Views, Controllers and Services. One of the most important things for me was how it did this, by using a new concept (to me at least), Automatic Dependency Injection.

Automatic Dependency Injection (DI) was my second Coding Epiphany, it did away with my hard-coded Singletons and replaced them with neat little "Inject" tags. First you would define your dependency tree such as:

[code lang="java"]
public class Context
{
private void setup()
{
injector.mapSingleton(IPlayerManger, PlayerManager);
}
}
[/code]

You could then just write your Player like:

[code lang="java"]
public class Player
{
[Inject]
public IPlayerManger playerManager;

    private void Die()
    {
    	playerManager.OnPlayerDie();
    }

}
[/code]

Then when you create a player using the injector, the IPlayerManager instance will be filled with a PlayerManager instance.

[code lang="java"]
injector.createInstance(Player);
[/code]

This was a revelation to me as it now meant I could create better isolation between may various classes. Player doesn't care where PlayerManager comes from and it doesn't even care what the implementation of it is, it just wants to have the OnPlayerDie() method.

This general concept was great. It applied to everything I did, be it Actionscript games, C# apps or Java backend code, it created nice separation of concerns for me but I was missing one major benefit of DI which led me to my third Code Epiphany.

About 12 months ago I joined The Broth here in Perth Australia. I joined as an Actionscript developer onto a team that had been working on a Facebook and Mobile game for over 3 years. This was my first time joining a team on a project that had already been in development for years and it was a real revelation to me.

Over the years the code had grown and evolved. It had in fact grown to the point where it was starting to get really hard to maintain. I was really afraid to make any changes as I didn't have the years of experience to know what systems affected each other, whether deleting something over here would cause something over there to break.

So I did some googling and decided to invest in [Michael Feather's book Working Effectively with Legacy Code](https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052) and [Uncle Bob's Clean Code videos](https://cleancoders.com/videos).

![51H6SHy6g2L._SX374_BO1,204,203,200_](https://www.mikecann.blog/wp-content/uploads/2016/07/51H6SHy6g2L._SX374_BO1204203200_.jpg)

Both Michael Feathers and Uncle Bob both based most of their discussions around automated testing. Infact Michael Feathers defined legacy code as any code that doesn't have test coverage. I had heard about Unit Testing and knew that it was something I should be doing but never actually tried it.

Working on this 3 year old project was the perfect opportunity to get to grips with unit tests. As Michael Feathers describes in his book, once you have your code under test, that is you can be sure that its doing what it should be doing, you are then free to refactor the code so long as it passes the tests.

One thing I learnt very quick was that to make your code testable you have to be very careful how you structure your code. Your tests can get hard to write and maintain if your classes get too big or take on too many dependencies.

This to me was my third Code Epiphany. By keeping my classes small with minimal dependencies it made things easier to test. A side benefit was that it made the code much easier to read and reason about.

Going back to my contrived example. I would now structure my Player like:

[code lang="java"]
public class Player
{
private IPlayerManger \_playerManager;

    public Player(IPlayerManager playerManager)
    {
    	_playerManager = playerManager;
    }

    public void Die()
    {
    	_playerManager.OnPlayerDie();
    }

}
[/code]

I have removed the need for the [Inject] tag as now all my dependencies are just passed in the constructor.

I could then easily test like:

[code lang="java"]
public class PlayerTests
{
[Test]
public void WhenPlayerDies_PlayerManagerInformed()
{
var mock = new MockPlayerManager();
var player = new Player(mock);
player.Die();
Assert.IsTrue(mock.OnPlayerDieWasCalled();
}
}
[/code]

Unit Testing has forced me to write better, simpler to read code purely by the fact it would be hard to test if it wasn't the case. As Martin Fowler says:

> Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Well thats where im at these days. Trying to write easy to understand and testable code. I don't know what my fourth Epiphany could possibly be but im excited to keep learning and improving.

So I promised in my [last post](https://www.mikecann.blog/programming/unity-ash-a-different-way-of-thinking-about-making-games-in-unity/) to show how how [Unity-Ash](https://github.com/mikecann/Unity-Ash) can make things easyier when it comes to Unit Testing.



I have added some tests to the [Unity Asteroids](https://github.com/mikecann/UnityAshteroids) example game. Lets take a look at one of the simpler systems as an example, the DeathThroesSystem:

[code lang="csharp"]
public class DeathThroesSystem : NodelessSystem<DeathThroes, Entity, Audio>
{
public DeathThroesSystem()
{
\_updateCallback = OnUpdate;
\_nodeAddedCallback = OnNodeAdded;
}

    private void OnNodeAdded(DeathThroes death, Entity entity, Audio audio)
    {
        audio.Play(death.deathSound);
    }

    private void OnUpdate(float delta, DeathThroes death, Entity entity, Audio audio)
    {
        death.countdown -= delta;
        if (death.countdown <= 0)
            entity.Destroy();
    }

}
[/code]

We can see its a really simple system that does a couple of things.

First we want to test that when a node is added to the system we play a sound effect. Using Unity-Test tools you can quickly whip up a test case:

[code lang="csharp"][testfixture]
public class DeathThroesSystemTests : UnityUnitTest
{
private IEngine \_engine;
private DeathThroesSystem \_system;

    [SetUp]
    public void Setup()
    {
        _system = new DeathThroesSystem();
        _engine = new Engine();
        _engine.AddSystem(_system, 0);
    }

    [Test]
    public void WhenANodeIsAdded_DeathSoundPlays()
    {
        var e = AddEntityToEngine();

        Assert.AreEqual(1, e.GetComponent<Audio>().toPlay.Count);
        Assert.AreEqual(e.GetComponent<DeathThroes>().deathSound, e.GetComponent<Audio>().toPlay[0]);
    }

    private GameObject AddEntityToEngine()
    {
        var obj = CreateGameObject();
        obj.AddComponent<DeathThroes>();
        obj.AddComponent<Audio>();
        obj.AddComponent<Entity>();
        _engine.AddEntity(obj.AddComponent<Entity>());
        return obj;
    }

}
[/code]

I wrote a little helper that adds an entity to the engine with the necessary components. In the future we could use reflection to looup the types on the Nodeless system, but for now its enough to satisfy the test:

![2015-11-02_17-28-19](https://www.mikecann.blog/wp-content/uploads/2015/11/2015-11-02_17-28-19.png)

Next we want to check that after update the countdown is decremented.

[code lang="csharp"][test]
public void AfterUpdate_CountdownDecremented()
{
var e = AddEntityToEngine();

    var before = e.GetComponent<DeathThroes>().countdown;

    _engine.Update(1.5f);

    Assert.AreEqual(before - 1.5f, e.GetComponent<DeathThroes>().countdown, 0.01f);

}
[/code]

Easy, now we want to check that when the countdown is less than or equal to zero, the entity is destroyed:

[code lang="csharp"][test]
public void AfterCountdownTimerEnds_EntityDestroyed()
{
var e = AddEntityToEngine();

    var before = e.GetComponent<DeathThroes>().countdown;

    _engine.Update(before + 1);

    Assert.IsTrue(e.GetComponent<Entity>().IsDestroyed);

}
[/code]

Sweet and thats it! Sure we could add a few more tests for some of the corner cases but as an example I think it serves its purpose.

Let me know in the comments or email me: mike.cann@gmail.com with what you think!

[Over a year ago](https://www.mikecann.blog/portfolio/projects/unity-ashteroids-ash-framework-in-unity/) I decided to scratch an itch and see if I could get Richard Lord's Ash framework to work in Unity. It actually turned out to be far easier than I had imagined. A few people contacted me as they wanted to use it for production games so I decided to do [a little more work on it a few months later](https://www.mikecann.blog/programming/unity-ash-upgrades/) to fix some of the easily solved issues with my quick port.



Unfortunately I lacked any spare time to work on it until now. This week I spent 3 days rewriting the framework from scratch. I improved many things, making it much more Unity-friendly, and generally easier to use. Because of the differences from the AS3 version of Ash I now describe it as "heavily inspired" rather than a port.



Before I go into too much detail about the differences from [Richard's AS3 version](https://www.ashframework.org/) I should briefly explain Ash and how it differs and extends upon Unity's Enity / Component architecture.

## TL; DR

Checkout the Unity-Ash src: [https://github.com/mikecann/Unity-Ash](https://github.com/mikecann/Unity-Ash) and the example game: [https://github.com/mikecann/UnityAshteroids](https://github.com/mikecann/UnityAshteroids)

## Entity / Components in Unity

Unity is an Entity / Component game engine. This means that instead of having classes for object types such as Spaceship, Asteroid or Player which may extend some other classes you have Entities (Unity calls these GameObject's) which contain components that do the work.

![2015-10-30_09-48-45](https://www.mikecann.blog/wp-content/uploads/2015/10/2015-10-30_09-48-45.png)

This is a much better structure for game design as it favours composition over inheritance which prevents the common pitfall of the "[God Object](https://en.wikipedia.org/wiki/God_object)" when developing a game. By separating the concerns into differnt components you can reuse functionality by attaching components to Entities / GameObjects rather than extending a base class and overriding required functionality.

I won't go on any more about it, you can google the topic and find out plenty more.

## Entity / Components in Ash

Although Ash is an Entity / Component architecture, it differs quite fundamentally from Unity in how data and logic should be structured.

In Unity components typically extend MonoBehaviour and contain the variables and logic for that specific functionality. For example a simple Unity component may look something like:

[code lang="csharp"]
public class Bullet : MonoBehaviour
{
public float maxAge = 3;

    public float age;

    void Awake()
    {
    	age = 0;
    }

    void Update()
    {
    	age += Time.deltaTime;
    	if (age >= maxAge)
    		Destroy(gameObject);
    }

}
[/code]

Imagine that Bullet is a projectile fired from the player spaceship. We can see that the bullet ages over time and when it is equal or greater than the max age then it is removed from the game.

The Ash way of doing things is to separate the component data from its logic. So it may now look something like:

[code lang="csharp"]
public class Bullet : MonoBehaviour
{
public float maxAge = 3;
public float age;
}

public class BulletNode
{
public Entity Entity { get; set; }
public Bullet Bullet { get; set; }
}

public class BulletAgingSystem : ISystem
{
private INodeList<BulletNode> \_nodes;

    public void AddedToEngine(Engine engine)
    {
    	_nodes = engine.GetNodes<BulletNode>();
    }

    public void RemovedFromEngine(Engine engine)
    {
    	engine.ReleaseNodes(_nodes);
    }

    public void Update(float delta)
    {
    	foreach (var node in _nodes)
    	{
    		node.Bullet.age += delta;
    		if (node.Bullet.age >= node.Bullet.maxAge)
    			node.Entity.Destroy();
    	}
    }

}
[/code]

Here we can see that the Bullet's data is now separate from the logic which modifies that data. In Ash components should simple data, they can contain some methods but they should be limited to operating on the state of that instance, they certainty aren't allowed to have any dependencies on other components.

So instead of putting the logic with the data its been moved to a System. The system however may have dependencies on multiple components so it describes its dependencies by defining a structure, a "Node", in this case BulletNode. This class lists all the components an Entity must have before it can be used by the System.

What this means is that whenever an Entity (GameObject) is added or removed from the game the Ash Engine will automatically update the INodeList<BulletNode> with of all the Entities that match the required components specified in BulletNode.

If that all looks a little too verbose for you, one of the improvements I made in this rewrite of Unity-Ash was to provide a short-hand way of writing Systems in the form of the "NodelessSystem", so now the above example could look like:

[code lang="csharp"]
public class Bullet : MonoBehaviour
{
public float maxAge = 3;
public float age;
}

public class BulletAgingSystem : NodelessSystem<Bullet, Entity>
{
public BulletAgeSystem()
{
\_updateCallback = OnUpdate;
}

    private void OnUpdate(float delta, Bullet bullet, Entity entity)
    {
    	bullet.age += delta;
    	if (bullet.age >= bullet.maxAge)
    		entity.Destroy();
    }

}
[/code]

Now you may be thinking that's all well and good but it doesn't really improve things, you are just splitting the Monobehaviour up and adding more classes to the the game, which is true, but there are several benefits to working this way. One of those benefits becomes evident when you think about dependencies between components.

Suppose that we want to handle what happens when the player spaceship collides with an asteroid. We want to respawn the player somewhere but it would be a bit unfair if we respawned the player on top of an asteroid so we need to check that the new spawn location isn't too close to an Asteroid.

How would we go about this in Unity? Well one solution may look something like the following:

[code lang="csharp"]
public class Player : MonoBehaviour
{
private PlayerManager manager;

    void Awake()
    {
    	manager = FindObjectOfType<PlayerManager>();
    }

     void OnCollisionEnter2D(Collision2D coll)
     {
    	 var asteroid = hit.gameObject.GetComponent<Asteroid>();
         if (asteroid != null)
    	 	manager.PlayerHitByAsteroid(this);
     }

}

public class PlayerManager : MonoBehaviour
{
public void PlayerHitByAsteroid(Player player)
{
var asteroids = FindObjectsOfType<Asteroid>();

    	// Find a place to respawn the Player
    	var postion = UnityEngine.Random.insideUnitCircle*1000;
    	while (!IsClearToAddShip(position, asteroids))
    		postion = UnityEngine.Random.insideUnitCircle*1000;

    	player.transform.position.x = postion.x;
    	player.transform.position.y = postion.y;
    }

    private bool IsClearToAddShip(Vector2 newSpaceshipPosition, IEnumberable<Asteroid> asteroids)
    {
    	foreach (var asteroid in asteroids)
    		if (Vector2.Distance(asteroid.transform.position, newSpaceshipPosition) <= 1f)
    			return false;

    	return true;
    }

}
[/code]

Sure there are a few ways this could potentially be done but the point im trying to highlight is the way dependencies are handled in a typical Unity game. Usually we have managers which look after some part of the game and then we use FindObjectsOfType or Tags to get access to the entities in the system.

The ash way of doing it may looks something like:

[code lang="csharp"]
public class Player : MonoBehaviour
{
}

public class Collisions : MonoBehaviour
{
public List<Collision2D> hits = new List<Collision2D>();

    void OnCollisionEnter2D(Collision2D coll)
    {
    	hits.Add(coll);
    }

}

public class PlayerCollisionNode
{
public Player Player { get; set; }
public Collision Collision { get; set; }
public Transform Transform { get; set; }
}

public class AsteroidNode
{
public Asteroid Asteroid { get; set; }
public Transform Transform { get; set; }
}

public class PlayerCollisionSystem : ISystem
{
private INodeList<PlayerCollisionNode> \_players;
private INodeList<AsteroidNode> \_asteroids;

    public void AddedToEngine(Engine engine)
    {
    	_players = engine.GetNodes<PlayerCollisionNode>();
    	_asteroids = engine.GetNodes<AsteroidNode>();
    }

    public void RemovedFromEngine(Engine engine)
    {
    	engine.ReleaseNodes(_players);
    	engine.ReleaseNodes(_asteroids);
    }

    public void Update(float delta)
    {
    	foreach (var playerNode in _players)
    	{
    		foreach (var hit in playerNode.Collision.hits)
            {
    			var asteroid = hit.gameObject.GetComponent<Asteroid>();
                if (asteroid == null)
                    continue;

    			RespawnPlayer(playerNode);
    		}
    		_players.Collision.hits.Clear();
    	}
    }

    private void RespawnPlayer(PlayerCollisionNode node)
    {
    	var postion = UnityEngine.Random.insideUnitCircle*1000;
    	while (!IsClearToAddShip(position, asteroids))
    		postion = UnityEngine.Random.insideUnitCircle*1000;

    	node.Transform.position.x = postion.x;
    	node.Transform.position.y = postion.y;
    }

    private bool IsClearToAddShip(Vector2 newSpaceshipPosition)
    {
    	foreach (var asteroidNode in _asteroids)
    		if (Vector2.Distance(asteroidNode.Transform.position, newSpaceshipPosition) <= 1f)
    			return false;

    	return true;
    }

}
[/code]

Here we can see we have made the Collisions component generic so that it can be used by Asteroids, Bullets or whatever else requires collisions. Then we have a system that is specific to Player Collisions.

The PlayerCollisionSystem then gets references to the players and the asteroids and does the respawning logic.

Its important to realize that in Ash, Systems are not allowed to reference each other. They can only communicate by adding or removing entities / components or changing properties on those components. This may seem like a bit of a restriction at first but its really important to keep things separated and free from complex dependencies, as a side benefit it makes Unit Testing easier (more on that later).

## Single Point of Entry

So the final piece of the puzzle is how do these System's come together? What calls the AddedToEngine, RemovedFromEngine, and Update methods on the Systems?

Well this is another way that Ash differs from the typical Unity Game. Usually in a Unity MonoBehaviour you may add Awake() or Start() handlers which get triggered by Unity when the game starts up. The problem is that it makes it quite hard to know what order things are going to get initiated in. It also makes it really hard for a new coder to come to the project and understand how the project works.

In Ash you have a single entry point. So for example you may have something like:

[code lang="csharp"]
public class GameBoostrapper : MonoBehaviour
{
private EntityCreator creator;
private Engine engine;

    void Awake()
    {
    	creator = new EntityCreator();
    	engine = new Engine();

    	engine.AddSystem(new MenusSystem(), SystemPriorities.PreUpdate);
    	engine.AddSystem(new PlayerRespawningSystem(creator), SystemPriorities.PreUpdate);
    	engine.AddSystem(new LevelingSystem(creator), SystemPriorities.Update);
    	engine.AddSystem(new MotionControlSystem(), SystemPriorities.Update);
    	engine.AddSystem(new SpaceshipCollisionSystem(creator), SystemPriorities.ResolveCollisions);
    	engine.AddSystem(new HudSystem(), SystemPriorities.Animate);
    	engine.AddSystem(new AudioSystem(), SystemPriorities.Render);

    	creator.CreateGame();
    }

    void Update()
    {
    	engine.Update(Time.deltaTime);
    }

}  
[/code]

The Engine is the main control object for Ash. It holds a list of Systems which are updated each tick of the game.

The EntityCreator isn't an Ash specific class and is rather a helper class which is used to abstract out the creation of the entities from the business logic of the various systems (also important for the Unit Testing as we will see later).

There is one more piece I haven't mentioned yet. How is the Engine informed when Entities are added or removed from Unity? Well this is one of those places where Unity-Ash differs from AS3 Ash.

All GameObjects that should be picked up by the Ash Engine require that an "Entity" component be added to the GameObject:

![2015-10-30_11-57-09](https://www.mikecann.blog/wp-content/uploads/2015/10/2015-10-30_11-57-09.png)

The "Entity" represents an Entity in Ash but in Unity is actually a MonoBehaviour. It tells the Engine when the GameObject it is created and destroyed. One difference from my previous work on Ash is that if you want to add or remove components from a GameObject at runtime you should do it via the Entity directly so that it can inform the Engine:

[code lang="csharp"]
public interface IEntity
{
...
T Add<T>() where T : Component;
void Remove(Component component);
...
}
[/code]

This change was required to get around all the [performance problems related to checking for component changes each frame](https://www.mikecann.blog/programming/unity-ash-upgrades/).

## Unit Testing

Well this is another massive benefit to using Ash but this post is already way too long so ill save Unit Testing for the next part, stay tuned!

For now you can checkout Unity-Ash here: [https://github.com/mikecann/Unity-Ash](https://github.com/mikecann/Unity-Ash)

If you want to see an example of its usage you can see here: [https://github.com/mikecann/UnityAshteroids](https://github.com/mikecann/UnityAshteroids)

If you want some more info on Ash then you should check out the official Ash Framework site: [https://www.ashframework.org/](https://www.ashframework.org/)

Note its all still really new so things are probably going to be in flux quite a bit. I am really interested to get peoples opinions on this however. Let me know what you think!