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.

i was once again lucky enough to be able to build a fun little project. Brainbattle!

But how did it all start?

So, i occasionally give talks at the GoodSchool about technology, internet and so on. The GoodSchool is a school for new ways of communication. All things digital, social, web, etc. and it is targeted at people in the marketing world. They have lots of different events all over the year. One is “camp digital”. Seven days packed full of information, inspiration and, of course, fun things.

So, Christian from the GoodSchool this time gave me two brain sensor headsets from emotiv and asked me to build a little game with it. We decided to do a simple tug-of-war type of game.

So, how does it work?

So the setup is:

• Two emotiv epoc neuroheadsets (and their SDKs)
• Two PCs connected via a twisted Ethernet cable
• One Union Platform server (and the game control module build in Java)
• Two little client flash apps, which take the converted signals from the emotiv SDKs and send it to the server (along with game controls)
• One flash central Display app (seen in the pic above), that shows the game state.

OK, the headsets connect two their respective PC over the air via a dongle. These headsets basically read the electric signals from your brain. As you can see in the picture below, the headset has a bunch of sensors, which need to be wet (using a saline solution). The tricky part is, that the sensors ideally touch the skin, which means, you have to fight a bit with the hair of the user to get out of the way.

These signals are read from a software SDK. Part of that SDK is a “training” program. There you can basically train “actions”. Like pull, push, up, down, vanish, show and lots of others. So you train a certain action, like “pull”. For 8 seconds you think about “pull” and the programm records the signals of your brain during that time. Then if you think that thought again later, the software recognizes the pattern and knows, that you think “pull”.

Then there is a second little tool, called EmoKey. It is a simple converter. It converts an “action” into native Windows key events. So you define, that when the user thinks “pull”, it should emit a key event of the key “p”, for example. It can also do this continuously, lots of settings there.

So then i have a build a little client, which let’s you connect to the union server i have built, let the user click ready and also read those native key events. It then counts those incoming events per second and sends the result to server (every 500 ms).

The server (java) module takes those numbers from the two clients and calculates a force from it, being either positive or negative (depending on the numbers from client1 and client2). The server module of course also controls the various stages of the game, like client registering, game start, winning, and so on. The server is based on the union multiuser server, which is some nice piece of software and well documented. Its concept is around rooms and clients being in one or more rooms. The clients can send messages, set attributes on themselves or the rooms and so on. So i have created such a room, which has the game logic.

That game state is continuously send to the central flash display app, which is connected to the server as well (but only as an observer). It gets the force number and the game states and displays it.

So, that’s basically it. It took me about two and a half days to build it (and test it roughly). You can see a video of the game in action at facebook.

since i

a) was working quite a lot with Box2D lately

b) am sitting next to Lars (aka nulldesign)

today we had the idea to combine the Box2D alchemy port with Lars’ ND2D graphics engine. The result involved lots of basketballs

Caution: You need the Flash Player incubator build for this to run:

[Update]: As commenters have already pointed out, the app below doesn’t work with the current flash player anymore. I would have to update Lars’ ND2D engine to make it work again, but i currently simply feel to lazy to do it

http://ghost23.de/nd2dbox2d_demo/main.html

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.

a commenter made me aware of a bug in the Process class of my CommandCollection library, thanks for that. During fixing the bug i also fixed a wrong reference assignment for ProcessEvent.currentCommand, so now this should work as expected.

CommandCollection is now at v.1.0.1.

a little quiz again. We have three classes:

The first one is the main class of our swf, InternalTest:

package {
 
   import flash.display.Sprite;
   import testPackage.PublicClass;
 
   public class InternalTest extends Sprite {
      public function InternalTest() {
 
         var publicClass:PublicClass = new PublicClass();
         var ref:Object = publicClass.returnInternalClassRef();
         ref.doSomething();
         ref.doSomethingInternally();
      }
   }
}

Ok, in a package “testPackage” we have two other classes, PublicClass and InternalClass.

package testPackage {
   public class PublicClass {
 
      public function returnInternalClassRef():InternalClass {
         return new InternalClass();
      }
   }
}

package testPackage {
   internal class InternalClass {
 
      public function doSomething():void {
         trace("InternalClass did something!!");
      }
 
      internal function doSomethingInternally():void {
         trace("InternalClass did something internally!!");
      }
   }
}

Now make a guess, what happens?

Well, it’s not too hard to figure out, right? But interesting to remember anyway. The call for doSomething() works, whereas the call for doSomethingInternally() ends up in an exception. So if you define an internal class, you can still pass its reference outside its package (loosing the type obviously). Any public methods can be called then, but internal methods not. Makes sense, does it? I was just thinking about it, because i asked myself, why one would declare a class internal, but still have public methods.

So it only makes sense, if you want to pass it around as either an untyped reference or as a casted interface implementation. Means, you could have an interface outside the package and the internal class implements it. Then within the package you could use the class by its direct class type and outside you would use it by its interface type.

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

some weeks ago i was messing with OSGi and a possible implementation in ActionScript. That has been put aside, but one thing i noticed, was, that in the original Java implementation most of the constants were integers, using a bitwise notation. This is really not new, but i thought, it might be worthwhile to refresh the topic. Take this little example:

const first:int  = 0x000001;
const second:int = 0x000002;
const third:int  = 0x000004;

The rule is, every other constant has a value double of the previous one. With that, you can do pretty nice things.

You can have a variable, that functions as a toggle container for all your constants:

var constantsToggle:int = 0;
constantsToggle += second; // now you have turned on the switch for 'second'
constantsToggle += third;  // now you have turned on the switch for 'third'
constantsToggle -= second; // and now you have turned 'second' off again

Wanna know, if any of the switches is turned on?

if(constantsToggle) {...}

Wanna know, if a particular switch is turned on?

if(constantsToggle & second) {...}

Again, this is nothing major, but i found it useful.

arghh. Do you know the -include-stylesheets compiler option, which is specifically made for building libraries? It is a great feature, because it compiles your stylesheets instead of just embedding the css file in your swc(see update).

BUT! How are we supposed to use that wonderful feature in Flash Builder? If i add it as a compiler option, Flash Builder nags, that it does not want this option. My feeling is, that it is the mxmlc, that is speaking there, although i have a library project. But i cannot find any other place to tell FlashBuilder, that i want to use that option.

Have you found a solution to that? Please shout!

By the way, it would be so cool, if Flash Builder would not only show the classes of a library swc, but also included assets, otherwise, how am i to know, what files i can use?

[Update]: Hm, seems like that compiler option works differently than i thought. It actually does NOT compile the Stylesheet, but classes, which are referenced by that stylesheet only. Too bad.

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.