Flash Posts

Tinkering With Ash

Last October I was fortunate enough to attend the excellent Try Harder conference for the second time. I have spoken before 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 which led to my Recursive Chrome Extension.

Before I go any further I should mention that there is a Try Harder ‘Level Up’ 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:

logo

 

What is Ash? Well direct from the Ash Website:

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:

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.

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, the hardware accelerated 2D rendering framework built on Stage3D. Thus far I have produced this little map editor:


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

1046: Type was not found or was not a compile-time constant

Came across this little oddity the other day. Took me ages to work out what was going on, so thought I would share in case anyone else ran into the same issue.

One day, for a reason I couldn’t fathom, my project stopped compiling. I kept getting these odd “1046: Type was not found or was not a compile-time constant” errors all over the place. Not only that, when I tried to include the class in question either via auto-complete (control & space) or via manual import the error persisted.

To cut a long story short it seems that if you try to new a member property that is of type Class from another class and the constructor takes in at least one parameter the error will occur.

So for example take the two following classes:

[codesyntax lang=”actionscript3″]

package package2
{
	import package1.MyTestClass;

	public class MyTestClass2
	{
		public var type : Class = MyTestClass;
	}
}

[/codesyntax]

And

[codesyntax lang=”actionscript”]

package package1
{
	public class MyTestClass
	{
		public function MyTestClass(someVar:String)
		{
			trace(someVar);
		}
	}
}

[/codesyntax]

Now try using them in the following fashion:

[codesyntax lang=”mxml”]

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" 
			   xmlns:s="library://ns.adobe.com/flex/spark" 
			   xmlns:mx="library://ns.adobe.com/flex/mx" creationComplete="application1_creationCompleteHandler(event)">

	<fx:Script>
		<![CDATA[
			import mx.events.FlexEvent;			

			protected function application1_creationCompleteHandler(event:FlexEvent):void
			{
				var class2 : MyTestClass2 = new MyTestClass2();
				var class1 : MyTestClass = new (class2.type)("hello");
			}

		]]>
	</fx:Script>

</s:Application>

[/codesyntax]

And uh oh, bad times:

[codesyntax lang=”php”]

1046: Type was not found or was not a compile-time constant: MyTestClass.	FlexBugExperiment.mxml	/FlexBugExperiment/src/main	line 14	Flex Problem

1046: Type was not found or was not a compile-time constant: MyTestClass2.	FlexBugExperiment.mxml	/FlexBugExperiment/src/main	line 13	Flex Problem

1180: Call to a possibly undefined method MyTestClass2.	FlexBugExperiment.mxml	/FlexBugExperiment/src/main	line 13	Flex Problem

[/codesyntax]

The bad line is:

[codesyntax lang=”actionscript”]

var class1 : MyTestClass = new (class2.type)("hello");

[/codesyntax]

If you take away the “hello” part or you split it out into two lines like so:

[codesyntax lang=”actionscript”]

var tmpC : Class = (class2.type);
var class1 : MyTestClass = new tmpC("hello");

[/codesyntax]

Then everything is gravy

Anyway, I hope this helped someone out!

Funk IoC – A New Dependency Injection Framework

Twitter can be a funny beast, what makes it great can also make it poor. I use Twhirl which keeps me updated any time one of the people I follow tweets about something, the only problem is that so many people tweet that if I dont happen to see it within about and hour or so of the Tweet, ill miss it. This time however I was lucky enough to catch a tweet by @Joa about his new Inversion of Control and functional-programming-like library, Funk AS3.

As I have been getting well into RobotLegs (a Dependency Injection MVCS framework) recently I was extremely interested to hear about this new project by Joa who I respect very much as a brilliant coder not least because of his excellent work on low-level Flash byte-code optimisation (see Apparat).

Joa has taken a different approach to doing dependency injection. The approach most frequently used (and the one used in SwiftSuspenders / RobotLegs) is to use meta-data to declare to a number of variables for injection. You then map a class to be injected and instantiate it using the injector.

As an example, with Swift Suspenders you would define a class for injection with something like the following:

[codesyntax lang=”actionscript3″ lines=”normal” tab_width=”4″]

class MyInjectedClass
{
	public function sayHello(toSay:String)
	{
		trace("Hello "+toStay);
	}
}

var injector : Injector = new Injector();
injector.mapSingleton(MyInjectedClass);

[/codesyntax]

Here we are telling the Injector to make a single instance of our class and hold it internally ready for when it is next requested, such as:

[codesyntax lang=”actionscript3″ lines=”normal” tab_width=”4″]

class MyDependantClass
{
	[Inject] public var myClass : MyInjectedClass;

	public function performAction()
	{
		myClass.sayHello("World");
	}
}

[/codesyntax]

Here the [Inject] meta-data indicates that we want the framework to supply the class with an instance of type MyInjectedClass. The final part is to make an instance of the dendant class and inject into it:

[codesyntax lang=”actionscript3″ lines=”normal” tab_width=”4″]

var dependant : MyDependantClass = new MyDependantClass();
injector.injectInto(dependant);
dependant.performAction();

[/codesyntax]

As you can see this is a nice way of handling inter-module dependencies in your code, when coupled with a MVC framework such as RobotLegs it becomes and extremely powerful yet elegant way of coding.

It however isnt perfect and Joa, on his google code page mentions three drawbacks of this method:

  • Your injected properties are publicly exposed and mutable.
  • describeType is very expensive.
  • Steep learning curve.

This is where he suggests his alternative method, which is quite ingenious. Using the same example as above you would see something like the following:

[codesyntax lang=”actionscript3″ lines=”normal” tab_width=”4″]

class MyInjectedClass
{
	public function sayHello(toSay:String)
	{
		trace("Hello "+toStay);
	}
}

bind(MyInjectedClass).asSingleton();

[/codesyntax]

Then the dependant class would look like the following:

[codesyntax lang=”actionscript3″ lines=”normal” tab_width=”4″]

class MyInjectedClass
{
	protected var myClass : MyInjectedClass = inject(MyInjectedClass);

	public function performAction()
	{
		myClass.sayHello("World");
	}
}

[/codesyntax]

And making an instance of it could be as simple as:

[codesyntax lang=”actionscript3″ lines=”normal” tab_width=”4″]

var dependant : MyDependantClass = new MyDependantClass();
dependant.performAction();

[/codesyntax]

As can be seen there are some benefits to this method, the biggest one in my opinion is that injected properties dont have to be public as they are provided by the call from within the class scope rather than from outside.

So how does Joa perform this magic? By abusing a little used ability of the Actionscript programming language known as package-level-functions. These are throwbacks from the old AS1 & AS2 days of global functions. There are actually a couple of common examples in AS3 still such as getTimer() and getQualifiedClassName() still used. What Joa has done is to use these package level functions as a method of generating concise looking code reminiscent of functional programming.

Performance wise, im not entirely sure whether by using package-level functions instead of describeType() calls used in meta-data driven IoC frameworks is any faster as Till Schneidereit of Swift Suspenders suggests:

I don’t think that Funk’s approach is any faster than an optimized
metadata-based IoC container: describeType may be slow (as in “takes a
few dozen microseconds to run”), but is only ever called once for each
class an instance of which is injected into. After that, it’s just a
straight iteration over an array for all injection points instead of
Funk’s multiple method calls for each injection point.

So the next step for me is to run some tests to see how things pan out. Either way im very impressed with both approaches and cant wait to see what kind of exciting advances will be developed in the coming months.