Here is my take on the issue of Stage3D/Molehill. While reading related tweets and posts, I notice a few misconceptions about Molehill – and this is something I’d like to address here.

Dude, where is my Display List?

Right from the start I felt something doesn’t feel right. If all the demos are using engines like Away3D, what’s in it for ‘plain’ flash games? Apparently, Molehill (and Flash 11) does not include GPU hardware acceleration for the Display List.

First of all a note about architecture. Flash uses a retained mode rendering model, through its Display List. It means we don’t actually draw, we place display objects on the display list (and the stage) – the rest is done by the Flash player, where the drawing actually takes place on every frame.

In contrast, Moelhill API  is a thin wrapper for OpenGL  (or Direct3D in some cases) that provides low level drawing of 3D geometry and textures, including programmable shaders. It exists outside of the flash stage, almost as a standalone system. It is not designed to support, or implement drawing of display objects.

While not without its problems, the flash display list is the core feature of Flash: a simple and easy to use scene graph that gets processed and rendered on every frame. Its what makes Flash Flash: you would not want to imagine building any games or applications without it.

Catching up to current technologies

This year we started seeing GPU hardware acceleration in JavaScript/CSS, although not on all browsers. Browser have rendering engines that can accelerate primitive drawing for vectors and font when rasterizing them to canvas. I would expect no less from the flash player.
The days when non-accelerated Display List was sufficient for developers are over. Here is what Ben Garney, a flash game heavyweight, says on his blog:

[...] I use the display list for lots of things, just like any Flash developer. It’s a useful, flexible, and powerful tool.

But when I have specific, performance oriented needs, I ditch it in favor of something I can control completely. That’s why I always use a raster pipeline – drawing all my own pixels – for my game rendering. Using BitmapData.copyPixels has a consistent, reliable cost, whereas the cost of drawing a DisplayObject hierarchy, either on stage or via draw(), is highly variable and difficult to predict in terms of both memory and CPU consumption. [...]

So developers like Ben Garney are opting to write their own renderers in order to gain better performance, but that is not an ideal long term solution. A much better one would be to utilize both multi-threading and GPU hardware acceleration for the standard flash Display List.

Hello 1993

For me, this is Deja vu all over again. It brings memories of the early 90s, were all we had was raw OpenGL or DirectX, and programming 3D was considered a black magic, some sort of witchcraft. We had to use special bitmap fonts and skimp on UI features for games, because everything was done in low-level, with no component libraries to speak of.
A lot has changed since then, both in technologies and standards. Are we are expected to use the low level Molehill or use a Molehill based 3D engine for any plain old 2D project?

1993 Ford Mustang

Bringing GPU acceleration to a small subset of flash applications just won’t cut it. Casual games that make a large part of Flash projects, need fast performing 2D display as well as complex UI. Forcing developers to shoehorn Molehill into any 2D project is just wrong. It’s not a good solution and would push more Flash developers to jump ship and look for alternatives.

GPU Acceleration for All

Don’t get me wrong: I am a 3D enthusiast myself, and did a lot of 3D programming on different games way before I started using Flash – and 3D API in flash is better than none. I simply don’t like the idea of having to choose between hardware acceleration or the Display List and not both of them together.

The next logical step for Adobe would be to build GPU hardware acceleration into the Flash Display List, so that the bottleneck of scene rendering would be removed. Yes, it carries some risks since Flash would become dependent on display driver vendors to run consistently on different platforms, but surely this can be resolved by partnering with nVidia and AMD. If done correctly, any existing AS3 code would be accelerated without any changes.

Last month I participated in the Toronto Game Jam, where game developers make a game over one weekend. The game ‘Pileup’ was made that way, with most coding done during the TOJam. This is a detailed postmortem of the game ‘Pileup’. You can read more about my TOJam experience on a previous post,  ’Things I Learned in TOJam‘.

[]

Play Pileup

What Went Right

The Development Platform

Pileup is a game built on the Flash platform. Making it a Flash game enables us to easily target both desktop web browsers with Flash player, and mobile devices with Adobe AIR. The game is small and simple enough to fit within the technical limits of Flash and its media handling is extremely simple and easy to use – a perfect fit for a very short development schedule like the one we had.

Game Framework and Physics

We made an early decision to base Pileup on physics, specifically the Box2D physics engine. It made perfect sense in the context of TOJam, since the game has to be simple enough to create and entertaining at the same time. In order for that to work, we needed a framework or game engine that can handle physics, and so had to consider one of the following  options:

1. Use one of the popular game engines, like Flixel, FlashPunk or PushButton
2. Integrate physics with a wrapper library, like QuickBox2D
3. Write our own framework with Box2D integrated into it

The first option was lucrative, as it would save a lot of effort. I tried to set up a simple physics demo with these engines and quickly strike out Flixel and FlashPunk, as they are more suitable for simple platform games and don’t work well with physics simulation like Box2D. PushButton was a serious contender, and it even has Box2D built into it – however the interface for it is not very easy to use, and it require having a physics component attached to every game object. After digging into the source I also discovered that the collision system is far from optimized and uses an older version of Box2D so I decided to drop it as well.

Option #2 was using QuickBox2D - very easy to use but way too generic to be used in an actual game. It did find a lot of good ideas inside the source code, like the way they build physics bodies based on shapes.

We ended up with the the last option, and I took a shot at writing my own framework. Taking a cue from libraries like Corona and QuickBox2D, I designed a simple interface that couples a display objects with a physical body. After spending some time with excellent tutorials by Todd Kerpelman, Allan Bishop and Emanuele Feronato, I managed to get a grasp on the basics of Box2D and write a simple engine that would form the core of our game framework. It also helped that by that time I was familiar with the way that the other frameworks integrated Box2D so I had plenty of references.
This effort resulted in our homegrown framework  - a game framework with a physics subsystem, that encapsulates all Box2D functionality as well as an actor system similar to the one used in engines like Unreal3.

Architecture: Composition vs Inheritance

Engine architecture is typically based on one of two patterns to define the different game objects: inheritance or composition. Some engines use composition (like PushButton Engine), some use inheritance (Flixel) and others, like Unreal3 use a blend of the two.  We had to pick a side.
We chose to rely on inheritance rather than composition, simply because it suited our needs – we kept the hierarchy simple and composition would take too much time to implement. The base class for any game object is the Actor class, and the subclasses override specific functionality to define their own behavior.
Here is a snippet of the base actor class:

	public class Actor
	{
		protected var _body:b2Body;
		protected var _geom:DisplayObject;
 
		public function get body():b2Body { return _body; }
		public function get geom():DisplayObject { return _geom; }
 
		public function Actor(disp:DisplayObject, b:b2Body=null)
		{
			_geom = disp;
 
			if (b) {
			    _body = b;
			    _body.SetUserData(this);
			}
		}
 
		public function updateNow():void
		{
			updatePosition();
			childUpdate();
		}
 
		public function destroy():void  {}
 
		protected function updatePosition():void  {}
 
		// Called when collision occured
		public  function hit(force:Number, actorB:Actor):void {}
	}

Assets: Vector vs Bitmap

Another early decision we made is to try to optimize for mobile, so it would be easier to port the game to mobile platforms later. Even though the framework supports any display object as the visual element, we opted to use bitmaps over vectors and spritesheets over movie clips. This actually made it much easier to handle the art pipeline – bitmaps get loaded dynamically on game setup and do not require embedding or rebuilding when updated. Performance wise, spritesheets make sense since they render faster – by blitting the frame and avoiding the overhead of timeline in movie clips. The faster rendering is due to the face that a movieclip frame (or a shape) is drawn (and rasterized) on every frame in the game loop, while a bitmap is only blitted once and then get cached and used on subsequent frames without rasterizing.
Also, we only used a limited number of frames per asset in the game so the memory usage is kept on check.

Engine First, Game Later

This may sound trivial, but too often ignored: avoiding tight coupling between engine (framework) and the game specific code is not only a best practice, but also a big time saver. Once the scope of development has switched from the framework to the game, we were able to focus on the game code almost exclusively. Tasks become much clearer and easier to implement that way, especially under pressure of a very short schedule. Also the game code is often coupled with specific assets, and involves close collaboration with the artist that creates them, so there is minimal down time for the artist since they don’t need to wait for the coder to implement the infrastructure.

Level Editing Tool

Perhaps the biggest win for us was the fact that we made our own level design tool in advance. These kind of platform game requires a lot of time and effort to build a level, and we approached the problem from two aspects- design time and load time.

First we created a script for Flash CS4 (using JSFL) that exports all instances on the stage to an XML file, in the form of a list of objects with type, name and position. Then, we wrote a level loader into the game framework to read the level XML, create the game objects and place them on the game screen. This was simple and crude but extremely effective – any of us could edit a level in a matter of minutes and creating a new one in an hour or two.

What Went Wrong

Finalizing Game idea

Up until the last moment before the jam we weren’t able to nail down a clear idea for the game and how to make it fun. We had to fill in the blanks as we go, often while coding – that impacted the final product as it often feels like something is missing. Maybe we would add more in future versions.

Content and Production Value

For a game created in such a short schedule you really need to prepare goo concept art and visual style guide well in advance. Like every other game out there, content is king – highly polished visuals are extremely important to give the game high production value. Our visuals fell behind and did not meet our initial expectations, leaving the game without anything that stands out of the ordinary.

Conclusion

Pileup was a lot of fun to create. It may not stand out and is not very original, but we learned a lot while making it. The production process is compressed to a few days and the stakes are high, and we managed to reach the finish line with a complete game. Lots of features did not make it to this release, so hopefully we would be able to include them future updates.

Game Facts

Development Team: Two coders and two artists

Tools used
Adobe Flash Builder 4.5, Adobe Flash CS4, Photoshop CS4, SVN

3rd Party libraries
Greensock TweenLite, AS3 Signals, Box2D 2.1a (Boris the brave AS3 port)

Source 3600 lines of code in 44 classes
Build Size Binary SWF file: 112k, Total Assets: 6 MB

In this post, I will cover a few alternatives to Flex while staying in the realm of Actionscript and Flash. Yes, this may sound strange from someone who makes his living using Flex, but there are situations when Flex can become a liability.

The Right Tool?

A basic rule of thumb is: use the right tool for the job: Different projects have different requirements, so does it make sense to use the exact same tool for all of them?

Some projects require heavy back-end data support or lots of UI, while others need to be light and fast and require very minimal UI. Enterprise projects are completely different from, say, casual games or advertising projects on so many levels, and it’s not a good idea to build them in the same way.

The Flex framework was designed and written by Adobe (and later became an open source project) as a layer on top of the flash API. While it did prove to be powerful and easy to use, Flex is far from perfect. It was touted as the one solution to fits all problems, and typical to projects developed by large corporations, the objective was to cram as many features as possible, and it quickly grew in size and complexity – code size and efficiency fell victim and pushed to lower priority.

The fact is that most projects don’t use 100% of these features, and a good part of them use maybe 20% of them. The underlying overhead is significant. Sure the framework is modular, and the compiler will not include components that are not accessed, but because of so many dependencies in the flex core components the resulting swf file would be significantly larger.

The Flash community has developed a love-hate relationship with Flex, and Adobe did address some of the problems over time. However, even with the recent release of Flex 4 the fact remains that the framework is large, heavy and not very efficient. The good thing about Flex, is that being an open source project, we are able to look under the hood and see exactly what code is being used.

So How big is it anyway?

A sample project with a couple of labels and buttons can serve as a basic test case. Create two projects, one as Flex project and the other as pure actionscript project.

Use either MXML or actionscript to place these labels and buttons – in the flex project it would use the Application, Label and Button components while in the AS3 project it would use TextField and SimpleButton.

Set the linkage in the build properties to ‘merge into code’ to create a single swf. Now and build the projects and compare the resulting SWF files.

600K versus 12K – that is almost 50 times ratio!

Big deal, you might say, why should we even care about file sizes and memory footprint when we have gigs of memory and bandwidth to spare?

Well, if you want your flash app/game to run properly on platforms like netbooks, smartphones and mobile touch devices you already know the answer: smaller and faster is always better. Even on desktops, loading time might become a factor for some projects.

To understand this issue further, a few words on the Flex SDK architecture.

At the core of the SDK lies the forefather of Flex: UIComponent – the base class for all visual components. Developers sometimes refer to it as the ‘God Component’ – an all powerful, massive entity that contains all the functionality needed in interactive and non interactive components (lifecycle events, mouse interactions, effects, tool-tips etc.). To iterate, classes like button and label are based on UIComponent.

The class hierarchy for a simple button (spark) is:
Button -> ButtonBase -> SkinnableComponent -> UIComponent.
To get a rough estimate for the size in memory of a button, simply add up all of the classes up the hierarchy. Actual results may vary depending on how optimized the compiler and player are.

Now lets take a look at a few popular controls in the Flex SDK code and try to get an idea of how big they are.

Wow, 1560 lines of code for a simple label? that’s not exactly compact and efficient. Also 2000 lines for a group, the container used to layout child components, looks a bit bloated.

Well, you get the point. Since all Flex visual components are derived from the jumbo size UIComponent, we start with a few hundred KBs no matter how basic our project is. And we didn’t even cover actual memory footprint for these components.

To conclude, with thousands of lines of code that make up most flex components, its no wonder we end up with SWF files that are over a Meg, and sometimes a few megabytes before adding any assets.

The Code behind

Another aspect of Flex is the usage of MXML for layouts to simplify code. Other than simple layout it offer other features, like states, data binding and styles. MXML is actually only a markup that is pre-complied into Actionscript code. The generated code is added to the ‘plain’ code and then complied into a swf.

[Bindable]
public var myData:String;

Will generate somthing like this:

public function set myData(value:String):void
{
   var oldValue:Object = this._1167269232myData;
   if (oldValue !== value) {
      this._1167269232myData= value;
      if (this.hasEventListener("propertyChange"))
         this.dispatchEvent(mx.events.PropertyChangeEvent.createUpdateEvent
         (this, "myData", oldValue, value));
      }
}

And MXML state code like the following

<s:states>
    <s:State name="normal"/>
    <s:State name="before"/>
    <s:State name="after"/>
</s:states>
 
<s:Label text="aaa" color.before="#cccccc" color.after="#888888"/>
<s:Group includeIn="after">
    <s:Label text="bbb"/>
</s:Group>
<s:Group visible.before="false">
    <s:Label text="www"/>
</s:Group>

Generates:

var _TestApp_Group1_factory:DeferredInstanceFromFunction =
 new mx.core.DeferredInstanceFromFunction(_TestApp_Group1_i);
 
 
states = [
 new State ({
   name: "normal",
   overrides: [
   ]
 })
 ,
 new State ({
   name: "before",
   overrides: [
     new mx.states.SetStyle().initializeFromObject({
       target: "_TestApp_Label1",
       name: "color",
       value: 13421772
     })
     ,
     new mx.states.SetProperty().initializeFromObject({
       target: "_TestApp_Group2",
       name: "visible",
       value: false
     })
   ]
 })
 ,
 new State ({
   name: "after",
...

All that code only to switch a couple of properties when a state changes. A similar result could be achieved in only a few lines of hand written code.

So we want to start a project that will use some simple UI elements and layouts. We might want to be able to use mxml and data binding as well. In the list of requirements we also have a light and fast user experience. For the type of projects that requires very simple UI, like interactive ads or games we would need a minimal set of components, and in most cases we want to heavily customize their visual appearance.

But for this minimal set, we would drag the entire Flex framework with all its overhead with it. Does it really have to be that way?

What are the options out there?
Part 2 will lay out some of the available lightweight alternatives, their pros and cons and how to incorporate them into your projects.