Going Mobile Slides from Flash Gaming Summit
1Here are my slides from my presentation at Flash Gaming Summit at Casual Connect.
Tip of the Day – Populate Version Number from an AIR Descriptor File in ANT
1So I’ve seen this question pop up a few times.
Can I grab a version number from the app-descriptor via ant and add that to the AIR filename? Anyone know?
This is a pretty straight forward thing to do using Ant-Contrib tasks, that are publicly available.
You can download the example files –> here.
Let’s take a quick look at the ANT script.
<project name="PopulateVersion" default="populateVersion" basedir="."> <taskdef resource="net/sf/antcontrib/antcontrib.properties"> <classpath> <pathelement location="./ant-contrib.jar"/> </classpath> </taskdef> <property name="app.descriptor" value="air-app.xml" /> <target name="populateVersion"> <echo message="Parsing application.version from ${app.descriptor}"/> <xmlproperty file="${app.descriptor}" prefix="airApp.appdescriptor"/> <propertycopy property="versionNumber" from="airApp.appdescriptor.application.versionNumber" override="true" /> <echo message="Parsed application version: ${versionNumber}"/> <propertyregex property="fileVersionNumber" input="${versionNumber}" regexp="\." replace="_" casesensitive="false" /> <echo>Version Number: ${versionNumber}</echo> <echo>File Version Number: ${fileVersionNumber}</echo> </target> </project> |
As you can see it’s very straight forward to parse the version number out of the Application Descriptor. The only other thing we do is us RegEx to change the periods in the version number to underscores to make for more friendly file names.
Using the same concept it is very easy to also populate a Version file that gets compiled into your application which can include build numbers, or other interesting things… but we’ll save that for another day.
Ignite Seattle 13
1I had the pleasure of speaking at Ignite Seattle 13 last night. It was a blast! Thanks everyone who showed up.

My talk was titled, Searching for Adam Savage, and was based around a research project that I conducted called Seeker. The basic premise is this:
Modern cell phones frequently include a camera and a GPS. Even if a GPS is not included, cell phone towers can be used to establish the location of the phone. Image formats include special headers that can be used to store this information, so called EXIF tags. In this talk, I described the process that was used to find the information that many consumers (including celebrities) unknowingly broadcast out on the internet.
The article that resulted from my research can be found over at ZaaLabs.
During the presentation one of my slides was missing, somehow creating the slides in Apple Keynote and then converting them to PowerPoint caused some issues.
So here is the slide that was missing.
Also, Ben Huh of Cheezburger Network wants everyone to know that they are hiring.
Developing games with PushButton Engine – Understanding the Difference Between UI and Game Simulation
2I’ve been trying to spend more and more time answering questions in the PushButton Engine community. I’ve been answering questions on the forums and in the community IRC channel. If you have questions about PushButton Engine, feel free to ask in either of those places.
One of the really cool features that PushButton Engine has is the ability to use XML to define your entities and templates, and how to wire all of the components together. It looks very much like MXML… (side-note: changing the level files to be compiled MXML is a feature we’ve discussed heavily and are considering doing in the future) which I think is causing a lot of confusion.
We get asked multiple times a week how to define a main menu, a high score screen, a tutorial screen, the list goes on and on… using PushButton Engine. The answer is… you don’t.
Terminology
So let’s get some terminology out of the way, for purposes of this blog post, I’m going to call menus, tutorials, and everything in that bucket… the User Interface (or UI). I’m also going to use the term Game Simulation, we’ll get to that in a moment.
What better way to explain these two concepts than to do so with some examples.
User Interface
Here is an example of UI in a game that we’re currently working on at ZaaLabs along with PushButton Labs:
This is the main menu to Grunts Skirmish. There isn’t a single piece of PushButton Engine here on this screen… in fact… it’s 100% Flex 3… even using mx:State and mx:Transition. Everything on here is UI.
Game Simulation
The Game Simulation is the actual rendering of the game, it’s what you play. You don’t “play” the menu system.
Here is an example once you get into the playable part of Grunts… this is the Game Simulation:

The Game Simulation is where we make use of PushButton Engine… animations via sprite sheets, process manager, renderers, scenes, components, entities, etc… all of the good stuff that PushButton Engine has to offer.
Putting it all together
Now… this doesn’t mean that you are limited to one or the other… the two work together to make your final game. Using Grunts Skirmish again as an example… you’ll notice that we actually have UI elements layered on top of the Game Simulation.
As you can see… both pieces are needed to make a successful game.
Just remember… PushButton Engine is a framework for building simulations.
When you need help building your User Interface… there are tons and tons of UI Frameworks out there… for Grunts Skirmish we used Flex 3.
Here are a few of my favorites UI libraries:
Exception
There are always exceptions… perhaps you want to build a menu system that plays like a game. A fantastic example of this is Fancy Pants Adventures.
Here is the menu system for the game.

Conclusion
As you can see with Fancy Pants Adventures you’re playing the menu. If you’re not playing… it’s probably not a simulation… this is ultimately the biggest difference between User Interface and Game Simulation.
For more information on using Flex with Pushbutton Engine, checkout my Flexible Games Video over on ZaaTV. The beginning is more of a PushButton Engine overview… skip towards the end for information on FlexSceneView and integrating the simulation with Flex UI Components.
Tip of the Day – Getting a SWF’s background color
3Recently at ZaaLabs, I’ve been working on a really cool tooling platform called Eden. One of the features that Eden has is a Screen Capture plugin. Eden can send a request to a remote SWF to return a bitmap of the stage.
For example, here is Eden pulling a screen capture from HanClinto’s Platformer Starter Kit.
Really cool! However, I quickly ran into an issue when I tried to take a screen capture of a more basic game.
On the right is the game running in Flash, and on the left is the screen capture.
As you can see, my screen capture doesn’t include the green background. So what happened?
Well it turns out the background color of a SWF isn’t actually part of the stage. The background color that you set using the SWF Metadata tag, or set in Flash Professional is drawn directly by Flash Player.
package { import flash.display.Sprite; [SWF(backgroundColor="0x00FF00")] // <--- How can I get this programmatically? public class SwfBackgroundExample extends Sprite { public function SwfBackgroundExample() { } } } |
So I had a dilemma… how could I access the backgroundColor of the SWF? I scoured the API docs, I asked the Twitter-sphere, but no luck. All I learned was that the backgroundColor was hard coded into the bytes of the SWF. So I decided that’s where I needed to look for it.
SwfData to the rescue.
I read up on the Adobe SWF specification, and consulted with my good friend James Ward. He pointed me in the direction of loaderInfo.bytes, which gives us access to the bytes of the currently running SWF.
After a few hours, I had a fun little class I like to call SwfData, which parsed the background color out of the currently running SWF’s bytes… as well as some other fun things. Here’s how you use it:
package { import com.zaalabs.utils.SwfData; import flash.display.Sprite; [SWF(backgroundColor="0x969696")] public class SwfDataExample extends Sprite { public function SwfDataExample() { var data:SwfData = new SwfData(loaderInfo.bytes); trace("version \t"+data.version); trace("frameRate \t"+data.frameRate); trace("frameCount \t"+data.frameCount); trace("fileLength \t"+data.fileLength); trace("bgColor \t0x"+data.backgroundColor.toString(16)); } } } |
Using SwfData, I could now use the background color as the fill color of my BitmapData class.
Get It Here
SwfData is MIT licensed under ZaaUtils (do with it what you will). It is available on GitHub
Questions, comments, complaints are all welcome below.
== UPDATE ==
So I just found out that Claus Wahlers has an awesome, more feature complete version of an AS3 SWF parser. It’s also available on GitHub. I’m still going to keep SwfData up since it’s much more specific to getting the background color of the swf. If you need more features, use as3swf by Claus, it’s very well done.












