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

技術小美發表於2017-11-14

隨著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程式易被篡改,只能作為渲染終端。

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

 

本文轉自百度技術51CTO部落格,原文連結:http://blog.51cto.com/baidutech/743749,如需轉載請自行聯絡原作者


相關文章