While this may seem like a trivial issue, consider the time it takes to implement, compile and test all of the possible fontFamily names for the font Gotham Rounded Medium:

fontFamily: “Gotham Rounded Medium”
fontFamily: “GothamRoundedMedium”
fontFamily: “GothamRounded Medium”
fontFamily: “gotham rounded medium”
fontFamily: “gothamroundedmedium”
fontFamily: “gotham rounded medium”
fontFamily: “GothamRounded-Medium”
fontFamily: “Gotham-Rounded-Medium”
fontFamily: “gothamgounded-medium”

After embedding a font from a SWF using Adobe’s suggested CSS syntax, I find myself having to try several different values for the fontFamily parameter before the compiler stops throwing errors.

After running into this issue yet again today, I found this article by Mark Walters. He includes in his steps for embedding fonts from a SWF a simple for loop that traces the correct name of each embedded font. By adding this loop to the first frame in the timeline of the FLA in which the fonts are embedded, you can discern exactly which fontFamily name to use in your Flex CSS document.

Here’s the loop to place in the FLA (quoted from Mark’s site):

var fontList:Array = Font.enumerateFonts();
for( var i:int=0; i < fontList.length; i++ ) {
    trace( "font: " + fontList[ i ].fontName );
}

Which will trace out something along the lines of:

font: GothamRounded-Medium
font: Rockwell

Making Your App Talk

Wether it’s a trace() statement in AS3, an NSLog() command in Objective C, or an alert() in JavaScript; every language has it’s mouthpiece. A device by which the developer can tell the application to spit out human-readable information from within the running program is essential to the development and debugging process.

A Tiny Tower of Babel

In Ham’s AS3 core library, we had always used the intrinsic trace() statement for this purpose, sporadically spread throughout the the core and all published applications. After functioning this way for years, we realized that the output console was filling up quickly with trace() statements from 4 or 5 different developers. Aside from the, admittedly minor, extra computational power these trace() statements absorbed, it became very difficult to find your own messages among the clutter.

Stranger Danger

We also realized the danger in allowing these traces to be published within a live application: you never know who has the debug version of Flash Player installed. Anyone running the debug Flash Player can easily see the content of all trace() statements. While this may be a relatively minor concern for some, it is in some ways a breach of security.

Consider the case where a developer needs to confirm that privileged information from an application is being stored or computer correctly. They may use a trace() to reveal a password, credit card number, or cheat code intended for their eyes only. If they forget to remove the trace() or rely on the public not having the debug player, this privileged information could be exposed unintentionally.

The Solution

While we don’t deal with all that many credit card numbers at Ham, we still need to take security seriously so we realized the need to create a system to prevent unwanted trace() statements from making it into the wild. Furthermore, a system by which one developer could prevent the output of all messages other than their own would be enormously helpful to the development process.

We ended up calling our solution the OutputManager; a singleton class to manage all output to the debugging console. Essentially, this class is intended to be the ONLY location in the entire core library where a trace() statement could be found. This way, there was a single choke point at which we could control the flow of data to the console. We ended up shortening the class name to “Out,” because who wants to type 13+ characters (“OutputManager” + method names) when they could just type 5 (“trace”)?! This is an important thing to remember when writing classes that are intended to be used by multiple developers; if it’s inconvenient in any way, it won’t be universally adopted.

So, we created a singleton class with several static methods in order to log both regular messages (logM) and errors (logE). Making the methods static and forcing instantiation on the first line of the method also made the methods more convenient to use. Instead of having to create and store an instance of the OutputManager, a dev could simple type Out.logM() and trace away.

These “log” methods in turn call a private method in the OutputManager that performs the actual trace. This is the point at which we wrapped the trace() statement in a conditional that checks if the app is allowed to perform traces. By simple setting this Boolean early in the run sequence of the app, we can block all output messages from reaching the console.

The Finishing Touches

After using the OutputManager system for some time, we discovered a couple pieces of functionality that could make the class even more useful. First, we realized that having an automatic way to announce which class and method from which the message originated would be very helpful for debugging. Also, we found that one of our original problems was still present; too many traces in the output console from other developers. This meant it was still difficult to find your own messages in the crowded output window.

To solve the issue of automatically notating the location of the original message, we built off the suggestion of this article. By throwing an Error in the OutputManager when a message was sent to be traced, we could parse through the text of the Error’s stack trace and capture the class and method names, along with the line number. The one issue we ran into when implementing this, is that throwing an Error in this way will cause the non-debug version of the Flash Player to freeze up, as it cannot handle the Error properly. To overcome this, we employed the Capabilities class’ isDebugger property. By checking if this property is set to true before throwing the Error, we could avert the issue altogether.

We were able to solve the problem of a crowded output console by adding something we call the “Override Flag.” This flag is a String set on the OutputManager at some point (presumably early) in the run sequence of the app using the setOverrideFlag() method. After the flag has been set, any messages sent to the log() methods in the OutputManager that do not include the correct override flag String (as an optional parameter) will not be traced. This way, a single developer can choose, with minimal effort, to see ONLY their own trace messages in the output console.

Take a Look

Download a zipped copy of the Out class here.

Options

Originally we had considered several options: copying the files “by hand” as-needed, setting up a folder action to automatically copy the files when new assets are added, setting up an Automator script to copy the files as-needed, or attempting to use an alias.

Copying by hand: This was our fallback. Copying files as-needed would be the most sure-fire way to accomplish the task, but it is also the most tedious and would slow down our overall workflow.

Folder Action: This appeared to work at first, but we soon realized that only newly added files would be copied and would not suit our needs as all updates to files would need to be copied as well.

Automator Script: This worked quite well. Automator allows you to create an application that will run a set of actions, in this case we could set up an application for each project, double click it, and it would copy the files automatically.

Alias: This did not serve our needs as development IDE’s may not recognize the files in the assets folder as accessible via an alias, as they actually reside at a path different from the source folder.

Another consideration we realized while trying to find solutions was that directly copying the files may take a great deal of time and waste storage space for asset-heavy projects.

The Solution

Though making an application with Automator would work, it required the application to be run every time an asset update was needed. Furthermore, all of the solutions mentioned above (save the alias) would still have the issue of storing potentially heavy files twice on your hard drive.

After some research by Cameron (a member of Ham’s dev team) we found the perfect solution: a Symbolic Link. A Symbolic Link creates a “soft link” that resolves the file path of a folder to a different location. In essence, it is like an alias that makes the files within it appear as if they reside at the location of the alias.

How To Make the Link

The Symbolic link is made possible by a free Automator action written by Junecloud software (download it here). Download the actions and take a look at the demo video to see how it’s done (apologies for the Screenflow watermark).

Icon.png: icon dimentions (114 x 114) don’t meet the size requirements. The icon file must be 57×57 pixels in .png format.

This seemed odd to me, as we had very explicitly created a 57×57 (standard display) icon and a 114×114 (Retina display) icon, and followed Apple’s “@2x” naming convention.

After some digging, I found that the root of the issue was the info.plist file for the app. Apparently you must not only follow the “@2x” convention, but also explicitly specify paths to the various sizes of your App’s icon files in a “CFBundleIconFiles” array.

I found a great article at Use Your Loaf that helped resolve the issue. By specifying paths for each size of the app icon, the App Store error was resolved and we could also include icons at the correct sizes for all iOS device screens.

I decided today was the day to jump on the bandwagon to the future and teach myself some "HTML5."

I finally had enough free time to do some research, and the new <canvas> element is what I see as the most promising of HTML5′s features. So, I put together a pretty simple little Hello World demo I call Color Canvas.

With the help of Seb Lee-Delisle‘s Particle class (adapted from the AS3 Particle class I’ve come to know and love), you can use your mouse to change the color and origin of a particle system in your "HTML5-equipped" browser.

It’s exciting to finally be able to have the creative freedom usually reserved for a plugin, in a browser. As I dive further in I’m sure I will find that the <canvas> element (like any other visual technology) has it’s limitations. But from the little I’ve seen of it so far, <canvas> seems to be a solid visual building block we’ll be using in the next generation of interactive experiences.

To find your device’s UDID, follow these steps:

• 1: Connect your device to a computer.
• 2: Open iTunes.
• 3: Select your device from the “Devices” list in the left-hand column.
• 4: Your device summary display in ITunes should now display the Serial Number as the 4th piece of information to the right of your device’s icon (outlined in red below).



• 5: Click on the serial number and the display will update to show the UDID number (outlined in red below).



• 6: Select Edit > Copy, or press Command + C in your keyboard, to copy the UDID number to your clipboard.
• 7: Paste the UDID into any text document (text file, email, etc.) you wish.

As an incentive for users to join their GoldPoints Plus rewards program and also highlight the hotel chain’s continental breakfast options, Country Inn and Suites wanted to create a game in which users could earn real reward program points. The company’s advertising agency, Olson, concepted and designed an experience reminiscent of the Price is Right game “Plinko” (only with falling breakfast foods instead of discs) and contracted Ham to develop it.

As the user’s success in the game could net them “real-world” points (which held a monetary value), security of data transmission and level of difficulty were primary concerns. After several rounds of tweaking point values and gameplay timing, a balance of playability and moderate point payout was achieved. A high level of coordination with Olson’s tech team was also required to maintain security and speed while exchanging data via .NET webservices.

On this project I was responsible for essentially all of Ham’s involvement in the process. I interfaced with Olson’s design and tech team, both on and off-site, many times contributing key technical suggestions about gameplay. I also functioned as production artist, cutting up PSDs and structuring Flash files for the final deliverable. Last but not least, I developed the game using AS3 within Ham’s Flex application framework, also utilizing the Box2D physics engine for gameplay interactions.

The Gold Points promotion was capped at 1,000,000 points, so the monetary payout may not be in effect anymore, but you can check the game out here: [Play Online]

To help promote the 70th anniversary of the original release of the Wizard of Oz, KidsWB engaged Ham to create an online dress-up game for kids featuring favorite characters from the film. The main element of the game is to dress Dorothy, Glina, or the Wicked Witch with thousands of clothing combinations and place them in one of four environments from the film. Once the user has chosen a character, dressed them and placed them in an environment, they can print and save their creation or play a scavenger hunt mini-game within the environment to unlock extra clothing options.

The game was developed using a combination of Flex components and more traditional Flash assets, all within Ham’s Flex application framework. As senior developer on the project I helped concept overall gameplay, architected the structure of the application, oversaw a junior developer’s implementation of that structure, and eventually completed building the application. The result was a beautiful and addictively-fun game for kids. Enjoy! [Play Online]

Recently Ham was tasked with making a game for the new TNT series Dark Blue. The show revolves around an undercover officer, so the game reflects situations a covert agent may encounter. Tasks like taking a cell phone “off the grid,” forging a signature, and hot-wiring a car are recreated in a mouse-driven Flash environment.

As senior developer at Ham I assumed a management role on this project. We used an external resource to write the majority of the code as I oversaw the project’s technical details and aspects of gameplay as they related to development. Try it out for yourself here: [Play Online]

KidsWB asked Ham to create a game to help promote the DVD release of Tom & Jerry Meet Sherlock Holmes. In gameplay we tried to capture some of Tom & Jerry’s classic “cat and mouse” hijinks while they also work together to help Sherlock Holmes solve the case. Players can explore seven levels looking for keys to unlock doors, collecting diamonds and special skills, and ultimately find clues represented by magnifying glasses to help Sherlock solve the case.

I was the lead developer on this project and tasked with creating all of the systems used in gameplay. Maintaining visual continuity proved to be the most challenging aspect of the project. When Tom & Jerry engage in a specific one of their ‘hijinks’ an animation is displayed using a unique spritesheet. Because the characters had to organically transition between a wide variety of states, it was essential to build a system that allowed fine-tuned control of spritesheet positioning.

Another development challenge on this project was it’s sheer size. Each of the seven levels in the game was greater than 2000px x 1000px. To accommodate this size, the memory footprint of each system had to be carefully managed and all assets had to be optimized to the smallest possible size while maintaining quality.

Through the course of the project, three different physics engines were implemented in the game based on client feedback. After APEngine and Box2D could not live up to the client’s requirements, I ended up creating a custom physics engine from scratch that met the client’s exact needs. Though Box2D provided by far the most natural interactions, the custom engine proved to be very lightweight, efficient and malleable to the client feedback.

The result is a smoothly- performing side-scroller that hopefully captures the spirit of the Tom & Jerry franchise. [Play Online]