在本文，我們將介紹HTML5的能力和解釋關(guān)于JavaScript的常見誤解，提出一些解決HTML5可怕的音頻問題的方案，以及介紹開發(fā)HTML5游戲可能遇到的主要問題。

　　我敢說，讀者們應(yīng)該已經(jīng)知道，用單一的語言編寫游戲且不需要移植或甚至重新編譯就在多個平臺上發(fā)布，能擴(kuò)大游戲的普及范圍，增加玩家的自主權(quán)，這對商業(yè)是有好處的。

　　關(guān)于HTML5，網(wǎng)上流傳著諸多誤解。最重要的一個問題是，“HTML5迎來全盛時期了嗎?”

　　簡短的答案是：是的，你可以用HTML5寫出很好的游戲，這些游戲可以在多個瀏覽器、平臺和設(shè)備上運行且保持相同的品質(zhì)。

　　更長的答案是：詳見下文——HTML5仍然很年輕，它還有一些非�，F(xiàn)實的問題應(yīng)試避免。

　　HTML5-logo(from 36kr.com)

　　熱詞之外

　　所以當(dāng)我們談?wù)揌TML5時，我們其實是指Javascript(JS)與圖像和交互API相給合，用JS在瀏覽器顯示。與其他成熟的技術(shù)一樣，Javascript也有它自己的教條和誤解。

　　以下是常見的誤區(qū)：

　　“Javascript 太慢!”

　　這是真的，直到2005年以后瀏覽器制作者開發(fā)好好搞JS的優(yōu)化�，F(xiàn)在通常認(rèn)為，JS已經(jīng)是最富動態(tài)的語言——與靜態(tài)語言Java和C#相比，速度只有本地編譯的C的約一半。這是很了不起的。

　　“Javascript沒有類庫!”

　　我們經(jīng)常聽到這個報怨，但這不是真的;JS的原型遺產(chǎn)傳達(dá)了你想在游戲中出現(xiàn)的所有基本的OO特征(面向?qū)ο?：成員變量、成員功能、亞類、靜態(tài)成員、多態(tài)形、反射在、函數(shù)/構(gòu)造函數(shù)過載、類型識別。

　　“Javascript不安全，因為它不是編譯的!”

　　使用極簡化和混淆(如果反射不需要的話)，把你的代碼變成少空白的、少評論的廢話，就像本地代碼編譯一樣有效，對人記住，任何在客戶端上運行的東西，無論它是Javascript、Java還是C++，都是不安全的，含糊并不是安全。

　　“Javascript不是真正的編程語言!”

　　這太蠢了。從語言設(shè)計的角度出發(fā)，Javascript是相當(dāng)好的。它是Scheme Lisp語言加上C式句法和Smalltalk風(fēng)格原型的對象的簡化版本。

　　順便一提，Javascript的下一個版本——ES6會非常好的。

　　我們已經(jīng)認(rèn)識了關(guān)于Javascript的幾個常見誤解，現(xiàn)在可以談?wù)凥TML5了。HTML5只是添加到我們所知道和喜愛的現(xiàn)有的HTML上，作為游戲開發(fā)者，我們真的只關(guān)心幾個選項。以下是使用HTML5的好處和一些陷阱。

　　Canvas

　　這是我們都已經(jīng)聽說的與HTML5游戲有關(guān)的特征。Canvas在你的網(wǎng)頁頁面上創(chuàng)造一個2D繪制空間。你可以控制幀緩存大小(象素寬和高)，設(shè)置Canvas元素的屏幕大小;它會根據(jù)元素大小自動拉伸或收縮緩存。你甚至可以創(chuàng)造離屏幕的Canvas，然后復(fù)制一個Canvas到另一個，使效果和表現(xiàn)更加強大。

　　使用簡單的間隔計時順(或更好的，請求動畫幀 API)和Canvas，你就可以用更少的時間繪制東西。

　　“陷阱!”

　　除了飛快地加速位圖圖像，Canvas包含強大的API(基于PostScript)，用于幾何線和填充，和初步的文本渲染工具;然而，你要少量地使用這些，因為它們往往降低幀率。

　　另外，Canvas喜歡從少量的源圖像繪制，所以你要控制好繪制圖像調(diào)用次數(shù)(這可能是底層驅(qū)動/API的現(xiàn)實)。所以，壓縮這些小圖像(你會希望舊能減少http加載調(diào)用)和使用離屏幕Canvas來緩存嘲中不變的部分(游戲邦注：把那些6400次繪制貼圖變成一次繪制圖像命令)。

　　老實說，HTML5的音頻弱爆了。這個問題沒有辦法掩蓋了。在我進(jìn)一步探討這個問題以前，我先向你保證，HTML5是可以提供比較體面的聲音體驗的，但你將面臨以下幾個問題：

　　音頻格式問題：

　　某種瀏覽器只能播放某種音頻格式，這意味著你不得不至少配置兩種音頻格式(目前是.mp3和.ogg)。要怪就怪軟件專利吧。

　　糟糕的信息：

　　有一個API會詢問瀏覽器它可以播放什么音頻格式;可悲的是，這個API有一個非�？膳碌慕獯a器支持，所以它得到的回答是“也許”�？v觀那么多種瀏覽器，我們還發(fā)現(xiàn)這個API在支持什么和不支持什么上完全說謊了。

　∩怕的執(zhí)行：

　　有些瀏覽器，即使它們發(fā)誓它們可以播放某種格式;它們的解碼器/流媒體執(zhí)行法也是無效的。延遲嚴(yán)重、低劣的音頻質(zhì)量、不正確的計時。有些瀏覽器(或操作系統(tǒng))根本不能播放，卻說自己支持某種格式。

　　嚴(yán)重的延遲

　　如果你通過http加載一個聲音然后點擊播放，到聲音下載完的時候，對應(yīng)的事件已經(jīng)過去了。如果這是背景音樂，那就無所謂，但如果是動作游戲的聲音特效呢?那就不能接受了。

　　聽起來真是太糟了!

　　音頻是HTML5當(dāng)下的第一大問題;所幸有許多能人開動腦筋，再加上技術(shù)的進(jìn)步，HTML5的音頻至少能用了，雖然還算不上好。

　　音頻救星：Audio Sprites

　⊥像Atlas是針對圖像的2D封裝方案，為了減少http調(diào)用和域名費用的負(fù)擔(dān)，針對音頻的1D解決方案——Audio Sprites應(yīng)運而生。Remy Sharp在這方面做了一些基礎(chǔ)工作。他的基本思路是，你把你的聲音特效打包進(jìn)一個聲音文件中，每個聲音之間留半秒的無聲狀態(tài)，作為計時誤差。一個附帶的.json文件羅列了所有這些包含在Audio Sprites中的文件，以及它們的起止位置。

　　借助Audio Sprites，你只需要把一個文件轉(zhuǎn)換為ogg和mp3，且你只需要一個http請求就能加載它了。

　　延遲消失了!

　　有一個統(tǒng)一的大聲音文件的主要好處是，我們避免了小聲音文件的傳輸問題。瀏覽器可以預(yù)加載這個大聲音文件，然后當(dāng)被調(diào)用時就尋找各個聲音特效的開頭，這樣延遲就非常小了。我們的 問題是，在這個聲音結(jié)束而下一個聲音播放以前，我們必須監(jiān)控和中止傳輸。

　　“糟糕的格式檢測怎么辦?”

　　在一定程度上這仍然是一個問題;我們已經(jīng)發(fā)現(xiàn)，你可以使用MP3，大部分瀏覽器都支持MP3;但在編寫的時候，最好能在菜單中加入“MP3或OGG”的設(shè)置選項。另外，確保你沒寫錯;許多人在格式檢測方面偷懶。

　　“這聽起太難處理了!”

　　是的，是很讓人頭疼;要求我們花幾周的時間開發(fā)必須的工具和尋找技巧。

　　順便一提，希望還是有的。大部分網(wǎng)頁瀏覽器已經(jīng)支持新的Opus格式和/或新的基于OpenAL的WebAudio API。普及只是一個時間的問題。

　　WebGL

　　作為HTML5運動中的一個主要熱詞，WebGL承載了太多希望，即3D游戲能夠使用本地圖像API。然而我們的實驗表明，WebGL還沒有準(zhǔn)備好迎接黃金時代。在相同的機子上，可以運行用C++寫的OpenGL程序，但用WebGL寫的就運行不了，這個事實意味著仍然存在問題。該死的NVidia/ATI 驅(qū)動專利!與Canvas相比，WebGL還很難學(xué)習(xí)。到年底，WebGL應(yīng)該非常有希望成為2D和3D圖像中間件的可行選擇。

　　WWW負(fù)擔(dān)

　　瀏覽器支持許多文件格式化的特性(CSS、HTML、XML、SVG等)，而這些特性對Canvas和WebGL游戲太不實用了，可能最好避免。一款簡單的游戲只需要半頁的HTML作為裝載javascript的容器。不幸的是，如果出于某些原因你并不了解網(wǎng)頁設(shè)計，那么為了制作JS游戲，你就得學(xué)習(xí)基礎(chǔ)的HTML和CSS。無論如何，登錄頁面和UI對話框是必須知道的。

　　因為Canvas和WebGL的渲染是很糟糕的，你可能希望使用HTML作為游戲內(nèi)的文本(游戲邦注：如提示、角色對話等)。這個技巧是使用“pointer-events: none”(CSS)來避免通過鼠標(biāo)點擊出現(xiàn)文本。

　　使用CSS的“正解方法”可能是單調(diào)且沒有意義的。當(dāng)不確定時，就使用和濫用“position: absolute”!

　　XML是HTML的近親，有些人可能會認(rèn)為瀏覽器會有出色的XML工具。相反的是，我們發(fā)現(xiàn)它們不僅笨拙，有時候甚至漏洞百出，所以我們把舊的XML資產(chǎn)轉(zhuǎn)換成JSON。

　　另外，你可能需要安裝一個網(wǎng)頁服務(wù)器程序，比如Apache。打開你的硬盤中的HTML 文件，你也許能夠運行你的游戲，但有一些奇怪的案例限制會讓你很為難，特別是當(dāng)你的游戲是AJAX或WebGL的。

　　陷阱：網(wǎng)頁瀏覽器不是100%兼容的

　　眾所周知，“跨平臺”從來就不是無縫的。我們的建議是，至少支持最常用的3、4種瀏覽器，并經(jīng)常性地在這些瀏覽器上做測試。Chrome和Safari通常是最適合玩游戲的，且它們都使用WebKit，所以100%是互相兼容的。

　　Firefox也不錯——在某些方面甚至更好，但要注意避免滲出邊界特征如“l(fā)et [x,y] = point”。IE和Opera需要額外的努力，它們可能不太適合比較大的游戲，因為所有設(shè)備都會選擇比它們更好的瀏覽器。但另一方面，對于簡單的休閑游戲，支持IE還是比較簡單的，且可能是獲得商業(yè)成功的必須條件。

　　如果你在制作手機/平板游戲，請記�。菏謾C瀏覽器是不同的。

　　資源打包和加載

　　在其他平臺你可以在安裝包里解壓所有資源，HTML5卻不同，你要把子畫面和聲音特效、小的HTML文件嵌入JSON，嵌入GLSL著色器如果你使用的是WebGL的話，把JSON嵌入JS，然后合并和壓縮所有JS文件。我們使用Make、PHP和NodeJS scripts、ImageMagick、LAME和OggEnc自動化這個過程。

　　之后，當(dāng)你的游戲啟動時，預(yù)加載你的所有資源(可能除了音樂)。我們使用async.js來從AJAX中同時取得所有東西，然后開始游戲循環(huán)。

　　AppCache(AKA Offline Mode)是一種相當(dāng)簡單的加速預(yù)加載和重新加載的方法(甚至于對在線多人游戲)，如果你保持游戲簡單的話。記住，這個方法也可能出大錯，在你得意忘形以前，先讀讀《Application Cache is a Douchebag》這篇文章吧。

　　一開始，當(dāng)你在你自己的機子上運行游戲時，是不會發(fā)生這種問題的。提醒你一下，如果你完成了一款HTML5游戲，資源加載問題可能拖延你的發(fā)布日程。

　　總結(jié)

　　用一種能夠無縫兼容現(xiàn)有的網(wǎng)頁服務(wù)器的語言制作游戲，具有簡化免費和開放平臺的網(wǎng)頁開發(fā)的潛能，使HTML5成為開發(fā)和實用性方面非常誘人的選擇。

   投稿郵箱：chuanbeiol@163.com   詳情請訪問川北在線：http://dstuf.com/