another project just went online this week, in which i was involved: Drive and Seek – The Prologue. Together with Harald, who was the lead here, we were responsible for the development. I took special care of the interface to facebook and the customization features of the end video, in which you can put your own picture either by uploading one or via webcam.

It was a fun project, going for a about a month.

What did i learn? First of all, i have mixed feelings about robotlegs. I like the DI part, but i cannot get used to these top-down mvc structures, which seem to put too much emphasis on infrastructure and too little on conceptual entities. I have to admit, that robotlegs technically does not tell you how to structure your application, but the best practices documentation does promote the approach of using mediators, commands and so on and tying it all together via bunch of events. This sounds all nice in theory, in practice for me, it is too technical and does not reflect the individual, conceptual relations of the components and modules i like to build. But this is stuff for another post.

I do like the Facebook API, although its documentation leaves a lot to be desired. The JavaScript SDK is nice and after fighting with the Facebook ActionScript library initially (couldn’t get it to initialize reliably), i soon abandoned it and used the JavaScript SDK directly via ExternalInterface.

it doesn’t happen that often, that you work on a project for some time and finish it as smoothly as you started it. That happened to me while developing the jump ‘n run game Lego – builders of infinity. Working with the nice people at Plan.net here in hamburg, we just finished this project together (If you like it, you might want to express that with a vote?).

Update: Nice: Just got notified, that the project won a silver lion in Cannes!

Update 2: Double nice: FWA site of the day.

Update 3: Triple nice: Dope Award

This took roughly two months. It’s based on Flash Player 10 and uses the Box2d wck alchemy port. Its basically two apps: the game and the microsite. You can embed the game in your own website or blog, if you like.

The whole project consists of 103 ActionScript files (mostly classes) and around 6640 lines of code (no comments, no blanks, no libs).

The most challenging thing was, that Box2D has issues with letting boxes slide over a set of other boxes. From time to time, the box sticks at the edge from one underlying box to another, even if they are perfectly aligned. I first used the “normal” Box2D Flash port, but as it seems, there has not been a lot of development going on there, lately. So i switched to the Box2D wck alchemy port, which requires Flash Player 10. That port is more up to date with the original C implementation and thus can take advantage of some changes, which help fix the sliding issue. You can now cut off the corners of your boxes and thus let it slide over the corners of two adjacent boxes (which actually don’t exist, but as i said, box2d thinks they do exist). This trick does not work in the old “normal” Box2D Flash port.

Hope you enjoy the game.

i am currently involved in a fun project, where i am told to build a classical jump ‘n run game. Very nice. I am using the flash port of Box2d in its version 2.0.1. I know, that there is version 2.1, but it’s still alpha and i generally do not feel so comfortable using alpha software.

Like in most jump ‘n run games, we have moving obstacles, like little bricks, that move from left to right and back again and you have to jump on them to get over a giant abyss.

Now these moving bricks should move autonomously and indefinitely. Being a flash developer, first thing, that comes to mind is tweening them. But as we learn from many sources in the box2d community, this is actually a no-go, because we should rather use velocities and the real physics of Box2d to make things move. Makes sense to me.

So my first attempt was to reuse some of the smart scripts from Todd. And that worked quite well. Here is an excerpt of the script (actually with slight changes from my side), that will run in the usual world update method (box2d specific):

if(currentPosition.x >= initialPosition.x + movementDistance) {
   _direction = -1;
}else if(currentPosition.x <= initialPosition.x) {
   _direction = 1;
}
 
var idealLocation:b2Vec2 = new b2Vec2(currentPosition.x + (_direction * (TRAVEL_SPEED / PhysiVals.RATIO)), initialPosition.y);
var directionToTravel:b2Vec2 = idealLocation.Copy();
directionToTravel.Subtract(currentPosition);
directionToTravel.Multiply(30);
_body.SetLinearVelocity(directionToTravel);

So looking at this, after a while i thought, idealLocation is a point, that changes on every box2d world step and reflects the position, where the body should be. Isn’t that the same thing, that a tweener does? Of course, it is.
So changing this script to use a tweener like TweenLite or something is pretty easy. In my case, i am using TimelineMax, because i want to let my body to move back and forth infinitely (code simplified):

private var positionTracker:b2Vec2;
 
private function initialize():void {
   positionTracker = initialPosition.Copy();
   timeline = new TimelineMax({repeat:-1});
   timeline.append(new TweenLite(positionTracker, 1, {x:initialPosition.x + movementDistance}));
   timeline.append(new TweenLite(positionTracker, 1, {x:initialPosition.x}));
}
 
private function onWorldUpdate():void {
   var currentPosition:b2Vec2 = myBody.GetXForm().position;
   var directionToTravel:b2Vec2 = positionTracker.Copy();
   directionToTravel.Subtract(currentPosition);
   directionToTravel.Multiply(Environment.TIME_STEP);
   myBody.SetLinearVelocity(directionToTravel);
}

So, what is happening here? Well, we keep a helper object, the positionTracker. This is our object, that gets modified by our tweener. It is a b2Vec2 instance, which has x and y attributes. We give the positionTracker our initialPosition of our box2d body. Then we create our tween, just the normal way we always use tweens. But we use our positionTracker with it.

Now, somewhere in our program we usually have a world update method, because that’s how Box2D works. And here we simply use the approach Todd uses in his tutorial, we take the current position of our body, calculate the difference from our desired location (which now is the location our tweener has calculated) and the current location and build a velocity vector from it, which we then set to our body.

The result is a crystal clear animation just the way we have defined it in our tween. But since we are setting a velocity, our body is still open for other forces, that have an impact on it. So in my case, when my character jumps on the brick, the brick eases off a bit, but quickly goes back on its path, which is a rather nice behavior, i think.

today i release a little library i have been working on for quite a while. It contains three little class collections, i have used in the past and i thought, they might be useful for some.

CommandCollection is a little ActionScript 3 library around using commands. It includes three tools:

• Process
• BranchProcess
• StateMachine

Process is essentially a queue, in which you can put commands (synchronous or asynchronous), which will be executed sequentially.

BranchProcess is similar, but allows you to build a tree of commands with the ability of one commands result having an impact on which command comes next.

StateMachine is a classical finite state machine, that supports input commands for each state and is navigable. Means, you can aim for a state and the state machine will calculate a path to the target state and will try to reach it.

CommandCollection comes as .swc for integration into your project. Go check it out at http://code.google.com/p/command-collection/.

i just recently stumbled upon this little gem: MouseEvent.relatedObject. It turns out, it already exists since FlashPlayer 9.0, but i missed it. It is a pretty useful property. In a nutshell, it holds a reference to the object, which either lost or gained focus during mouse over or mouse out respectively. So i thought, i make a little example:

package {
 
   import flash.display.Sprite;
   import flash.events.MouseEvent;
 
   public class HelloWorld extends Sprite {
 
      private var panel:Sprite;
      private var button1:Sprite;
      private var button2:Sprite;
 
      public function HelloWorld() {
 
         panel = new Sprite();
         panel.graphics.beginFill(0x777777, 1);
         panel.graphics.drawRect(0,0,200, 150);
         panel.graphics.endFill();
         panel.x = 50;
         panel.y = 50;
 
         button1 = createButton(0xff0000, 100, 100);
         button2 = createButton(0x0000ff, 100, 120);
 
         panel.name      = "Panel";
         button1.name   = "Button 1";
         button2.name   = "Button 2";
 
         addChild(panel);
         addChild(button1);
         addChild(button2);
 
         addEventListener(MouseEvent.MOUSE_OVER, onMouseOver);
      }
 
      private function onMouseOver(event:MouseEvent):void {
         trace(
            "Mouse now over: " + event.target.name +
            ". Used to be over: " + (event.relatedObject != null ? event.relatedObject.name : "n/a")
         );
      }
 
      private function createButton(color:uint, x:int, y:int):Sprite {
 
         var result:Sprite = new Sprite();
 
         result.graphics.beginFill(color, 1);
         result.graphics.drawRect(0,0,100,20);
         result.graphics.endFill();
 
         result.x = x;
         result.y = y;
 
         return result;
      }
   }
}

Instead of explaining everything, simply take a look at the result (in which i added a textfield, so you can see the traces). You will see, that whenever you roll on the panel from the main stage (which is colored in this aesthetically bright yellow), the relatedObject is null.

you probably know this setting perfectly well:

package {
   public class Example {
 
      private var myDispatchingObject:DispatchingObject;
 
      // ...
 
      private function createSomething():void {
 
         myDispacthingObject = new DispatchingObject();
         myDispatchingObject.addEventListener(SomeEvent.COMPLETE, onDispatcherComplete);
         myDispatchingObject.start();
 
         // ...
      }
 
      private function onDispatcherComplete(evt:SomeEvent):void {
 
         if(evt.something == true) doSomethingImportant();
      }
 
      private function doSomethingImportant():void {
 
         // ...
      }
   }
}

This class is very simple, it has an object which apparently dispatches an event. You add yourself as a listener and implement an event handler.

You also know, that if your class uses a bunch of objects, which dispatch events, your own class becomes littered with event handler methods. Here’s a thought i just had, which aims for making this a bit more readable (which in the end is the opposite of being new. I just noticed, that for some reason, i have stopped doing it this way in the past):

The purpose of an event handler should be:

• check, if the event is relevant.
• If yes, call some functionality.

Now, this is important. If you do not agree with these two things, you don’t have to read any further. A lot of times, we tend to put more into our event handlers, than these two things. But we shouldn’t, because all the additional functionality is then bound to that event. As soon as you recognize, that you might want to call that functionality at another point in time, too, you will separate the handling part from the actual functionality anyway.

So, if you’re still with me, you will probably also agree, that you never want to call the event handler function directly, because it is purely meant to be invoked by, well, an event.

So i thought, why actually defining it as a class member? If the whole purpose is for wiring an event to another function, wouldn’t it be more appropriate to use an inner function instead?

[Update]: OK, that was quick. As Hristo points out, this whole thing makes no sense, if you ever want to remove yourself as a listener and don’t want to do tricks like using arguments.callee. Bummer.

Let’s rewrite the above example accordingly:

package {
   public class Example {
 
      private var myDispatchingObject:DispatchingObject;
 
      // ...
 
      private function createSomething():void {
 
         myDispacthingObject = new DispatchingObject();
         myDispatchingObject.addEventListener(SomeEvent.COMPLETE, function (evt:SomeEvent):void {
            if(evt.something == true) doSomethingImportant();
         });
         myDispatchingObject.start();
 
         // ...
      }
 
      private function doSomethingImportant():void {
 
         // ...
      }
   }
}

By the way, i was a bit astonished at first, that it works this way. Like, that doSomethingImportant() is available within the inner function. Seems like closures do not only have access to their parent function, but also to class members. I think, that used not to work in the past, or am i mixing things up?!

Anyway, doing it this way, has a couple of advantages in my opinion:

• The wiring of the event becomes directly apparent and it happens at a place, you would search for anyway, because the DispatchingObject is created there.
• Since the event handler function is now an inner function of the createSomething method, it cannot accidentally be called directly.
• All methods in the class are ones, that are valid to be called. No litter of event handler methods.

So, again, this not new at all, but i know a lot of developers, who have not been doing event handlers this way for ages anymore (including me). You might say, that using inner functions brings a bad smell with it. But perhaps this is just a “i’m not used to this” feeling?!

today i was juggling with Events quite a bit. By the way, isn’t it odd, that EventDispatcher does not reveal its listeners? At least to its subclasses? Or at the very least have some kind of “removeAllListeners()” method (like Robert Penner already noticed)?

Anyway, i was thinking: Events in Flash are all over the place nowadays. You use them in DisplayObjects, in your classes and also Flex has them everywhere. The good thing about them is, they could make threads needless. I sometimes see some developers shout for threads in Flash and i want to shout back: “Are you kidding?” To whomever Java developer i speak to, they all say, handling threads is a mess. I have no practical experience myself, but i know the basics of threads in Java. Events come to the rescue. They are easy to understand and to handle. It would only take the ability to dispatch an Event, which only fires AFTER the return of the method, that wanted to fire it. This way, we would be able to avoid weird issues like: “ClassA instantiates ClassB, adds itself as a listener to ClassB, but ClassB already fires an event in its constructor” (yeah, i know, not the best example, but i hope you get the point). And all the multicore and threading stuff could be managed in the background.

I think, Events should become first-class citizens of the ActionScript language at long last. It would allow for some cool new ways of expressing things. Imagine this:

package {
 
   import flash.events.Event;
   import com.sample.CoolEvent;
   import org.sample.OtherEvent;
 
   public class Example dispatches CoolEvent,OtherEvent {
 
      private listener myListener:EventFromCoolOtherClass.STARTED;
 
      public function Example() {
 
         init();
      }
 
      private function init():void {
 
         someOtherClass = new CoolOtherClass();
         myListener = someOtherClass >> someHandlerMethod;
 
         // blah, doing stuff
 
         dispatch async new CoolEvent(CoolEvent.COMPLETE);
      }
 
      private function someHandlerMethod(evt:Event):void {
         myListener = null;
      }
 
      // ...
 
      private function someOtherFunction():void {
 
         // blah, doing more stuff
 
         dispatch new OtherEvent(OtherEvent.STOPPED);
      }
   }
}

These are just some thoughts, that came out of my head within the last hours. For example, it would be nice to be able to define officially, which events a class dispatches. And if you define it in the class header, you have to implement the dispatching, otherwise you’d get a compile time error (we could need this for errors as well, by the way, but different story). Then the ‘listener’ property. It works a bit like a pipe. Yo specify the listener and give it the Event type, you’re interested in. And in code you wire the dispatcher together with your handler method. Simply unwire by setting the listener to null.

Dispatching an event is almost like today, but you have the async option, which let’s the init method return, before the event is fired, which releases the stack (only works, if dispatch is the last statement in the method body, of course).

Probably i have forgotten some details, which might make these things not work the way i imagine, but anyway: Events should finally become a part of the ActionScript DNA.

today i stumbled upon a weird bug in the mxmlc compiler. I filed a bug, which turned out to be a duplicate of an earlier report here.

It basically goes like this:

Say, you have a swf file, which wants to spread its classes over multiple frames (if you read my previous post, it might sound familiar). So, to keep things simple, let’s say, you want to have two frames, each holding one class, let’s call them FirstFrameClass and SecondFrameClass. And additionally this swf file uses an external library, means, a .swc that should NOT be compiled into our .swf. Let’s assume, in that .swf there is one class, we call it LibraryClass.

Now the weirdness starts. If FirstFrameClass references LibraryClass, LibraryClass gets compiled into our resulting swf, although we specified the library to be an external one (using external-library-path in the compiler configuration). If instead SecondFrameClass references LibraryClass and not FirstFrameClass, LibraryClass gets NOT compiled into our resulting .swf file, just the way we want it.

In the end, the issue is, only if you reference a class from an external library in a class, which sits on the last frame of your own .swf file, the external-library option works, otherwise it is simply ignored.

In the bug report it says, the issue will be resolved for the upcoming Flex Hero release. I tested with the current build, but the issue is not resolved yet (which makes sense, because the bug entry in Adobes bug tracker is not set to Resolved yet).

If you find this as weird as i do, please vote for the bug.

i know, everybody hates Singletons, and i do, too. But i find it an entertaining exercise to come up with new ways of circumventing the lack of private constructors for Singletons. Today this new one came to my mind:

First, we define an Interface, which specifies, how our Singleton should look like:

IMySingelton.as:

package {
	public interface IMySingleton {
		function doodle(something:String):void;
	}
}

Ok, next we define our Singleton.

myInstance.as:

package {
	public var myInstance:IMySingleton = new MySingleton();
}
 
class MySingleton implements IMySingleton {
	public function MySingleton() {
		trace("MySingleton is now there!");
	}
	public function doodle(something:String):void {
		trace("yippee: " + something);
	}
}

Very simple, isn’t it? We could optionally also go without the Interface, but then we loose code completion in our editors, because the class MySingleton will be ignored by most editors, although it would compile and run just fine. I do agree, that this is not really exactly the idea of a Singleton, because it has no getInstance() method, but in the end, the result is the same, we only have one global instance of MySingleton.

And since the variable is already global, we don’t even have to declare it in our class, we can directly use it:

Main.as:

package {
	import flash.display.Sprite;
 
	public class Main extends Sprite {
		public function Main() {
			myInstance.doodle("loodle");
		}
	}
}

now, that this flash / iphone thing is closed, Adobe, can you please make sure, that Flash Player 10.1 on Android will be nothing else but mind-blowing? You know, not like “it works OK”, but more like “wtf, is this flash? you’re kidding. this is flash? Can’t believe it, this is sooo fast!”. It doesn’t matter matter, if it takes another month, but please get this right.