Anyway, fortune has thrown some Flash work my again, and it’s been great fun getting back into. However, here in the debugging phase I’m coming back to some of the weird old quirks of Flash content that I always had to keep a cheat-sheet handy for. One of those points being: how the heck do you put em-dash characters into Flash HTML text?! It seems so simple… after embedding the em-dash font character, you should just be able to put the character into UTF8 text, right? Or at the very least, you should be able to use the — entity, right? Wrong. You have to use the ASCII entity. Okay, that’s simple enough; except that when I look up the em-dash ASCII code most conversion tables list —–which does NOT work. Gar! So, I’m not sure why em-dash has multiple ASCII values, but the one that works in Flash is —. Please post in comments if you can elaborate on the difference between those two ASCII codes, I’d be curious to know the difference!

And for those just skimming the article, here’s the bottom line… to make an em-dash in Flash HTML text, just embed the font character and then use this ASCII code in your text: —

Stitch is a commercial release – we financed the project so that we could designate fulltime human resource to the project (otherwise it never would have been built!). The game is selling for $15 USD, and we’d really appreciate all the help we can get in making the game a success! You can check out the new game website at http://www.lassiegames.com/stitch.

Enjoy!

I started by adding lots of Security.allowDomain() calls into all my SWF media. No luck. The Lassie engine relies on library sharing between SWFs, and try as I might – I could not get the SWFs to authorize that level of access using just allowDomain() (maybe I was missing something…). Either way, I moved on and found a cross-domain loading feature that I’d never used before: import loading. Wow, it’s really handy.

The premise of import loading is very simple: you’re loading media from another domain into the current security sandbox, at which time the loaded media can be accessed as though it were available on the local file system. No symmetrical Security.allowDomain() calls are required between media files, so this is super clean and easy to set up. Just have a Flash Loader object perform an import load, and you’re off to the races. Here’s how to do it:

First, let’s assume that we’ll be working with the following servers:
- http://www.mymediaserver.com – this server hosts all of the external media that we’ll be loading.
- http://www.myappserver.com – this is where our application will be running at.

1) Set up a cross-domain policy file on your media server.

This policy file must be called “crossdomain.xml” and must reside in the media server’s web root (ie: the policy file URL would need to be “http://www.mymediaserver.com/crossdomain.xml”). This policy file specifies what domains may access files on this server. The content of the cross-domain XML should be this:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
 <site-control permitted-cross-domain-policies="master-only"/>
 <allow-access-from domain="www.myappserver.com"/>
 <allow-access-from domain="myappserver.com"/>
</cross-domain-policy>

2) Configure an import load

Now that you have a cross domain policy file that will allow your application to access files on the media server, you can import load from the media server by doing this:

var $loader:Loader = new Loader();
var $context:LoaderContext = new LoaderContext(true, null, SecurityDomain.currentDomain);
var $request:URLRequest = new URLRequest("http://www.mymediaserver.com/media/myfile.swf");
$loader.load($request, $context);

The trick here is to use a LoaderContext object that specifies the current security domain as the sandbox to load the external media into. Specifying “SecurityDomain.currentDomain” brings the external media into the local sandbox. Once you’ve done that, neither the loader nor the loadee file need any further security scripting to work together (such as allowDomain() calls).

http://www.lassiegames.com/games/stitch_demo

Day and night at the Ravenhollow docks.

I believe it was Matt (my partner on Stitch, and inspired by his childhood of playing Zelda games) who initially proposed the idea of time changes during an early brainstorming session. While I didn’t object to the idea from a tech standpoint, I also didn’t really expect to go through with it… In my experience, massive labor-intensive features generally have a way of working themselves out of a product. Only later did I realize my oversight: massive features only work themselves out of client projects where the client doesn’t want to pay for a grandiose vision. Unfortunately, features do not work themselves out of your own projects unless you heart-wrenchingly cut them (hence the reason we are each our own worst clients!). While I remained leery of the idea, Matt wrote it into his first draft of the script and it became a lock-in. However, that’s not to say that we didn’t make ANY cuts. Matt’s first version of the script actually included three times of day: sunrise, daytime, and night. Wow – that would have been a ton of work (I emphasize that now that we’ve implemented ONLY day and night). Thankfully, it was a pretty easy decision to cut back to just the two; mainly because:

1. We were concerned with making the world so faceted that the player would miss connections between the different times of day. We decided that a player would have plenty to figure out with only two times to work between.
2. After some early artwork tests, it became clear that the original idea of rendering all scenes as daytime and then just adding color overlays for the alternate times was not going to work. The artwork looked very flat, so we were going to need to render every lighting scheme as a custom painting (and two paintings for each room was enough!).

So after the day/night concept was locked in, it was time to think through the technical solution. One “easy” idea that was quickly thrown out was to create two separate instances of the world: one in daytime, one at night. While the idea seemed lucrative because of its simplicity (just swap the player into the same point of the other world instance, right?), it just didn’t make sense. We had a ton of puzzles planned, and while some puzzles were unique to day and night, the majority would be universal between times. That meant that all universal puzzles would need to be coded, tested, and debugged twice (once for each world instance)… and that doesn’t even take dialogue into account. The world is full of dialogue responses, so each world instance would need to be edited and maintained separately. Finally, multiply this scenario by roughly 20 rooms and you’ve got an extremely formidable challenge. So, that got me thinking of sneaky alternatives to pull off day and night without the development overhead.

This led me to build a layer setting within the Lassie engine called “frameOffset”. The concept is pretty simple: Lassie assigns a MovieClip as the image of each layer within a room, then tells that clip to go to a frame based on the layer’s current display state. Adding a “frameOffset” basically tells the layer to figure out which frame it should display, then go to that target frame +X. This allowed us to start building all graphics with day and night states, where the night graphic was placed on a timeline frame immediately following its daytime counterpart. At night, all dynamic layers receive a frameOffset of “1″, which causes them to go to the frame after their baseline daytime state. Suddenly, this process became a whole lot more manageable: create all rooms once, then just track whether their graphics should be skinned as day or night. Of course, we still needed to add lots of conditional logic to control puzzle behavior between day and night, but that was a minor endeavor compared to what it would have taken to maintain separate world instances.

Overall, time-of-day was a tough process that made for twice the art production, extra programming, and a general feeling of exponential complexity. I’ll admit, I had a moment of weakness where I tried to narrow the scope of day and night down to just work within the center of Ravenhollow (about 3 scenes). However, Matt never budged on keeping the whole world playable in both times of day, and he was right. It IS better this way. We think our fans will really enjoy act 2 of Stitch (the largest act), where day and night is fully utilized. While we’ll be introducing the time switching scenario in act 1 (the demo area), the process will be linear so that the world state only changes once. However, in act 2 the player gets complete control of the clock!

March 18th has been officially announced as the release date of the “What Makes You Tick: A Stitch in Time” demo game. The demo will be available for free download, and will include the complete first act of the full game. The demo delivers four playable rooms, 15 character appearances, lots of great artwork and music, and perhaps a few surprises! The game experience amounts to the combined effort of many talented people, and my co-author, Matt, and I are very pleased with the result. That said, we’re excited to share the game with our friends and fans! For more information and all the latest news on “A Stitch in Time”, visit the game’s official website at http://www.lassiegames.com/stitch.

This release is also big news for the Lassie game engine. The Stitch demo will assume the role of the official Lassie Shepherd demo game for showcasing the engine’s core features. Lassie enthusiasts who are curious about what’s possible with Shepherd may be interested to see the demo in action… the game makes use of everything from basic room transitions to heavy cache tracking and dynamic logic features.

Whether you’re a designer, a developer, or just a general game enthusiast, we hope you’ll stop in on Match 18th to celebrate this release with us!

Toggling fullscreen

Generally I implement a toggle button to click in and out of fullscreen mode. This is super easy to set up, and just uses the basic fullscreen controls of Flash. Nothing fancy going on here; I’d just set this as the CLICK handler of my toggle button…

private function _onToggleFullscreen($event:MouseEvent):void {
 var $fs:Boolean = (stage.displayState == StageDisplayState.FULL_SCREEN);
 stage.displayState = $fs ? StageDisplayState.NORMAL : StageDisplayState.FULL_SCREEN;
 }

Responding to displayState changes

Now, it’s not uncommon to want to rearrange your display a bit when entering/exiting fullscreen mode. I generally shift the alignment, scale, and proportions of elements on screen to better fit the display in fullscreen mode. Now, it would seem like we could just add this reformatting logic into the fullscreen toggle button’s event handler (above) where we actually toggle the displayState. However, this doesn’t work in practice because Flash Player automatically activates the ESC key as an exit from fullscreen mode. This provides a back-door to changing the displayState without going through your toggle button. As a result, all mode-change logic should occur in response to the stage’s RESIZE event (which will trigger in response to your toggle button, and in response to exiting fullscreen with ESC). So, do this:

stage.addEventListener(Event.RESIZE, this._onStageResize, false, 0, true);
function _onStageResize($event:Event):void {
 // perform actions in response to stage resize here...
}

Configuring the fullscreen presentation

The next nuance of this process is considering how you want to present your content in fullscreen mode. By default, your stage will be upscaled to fill the screen along with black space to fill up any differences in aspect ratio. This upscaling is controlled by another stage property called “scaleMode”, which has a set of value constants defined in the StageScaleMode class. By adjusting the stage’s scaleMode property, you can define how stretching is (or is not) applied. But wait, there’s more! Also check out the stage’s “align” property which goes hand-in-hand with the scaleMode property. The “align” property (set to one of the StageAlign class constants) will define how an unscaled stage positions itself while in fullscreen mode.

Now, while the “stage.align” property is a good concept, it has one blatant omission: there is no StageAlign.CENTER option to place the unscaled stage in the center of the screen while in fullscreen mode. This oversight confounds me, and even a good technical explanation from Adobe would not excuse the feature omission in my opinion. So, if you do want to center unscaled content within fullscreen mode, you’ll need to set the stage’s scaleMode to “NO_SCALE”, the stage’s align to “TOP_LEFT”, and then manually do the math to center your root display item within the visible stage boundaries.

Other weird stuff about fullscreen mode

I’m not even sure how to categorize these items, so I’ll just make a list of all the other “gotchas” that I’ve run into…

1) Fullscreen mode does NOT work in a test publish running within the Flash IDE. You’ll need to place the SWF into a browser or publish a projector to have your fullscreen button work.

2) Fullscreen will only work within a web browser if you’ve included a [allowFullScreen="true"] parameter within the Flash embed tag.

3) Flash does not respond to keyboard input while in fullscreen mode (grumble). I’ve looked for the rationale behind this restriction, but have found nothing other than Adobe citing it as a “security measure”. As of Flash Player 10, they threw us a bone and gave us the arrow keys, SPACE, and TAB as fullscreen freebies. Otherwise, you can only get unrestricted fullscreen keyboard access by going through AIR.

http://lassieadventurestudio.wordpress.com/2008/10/09/better-swfaddress/

I hope it’s useful!

In that demo, all four effects are driven by the same codebase. The particle system is just composed of two base classes: a particle and a particle field. From there, all implementations of the various particle effects just customize the appearance of the particle and the behavior of the field. The source files are available.

So: enjoy, stay warm, and happy holidays! I’ll post again next year after getting back from some holiday travel around South America. Or who knows… maybe I’ll post an update from the road.

Stitch is the follow-up to Matthias Kempke’s 2007 release, “What Makes You Tick?”. Matt and I partnered up to build this sequel and have been actively developing it within Lassie Shepherd over the past year. While there is no playable demo released to the public yet, the game is making good progress and we still hope to release it in the first half of 2010. In the meantime, the website will act as the definitive source of news about the project.