作者：Raymond Jacobs & Tom Novelli

在本文，我们将介绍HTML5的能力和解释关于JavaScript的常见误解，提出一些解决HTML5可怕的音频问题的方案，以及介绍开发HTML5游戏可能遇到的主要问题。

我敢说，读者们应该已经知道，用单一的语言编写游戏且不需要移植或甚至重新编译就在多个平台上发布，能扩大游戏的普及范围，增加玩家的自主权，这对商业是有好处的。

关于HTML5，网上流传着诸多误解。最重要的一个问题是，“HTML5迎来全盛时期了吗？”

简短的答案是：是的，你可以用HTML5写出很好的游戏，这些游戏可以在多个浏览器、平台和设备上运行且保持相同的品质。

更长的答案是：详见下文——HTML5仍然很年轻，它还有一些非常现实的问题应试避免。

热词之外

所以当我们谈论HTML5时，我们其实是指Javascript（JS）与图像和交互API相给合，用JS在浏览器显示。与其他成熟的技术一样，Javascript也有它自己的教条和误解。

以下是常见的误区：

“Javascript 太慢！”

这是真的，直到2005年以后浏览器制作者开发好好搞JS的优化。现在通常认为，JS已经是最富动态的语言——与静态语言Java和C#相比，速度只有本地编译的C的约一半。这是很了不起的。

“Javascript没有类库！”

我们经常听到这个报怨，但这不是真的；JS的原型遗产传达了你想在游戏中出现的所有基本的OO特征（面向对象）：成员变量、成员功能、亚类、静态成员、多态形、反射在、函数/构造函数过载、类型识别。

“Javascript不安全，因为它不是编译的！”

使用极简化和混淆（如果反射不需要的话），把你的代码变成少空白的、少评论的废话，就像本地代码编译一样有效，对人记住，任何在客户端上运行的东西，无论它是Javascript、Java还是C++，都是不安全的，含糊并不是安全。

“Javascript不是真正的编程语言！”

这太蠢了。从语言设计的角度出发，Javascript是相当好的。它是Scheme Lisp语言加上C式句法和Smalltalk风格原型的对象的简化版本。

顺便一提，Javascript的下一个版本——ES6会非常好的。

我们已经认识了关于Javascript的几个常见误解，现在可以谈谈HTML5了。HTML5只是添加到我们所知道和喜爱的现有的HTML上，作为游戏开发者，我们真的只关心几个选项。以下是使用HTML5的好处和一些陷阱。

Canvas

这是我们都已经听说的与HTML5游戏有关的特征。Canvas在你的网页页面上创造一个2D绘制空间。你可以控制帧缓存大小（象素宽和高），设置Canvas元素的屏幕大小；它会根据元素大小自动拉伸或收缩缓存。你甚至可以创造离屏幕的Canvas，然后复制一个Canvas到另一个，使效果和表现更加强大。

使用简单的间隔计时顺（或更好的，请求动画帧 API）和Canvas，你就可以用更少的时间绘制东西。

“陷阱！”

除了飞快地加速位图图像，Canvas包含强大的API（基于PostScript)，用于几何线和填充，和初步的文本渲染工具；然而，你要少量地使用这些，因为它们往往降低帧率。

另外，Canvas喜欢从少量的源图像绘制，所以你要控制好绘制图像调用次数（这可能是底层驱动/API的现实）。所以，压缩这些小图像（你会希望尽可能减少http加载调用）和使用离屏幕Canvas来缓存场景中不变的部分（游戏邦注：把那些6400次绘制贴图变成一次绘制图像命令）。

老实说，HTML5的音频弱爆了。这个问题没有办法掩盖了。在我进一步探讨这个问题以前，我先向你保证，HTML5是可以提供比较体面的声音体验的，但你将面临以下几个问题：

音频格式问题：

某种浏览器只能播放某种音频格式，这意味着你不得不至少配置两种音频格式（目前是.mp3和.ogg）。要怪就怪软件专利吧。

糟糕的信息：

有一个API会询问浏览器它可以播放什么音频格式；可悲的是，这个API有一个非常可怕的解码器支持，所以它得到的回答是“也许”。纵观那么多种浏览器，我们还发现这个API在支持什么和不支持什么上完全说谎了。

可怕的执行：

有些浏览器，即使它们发誓它们可以播放某种格式；它们的解码器/流媒体执行法也是无效的。延迟严重、低劣的音频质量、不正确的计时。有些浏览器（或操作系统）根本不能播放，却说自己支持某种格式。

严重的延迟

如果你通过http加载一个声音然后点击播放，到声音下载完的时候，对应的事件已经过去了。如果这是背景音乐，那就无所谓，但如果是动作游戏的声音特效呢？那就不能接受了。

听起来真是太糟了！

音频是HTML5当下的第一大问题；所幸有许多能人开动脑筋，再加上技术的进步，HTML5的音频至少能用了，虽然还算不上好。

音频救星：Audio Sprites

就像Atlas是针对图像的2D封装方案，为了减少http调用和域名费用的负担，针对音频的1D解决方案——Audio Sprites应运而生。Remy Sharp在这方面做了一些基础工作。他的基本思路是，你把你的声音特效打包进一个声音文件中，每个声音之间留半秒的无声状态，作为计时误差。一个附带的.json文件罗列了所有这些包含在Audio Sprites中的文件，以及它们的起止位置。

借助Audio Sprites，你只需要把一个文件转换为ogg和mp3，且你只需要一个http请求就能加载它了。

延迟消失了！

有一个统一的大声音文件的主要好处是，我们避免了小声音文件的传输问题。浏览器可以预加载这个大声音文件，然后当被调用时就寻找各个声音特效的开头，这样延迟就非常小了。我们的唯一问题是，在这个声音结束而下一个声音播放以前，我们必须监控和中止传输。

“糟糕的格式检测怎么办？”

在一定程度上这仍然是一个问题；我们已经发现，你可以使用MP3，大部分浏览器都支持MP3；但在编写的时候，最好能在菜单中加入“MP3或OGG”的设置选项。另外，确保你没写错；许多人在格式检测方面偷懒。

“这听起太难处理了！”

是的，是很让人头疼；要求我们花几周的时间开发必须的工具和寻找技巧。

顺便一提，希望还是有的。大部分网页浏览器已经支持新的Opus格式和/或新的基于OpenAL的WebAudio API。普及只是一个时间的问题。

WebGL

作为HTML5运动中的一个主要热词，WebGL承载了太多希望，即3D游戏能够使用本地图像API。然而我们的实验表明，WebGL还没有准备好迎接黄金时代。在相同的机子上，可以运行用C++写的OpenGL程序，但用WebGL写的就运行不了，这个事实意味着仍然存在问题。该死的NVidia/ATI 驱动专利！与Canvas相比，WebGL还很难学习。到年底，WebGL应该非常有希望成为2D和3D图像中间件的可行选择。

WWW负担

浏览器支持许多文件格式化的特性（CSS、HTML、XML、SVG等），而这些特性对Canvas和WebGL游戏太不实用了，可能最好避免。一款简单的游戏只需要半页的HTML作为装载javascript的容器。不幸的是，如果出于某些原因你并不了解网页设计，那么为了制作JS游戏，你就得学习基础的HTML和CSS。无论如何，登录页面和UI对话框是必须知道的。

因为Canvas和WebGL的渲染是很糟糕的，你可能希望使用HTML作为游戏内的文本（游戏邦注：如提示、角色对话等）。这个技巧是使用“pointer-events: none”（CSS）来避免通过鼠标点击出现文本。

使用CSS的“正解方法”可能是单调且没有意义的。当不确定时，就使用和滥用“position: absolute”！

XML是HTML的近亲，有些人可能会认为浏览器会有出色的XML工具。相反的是，我们发现它们不仅笨拙，有时候甚至漏洞百出，所以我们把旧的XML资产转换成JSON。

另外，你可能需要安装一个网页服务器程序，比如Apache。打开你的硬盘中的HTML 文件，你也许能够运行你的游戏，但有一些奇怪的案例限制会让你很为难，特别是当你的游戏是AJAX或WebGL的。

陷阱：网页浏览器不是100%兼容的

众所周知，“跨平台”从来就不是无缝的。我们的建议是，至少支持最常用的3、4种浏览器，并经常性地在这些浏览器上做测试。Chrome和Safari通常是最适合玩游戏的，且它们都使用WebKit，所以100%是互相兼容的。

Firefox也不错——在某些方面甚至更好，但要注意避免渗出边界特征如“let [x,y] = point”。IE和Opera需要额外的努力，它们可能不太适合比较大的游戏，因为所有设备都会选择比它们更好的浏览器。但另一方面，对于简单的休闲游戏，支持IE还是比较简单的，且可能是获得商业成功的必须条件。

如果你在制作手机/平板游戏，请记住：手机浏览器是不同的。

资源打包和加载

在其他平台你可以在安装包里解压所有资源，HTML5却不同，你要把子画面和声音特效、小的HTML文件嵌入JSON，嵌入GLSL着色器如果你使用的是WebGL的话，把JSON嵌入JS，然后合并和压缩所有JS文件。我们使用Make、PHP和NodeJS scripts、ImageMagick、LAME和OggEnc自动化这个过程。

之后，当你的游戏启动时，预加载你的所有资源（可能除了音乐）。我们使用async.js来从AJAX中同时取得所有东西，然后开始游戏循环。

AppCache（AKA Offline Mode）是一种相当简单的加速预加载和重新加载的方法（甚至于对在线多人游戏），如果你保持游戏简单的话。记住，这个方法也可能出大错，在你得意忘形以前，先读读《Application Cache is a Douchebag》这篇文章吧。

一开始，当你在你自己的机子上运行游戏时，是不会发生这种问题的。提醒你一下，如果你完成了一款HTML5游戏，资源加载问题可能拖延你的发布日程。

总结

用一种能够无缝兼容现有的网页服务器的语言制作游戏，具有简化免费和开放平台的网页开发的潜能，使HTML5成为开发和实用性方面非常诱人的选择。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Is HTML5 Ready for Prime Time?

by Raymond Jacobs & Tom Novelli

I will make the assumption that you, the reader, have already come to the conclusion that writing a game in a single language and releasing it on multiple platforms without porting or even recompiling is a benefit to your business, through greater visibility and empowering the player.

There has been a lot of misinformation floating around the web concerning HTML5. The most important question is, “Is HTML5 ready for prime time?”

The short answer is yes, you can write polished games in HTML5 and have them run across a myriad of browsers, platforms and devices with consistent results.

The longer answer – the subject of this article – is that HTML5 is still young, and there are real-world pitfalls which should be avoided whenever possible.

Beyond the Buzzword

So when we’re talking about HTML5, what we really mean is Javascript (JS) coupled with graphics and interactive APIs exposed to JS by the browser. Like any mature technology, Javascript comes with its own set of dogma and misinformation.

Here is a short list of common misconceptions:

“Javascript is slow!”

This was true until the browser makers started pouring R&D into JS optimization, circa 2005. Nowadays, according to this list, it’s generally the fastest dynamic language – on par with static languages Java and C#, and only about half the speed of native-compiled C. That’s not bad – it’s awesome.

“Javascript doesn’t have classes!”

We hear this one a lot, and it just isn’t true; the prototypal inhertiance in JS delivers all the basic OO features you’d want in a game: member variables; member functions; sub-classing; static members; polymorphism; reflection; function/constructor overloading; type identification (instanceof).

Check out the object-oriented section of Tom Novelli’s JS reference for more information.

“Javascript isn’t secure because it isn’t compiled!”

The use of minification and obfuscation (if reflection isn’t needed), turning your code into a whitespaceless, commentless heap of nonsense to the human eye is as effective as native code compilation. Remember, anything run on the client, be it Javascript, Java or C++ is not secure, and obscurity is not security.

“Javascript isn’t a real programming language!”

This is just silly; look at http://en.wikipedia.org/wiki/ECMAScript. From a language design perspective, Javascript is pretty nice. It’s a pared-down version of Scheme Lisp with a C-like syntax and Smalltalk-style prototypal objects.

By the way, the next version of Javascript – ES6 – is going to be sweet.

Now that we’ve addressed some dogma concerning Javascript, let’s talk about HTML5. HTML5 simply adds to the existing HTML specification we all know and love, and as game developers we only really care about a few choice bits. So here are some exciting things you can use today with HTML5, and some pitfalls.

Canvas

It’s the feature we’ve all heard about concerning games in HTML5. The Canvas creates a 2D drawing space on your web page. You can control the frame buffer size (pixel width and height) and set the screen size of the canvas element; it will automatically stretch or shrink the buffer to the element size. You can even create off-screen canvases and copy one canvas to another, giving the potential for powerful effects and/or performance enhancements.

With a simple setInterval timer (or better yet, the requestAnimationFrame API) and a canvas, you’re ready to start drawing things in less time it would take to install a typical IDE.

“Pitfalls!”

Besides blitting bitmap images at lightning speed, canvas includes a robust API (based on PostScript) for geometric lines and fills, and rudimentary text rendering facilities; use these sparingly however, as they tend to sap frame-rate.

Also, canvas likes to draw from a small number of source images and would prefer that you keep your drawImage calls down (this is probably a reality of underlying drivers/API which are 3D in nature). So, atlas those tiny images (you’ll want to anyway to reduce http load calls), and use offscreen canvases to cache unchanging parts of the scene (turn those 6400 drawn tiles into a single drawImage call).

Audio

So I’m gonna come right out and say it, audio in HTML5 sucks. There is no reason to dance around the issue. Before I go any further, let me assure you, you can get a decent audio experience in HTML5, but here are some issues you’ll face:

Audio format issues:

Certain browsers can only play certain audio formats, this means you will have to deploy at least two audio formats (currently .mp3 and .ogg). Blame software patents.

Bad Information:

There is an API to ask a browser what kind of audio formats it can play; sadly this API is horrible with such decoder support responses as “maybe”. Across the myriad of browsers, we’ve also found the API to outright lie about what it can and can’t support.

Cruddy Implementations:

Some browsers, even though they swear they can play a format; their decoder/stream implementations are just broken. High start latencies, bad audio quality, incorrect timing. Some browsers (or operating systems) seem to implement the bare minimum just so they can say they support a format.

High start latency:

If you load a sound file via http and hit play, by the time the sound has downloaded the moment has passed. This is okay for background music, but it’s unacceptable for sound effects action games.

This all sounds really hard!

Audio is the #1 problem with HTML5 today; thankfully a lot of smart people have come together, and technology is emerging that makes HTML5 audio at least functional, if not feature-rich.

Audio Sprites to the rescue!

Just as the Atlas is a 2D packing solution for images, to reduce loads of http calls and nominal overhead; the Audio Sprite is a 1D solution for sounds. We took our lead from the ground work done by Remy Sharp. The basic idea is that you pack your sound effects into a single audio file, with a half-second of padding (silence) between each sound to allow for timing irregularities. An accompanying .json file lists all of the files contained in the audio sprite, and their start and end positions.

With audio sprites, you only need to convert one file to ogg and mp3, and you only need one http request to download it.

Latency b-gone!

The main benefit of having one large sound file is that we avoid streaming issues with small audio files. The browser preloads the single audio file, then seeks to the beginning of each sound effect when called for, with minimal latency. Our only issue is that we need to monitor and stop the stream after the sound ends but before the next one begins.
“What about bad format detection?”

This is still somewhat of an issue; we’ve found that you can favor MP3 and get coverage on most browsers; but at the time of writing it would not be a bad idea to include an MP3-or-OGG setting in your options menu. Also, make sure you’re doing it right; a lot of people cut corners in format detection.

“This all sounds like a bit much to handle!”

Yeah it’s a pain; it took us weeks to develop the necessary tools and tricks. If you’ve got a project in the works and need some help, drop us a line at this e-mail.

By the way, there is hope. Most web browsers already support the new Opus format and/or the spiffy new OpenAL-based WebAudio API. It’s probably just a matter of time before they all do.

WebGL

One of the principle buzzwords in the HTML5 movement, WebGL holds great promise, the ability to use the native graphics API for 3D games. Our experimentation however, has shown webGL is /not/ ready for prime-time today. The fact that I can run an OpenGL example program written in C++, and on the same machine fail to run the same example written in WebGL, means there are still issues. Damn those proprietary NVidia/ATI drivers! WebGL also has a steep learning curve, compared to Canvas. That all being said, if these issues can be overcome, WebGL should be a very viable option for 2D and 3D graphics middleware – hopefully by year’s end.

Annoyance: WWW Baggage

Browsers support a ton of document-formatting features (CSS, HTML, XML, SVG, etc) that aren’t terribly useful for Canvas and WebGL games, and are probably best avoided as much as possible. A simple game requires only a half-page of HTML as a container to load the Javascript. Unfortunately if for some reason you know nothing about web design, you’ll have to learn basic HTML and CSS in order to create JS games. It’s necessary for landing pages and UI dialogs anyway.

Because text rendering is awkward in Canvas and WebGL, you’ll probably want to use HTML for in-game text (notifications, character dialogues, etc). The trick is to use “pointer-events: none” (CSS) to prevent the text from blocking mouse clicks.

Using CSS “the right way” can be tedious and pointless. When in doubt, use and abuse “position: absolute” with reckless abandon!

XML being a close cousin of HTML, one would think browsers would have excellent XML facilities. To the contrary, we have found them to be awkward and sometimes buggy, so we converted our old XML assets to JSON.

Also, you’ll probably need to install a web server program such as Apache. You may be able to run your game by opening the HTML file on your hard drive (as a “file://” URL), but there are some arcane security restrictions that’ll stump you, especially if you get into AJAX or WebGL.

Pitfall: Web Browsers are not 100% Compatible

There’s always a catch; “cross-platform” is never seamless. Our advice is to support the top 3 or 4 browsers, and test your game on all of them regularly. Chrome and Safari are generally the best for games, and they both use the WebKit engine so they’re nearly 100% compatible. Firefox is also good – better in certain respects – but be careful to avoid bleeding-edge features like “let [x,y] = point”. IE and Opera require extra effort which may not be worthwhile for /serious/ games because better browsers are available for all devices. For simple casual games, on the other hand, supporting IE is easier and probably essential for commercial success.

If you’re making phone/tablet games, beware: mobile browsers are different beasts.

Resource Packing and Loading

Unlike other platforms where you can zip everything up in an installer package, HTML5 requires a bit more effort. Atlas your sprites and sound effects, embed small HTML files in JSON, embed GLSL shaders if you’re using WebGL, embed JSON files in JS, then combine and minify all your JS files. We automate the process using Make, PHP and NodeJS scripts, ImageMagick, LAME, and OggEnc.

Then, when your game starts up, pre-load all your resources (except perhaps music). We use async.js to ajax-fetch everything in parallel, then start the game loop.

AppCache (AKA Offline Mode) is a fairly easy way speed up pre- and re-loading (even for an online multiplayer game) if you keep it simple. Beware, it can go horribly wrong; read the highly entertaining Application Cache is a Douchebag article before you get too excited.

In the beginning, when you’re running your game from your own machine, none of this matters. Do whatever works. Just be forewarned, if you finish an HTML5 game, resource loading issues could delay your release by a few days or weeks.

Summary

The potential of making games in a single language that can seamlessly blend with existing web services, have all the trappings and simplicity of web development in free and open platform makes HTML5 very attractive from both development and availability angles.(source:gamedesignaspect part 1 part 2 part 3)