以圓桌騎士爲例淺嘗HTML5遊戲開發
隨着XHTML的逐漸式微，Chrome，Safari，FireFox，Opera等現代瀏覽器正在積極完善HTML5實現，IE9也加入到標準的行列並將在今年上半年發佈正式版，HTML5時代來臨了。web
在各類HTML5特性中，最吸引人的莫過於canvas標籤，其提供的繪圖API將顛覆以往web表現力匱乏的形象。隨着瀏覽器對canvas的廣泛支持，利用canvas實現的web應用會出現爆發性的增加。json
本人嘗試了使用canvas開發2d卷軸遊戲，與你們分享。canvas
本文將不介紹canvas2d API的用法，若是想了解canvas2d API請訪問：https://developer.mozilla.org/cn/Canvas_tutorial瀏覽器
可行×××網絡
嘗試製做的遊戲是Knights of the Round 圓桌騎士。框架
圓桌騎士（knights of the round）是由CAPCOM公司於1991年推出的一款動做遊戲，對應遊戲平臺爲街機，遊戲基板爲CPS1。遊戲操控性上，圓桌騎士也更爲注重一招一式地砍殺感受，那種刀碰鎧甲的感受至關曼妙。dom
如今的問題是，實現一個模擬器仍是手工復刻。編輯器
用JS製做CPS1模擬器，涉及到ROM解碼，68000彙編等技術，此非能力所及故不可行。有能力的大牛不妨試試，如今已經有JS實現的NES模擬器了。最後選擇了純手工復刻。ide
下一個問題是幀率，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還存在很多問題，但仍值得期待：
- 缺乏成熟的開發框架和環境。
- 仍然存在較大的兼容性問題。
- 商業化難題，JS程序易被篡改，只能做爲渲染終端。
這是一次使用新技術的探索與實踐，但願能以此拋磚引玉，創造出更有價值的應用。