Nate Beck – Adobeholic

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.

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.

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

For a long time I’ve been doing things like this within Flex.

[Bindable] private var _skills:Array = 
[
	{label: "---", id: -1},
	{label: "1 - Newbie", id: 1},
	{label: "2 - Some Experience", id: 2},
	{label: "3 - Expert", id: 3},
	{label: "4 - I'm a baller", id: 4}
];

And then binding this data provider to a ComboBox…

<mx:ComboBox id="skillsCB" dataProvider="{_skills}" />

Well it turns out there is a much easier way of doing this that I never knew of until today. ComboBox has a “prompt” attribute that you can set. It’s so easy…

<mx:ComboBox id="skillsCB" dataProvider="{_skills}" prompt="---" />

I told you it was easy. Can’t believe I never noticed it before.

So the reason I haven’t posted a tip the past couple of days is because I have been working on a new project.

Check it out here —> Bug Quash

Please vote on the poll. We’re trying to see how much interest there is in this kind of event.

Any questions, comments, ideas, complaints, suggestions, etc… please post them below.

p.s. I know… this wasn’t really a tip… but I’m tired and it’s beddy time for Nate.

:: Update ::

New information including how to sign up for notifications —> here.

The tip that helped me the most lately is the with flipping objects with the help of matrices.

Here is the code:

function flip( display:DisplayObject, orientation:String ):void {
 
       var m:Matrix = display.transform.matrix;
 
       switch (orientation.toUpperCase()) {
 
               case "HORIZONTAL" :
                       m.a = -1;
                       m.tx = display.width + display.x;
                       break;
               case "VERTICAL" :
                       m.d = -1;
                       m.ty = display.height + display.y;
                       break;
       }
       display.transform.matrix = m;
}
 
flip(logo, "horizontal");

This tip was provided by Sidney K. Thanks Sidney!

Today’s tip is a short one… I have begun planning a very exciting Flex-centric event that is going to be held up here in Seattle. More on that later though.

Your tip for the day… The Flex SDK team has a guide that explains the coding conventions that they use within the SDK (for the most part).

Flex SDK coding conventions and best practices

I agree with almost all of the conventions they list here. If you’re planning on contributing the to Flex SDK, you NEED to be familiar with these conventions.

Today a bug that I have been watching was resolved as ‘Not a Bug’. In the QA team’s defense, the original bug description was not very clear. I have commented on the bug explaining why it needed to be reopened.

This situation brings up a valid question.

How do we (the Flex community) effectively help the Flex SDK team in a way that doesn’t hinder them? Let’s face it, spamming the inbox of Flex team members isn’t going to get us anywhere.

As I was contemplating this situation, I opened up my Google Reader. It turns out that Joan (a member of the Flex SDK QA team) has a series of posts discussing tips and tricks to using JIRA, along with what we can do to escalate issues that are important.

So for today’s tip, I’m going to provide links to these great posts:

• Flex SDK Fixed Bugs in 3.3
• Flex JIRA Tips (part I): Voting on Bugs
• Flex JIRA Tips (part II) : XML Feeds and Email Subscriptions
• Flex JIRA Tips (part III): How do I reopen a ‘Closed’ bug?
• Flex JIRA Tips (part IV): Community Fix Candidates
• Flex JIRA Tips (part V) – What does it mean when my bug is ‘Deferred’?
• Flex JIRA Tips (part VI): Understanding Milestones
• Flex JIRA Tips (part VII): How do I request a Feature in Flex?

I’ll update these links as she posts more.