flappy pig小遊戲源碼分析(2)——解剖option

標籤：

今天繼續分析flappy bird的源碼。重溫一下源碼的目錄結構。

在本系列第一篇中我們分析了game.js檔案，也就是整個程式的架構。這一篇我們來看看option.js檔案，這個檔案的內容很簡單，主要是配置一些遊戲中各類元素的參數。

我們還是按照慣例先上原始碼：

var flappy = (function (self) {    ‘use strict‘;    //設定    self.option = {        //重力加速度，螢幕像素和實際物理上的米有差別，所以存在換算        g: 400,        //跳躍的初速度，控制豬的彈跳力        v0: 400,        //柱子移動速度        vp: 2.5,        //頻率，控制動畫幀數，預設20ms        frequency: 20,        //關卡數        levels: 100,        //開頭的空白距離        safeLift: 500,        //地板高度（和圖片有關）        floorHeight: 64,        //豬的寬度        pigWidth: 33,        //豬的高度        pigHeight: 30,        //豬當前高度        pigY: 300,        //豬距離左邊的距離,        pigLeft: 80,        //柱子Html        pillarHtml: ‘<div class="top"></div><div class="bottom"></div>‘,        //柱子寬度        pillarWidth: 45,        //柱子上下間隔高度        pillarGapY: 108,        //柱子左右間隔寬度        pillarGapX: 250,        //上柱子的基礎定位值（就是top值，和css寫法有關）        pillarTop: -550,        //下柱子的基礎定位值        pillarBottom: -500    };    return self;//這個執行完之後flappy就是一個含有option屬性的對象了})(flappy || {});

關於其中var flappy = (function(self){

//其他細節

})(flappy || {})的用法如果還是不太理解，可以再去看看本系列的第一篇。

看完這個源碼我相信絕大多數同學都沒有一點壓力，唯一可能產生疑問的就是，為什麼要這麼做呢？我們為什麼要單獨的用一個檔案來專門存放這些配置參數呢？

我們經常聽到關於程式設計的一些專業術語如：低耦合、高內聚、可維護性、模組化等等，先拋開這些模糊的概念不談，我們來說說現實生活中隨處可見的一個概念——單一職責原則。

大掃除的時候，掃地的同學只負責掃地、擦玻璃的同學只負責擦玻璃、擦黑板的同學只負責擦黑板，大家各司其職互不牽涉。檢查的時候發現地沒有掃乾淨，那就肯定是掃地同學的責任，相應的玻璃沒乾淨就找擦玻璃的同學來負責。一旦掃地的同學不僅負責掃地，同時還順便幫忙擦擦玻璃的話，檢查時如果發現玻璃沒擦乾淨，這個時候想要知道誰負責的話就很很麻煩了，起碼要把兩個人叫來問個清楚，說不定他倆再互相推脫一下。在程式設計中我們把各司其職個安其分稱之為單一職責原則，一旦出了任何問題，我們能很快的找到哪個模組該對問題負責。

瞭解了什麼是單一職責原則，我們再來看看這個option.js檔案，我們很容易的就會知道，這個option.js檔案的職責就是配置遊戲參數供其它模組使用，一旦需要調整參數，比如我要把豬變大一點，把柱子之間的距離加大一點同時把地板額高度設高一點，我只需要更改option.js檔案就可以了，改完後他會立刻反應到每個引入他的檔案中去。如果你把這些配置項分別寫在各自的模組中，那麼一旦需要調整，你可以想象你有多麼痛苦。

這一節的內容很簡單，但是需要讀者自己加深理解，形成程式設計的思想並加以運用。

flappy pig小遊戲源碼分析(2)——解剖option