To plug in, or not to plug in: that is the question! 

May 17th, 2012 by Elliott Mitchell

In recent years, we have seen a tremendous amount of attention to what can only be described as a debate between browser based plugins and their more standards based equivalent technologies, HTML & Javascript. Granted, even plugin providers can argue that they have open standards, but HTML definitely has its roots originating by a standards processes like W3C which is widely accepted by the web community. While we don’t want to go down the route of arguing for either side, it’s quite interesting to consider some of the available information freely circulating on the web.

Let’s start off first by examining some of the requirements of a plugin based deployment. If a webpage requires a plugin, often the end user will be prompted to install or update before they can proceed. This prompt is often met with resistance by users who either don’t know what the plugins are, have a slow Internet connection or receive security warnings about installing the plugin. While there are steps to install browser based plugins and these may present difficulties for some, most online statistics show that this hasn’t really affected adoption rates.

To address this, I thought it would be helpful to take a peek at the current trajectory of plugin usage, plugin alternatives like HTML5, and browser usage as to better inform developers to decide whether or not to create plugin dependent content for the web browser. Let’s first take a look at desktop web browser plugin usage between September 2008 and January 2012 as measured by

Flash – 95.74%
Java Support 75.63%
SilverLight Support 67.37%
Quicktime Support 53.99%
Window Media Player Support 53.12%

Unity – ?% (numbers not available, estimated at 120 million installs as of May 2012)

Flash has been holding strong and is steadily installed on a more than 95% of all desktop computers. Flash is fortunate that two years after it’s launch, deals were made with all the major browsers to ship with Flash pre-installed. Pre-installs, YouTube, Facebook and 15 years on the market have made Flash the giant it is. Flash updates require user permission and a browser reboot.

Java Support updates for browsers have been holding steady for the past four years between 75% and 80%. Some of these updates can be hundreds of megabytes to download as system updates. At least on Windows systems, Java Support updates sometime require a system reboot. Apple has depreciated Java as of the release of OSX 10.6 Update 3 and is hinting of not supporting it in the future, at which time Java would rely on manual installation.

Interestingly enough, Microsoft Silverlight’s plugin install base has been steadily rising over the past four years from under 20% to almost 70% of browsers. Silverlight requires a browser reboot as well.

Both Windows Media support and Apple’s Quicktime support have seen installs drop steadily over the past four years, down from between 70% – 75% to a little more than 50%. It is worth pointing out that both these plugins are limited in their functionality when compared to the previously discussed plugins and Unity, mentioned below. Quicktime updates for OSX are handled through system updates. Windows Media Player updates are handled by Windows Systems updates. Both Windows and OSX require rebooting after updates.

Unity web player plugin has been on the rise over the past four years, although numbers are difficult to come by. The unofficial word from Unity is it has approximately 120 million installs. This is impressive due to Unity emerging from relative obscurity four years ago. Unity provides advanced capabilities and rich experiences. Unity MMO’s, like Battlestar Galactica, have over 10 million users. Social game portals like Facebook, Brass Monkey and Kongregate are seeing a rise in Unity content. Unity now targets the Flash player to leverage Flash’s install base. *The Unity plugin doesn’t require rebooting anything (See below).

So what about rich content on the desktop browser without a plugin? There are currently two options for that. The first option is HTML5 on supported browsers. HTML5 is very promising and open source but not every browser fully supports it. HTML5 runs best on Marathon & Chrome at the moment. Take a peek at to see how desktop browsers score on supporting HTLM5 features.

The second option for a plugin free rich media content experience in the browser is Unity running natively in Chrome. That’s a great move for Chrome and Unity. How pervasive is Chrome? Check out these desktop browser statistics from around the world ranging between May 2011 to April 2012 according to StatCounter:

IE 34.07% – Steadily Decreasing
Chrome 31.23% – Steadily Increasing
Firefox 24.8% – Slightly Decreasing
Safari 7.3% – Very Slightly increasing
Opera 1.7% – Holding steady

Chrome installs are on the rise and IE is falling. At this time, Chrome’s rapid adoption rates are great for both Unity and HTML5. A big question is when will Unity run natively in IE, Firefox and/or Safari?

We’ve now covered the adoption statistics of many popular browser based plugins and the support for HTML5 provided by the top browsers. There may not really be a debate at all. It appears that there are plenty of uses for each technology at this point. It is my opinion that if the web content is spectacularly engaging, innovative and has inherent viral social marketing hooks integrated, you can proceed on either side of the divide.

, , , , , , , , , , , , , , , ,

Top 10 GDC Lists

March 1st, 2012 by Elliott Mitchell

GDC is approaching next week and I’ll be traveling to San Fransisco to participate in the epic game developer event. I’m psyched and here’s why:


10  The Expo Floor
9    The History Of 3D Games exhibit
8    Experimental Gameplay Sessions
7    The Unity Party
6    Indie Game: The Movie screening & Panel
5    GDC Play
4    14th Annual Independent Games Festival Awards
3    Networking, Networking & Networking
2    Independent Game Summit
1    Unity Technology Engineers


10  The Pursuit of Indie Happiness: Making Great Games without Going Crazy
9    Rapid, Iterative Prototyping Best Practices
8    Experimental Gameplay Sessions
7    Create New Genres (and Stop Wasting Your Life in the Clone Factories) [SOGS Design]
6    BURN THIS MOTHERFATHER! Game Dev Parents Rant
5    Bringing Large Scale Console Games to iOS Devices: A Technical Overview of The Bard’s Tale Adaptation
4    Light Probe Interpolation Using Tetrahedral Tessellations
3    Big Games in Small Packages: Lessons Learned In Bringing a Long-running PC MMO to Mobile
2    Art History for Game Devs: In Praise of Abstraction
1    Android Gaming on Tegra: The Future of Gaming is Now, and it’s on the Move! (Presented by NVIDIA)

If you’re going to be at GDC and want to talk shop with Infrared5 then please ping us! info (at) Infrared5 (dot) com

, , ,

Simplify and Expedite Front-end Web Development

February 24th, 2012 by Kyle Kellogg

Front-end web development projects can be difficult at times, but they don’t have to be. Every project is unique and each brings new and interesting challenges. These challenges are frequently presented by the very technologies we choose or must use on the aforementioned projects. Although using them is a great way to become more skilled, sometimes they can stand in the way of the project at hand. Mitigating these challenges through a process which can be repeated serves to not only improve the project and it’s schedule, but also your work.

Many, if not all, of the examples that follow are technologies or methodologies that members of Infrared5 have used before, but they’re in no way a comprehensive list of what is available or a recommendation as to what to use. Figuring out what works for you, your team, and the project is an important piece of this repeatable process.

The most important thing you can do is to plan ahead. That may seem obvious, but it can be easy to overlook doing it properly. Planning doesn’t have to be absolute and it doesn’t have to be too granular, but the more you plan for the more you can prepare for. Have you had things go wrong in the past? Make sure you account for similar situations in any new plans you create! You’ll never be able to perfectly account for everything, but you can account for most things.

Decide which technologies you’ll use. Remember, use the right (or best available) tool for the job. Think about what your browser, device, and screen size support will be like for the project. What javascript framework or toolkit, like jQuery or Dojo, will you use, if any? Will you be supporting HTML5 and CSS3? Will you be using any external libraries at all? All of these considerations will be important throughout the project and it is best to decide upon them early and stick with them in order to maximize your efficiency.

Start with something and build up from there. You can utilize HTML5 BoilerplateBootstrap, or whatever other starting point you feel comfortable with. You can use Initializr help set up an entire project, if that’s what makes you feel comfortable. Personally, I like to start with just the 1140 CSS Grid and jQuery.

Have your content and designs ready before you need them. Also make sure your designs are done based on whatever grid you’ll be using for your layout so that you don’t have to retrofit the design to the layout. Getting a running start on a project is all well and good, but breaking the up the development with blockades can make everything take longer than it has to.

You’ve got lots of technology at your disposal, so make it work for you. Your layout grid should serve as a flexible base upon which you can build without constraint. Lean on it’s support for your layout needs when you can, including responsive resizing. Use LESS or Scss/Sass to style faster and in a more organized way with less repetition. Break your javascript up into self-contained, self-cleaning, interconnected modules to help reduce the chances of memory leaks and unexpected errors. Document your javascript as you go so that everyone on the project can easily keep informed of what’s going on. Finally, use an IDE that helps you be more efficient. For me that’s Espresso, but for other developers at Infrared5 it’s Sublime Text 2.

I want to expand upon the modules I mentioned in the previous paragraph. These modules allow you to break functionality into smaller pieces, focus on them, and then combine as a whole to get the job done. Think of it as a loose implementation of feature-driven development. This allows your code to be more organized, more readable, kept in context, and focused on in a feature-by-feature way which, for me, helps development get done quicker.

Another piece of the development process I cannot stress enough is to use version control software and use it often. I prefer git, because Keith Peters turned us all on to this process which has helped reduce conflicts while working with a team. Use whatever you like though, because at the end of the day it’s all so that you don’t lose any work you’ve done.

Separate your development cycles so that your brain isn’t trying to do too many things at once. Do your development, then any and all enhancements, and then whatever bugs there are. This process may need to go through several iterations, becoming something like the spiral model.

Lastly, wrap it up by condensing and publishing a final product. Minify and concatenate your javascript and css, obfuscate if you must, in order to wring every last drop of speed you’re able to get out of the browser. Publish whatever documentation you’ve built up for client use, if applicable. Hand it off. See? Not so difficult after all.

Next Entries »