以圓桌騎士爲例淺嘗HTML5遊戲開發

隨着XHTML的逐漸式微，Chrome，Safari，FireFox，Opera等現代瀏覽器正在積極完善HTML5實現，IE9也加入到標準的行列並將在今年上半年發佈正式版，HTML5時代來臨了。

在各類HTML5特性中，最吸引人的莫過於canvas標籤，其提供的繪圖API將顛覆以往web表現力匱乏的形象。隨着瀏覽器對canvas的廣泛支持，利用canvas實現的web應用會出現爆發性的增加。

 

本人嘗試了使用canvas開發2d卷軸遊戲，與你們分享。

本文將不介紹canvas2d API的用法，若是想了解canvas2d API請訪問：https://developer.mozilla.org/cn/Canvas_tutorial

可行×××

嘗試製做的遊戲是Knights of the Round 圓桌騎士。

圓桌騎士（knights of the round）是由CAPCOM公司於1991年推出的一款動做遊戲，對應遊戲平臺爲街機，遊戲基板爲CPS1。遊戲操控性上，圓桌騎士也更爲注重一招一式地砍殺感受，那種刀碰鎧甲的感受至關曼妙。

如今的問題是，實現一個模擬器仍是手工復刻。

用JS製做CPS1模擬器，涉及到ROM解碼，68000彙編等技術，此非能力所及故不可行。有能力的大牛不妨試試，如今已經有JS實現的NES模擬器了。最後選擇了純手工復刻。

下一個問題是幀率，60FPS仍是30FPS？顯而易見，60比30更有表現力，視覺感覺更流暢。

CPS1的幀頻是60FPS，要提升仿真度，幀頻必須達到60。帶來的問題是對性能的苛刻要求。

工欲善其事必先利其器

動做遊戲的核心在於各類精靈的動做。

須要一種工具，可以方便的建立，編輯，精靈所須要的幀與動做。

在寫遊戲以前，必須完成基礎設施建設。爲此開發了SpriteEditor工具，純JS開發，利用dataURIscheme與圖片另存爲功能保存json格式的精靈配置文件。

 

精靈編輯器

使用編輯器的好處是能以可視化的方式管理精靈幀，動做與斷定區。另外一種解決方案是使用規則的圖片，在程序中生成維護幀和動做。這種方式與資源圖片耦合較高，不方便維護。擴展性也有限，例如某幾個動做須要同一幀，只好在連續圖片中重複，產生沒必要要的冗餘幀。利用編輯器能夠方便解耦程序和圖像資源，編輯器負責分析圖片併產生配置文件，遊戲程序負責解讀配置文件並還原，利於團隊協做。

遊戲系統結構

 

典型遊戲軟件系統結構圖

典型遊戲軟件系統結構相似MVC。遊戲狀態至關於Model，渲染器至關於View，控制器就是Controller了。仿真器介於Model和Controller之間，理解起來比較簡單。

canvas效率與兼容性

canvas渲染效率很不錯，在Chrome裏分辨率384*224能夠輕鬆跑到200幀/每秒以上。不過拉伸後效率降低較嚴重。IE9得益於強大的硬件加速，即便放大10倍，幀率也不低於60。相比之下其餘瀏覽器慘不忍睹，幀數不到兩位數。Chrome開發版開啓硬件加速反而變慢了。

比較杯具的是canvas仍存在兼容問題：

IE9 beta目前還不支持globalCompositeOperation
其餘瀏覽器的globalCompositeOperation 效果也不是徹底一致。
Opera的save和restore與其餘瀏覽器不一致。

IE9 canvas若是使用了drawImage再調用toDataURL會致使瀏覽器崩潰等等。

 

globalCompositeOperation兼容狀況 ，IE9beta不支持。（其中截圖來自網絡）

遊戲優化

考慮使用多個canvas分層渲染，避免屢次渲染相同部分，但分層的粒度要把握好，若是canvas過多在dom上的開銷可能超過收益。

考慮使用髒矩形技術，只更新產生變化的區域。注意在不一樣瀏覽器中收益不一樣，甚至會產生負收益。

使用setInterval代替setTimeout效果較好。

避免給每一個精靈設置定時器，太多會形成隊列阻塞。嘗試在一個定時器中處理多個精靈動畫。

避免給多個對象綁定事件監聽，使用統一的事件代理。

總結與展望

雖然目前HTML5還存在很多問題，但仍值得期待：

1. 缺乏成熟的開發框架和環境。
2. 仍然存在較大的兼容性問題。
3. 商業化難題，JS程序易被篡改，只能做爲渲染終端。

這是一次使用新技術的探索與實踐，但願能以此拋磚引玉，創造出更有價值的應用。

 

【本文首發於： 搜索研發部官方博客】 http://stblog.baidu-tech.com/?p=430

【 關注百度技術沙龍】