HTML and CSS Reference
In-Depth Information
Maintenance
The very first Flash games I wrote back in 1999 still work perfectly today. They have needed no updates, tinkering,
or recrafting in any way. The Flash Player took the responsibility of making its content work on each and every
browser. Every HTML5 game I have been involved with over the last few years has required a revisit to fix the audio,
the rendering, the button placement, and much more. The need for maintenance and QA is a fact of life now. The
proprietary “black box” nature of a browser plug-in was fantastic for backward compatibility. In the Wild West of
unstable, un-ratified standards, browser manufacturers will deliver interpretations that are anything but standard. It is
the nature of competition to deliver features better than your rivals'—“better” frequently meaning “non-standard.” For
my team, delivering games with complex logic and display rendering systems, we need to assign a large fraction of our
budget to a maintenance strand just to keep the games live. Typically, the QA budget rate is from 10 to 20 percent per
project, with maintenance being the same again.
So, is there a way to insulate games from changes of standard implementation? Frankly, there is no silver
bullet. The problems are coming from multiple areas: crossorigin resource sharing, browser behaviors, audio
implementation, memory allocation, page embedding methods—the list goes on. As HTML5 game portfolios
get bigger, so does the task of implementing a fix across the whole portfolio. If libraries are shared, then there are
possibilities.
We are in a space now in which the interesting JavaScript libraries are still in development, and many haven't
even reached release 1.0 yet. This means that backward compatibility can't be guaranteed. Over the next few years,
the ecosystem will settle down, and many of the problems will ease. Expectations need to be managed, and budgets,
apportioned to acknowledge the current state of play.
Conclusion
Remember, isn't the reason we are working with HTML5 so that we can get our games onto mobile devices? It is very
easy to get swept along by all the great advances being made on desktop browsers—the extra performance and Web
Graphics Library (WebGL) goodness. Those features and possibilities don't exist as yet in a standard and consistent
way across the mobile Web. This doesn't mean, however, that we shouldn't still be excited about the possibilities
of what can be achieved. With a mind toward optimization and creative thinking, within the technical constraints,
amazing experiences can be produced.
On the desktop, Flash games matured to set a very high standard. This level has been carried on in the app space
by some fantastic games. Publishers and clients now seemingly expect this quality from every game build, irrespective
of language, technology, or platform. These expectations need to be managed; delivering with quality to multiple
platforms is a complicated business.
Scooby Doo Funfair Freak Out was launched in early summer of 2013. It was the most successful game launch
ever for CBBC, a portfolio that has seen more than 400 games. Now, a game made with HTML5 and JavaScript has
reached the peak! This is undoubtedly due to hitting desktop, smartphone, and tablet at the same time and shows the
strength of and potential for multiplatform projects.
 
Search WWH ::




Custom Search