遊戲開發者如何應用 CocosCreator 技術？｜技術頭條

作者 | 張曉衡

責編 | 郭芮

本文詳解介紹了Cocos Creator這一遊戲開發方案。Cocos Creator包括 cocos2d-x 引擎的 JavaScript 實現，能讓用戶快速開發遊戲所需要的各種圖形界面工具。目前，其支持發布遊戲到 Web、iOS、Android、各類"小遊戲"、PC 客戶端等平台，能夠實現全平台運行。

CocosCreator基礎教程（1）——從zIndex開始

從Cocos2d-x/lua/js過來的老程序員們肯定發現了，在CocosCreator屬性檢查器中Node節點竟然沒有zIndex屬性？

因為這一點，UI節點的遮擋關係控制不便，經常讓策劃、測試、甚至老闆找程序員麻煩。不知道大家有沒想過用編輯器去控制zIndex呢，請思考一下？我發現自己是用了CocosCreator快一年才去想到這個問題的。

要用編輯器控制，最簡單的方案就是編寫組件腳本。

/***SetZIndex.js 控制組件
**/
cc.Class({
extends: cc.Component,
//編輯器屬性定義
properties: {
zIndex: 0
},
onLoad () {
this.node.zIndex = this.zIndex;
}
});

代碼非常簡單，將這個組件腳本掛載到任意節點上，通過zIndex屬性就能控制節點的zIndex了，看下圖：

SetZindex組件

但上面的代碼有兩個小問題，不仔細還不易被發現：

• 「zIndex:0」，這樣定義zIndex屬性，它是一個浮點數類型，你可以在編輯器設置0.1這樣的值。運行在瀏覽器或H5環境沒什麼問題，但跑在原生環境zIndex對應的是cocos2d-x中的Node::setLocalZOrder(int localZOrder)函數，它的參數類型是整型。
• 這個組件只在onLoad時設置了節點的zIndex，如果運行過程中，給這個組件的zIndex屬性賦值沒有任何作用，並且在編輯器中，你設置zIndex也看不到節點層級的變化。

知道問題了就好辦了，看下面的代碼：

/**
*SetZIndex.js 控制組件
**/
cc.Class({
extends: cc.Component,
//編輯器屬性定義
properties: {
zIndex: {
type: cc.Integer， //使用整型定義
default: 0,
//使用notify函數監聽屬性變化
notify(oldValue) {
//減少無效賦值
if (oldValue === this.zIndex) {
return;
}
this.node.zIndex = this.zIndex;
}
}
},
onLoad () {
this.node.zIndex = this.zIndex;
}
});

使用一個對象來定義zIndex屬性，同時監聽zIndex的修改，問題解決。

SetZIndex組件不依賴任何其它組件和節點，可以掛載任意節點之上，因此它是一個通用組件。不要小看了這個組件的設計，它蘊涵了CocosCreator的組件編程模式和思想。

CocosCreator基礎教程（2）——聊聊scale與size屬性

在CocosCreator引擎編輯中，節點的scale和size屬性都可以改變節點內容的大小。如下圖中可愛的椰子頭，原圖尺寸為512*512，在UI編輯時發現太大了，需要128*128的大小更適合。

scale&size

此時將節點scale屬性設置為0.25好，還是將size屬性的高寬設置128好？回憶一下你在做UI編輯時，習慣用那個屬性控制節點大小，思考一下怎樣做才是UI開發的最佳實踐？

scale與size的區別

• scale: 節點整體的縮放比例，影響所有子節點。可使用scaleX、scaleY控制節點XY軸的縮放。
• size：節點內容尺寸，以像素為單位，修改size不影響子節點。size是一個對象，使用widthheight控制寬高像素尺寸。

通過上面屬性說明，比較容易看出scale與size的區別有兩點：

• scale使用比例單位，size使用像素單位；
• scale影響子節點，size不影響子節點。

在API介面上，scale可以直接使用node.scale訪問，但size卻不行，需要過node.getContentSize()
ode.setContentSize()這兩個函數訪問，不過size支持node.width
ode.height屬性訪問控制寬高。

雖然scale/size兩個屬性都可以改變節點的大小，但是當這兩個屬性同時發生了變化 ，如何獲取節點的實際像素大小用呢？比如說，將上面截圖中的椰子頭節點scale XY改為0.5，size W/H改為256，它會變成下面這樣：

scale&size同時修改

你會發現，節點只有原來的1/16大小了，它的實際像素計算如下：

width = node.width * node.scaleX
height = node.height * node.scaleY

再進一步，如果它的父節點也被縮放了，那當前節點的實際像素尺寸又怎麼計算呢？還好有引擎提供有API獲取節點包圍盒的大小，也就是節點實際看到的像素尺寸：

//節點在父節坐標系下的軸向對齊的包圍盒
rect1 = node.getBoundingBox()

getBoundingBox返回的是一個矩形cc.Rect對象的實例，其中的widthheight就是節點的像素尺寸，xy是矩形在父節點下的左下角位置。

有人可能會問，獲取節點的實際尺寸有什麼呢？最為常用情景就是做碰撞檢測，簡單的矩形碰撞並不會用到碰撞組件，而是使用cc.rectContainsPointcc.rectContainsRect這類函數做檢測，例如：

• 觸摸一個節點時，檢查觸摸點是否在節點區域中；
• 檢查將一個節點是否在另一個節點之區域內。

檢查一下你的項目代碼，是否有直接使用getContentSize()或widthheight獲取節點大小做類似上面的碰撞檢測，嘗試修改節點的scale屬性看看是否還能正常工作。

修改scale屬性，節點的size並不會變化。由此也可以看出，使用scale修改節點外觀大小不是一個好主意；簡單的使用getContentSize()獲取節點大小也不是一個安全之舉，你不能保證UI編輯的同學不會使用scale屬性，所以使用node.getBoundingBox()才是安全之道。

圖片尺寸變化對精靈節點的影響

在遊戲開發中，時常會遇到圖片資源更改的情況，比如：有一系列的角色圖片，切圖為512*512的尺寸，但在遊戲中只需要128*128或其它尺寸展示。

後來發現之前的切圖過大，包體體積不理想，於是要求美術將其改為256*256的尺寸。這時做UI編輯的同學可能會被鬱悶到，在UI編輯器中，他使用的是scale調整的精靈大小，那圖片更新還得再全部重新調整，因為它會以圖片原始尺寸的變化而按比列變化。

如果之前使用的是size屬性控制的精靈尺寸，同時Script組件設置的sizeMode為CUSTOM（當修改精靈節點的size屬性時Sprite組件的sizeMode會自動變為CUSTOM模塊，默認為TRIMMED），那圖片的尺寸變化就不會影響精靈在遊戲中的尺寸變化，所以size屬性在這次勝出。

通過上面的舉例，還說明了一個問題，將遊戲中的關鍵元素的尺寸預先規定下來非常的重要，這也就是在確定所說的設計尺寸。設計尺寸不僅僅只是屏幕設計尺寸用於規定背景圖的大小，還包括統一的角色、圖標、UI等等。

Sprite組件對圖片大小的約束

上面提到了Sprite組件的sizeMode屬性可以配合節點size對圖片大小進行約束：

Sprite組件的SizeMode屬性

當sizeMode設置為CUSTOM時，不論圖片尺寸是多大，當精靈幀spriteFrame變化時（可以嘗試拖動不同尺寸的圖片到spriteFrame屬性上）都不會影響當前節點的size大小。如果你選擇的是其它值，當spriteFrame變化時節點size也會隨之變化。

scale則不然，scale會在size的基礎上再做縮放，所以scale保持為1是最安全的，size屬性又得1分。

精靈的九宮模式

Sprite組件的type屬性為SLICED時可開啟精靈的九宮模式，當編輯好九宮屬性後，用節點size屬性可無限放大節點。

精靈九宮

需要特別注意的是，九宮屬性只適合將精靈節點放大，而不適合將節點縮小，如果九宮的邊緣像素佔比較大，縮小後會導致精靈變形。

因此使用九宮屬性的圖片尺寸盡量可能的要小，同時最好不要疊加scale屬性，這會讓精靈變形更為嚴重，size屬性再得1分。

scale屬性的應用

從上面得分來看scale屬性好慘，根據我這些年的經驗來看將其保持為1是最安全的，所以scale屬性盡量少用（默認為1）。

說scale屬性一無事處，確實也不太地道，scale屬性至少有下面3個用處：

• 用於cc.ScaleTo/cc.ScaleBy的Action動畫；
• 用於有子節點的複雜界面的整體縮放，比如對一個預製件進行縮放；
• 將scaleX或scaleY設置為負數，實現圖片的左、右、上、下鏡像減少資源量，比如下圖中兩個精靈這是同一張圖片。

設置ScaleX為負數，實現向左鏡像

所以scale屬性的作用就如同它的名字一樣：縮放！不僅可以放大、縮小，還可以向負數做縮放。

回到最初的問題，設置節點的大小使用size將是最佳的實踐。這有助於在UI的編輯與設計，同時預先規劃好遊戲元素的設計尺寸、資源的文件名，無需太多考慮圖片素材的尺寸，使用臨時圖片即可開始項目的開發。

CococsCreator基礎教程（3）——meta的秘密

CocosCreator會為assets目錄下的每一個文件和目錄生成一個同名的meta文件，那meta文件有什麼作用呢？下面我們就來說下meta，理解了CocosCreator生成meta文件的作用和機理，能幫助你和你的團隊解決在多人開發時常會遇到的資源衝突、文件丟失、組件屬性丟失等問題。

腳本丟失

先看下一個場景文件的meta長什麼樣子：

{
"ver": "1.0.0", //版本"uuid": "911560ae-98b2-4f4f-862f-36b7499f7ce3", //全局唯一id"asyncLoadAssets": false, //非同步載入"autoReleaseAssets": false, //自動釋放資源"subMetas": {} //子元數據
}

場景與預製件的meta都長的一個樣，再看一個png圖片的：

{
"ver": "1.0.0",
"uuid": "19110ebf-4dda-4c90-99d7-34b2aef4d048",
"type": "sprite",
"wrapMode": "clamp",
"filterMode": "bilinear",
"subMetas": {
"img_circular": {
"ver": "1.0.3",
"uuid": "a2d1f885-6c18-4f67-9ad6-97b35f1fcfcf",
"rawTextureUuid": "19110ebf-4dda-4c90-99d7-34b2aef4d048",
"trimType": "auto",
"trimThreshold": 1,
"rotated": false,
"offsetX": 0,
"offsetY": 0,
"trimX": 0,
"trimY": 0,
"width": 100,
"height": 100,
"rawWidth": 100,
"rawHeight": 100,
"borderTop": 0,
"borderBottom": 0,
"borderLeft": 0,
"borderRight": 0,
"subMetas": {}
}
}
}

圖片文件meta信息比較多，除了基本的ver和uuid外，還記錄了圖片的高寬、偏移、九宮格等數據。上面這麼多信息，我們這裡只關心一個：uuid，通用唯一標識符（Universally Unique Identifier）。

uuid是CocosCreator用來管理遊戲資源的，它會為每個文件分配一個唯一的id，圖集會生成多個。由此可以了解在CocosCreator引擎中，識別一個文件不是簡單地通過路徑+文件名定位，而是通過uuid來引用文件。因此可以在編輯器資源管理中，隨意刪除、移動文件。

CocosCreator生成meta文件有以下幾種情況：

• 打開工程時。CocosCreator引擎在工程剛被打開時，先掃描assets目錄，如果哪個文件還沒有meta文件，此時就會生成。

• 更新資源時。更新資源也會引發meta文件的更新：

• 通過引擎編輯器資源管理窗口，可以對資源進行文件名修改、改變目錄、刪除文件，添加文件可以從桌面或操作系統的文件管理器將文件拖入引擎資源管理器中。

拖動圖片到資源管理器

還有一種情況是在操作系統的文件管理器中對assets目錄中的文件進行增、刪、改之後，激活引擎編輯器窗口，此時可以看到資源管理器刷新的過程。

資源刷新

如果一個文件的meta文件不存在，上面兩種情況都會觸發引擎去生成meta文件。

下面我們分析下meta文件出錯的幾種可能情況。

uuid衝突

uuid是全局唯一的，產生衝突肯定是有不同的文件的uuid相同了，一旦出現這個問題會導致CocosCreator資源管理器目錄結構載入不完整，看下圖，遇到這種情況估計會讓你嚇出一身冷汗：

CocosCreator UUID衝突

從提示中可以看到衝突的uuid字元串，打開操作系統文件管理或代碼編輯器，搜索這個uuid：

搜索uuid，找到兩個相同的

這時先關閉CocosCreator，然後再任意刪除其中一個meta文件，再打開CocosCreator問題可以解決。

這種方法雖然可以解決問題，但如果在編輯器中曾經引用過這個資源的地方將會出現資源丟失，你需要重新編輯或配置一次。最好是通過版本管理工具還原此meta文件。

據我觀察，出現這種問題的原因有兩個：

• 在操作系統的文件管理器中移動文件時，將剪切、粘貼操作不少心弄成了複製、粘貼，同時也把meta文件也複製過去了。導致項目中同時出現兩個相同的meta文件。
• 在多人協作時，從版本管理工具中，更新資源時碰巧遇到別人生成的uuid與你的電腦上某個文件生成的uuid一樣了，但這種情況非常罕見。

總的來說，要解少uuid衝突發生，最好在引擎資源管理工具中進行添加、移動文件。

uuid變化

還有種情況是uuid變了，你曾經編輯的界面將會出現資源、圖片丟失，還可能出現組件屬性丟失。

uuid變化，編輯器資源丟失

通過Creator控制台的警告可以看到，有曾經被使用過的資源uuid，但現在丟失了。提示還是很詳細的，給出了所在的場景文件名、節點路徑、組件、uuid，通過提示可以快速定位資源丟失的地方。

這種情況又是怎麼造成的呢？一種情景是在新資源添加進項目時，忘記了激活一下CocosCreator讓其生成meta文件，同時又將這些新增的文件提交到了版本管理中(不包含meta文件)。之後，有同學去更新了他提交的資源，同時打開或激活了CocosCreator進行編輯，這時Creator會檢查到新資源沒有meta便會立即生成。這樣兩個同學的電腦上為同一個文件，生成的meta文件中的uuid都不相同。

這種情況下，後面進行資源提交或更新的同學，肯定也會遇到衝突，如果不明就理就強行解決衝突，就會產生上面的問題，同時把問題蔓延到別的人身上。下面時序圖，描述了這種錯誤的工作流程：

資源更新流程

上面就因第一個A同學忘記生成meta並提交，導致這個嚴重的問題，每個人都編輯過項目，但每個人生成的uuid都不同。如果不明其理，會陷入無限的資源出錯中，做好的東西，一提交更新又出問題了。

要解決這個問題注意下面幾點：

• 提交前檢查是否有新增文件，有新增文件時，注意是否有meta文件，需要一起提交。
• 拉取文件時，注意是否有新增文件，並且是有meta文件成對，如果沒有提醒之前提交文件的同學，把meta文件一併提交。
• 提交時，如果發現只有新增的meta文件，那這個meta文件肯定是自己生成的，那注意是否使用過這個meta文件對應的資源（同名文件）。如果沒用過，那請這個文件最早提交者把meta文件提交了。千萬不能將這個meta文件提交上去。

注意上面幾點基本上就可以杜絕meta文件uuid變化導致的工程出錯了。

meta文件是CocosCreator用於資源管理的重要手段，但在多人協同開發中稍有不慎就容易產生資資源錯誤。要解決這個問題，不僅需要理解meta文件的產生機制和導致衝突的原因，同時還應該規範資源提交流程。

CocosCreator基礎教程（4）——color屬性的妙用

在CocosCreator中巧妙利用節點的color屬性，改變精靈的顏色，可以有效減少美術資源。我們一起來看看CocosCreator的HelloWorld工程：

背景節點的Color屬性

看上圖，這次我們的重點不在可愛的椰子頭節點上，而是在背景background節點上。它是由一個高寬2像素的純白色(#FFFFFF)圖片渲染而成，但節點的color屬性為#1B262E，同時注意，節點的高寬充滿了整個畫布，你可以通過size屬性（沒有使用scale哦）自由調整節點的尺寸大小。

回想一下，在你的工程中，有沒有切出一大塊純色圖片做背景？如果有的話這就是一個可優化的點！我們來看看充分發揮color的作用需要注意些什麼。

顏色疊加

要想使用color屬性精確控制精靈顏色，圖片要盡量使用白色，因為color屬性並不是簡單地設置顏色，而是用紋理像素的rgb與節點的color的rgb相乘（r * color.r、g*color.g、b*color.b）。

節點的Color效果

看上圖，在場景編輯器中，椰子頭和一個純紅色的精靈節點，都設置為黃色（#FFFF00）。椰子頭覆蓋上了一層黃色，再看純紅色的精靈則沒什麼顏色變化，另外注意椰子頭整體顏色變暗了，由此得出下面幾條經驗：

• 最好在純白色的精靈上使用color屬性，可以精確控制顏色；
• 在非純色的精靈上使用color屬性，整體色調會變暗；
• 純紅、綠、藍的三元色精靈使用color屬性，顏色只能在當前圖片顏色範圍變化，應用範圍有限。

color屬性在字體上的應用

上圖中，我不僅在精靈組件上設置了顏色，同時也設置了它們下方的Label文本節點的顏色。使用系統字體，引擎默認渲染出的文本是白色的，疊加任意color屬性，可以精確控制顏色。

通過修改字體的color屬性可以很方便實現一些效果，比如：使用紅色Label做受傷時的hp減少；使用綠色Label實現hp的回復；

但是這裡有個問題，項目中我們經常使用的並不是系統字體，而是點陣圖字體，也就是由圖片製作的字體，看下圖：

藝術字體

上圖使用的是Atlas藝術字體，關於自定義字體相關的內容我們以後再說。這裡可看到綠色Label的文本是由字體文件中的圖片構成，也使用了圖片的顏色。但這裡有個小小的遺憾，這個字體圖片使用了個純RGB三元色中的的綠色，它的顏色變化範圍有限，只能用於hp回復這類場景，要給它疊加紅色只會讓你失望，看下圖：

綠色字體疊色後變黑色了

所以在製作字體時，盡量先用純白色，或者再用點淺灰色做字體外發光，這樣可以讓字體文件的使用範圍更大，發揮更大的價值。

透明度對節點影響

透明度也是color屬性的一個組成部分，但透明(opacity)會影響到子節點，RGB則值不會。

不知道你是否注意到美術切出的圖片，應用到遊戲被引擎渲染出來時，在顏色上總是覺得有所偏差，這裡有一個很重要原因就是：透明度。如果一個精靈節點設置了透明度，你看到的並不是這個精靈所表現出來的顏色，而是當前這個精靈與它背後的顏色重疊後色彩，看下圖：

透明度對圖片的影響

中間和左邊兩個精靈透明(opactiy)為155，但中間的這個精靈節點放在了一個白色圖片的上面，精靈節點的顏色與它的背景顏色做了疊加。最右邊的精靈沒有設置透明，與最左邊對比，左邊精靈的顏色要暗些，也是因為透過了當前節點加入了背景色的原因。

不僅設置節點的透明屬性會影響到精靈的顏色表現，如果原始圖片帶有透明通道同樣會影響到圖片在布局時的顏色表現。它與不同的背景色重疊會產生不同的顏色偏差，因此用作背景的圖片不論尺寸大小，紋理內容區域盡量不要設置透明（不規則邊緣不在此列），這樣做不僅避免顏色重疊產生的不一至，而且讓圖片所佔用的磁碟空間、內存空間也會更小。

節點color可以控制精靈的渲染顏色，靈活運用可以減少圖片資源。color屬性不僅可以作用於精靈，更多的是應用於Lable標籤，使用白色紋理，可以讓圖片更具靈活性。

另外需要注意，圖片的透明和節點的透明度都會影響遊戲最終渲染出的顏色效果，合理利用color、size、錨點、旋轉、九宮等屬性特性，揚長避短，可以讓遊戲更加出色。

Cocos Creator基礎教程（5）—資源結構

對於遊戲開發來說，除了編輯遊戲界面、製作遊戲動畫、編寫代碼這些具體的工作外，大家還需要對遊戲資源結構要非常清楚。如果馬虎上陣，等你把項目運作做起來後，一是工作效率不會太高，二是難以精確控制資源，最後甚至會因此陷入混亂。

資源是指用於遊戲內容創作所需要的素材，對於Cocos Creator工程來說就是assets目錄下的文件，看下圖：

資源目錄結構

那資源結構就是將眾多的資源文件按一定的規則存放和命名，以方便使用管理。

看上圖所示，我把資源大致分為以下幾類：

• 動畫：animation
• 預製：prefab
• 場景：scene
• 腳本：scripts
• 紋理：textures
• 聲音：sound
• 配置：config

其中紋理可再細分為：動畫幀、背景、字體、UI、圖標等（將動畫幀圖片放到動畫目錄中會更好，這樣可以將動畫資源與項目做分離）。分類目錄也不要過細，過細會增加重複文件（同名或不同名但內容）出現機率，同時將通用資源和專用資源分開存放，可以再次減少重複文件的產生。

代碼的分類也需要注意，我通常將Cocos Creator通用組件（純腳本組件）放在component目錄下。如果組件腳本是與某個prefab緊密關聯的，則將它們放在一起，如下圖：

預製文件與組件腳本放在一起

上面有兩個預製組件Chessboard是棋盤，Chessmain是棋子，它們各關聯了一個同名的組件腳本。因為這兩腳本不具備通用性，所以沒有把它們放在component目錄下，而是將它們與所關聯的預製放在文件一起。

我上面只是舉個例，不同公司、項目可以根據自己的具體情況設計資源結構，而且非常必要讓參與項目的成員（策劃、美術、程序）都清楚分類規則。

文件命名

一個普通的遊戲項目，資源大致包括有：圖片、代碼腳本、聲音、配置文件、場景預製文件等等，小項目至少也有上百個文件，大的項目甚至過萬。僅對資源分類還不能進行快速定位，還需要有文件命名規則。

通常圖片文件是遊戲中用的最多的資源，我之前總結了一個簡單的圖片文件命名公式，供大家參考：命名公式：前綴+中綴+[後綴]。

前綴用於分類，中綴表示功能或特徵，後綴可選一般是序號，舉幾個例子：

• img_gold.png：一個金幣圖片，img表示圖像是除UI交互元素之外的統稱。
• btn_blue_ok_0.png: 一個綠色按鈕，btn表示一個UI按鈕，blue_ok是顏色特徵和功能特徵(注意的是中綴可以由多個單片語成)，後綴0是表示，正常、按下、禁用中的正常狀態。
• bg_login.png：登錄界面的背景圖片，bg表示背景，login是功能特徵表示用於登錄界面。

有了這樣的文件命名，在編輯UI時就不會如大海撈針，把時間和精力消耗在資源管理里尋找圖片了，直接使用Cocos Creator資源管理器模糊搜索前綴或中綴就能快速鎖定目標，看下圖：

定位資源並拖放到屬性檢查器中

上圖不小心暴露了我的一個小技巧，如果你用心看了上圖會發現，上面的窗口布局中將屬性檢查器、層級管理器、資源管理器放在一起，屬性設置時減少了滑鼠拖拽距離，減少了操作時間和出錯機率，從而可以有效提高UI編輯效率，但我發現很少有人這樣布局引擎編輯器。

文件命名與資源分類相同，可以根據自己實際情況制定自己的文件命名規則，一定要讓參與項目的成員知曉且嚴格遵守，這樣可以有效提高開發效率，躲避風險。

以上講了資源分類與命名在遊戲開發中的重要性，結構化不僅可用於資源管理，同時在分析問題時也可以使用結構化的思維。請用心觀察體會自己現在或過去的項目，有沒有在資源管理上遇到問題，是否注意到了資源結構對項目的影響。

Cocos Creator基礎教程（6）——AudioSource組件

下面我們介紹cc.AudioSource音頻播放組件的使用，使用cc.AudioSource組件不用寫任何一行代碼，就能控制音效的音量、播放、停止、恢復等操作。

在層級管理器裡面創建一個空白節點，然後在下圖示意位置添加AudioSource組件：

添加一個AudioSource組件

這裡需要注意，有不少默認組件並不在組件庫中或層級管理器的右鍵菜單中，但可以在屬性檢查器下方的添加組件按鈕菜單中找到。

將AudioSource組件綁定到節點，可以看到它提供的屬性介面，見下圖：

簡單解釋一下組件屬性：

• Clip 音頻資源，通過拖拽音頻文件設置；
• Volume 音量大小，範圍0~1之間；
• Mute 是否靜音，靜音後可以繼續播放；
• Loop 是否循環播放；
• Play on load 載入完成是否立即播放；
• preload 是否在未播放的時候預先載入。

接下來把資源目錄下的音頻文件拖到AudioSource的Clip屬性，看下圖：

設置音頻文件

箭頭2所指的Play On Load屬性打勾，在遊戲運行起來的時候就能自動播放了。不用任何代碼，這對不會編程的策劃同學來說是一個驚喜哦，不依賴程序員就能控制遊戲音效，至少在做遊戲原型時增加了聲音這個維度！

下面我們講下如何控制聲音播放和停止，這裡需要使用cc.Button組件來控制，同樣無需編程。首先在層級管理器右鍵點擊Canvas創建兩個按鈕：

也可以在控制項庫裡面拖拽按鈕：

接下來給按鈕綁定事件：

• 選中按鈕，把我們之前設置的含有AudioSource節點拖到箭頭指定的地方；
• 然後在中間的選項卡裡面選中我們的cc. AudioSource；
• 最後在右邊的選項卡裡面找到我們的play函數。

這樣就算綁定完成了！ 快去運行起來試試看吧！

用同樣的方法，給停止按鈕綁定stop函數，與綁定play函數一樣，在第3步選擇stop就行了，這裡附上AudioSource的實用函數介面，都可以使用cc.Button組件調用：

play() //播放音頻剪輯
stop() //停止當前音頻剪輯
pause() //暫停當前音頻剪輯
resume() //恢復播放
rewind() //從頭開始播放

這裡給大家分享了AudioSource組件的使用方法，不需要編寫任何代碼。不過AudioSource組件還有存在一點瑕疵， 它不適合播放背景聲音，而且為AudioSource組件做全局控制音量控制也不方便。

Cocos Creator基礎教程（7）——場景切換

在Cocos Creator中切換遊戲場景可以像切換幻燈片頁面一樣簡單，這次教程我們稍微進階一點點，帶著大家編寫這個場景切換組件。

先看組件代碼：

//場景載入組件
cc.Class({
extends: cc.Component,
properties: {
scene: cc.SceneAsset, //定義場景資源
},
onLoad() {
//註冊節點觸摸事件，當觸摸結束載入場景this.node.on(cc.Node.EventType.TOUCH_END, () => {
//使用cc.director.loadScene引擎API載入場景
cc.director.loadScene(this.scene.name);
);
}
});

新建一個測試場景，場景中添加一個Label，將LoadScene組件綁定到Label節點上，同時拖拽另一個場景到LoadScene的Scene屬性上，看下圖所示：

LoadScene組件

我們這個LoadScene組件可以掛載到任何節點上，配置好想載入的場景，啟動預覽下效果如何！

在Label上點擊沒有什麼反饋效果，我們把節點換成按鈕控制項體驗會更好，而且cc.Button組件還帶有事件觸發能力，可執行指定節點上的組件函數。

改造一下組件代碼：

//增加loadScene函數，可被Button組件調用
cc.Class({
extends: cc.Component,
properties: {
scene: cc.SceneAsset, //定義場景資源
clickable: true, //是否可點擊
},
onLoad() {
//開啟點擊，註冊場景載入事件if (this.clickable) {
this.node.on(cc.Node.EventType.TOUCH_END, this.loadScene, this);
}
},
loadScene() {
//場景存在，調用場景場景載入if (this.scene) {
cc.director.loadScene(this.scene.name);
}
}
});

增加了一個clickable屬性，如果使用Button的事件觸發來調用函數，就不要註冊觸摸事件了，不然會執行多次。我們把之前的觸摸事件單獨抽成了一個loadScene函數，同時做了屬性檢查，請看下圖配置：

LoadScene組件關聯Button

在場景中添加了一個Button節點，掛載好LoadScene組件，設置好要載入的場景，不要勾選Clickable屬性（不與Button事件配合時勾選）。然後將重點放在cc.Button組件屬性設置上：

• 增加一個Click Events事件；
• 事件第一個參數是指向一個節點，這裡拖動Button節點到這裡；
• 事件第二個參數是選擇這個節點上的一個組件，這裡選擇LoadScene；
• 事件第三個參數是選擇組件上的LoadScene函數。

與cc.Button組合在配置要繁瑣一些，你可以只使用Button的點擊過渡效果，不使用Button的事件，勾選下面的Clickable屬性效果相同。

Cocos Creator基礎教程（8）——載入預製件

我們上面講了場景切換並編寫了LoadScene場景加組件，這次我們在場景裡面創建獨立的子界面或子窗口。在Cocos Creator中實現子界面的最好方案就是: 預製件。

Cocos Creator並沒有一個新建預製件的功能菜單項，我們可以在場景中先做一個大概的布局，然後在層級管理器中將節點拖動到資源管理器中：

層級管理器與資源管理器的本質是內存數據與磁碟文件的關係，從層級管理器將節點拖到資源管理器，就是從內存中將數據保存到磁碟上。

需要注意的是場景中的Dialog節點與資源管理器的Dialog預製文件並沒有太多的聯繫，它們是同一個數據不同的表現形式而已，如果感興趣可以用文本編輯器打開預製文件了解。

雙擊預製件文件，切換到預製件的獨立編輯界面：

預製件的界面編輯與場景一樣，但它們都應該保持邏輯清晰的層級結構，注意下面幾點：

• 有意義的節點命名，同層節點名盡量不要重複；
• 建立節點之間在邏輯上的祖、父、子關係（例如：按鈕上顯示文字，就應該將Label節點放在Button節點的內部）；
• 將預製件根節點坐標位置設置為{x:0, y:0}；
• 建議預製文件名與預製件根節點名字保持一至。

接下來我們來實現LoadPrefab組件，先上代碼：

cc.Class({
extends: cc.Component,
//組件屬性定義
properties: {
PREFAB: cc.Prefab, //預製件
parent: cc.Node, //預製件實例化後所在的父節點
autoLoad: false, //自動載入
},
//組件載入時檢查，是否自動載入預製件
onLoad() {
if (this.autoLoad) {
this.loadPrefab();
}
},
//實例化預製件，設置父節點
loadPrefab() {
let node = cc.instantiate(this.PREFAB);
//當父節點不存在時，使用當前組件為父節點
node.parent = this.parent || this.node;
}
});

我們用一個按鈕點擊顯示Dialog對話框，一起看看在編輯器上的配置，見下圖：

• 在場景中添加一個Button控制項；
• 將LoadPrefab組件腳本掛載到Button節點上；
• 從資源管理器中將Dialog預製件拖動到DialogLoadPrefab組件PREFAB屬性上，這是我們要載入的預製件；
• 從層級管理器將Canvas節點拖動到DialogLoadPrefab組件Parent屬性上，這是預製件實例化後的父節點；
• 配置按鈕事件，與上篇場景載入相同，就是調用Button節點上的LoadPrefab組件上的loadPrefab函數。

編輯器配置複雜了點，這裡分享一個小小的經驗，配置好一個複雜的組件後，你可以通過複製節點或複製組件，將其粘貼到界面中再做修改，這樣比重頭配置組件參數可以提高50%以上的效率。不過還好代碼還是比較簡單，你也可以在組件代碼中監聽觸摸事件來調用loadPrefab函數，同樣可以減化編輯器配置。

我們的組件上還提供了一個autoLoad屬性，可以在宿主節點創建時自動創建預製件，這可以解決直接將預製件拖入場景，然後又去編輯預製件，導致場景中的預製節點與預製文件不同步的問題（預製件的嵌套問題）。

這一段我們講解了預製件的生成，就是編輯的界面從內存保存到磁碟，之後可以通過cc.instantiate函數將預製件文件實例化為節點。同時介紹了我對編輯預製件的一點小經驗供大家參考。最後編寫了一個通用的LoadPrefab組件，可以方便非程序員同學使用。有了這些組件代碼的積累相信以後不論是做遊戲還是原型或是Demo，都能為我們提高生產效率。

Cocos Creator基礎教程（9）——優化代碼編輯器

Cocos Creator遊戲開發主要是使用JavaScript語言，這裡向大家推薦Visual Studio Code和Webstorm兩款JavaScript神級編輯器。這兩款編輯器的安裝都很簡單，這裡主要介紹在Cocos Creator項目中如何調整編輯器配置，以提升開發效率。

我們知道Cocos Creatror會為項目資源文件生成同名的meta文件，在代碼編輯器中很是礙眼，而且也不能更改裡面的內容，嚴重干擾我們在代碼編輯器中瀏覽文件，請看下圖：

我們這裡介紹VSCode和Webstorm如何屏蔽干擾文件。

首先用VSCode打開Cocos Creator項目，使用shift+ctrl+p/shift+cmd+p打開命令控制台。

在命令行中輸入settings，在過濾出的選項中選擇打開用戶設置，在用戶設置編輯區配置文件排除規則：

"files.exclude": {
"**/*.meta": true
}

嘗試保存此文件，你會看到VSCode的資源管理器中所有meta文件都不在了，下圖是我慣用的文件排除配置：

除了過慮meta文件外，同時把git、svn和Cocos Creator的臨時目錄出排除了，這樣可以通過ctrl+p/cmd+p在編輯器中快速準確地定位文件。

接下來我們看在Webstorm中怎麼排除干擾文件，先在Webstorm中打開Cocos Creator項目，使用快捷鍵ctrl+,/cmd+,打開Preferences窗口，在左上角過濾框輸入：File Types。

注意選中下方列表File Types選項，在右側下方Ignore files and folder輸入框中增加*.meta、.DS_Store等需要過濾的文件類型以分號隔開，然後點擊下方Apply按鈕，觀察最左側資源瀏覽器窗口，會看到相應要排除的文件不在了。

代碼補全增強

代碼補全是開發中提高效率的重要功能，對於JavaScript動態語言來說，代碼補全確實要比c/c++、Java要差很多。但是經過配置VSCode和Webstorm也能提高不少我們的生產效率。

Cocos Creator集成有VSCode智能提示數據，可以通過Cocos Creator的主菜單：開發者－＞VS Code工作流－＞更新VS Code智能提示數據：

執行菜單命令後，Cocos Creator會在當前工程中添加一個creator.d.ts文件，此文件也是我們熟悉Cocos Creator API介面的重要文件，而且是中英兩語的哦！

Webstorm除了像上述安裝creator.d.ts文件外，還需要設置JavaScript語法為ES6，不然你可能會在IDE中看看到一大片紅色的語法錯誤。進入Preferences設置窗口，在最左上角過濾框中輸入JavaScript，定位到Languages & Frameworks下的JavaScript選項，在右邊JavaScript language version選擇ECMAScript 6，看下圖：

配置上Cocos Creator的源碼路徑，可以進一步提高Webstorm代碼提示精度，見下圖：

點擊Add…按鈕，添加Cocos Creator源碼路徑：

• 首先為導入的庫設置名字；
• 選擇應用範圍為Global所有工程有效；
• 點擊+按鈕，選擇Attach Directories… 瀏覽到Cocos Creator源碼目錄我用的是Mac系統設置的路徑是： /Applications/CocosCreator.app/Contents/Resources/engine/cocos2d；
• 點擊OK保存。

代碼編輯器是程序員的一把利劍，這裡介紹在VSCode和Webstorm中如何排除干擾文件、優化代碼提示，以提高開發效率。

Cocos Creator基礎教程（10）——預覽調試

遊戲預覽是開發中的一個重要環節，Cocos Creator遊戲引擎基於JavaScript語言有著豐富強大的預覽調試能力，下面我們介紹預覽調試相關的技術，了解一下這方面的知識相信對你也非常有幫助。

Cocos Creator是跨平台的遊戲開發引擎，從類別上主要分為Nativet和H5兩大平台，遊戲預覽也分為這兩大模式：瀏覽器、模擬器。我們可以從Cocos Creator主窗口上選擇預覽模式、啟動預覽，也可以通過掃描二維碼在手機瀏覽器中預覽（注意IP地址為區域網地址，如不正確請在設置中修改）。

預覽遊戲

在瀏覽器中預覽遊戲是日常開發工作最為常用的功能，同時Cocos Creator為我們提供多種屏幕解析度的模擬，查看遊戲渲染性能參數，請看下圖：

瀏覽器預覽

在原生模擬器中也可以模擬不同的設備尺寸、設置橫豎屏，看下圖：

模擬器預選項

日常的開發中，我們用的最為頻繁的還是在瀏覽器中預覽，這裡推薦大家使用Google Chrome瀏覽作為開發調試環境。

在瀏覽器中啟動預覽後，可以開啟Chrome的開發者工具進行遊戲代碼的瀏覽、調試、日誌查看等調試代碼中的問題。在遊戲畫布窗口之外，點擊滑鼠右鍵，選擇檢查（快捷鍵：ctrl+shift+I/cmd+opt+I），打開開發者工具：

啟動開發者工具

在Chrome開發者工具窗口中使用快捷鍵ctrl+p或cmd+p呼出文件搜索窗口，快速定位代碼文件（與VSCode的文件查找一樣）。

Chrome開發者工具

此處你可以利用開發者工具，對Cocos Creator的源碼進行跟蹤調試，查看API介面，這是學習Cocos Creator一個重要途徑，看下圖：

Chrome調試

Chrome的開發者調試工具非常強大，這裡簡單介紹幾個常用的功能：

• 點擊行號設置斷點，代碼運行到此處程序會自動暫停下來；
• 當代碼被斷點後，將滑鼠移動變數之上查看變數值；
• 使用快捷鍵ctrl+~呼出互動式命令控制台，可以查看變數值或執行代碼；
• 使用快捷鍵F10單步執行、F11單步跟入、Shift+F11跳出當前函數、F8運行；
• 右側Call Stack函數調用堆棧窗口，點擊堆棧函數可以跳轉到對應函數源碼。

Cocos Creator支持多平台構建模板，如果你開發的是微信小遊戲，一定要在微信開發者工具中預覽調試。在構建發布窗口中，簡單設置就可以構建出目標平台所需的文件，請看下圖：

構建微信小遊戲

啟動微信開發者工具，選擇小程序項目，你會看到與Chrome瀏覽器類似的預覽調試窗口：

微信開發者工具

按照之前Chrome的快捷鍵用法，你就可以在微信開發者工具中斷點調試遊戲了，沒什麼太多區別，就是窗口太擠了，建議將調試窗口浮動出來形成一個獨立的窗口。

Chrome是JavaScript的開發調試神器，熟練使用Chrome的調試工具是開發H5遊戲的必備技能，我們這裡只是介紹了Chrome的冰山一角，下來還請大家多多實踐。

Cocos Creator基礎教程（11）——可拖拽組件

在遊戲中實現節點的可拖動是一個比較常見情況，比如：可以給小朋友做一個將果皮投進垃圾箱的教學練習、角色換裝、物品包裹界面等。在Cocos Creator中實現一個可拖動組件，只需對目標節點拖拽配置就能讓節點任意移動，這對策劃、美術人員來說是不是很有殺傷力？

在實現一個組件代碼之前最好新建一個測試場景，組件代碼在測試場景中通過了基本測試之後再放入正式環境使用。而且在組件完成後，測試場景最好也不要丟棄了，等我們以後為組件升級或修改BUG時，可用於快速檢驗修改是否正確。

初始化工程

我們來看下組件代碼非常簡單，就算你不會編程，根著注釋相信也能明白個大概：

cc.Class({
extends: cc.Component,
onLoad() {
//註冊TOUCH_MOVE事件
this.node.on(cc.Node.EventType.TOUCH_MOVE, this._onTouchMove, this);
},
_onTouchMove(touchEvent) {
//通過touchEvent獲取當前觸摸坐標點
let location = touchEvent.getLocation();
//修改節點位置，注意要使用父節點進行對觸摸點進行坐標轉換
this.node.position = this.node.parent.convertToNodeSpaceAR(location);
}
});

代碼主要是設置節點的觸摸監聽，在監聽事件中修改節點的位置。將組件代碼掛載到節點上，其它什麼都不用做。

我給目標節點掛載了一個Layout組件，設置成GRID模式，實現自動網格排列，很像遊戲中的物品包裹功能，這個組件真的是物超所值。

這次主要運用了節點的觸摸事件監聽，在觸摸事件的touchEvent參數中獲取當前觸摸坐標點。同時還需要對坐標點在不同節點坐標系下進行轉換，需要理解的是拖動節點的本質是：修改節點在父節點上的位置，需要使用this.node.parent.convertToNodeSpaceAR進行轉換。同時還有使用了最簡單的碰撞檢測函數rect.contains（在Cocos Creator 1.9.3之前用cc.rectContainsPoint），檢查一個坐標點是否在矩形內。

Cocos Creator基礎教程（12）——精靈變身

在Cocos Creator中使用率最高的非精靈(Sprite)莫屬了， 在遊戲中我們經常會遇到將一張圖片替換成另一張圖片的情況，或者是在不同狀態時來回切換圖片。實現這個功能對程序員同學來說並不難，但是回頭檢視一下編寫的代碼，能否讓美術、策劃同學使用上嗎？如果不能的話，相信下面的教程可能對你和你的夥伴有更多啟發！

我們這裡設計一個SpriteIndex組件，使用組件的index屬性來控制Sprite組件的spriteFrame屬性，從而得到圖片變換的能力。

//SpriteIndex.js
cc.Class({
extends: cc.Component, //編輯器屬性，只在編輯狀態有效
editor: CC_EDITOR && {
requireComponent: cc.Sprite, //要求節點必須有cc.Sprite組件
},
properties: {
spriteFrames: [cc.SpriteFrame], //定義一個SpriteFrames數組
_index: 0, //以下劃線「_」開始的為私用變數

index: { //index屬性控制圖片切換
type: cc.Integer, //定義屬性為整數類型//這次沒使用notify方式實現屬性值的變化監聽，改用getter/setter方式
get() {
return this._index;
},
//為負數退出
set(value) {
if (value < 0) {
return;
}
//根據spriteFrames組件長度計算this._indexthis._index = value % this.spriteFrames.length;
//獲取當前節點上的Sprite組件對象
let sprite = this.node.getComponent(cc.Sprite);
//設置Sprite組件的spriteFrame屬性，變換圖片
sprite.spriteFrame = this.spriteFrames[this._index];
},
}
},
/**
*next方法，調用index++切換圖片，
*可以方便被cc.Button組件的事件調用
*/
next() {
this.index++; //調用自身index屬性，編號+1
}
});

代碼比之前的教程要複雜了一點點，對沒有編程經驗的美術、策劃同學來說可能殘忍了點，但堅持跟著注釋了解組件的實現意圖，相信你會收穫更多。

我們再看下圖，SpriteIndex組件的用法：

• 在編輯器場景中添加一個Sprite組件；
• 然後掛載上SpriteIndex；
• 添加SpriteFrames數組屬性元素；
• 將可能會出現的圖片拖動到SpriteFrames數組屬性下；
• 嘗試修改index屬性，你會看到精靈圖片的變化。

運行時圖片切換

請出我們的按鈕組件，通過點擊時調用SpriteIndex.next方法進行切換，看下圖配置：

此時啟動預覽，嘗試點擊這個精靈節點你就能看到圖片在不斷切換變化了。如果你想玩的再高級一點，可以在一個定時器中調用next方法，它立馬就是成了一個序列幀動畫了。

直接繼承cc.Sprite

我們設計的是通用型組件，最好還是不要訪問別的節點、組件的屬性和方法，保持乾淨！這樣更具有可擴展性和適應性。

SpriteIndex在這裡就是給cc.Sprite做輔助的，它能不脫離cc.Sprite而存在。堅持做到最好，儘可能的讓組件更多人能使用，限制越少越好，屬性也是越少越好，只要能完成任務就行，看下在的做法，我們改進一下：

//SpriteEx.js
let SpriteEx = cc.Class({
extends: cc.Sprite, //繼承自cc.Sprite
properties: {
spriteFrames: [cc.SpriteFrame],
_index: 0,
index: {
type: cc.Integer,
set(value) {
if (value < 0) {
return;
}
this._index = value % this.spriteFrames.length; //直接訪問spriteFrame屬性，因為this就是cc.Spritethis.spriteFrame = this.spriteFrames[this._index];
},
get() {
return this._index;
}
}
},
next() { this.index++
}
});
//下面是控制SpriteEx組件在屬性檢查器中的屬性顯示
//不顯示spriteFrame屬性
cc.Class.Attr.setClassAttr(SpriteEx, "spriteFrame", "visible", false);
//不顯示Atlas屬性
cc.Class.Attr.setClassAttr(SpriteEx, "_atlas", "visible", false);
//根據函數返回值控制屬性顯示、隱藏
cc.Class.Attr.setClassAttr(SpriteEx, "fillType", "visible", function() {
return this._type === cc.Sprite.Type.FILLED;
});
cc.Class.Attr.setClassAttr(SpriteEx, "fillCenter", "visible", function() {
return this._type === cc.Sprite.Type.FILLED;
});
cc.Class.Attr.setClassAttr(SpriteEx, "fillStart", "visible", function() {
return this._type === cc.Sprite.Type.FILLED;
});
cc.Class.Attr.setClassAttr(SpriteEx, "fillEnd", "visible", function() {
return this._type === cc.Sprite.Type.FILLED;
});
cc.Class.Attr.setClassAttr(SpriteEx, "fillRange", "visible", function() {
return this._type === cc.Sprite.Type.FILLED;
});
cc.Class.Attr.setClassAttr(SpriteEx, "srcBlendFactor", "visible", function() {
return this._type === cc.Sprite.Type.FILLED;
});
cc.Class.Attr.setClassAttr(SpriteEx, "dstBlendFactor", "visible", function() {
return this._type === cc.Sprite.Type.FILLED;
});

上面的核心代碼沒幾行，千萬不要被嚇到了，後面的屬性控制函數主要是減少不必要的屬性產生的干擾，提高組件使用時的體驗，看下圖：

紅色框線是我們添加的屬性，上面的是cc.Sprite組件原始屬性，我們屏蔽了spriteFrame、Atlas屬性的顯示，這裡已經看不到了。

節點下面再掛接一個Button組件，與之前的SpriteIndex的用法一樣，運行起來效果相同。不過這裡的節點掛載的組件少了一個，使用起來會簡單一些，對策劃、美術同學來說更貼心啦。

可能有程序員同學會懷疑，我是不是被美術、策劃給收買了，盡為他們著想。請相信我這是在為程序員節省時間，將界面編輯的工作交給擅長的人，這樣你就有時間可以去學習更有價值的東西了。

本段介紹了對cc.Sprite組件的擴展，有兩種方式，一種是做輔助，一種是繼承，它們沒有絕對的優缺點，需要根據不同的情景取捨不同的方案。一是實現起來儘可能簡單，二是用起來容易，三是能解決實際問題。

其實我們這裡仍然是在講組件化思維，合格的組件化組件將成為非程序員創作遊戲內容的利器，它也是提高生產力的秘密。我在想以後是不是做代碼審查，美術、策劃也能為程序投上一票呢？

Cocos Creator基礎教程（13）——組件與節點的秘密

有經驗的同學，一上手Cocos Creator就能想到「裝飾模式」，我們看下定義：裝飾模式（Decorator）動態地給一個對象添加一些額外的職責，就增加功能來說，裝飾模式比生成子類更為靈活。

再看一下裝飾模式的基本UML類圖結構 ：

大話設計模式-裝飾模式UML

請注意，上圖是我從《大話設計模式》中截取的，圖中的Component在Cocos Creator對應的是Node，Decorator對應的是Cocos Creator中的Component。那麼我對組件與節點關係的理解就是：組件為節點賦能。

組件為節點賦能

基於Cocos Creator這樣的可視化引擎，組件代碼有著巨大的意義。程序員開發出的組件代碼不應該只是滿足自己完成任務，而應該是為遊戲設計師提供體驗優良的工具，當然你在提供這些組件工具的同時，你的設計水平也在提高。

組件腳本就像是美術生產的圖片、策劃編寫的文案一樣，是遊戲開發中的一項基礎生產資料，遊戲內容更多的是應該由遊戲設計師去完成。

程序不僅僅是編寫組件腳本，還應該向團隊其他人員提供更多的幫助，比如：教他人使用Cocos Creator、教他人使用你編寫的組件、編寫項目輔助工具......目的是用程序的知識、思維和工具，去裝飾身邊的人，給他們提供他們本身不具備的能力，這樣才能更多地發揮程序員的價值。如果程序員平時沒有察覺到開發體驗（各種不爽），做出的產品也很難談的上有用戶體驗。

站在團隊基礎上，為他人賦予能力，將自己當成裝飾品做為組件，去裝飾他人讓節點充分發揮能力，進行人與人之間的組件化協作，這是我最近從Cocos Creator組件化開發收穫的啟發。

作者：張曉衡，奎特爾工作室·cocos遊戲開發工程師。10年開發經驗，擅長cocos H5遊戲開發和管理，技術培訓和團隊建設。

聲明：本文為作者投稿，版權歸對方所有。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！