Web前端能夠轉行作遊戲嗎？

做者：ManfredHu
連接：http://www.manfredhu.com/2018/03/15/31-laya-game-tips/index.html
聲明：版權全部，轉載請保留本段信息，謝謝你們

LayaBox

Web前端最近都在跨界！！如今又伸手到遊戲領域了。可是真的那麼好跨界嗎？請讓我一一道來。

Canvas和WebGL的出現其實讓Web遊戲有了實現的可能，可是讓咱們用ctx一個個畫，效率仍是低了點，因此須要遊戲引擎。它幫助咱們去動態渲染遊戲每一幀的元素。

業界比較著名的幾個H5遊戲引擎，有Egret(白鷺)，Layabox，Three.js，coco2d-js等等，詳情能夠看知乎的回答。
由於咱們團隊不是一開始作遊戲的，咱們是傳統意義上的前端團隊，從web發家的，起初作的是電商類的業務——拍拍。因此這裏咱們綜合幾家遊戲引擎，選擇了Layabox。
有以下有點吧：

1. LayaAir是一個優秀的適用於多端的遊戲引擎，配備有豐富的組件，有本身的IDE能夠快速構建佈局等，不須要寫相似CSS的代碼
2. 支持html的頁面渲染，就是說你可讓遊戲引擎跟web頁面，混用（這在一些相似文本的頁面很是有用）
3. 支持2D、3D甚至VR方面的開發。性能也足夠優秀
4. 對Web前端廣泛的上手難度也較其餘引擎框架簡單不少
5. 不須要寫重構（CSS）代碼

其實咱們團隊以前也是作得H5競猜小遊戲，不過是基於DOM的，用CSS3作動畫。可是發現CSS3操做複雜動畫，有不少缺點：

1. 複雜動畫支持度很是差
2. 頁面元素太多，渲染性能差
3. 不少複雜的需求作起來很耗時
4. 玩家手機容易發燙（頁面元素多，動畫複雜）

所以，咱們通過預研和討論，果斷走出傳統Web的開發模式，擁抱傳統的遊戲開發！！固然這裏確定不是一路順風的，從Web前端轉向遊戲開發，仍是有很是多的坑點的。

首先須要擺脫HTML和CSS，你不是在作頁面，你是在作一個遊戲！！遊戲的邏輯佔據了一個遊戲80%的工做量，因此你不少時候是在寫JavaScript代碼，這不是問題，其次，你須要擁有面向對象編程的思想。這多是不少老前端欠缺的，由於JavaScirpt說究竟是一門面向函數、面向過程的語言。你們知道模塊化，可是卻仍是習慣寫function而不是ES6的class。

這裏由於平臺也在轉型向ES6靠近，因此大膽採用了ES6+Babel+Webpack的模式，甚至於在作Weex、小程序、Web三端融合。即一份代碼，能夠在三個平臺跑。扯的有點遠哈，下面開始正文，咱們不說用法，具體是說一些坑點，和優缺點對比。

遊戲引擎不適用的地方

遊戲引擎這東西在動畫一塊是真心好用，能夠高度還原設計師的動畫，但是其沒有網頁的排版佈局，更多的佈局應該是經過x、y、更改pivot、anchor屬性來實現。
CSS能夠很快速的經過代碼進行相關佈局（flex、float、position等屬性），網頁那種自上而下的內容排版能夠自動適應內容，對文字處理十分便捷。

針對各自的優缺點，從實現的便捷性來講，遊戲主場景（動畫極多）的狀況下，爲了提升用戶的體驗，應該用遊戲引擎來寫。
而對一些活動浮層、投注記錄、遊戲規則等有大量圖片文本的頁面，應該用傳統的Web網頁來編寫，這樣纔是物盡其用的作法。

在這個背景下，遊戲開發的前端須要掌握多好幾種技能——簡單的遊戲開發的技能、重構部分的構建技能（團隊大前端的趨勢下，去除重構崗位，重構工做由前端接管），能夠說工做量翻了一倍。可是在業務側來考慮，由於減小了相關的中間環節，需求迭代能夠更快速的落地。

Laya的IDE使用要注意的地方

LayaIDE提供一個組件庫，如list列表，tab按鈕切換等等簡單的Web組件，能夠直接拖拽使用而不用本身用代碼再實現一次。
可是IDE自帶的不少組件有坑點，如list組件的selectHandler觸發並不靈敏，數據源從新綁定後會出現點擊沒法響應的問題，這個時候要綁定mouseHanlder來代替點擊事件等。
IDE的使用對於不熟悉的人來講上手並不簡單，熟練後能夠提升效率。具體能夠看官網的介紹。

sceneColor並不起做用

這個屬性是IDE的一個配置屬性，在引用的時候並不會起做用。能夠理解爲是一個IDE的背景色，可讓你在用IDE編輯的時候看的更清楚。
sceneColor並不起做用
若是你須要更換背景色，應該經過繪製一個底部的矩形來實現。

1	this.graphics.drawRect( 0, 0, this.stage.width, this.stage.height, '#404d6f'); //設置背景顏色

 

var和name

var

通常組件view下無論嵌套的層級多深，只要有一個var屬性的命名，均可以用this.xxx來獲取到這個var屬性得帶組件的引用，並對其進行邏輯操做。

name

而name在特定的組件內name有本身的命名規則，如list下的box，命名爲render，能夠自動識別該box爲list內部渲染節點，設置list的repeat等值，直接簡便的實現某些功能。
再譬如dialog界面，咱們設置btn的name爲close、yes、no等值，能夠直接實現關閉dialog窗口的功能等等。name在這個組件下面也是惟一的，能夠用來區分不一樣的組件。

top、right對x,y的影響

若是組件設置了top、right等值，在對其進行x,y變化是無效的。
解決方法：IDE經過這些屬性設置好佈局要取消掉，會轉化爲對應的x、y值，此時能夠操做

圖集圖片過大致使圖片加載失敗

以前按照引擎官方人員的建議設置最大合集圖片爲2048乘以2048，後面通過咱們的測試發現1024寬高比較適配大部分機型，即圖片最大不能超過1024，不然微信手Q會有圖片load時間過長致使失敗的問題。
這裏多是部分合並的大圖片下載失敗，也多是所有下載失敗。而後引擎會單獨去下載每一個碎片文件，而服務器是沒有這些文件的，致使下載所有返回404。應該儘可能避免這種狀況發生。

顯示區域與點擊區域並不徹底相等

用一句話來講就是：你看到的並不必定是真實的。如我要完成收起按鈕，而後隱藏整個浮層。
可是你明明能夠看到，綁定的點擊事件卻沒有觸發。
這是由於這個層級的高度或者寬度過小，被遮擋這部分是不會觸發的。可是是可見的

分離代碼和工程

起初是由於不想在LayaIDE下寫代碼，因此分紅了兩部分，後面發現這種形式仍是很是OK的，由於Laya工做人員不是傳統前端開發，他們的IDE是相似Atom的Electron作的，因此其實運行起來編碼體驗並非太好。其次是由於IDE會生成圖片(png)和圖集(atlas)文件，這些圖片類的靜態資源，更新頻率仍是很是高的。若是你只須要修改代碼，或者只要修改圖片圖集，發佈一次就行了，不須要同時發佈兩種。

這樣的分離，代碼你能夠按照你喜歡的方式來寫，好比webpack配置工程，好比文件擺放，該怎麼放怎麼放。再把Laya生成的東西拷貝進來就行了。

設計稿和工程大小

這裏咱們設計稿和IDE的寬度高度是徹底對應的，因此不存在換算的問題。也不須要相似CSS的作REM兼容等等操做。你設定寬度是750，高度會自動拉伸，可是顯示的頁面層級，須要在初始化的時候拉伸一下，否則仍是IDE裏面設定的寬高，固然若是你懼怕上面提到的點不到，也能夠設定一個很是大的值。

Object.assign兼容

Object.assign是ECMAScript標準的合併對象屬性的方法，相似有jQuery的extend等等。
若是你拋棄了jQuery和Zepto等懶得寫extend方法，又擁抱了ES6，那你能夠像我這樣找polyfill來兼容，這裏babel官方有個模塊
也能夠本身選擇作兼容，在入口開始的時候載入兼容文件就好。

抗鋸齒問題

這個問題是在WebGL下（Canvas不會），會出現graphics.drawCircle繪製的圓環有鋸齒問題。以下圖：
鋸齒問題
左邊爲沒有設置抗鋸齒，右邊設置了抗鋸齒。

1 2	Laya.Config.isAntialias= true; //開啓抗鋸齒，會消耗一些性能 Laya.init(Browser.clientWidth, Browser.clientHeight, WebGL);

 

mask遮罩不支持抗鋸齒

有無鋸齒處理的區別
如圖，下邊是沒有優化前的，鋸齒嚴重。上邊那個圖是優化後的，明顯邊框清晰了不少。
這裏以前的思路是矩形頭像和mask遮罩爲一個總體在前面，而後內邊框和外邊框層級在後面，可是這樣的話，mask遮罩部分如今laya還不會抗鋸齒，因此這裏對公共頭像組件進行參數擴展，加了zOrder參數。讓邊框蓋在頭像上，就能夠達到抗鋸齒的做用。
最後實現的思路以下圖層級所示。
頭像層級

Laya幾種優化的寫法

用Laya自帶的屬性獲取像素比

1 2 3

//var browserHeight = document.body.scrollHeight * window.devicePixelRatio; var browserHeight = Laya.Browser.height; //會考慮設備像素比，並且會針對特定機型調整補全 `

這個不用本身算了，Laya.Broswer如今能夠獲取獲得了。簡化了運算過程

用.super()方法繼承父類

Laya.class定義的時候會在原型定義.super方法，直接用就好。兩種用法等價，可是看起來.super更簡單把？
可能有一些例子是經過xxx._super.call(this)繼承父類的，其實直接xxx.super(this)就行了。_super仍是當作私有屬性好了。