Why WarLight switched from Silverlight to Flash

The old-timers all remember back when WarLight was a pure Silverlight site. The original post explaining why the change was made is buried in an old forum post, so I figured I would document the switch here.


I first started writing WarLight with the Silverlight 1.1 Alpha. At the time I was just playing around with Silverlight to see what it was; I had no idea WarLight would balloon into something as big as it has. I liked what I saw in Silverlight, as it was quick, efficient and allowed me to easily share C# code between the client and server. This allowed me to get a prototype up and running quickly.

WarLight launched using the Silverlight 2.0 beta, and migrated to 2.0 RTM on launch day and then to 3.0 RTM shortly after it launched. Sadly, this is the last version of Silverlight that WarLight would ever see.

The Switch

Fast forward to September 2009. I had just finished adding the Single-Player mode to WarLight, and had decided that I enjoyed working on WarLight and wanted to continue with it. Silverlight was, unfortunately, the biggest thing holding WarLight back. Silverlight’s marketshare was less than 50% according to riastats.com, meaning that most players coming to WarLight were faced with an install prompt. Admittedly, Silverlight’s install rate rose very quickly – much more quickly than I expected. Getting to almost 50% in such a short time is unprecedented in terms of browser plug-ins.

Asking users to install a plug-in to use a website is a huge barrier to entry, and is unacceptable to me. Many users want to play from work/university/library computers where they don’t have Administrator access and can’t install anything. Many users also just don’t want to install things, which is understandable – my standard procedure is to immediately close the tab when a site wants me to install QuickTime, Java or Unity. (I have nothing against Unity, it just always crashes during install on my main PC for some reason.) And yes, I know Flash is a plug-in too. However, Flash’s 98% marketshare means that for the vast majority of users, no install is required.

The bottom line is that Flash is the de-facto standard for web-based games. Silverlight has definite potential as it’s more developer friendly and, in my experience, performs better. But Silverlight is new and I’m not willing to wait for its marketshare to be comparable to Flash’s.

I often get asked why I didn’t port it to a HTML/Javascript solution using HTML5′s canvas. That’s easy – canvas’s marketshare was far less than Silverlight’s (probably less than 10%), which is a big step in the wrong direction. At some point in the future I’d love to do this, but 2009 was certainly not the time.

Comparison of Flash and Silverlight

Both Flash and Silverlight have their advantages and disadvantages. Writing the same application in both has given me a good appreciation of the differences between them, at least as it compares to WarLight’s specific requirements.

This section specifically compares Silverlight 3.0 with Adobe Flex 4.0 running in Flash 10. Flex is required for an adequate comparison, as Silverlight has things like buttons, checkboxes, sliders, and a layout system built in. To get these things in the Flash world, Adobe provides Flex which is a layer on top of Flash.

  • Layout: Comparing the flexibility of the layout systems, I prefer Silverlight’s. Silverlight’s objects fill to their parent by default, whereas Flex requires you to put width/height=100% all over the place. Although, being able to say width=50% in Flex is nice, which takes more typing to do in Silverlight. Flex’s VGroup/HGroup only let you set an alignment for the entire container, whereas Silverlight’s StackPanel lets you set the align for each object in the container.
    Winner: Silverlight.

  • Mxml vs Xaml: Silverlight uses Xaml to design its UI whereas Flex uses Mxml.
    Mxml is nice since you can put event handling code right into the mxml file, but Xaml’s attached properties are a thing of beauty, since they avoid Flex’s problem of having a ton of unusable properties on every object.
    Mxml has hacks like a “width” attribute that sets either the “width” or “percentWidth” properties depending on whether or not you include a %. This is lame, as it’s unintuitive as soon as you try to set it via code.
    Some of the Mxml properties are considered “styles” which mean you can’t set them via a normal property assignment. You need to use the setStyle() method, which is unintuitive since they look just like properties. Silverlight has a similar issue with attached properties, requiring you to use SetValue(), but at least you can easily see in the Xaml which properties require this.
    Visual Studio was always slow to open Xaml files for me, sometimes over 10 seconds. I don’t use the designer, I had them always set to open as text, but I suspect some designer-related components were loading anyway that I couldn’t figure out how to turn off. Endless frustration!
    Xaml is just serialized .net objects, which makes everything intuitive and easy. You can import/export Xaml yourself very easily with XamlReader and XamlWriter, and you can even load Xaml at runtime. Mxml is statically compiled, and can’t be loaded at runtime.
    Winner: Silverlight. Xaml is just a well-designed markup language.

  • Language: Flash uses ActionScript, Silverlight allows (almsot) any .net language but most people use C#. This is one of Flash’s weak areas, as ActionScript has decades of baggage that make it a frustrating coding experience. Although it’s clear that Adobe is trying, as they do support closures, first-class functions and garbage collection. However, the inability to share code between the client and other languages give this one to Silverlight easily.
    Winner: Silverlight by a landslide.

  • Component Customization: Silverlight allows any object to contain any object. For example, you can easily put a list box inside of a button (not that you’d want to…). Flex is a more traditional UI layout system, which tries to cover the most common scenarios but ultimately leaves holes. You can still do more powerful things using skinning, but it’s a lot more cumbersome. I recall having to copy+paste over 100 lines of mxml just to have a button with two lines of text. Sad!
    Winner: Silverlight.

  • Automated Testing: Both Flex and Silverlight have poor automated testing tools. I used the Silverlight Unit Test framework and was able to get it working successfully, but for testing an asynchronous app like WarLight, you have to do all sorts of crazy lambdas and callbacks just for basic operations. This makes maintaining state and looping within a test difficult, and also requires that you run your test code on the UI thread.
    With Flex, I used Selenium with a Flex plugin and it avoids the problem above, but required I write a bunch of plumbing code to give myself strong binding between my app’s UI and the test code.
    Winner: Only losers here.

  • Error Reporting: Silverlight has a global error handler that gives you the exception object which includes details of the error, and a stack trace, even in retail builds of Silverlight.
    The retail version of Flash eats all errors. This is a problem for me, as being able to fix errors quickly is important to me. Flash required me to do a bunch of extra work in this area. Every entry point must do a try/catch in order to handle and report errors gracefully. What a pain!
    Even then, you have no stack traces in retail builds. Without stack traces, you often get back an error where the extent of the message is “1009.” 1009 is the Flash code for a null reference exception, but just knowing you have a null reference exception somewhere in your app is not enough to fix the problem. You can put an identifier on each error handler so you at least know the entry point, but that wasn’t enough for me.
    So I wrote a routine that would track stack traces myself. I wrote some rudimentary ActionScript parsing code that injects a PushStackTrace() call to the start of every function, and a PopStackTrace() at the end. Using this, I can track the stack trace all of the time, and when an error occurs I include it in the error report. This has been wonderfully useful, but it took a lot of work just to get back to what Silverlight does for free.
    Flex 10.1 added a global error handler, but you still don’t get stack traces even in 10.1, so it doesn’t solve the issue.
    Winner: Silverlight by a landslide.

  • Performance: Although I haven’t taken measurements, there was clearly a noticeable and significant drop in performance after migrating to Flex. I believe this is specifically attributed to Flex, not Flash. The speed of constructing bunch of Flex objects (order details) and placing them into a scrollable panel (the orders list) made scrolling through the history of a WarLight game much slower than it was in Silverlight.
    Winner: Silverlight.

  • Adoption: Covered above.
    Winner: Flash by a landslide.

  • Bugs: I ran into bugs on both platforms. I’ve reported a few back to Microsoft and Adobe, but overall I wouldn’t say that either platform is more or less buggy than the other.
    Winner: Wash.

  • Overall Winner: Flash! Flash is of course the winner, as WarLight uses Flash today. I’m not particularly tied to the Flash platform, and I’d be happy to move to something new in the future if the move makes sense.

Announcing Beta Phase 22.1: Minor release

WarLight will be upgraded tonight with a small release that contains mostly of bug fixes, but I was also able to sneak in a few features.

WarLight will be going down on Sunday, January 16th at 1am PST (9am GMT) for up to an hour. Please plan accordingly for any fast games or single player games that may get interrupted during this 1-hour window.

During this time, WarLight will be upgraded to Beta Phase 22.1. Once the deployment is complete, you can view all of the changes on the Change History page.


Initial Pieces: Once Phase 22.1 is live, game creators can specify how many cards (or pieces of a card) that players will begin with at the start of a game. Not only is this useful for making the beginning of games more interesting, but it also allows for further customization in variants. If you also set a card’s weight to 0, you can now make cards that are limited in quantity. For example, you could give just one abandon card to each player. They’d only have one for the entire game, so they would need to make good use of it.

Facebook Integration: WarLight will have a “Share on Facebook” button, which assists you in gloating about your wins on Facebook.

Many more small changes and fixes: Such as the refresh hotkey, which allows players to press the “R” key as a shortcut to clicking the Refresh button.

Announcing Beta Phase 22

Phase 22 is the biggest release of WarLight since it ported to Flash! First, business:

WarLight will be going down on Wednesday, January 5th at 1am PST (9am GMT) for up to an hour. Please plan accordingly for any fast games that may get interrupted during this 1-hour window.

During this time, WarLight will be upgraded to Beta Phase 22. Once the deployment is complete, you can view all of the changes on the Change History page.

Personalized Game Templates

Once phase 22 is live, whenever you create a customized game, WarLight will ask you if you’d like to save your game settings as a template. You can then use that template to easily create games with the same or similar settings.

Not only will this ease the burden of creating new games, but it will also allow you to share your settings with other players. Each template will have a URL associated with it that you can give out to let other players use your templates.

Phase 22 will also allow you to create new templates/games with the same settings as any existing game, whether they were created with a template or not. This allows you to easily create rematches, or create templates from the games created by other players or games you created before templates were available.

Being able to save your game settings as templates is great, but when combined with custom scenarios, phase 22 really opens up a lot of new doors.

Custom Scenarios

Once phase 22 is live, game creators can elect to forego the built-in map distribution system and enter, territory-by-territory, exactly how they want the map to be distributed.

This gives game creators an incredible amount of power, and opens up all new styles of gameplay. For example, game creators could:

  • Give players handicaps, such as starting one player with fewer armies. This is useful for introducing WarLight to a new player, or when veterans just want to give themselves additional challenge.
  • Hand-craft a strategic map so that bonuses that start with wastelands in them are worth additional armies per turn, giving incentive to take down the wasteland.
  • Finely-tune a 1v1 map by picking which territories are available for players to pick, or making less-desirable bonuses start with fewer neutral armies, or placing wastelands in strategic positions.
  • Create a Godzilla scenario where one player starts with 10,000 armies, and 20 other players are teamed up to take them down.
  • Many more – the possibilities are endless!

Design your own single-player levels

If you think about custom scenarios and game templates, you’ll realize that they give you the power to do everything the current single player levels do. In fact, the existing six single player levels are being made into templates!

This opens up a wealth of possibilities. Perhaps you’ve always wanted to play level 1 reversed – where the AI is about to get Europe and you start in Australia. Or maybe you want to try the Europe challenge as Russia instead of Britain. These templates can even be used in multi-player, which means you could do the Europe or Insane challenges cooperatively with a friend!

Not only can you customize the existing six single player levels to your heart’s desire, but you could even make your own from scratch, and share them with other players using the templates feature. I may run a single-player level design contest, where the winners can have their levels included into the game.