Pew Pew Chronicles: Submitting to the App Store

This is part six of a series of blog posts about a crazy journey that eventually led to Pew Pew becoming one of the first apps in Microsoft’s App Store. On a long flight from Seattle to Omaha in December 2011 I learned about Metro and got immediately hooked.  After installing Windows 8 Developer Preview and playing with Metro I discovered that I could even cross-compile Pew Pew to Metro. But there was a problem: this game was “crappy”, not “charmingly crummy” and unsuitable for submission to the Windows 8 First App Contest. My Death March Plan boiled down to improving Pew Pew first before implementing Metro features. Everything seem to be on track until my friend Christina made a video that recorded her first attempts to play the game. I clearly needed to to redesign a new joy stick and there were still a few features missing. According to my original plan I had nine hours left.

 

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:

  1. Create a new document in Photoshop.
  2. Create a new layer and import the original artwork (here a screenshot of the sample’s joystick).
  3. Dim that layer by setting the layer’s alpha channel to 0.5 to 0.75.
  4. Create a new layer on top of the first layer that contains the original artwork.
  5. Use a fine brush and manually draw the artwork by following the contours exposed by the dimmed layers.
  6. 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:

var appLayout : ApplicationView = Windows.UI.ViewManagement.ApplicationView;
appLayout = appLayout.getForCurrentView();
appLayout.addEventListener("viewstatechanged",  onViewStateChanged, false);

 

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().

const app : Application = WinJS.Application;
app.addEventListener("settings", onAppSettings, false);
private function onAppSettings(e:SettingsPaneCommandsEvent) : void
{
  pause();
  settings.writeSettings();

  e.detail.applicationcommands = {
    "gameOptionsDiv":
    { href: "SettingsUIFlyout.html", title: "Game Options" },
    "helpDiv": { href: "HelpSettingsFlyout.html", title: "Help" },
    "aboutDiv": { href: "AboutSettingsFlyout.html", title: "About" }
  };
  WinJS.UI.SettingsFlyout.populateSettings(e);
}

 

As you can see each Settings Charm (game options, help, about) has its own HTML file.

For more details about implementing a Settings Flyout please see the documentation for WinJS.UI.SettingsFlyout and SettingsFlyout.populateSetting.

 

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.

var mgr : DataTransferManager =
    Windows.ApplicationModel.DataTransfer.DataTransferManager;
mgr = mgr.getForCurrentView();
mgr.addEventListener("datarequested", onDataRequested, false);
private function onDataRequested(e:DataRequestedEventArgs) : void
{
  var txt : String = "Hey, check out Pew Pew. It's fun!"
  ...
  const request : DataRequest = e.request;
  const data : DataPackage = request.data;
  data.properties.title = "Tell your fellow Earthlings:";
  data.properties.description = "\"" + txt + "\"";
  data.setText(txt);
}

 

For more details about implementing the Share Source Contract please see the documentation for DataTransferManager and DataPackage.

 

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.

const app : Application = WinJS.Application;
app.addEventListener("checkpoint", onCheckPoint, false);
private function onCheckPoint() : void
{
  settings.writeSettings();
}

 

In order to access the roaming data storage in writeSettings I had to query the roaming settings from the ApplicationData

const applicationData : ApplicationData = Windows.Storage.ApplicationData.current;
const roamingSettings : ApplicationDataContainer = applicationData.roamingSettings;
propertySet = roamingSettings.values;
...
propertySet["highScore"] = highScore;
propertySet["leftHanded"] = leftHanded;
propertySet["score"] = score;
propertySet["lives"] = lives;
propertySet["wave"] = wave;

 

For more details about using roaming data storage please see the documentation for ApplicationData and 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.

const domWindow : DOMWindow = adobe.globals;
domWindow.addEventListener("blur", pause, false);
private function pause() : void
{
  ...
  // pause the TickManager
  const tm : TickManager = TickManager.getInstance();
  tm.pause();

  // dim the game area
  const currentView : GameSprite = viewManager.getCurrentView();
  currentView.alpha = 0.4;

  // add the pause button to the view
  pauseButton = createPauseButton();
  pauseButton.addEventListener(MouseEvent.MOUSE_UP, onResume, false);
  viewManager.displayOverlayView(pauseButton);
}

 

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.