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:

Source code

package package2
{
	import package1.MyTestClass;
 
	public class MyTestClass2
	{
		public var type : Class = MyTestClass;
	}
}

And

Source code

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

Now try using them in the following fashion:

Source code

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

And uh oh, bad times:

Source code

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

The bad line is:

Source code

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

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

Source code

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

Then everything is gravy

Anyway, I hope this helped someone out!

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:

Source code

class MyInjectedClass
{
	public function sayHello(toSay:String)
	{
		trace("Hello "+toStay);
	}
}
 
var injector : Injector = new Injector();
injector.mapSingleton(MyInjectedClass);

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:

Source code

class MyDependantClass
{
	[Inject] public var myClass : MyInjectedClass;
 
	public function performAction()
	{
		myClass.sayHello("World");
	}
}

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:

Source code

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

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:

Source code

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

Then the dependant class would look like the following:

Source code

class MyInjectedClass
{
	protected var myClass : MyInjectedClass = inject(MyInjectedClass);
 
	public function performAction()
	{
		myClass.sayHello("World");
	}
}

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

Source code

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

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.

Its Oliver and my latest game. It was supposed to be a quick re-skin of BlastWave, but as usual “quick” was a word that got lost during development as we got excited about it and decided to add more and more features.

The Art by Oliver Pitceathly follows a simmilar style to MonkeyMines. Hope you like it!

The following is a little promotional clip done by MiniClip.com for the game, quite cute we think. Anyways stay tuned, to play the game in the next few days!

Q-BLOCK – Create 3D Pixel Art Online

Oh my this is good! An excellent use of flash and 3D! (cheers to Richard Davey for pointing this out).

Cant help making the reference to Fez:

First up is one of my favorite flash games of all time MotherLoad.

I loved the simplicity and addictiveness of this game. Basically you play a miner who digs down through the earth for minerals and then has to return to the surface to sell the minerals. With the cash you earn you can buy upgrades for you mining machine which allows you to go deeper and stay down for longer.

The graphics are simplistic but functional, giving you an easy to understand indicator of where the resources are and where you are to mine.

You can quite easily play this game for hours, getting deeper and deeper.

The iPhone version of this game is called iDigIt and is by the developer inmotion software.

The first thing you notice is that the graphics have been given a significant upgrade. I must admit I like the graphical additions, I think they give a needed boost of professionalism to the game especially if you are going to pay 59p to download it.

Once the pleasure of the new graphics wears off you start to notice a few issues.

Firstly the whole radar thing. In the original game you could mine down as far as you wanted and still see the minerals around you, in the iPhone version they have introduced a “fog of war” that shrouds your digger as you start to go deeper. You can buy radar upgrades that increase the distance you can see but I found this to have little effect as you get deeper (see screenshot to the right).The effect of this is that you cant see where the minerals are so you end up digging blindly into the dark.

Another issue is the control system. The game uses an on-screen joystick, im not a particularly massive fan of this method in the first place but its compounded by the fact that you have 360 degrees of freedom when underground. This is an issue as when digging you can only dig right, left, and down at 90 degree angles so having 360 degrees of freedom results in you often digging in the direction you werent intending. I would of liked to have seen the digging directions limited to 90 degree angles when the digger is on the ground.

As for replayability of the game, i dont think this game will have the same appeal as other games due to the fact that the only change the deeper you go is that you get higher quality minerals. There doesnt appear to be any other variation (i may be wrong here). In the flash version there were events like earthquakes to keep you interested, I would of liked to have seen this developed some more and improved on, perhaps some interesting creatures that you encounter. This would of also prevented the most efficient yet most boring tactic of just mining every single block in a strip fashion from left to right.

Overall the game is probably worth the 59p (cheap!) download but I think some of the game play features could of been extended and improved giving a richer more replayable experience.

Stumbled across this game this morning and was blown away by the beauty and complexity of the game, I dont want to think about the amount of code that must of gone into making this beast!

Play Here

We are wanting to go for a significantly more polished feel to this game and one of the factors that has been abit rough around the edges in the past has been the menu systems. As mentioned in a previous dev update were were looking to for something like Photon Storm’s Kyobi as a splash screen:

Also we have decided to jump on the micro-payments train and offer unlockable levels likely via the mochi-coins system:

For the price of about $1 you will get 20 more levels with new puzzle features. We are also considering implementing an achievements system with an in-game “best of the best” leader board, but we haven’t quite worked out where to put that yet

Now the game is mostly feature complete its onto the slow laborious process of trying to find sponsors for the game.

Im off to France for 10 days tomorrow however so apart from a few emails, work will have to be suspended on this project for a little while. When I return I shall be starting at my new job (more on that when im back!)

My partner in crime Oliver P has just  released a little game. Its catered for a very specific, yet popular, crowd. Yes yes its a dress up game, but it has very nice graphics so I think its definately worth a mention