I will say this right away, I’m biased towards Parsley and have advocated its use for over a year and a half now.  It has time and time again proven itself a reliable, robust and rapid framework for application development.  Its track record is quite impressive;  It was used to build some of the world’s largest Flex applications.  Jens Halm, the creator of Parsley, has done a wonderful job at making his framework extensible, fast and optimized for both Flash and Flex.  Robotlegs is also a good framework, don’t get me wrong, it just doesn’t capture me as much and it’s not optimized for Flex (pure Actionscript), but  in the end it comes down to your development preference.

Now to ask the question, which pattern we use for our project? Presenter or Mediator?  Parsley is built around the Presenter pattern while RobotLegs uses Mediator.  Simply speaking, the difference between the two is fairly minimal, but can affect your project quite a bit.  Here’s a quick diagram on how they work:

If you remember your UML class diagrams, you would see that a Mediator can only have one View, while the View can have many Mediators.  In this case, the Mediator is the ‘man-in-the-middle’ since nobody else knows about it; its sole purpose is to listen to the View and give it data.  The View communicates with the Mediator through events to which the Mediator acts upon.  One thing I like about this pattern is that it forces developers to use a proper “data in, events out” methodology and separates the concerns of the business from the View.  This also creates decoupled components since there’s no hard dependency in the View; it could still fully function if it is moved into another project.

For the Presenter, things are a bit different since the View knows about it.  The Presenter is there to just present data which is easily binded within the View, but this is problematic since it’s coupling your View to that Presenter and even the model (data).  However, you don’t need to use events within the View to communicate to your Presenter since you can access its public functions directly.  It’s easier to use this method because it limits the code needed to communicate between the View and the Presenter, but it’s coupling your View.

In the diagram, you might have noticed that with a Mediator pattern you can have a View with several Mediators and even reuse the Mediators on other Views.  This makes the Mediator more of a View based pattern.  The Presenter however doesn’t care and a View can have multiple Presenters which can (and should) be reused across multiple Views to display the data they need.  This makes the Presenter more of a data based pattern since it’s job is to give access to data and manage it.

There you have it.  One thing to remember is that patterns are meant to help you develop, not make it harder.   Since I love Parsley so much and had a need for a Mediator pattern for a project (needed to decouple the component) and Parsley only provides a Presenter pattern, I extended the framework to include a Mediator tag. It’s completely open source and now on GitHub.  Enjoy.

This is very exciting news for many reasons, but not only for game developer;  Flash and Flex developers could use the technology to their advantage.  With a full graphic API at your disposal that can write directly to the GPU, a developer could go a little crazy.  Most people think games when they hear 3D, but since we can write directly to the hardware, it also means more complex graphs or animations that doesn’t eat up CPU resources.

When the demos were shown, the graphics were impressive.  PS2 type of 3d quality and very smooth.  In some of the better examples shown (a driving game), the polygon count was over 100k but the CPU utilization was only 1%.  If this was software rendered instead, the polygon count would have had trouble going over 10k and the CPU would be fully utilized to keep up.

However, this new API means another learning curve to the whole process and not only on the software front, but also on the hardware front.  A developer needs to understand how Flash communicates with the hardware to be effective.  For instance, the GPU cannot render over normal display list graphics.  This is a limitation that is very important to know.  The short answer for the reason of this limitation is to reduce system bus congestion; you wouldn’t want to send over information to the GPU, render it, send it back to flash, overlay on top and send it back to the GPU.  It’s only one way, hence a UI can be overlaid on top of a 3D rendered scene, but not vice versa.  Also, since this is hardware based, there is no ‘retained’ mode of rendering.  What this means is that the 3d stage gets re-rendered every frame, unlike the normal display list which only gets re-rendered when something changes.

When wanting to create your scene, you need to add a new class to the stage called Stage3D.  This is an object that runs separately from the normal stage (and display list).  You then need to add a context to that stage, and draw whatever you want to that context.  It’s pretty easy, but remember this is a very low-level API.  You’ll able to just draw a 3D object with it, for that you need a 3D framework that will draw all the triangles properly.  For that, there are many out there that are already taking advantage of Flash 3d, like Alternativa and Flare.

A cool feature about Flash 3D is that it can render to many rendering layers like DirectX 9 (and up), OpenGL 1.3, OpenGL ES2 (for mobile) or just plain old software rendering.  This can be set manually or Flash can choose automatically which one is best.  This is particularly important if you’re making games that are played by both desktop and mobile.

You can also use Adobe’s “Graphic Assembly Language” to make your own low-level code for the video card and do some funky things that you wouldn’t be able to out of the box.  It’s a very nice extension for hardcore hardware developers.

For now, Adobe is only concentrating on the rendering aspect of it, but are thinking of adding more features that would make development even easier, like support for 3D audio, physics and other gaming features.  All of this will be coming out with the next version of Flash Player in mid 2011 with a beta to be released “soon”.

I’m a fan of Flash, but like most things in life, it isn’t perfect.  Flex and Actionscript have been an integral part of my career and I would like them to continue to be so.  I would like to touch on certain concepts that I think would add more value to the current software offerings and in turn give Adobe an edge over the competition.

Time is an important asset for a company, which is why increasing development efficiency will be a key factor in winning this war. I’m talking about reducing the compiler time, making it smarter and bug free, and adding 64bit support to utilise workstation performance. This improvement can save valuable minutes or even hours depending on the developer.

Speaking of development efficiency, I also suggest that Flash Builder starts supporting Linux.  Adobe doesn’t even have to officially support it, just make sure the eclipse plug-in can work in a Linux environment with or without design view (I personally never use it).  The feature request for having Flash Builder on Linux is one of the most popular requests on the Adobe bug tracker.

Irritations while using Flash products also need to be eliminated. I personally enjoy development work (geek alert!), but when something doesn’t work like expected, it frustrates me to no end. The Flex framework is fairly good at doing exactly that; it’s supposed to save time, and it does, but there are some components that have been buggy ever since its inception and they aren’t being fixed.

The next point is cause for debate between developers, in the end it comes down to preference, but it needs to be addressed. Of course, I’m talking about Cairngorm – or more specifically your decision to support it. I personally don’t think MVC is the pattern to use when handling a Flex application, and other developers in the community agree; hence the creation of several new open- source frameworks. It seems to me that Adobe is playing favorites with Cairngorm and could instead use that development effort in a more productive way.  Adobe should work on enhancing the Flash API and opening up doors to allow third party frameworks to improve their usability.

With complex applications come crucial new ways to design the flow and interaction within the system.  For that, a developer needs tools to show this visually.  Tools like wireframe UI timeline or UML round-trip engineering can combine both design and functionality in a uniform way that all developers can understand.  A lot could be learned from Java and their tools: e.g. offering code hot-swapping to greatly reduce debugging time.

If Adobe is serious about creating a developer language, then a more complex language needs to be their goal.  Multiple-inheritance, polymorphism, overloading, enumerators, abstract classes, destructors, private constructors, decimal data type, threading support – these are only a few of the things that Actionscript is lacking. Some would argue that there are a lot more. I’m not saying it’s a bad language, after all, it does do what it’s supposed to do, but with bigger systems come more architectural complexities that the current language cannot support.

A common topic when debating Silverlight vs Flex is the lack of multi-threading.  I really do hope that this will be implemented in the next iteration of the language because the possibilities it would open would be mind-blowing.  Imagine a system that can execute complex algorithms and computations without disrupting the user experience; that would be a major improvement! Heck, even if the language doesn’t give developers access to threads, just allowing the player to run different threads for visual components and for computations would be a great improvement.

Let me leave you with this: I’ve been a fan of Adobe since I was a kid, and I still am. If any business is capable of surmounting the upcoming challenge, it will be Adobe. I believe that the community surrounding this product will be a key factor in this war; if Adobe listens and responds to our suggestions, only great things can happen.

Speaking of community, I invite all developers and designers to debate and comment on this topic. I think it is one that will be talked about for quite some time to come.  I’d also like to thank Joe Morrison, a Director at Lab49, for letting me bounce ideas off of him.

Ever since I started developing Flex, the only real Enterprise level framework out there that was tried and trusted was Cairngorm.  It tries (emphasis on tries) to implement an MVC pattern in your projects so that it’s easier to manage and reuse your code.  However, something I’ve noticed over the years is that Adobe Consulting, the people that made Cairngorm, are not exactly great developers.  This is very apparent with the framework they put out because even though they say that it’s an MVC framework, it is not.  It’s very far from a good MVC pattern, but since it was the only one out there, a lot of developers didn’t have a choice other than creating a new one from scratch.

Fortunately, this has recently changed with a plethora of new frameworks that actually do implement MVC properly.  The two most notable are Swiz and Mate.  Both are really good, however only Mate utilizes Flex to its full potential since most of it can be done with MXML.  It makes it very easy to use and actually quite fun to code with.

In the spirit of supporting and using this fine open source project, I registered another channel on Freenode called #flex-mate.  This would be an open discussion channel about the Mate framework.  If you’re in any way related to the Mate framework, I strongly suggest you come visit the channel and support this amazing project.