Pew Pew Chronicles: Planning A Death March

This is part four 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 looked crappy.


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:

  1. Damage report
  2. Research & extracting features
  3. WAGs
  4. Prioritizing features
  5. Implementation!
  6. Debugging & testing
  7. Release Candidate
  8. 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

Ian Lobb wrote a great code review of Pew Pew, which gave me some good pointers for improving Pew Pew:

  • Use hand-written looking font, rather than Helvetica
  • 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.



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.

There was only one way to find out whether this was an insane plan…




Comments are closed.