"pushbutton-engine" Posts

ZaaImbue, A dead-simple injection system for Flash

Yesterday in the PushButton Engine IRC channel, we were discussing our need for metadata based injection for the next version of PushButton Engine.

While developing Eden, we encountered a similar problem and ended up writing our own injection system. We’re fond of it, and wanted to use it in PBE… so we open sourced it. Take it, use it, modify it… we’re releasing it under the MIT License.

Check out the source over on GitHub.

Make sure you add this to your compiler arguments:


Here’s a basic example of using ZaaImbue:
[gist id=871172 file=ImbueExample.as]

Some people have asked us why we called it “Imbue”… frankly… we didn’t want to call it Injection, so we looked up synonyms on the interwebs and imbue was one of them.

We all played a lot of Diablo 2, and had fond memories of Charsi imbuing our gear with magical properties… and that’s where imbue came from.

Developing games with PushButton Engine – Understanding the Difference Between UI and Game Simulation

I’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.


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:


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.


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.

Speaking at 360|Flex San Jose 2010

So if you haven’t seen my fun badge there on the right side of my blog… —>

I will be speaking at 360|Flex San Jose.

If you haven’t attended a 360|Flex conference before, you really should. In my opinion, 360|Flex is the best conference out there for Flex developers. It’s put on by developers for developers.

It is a very focused conference, where you can really get into the nitty gritty of Flex and geek out with other members of the community. Plus the food isn’t half bad.

When are you speaking?

I’ll be speaking on Wednesday, March 10th (my birthday) from 1:00 pm – 2:20 pm.

What will you be speaking about?

Session Title: Flexible Games… game development with stuff you already know.

Session Level: Intermediate

Description: I don’t know about you… but as an enterprise software developer, sometimes I need to take a break from the corporate world and want to develop something fun. In this session Nate Beck will take you through the basics of game development using the Flex SDK you know and love.

Nate will walk you through setting up your development environment, the basics of game development, using the open source PushButton game engine and building a functioning game.

What will Doug McCune do for revenge?

For those of you who weren’t at 360|Flex in Indianapolis, there was an incident… You can read about it in my Punking Doug McCune post.

Since the incident, Doug has vowed to get payback. And if you don’t know Doug, he is a scary creative guy. So we’ll have to see what he comes up with. Find out, along with me at my session.

Alright I’m convinced, where do I sign up?

Either click here or click the 360|Flex San Jose badge on the top right of my blog.

More information about travel and the conference in general can be found on the 360|Flex Website.

Developing games with PushButton Engine – Understanding Local Flash Player Security

As I spend more and more time on the PushButton Engine Forums, it’s funny how often the same topic seems to come up. Today a topic showed up again, regarding running Flash swf files locally. You see this same topic in many different flavors…

  • When I email my game to the client it won’t run on his computer
  • Playing the game only works inside my Flash Builder (or Flex Builder) project development folder
  • My game worked perfectly in one folder, but no longer works when moved to another folder

These issues are all part of the same underlying problem, a misunderstanding of Flash Player Security.

The first question you should ask yourself is… what security sandbox type is my game running in?

What is a Sandbox Type?

The sandbox type indicates the type of security zone in which the SWF file is operating.

Please remember that the security sandbox is determined at runtime, not compile time!

In the PushButton Engine we make identifying the security sandbox easy. When your game starts it logs the security sandbox that your swf is currently running (you can also get this by using the built in “version” console command). It looks like this:

PBE - PushButton Engine - r841 (ZaaBot build #97) - flash - localTrusted

In this case, the game is running in “localTrusted”. Most games that you run from Flash Builder will run in the localTrusted sandbox type. This is because Flash Builder configures your system to trust files in Flash Builder project directories. This is meant to make our lives easier as Flash developers… but it can cause confusion.

You can figure out what sandbox you’re running in by checking Security.sandboxType at runtime.

So what are the types of sandboxes?

In Flash Player, all SWF files are placed into one of four types of sandbox:

remote All files from non-local URLs are placed in a remote sandbox. Basically anything loaded from the web (ex: http, https) falls into this category. There is no access to the local filesystem.

local-with-filesystem This is the default sandbox for local files. SWF files in this sandbox may not contact the Internet (or any servers) in any way. They may not access network endpoints with addresses such as http URLs.

local-with-networking A SWF file in this sandbox may communicate over the network but may not read from local file systems. It is the exact opposite of local-with-filesystem.

local-trusted This sandbox is not restricted. Any local file can be placed in this sandbox if given authorization by the end user. This authorization can come in two forms: interactively through the Settings Manager or non-interactively through an executable installer (or created manually) that creates Flash Player configuration files on the user’s computer.

I added use-network=false to the compiler / flex-config file and it fixed it!

That’s great, but you still need to understand what is happening.

When you add the “use-network=false” parameter to your compilation, you are forcing the swf into the local-with-filesystem sandbox (“user-network=true” forces local-with-networking). This may end up giving you the desired behavior that you want, a swf that will run locally when you send it to your client or friends. However, you may run into some issues later on.

What if you and your friends were competitive, and you then decided your game needs to post a high score? You would need to make a request to a server to submit the score. When running in the local-with-filesystem sandbox you are not able to make requests of any kind to the internet, and therefore you can’t post to the score board.

So what is the solution?

You could teach all of your friends how to setup their game to run in localTrusted, by configuring their security files. But there has got to be a better way.

Well there is, and it all depends on how you plan to deploy your game.

I want to distribute a local game.

The recommended way to distribute flash games to be run locally is using the Adobe AIR runtime. It’s a great platform, and gives you much more flexibility and functionality.

I want to put it on a website.

So the best way to test your game then would be, to put it on a website. Now don’t get scared, this isn’t going to change your development workflow all that much.

The simplest way to simulate a local swf running on a website would be to have a local web-server running on you box. I highly recommend WAMP for Windows, MAMP for Mac OS X and LAMP for you Linux folk.

You then build your game (setup your output directory to drop the files in the web root) and launch your web-browser. Running a game swf from http://localhost will put your swf into the “remote” sandbox. You will want to do all of your testing within this sandbox, because it best mirrors the environment when you deploy your game to the web.

More Information

This post is just a brief overview of a very complex topic, for more information check out these resources:

Flash Player Security Basics

A full hour presentation from MAX 2008 by Deneb Meketa, explaining how Flash Player Security works and why it does it that way (if you don’t want to watch the whole thing, 47:12 is where it talks about local file security). I highly recommend everyone watch it:
Understanding the Flash Player Security Model