Ham’s fourth installment of Five Minutes to Kill Yourself, launched this week. Subtitled “Reloaded,” it expands on the original game’s premise and environment. In addition to rebuilding the game using the damage cutscene system developed for the third installment (Wedding Day), new rooms like the gym and CEO’s office have been added, along with some goodies like a Malkovich door and printable Successories-style trophies.

As senior developer I oversaw the development team on the project. Because this game was built on the engine I helped develop for the previous FMTKY game, I was able to familiarize the team with the engine’s core systems. I also helped concept and architect the game’s new features, and later optimized some of these new features for system performance.

If you liked the previous FMTKY games, this one will not disappoint. With four new rooms and many new ways to injure yourself, there’s plenty of dark and irreverent hilarity to go around. [Play Online]

Ham was recently contacted about making a “launcher” style game for the new franchise based on a golfing scene where the main character’s boss uses his dog in place of a golf ball. Though we had an external resource in the trenches writing the code, I oversaw the project’s technical details and aspects of gameplay as they related to development.

The game launched this week and don’t worry, no animals (demonic or otherwise) were harmed in the production of the game. [Play Online]

A word to the wise; when including an external javascript file on an HTML page, always terminate your script tag with a closing script tag, not an inline closing slash.

I ran into an issue where Firefox does not recognize that the script tag is closed and therefore does not render the remainder of your HTML code. This is quite confusing when you specify your JavaScript include in the Head tag and end up with a completely plank render page in Firefox.

Simply put, for Firefox compatibility use this:

<script type=”text/javascript” src=”/js/externalFile.js”></script>

Not this:

<script type=”text/javascript” src=”/js/externalFile.js” />

I undertook this project as a principal of Walker.Voth with designer Seth Walker. We were tasked with creating an engaging mobile experience for Minneapolis art review blog MPLSArt.com.

The primary challenge of the project was concepting an experience what would deliver the site’s content to iPhone users in a clear and useful way while making use of the iPhone’s native features. We could have easily created a mobile version of the site to simple deliver content to the mobile user, but we wanted to take it one step further.

What we ended up with was an app that both delivers the site’s content in a straightforward list format, and also allows the user to draw a line with their finger (in effect creating their own primitive “art”) which then populates with the most relevant content.

View the App’s page here, or download it from the iTunes Store here.

The plan was ambitious: create a site where content provides the basis for navigation, present that content in a way that highlights Ham’s style and capabilities, and do it without using Flash.

We chose to present our work without using Flash because we wanted to provide users an experience available on any device, in any standards-compliant browser. We also felt that our Flash work speaks for itself, and a standards-based site provided a prefect “canvas” for our Flash and non-Flash work alike.

We had originally intended to create a Content Management System from scratch, tightly linked to our specific needs. This proved challenging as the project was self-promotional and thus non-billable to a client. After realizing the futility of building a custom CMS the dev team began researching existing open-source CMS systems, finally deciding to use WordPress. The WordPress system allowed the greatest stability and flexibility with a massive community of developers and library of plugins.

The site’s navigation system is by no means revolutionary, but ingenieus in it’s simplicity. The underlying concept is to allow the user to determine their path, by providing them with content related to each choice they make. We accomplished this by treating each blog post, portfolio piece, image, video and client as a separate piece of content with an associated set of descriptive tags. While the user is viewing a single piece of content, the site creates a navigation system dynamically by displaying the pieces of content most relevant to what they are viewing.

As the development team created the structure and logic of the tag-based navigation system, the design team got to work on creating a theme using CSS and JavaScript magic. The end result was an experience that is fluid, functional and usable on any device. [View Online]

After attempting to set the Shape and Body’s friction property several ways, I stumbled upon the section in the Box2D documentation that states: “Box2d does not support rolling resistance. As a consequence, circles roll forever on flat surfaces with no damping.”

A ha! No wonder the friction setting had no effect; I was applying a friction parameter that was being ignored by the engine. The solution was more simple than I could have imagined.

Since Box2D ignores “rolling resistance” all one has to do is prevent the circle from “rolling.” To accomplish this, there is a handy Boolean in b2BodyDef called “fixedRotation.” Setting fixedRotation to true prevents the body from rotating or responding to angular force. Here’s how that looks in pseudocode:


//Create Body Definition
_bodyDef = new b2BodyDef();

//Create body in new b2World
_box2DWorld = new b2World();
_box2DWorld.CreateBody(_bodyDef);


As I mentioned, this solution cost me a couple hours. Hopefully it can save you a couple in return.

Box2D was a clear choice for this role. Not only is it better documented and supported than APE, it is also vastly more flexible, stable and efficient.

Originally written in C++ by Erin Catto, the version we used was a port to AS3 found here. We ended up using version 2.0.2 as opposed to the most current 2.1, as the documentation, example projects, and many support articles are still written for 2.0.x. There also exists a Cocoa port that may be useful for future iPhone development.

The API for Box2D has several important differences from APE. Most notably, the World object. APE works through a static APEngine object, physics objects are created independently and then added to and removed from the static engine instance. In Box2d the World object handles similar functions, however all physics object are created and destroyed inside the World object for performance optimization purposes. Furthermore, multiple World objects can exist simultaneously, although using this technique should be carefully managed to avoid performance issues.

Similar to physics object creation, collisions are also handled in a centralized manner through the World object. Where one would listen to individual objects for collisions in APE, a Contact Listener object must be used in Box2D and assigned to a World object. From this Contact Listener class it is then possible to notify physics objects and other systems of collisions.

Perhaps the most disorienting difference in Box2D is it’s unit system. Instead of pixels and arbitrary force values, the Box2D system uses the Meters/Kilograms/Newtons system of units. Anything being moved, sized or placed in the Box2D world must be translated into this system and then translated back out to pixels for things like updating a display object’s position based on it’s corresponding physics object. There is a general rule of thumb that 30 pixels equals 1 meter, which we adopted and currently use.

Overall, the transition to Box2D has been a smooth one. We are currently enjoying a sizable performance increase, increased flexibility (with things like object rotation, a variety of joint types, and separate control over mass and density), as well as a wider community and support base.

Let’s face it, there’s a LOT of poorly-produced Flash content out there. We’ve all seen our share of visually assaulting banners. But let’s not forget the processor-hogs, the unnecessary site headers and the flashterbating intro “splash” screens. As you navigate your way down the freeway of the internet, wouldn’t it be nice if you could avoid these potholes?

Enter, the Flash blocker.

Of course the primary function of a blocker plugin is, well, blocking your browser from downloading and displaying Flash content. This will keep out all the riff-raff, but also block the “good” content as well. What happens when you visit Hulu or YouTube expecting to watch a video?

Any blocker plugin worth it’s salt (I use FlashBlock) will also include a “whitelist” option, which allows the user to specify specific sites or pages on which Flash content will NOT be blocked. Also, good blockers will provide the user with a simple way to allow Flash content to display on a case-by-case basis, such as masking the Flash content area with a button that loads the SWF behind it when clicked.

These features turn a blocker plugin from wall into a gateway, only allowing content the user approves to get through. As someone who spends most of their day on the internet, my Flash blocker plugin has become a vital part of reclaiming my time and sanity as a browse.

I recently created a new class in the Flex Library Project that houses my core codebase. The Library Project is set up to automatically compile a SWC when it builds, this SWC is then imported in to any other projects that require the core by referencing the SWC in their build path (pretty slick little workflow). Only this time, the projects referencing the core SWC couldn’t find the class I had just added. Fail.

After trying all varieties of refreshing, cleaning, closing/opening the project, quitting/restarting Flex 3, I was beginning to wonder what had actually happened to my class. How had it gotten swallowed up in the gears of the Flex compiler?

The problem ended up being not with the new class, or the compiler, but with the .flexLibProperties. This is the XML file that stores a list of classes to include in a SWC. By default, it’s hidden from the list of files in your Flex project so you have to “un-filter” it from the Flex Navigator panel.

To do this:
• Click the downward-facing triangle icon in the upper left of the Flex Navigator panel.
• Now select “Filters…”



• Then un-check the box next to “.flexLibProperties” and the file magically appears in your project file structure.

My new class was notably absent from this list, so I included it using this syntax:

<classEntry path="core.path.path.ClassName"/>

After building the Library Project again the SWC was recompiled, now complete with my new class.

http://blog.yakitara.com/2009/10/unofficial-google-wave-notifier-for-mac.html (Download Link)

It’s still quite primitive, but very functional. The app sits in your Mac’s toolbar and lights up when you have new blips on a wave, displaying a number of total un-viewed blips. This simple functionality has allowed me to actually pay attention to Google Wave, turning Wave from a novelty into a tool.