I would like to end this series with summarizing the underlying ideas of my work on Pew Pew.

Please wake up now

Last month I gave a talk about creating Metro applications using ActionScript. In order to spice up the Q&A segment at the end of my talk I thought it would be fun to add a final slide with some provocative statements. I called that slide The Pew Pew Manifesto, which I am going to share with you in a minute.

I suspect that not everybody will agree with what I put into the Pew Pew Manifesto. But before we enter a religious war about dynamically versus statically typed languages, or whether JavaScript can be used for large projects, let me stress that I didn’t write the Pew Pew Manifesto in order to pick up a bar fight. I wrote it in order to wake up my colleagues that fell asleep during my talk! (Just kidding, nobody fell asleep.)

JavaScript is not suitable for large web apps.

I am serious: Don’t write large web apps in JavaScript. As mentioned in Planning A Death March I don’t think JavaScript is suitable for implementing large projects. Last year I was asked to help out with an internal project that used JavaScript. Over time the code had grown out of control and there was only one person left, who really understood how it worked. The project had also become unscalable, because adding more developers would not have increased the overall productivity. It would have taken those developers too much time to come up to speed and work on this particular code base written in JavaScript. I looked at the code and suggested this crazy idea: Why not porting the existing JavaScript code to ActionScript and then continuing development in ActionScript while cross-compiling to JavaScript?

Porting JavaScript to ActionScript in order to cross-compile back to JavaScript? Was that crazy-talk? Perhaps, but it surprisingly worked and probably saved that project. Here is what happened when I ported the JavaScript code to ActionScript:

The code naturally distributed itself from about 10 files to over 100 files when creating ActionScript classes.

Porting JavaScript to ActionScript revealed inconsistencies and at times incoherent uses of types.

I don’t know why but JavaScript programmers tend to put all of their code into few files. That’s not so useful, though, if you want to have multiple developers work on the same project. Splitting up the code into multiple files enabled us to scale the project.

You wouldn’t believe how many inconsistencies I found when porting JavaScript to ActionScript. Often JavaScript code, which looked perfectly fine at the first glance, revealed itself as incoherent the moment I tried to compile it with an ActionScript compiler. Sloppy usage of types were to blame for most of the inconsistencies. A very popular anti-pattern seemed to emerge: functions, which return incompatible types:

Nobody in his right mind would write this kind of code. But I have seen it more than once. In fact I have written that kind of code myself. My point is that it’s not necessarily the developer’s fault that we end up with bad code like the examples above. I would argue that dynamically typed languages like JavaScript are too tolerant and don’t slap developers on the fingers when they start mixing up bunnies with toasters. It might cramp your artistic programming style if you cannot mix up bunnies with toasters but where I come from doing so results in bad projects.

Just to be clear: You can write bunny-and-toaster code in ActionScript, too. But I would argue that you get immediate feedback of something being fundamentally wrong as you are typing that code, just by being confronted with questions like “what should be the return type?”. Of course you can choose to use “*” or “Object”. But most people pause and rethink their design at that point.

Not everybody is as smart as Gilad Bracha or John Resig and those that aren’t – like this author – are probably better off with writing their code in a statically typed language. Many will probably disagree with this statement. It might make more sense after reading the next Manifesto statement.

JavaScript is the browser’s assembly language.

In the following week after I gave my talk about creating Metro apps using ActionScript I ran into a few colleagues and I was surprised that it was this statement that they found most intriguing. One colleague argued that the definition of assembly language implies a one to one correspondence with the underlying machine code. Another characteristic element of assembly languages are that they are also generally understood to be non-portable. Since JavaScript is neither, where does this idea of JavaScript being an assembly language come from and what is this about?

The first time I heard about JavaScript described as an assembly language was through Gilad Bracha’s blog. In 2008 he wrote in java’scrypt:

I’m not advocating writing clients in Javascript directly. Javascript is the assembly language of the internet platform (and the browser is the OS). It’s flexible enough to support almost anything on top of it, and poorly structured enough that humans shouldn’t be writing sizable applications in it.

To illustrate his point let me show you my cross-compiled and optimized JavaScript code of SpriteExample, which is included in Adobe’s online documentation about the Sprite class. As you can see the JavaScript code is extremely dense and no longer readable. In that sense the code looks more like binary code to me. It turns out that this kind of “binary looking” JavaScript is the most efficient version in terms of size and performance.

Choose a high-level language for developing web apps.

Implementing your project in JavaScript leaves you with some tough choices: If you ship the development version of your JavaScript code with your product, it is not obfuscated, and also bigger, and slower. If you want a faster, smaller app that also protects your intellectual property you have to optimize your JavaScript. But then you also have to annotate your code with type hints. If you don’t annotate your code with type hints the Closure compiler won’t be able to optimize as much and your code is less obfuscated, bigger, and slower. If you do find yourself writing JavaScript with type type annotations then why not using a high-level language instead and use a cross-compiler that automatically generates the type hints for you?

In the case of Pew Pew I used my own ActionScript to JavaScript cross-compiler. In Planning A Death March I made the argument that if you had to implement Photoshop in six weeks you wouldn’t pick an assembly language. Being able to cross-compile from a high-level language to JavaScript was a crucial element of my plan.

Use Google’s Closure Compiler for optimizing JavaScript.

In Optimizing cross-compiled JavaScript I wrote a whole article about the importance of optimizing your JavaScript code. As far as I know Google’s Closure Compiler is still the best JavaScript optimizer out there.

A nice side effect of optimizing your JavaScript is that it becomes unreadable as I illustrated with my SpriteExample snippet. You would never write “binary JavaScript” code like that manually. But for professional software production it is important to be able to write code in a maintainable high-level language while deploying a product that does not reveal the ideas of your source code.

In my opinion the current version of Visual Studio 11 for Metro is missing this important point. There is no built-in JavaScript optimizer and no support to hook one in. Microsoft seems to assume that nobody wants to optimize JavaScript code. Their current IDE only outputs Debug JavaScript code. There is in my opinion essentially no Release option for JavaScript apps in Visual Studio 11 for Metro. I really hope Microsoft will change that.

Let your app degrade gracefully when OS features are missing.

This might be an obvious statement. But what I am saying is, if you write a Metro app in a high-level language like ActionScript make sure that your code “degrades gracefully” so your app would also run in most modern browsers on other platforms.

The code above only registers onViewStateChanged if the environment is known to support the Windows namespace. In other words, if this code runs in a browser without Metro support, it won’t register for view state changes.

Why going through the trouble? The last statement of the Pew Pew Manifesto will answer that question.

Invade every Web Platform!

I think, being able to write code once and reuse the same code on different platforms without compromising neither functionality nor aesthetics of your app’s user interface is a very desirable goal.

This might sound like science fiction, but what if all of your apps in the near future were just custom browsers? Like Flash Player playing SWFs your custom browser would run your JavaScript, that is, code written in a high-level language and then cross-compiled to JavaScript. There are many cases where your JavaScript code could run in the browser as is. But how would you get your app into the Apple App Store, or the Android Marketplace? How would you make money?

This is why I find PhoneGap (now an Apache incubator project called Apache Cordova) very intriguing. In many ways PhoneGap’s architecture might lead to a new type of apps that you could call “custom web browser apps”. You can look at the PhoneGap architecture as a framework that provides custom browsers for multiple platforms (iOS, OSX, Android, Blackberry, Windows Phone). All you have to care about are the HTML, CSS and JavaScript parts you have to provide. PhoneGap even supports special JavaScript APIs for features like Camera, Location, or Accelerator, that are not accessible via standard DOM APIs.

For example, if I wanted to get Pew Pew into the Apple AppStore and Android Marketplace I would simply cross-compile my ActionScript project to JavaScript and plug it into the PhoneGap architecture. As far as I know I can even write my own native plug-ins for PhoneGap. If that’s really the case I can pretty much invade every web platform that PhoneGap supports.

Waiting For Godot

Shortly after submitting Pew Pew to the Windows Store on 1/8/2012 I received a friendly email from Microsoft’s staff to let me know that the finalists would be announced a week later on Sunday, 1/15. After my “coma hacking” week prior to the Pew Pew submission my regular work week felt like vacation. Sunday came and I was checking my emails throughout the day. But there was no email from Microsoft. I had to face the bitter truth: Pew Pew didn’t make it into the finals.

I have to admit I was disappointed as well as a little bit surprised. Granted that Pew Pew was only a “charmingly crummy” space shooter game it was also loaded with Metro style features like view states, tiles, settings charm, share source support, roaming data storage, and pause and resume. Pew Pew must have been up against some tough competition, I thought. I had read that Microsoft teamed up with game developers to create HTML games like Cut The Rope and Pirates Love Daisies. If those had been the kind of games Pew Pew was compared against then it wouldn’t have had the slightest chance.

Off By One

If there is one piece of wisdom I learned from our dog Joe it is moving on to the next interesting thing quickly and not dwelling on failures. It still amazes me how fast Joe is able to disconnect himself from unpleasant events and focus on all the exciting opportunities that lie in front of him. Joe’s “event horizon” is approximately one minute. Mine is in the best case about one day .

“Well, that didn’t work out” was my first thought when I logged into my computers the next morning at work. I almost reached “Joe Zen” state by late afternoon until I saw an email from Microsoft. The subject said, First Apps Contest: You are a Finalist! I guess, Microsoft missed their own deadline by one day and elected the finalists on Monday instead of Sunday. That was fine with me!

After doing a little dance in my office and calling my wife I also contacted Mike Chambers to let him know that Pew Pew made it into the finals of Microsoft’s First App Contest. He laughed and said: Microsoft must be in trouble. He was humbly referring to the crappy quality of his original Pew Pew version.

Sleeping In

Microsoft’s congratulation email included some information about the next steps that would follow. They kindly asked every finalist to do four things:

Install a new development version of Windows 8

Compile and update the app using that new Windows 8 and Visual Studio 11 beta.

Sign up for a Windows Store account.

Submit the app to the Windows Store before 2/3/2012.

I don’t recall the details but I pretty much ended up ignoring that email for a few weeks. Perhaps I was a little bit burnt out, or I thought that installing the new Windows 8 and recompiling my app shouldn’t take that long. But for about a month I did literally nothing for the contest.

Rude Awakening

Then on 2/23 I got an email from a staff member of the First Apps Contest Team politely asking about the progress on migrating my app to the new Windows 8 version. The term “migration” woke me up. I thought it was just recompiling. I also realized that the next deadline on 2/3 was coming up in less than a week. In fact my sabbatical was starting on 1/30 and our plane to Mexico was leaving on 1/31. In other words I had to be done by 1/30.

Installing the new Windows 8 version was easy but then I ran into unexpected problems when recompiling Pew Pew. When I launched Pew Pew in the debugger I found myself staring at a white, empty screen.

Now, as part of downloading and installing the new Windows 8 build I also did sign a non-disclosure agreement (NDA), which prevents me from getting into any details of this particular Windows build. But let’s say the reason for my broken Pew Pew were a combination of unexpected Metro changes and my own code in respect to loading images. To be fair, I think the problems were more in my code than it was Metro’s fault. In order to fix those problems I had to rewrite the image loading code, which also significantly improved Pew Pew’s performance.

Busy Bees

I was pretty busy that week wrapping up my projects before I was leaving for my six week sabbatical on 1/31. The Pew Pew changes were not that hard but I just didn’t have a lot of time that week. I ended up testing and getting ready for the app submission on 1/31, which was just one day before my wife and I would take a plane to Mexico City. That’s when I hit a pretty big roadblock: Microsoft’s Windows Store website refused to accept my new version of Pew Pew and I couldn’t figure out why.

Finally I gave up and sent an email to my contact person for the First App Contest. I said that I was unable to submit my app to the store and that I would probably not make the deadline on 2/3, because I would leave early next morning for Mexico. I would only have three hours left to get Pew Pew into the store.

I have to admit that I was impressed how fast the Microsoft guys reacted to my email. Another Windows Store specialist got quickly pulled into the thread and he promptly sent me instructions from his Windows 7 Phone. Microsoft’s response team actually helped me with my problems within an hour and the new Pew Pew version was in the Store shortly afterwards. Without their help I would have missed the deadline and Pew Pew would have been disqualified.

Looking back my biggest mistake was probably not starting earlier with my work on Pew Pew. But life is complicated and sometimes you have to improvise. In the end it all worked out and I definitely found new respect for those busy bees at Microsoft.

Mexico

Sabbatical! Adobe is a great workplace and offers its employees one sabbatical every five years. I have been with Adobe for over 15 years and got the maximum of six weeks. There are three rules for Adobe sabbaticals:

You have to take them within 2 years.

You are not allowed to split your sabbatical up in smaller pieces.

You should have fun.

I made up rule #3. But Adobe really means it: You should have fun and recharge your batteries. For example John Nack went to Guatemala for his sabbatical roughly at the same time I was starting mine. I was definitely planning on having fun and relaxing in Mexico.

For my trip to Mexico I established similar ground rules like I did back in December 2011: no more than 4 hours of work per day. It turned out that I worked perhaps 2 hours of work after one week of not working at all. Frankly, I didn’t know I could do that.

Improving Pew Pew

My time in Mexico was rather uneventful in regards to developing Pew Pew. I worked only for a few hours but continuously and over time improved Pew Pew little by little.

I added a few more settings for adjusting ammunition and speed

I also added a button for clearing the high score to the Game Options flyout.

I improved the accuracy of the ship movements

I improved (“fixed” is probably a more appropriate word here) the collision detection algorithm.

I removed the game area boundaries (game objects re-enter on the opposite side).

UFOs now shoot too.

In the meantime Microsoft sent me an email asking me to install yet another version of Windows 8 and to resubmit Pew Pew by 2/17/2012. After avoiding a disaster caused by doing nothing I was eager to start my work early. But this time it looked like the re-submission process would be only a matter of recompiling the app, because Microsoft was planning on releasing the next new Windows 8 build on 2/14. There was one tiny problem: Our flight was leaving on 2/15. If I downloaded the new Windows 8 version back in Seattle I would only have two days to fix any problems and submit Pew Pew to the Store. At that point I really didn’t want to mess up again. I had to start my work in Mexico City.

Bandwidth Problems

My wife and I left Oaxaca in the morning of 2/14 and arrived in the late afternoon in Mexico City. Before I unpacked my luggage I checked my email and sure enough there was the announcement for the new Windows 8 version. I logged into my connect.microsoft.com account and clicked on the link for the Windows 8 images. The progress bar was crawling. The ETA for those two images was 15 hours.

That didn’t worry me, because I could just let the browser download over night. The next morning I realized that the process got interrupted after downloading about 10%. The new ETA had been reset to 12 hours. We had to be at the airport in 7 hours.

If you ever run into a similar bandwidth problem abroad try what I did: I went to the reception and asked whether the hotel had a land line (they did not), or whether they had different routers (they did). Then I tried every router until I found one that was faster. I eventually picked a router that downloaded my images in 4 hours.

Airplane Mode

I got my Windows 8 images just in time before we entered the plane. But if your laptop’s battery only holds about 3-4 hours of juice, how do you make use of the precious power so it would last a long flight?

Here are my tips for saving laptop energy:

Turn off wireless and bluetooth.

Pull down the shades and lower the screen brightness so you can still see the letters on the screen.

Quit every app that you don’t use.

Try to avoid compiling. Reading and writing is cheap, compiling costs more energy.

In my case I didn’t have much choice and had to use VMware in order to install the new Windows 8 version.

Fortunately everything went well. No problems, Pew Pew only needed to be recompiled.

The Video Shoot

We arrived in Seattle on 2/15 at 2:00 AM and I got up 5 hours later at 7:00 AM in order to prepare the house for a video shoot for Microsoft’s website. Microsoft told me that they would like to shoot a little video for their blog, which would introduce the finalists. In hindsight I suspect that by then they had already selected the winners and they wanted to have a video about the winners and not all of the finalists. I am saying that, because shooting a video is extremely expensive and labor intensive.

Microsoft hired Omelet, which is a video production company from L.A., and their friendly crew of about 8 showed up at 9:00 AM in the morning at our house. I also met three folks from Microsoft’s PR department. The whole video shoot took about 4 hours and in the final video you only see about 4 seconds.

If you have never been part of a video shoot, I can tell you it’s very interesting. The equipment they used was all high-tech. What to me looked like high-end photo cameras were fully functioning video recording devices. They had a sound guy that heard everything. From time to time he raised his hand and said “plane”, or “fridge” and only then I would notice that a plane was flying over Seattle or the fridge was doing whatever fridges need to do periodically in order to keep the chamber cold.

Adam, the director, told me that this shoot would be like an interview, except for they would never see him. That’s why it would be important that I incorporated the questions in my answers. It sounds easier said than done! At one point Adam asked me: So how do you like Windows 8? I answered: “Oh, it’s great” before I realized that I had to incorporate the question in something like “What I like so much about Windows 8 is …”. I apologized and offered a corrected version. Adam told me that that happens all the time and they can edit everything later. What I found funny is that one of the few sound-bites they used from our 4 hour interview was “Oh, it’s great.” and “I like competition”.

Another funny trivia I learned later: This whole video cannot be shown in Singapore, because my dog Joe walks towards me in one scene and naturally turned his behind to the camera. Apparently showing a dog’s butt in a video is considered extremely rude in Singapore.

I was pretty tired when the video shoot was over. But I would do it again in a heartbeat. The Omlet crew and the Microsoft PR folks couldn’t have been nicer. It was an interesting experience and a pleasure working with them.

It was a lot of work but it was also a lot of fun. What started as a Metro learning project ended with a nomination for Microsoft’s First App Contest. I never expected that back in December 2011. Now, what’s next? Where do I go from here?

Nine Hours?

Forget it. That was impossible. It was Tuesday and the deadline was on Sunday, 11:59 PM. I decided to postpone testing and app store submission into Sunday. In addition I increased the capacity form 3 to 6 hours for the remaining work days from Tuesday to Friday. Saturday would be a 12 hour work day – “coma hacking” as we used to call it back in the days when I was working for Star Division (which got absorbed by Sun, which got absorbed by Oracle). With my creative accounting I increased my overall capacity from 9 to 36 hours. That’s almost a full work week!

A New Joystick

After searching around for a little bit I found an ActionScript sample with source code that emulates joystick controlled movements. The sample code looked terrible, because it used hazardous with statements and had to be cleaned up first. But the joystick logic seem to be working. It took me about 6 hours to integrate that joystick into Pew Pew including “crummifying” the artwork.

Crummifying Images

Pew Pew’s style guide could be summarized as: “make it charmingly crummy”. Images should look hand-drawn and the font for any text should look hand-written. But what do you do if you have a piece of perfect artwork? For example the artwork of the joystick from the ActionScript sample with source code that I found was clean and even had 3D effects for the knob. Whenever I had to add new artwork to Pew Pew like in this case the new joystick I had to make it crummy looking – a process that I named “crummifying”.

This is how it worked:

Create a new document in Photoshop.

Create a new layer and import the original artwork (here a screenshot of the sample’s joystick).

Dim that layer by setting the layer’s alpha channel to 0.5 to 0.75.

Create a new layer on top of the first layer that contains the original artwork.

Use a fine brush and manually draw the artwork by following the contours exposed by the dimmed layers.

Remove the first layer with the original artwork.

That left me with a crummified version of the original artwork. Over time my artistic skills naturally improved and I had to force myself to not draw as well as I was capable of doing. In some cases I had to start over and make everything crummier.

Metro Features

The joystick was going the right direction and the game was finally looking like a real game. All that was left was finishing up the Metro features and fine tuning the game. As you might recall I derived these eight Metro Commandments from Jensen Harris’s 8 traits of great Metro style apps:

Metro Style Trait

Commandment

1. Metro style design

“Align to the grid.”

2. Fast and fluid

“Optimize with the Closure Compiler.”

3. Snap and scale beautifully

“Honor the View States.”

4. Use the right Contracts

“Implement Settings and Share Source.”

5. Invest in a great Tile

“Provide wide and small Tiles.”

6. Feel connected and alive

“Be interruptible: pause and resume.”

7. Roam to the cloud

“Store app settings into the cloud.”

8. Embrace Metro principles

“Do all of the above!”

I boiled those Metro Commandments further down to these Metro features that I wanted Pew Pew to support:

Tiles (wide, small, live).

View States (snap view, landscape, portrait).

Settings Charm.

Share Source.

Roaming Data Storage.

Pause and Resume

I’ll walk you through each of those features and tell you (roughly) how I implemented them.

Tiles

In Metro every application is represented by a Tile. One of Jensen Harris’s recommendations is therefore “Invest in a great Tile”. It is important to note that there are three different Tile sizes. But Tiles could also be implemented as targets for push notifications for, i.e. stock ticker apps or weather apps, which allowed the apps to change their Tiles dynamically. Time was running out so I only provided the three tile sizes, which was super easy.

If you launch Visual Studio 11 and open your project’s package.appxmanifest you can simply add PNG files for the three tile sizes. All you have to do as a developer, really, is drawing those PNGs.

View States

“Snap and scale beautifully” meant to me “Honor the View States”. In order to observe view state changes I added an event listener to ApplicationView:

In onViewStateChanged I implemented the logic that changed the game area’s size and notified the game objects. (For more details about observing view state changes in Metro see the documentation for Application View Class and Snap Sample.)

Settings Flyout

For the first release I just wanted to have one Pew Pew setting for adjusting the position of the joystick. If you are left-handed you probably want your joystick on the left side of the screen. My settings control was a simple switch for “left” and “right” joystick position.

In order to implement a Settings Flyout I added my event listener to the application’s “settings” event, which gets called when the user opens the Settings charm. My event listener then populates the Settings Charm using SettingsFlyout.populateSettings().

Share Source

From Jensen Harris’s talk about 8 traits of great Metro style apps I learnt that every Metro style app should be a Share Source if possible. In more technical terms: every Metro app should implement the Share Source Contract. Contracts are callback interfaces, that Metro asks you to implement in order to support features like Share Source. The Share Source Contract is about sharing information with others through apps and services like Facebook, Twitter, and email. Those apps and services are Share Targets. But you can also make your app a Share Target if you implement the Share Target Contract.

For Pew Pew I decided that players should be allowed to share the great news of reaching a new high score with the world. If you don’t have a high score the text would say something like “Hey, check out Pew Pew. It’s fun!”.

In order to implement a Share Source Contract I added an event listener to the DataTransferManager’s “datarequested” event, which gets called when the user opens the Share charm. My event listener code then populates the DataPackage with information that the Share Charm will display.

Roaming Data Storage

Jensen Harris says: “Roam to the Cloud”. In the context of Pew Pew that meant that if I stored the app settings and the current game state (high score, current score, lives, and wave level) into the cloud I could in theory interrupt a game on one device and continue where I left off on a different device. That would be cool!

I added an event listener to the application’s “checkpoint” event, which gets periodically called and when the app is being quit or suspended. My event listener code then writes out the app’s settings using ApplicationData.roamingSettings.

Pause and Resume

I translated “Feel connected and alive” to “Be interruptible: pause and resume”. In other words, Pew Pew needed to pause if Metro brought up the App Bar, Charms, or suspended the app, or switched to a different one. It turned out that the best way of doing that was by adding an event listener to the window’s “blur” event, which gets called when the user opens a Charm or the App Bar – in general: when Metro interrupts your app. My event listener code simply pauses the game by displaying a (crummified) Pause button, which resumes if the user presses the button.

onResume() does the reverse (remove the pause button, undim the game area, and start the TickManager).

For more details about observing interrupt events please see the documentation for onblur .

Pew Pew, release candidate

Everything came finally together on Friday evening. This was my release candidate: I integrated a new, crummified joystick and all of my Metro features (Tiles, view states, settings, share, roaming data storage, and pause and resume) were in. It was time to let my friend Christina Storm have another look at this much improved version. Her first video that recorded her first attempts to play the game was pretty devastating. This release candidate had to work for her, or I was doomed.

Fortunately everything worked out great as you can see in Christina’s second video. She even completed a wave!

Release the Kraken!

On Saturday I tested Pew Pew thoroughly and fine tuned a few minor things. On Sunday I submitted Pew Pew just in time and 6 hours before the deadline. The whole process of submitting a Metro app couldn’t be easier. I actually started the submission from within Visual Studio 11 via a menu item that said something like “Submit to the App Store”.

Once Pew Pew was in the App Store I could observe the different stages the app went through. The longest wait time was about 5 days for “Content Review”. Since my submission was part of the Windows 8 First App Contest I received a friendly email from Microsoft’s staff to let me know that the finalist would be announced a week later on Sunday, 1/15/2012.

I was fried. The last two weeks were pretty exhausting. I almost didn’t care about the outcome of the First App Contest. I was just glad it was over. Even though I just returned from Adobe’s 2 week holiday break (which I partially used for working on Pew Pew) I was ready for more vacation.

Fortunately my 15 year sabbatical of six weeks was coming up in February.

Improving Pew Pew

I started the morning of 12/26/2011 with drinking an almost poisonous amount of coffee to get my blood moving. I knew I had a lot of things to do before I could submit Pew Pew to the app store by 1/8/2012. These were the features I needed to get done by 1/1/2012:

A. Improving Pew Pew

WAG

1. Resizable Game Area

8h

2. Replace game controller with analogue joy stick

10h

3. Use hand-written looking font, rather than Helvetica

8h

4. Roll-overs on buttons

2h

5. Redesign start screen

3h

6. Add health bar

3h

Total:

34h

On 1/1/2012 I would then decide whether it would make sense to continue, or drop out of the contest.

Resizable Game Area

The original Pew Pew version was designed as a prototype game for mobile devices and used a fixed size of 320 x 480 pixels for the game area. If you resized the browser window the game area would still stay at that size. In order to fix this problem I added an event listener that attached to the document’s window and observed the onresize event. When my event listener got triggered I resized the game area and notified every game object (ship, enemies, UFO, chaser etc.) of the boundary changes. I made a note that the size of the game objects should also change depending on the size of the game area. If the game area was 320 x 420 or smaller I wanted to use small images, otherwise I wanted to use bigger images.

Hover Ball

In the original Pew Pew version the game controller was a circle with a line in it that indicated the direction of where the ship was heading. The game controller was mirroring mouse movements. As you moved the mouse the line in the game controller would spin around similar to a steering wheel. I decided that this game controller had to be replaced with something like a joy stick as Ian Lobb suggested in his code review of Pew Pew.

I thought, why not introducing a new kind of joy stick? A ball that hovers over a pad. Yes, that would be the joy stick of the future! You would control the Ship’s movements by moving a hovering ball in different directions. If you released the mouse the ball would snap back to the middle of the Hover Ball Pad. If you dragged the ball further away from the pad the ship would accelerate. Not being able to accelerate/decelerate the Ship was one of the main complaints Ian Lobb had about the game controller. The Hover Ball would solve all of those problems and it would look cool, too.

Fortunately switching the original Circle game controller over to the Hover Ball turned out to be easier than I thought. So I moved on to other problems.

Text

The original Pew Pew used flash.text.TextField controls for everything that had text on it: the start screen, the score bar in the game area, and the screen between level changes that said “Wave completed!”. Every button was a flash.display.SimpleButton, which internally uses a TextField.

TextField’s default font is Helvetica and I wanted to change that and use hand-written fonts throughout the game (which Ian Lobb had also suggested). Now, you can set any font you like via TextField.defaultTextFormat and flash.text.TextFormat . But the problem is that not every platform has every font. In order to avoid this dependency I used Photoshop: First I created a new text box, then I set the font to a font I found named “Handwriting Dakota” and wrote the text I wanted to display. Finally I exported my text as a PNG image file.

In Pew Pew I then replaced TextField and SimpleButton with my own classes that loaded my handwritten text image snippets. This was very tedious work, which I usually did in the evenings while watching TV.

Buttons

The original Pew Pew version used SimpleButton, which are rather ugly rectangles with Helvetica labels. I had to replace those with my own buttons with handwritten text image labels and round “crummy” corners. I also added support for roll-over states: over, down, and up. In other words I created three images for each button using Photoshop.

Start Screen

The original Start Screen was just hideous. I completely redesigned it using handwritten text images and added a line that gave credit to Mike Chambers with a link pointing to Pew Pew’s github depot. I made a note that if the URL should probably be implemented as a real link if there was time left.

Health Bar

Pew Pew’s original game area displayed some sort of score bar at the top showing the number of lives you had left and the points you had accumulated including the level (“wave”) you had reached. My plan was to replace that score bar with a crummy looking Health Bar with three sections: Ship symbols for the lives left plus two number wheels for the points and the current wave level.

Checkpoint

When I reached the checkpoint on 1/1/2012 I was pleased. I had implemented most of the Pew Pew improvements I needed and I made great progress on my Metro features (more on Metro features in my next post). Not everything was entirely done and my list with notes of things with what I should add if there was time left also grew disturbingly long. I hadn’t started with the Health Bar yet, and the button labels were all still in Helvetica. But the bottom line was encouraging. Pew Pew didn’t look crappy anymore. I liked the direction this was going. I decided: No need to drop out, everything was under control.

It was time to get some feedback from other folks. Just by coincidence I met my friend Christina Storm at a coffee shop to discuss a project we were working on and I told her that I wouldn’t have much time, because I had been working on this “stupid game”. After telling the whole story Christina generously offered her help. She said: “Don’t worry about our project. Why don’t you send your game over to me and I’ll play with it? You probably need some testers.” That was exactly what I needed.

Straight To Video

Knowing that Christina would test the game and give me feedback encouraged me to work even harder on Pew Pew. On 1/3/2012 I threw my first alpha version over the fence. It took Christina only a few hours to reply. She did something really wonderful by creating a video that recorded her first attempts to play the game. As she was describing what she was seeing and how she was thinking Pew Pew would work it became quickly clear that my Hover Ball turned out to be not such a brilliant idea. On video I could see that she was trying to move the Ship with the mouse. First she tried dragging the ship, which didn’t do anything. Then she suspected that that ball in the right corner might have something to do with steering the ship and fiddled with that. When she dragged the Hover Ball the ship suddenly moved. But the movements of the ship were jerky and seemed unrelated to the movements she applied to the ball. This was a disaster. Towards the end of her video recording Christina was very frustrated. Her Ship got destroyed numerous times, because she couldn’t figure out how to navigate it. She felt like a sitting duck. The game sucked.

Morituri Te Salutant

It was Monday and before watching Christina’s video I thought I was well on track for freezing Pew Pew on Friday, which would give me enough time to test the game on Saturday before submitting it to the app store on Sunday, the dead line for the Windows 8 First App Contest. In this week I was planning on implementing all of those Metro features.

But now I had to redesign a new joy stick and there were still a few features missing. To make things worse this week was a very busy first work week in 2012. In my original plan I set my capacity for the first work week to 3 evening hours. I was looking at 9 hours for Tuesday to Friday in order to get Pew Pew back on track.

Implementing a joy stick plus the rest of the Metro features in 9 hours? That was perhaps a little bit too ambitious.

Reality Check

On 12/25/2011 my wife and I were returning to Seattle after a restful week in Omaha, which ended with a harsh wake-up call. Pew Pew for Metro in its current form was “crappy”, not “charmingly crummy” and unsuitable for submission to the Windows 8 First App Contest. The deadline for submitting apps for the contest was on 1/8/2012 and only two weeks away with one of those two weeks being my first work week in the new year. I realized I had to be very disciplined and focused in order to turn Pew Pew into a game worth submitting to the contest.

As we were entering the airplane I am laying out the plan for my Death March in my head:

Damage report

Research & extracting features

WAGs

Prioritizing features

Implementation!

Debugging & testing

Release Candidate

Contest Submission.

Most developers feel tempted to immediately start with #5 and then see where everything is going. But I knew that given my tight schedule starting with implementing small improvements would have been the safest way to end up with an even crappier version of Pew Pew. Over time I learned (often the hard way) that one has to follow those steps no matter how little time is left. First I needed to understand what was exactly wrong with Pew Pew.

Damage Report

Joystick doesn’t allow you to set speed, only direction. A simulated analogue stick would have been nicer.

Movement of the ship is not very graceful

Speed of the bullets is way too slow

Collision detection between the bullets and enemies is inconsistent

There are no roll-overs on any buttons

There aren’t any transitions between screens

The enemies bounce around the screen like asteroids, but they are UFOs.

Use a health bar rather than instant death.

Create a scrolling world.

Add basic physics like momentum

Allow pausing the game

Add particle effects for trails and explosions

Ian’s list was already depressingly long. But I had to add one very important missing feature:

The game area needs to be flexible and adjust to orientation and size changes.

I could have just taken that list and started fixing those problems until the deadline arrived. But as I mentioned before it is worth stepping back and spending a few extra cycles on what exactly needs to be done.

Research and extracting features

This second step is about finding ways to fix what is wrong. In my case: How do I get from “crappy” to “crummy”?

It was clear to me that I had to dramatically improve the game in order to avoid being kicked out in the first round of the First App Contest. But I also had to add as many Metro features as possible, because the fine print of the First App Contest rules clearly said that every app would be judged by how much it embraced the Metro Style guidelines. I hoped that even a borderline crappy Pew Pew game could make it into the next round, if it supported a lot of Metro features, because that’s what the contest was all about.

It was time to revisit Jensen Harris’s session about 8 traits of great Metro style apps. After all Jensen was one of the three First App Contest judges – I better listened to what this guy had to say about Metro apps. But even after watching Jensen’s talk a second time I felt that everything was a little bit too high-level and philosophical. I needed something closer to my daunting task at hand. So I came up with this table, in which I tried to translate Jensen’s “fluffy” Metro Style Trait definitions to 8 Commandments I was determined to follow in order to avoid eternal condemnation in Metro hell:

Metro Style Trait

Commandment

1. Metro style design

“Align to the grid.”

2. Fast and fluid

“Optimize with the Closure Compiler.”

3. Snap and scale beautifully

“Honor the View States.”

4. Use the right Contracts

“Implement Settings and Share Source.”

5. Invest in a great Tile

“Provide wide and small Tiles.”

6. Feel connected and alive

“Be interruptible: pause and resume.”

7. Roam to the cloud

“Store app settings into the cloud.”

8. Embrace Metro principles

“Do all of the above!”

I reduced those Metro Commandments even further down to these Metro features that I wanted to add to Pew Pew:

Tiles (wide, small, live).

View States (snap view, landscape, portrait).

Settings Charm.

Share Source.

Roaming Data Storage.

Pause and Resume

Now that I boiled everything down to a list of six Metro features I could start thinking about pricing those features.

WAGs

After identifying features for improving Pew Pew it was time to put some price tags on those features. Here at Adobe this process is often referred to as “wagging”. What does WAG stand for? Well, most people here at Adobe (including this author) think that WAG is an abbreviation of “wild a** guess”. Truth is, that during project planning nobody expects developers to generate precise estimates for tasks involving problems they don’t know yet how to solve. I often hear this joke where WAGs delivered by developers should be adjusted by increasing the time unit. “It takes 1 hour” becomes “it will take 1 day“, “it takes 1 day” becomes “it will take 1 week“, and so forth. Estimating tasks precisely is very difficult. My personal goal is trying to deliver within 10% of my WAGs. Do I hear some PMs laughing? – At least I am trying!

Prioritizing features

I decided to separate two distinct phases:

A. Improving Pew Pew

WAG

1. Resizable Game Area

8h

2. Replace game controller with analogue joy stick

10h

3. Use hand-written looking font, rather than Helvetica

8h

4. Roll-overs on buttons

2h

5. Redesign start screen

3h

6. Add health bar

3h

Total:

34h

The second phase would be all about implementing Metro features:

B. Adding Metro Features

WAG

1. View States (snap view, landscape, portrait)

8h

2. Tiles (wide, small)

1h

3. Settings Charm

8h

4. Share Source

8h

5. Roaming Data Storage

4h

6. Pause and Resume

4h

Total:

33h

By having two separate phases and starting with just improving the game I was hoping to save time, because improving the game didn’t require me to work in Windows 8 and Metro. Picking a development environment consisting of ActionScript, Flash Builder, my cross-compiler, and the browser allowed me to implement features very quickly at a low bug regression rate. Flash Builder caught syntax errors and debugging was easy in the browser. I would argue that one cannot implement large projects under massive time constraints in JavaScript alone. It would be like implementing Photoshop in Assembler in, say, six weeks . Not that implementing Photoshop in six weeks would be possible in any language. But if you really had to try, you wouldn’t pick Assembler. Being able to cross-compile from a high-level language to JavaScript was a crucial element of my plan.

In addition to having two separate phases I also decided to set a check point after the first phase. If I were too far behind I would cut my losses and drop out of this crazy race. In my opinion you have to know your own limits which includes that you know when you are beaten.

La Quenta, Por Favor

I was finally ready to add up all the numbers: it was 12/25/2011 and the Fist App Contest deadline had been set to 1/8/2012. I was travelling on 12/25 and I reserved 2 days at the end of that period to wrap up things, test, and submit Pew Pew to the store. That left me with 10 days, or 80 hours assuming a regular work week (Mon-Fri, 8 hours per day). But this wasn’t a regular project and the first week at work in the new year is never a regular work week. So I added the weekends back in (+4 days=32) but reduced my capacity for the first week at work in 2012 from 8 hours to 3 evening hours per day. That gave me roughly 76 hours (12/26 to 1/2: 8 days at 8 hours; 1/3 to 1/6: 4 at 3 hours). My WAGs totaled 67 hours. That was awfully tight. After Adobe program manager adjustments (“increase WAGs by one time unit”) the ETA for this project was 67 days and not 12.

My checkpoint after the first phase, which I wagged at 34 hours, would be in roughly 4 days. In other words at around New Year’s Eve 2011 I would know whether Pew Pew would see the light of the Metro Store, or not.

Digging out an old prototype

It only took me a few minutes to find that old prototype I wrote in February 2011 to convince skeptics within Adobe that you can cross-compile a game from ActionScript to JavaScript. There it was: Pew Pew, a cute space shooter game originally written by a Mike Chambers, a colleague of mine. The version that Mike open sourced Pew Pew in 2011 at github was pretty much the same I had used for my prototype. But I had to do a few important adjustments back then before I could cross-compile Pew Pew to JavaScript.

Converting from Flash to Flex

In Pew Pew’s github depot you will notice a file called Main.fla, which is a Flash IDE project file. If you open Main.fla with the Flash IDE you might be surprised to see that there is really nothing going on in this project. There is only one key frame, which kicks off the game through adding an instance of Main to the stage. Somewhere in Main.fla there is also one transition for animating explosions. Most of the logic is in a cluster of ActionScript files that contains code which gets attached to Symbols defined in Main.fla. (For more details about Pew Pew’s project I recommend reading Ian Lobb’s code review of PewPew.)

Later I learned that many games are written that way: one frame, a few transitions, a bunch symbols, and the rest is all ActionScript code. I can see why many developers prefer this kind of Flash Pro setup, because using Symbols in combination with ActionScript code is very convenient. You would have to do a lot more extra work in order get the same game running in Flex. Herein lies the problem, though. From a Flex developer’s point of view ActionScript code from Flash projects often appears incoherent and messy. The part that Flash Pro is adding to SWFs may seem convenient. But to me (and I suspect many other developers coming from the Flex world would agree) all that “magic” that Flash adds is just opaque. In many cases ActionScript code recovered from Flash project doesn’t even compile.

Back in January 2011 it quickly became clear to me that before I could cross-compile Pew Pew from ActionScript to JavaScript I had to convert the original Pew Pew Flash project into a coherent Flex project. In other words, first I needed to be able to create a Pew Pew SWF from a Flex project. You simply can’t compile incoherent code. Your compiler will (and should) throw compile errors if it detects inconsistencies. I realized, my job was adding that missing “Flash Magic”, that hidden extra code that game developers are fond of not having to worry about.

Implementing Flash Magic

You might think that you can easily convert a Flash project to a Flex project just by importing those ActionScript files and compiling everything. That’s unfortunately not the case. There are a few weird things I call “Flash Magic”, which Flash Pro adds to the SWF in order to make everything work. The two most important oddities every Flex developer needs to know about Flash projects are automatic instantiation of symbol members, and automatic promotions of local variables to members. Both concepts seem utterly counterintuitive and unnecessary to me. But that doesn’t matter. It’s part of reality and one has to deal with it. Fortunately automatic promotions of local variables to members didn’t seem to be a problem in Pew Pew. So let’s focus on automatic instantiation of symbol members and have a quick look at Main.as :

public class Main extends MovieClip
{
...
//instantiated within FLA
private var gameArea:GameArea;
//main game menu view
private var gameMenu:GameMenu;
...
//background
public var background:MovieClip;
...
//main entry point for applications
public function Main()
{
//note stage quality is always set to best in Adobe AIR. Have it
//set to HIGH here in case we are running in browser
stage.quality = StageQuality.HIGH;
stage.align = StageAlign.TOP_LEFT;
stage.scaleMode = StageScaleMode.NO_SCALE;
//listen for when we are added to the stage
addEventListener(Event.ADDED_TO_STAGE, onStageAdded, false, 0, true);
//cache bitmap so it can be accelerated
background.cacheAsBitmap = true;
//dont need mouse events on background, so disable for performance
background.mouseEnabled = false;background.mouseChildren = false;
stop();
}
...
}

You will probably agree with me that the code above as it has been checked into github looks very suspicious. Our Main class declares a background member of type MovieClip. Then Main’s constructor code uses background before it has been created. Where is the code that does “new MovieClip()” ? You won’t find it, because it is part of the “Flash Magic”. If you open Windows/Library in the Flash IDE you will find an entry for Background. As far as I know Flash automatically instantiates class members if they are listed in the Library.

Adding a SymbolManager

In order to convert the code in Main’s constructor to proper, coherent ActionScript I had to add these two lines:

By doing so I could use the same ActionScript code in Flash and in Flex. In the Flash version the background member would be automatically instantiated but in the Flex version we would instantiate background manually. I could have initialized background with just “new MovieClip()”. But I decided early on to encapsulated all the work for emulating “Flash Magic” into one class, which I named SymbolManager.

Lost in space

Some symbols like Ship have an initial transform, that SymbolManager also has to emulate. For example if you select GameItems/graphics/ship_graphic in Flash IDE’s Window/Library and observe the Transform panel you’ll notice that Ship is rotated by 90 degrees and also scales x and y axis by about 51.8%. The Info panel tells us that the initial x/y positions are set to 0.0/0.0.

Unfortunately I didn’t find the values that the Flash IDE gave me very reliable. In order to get correct values I had to export my symbols to FXG (File/Export/Export Selection, format=FXG). The exported Ship.fxg for GameItems/graphics/ship_graphic was just an XML file and looked like this:

As you can see rotation and scale values are listed as attributes of the BitmapImage tag. The interesting part is in the GameItems_graphics_ship_graphic tag, which is the container of the ship image. That container tag sets x and y to -12 and 15.35. You will never find those values in the Flash IDE. But they are very important in order to correctly set up the initial transform.

With the FXG information I was able to implement SymbolManager.createShip() and onShipLoaded, which gets called when the ship bitmap has been loaded:

There were a few other minor things I had to adjust in the Pew Pew. But I was eventually able to create a Pew Pew SWF from Flex. Once I had a coherent Flex project it was pretty easy to cross-compile Pew Pew to JavaScript.

A fine line

In the end it took me about three days to reanimate the old Pew Pew prototype with the latest version of my cross-compiler. Along the bumpy way I fixed a bunch of regression bugs and a few new ones as well. It was quite a moment of victory when I hit the debug button in Visual Studio 11 and Pew Pew finally worked in Metro. I thought, if I put in a little bit of work I might be even able to submit this game to the Windows 8 First App Contest I had just read about.

Being able to cross-compile that old Pew Pew prototype to Metro was a big accomplishment for me, which I wanted to share with my wife, who was sitting right next to me. The conversation that followed went like this:

Me: Hey, I got Pew Pew up and running in Metro! She: That’s great, let me see. Me: Here it is. It needs a little bit of work, though. I am thinking of submitting it to the contest. She: You will never win the contest with something like that. Me: What do you mean? The graphics? It’s supposed to look crummy. It’s charming. She: There is a fine line between “crummy” and “crappy”.

I knew I was in trouble. Cross-compiling ActionScript to JavaScript was one thing, developing a cool game that is not crappy is a completely different beast I would have to tame.

Setting up Metro on a Mac

After a few relaxing days of catching up with my in-laws and eating way too much good food it was time to get my hands dirty with Metro. I only brought my MacPro laptop to Omaha. So how does one install Microsoft’s Windows 8 Developer Preview on a Mac? This is how I did it:

I downloaded the Windows 8 Developer Preview ISO file (which is not available anymore, instead just use Windows 8 Consumer Preview).

I created an empty vmware image and installed Windows 8 from the ISO file through vmware’s CD drive emulator.

I took a snapshot called “Windows 8 Developer Preview”

This may surprise you, but I would have done the same on my Windows machine at work. I highly recommend sandboxing new operating system versions that are under development with virtualization software like VMware or VirtualBox. This method just saves you many troubles. Take many snapshots and just roll-back if things get too messy (as things tend to during software development).

Launching Metro

Then I launched Windows 8 in my sanitized vmware sandbox and made myself familiar with my new environment. Metro reminded me of Windows 7 for phones. It was all very “touchy.” I have to admit, at first I didn’t like the Tile metaphor. Tiles remind me of bathrooms and hospitals. They break into shards when they hit the ground and they are cold unless you have heated floors. I know, UI design is more difficult than one thinks it is, but I wondered, why didn’t they choose something organic like Leaves instead? Perhaps even Pillows?

Developer Tools

As far as I can remember Windows 8 Developer Preview from September 2011 came with Visual Studio 11 Express pre-installed. In case you run the latest Windows 8 Consumer Preview you need to install the Developer Tools and SDK with Visual Studio 11 Express Beta in a separate step. VS 11 looks pretty much like the previous versions except for a few new options like creating Metro Style JavaScript App projects. This all looked pretty encouraging. I was eager to write my first Metro Style App, Hello World.

Hello, Metro

Of course, I had no idea how to write a simple Hello World Metro Style app. So I downloaded the Windows 8 Sample Pack and looked for a Hello World sample. There was one example called “DirectWrite hello world sample.” But that didn’t look simple at all. I believe I ended up picking the “App tiles and badges sample” and built it. When I hit the debug button VS linked the app, deployed it to Metro and launched it without problems. That was easy.

Just for fun I decided to create a blank Metro Style JavaScript App Project and sniff around a little bit. VS 11 created a bunch of files, one of them was named default.html, which included default.js . That had to be the entry point! Sure enough, when I opened default.js I saw that WinJS.Application.start() brings the app to life, which would eventually trigger the call to WinJS.Application.onactivated – a function that I could, for my convenience, override:

I noticed two namespaces: Windows.* and WinJS.* . Apparently, the Windows.* namespace corresponds to Windows Runtime, which “is designed for use with JavaScript, C#, Visual Basic, and C++”. The WinJS.* namespace on the other hand refers to “the Windows Library for JavaScript is a set of JavaScript and CSS files that make it easier to create Metro style apps using JavaScript”.

I was feeling ready to try running a simple cross-compiled app. Why not SpriteExample?

SpriteExample for Metro

One of the first ActionScript apps (if not the first one) I ever cross-compiled to JavaScript was SpriteExample.as . I simply imported my cross-compiled SpriteExample.js into the empty “Hello, Metro” project and made a small change:

The only step left was adding a script tag to default.html, which loads SpriteExample.js:

<script src="/js/SpriteExample.js"></script>

Frankly, I was shocked when I saw SpriteExample running in Metro without problems.

This all was way too easy. Could it be that it was in fact super easy to develop Metro Style apps using ActionScript and my cross-compiler? I had to try a more complicated project. I was convinced, at one point reality would stop me from doing what I was doing. So I chose Pew Pew as my next project…

Attention Earthlings!

If you download and install Microsoft’s Windows Consumer Preview of their upcoming Windows 8 operating system and click on the Store button you will find a rapidly growing number of apps. One of them is a game called Pew Pew, which I submitted for the First App Contest. The description reads:

Attention Earthlings! This fun, retro space shooter game allows you to destroy enemy ships and UFOs from the safety and convenience of your home planet. Rack up points while protecting your planet from invasion.

Pew Pew was originally written by Mike Chambers, who is currently the Directory of Developer Advocacy for web platforms here at Adobe. In 2010 Mike published Pew Pew’s source code under the MIT license at github. The original Pew Pew version was written in ActionScript and in order to turn Pew Pew into a Metro app I had to solve three problems. First I downloaded the latest Pew Pew source code from github and cross-compiled Pew Pew’s ActionScript code to JavaScript. Then I improved the game and added Metro features before submitting Pew Pew to Microsoft’s App Store. This all happened in 9 weeks between 12/17/2011 and 2/17/2012.

Restless Developer Syndrome

Vacation! On 12/17/11 my wife and I hopped on an airplane in Seattle to visit her parents in Omaha. Those, who know me better, have accepted that I am one of those developers that always work – even on their vacations and honeymoon. I call it Rest Developer Syndrome while my wife thinks I am just a workaholic.

As in most cases, my wife is probably right, but still, in my opinion there is a difference between work and “work”. When I am on vacation I can finally catch up with all the new stuff that had come out in the past few months. That’s not work for me, that’s even more fun than my regular work! There was that //build conference that I missed in September 2011, when Microsoft revealed its new Windows 8 operating system with something completely new called Metro. Fortunately Microsoft made recordings of the keynotes and many talks publicly available. So I downloaded five or six of those videos and watched most of them during the long flight from Seattle to Omaha on my slow iPad.

Learning about Metro

I started with the keynotes, which seemed a little bit hectic as most keynotes usually are (only few deliver brilliant keynotes as Steve Jobs did). I did learn from those keynotes that Windows 8 would introduce a new user interface called Metro in addition to the “traditional” desktop. Only Metro style apps would run in Metro, they said, and developers would be able to write entire apps in JavaScript, because Metro’s JavaScript API would allow developers to access the operating system through a new, unified Windows Runtime layer. In Windows 8 you could only install Metro apps through Microsoft’s new App Store. That’s how developers would make money (and Microsoft would make a few pennies, too).

I didn’t mind seeing Microsoft try to catch up with Apple and Google by opening their own App Store. I love competition, I love Freedom of Choice! What really intrigued me was that I could access the operating system through Metro’s JavaScript API. I had been cross-compiling a lot of complex ActionScript projects for almost a year and by December 2011 I had become a fearless gladiator. The biggest limitation when cross-compiling ActionScript to JavaScript was the browser and its DOM. For example, there was (still isn’t) any way to access the camera from JavaScript unless you used something like PhoneGap. If it were really true (as Microsoft promised in the keynotes) then Metro would open a gigantic candy store right in my own neighborhood: access to the OS layer. I definitely wanted to learn more about Metro.

Jensen’s talk walks you through each of those traits and frankly, I was surprised. Something was really different with this guy and Metro itself also seemed different from what I had expected. I had to watch another talk about Metro.

Designing Metro style: principles and personality

The next talk I picked was Samuel Moreau’s talk about Designing Metro style: principles and personality and this one just blew me away. Sam, who is a director at UX Design and Research at Microsoft, explains the background and inspirations for Metro style design. He identifies three key influences:

Modern design (Bauhaus)

International Typographic Style (Swiss Design)

Motion Design (Cinematography)

Sam’s talk really opened my eyes. I realized, that Metro is not some flashy technology tacked on to a mature operating system (the lipstick on the pig if you will). Instead I had to look at Metro as a new paradigm. The gladiator in me knew that cross-compiling ActionScript projects to Metro wouldn’t be as easy as I thought it would be. Bringing some cross-compiled JavaScript up and running in a new environment alone won’t do it for Metro. Metro is a different beast.

A New Microsoft?

Jensen Harris and Samuel Moreau really surprised me in many ways and it took me a while to put my finger on what it was. Their talks were interesting and I didn’t feel lectured to at all. Instead of past attitude, I sensed a human side that I found refreshing. Those guys seem to be normal people and their reasoning resonated with my way of thinking and cultural values. I wondered, is there maybe a new breed of developers and managers like Jensen and Sam emerging within Microsoft? Perhaps there is a New Microsoft forming within the Old Microsoft? One can only wait and see.

Ground Rules

By the end of our flight to Omaha I have already decided to dive into Metro. But I also wanted to spend the holidays with my wife, who I love very much, and her wonderful family. So I came up with these ground rules for my new Holiday project: I should not work more than 3-4 hours a day on this, or any project that involved me being emerged with my laptop.

After almost three long months of writing about cross-compiling ActionScript to JavaScript I would like to start a new series of blog posts that is perhaps a little bit more entertaining but also contains information that you will hopefully find useful.

“You may recall we issued a challenge to developers to be among the very first to be featured in the Windows Store. Under tight deadlines, and limited only by their own imagination and creativity, they responded!”
Source: Introducing the winners of the First Apps Contest

If you go to the Windows 8 First App Contest website and you scroll down a little bit you will find an app called Pew Pew and my name next to it. Yep, that’s me. I somehow managed to be one of the eight winners. In the following weeks I going to tell you about the crazy journey that eventually led to Pew Pew becoming one of the first apps in Microsoft’s App Store.

After discussing optimizing and debugging cross-compiled ActionScript I would like to take a look at testing cross-compiled ActionScript. The short answer I can offer is: testing cross-compiled ActionScript is not much different from testing JavaScript. But of course there is more to it. There is always more…

Testing your patience

Be warned, this is a long post. I thought about splitting this post up as I have done in previous posts. But in this case I think everything should stay together. That said, let’s dive in!

In my opinion there are two different testing scenarios:

Testing your cross-compiler.

Testing client code.

In both scenarios we test JavaScript, but as we will see the goals and methods are different. Before we jump right in let me also point out that there are two types of testing, automated testing and manual (interactive) testing. Of course we prefer automated testing, because it is cheaper, less error prone, and can be integrated into Continuous Integration (CI) loops.

For running the Tamarin Acceptance Tests, which tests the cross-compiler, I use Chrome’s d8 (the debugger for V8) and for testing client code and running regression tests I use the default browser (usually Safari on OSX) with Google’s js-test-driver.

Correctness versus Consistency

As mentioned above the goals for testing your cross-compiler and testing client code are different. When you test your cross-compiler you want to ensure that all language constructs in the source language are correctly cross-compiled to the target language. The term “correct” refers to preserving the internal consistency of the source code in the target code, not correctness in an abstract sense. I tried to explain this idea in a previous post, where in ActionScript and JavaScript you’ll get a mathematically incorrect result when adding 0.2 to 0.1:

I argued that in the context of cross-compiling one language into another it is very important to produce the same results in both worlds (here 0.30000000000000004) even if the results are incorrect. Our test suites need to follow that principle as well. As wrong as it may seem we should include a unit test that tests against 0.2 + 0.1 = 0.30000000000000004.

Missing Language Specification

Testing implies that you know the correct and expected results of your tests. When testing your cross-compiler the expected results are defined by the grammar of the source and target languages. What we need in our case are the language specifications of ActionScript and JavaScript. Herein lies a big problem. While the current JavaScript specification is summarized in ECMA-262 you won’t find a language specification for ActionScript. Just to be clear, a “language specification” is a document that describes the language grammar (usually formulated in Backus-Naur Form), so that developers can build a compiler for that language. A language specification is not a tutorial, FAQ, or online help about that language. For example Dart has a language spec, on the other hand Coffeescript’s langage reference does not qualify as a specification.

Neither does ActionScript’s online help. The closest to a language specification that Adobe currently offers is a section in the online help called Learning ActionScript 3.0 . You might argue that an ActionScript language specification is not really necessary, because the syntax of ActionScript is by now well known and documented. I am afraid you cannot assume that everything about ActionScript is well documented. Just try find the exact syntax for Vectors in Learning ActionScript 3.0. I found this snippet under Array/Advanced Topics (you also find other bits and pieces under Basics of Arrays):

Note: You can use the technique described here to create a typed array. However, a better approach is to use a Vector object. A Vector instance is a true typed array, and provides performance and other improvements over the Array class or any subclass. The purpose of this discussion is to demonstrate how to create an Array subclass.

Even though it’s not really my fault, I truly regret that Adobe has never properly published a language specification for ActionScript. One could even argue that all computer languages can be divided into “hobby languages” and “professional languages”. The latter have language specifications.

Tamarin Acceptance Tests

The lack of a language specification for ActionScript has another nasty side effect. Without a language specification you also won’t find a corresponding language validation suite, which tests a compiler against the language specification. But that’s exactly what we need: a test suite that tells us that our cross-compiler complies to the language specification.

The next best thing to a language validation suite are currently the Tamarin Acceptance Tests. Those tests are grouped into different sections:

abcasm

as3

e4x

ecma3

misc

mmgc

mops

recursion

regress

spidermonkey

versioning.

Of those sections the most important ones are as3 and ecma3. The ecma3 section covers about 40,000 unit tests while as3 only has about 650 unit tests. I suspect the name “ecma3″ refers to the 3rd edition of ECMA-262. In reality, though, the tests seem to validate against the latest edition, which is the 5.1 edition of ECMA-262. Unfortunately we can’t really tell what the ecma3 folder is testing against, because there is no ActionScript language specification, and the Tamarin Acceptance Tests don’t claim to be the language validation suite.

Oberflächenverdoppelung

In fact, the Tamarin Acceptance Tests only seem to care about the behavior of the ActionScript VM in the Flash Player not changing in new versions of the Tamarin VM. The definition “ActionScript is what passes the Tamarin Acceptance Tests” does unfortunately not work as we will see in the following chapters.

There is a wonderful, but rarely used German philosophical term for this kind of circular reasoning (ActionScript is what passes the Tamarin Tests, which validate Tamarin VM results, which reflect ActionScript language rules). It is called “Oberflächenverdoppelung“, which I would translate as “surface duplication“. By creating tests that just confirm the results of an existing VM you only reiterate the knowledge of your own belief system. Instead of probing for truth you merely duplicate the surface of what you already know.

typeof Number

Assuming that the “ecma3″ section of the Tamarin Acceptance Tests validates against ECMA-262 (even the 3rd edition) there is a cluster of tests, which are in my opinion incorrect. To be precise, I believe ActionScript does not always comply to ECMA-262, and the Tamarin tests just bend to the status quo of ActionScript. For example, test e15_4_2_2_2, which is under ecma3/Array, would fail in every browser, because of this tiny difference between ActionScript 3 and JavaScript:

// ActionScript
typeof(new Number()) == "number"

// JavaScript
typeof(new Number()) == "object"

I asked our specialists here at Adobe why there is this difference and this was one of the replies:

“In javascript, new Number(…) evaluates to an Object that wraps a number value. In AS3, new Number(…) return a number value. In both languages the Array constructor creates an Array of length 1 if given an object and an array of length n if given a number, where n is the value of the number.“

But does ECMA-262 really allow both points of view? Is it allowed to return a number value for “new Number(…)” without fragmenting the language specified by ECMA-262? The ECMA-262 Language Overview chapter says (highlights added by me):

ECMAScript defines a collection of built-in objects that round out the definition of ECMAScript entities. These built-in objects include the global object, the Object object, the Function object, the Array object, the String object, the Boolean object, the Number object, the Math object, the Date object, the RegExp object, the JSON object, and the Error objects Error, EvalError, RangeError, ReferenceError, SyntaxError, TypeErrorand URIError.

Number is clearly defined as an Object and typeof(new Number()) = "object" seems to be the correct result according to ECMA-262. There is also a whole chapter on Number Objects in ECMA-262. But I couldn’t find any supporting arguments for typeof(new Number()) = "number".

As mentioned earlier it is important to preserve the behavior of the source language in the target language. But I decided that in this case, ActionScript (and the bending Tamarin tests) are incorrect, if you assume that “ecma3″ really does validate against ECMA-262. This would be similar to, say, getting 0.2 + 0.1 = 0.30000000000000004 in AS3 and 0.2 + 0.1 = 0.3 in JS. If you get a different result in AS3 and JS and JS reports the correct result I usually decide against AS3. You can’t rely on the Tamarin Acceptance Test. Their definition of correctness only preserves behavior exhibited in pre-existing C++ implementations of the ActionScript VM.

In either case, this was one of the rare exceptions where I decided to stick with ECMA-262 and not with what the Tamarin tests says is ActionScript (who really knows what ActionScript is without a language spec). As we just learned, one nice thing about language specifications is that there are almost no ambiguities (Number is an Object). I’ll get to the “almost” in a second.

function.toString()

There are many more Tamarin tests, that I find questionable and sometimes even absurd. This one is particularly annoying, because the test could have been phrased to serve a broader definition of what function.toString() may return. This code yields different results in ActionScript 3.0 and JavaScript in browsers:

(Array(1,2)).toString;

// Result in ActionScript
"function Function() {}"

// Result in JavaScript
"function toString() { [native code] }"

It turns out that ECMA-262 does not specify what function.toString() should exactly return. But we do know the retuned value is of type String and it should start with “function “. Instead of validating against “function ” the Tamarin Acceptance Tests unfortunately check for what the Tamarin VM returns, which is “function Function() {}” and therefore triggers numerous false negatives in browser environment.

What shall we do about it? Shall we perhaps decide against ActionScript like we did for “typeof Number” above? This is a tough one, and I don’t think I am allowed to implement the JavaScript version by ignoring the ActionScript version as I did with “typeof Number”, because ECMA-262 is in regards to function.toString() somewhat ambiguous. (At least I try to be consistent in the way I am fragmenting the ActionScript language!)

So here is the compromise that I came up with. I added a new compiler option to the cross-compiler called “-js-extends-dom”, which defaults to “true”. If you compile the Tamarin tests, -js-extends-dom will be true and the cross-compiler will emit this ugly glue code at the top of your generated JavaScript:

The glue code above contains all the hacks for passing the Tamarin tests. In October 2011 my cross-compiler passed 40930 of the ecma3 Tamarin tests, which is about 95%.

In case you are wondering, of course I tell all my clients to run my cross-compiler with -js-extends-dom=false.

Validating versus Testing

In my test suite I differentiate between validating and testing. Validating unit tests generate JavaScript that I diff against a known, correct JavaScript version of the same test. All other tests are just run in the browser or in d8 as mentioned earlier. If the generated JavaScript is different during validation, I’ll get an error. If I accepted the newly generated JavaScript as the correct version then I would copy the new version to the saved version. If I detected a bug in the delta code of the newly generated JavaScript, I would reject the build. This method has been very successful and helped me keeping my bug regression rate at an astonishing low level.

Testing Client Code

I have a few test apps that I always cross-compile as part of my unit tests. One of them is SpriteExample, which is one of the first examples that I ever cross-compiled to JavaScript. You can find that example at the bottom of the Flex online help for flash.display.Sprite .

The SpriteExample is actually not that trivial, because it uses constructor functions (which I very much dislike):

var sprite:Sprite = Sprite(event.target);

In order to get this example to work you would also have to solve event dispatching and drag and drop for Sprites. The drag and drop part can only be tested manually, though.

The End

That’s it, I hope! Now I have told you almost everything I know about cross-compiling ActionScript to JavaScript. There are still many topics that I could discuss in more detail. But after almost three month since my first post when I started this series, I think, we all deserve a break.

Next week, I am starting a new series about something completely different. Well, maybe not completely different…