前言
mota-js是一款用於做出魔塔類型遊戲的HTML5 2d遊戲引擎(github項目地址)，目前最新的版本是v2.66，由於原主力開發已經工作，因此很長一段時間沒有大版本的更新。
最近在用樣板做一個遊戲的時候，體會到了樣板的一些限制。主要有：1. 地圖尺寸受限，超過一定尺寸(30x30)會到達性能瓶頸，尤其是在手機上會很卡頓。2. 素材尺寸受限。貼圖種類被限制在32x32或32x48，尺寸更大做起來會很麻煩，沒有一個精靈系統。3. 實現一些特效很困難。樣板中大量使用了dom來分割地圖場景與狀態欄UI，一些聯動特效難以實現，並且使用dom對做遊戲開發而非前端開發的人來說是個噩夢。
去年針對這些問題改了一版pre3.0的運行時系統，但現在回看感覺問題很多，首先是設計模式選取不當，造成理解困難，其次對原樣板的耦合太多，被原有框架所限制，導致渲染引擎的能力沒有發揮出來。因此這兩天決定重啓項目，解決之前的問題。
運行時系統簡介
這裏主要施工的部分是運行時，編輯器有另外一位大佬在施工。遊戲引擎的運行時系統，如果是複雜的遊戲，其系統規模將會是龐大的，如圖是《遊戲引擎架構》一書中對現代遊戲引擎的系統架構描述。
這樣的架構在unity、ue4等引擎中有完整的體現，但在我要施工的對象上不可能有這麼多。
HTML5遊戲是運行在瀏覽器上的，因此瀏覽器解決了A1-A3、B、C以及部分D的問題。其次因爲是2d遊戲，許多核心繫統中的東西用不到。然後因爲魔塔是棋盤類單機遊戲，位置是確定的方格，因此也不需要碰撞檢測、骨骼動畫、在線多人等模塊。最後，因爲是在原樣板基礎上進行的二次開發，很多遊戲算法都已經實現過了。因此算下來，藉助成熟的第三方庫，工作量並不大，對預期的架構圖修剪如下，預期工期在15天左右。
施工日誌
4-19
調研第三方庫：
- 渲染引擎PIXI
- 動畫庫tweenjs
4-20
實現資產管理(AssetsManager)。
資產管理中存在的坑：
- PIXI的材質對象在載入圖片時，如果圖片超出一定尺寸（網上說是1024）會導致圖片渲染失敗，這是webgl存在的問題，無法解決。因此在導入材質之前，需要將原始圖集進行手動裁剪，切分成一個個img元素。
4-21
實現動畫管理(AnimationManager)、精靈管理(SpriteManager)的部分功能。
4-22
實現一個地圖的原型：瓦片地圖繪製與角色移動。
對系統框架的進一步總結：
4-23
- 實現一個UI的原型：對話框的繪製與控制消失
– 對話框基於窗口基類(WinBase)，這是UI的基本單元，包含基本的座標、長寬屬性，並且可以有皮膚(WinSkin)，具有聚合組件的功能。
– 組件(Components)是使能窗口的重要部分，可以接收消息控制窗口屬性，如，在對話框窗體註冊一個“點擊響應”(tapScreen)組件，其功能爲關閉當前窗口。
– 對話框文字格式控制。控制字符，比如"\r \n"之類的，對文字內容進行格式控制，重寫了原樣板的實現，可以通過註冊實現任意格式控制，如字體變化、透明度變化等等。 - 實現尋路與路線繪製
– 尋路使用bfs，複用原樣板的函數。路線繪製重寫，功能性與原樣板一致。
– 對控制器(Controller)概念思考：一個控制器，響應用戶操作，控制一個對象，對象可以是角色、UI，也可以沒有特定對象，表示實現某種操作(比如響應點擊操作)。當有特定對象時，被控制的對象是完全“受控”於控制器的。舉個例子：勇士在被控制移動時，使用了尋路功能，那麼此時，尋路走動的過程中，會不斷調用的move，而這個move，是勇士自身的方法，還是控制器的方法？如果注意了控制器的概念，那麼這裏就應該是調用控制器的方法，這樣做的好處是，把操作與對象的行爲分離了，便於後續實現錄像系統——操作全部由控制系統管理，對象無需關心操作。
記錄一個坑：
ES6中的箭頭函數()=>{} 與 function有一個重要區別，那就是箭頭函數中的this綁定的是函數體外的，也就是說在聲明的時候就綁定了this，而不是像function一樣在調用的時候才綁定。
這兩部分需要後續補充的內容：
- 窗口的更多功能，包括不同位置顯示，自適應大小，需要後續補充。
- 需要後續補充更多組件
- 尋路移動的路線目前沒有UI顯示，後續UI完善了在這裏加上。