May 22, 2008
New FREE Multiplayer API for Flash Developers
Wow talk about cool. The dudes over at http://nonoba.com just released a free multi player API for Flash developers!
"The API supports the full range of multiplayer games, from simple turn based games to more complicated real-time games. To show these capabilities, we have released a new, and in our opinion, awesome game called Nonoba Racer. We have also ported some of our old creations to act as examples in the SDK, such as Fridge Magnets, Multiplayer Asteroids and DrawPad.
We want to make all the things that are currently hard for flash game developers dead easy. Our hosted Multiplayer API is the first big step in that direction. We've got more APIs in mind to fix the rest of the stuff that we think is currently too hard."
To sign up: http://nonoba.com/developers/multiplayerapi/signup
For more info: http://nonoba.com/developers/multiplayerapi/overview
Posted by erikbianchi at 09:32 PM | Comments (0)
October 17, 2005
Live from Max
So I’m chillen at the community lounge just hanging playing with Flex 2 and Flash Player 8.5. As cool as some of the sessions are, I am way more excited about playing with the public alpahas that macromedia released today then I am anything else.
Sitting here hacking away at max is pretty scwheet! I’ve bumped into some of my old friends from blitz (Ivan and John), just talked to Mike Chambers & Chafic Kazoun, hung out with some yahoo and macromedia peps and even sat next to Kevin Lynch (didn’t want to geek out on him so I didn’t say anything).
If anyone wants to hang I’m one of the only guys (minus Chafic) walking around this conference with a red Flash MX 2004 Timbuk2 bag.
BTW: comments still dead.
-erik
Posted by erikbianchi at 11:22 PM | Comments (0)
July 18, 2005
[Flash Platform] Delegates are not just for Events!
Some of you may already be familiar with the usefulness of mx.util.Delegate for events. However, you may not have realized their full potential!
Delegates are great, they resolve the scoping issue related to how functions are scoped to the invoking object. However, most examples I’ve seen using Delegates use them in events:
someComponent.addEventListener(this,Delegate.create(this, this.someMethod));
However, they can be most useful for solving other technical design issues as well:
Callbacks:
When you don’t need an event to broadcast itself to N number of listeners you can use a simple callback which will only respond to 1 object. Most callback implementations I’ve seen (and have written myself) look something like this:
class SomeClass
{
private var m_callbackObject:Object;
private var m_callbackMethod:String;
function setCallback(obj:Object, method:String):Void
{
this.m_callbackObject = obj;
this.m_callbackMethod = method;
}
function doCallback():Void
{
this.m_callbackObject[this.m_callbackMethod]();
}
}
// code on timeline
function sayHi(){
trace(“Hi!”);
}
var myClass = new SomeClass();
myClass.setCallback(this,”sayHi”);
myClass.doCallback();
// output
Hi!
While this works it is not ideal. Using a Delegate here could greatly reduce the amount of code (by 50%) which is especially useful when dealing with multiple callbacks:
import mx.utils.Delegate;
class SomeClass
{
private var m_callback:Function;
function setCallback(obj:Object, method:Function):Void
{
this.m_callback = Delegate.create(obj, method);
}
function doCallback():Void
{
this.m_callback();
}
}
NOTE: Delegate takes a reference to a function for the second parameter
Now you might find yourself going back to the first example and asking why you couldn’t use a single reference and eliminate the Delegate:
this.m_callback = obj[method];
The above code will invoke the function but that function will be scoped to SomeClass! The Flash scoping rule comes into play here because SomeClass executed the callback, that function gets scoped to the instance of SomeClass which is what Delegate resolves.
Event Handlers
Another common problem Delegate resolves is when dealing with Event Handlers such as MovieClip events, Buttons events, etc:
function sayHi(){
trace(“Hi!”);
}
function someFunction(){
this.sayHi();
}
myMovieClip.onPress = this.someFunction;
// User
myMovieClip Pressed
// output
Nothing, the “this” keyword is scoped to myMovieClip.
The above implementation shows bad design because someFunction is getting scoped to myMovieClip. So when someFunction tries to invoke sayHi it is looking for the sayHi method on myMovieClip which does not exisit. Also note that the compiler doesn’t apply these types of scoping rules so no error is ever thrown.
Another implantation I have seen (and used myself) is:
function sayHi(){
trace(“Hi!”);
}
myMovieClip.onPress = function ()
{
this._parent.sayHi();
}
This example IMO is better then the first but I am manually resolving the scope which assumes that the required function will always be on _parent. The compiler doesn't check the scope here either so it essentially ignores any reference to _parent. Using a Delegate however is a much more flexible (and compile safe) option which I find to be more readable and consistent to how other scope related issues are dealt with (consistency == good):
myMovieClip.onPress = Delegate.create(this,this.someFunction);
Also, in any of the above examples you could do some neat optimization tricks as well:
var myDelegate = Delegate.create(this,this.someFunction);
myMovieClip.onPress = this.myDelegate;
myMovieClip2.onPress = this.myDelegate;
myMovieClip3.onPress = this.myDelegate;
Some food for thought =)
-erik
Posted by erikbianchi at 08:04 AM | Comments (45)
July 06, 2005
[Flash Platform] ARP Advisory Committee Member
Just a quick note to announce that I’ve been appointed a seat on the ARP Advisory Committee!
For those who don’t know, ARP is an Open Source Pattern-Based Rich Internet Application (RIA) Framework for the Flash Platform and currently supports both Flash and Flex RIA Development in ActionScript 2.
To learn more about ARP check out: http://osflash.org/arp
For a list of current ARP committee Members check out: http://www.openarp.org/index.php?page=ARP+Advisory+Committee
-erik
Posted by erikbianchi at 06:04 AM | Comments (3)