[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)](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)](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!

[A while back](https://www.mikecann.blog/portfolio/projects/unity-ashteroids-ash-framework-in-unity/) I decided to scratch an itch and see if [Richard Lord's Ash Entity Framework](https://www.ashframework.org/) could be ported to Unity. Well I was pleasantly surprised that it did port quite easily (with some help from David Arno's .NET port) and worked well enough that I could also port [Richard's Asteroids game over to Unity](https://github.com/mikecann/UnityAshteroids) too.



Since then I have had a few people contact me interested in using the port for their own projects so I decided to give it a little more love and polish.

## Part 1 - Separation

First things first was to split the Ash library from the Asteroids example project so you dont have to include the entire Asteroids port in every single one of your games (madness). So now the Unity Ash project can be found here:

[https://github.com/mikecann/Unity-Ash](https://github.com/mikecann/Unity-Ash)

..and the Asteroids project (which uses the Untity-Ash project) lives here:

[https://github.com/mikecann/UnityAshteroids](https://github.com/mikecann/UnityAshteroids)

Now all that you need to do to is to clone (or include as submodule) Unity-Ash into your game's Assets folder and you should be good to go, simples!

## Part 2 - GetComponents

Next up was performance. I knew that the performance of Unity-Ash was the biggest stumbling block and unfortunately it seemed like a fairly fundamental one thanks to some holes in the Unity API (more on that later). However, I knew there were a few low-hanging-performance-fruits I could pick that should speed up things a bit.

To experiment with things I setup a separate Unity project for the performance tests and included [Unity-Ash from GitHub](https://github.com/mikecann/Unity-Ash).

[![2014-12-10_09-30-51](https://www.mikecann.blog/wp-content/uploads/2014/12/2014-12-10_09-30-51-1024x618.png)](https://www.mikecann.blog/wp-content/uploads/2014/12/2014-12-10_09-30-51.png)

The key performance bottleneck in Unity-Ash is the way the code checks for component additions and removals. Dynamic component addition and removal is key to how Ash functions and in AS3 because it was all custom code we could just fire an event when a component is added or removed from an Entity. Because Unity-Ash tries to piggyback on top of Unity's existing Entity (GameObject) / Component architecture we dont actually have access to the GameObject source and thus cant trigger events when a component is added or removed.

The solution I came up with is to add a component to each GameObject which acts like the Entity. It is responsible for checking to see if components have been added or removed, to do this it gets a list of all the components in the GameObject each frame and compares against its internal cache to see if any have been added or removed. This solution works well, however you can probably see the performance hit involved with getting a list of components from Unity for each GameObject, each frame will likely be quite high.

Because this listing of components was so crucial to performance I decided to write some tests to see what is the fastest way of doing that:

```
public class GetComponentTests : MonoBehaviour
{
	public int iterations = 10000000;
	public int repeats = 3;

	public GameObject noComponents;
	public GameObject manyComponents;
	public List<Component> components;

	public void TestAll()
	{
		components = new List<Component>();
		TestHelpers.Execute(iterations, repeats, "Empty Function", TestEmpty);
		TestHelpers.Execute(iterations, repeats, "Get Components With No Components", NoComponentsGetComponents);
		TestHelpers.Execute(iterations, repeats, "Get Components With Many Components", ManyComponentsGetComponents);
		TestHelpers.Execute(iterations, repeats, "Get Components With No Components List", NoComponentsGetComponentsList);
		TestHelpers.Execute(iterations, repeats, "Get Components With Many Components List", ManyComponentsGetComponentsList);

		Debug.Log("components " + components.Count);
	}

	public void TestEmpty()
	{
	}

	public void NoComponentsGetComponents()
	{
		noComponents.GetComponents<Component>();
	}

	public void ManyComponentsGetComponents()
	{
		manyComponents.GetComponents<Component>();
	}

	public void NoComponentsGetComponentsList()
	{
		noComponents.GetComponents<Component>(components);
	}

	public void ManyComponentsGetComponentsList()
	{
		manyComponents.GetComponents<Component>(components);
	}
}
```

I run each of these 10 million times then repeat 3 times and average:

1. "TestEmpty" is my control test test to get a sense of the cost of simply calling an empty function. That averaged to 0ms elapsed
2. "NoComponentsGetComponents" I test getting a list of components when the GameObject is empty (other than Transform), that averaged to 22ms.
3. "ManyComponentsGetComponents" I test getting a list of components when there are 20 components (plus Transform) to see what the cost of getting additional components would be, that averaged to 35ms.
4. "NoComponentsGetComponentsList" is the same as 2) except I avoid an internal memory allocation my passing in a List to populate the return with, that averaged to 5ms.
5. "ManyComponentsGetComponentsList" is the same as 3) except I pass in the List again, that averaged to 15ms.

So in summary, I learned its much faster if I pass in a list to GetComponents, which makes sense as I avoid the memory allocation associated with returning a new array each time. As a result I folded this performance improvement into Unity-Ash.

## Part 3 - Unity vs Ash

These tests are all well and good but 10 million iterations of GetComponents in standalone is probably an unlikely use case in the standard game so in addition I wanted to test what the actual performance hit you would get if you used Unity-Ash in a game instead of the standard Unity way.

To test this I set up another scene that creates and updates 5,000 asteroids on the screen.

[![upout](https://www.mikecann.blog/wp-content/uploads/2014/12/upout.jpg)](https://www.mikecann.blog/wp-content/uploads/2014/12/upout.jpg)

I time how long they create then I count how many frames I get in 10 seconds of updating them. Each asteroid has a 2D rigid body and a very simple controller script that wraps the Asteroids position on the screen:

[![2014-12-10_10-15-54](https://www.mikecann.blog/wp-content/uploads/2014/12/2014-12-10_10-15-54.png)](https://www.mikecann.blog/wp-content/uploads/2014/12/2014-12-10_10-15-54.png)

```
public class AsteroidController : MonoBehaviour
{
	private Bounds bounds;

	void Awake()
	{
		var size = Camera.main.ScreenToWorldPoint(new Vector2(Screen.width, Screen.height));
		bounds = new Bounds(Vector3.zero, new Vector3(size.x * 2, size.y * 2));
	}

	void Update()
	{
		if (transform.position.x < bounds.min.x)
		{
			transform.position = new Vector3(transform.position.x + bounds.size.x, transform.position.y, transform.position.z);
		}
		if (transform.position.x > bounds.max.x)
		{
			transform.position = new Vector3(transform.position.x - bounds.size.x, transform.position.y, transform.position.z);
		}
		if (transform.position.y < bounds.min.y)
		{
			transform.position = new Vector3(transform.position.x, transform.position.y + bounds.size.y, transform.position.z);
		}
		if (transform.position.y > bounds.max.y)
		{
			transform.position = new Vector3(transform.position.x, transform.position.y - bounds.size.y, transform.position.z);
		}
	}
}
```

This was the base test and it took about 440ms to create 5000 asteroids and processed 83 frames over 10 seconds (8.3FPS).

Now I had my base I decided to setup the same scenario but using Unity-Ash to drive the updates. So now the Asteroid looks like this:

[![2014-12-10_10-19-42](https://www.mikecann.blog/wp-content/uploads/2014/12/2014-12-10_10-19-42.png)](https://www.mikecann.blog/wp-content/uploads/2014/12/2014-12-10_10-19-42.png)

Notice that there is no controller for the Asteroid, now all the update logic happens in a system:

```
public class MovementSystem : SystemBase
{
	private Bounds bounds;
	private NodeList nodes;

	public MovementSystem()
	{
		var size = Camera.main.ScreenToWorldPoint(new Vector2(Screen.width, Screen.height));
		bounds = new Bounds(Vector3.zero, new Vector3(size.x * 2, size.y * 2));
	}

	override public void AddToGame(IGame game)
	{
		nodes = game.GetNodeList<MovementNode>();
	}

	override public void Update(float time)
	{
		var cam = Camera.main;
		for (var node = (MovementNode)nodes.Head; node != null; node = (MovementNode)node.Next)
		{
			var transform = node.Transform;
			var rigidbody = node.Rigidbody;

			if (transform.position.x < bounds.min.x)
			{
				transform.position = new Vector3(transform.position.x + bounds.size.x, transform.position.y, transform.position.z);
			}
			if (transform.position.x > bounds.max.x)
			{
				transform.position = new Vector3(transform.position.x - bounds.size.x, transform.position.y, transform.position.z);
			}
			if (transform.position.y < bounds.min.y)
			{
				transform.position = new Vector3(transform.position.x, transform.position.y + bounds.size.y, transform.position.z);
			}
			if (transform.position.y > bounds.max.y)
			{
				transform.position = new Vector3(transform.position.x, transform.position.y - bounds.size.y, transform.position.z);
			}
		}
	}

	override public void RemoveFromGame(IGame game)
	{
		nodes = null;
	}
}
```

The update logic is functionally exactly the same as the AsteroidController except its now contained within a system.

This time it took 595ms to create the Asteroids and we processed 33 frames over 10 seconds (3.3FPS).

So immediately you can see there is a large performance hit in using Ash-Unity over regular Unity (8.3FPS compared to 3.3FPS). To confirm that it was the extra overhead of checking for new components on each asteroid rather than the internal updating mechanism of the Systems in Ash I decided to turn off checking for component updates..

[![2014-12-10_10-40-02](https://www.mikecann.blog/wp-content/uploads/2014/12/2014-12-10_10-40-02.png)](https://www.mikecann.blog/wp-content/uploads/2014/12/2014-12-10_10-40-02.png)

Sure enough the frame rate went back up (in fact higher!) than the Unity update rate of 8.3FPS to 8.6FPS.

So with this in mind I decided to add an option to the Entity component that lets you choose how often it checks for new components:

[![2014-12-10_10-42-02](https://www.mikecann.blog/wp-content/uploads/2014/12/2014-12-10_10-42-02.png)](https://www.mikecann.blog/wp-content/uploads/2014/12/2014-12-10_10-42-02.png)

The reasoning is that its actually quite rare that you change the components after the initial creation of the object (at least that's what I found) and thus by reducing the number of times the Entity component checks for updates we should be able to increase the performance.

Sure enough, when set to "Every Other Frame" the framerate goes up to 4.5FPS then set to "Every 10 Frames" it goes up to 7.4 FPS. The final setting "If Component Count Changes" attempts to skip the iteration of the components by comparing the number of components against the previous frame, this results in 7.5 FPS.

So the short of the long is that you can get the same as or higher FPS using Unity-Ash so long as you know beforehand how often you are going to be added or removing components. If you have entities that is likely never to have components added or removed then set it to update "Never" and enjoy great FPS with the power of using Ash.

Just as an addendum to this, I have submitted a feature request to Unity to add in events to GameObject that we can listen to that are fired when components are added or removed, this would obviously remove 99.9% of these performance issues from Unity Ash so I would love your votes:

[https://feedback.unity3d.com/suggestions/componentadded-slash-removed-events-on-gameobject](https://feedback.unity3d.com/suggestions/componentadded-slash-removed-events-on-gameobject)

As a final step in the upgrade process I looked at what more radical changes we could make to the framework by taking advantage of Generics and some other features that C# gives us that were lacking in AS3, you can check those out towards the bottom of the readme: [https://github.com/mikecann/Unity-Ash](https://github.com/mikecann/Unity-Ash)

Well that's it for now, I hope you enjoy the improvements, please to let me know if you think its worth carrying on development, I would love to work on it some more but I have games to write!

[Last October](/posts/try-harder-2012-slides/) I was fortunate enough to attend the excellent [Try Harder](https://www.tryharder.org.uk/) conference for the second time.[ I have spoken before](/posts/try-harder-2012/) about how inspirational the event is where every attendant must give a talk on something they are passionate about. One of the talks was by David Wagner's and was on 'The Value of Tinkering' and it inspired me to[ tinker with TypeScript](/posts/tinkering-with-typescript/) which led to my [Recursive Chrome Extension](/posts/personal-project/recursive/).



Before I go any further I should mention that there is a [Try Harder 'Level Up'](https://www.tryharder.org.uk/level-up-2013/) session taking place in April that is open to new attendees, I thoroughly recommend you check it out!

Following on in the same 'Tinkering' vein I have decided to investigate an AS3 library by another Try Harder attendee [Richard Lord](https://www.richardlord.net/blog):

[![logo](/wp-content/uploads/2013/02/logo.png)](/posts/tinkering-with-ash/attachment/logo-4/)

What is Ash? Well direct from the [Ash Website:](https://www.ashframework.org/)

> Ash is a high-performance entity system framework for game development.
>
> An entity system is a way to organise the code for a game that is efficient for both code execution and code management. It uses composition rather than inheritance for sharing features between game objects and uses a data-oriented approach to separate the game state from the game logic. This makes it much easier to manage the code and to manage the game state.
> Im not going to go into the details too much of why composition over inheritance is a good idea as Richard has already done a much better job than I ever could in these two posts:

- [What is an entity system framework for game development?](https://www.richardlord.net/blog/what-is-an-entity-framework)
- [Why use an entity system framework for game development?](https://www.richardlord.net/blog/why-use-an-entity-framework)
  If you haven't got a clue what im talking about when I say Entity or Component I strongly recommend checking out his posts first.

The reason why Ash has piqued my interest is because for the last three years I have been working with Entity-Component systems for games but in a totally different way. The way I have been using and developing started with the Push Button Engine (PBE) method and later expanded out to include Dependency Injection culminating in the [Swft Framework](/posts/swft-dependency-injection-component-based-game-framework/).

Ill give one example of why am starting to fall in love with Ash:

In PBE and Swft the components contain data and functions. They can also declare dependencies (via [Inject]) which are automatically fulfilled when a component is added to an Entity. The functions in the component are able to act on their own data, other components and interact with the game as a whole.

One problem with this method is that components are largely tied to their entity and once attached aren't really free be removed or added. The reason is because other component may have dependencies that depend on that component being part of the Entity. Removing the component will cause the game to crash. This becomes a problem when you want to enable a certain chunk of functionality for a certain time then disable it, what you tend to end up doing is adding the component at Entity creation time then inside of it toggling its behaviour with a boolean.

In Ash components are pure data with the bulk of the functionality being contained within systems. Sure you can have functions in a component but they **only act on their own data**. There are no hard dependencies between components. What this means is that components are much more free to be added and removed from Entities. So how do component function together then? Well that's where Systems come in.

Systems are classes that contain the logic that makes up your game. When added to the engine they grab one or many lists of Nodes. A Node simply defines a collection of components that must exist on an Entity. In effect it declares the dependencies that this System needs to operate. What's neat about this is that this list of nodes is constantly changing as components are added and removed from entities. The Ash Engine manages this all for you so all the system need do is iterate over the linked list of Nodes each frame and execute its logic.

Systems also must not declare dependencies between each other. This rule means you don't end up with large dependency hierarchies between Systems. This frees up systems to be added and removed from the Engine with no side effects! This is rather remarkable as it lets you do crazy things that you couldn't normally do when there are many dependencies between systems. For example your game could have a Blitting based rendering system, then halfway through a running the game you could swap that out that System and replace it with a Starling based rendering System!

Thus far I have only spent a limited amount of time tinkering with Ash but I am having a whole lot of fun. I have started work on a little game to experiment around with the framework. At the same time I have been exploring [Starling](https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0CD8QFjAB&url=http%3A%2F%2Fgamua.com%2Fstarling%2F&ei=yiEdUazkL-uX0QWNz4EI&usg=AFQjCNHKL4BaeidkUlpmw48eBMwyhwG2tw&bvm=bv.42452523,d.d2k), the hardware accelerated 2D rendering framework built on Stage3D. Thus far I have produced this little map editor:

<object width="650" height="650" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="https://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="wmode" value="direct" /><param name="src" value="/projects/Mash/01/MashWeb.swf" /><param name="quality" value="high" /><param name="pluginspage" value="https://www.macromedia.com/go/getflashplayer" /><embed width="650" height="650" type="application/x-shockwave-flash" src="/projects/Mash/01/MashWeb.swf" wmode="direct" quality="high" pluginspage="https://www.macromedia.com/go/getflashplayer" /></object>
Click to place a block, shift and click to remove, scroll mouse to change block type and hold control and click to zoom in / out.

Its only a tech demo at the moment and as such hasnt got any game play elements. Im not entirely sure what to turn it into but as a platform for tinkering with Ash its been great.

Its too early to share the code at the moment but if you would like to see how some Ash code looks I strongly recommend you check out [Richard's Asteroids example on GitHub](https://github.com/richardlord/Asteroids). I was really quite taken aback by how neat and modular the code is. The example is provided in 4 different flavours, one using RobotLegs one with Starling one with SwiftSuspenders and one with no dependencies at all. The fact that the code still works and looks simple in all the examples really demonstrates the versatility of the framework :)