Porting Wordament to Windows 8

With the release of our first beta of Wordament on Windows 8, we made a big move. On Windows Phone, your two options for app development are XAML (Silverlight) / C# and XNA (DirectX-like APIs) / C#. So, either way, you are writing in C#—which is a terrific language. On Windows, you have nearly unlimited coding options, but the three primaries during Consumer Preview are: HTML / JS, XAML / C#, and DirectX / C++. We chose HTML / JS. Why? Why on earth would we choose to port a substantial and relatively stable code base? A variety of reasons, some of which we can talk about today:

  • We love HTML, and JavaScript is OK.Honestly, our preferred option would have been HTML + C#. HTML is a tremendous forms and layout package with tons of standards and support. There’s nothing easier than running into a problem and being able to find 1,000+ solutions on the interwebs and Stack Overflow because you often aren’t the first person to run into that problem. HTML has evolved SO much in that past five years and Internet Explorer-based HTML with full GPU acceleration is GREAT for 2D + 2.5D games. We aren’t even using a canvas!

    JavaScript is a pretty good language. It’s no C#, but with the right combination of tools and approach, it’s not terrible. Some aspects (like the fact that you don’t need to rigidly define every last type) makes things much more developer efficient. Perhaps the most important thing to consider as a JavaScript developer is: which JavaScript “denomination” you want to abide by (more on that below).

  • Long-term developer efficiency. This one is going to sound a bit backwards. Porting is never faster than a recompile, is it? Well, there was going to be porting either way. The XAML page model is slightly different on Phone than Windows 8, and going from 3.5” to 11.6” is more than a port. It’s a reimagination of the layout. A good app is highly optimized for its environment. The XAML we have on Phone would conceptually port as well to XAML on Windows 8 as would rewriting it in HTML. One of the truly great things about Windows 8 is “tablet-style multitasking” which includes Full, Filled, and Snap layouts and that’s where we spent the bulk of our CSS time—making sure that the app looked right in all the various layouts. We still have bugs, obviously, but for a time-sensitive first stab for Beta, we are pretty proud of how much we got done so quickly. Long-term, it seems logical (at least to me) that across the industry there will be more investment in HTML than in XAML. I’m sure the XAML folks don’t like me saying that, but if you think about it as purely a numbers game, there are more devs in the world working on HTML in every way than there ever will be on XAML. So, if you can’t beat ’em… might as well join ’em.
  • Testing out the newest Windows 8 Dev Platform. While our managers in Microsoft Studios don’t care what languages we choose to use, we thought that for the greater benefit of Microsoft, it would be a good experience to try and port a decent-sized mobile app from one set of technologies to the other at which point we could share our findings with the Windows team (which we’ve since done). Having powerful tools like the DOM Explorer in Visual Studio is a game changer for UI devs. Click an element, figure out why it’s wrong… fix it… bug resolved. Wow. Also, building Metro-style Windows apps feels really fast and FUN.
  • Does our code port? This was purely a feel-good exercise for us. Last year, John and I went kind of crazy learning MVC and MVVM (we are closer to MVC than MVVM), and last July we rewrote the entire Wordament client (the version you are currently playing on Phone) as an MVC-style app. We were really happy to see how easily our code ported to JavaScript. In particularly, the C# and the JavaScript (pre-obfuscation) are almost line-for-line identical.

The only real downside of the entire adventure was the time it took us to hand port the JavaScript. I love learning new languages (an ECMAScript5 is not your father’s JavaScript). I started by reading the following terrific books (I recommend all of them):

The problem with JavaScript is: everyone has independently evolved their own ways of doing things. The first two books provide excellent guidance on “how to do it the right way” so you don’t fall into the pits that many other have discovered. The big gotcha we ran into during the port was selecting the right “JavaScript Denomination”. I say that, because it is almost like a religious decision—meaning there’s no “right” choice between different sets of people—and selecting one will choose your fate. You can change later, but it’s a rewrite to do that.

So, what am I talking about exactly? Determining how you want to write object-oriented code in JavaScript is a big deal. There are four different ways—all equally valid—as outlined by Crockford in Chapter 4 of JavaScript the Best Parts:

  • The Method Invocation Pattern
  • The Function Invocation Pattern
  • The Constructor Invocation Pattern
  • and the Apply Invocation Pattern

We started with the Method Invocation pattern, but have since abandoned that for the Constructor Invocation Pattern, because that’s what Google’s Closure prefers. We didn’t start with Closure, but have ended up using it as a tool in our build process because it:

  1. Adds additional “compile time checks”—stupid things like capitalization errors no longer plague our JavaScript.
  2. Optimizes JavaScript like an optimizing compiler would
  3. Minifies and obfuscates.

At this point, our build process is almost as straight-forward for JavaScript as it was for C# and our code performs great. By moving to HTML / JS, many of our animations are done in CSS and are “off the UI thread.” This leaves our JavaScript to doing the important stuff—commanding the game and responding to top-level events and operations.

Sadly, I think the biggest problem facing green horn developers today is the sheer number of tech-stack options you have to learn to really get moving: Want to write server stuff? Cool, learn PHP, Python, Java, C#, or Ruby. Want to write client stuff? Cool, learn Objective-C, Java, C#, or C++. Have you noticed something? There’s almost no overlap!

We could almost live in an all C# world is we wanted to only ever run on Microsoft devices, but even then… consoles require C++ and Web requires JavaScript. Our service was all Java and now it’s all C#. We could rewrite it to Node.js on Azure, but there’s a ton of OpEd pieces out there that call Node.js “cancer”. Harsh words.

At the end of the day, John and I want to build games. Fun ones that develop a great community like we’ve all discovered together with Wordament. We are developers by training, but UX and project managers by experience. We engineer because we have to—but what we really want to do is just build great games and communities. Any choice that simplifies our future will be one we are willing to take—even if there’s a short term cost to doing that. If we were to do it all over again, we obviously wouldn’t change anything. To get on Windows Phone means XAML and C#. To get on Windows 8 means picking. We are happy with our choices, and we hope this helps folks considering what to learn as they pick their Windows 8 coding option.

— Black Snapper


About Wordament

Wordament is a fun and addictive word game from You vs. the Internet, a Microsoft Studio.
This entry was posted in Uncategorized. Bookmark the permalink.

5 Responses to Porting Wordament to Windows 8

  1. JavaScript is OO as Sodomy is to consent.

    Nice read 🙂 cannot see JavaScript as a future tech, given it heavily relies on frameworks or tooling to unpick its mess.

  2. I think you can use multiple languages in the same project on Win8. Why didn’t you leave the core functions in C#?

    • Wordament says:

      You can, with pain. You can build either Managed or Native DLLs to accompany JS, but then you are really rearchitecting everything. The real problem: speaking in MVC terms, is that your Controllers can’t be in C#. Your Controllers would need to be in JS. At which point, you might as well have everything in JS. If you know something we don’t, we’d love to have a conversation, but we talked to some folks and the model seemed to be that HTML/JS are views/controllers and you can have models in JS or DLLs along with supporting functions.

  3. Thanks for the post, as someone who’s developing two Windows 8 apps, it’s great to get an insight into other developer experiences. The amount of languages to choose from is kind of insane right now. Personally I’m a fan of you’re suggestion HTML+C#.

  4. Pingback: Fixing a Metro-style app in Windows 8 Consumer Preview « Tim Anderson’s ITWriting

Comments are closed.