作者簡介：
　　Christopher Griffith  Blockdot公司高階遊戲開發師，擁有近十年的Flash應用及遊戲開發經驗，客戶包括樂高、微軟、美國航空公司、百事等知名企業。

譯者簡介：
　　李鑫  資深CG動畫講師及插畫師，深度關切遊戲與拉布拉多，喜歡研究小邏輯，最近空閒時在製作原創動畫《瑜的門票》。相信互動式媒體的發展如一切美好事物般會在不經意間抹上眉梢，沿路風景比站臺重要。

評論：
　　“這本書介紹了許多其他書都沒有提到的內容，如事件傳播、E4X、getter/setter方法。另外，作者還指出瞭如何在遊戲開發中避免養成壞習慣。我推薦每一位遊戲開發人員都備一本，它定會讓你受益匪淺。”
“我從1998年就開始用Flash開發遊戲了，看過的相關圖書無數，Christopher的這本書無疑是其中的珍品。書中不但介紹了遊戲開發過程中需要注意的重點事項，而且詳盡闡述了遊戲開發流程，探討了當前流行的一些遊戲設計元素的使用問題。”


內容簡介：
　　Flash因其外掛檔案尺寸小、效能優秀而得到全球網民的青睞，這也使得Flash成為網路休閒遊戲開發的首選平臺。
遊 戲開發融合了很多技術與表現風格，除了要有高質量的程式碼、迷人的藝術設計和良好的使用者介面，很重要的一點是要讓玩家覺得好玩。本書就是要讓讀者利用 Flash設計出這樣的遊戲。從遊戲開發基本術語和概念，到整個遊戲流程的規劃，再到音訊和視覺化資源的管理和遊戲邏輯的處理，乃至一些關於程式碼及庫的組 織方式，本書無所不包。作者以自己近10年的Flash開發經驗為基礎，總結了一些實用的遊戲開發原則。本書最後還介紹了在大型遊戲開發中如何與團隊其他 成員共享資源，以及一些Flash優化方法。
本書配套網站www.flashgamebook.com上提供了書中全部的原始檔，讀者可以借用這些資源來開發自己的產品。

 

作者簡介：
　　Christopher Griffith  Blockdot公司高階遊戲開發師，擁有近十年的Flash應用及遊戲開發經驗，客戶包括樂高、微軟、美國航空公司、百事等知名企業。

譯者簡介：
　　李鑫  資深CG動畫講師及插畫師，深度關切遊戲與拉布拉多，喜歡研究小邏輯，最近空閒時在製作原創動畫《瑜的門票》。相信互動式媒體的發展如一切美好事物般會在不經意間抹上眉梢，沿路風景比站臺重要。

評論：
　　“這本書介紹了許多其他書都沒有提到的內容，如事件傳播、E4X、getter/setter方法。另外，作者還指出瞭如何在遊戲開發中避免養成壞習慣。我推薦每一位遊戲開發人員都備一本，它定會讓你受益匪淺。”
“我從1998年就開始用Flash開發遊戲了，看過的相關圖書無數，Christopher的這本書無疑是其中的珍品。書中不但介紹了遊戲開發過程中需要注意的重點事項，而且詳盡闡述了遊戲開發流程，探討了當前流行的一些遊戲設計元素的使用問題。”


內容簡介：
　　Flash因其外掛檔案尺寸小、效能優秀而得到全球網民的青睞，這也使得Flash成為網路休閒遊戲開發的首選平臺。
遊 戲開發融合了很多技術與表現風格，除了要有高質量的程式碼、迷人的藝術設計和良好的使用者介面，很重要的一點是要讓玩家覺得好玩。本書就是要讓讀者利用 Flash設計出這樣的遊戲。從遊戲開發基本術語和概念，到整個遊戲流程的規劃，再到音訊和視覺化資源的管理和遊戲邏輯的處理，乃至一些關於程式碼及庫的組 織方式，本書無所不包。作者以自己近10年的Flash開發經驗為基礎，總結了一些實用的遊戲開發原則。本書最後還介紹了在大型遊戲開發中如何與團隊其他 成員共享資源，以及一些Flash優化方法。
本書配套網站www.flashgamebook.com上提供了書中全部的原始檔，讀者可以借用這些資源來開發自己的產品。

 

第1章　電腦科學並不適合所有人

1.1　一些基礎知識
　　在深入介紹Flash之前，瞭解一點遊戲開發的基礎知識是很重要的，這樣我們就能理解在本書其餘部分中所使用的術語了。如果以後你忘了某個術語的含義或者不明白它在特定情況下的用法，那就請重新翻開本章。要是你對所有這些長單詞與抽象概念有些不知所措，也請不要擔心！我們得承認，遊戲開發本來就是一項複雜工程（尤其對於高效且熟練的開發而言）。要知道每個編寫遊戲的傢伙都經歷過同樣的焦慮和困惑。如同生活中的任何事情一樣，只有不斷練習並加以實戰才能變得精通。因此，拿起一杯你喜愛的能提神的飲料，讓我們開始遊戲程式設計之旅吧！
1.2　常見遊戲型別
　　儘管有許多不同型別的遊戲（有些自身無法被簡單歸類的遊戲甚至還以此為榮），但多數遊戲卻可被歸為下列類別之一。
1.2.1　冒險類遊戲
　　冒險類遊戲（見圖1-1）通常是由背景故事為導向而展開的，並且一般會有一個或多個主角。從玩家感覺上來說，玩這些遊戲和看電影最為相像（有些遊戲據說已經快要拍成電影了），它們大量依靠劇情對白、搜尋探險以及解決邏輯謎題來推動玩家的遊戲程式。在20世紀80年代末與90年代初，冒險類遊戲非常流行，其中LucasArts公司和Sierra（雪樂山）公司都出品過一些堪稱絕佳典範的冒險類遊戲。由於其開發流程非常依賴美術基本功，並且通常對系統配置的要求也較低，用Flash製作的這類遊戲又開始流行起來。
1.2.2　動作類遊戲
　　此類遊戲（見圖1-2）可能會涉及許多遊戲玩法以及子類別，但就一般而言，動作類遊戲考驗的是一個玩家的機敏程度、反應時間以及在面臨壓力時頭腦是否靈活。第一人稱射擊遊戲、橫向與縱向滾軸遊戲及格鬥遊戲都可歸入動作類遊戲。Flash平臺可以很好地支援動作類遊戲中的一些子類別，特別是那種年代較早的動作類遊戲，比如像《太空入侵者》或《超級馬里奧兄弟》那樣的遊戲。
 
1.2.3　益智解謎類遊戲
　　想想《俄羅斯方塊》、《寶石迷陣》（Bejewled）還有《數獨酷》（Sudoku）吧！像這樣的遊戲還可以列出很多。凡是涉及邏輯推理、解謎、圖案匹配，或者包含以上所有這些構成元素的作品都可歸入此類遊戲。這類Flash遊戲很多，原因主要有以下兩方面。首先，創作一款簡單的益智解謎類遊戲所需要的美術工作一般較少，這意味著獨立開發者經常靠自己就可以將其製作完成。另外，網上主要的休閒遊戲玩家年齡都偏大，他們一般比較喜歡節奏慢些的益智解謎類遊戲。
1.2.4　詞彙類遊戲
　　這類遊戲可被認為是益智解謎類遊戲的一個子類，但是建立方法卻大為不同，所以我將它們劃為獨立的體系。尋找單詞、縱橫拼字迷、拼字遊戲以及迴文構詞 ，都屬於此類遊戲的範疇（見圖1-3）。基於和其他益智解謎類遊戲相同的原因，Flash平臺是此類遊戲的最常見載體。
1.2.5　策略與模擬經營類遊戲
    我承認，把這兩類遊戲歸併為一類確實有偷懶之嫌。但這兩者有一些共同點。策略類遊戲一般需要精心籌劃、資源管理以及決策制定，比如說規劃一個城市，或者組建一支龐大的軍隊。策略類遊戲與模擬經營類遊戲的區別經常可用玩家需要維持的遊戲元素細節程度來界定。有些遊戲會非常複雜，以至於要想進行巨集觀管理，玩家可能就要用到遊戲提供的全部選項。而更多休閒型策略類遊戲（比如像用Flash建立的多數策略類遊戲）則採用一些措施來簡化遊戲玩法，比如通過削減可用選項以及只關注一些主要任務。塔防類遊戲可算是休閒型策略類遊戲的一個常見特例。在這種遊戲中，玩家要策略地擺放各種不同的武器來阻止敵人通過防線。見圖1-4。
1.2.6　角色扮演遊戲
    角色扮演遊戲（RPG）類似於冒險類遊戲，但通常對主角在遊戲故事程式中不斷成長的歷程描述得更多。傳統上，RPG遊戲都發生在幻想設定的故事背景中，並且它注重於玩家統計資料的進展，比如力量、智力或敏捷這樣可增長的角色特性引數。近來最流行的RPG遊戲是大型多人線上RPG遊戲（也叫作MMORPG），玩家可以在這種遊戲中通過相互間的對抗或合作來使角色成長。由於網站社會化與網頁載體的需求，一些由Flash構建的MMORPG遊戲也開始嶄露頭角。但由於這類遊戲通常耗資巨大並且開發週期很長，遊戲廠商在開發時尚且要冒更多的風險，對於獨立開發者來說則更不可行。
1.2.7　駕駛類遊戲
    顧名思義，這類遊戲都會讓玩家操控某種交通工具，這些交通工具可能會在陸地上行駛，可能是在水域中航行，或者也可能在天空與太空中飛行。為了獲取真實效果，這些遊戲通常會以第一人稱或第三人稱視角來進行。由於系統配置需求以及在Flash中搭建全三維（3D）環境的複雜性，多數此類遊戲一般都採用二維視角。
1.2.8　桌面式和卡牌式遊戲
　　這種型別的遊戲通常是現實世界此類遊戲的數字式呈現，比如國際象棋、國際跳棋、二十一點和德州撲克（見圖1-5）。 因為系統配置需求較低，所以Flash平臺極為適合建立大多數桌面式和卡牌式遊戲，關於這點，網上大量存在的賭場式遊戲站點可為之佐證。
1.3　常用開發術語
　　電腦科學這個領域很深奧，絕對不適合那些只想做遊戲的人。但瞭解一些基本的核心概念與程式設計知識有助於我們以後對遊戲的逐層分析。確實，它不僅枯燥，而且偶爾會顯得很乏味，但我可以向你保證，理解了這些內容之後，好玩的東西多著呢！
1.3.1　偽碼
　　偽碼只不過是用標準語言對一系列程式設計步驟所作的解釋，有點像是一種邏輯總結。你以後就會看到，在本書的一些例子中，我會在編寫實際的ActionScript程式之前先用偽碼來分解遊戲邏輯。因為偽碼容易緊扣程式設計語法並忽略邏輯缺陷，所以在將問題付諸實際程式碼之前，我們先用英語來對它們的邏輯進行拆分，這樣做幾乎總能使問題的處理變得更為簡單。我所用的函式和屬性的名稱大多來源於我寫的偽碼。
1.3.2　演算法
　　演算法就是定義了問題解決方式的一系列指令與判斷。它們不是程式碼或特定語言，因此用直白的英語來表述會較易理解。例如在一個程式裡，我們要按照單詞的長度來對它們進行排序，演算法可能會跟程式的處理過程一樣簡單。下面就是用偽碼寫出的演算法：
for all in wordlist
  sort by length
sort by length (word A, word B)
  if A.length > B.length
    return B
  else
    return A
1.3.3　程式式程式設計
　　許多早期的程式語言如（Basic或Pascal）都被稱作過程式語言。程式式程式設計可被抽象理解為編寫一系列任務（或者叫作子程式）的過程。這些子程式的執行次序是隨意的，但所有命令都是由一個主邏輯控制語句來驅動，有時我們也把它叫作主迴圈語句。本書的範例將會融合程式式程式設計技術與下面我們將介紹的物件導向程式設計技術。
1.3.4　物件導向程式設計
　　程式式程式設計關注的是一組待解決的任務，然而物件導向程式設計（OOP）則專注於“物件”間的互動。OOP是一個非常複雜的課題，你可能很難全面理解它，但現在你只需知道的是：每個物件都是一個獨立實體，它能夠定義屬性，傳送與接收從其他物件傳遞來的訊息，以及處理自身內部邏輯。例如，在OOP中，一個人可以是一個物件，而他的一個朋友則是另一個物件。他們共享一些元件，他們都是人，但也都有各自唯一的特徵。而且他們彼此間會使用一種通用語言來傳遞訊息進行交流。ActionScript的有些方面是以OOP的方式運作的，我們稍後會在書中予以詳述。
1.3.5　設計模式
　　目前談論較多的是關於軟體工程中的設計模式。關於這一課題有很多冗長的解釋，並且還可以用一整套的理論專著來予以闡述。就本書而言，你只需把設計模式看成一種程式碼模板即可。它是你編寫程式碼構建遊戲時所用的藍圖，特別對於物件導向程式設計來說更是如此。在遊戲業界內有很多公認的設計模式，有些模式對於Flash遊戲開發非常有效，而有些則根本不適用。我會在第12章介紹我所發現的最有效的Flash遊戲開發設計模式及其實現方法。
1.3.6　類
　　在OOP中，類是充當物件基本單元的一種程式碼。你可以將其理解為一種模板，程式中使用的所有物件都衍生自這種模板。類定義了物件的所有屬性與函式（也被稱作方法）。在Flash程式設計中，類的使用是很重要的，主要原因如下。首先，在你定義類時，需要更多地考慮遊戲的構建方式。這是件好事，沒有清晰描繪的藍圖將導致日後開發中的盲目猜測與重複勞動。如果木工要蓋房子，而建築師除了一張草圖外什麼規劃也沒有給，那麼這房子可能就沒法蓋，或許他就只能在建造過程中不斷靠“拍腦門兒”來解決問題，這樣蓋出的房子會非常不牢靠，它沒準就根本不能住人。以後我會詳細介紹類結構的知識，因為大多數遊戲開發都要使用類。下面列出了一個簡單的類，我們用它來定義遊戲角色。
package {
  import flash.display.MovieClip;
  public class Player extends MovieClip {
    public const jumpHeight:Number=10; //畫素
    public const speed:Number=15; //每秒畫素

    public var health:Number=100;//百分比
    public var ammo:int=20;//單元

    public function Player() {
      //初始化
    }
  }
}
　　此刻你不一定能理解全部程式碼，但是我希望你能看出這裡定義的是一個玩家角色，它帶有預定義的角色跳躍高度與移動速度，並且包含了用於表示角色生命值與護甲值的變數。當然，僅靠這點程式碼無法實現任何功能，但這畢竟為建立更多功能與特性建立了一個基礎。
1.3.7　Public、Protected、Private和Internal
　　這4種字首符（也稱作類成員屬性）可以放在類中的屬性和方法之前，它們是用來界定一個類中何種專案可被其他類訪問的。關於它們的用法，Flash的幫助文件裡全都有，不過這裡讓我們簡要總結一下。
    Public（公共）方法與變數可從任何位置訪問，它們是類與類互動功能的基石；當一個類擴充套件（extend）自另一個類時，被擴充套件類的所有公共方法與變數也就一起被繼承下來。
    Protected（受保護）方法與變數只能從其所屬類內部訪問，它們能夠被繼承。
    Private（私有）方法與變數只能從其所屬類內部訪問，它們不能被繼承。
    Internal（同一包內部）方法與變數能夠被其所屬包內的所有類訪問到。
技術隨筆
　　還有一種稱作static（靜態）的類成員屬性，它能與以上列出的其餘4種類成員屬性中的任何一種共同使用。當一種方法或變數為靜態時，它就只會有一個副本，並且可以通過類來直接訪問，而無需建立類的物件。換句話說，Game類的靜態屬性version可以被這樣訪問：Game.version。如果你試圖從Game類的一個例項來訪問它就會出錯。
1.4　遊戲特有的開發術語
　　現在繼續介紹一些更有趣的開發術語。我們會在隨後章節中直接將本節介紹的概念用於建立遊戲。
1.4.1　人工智慧
　　人工智慧（AI）一般指的是程式制定的一套用來模擬人類決策方式的邏輯決策。AI可能會很簡單（就像在接球遊戲中讓計算機一方朝球移動球拍那樣），但也許會非常複雜（像《光暈2》中那樣，使敵方在感知危險時能夠閃避尋找掩護並作出相應的反應）。對於本書而言，由於Flash無法用別的方式來處理，相對來說我們開發的多數AI都不是很複雜。
1.4.2　遊戲迴圈（或者說“主迴圈”）
　　該術語通常指的是根據輸入、AI或其他一些主觀邏輯來確定遊戲下一階段行為的主要程式碼段。它的任務只是呼叫其他一些邏輯函式，並核查某種條件是否已滿足（比如說玩家是否已經勝利）。
　　下面的範例是某個遊戲中的一個簡單主迴圈的偽碼：
on enter frame
  move player
  move enemies
  check for collisions
  check for win or lose
　　在像C這樣的程式語言中，主迴圈確實是一種程式碼迴圈（如while迴圈或for迴圈），只有當滿足某種條件時它才執行。主迴圈有時也被稱作狀態機（state machine），因為這種邏輯能確定遊戲所處的“狀態”（遊戲開始前、遊戲進行中以及遊戲結束後等狀態），並且會執行相應的函式。而在ActionScript中，你卻必須要以不同方式來建立主迴圈，因為週期性的程式碼迴圈會將Flash Player一直鎖死到遊戲結束。由於Flash原本是一款動畫製作軟體，它的工作方式離不開幀，這點和電影很相像。Flash可以定義幀速率或者說每秒幀數。每經過一幀，Flash都會更新螢幕，此時非常適宜執行遊戲邏輯。這對於慣用其他程式語言的開發者來說似乎有點彆扭，但人們很快就能習慣它。我以後再討論遊戲迴圈，因為它們是遊戲程式碼的驅動力。
1.4.3　遊戲視角
　　我們能用多種視角來表現遊戲，遊戲型別一般就決定了它所採用的視角，但也未必。很多現代動作遊戲都採用第一人稱或第三人稱視角，這使你能以角色本人的視角或者以角色身後的視角來觀察遊戲世界。而休閒型動作與冒險類遊戲更多會採用側視角。其他型別遊戲（如策略類或競速類遊戲）可能會採用從上方來檢視遊戲動作的視角。遊戲是否引人入勝並好玩跟你所選用的視角有部分關係。動作類遊戲往往需要角色快速運動，並且有大量的障礙，如果採用鳥瞰檢視，遊戲就會變得既困難又乏味；但假使採用第一人稱視角，那麼隨之而來的實時且強烈的視覺感受就將打消玩家的不信服感。有些遊戲視角要比其他遊戲視角更適合在Flash遊戲中使用。由於受到Flash技術效能所限，多數包含3D環境的視角都不適用於Flash遊戲，但以後我會向你介紹一些令人信服的模擬3D效果的竅門與技術。
1.4.4　捲動背景
　　通常遊戲的背景都會超出遊戲的可視範圍。比如在《超級馬里奧兄弟》這款遊戲中，背景延伸了一定距離，但你每次只能看到一小部分的背景。因此，遊戲會水平地前後捲動背景影像，這使得玩家角色保持在主要的可視區域內。這種效果既可水平使用也可垂直使用，比如說可以用在駕駛類遊戲或策略類遊戲中。
　　有一種技術可以使卷軸遊戲環境更具有深度感和3D觀感，那就是讓不同的環境層以不同的速度捲動。這種技術被稱作視差卷軸法。它與真實世界很類似，出現在遠處的物體（比如像山脈或建築）的移動速度要比在前景中的物體慢。我們在第6章會詳細介紹一個側卷軸動畫的範例。
1.4.5　區塊式遊戲
　　一些遊戲環境可以被分解為一個個網格，比如像迷宮類遊戲或策略類遊戲。那麼就可用一些尺寸預定的區塊來建立遊戲的藝術形象。儘管在程式設計最後階段需要做更多的工作來開發一種有效的區塊對映系統，但遊戲卻能建立關卡編輯器，終端使用者可以用它來建立自定義地圖。《星際爭霸》與《魔獸爭霸》這兩款遊戲中的地圖編輯器的區塊系統就做得非常出色。我們將在第10章介紹一個區塊式遊戲引擎。
1.5　Flash程式開發術語
　　在結束本章內容之前，我再介紹幾個本書會不斷提到的術語。要想以後建立出良好的遊戲程式程式碼，關鍵就是要理解每個術語的內涵。在第4章中我們會更加深入地研究這些概念，目前先簡要概述一下。
1.5.1　舞臺
　　在Flash中，舞臺就是主要的創作內容區，所有的東西都建於其上。所有其他的視覺化物件一旦被新增進舞臺就會位於舞臺的頂層。你可把舞臺看成遊戲的畫布。
1.5.2　顯示物件
　　顯示物件就是物件的視覺化表現形式，它們可以被放置到舞臺中。在Flash中有很多不同型別的顯示物件；對有經驗的開發者來說最熟悉的就是按鈕、Sprite物件及影片剪輯了。甚至舞臺本身就是一種特殊的顯示物件。顯示物件有很多共同點；它們都有一個在螢幕上的x、y和z座標位置，同時也有縮放與旋轉屬性。在任何一個特定時間，Flash都維持著螢幕上所有顯示物件的列表，這使得人們可以很方便地去訪問與操控這些顯示物件。
1.5.3　事件和偵聽器
　　事件是在ActionScript 3中物件間通訊的主要方式。它們就是Flash中的物件廣播或者分發的訊息。任何設定好偵聽這些訊息的物件都會接收到事件。這些事件可能是關於使用者輸入的通知，也可能是關於所載入的外部資料的資訊等。Flash有很多處理常見任務的內建事件，並且也完全有可能（也鼓勵這樣做）為自定義物件（比如像遊戲）建立新的事件。事件可以包含任何與事件型別相符的資料，所有事件都含有以下一些基本屬性：
    名稱或型別
    目標——分發事件的物件
    當前目標——當前偵聽或處理事件的物件
　　事件是一種非常強大的工具，後續章節中將會大量地用到。
1.5.4　包
包就是一種類與函式的集合，用於管理類與函式。因為Flash中內建有很多不同的類（更不要說所有那些我們將要建立的類了），所以最好將它們歸入一個邏輯集合中。例如，在Flash中直接處理顯示物件的所有類都在一個叫作flash.display的包中。所有的事件都存在於flash.events包中。包的標準命名規範是全部字母為小寫。如果要在一個特定的包中使用類，我們要使用import命令來訪問它們。
package mypackage { 
  import flash.display.MovieClip;
  public class MyClass() extends MovieClip {
  }
}
1.5.5　創作時事件、編譯時事件及執行時事件
　　這些術語指的就是改變或檢查Flash資料的不同階段。本書中將介紹一些發生在Flash創作環境內的事情，這指的就是創作時事件。在Flash建立SWF檔案的過程中發生的事件或錯誤被稱為編譯時事件。最後，一旦SWF開始執行，執行時事件就會發生。
1.6　醒一醒
　　喔，本章到此為止！雖然你可能不會完全理解這裡所講的概念，但你會在後面章節中逐漸接觸到它們，隨後就能慢慢地明白了。想想看，你很快就能在閒聊中蹦出一兩個像“多型”這樣的詞兒，聽起來你就像是一位成熟老到的……呃……軟體工程師了。

第5章 管理資源與使用影像

　　儘管程式碼是多數遊戲中的重點部分，但一般來說程式碼所操控的資源（繪製的影像、聲音以及文字）同樣也很重要。大多數程式語言都將資源放入單獨的檔案與程式碼分開，而每個Flash檔案都連線著一個庫，庫中包含了在編譯時要歸併入SWF檔案的所有資源。一旦將資源匯入庫中，除非要對它進行更新，否則就不再需要外部的資原始檔了。由於大多數情況下Flash只需使用FLA檔案即可，所以開發者們能更容易地訪問資源。你當然可以建立一個全部由程式碼組成的SWF檔案，並且在執行時載入進它所需的全部資源，但這卻有悖於Flash的自身特點，並且這樣做幾乎在任何情況下都會得不償失。另外，Flash能為資源新增額外的壓縮層，而由外部訪問資原始檔卻達不到這一點，這就意味著包含全部所需資源的單個SWF檔案要比所有單獨的資原始檔合起來的尺寸小。在本章餘下部分中，我將為你介紹各式各樣的資源，在開發Flash遊戲時需要知道如何利用這些資源。
　　在本章中，我將持續關注資原始檔的尺寸。在一些Flash開發者圈子中，人們一般認為最關鍵的是最終產品，也即最終SWF檔案的尺寸。我看到過很多FLA原始檔大約有30 MB到50 MB那麼大，那還是相對比較簡單的遊戲。這就有問題了，原因有以下幾點。其一，如果你每次都使用一定型別的備份或版本控制系統，那麼新版本就會佔據相當多的空間。更重要的是，Flash樂於接受稍小的、記憶體佔用較少的FLA檔案，這樣就遠不會造成當機或崩潰，你只需在開發過程中定期地執行“儲存並壓縮”操作即可（見圖5-1）。如果在Flash中改動了資源（新增、更新以及刪除），Flash就會儲存一個歷史記錄，以便你能儘可能地取消這些行為。久而久之，這些“供取消的備份”就會使檔案體積增大，因為它們儲存了在幾次重複操作之前業已從庫中刪除的資源。“儲存並壓縮”操作會檢查FLA檔案，然後清除所有的取消行為資料。我曾見過有的庫檔案在執行完該操作之後，其尺寸立刻下降了75%，原因僅僅在於原先的庫檔案儲存了太多版本所遺留下來的歷史記錄。注意，假如你用的版本控制系統在每次儲存時都儲存為一個新檔案並且遞增檔名（而不是我推薦的檔名），那麼當選擇“另存為”操作時，Flash就會自動壓縮檔案。
5.1　小議組織庫元件
　　如果久做Flash開發，你可能時常會需要開啟別人的FLA檔案。我發現不同開發者庫的組織方式很少能夠保持一致。有那麼一段時間，大家流行按照型別來排列庫中的資源，所以會出現標明為MovieClip、Buttons以及Bitmaps等的資料夾。有些人則喜歡按照用途來排序，圖5-2就展現出這種資料夾結構。
　　你一定要記住這一點：有組織性就總比沒有強，你所使用的最佳結構總是要由專案的複雜性來決定。我通常將前述兩種方法混合起來使用。我會將視覺化資源（影片剪輯、影像、視訊）按照用途來分類，然後在其相應的資料夾下又按照型別來排序。另外對於像聲音或字型元件這樣的資源，我完全按照型別來排序。這樣做的理由在於，你終於能在Flash CS4中編輯多個同型別元件的屬性了，而將這些庫元件彼此相鄰地放置就會更易選取它們。
5.2　使用影像
　　現在已遠非《乓》遊戲時代，遊戲質量的門檻已經提高了。遊戲都要具有漂亮美觀的影像以及自然流暢的動畫才行，Flash遊戲也不例外。我將在本節中簡要地介紹一下最佳遊戲影像格式以及動畫時間軸的用法。我不會談論有關影像繪製方面的內容，原因如下。首先，我不是藝術家。其次，因為Flash遊戲已經變得越來越精良了，單憑一個人很難在遊戲開發中包攬程式設計與美工這兩個角色。不過，如果你是獨立開發者，或者你對Flash遊戲的影像設計感興趣，我建議你去讀讀Robert Firebaugh編寫的Flash Professional 8 Game Graphics一書。雖然它所講解的內容已經滯後了幾個Flash版本，但對於學習如何繪製Flash所用的高效能影像來說，該書依然很有價值。
　　Flash CS4既支援向量圖又支援光柵影像（點陣圖）。在遊戲開發中這兩種格式各有其優缺點。向量影像能夠調整大小，不會造成任何質量損失，檔案尺寸也比光柵影像要小得多，而且你能在時間軸上利用它們建立出非常流暢的專業級卡通動畫（前提是不在乎所耗費的時間）。然而，大量的向量影像或由向量影像構建的大型物件會對CPU造成沉重的負擔。雖然可以通過Adobe Illustrator這樣的創作工具來完成，但我們一般最好直接在Flash中建立向量影像，因為Flash會自動在繪製向量圖中使用盡量少的點來對其進行優化。而對於Illustrator這樣的設計軟體來說，它看重的是準確性以及完美的畫素質量，而非向量優化，這就將導致最終繪製的向量圖異常複雜，以至於將其匯入到Flash後我們還需要做很多的清理工作。如果你正在開發的專案使用的全都是向量影像，那麼構成向量影像的點越少，渲染速度就會越快，檔案尺寸也會越小。
　　幾乎人人都熟悉並使用過光柵影像，至少也用它們設定過電腦桌面。光柵影像有向量影像所不具備的一些優點。首先，它們能提供照片級真實感，而這得需要非常複雜的向量圖形才能辦到。許多不同的影像設計軟體（包括多數3D軟體）都能夠渲染出影像，然而只有幾個軟體能夠生成為Flash所相容的向量影像。另外，將光柵影像渲染到螢幕上所需的運算量也要少得多，因為Flash會將其與一個向量長方形以同等複雜度對待。但光柵影像也並非完美無缺。當畫素增加時，光柵影像的檔案大小會急劇呈指數級增加，並且在Flash中不可能做到質量無損地調整光柵影像的大小。另外，在Flash中渲染透明影像要比渲染不透明影像更耗費運算資源。
　　這時，你可能會說：“既然這兩種方案都不完美，那我該用哪一種呢？”就跟選擇如何組織庫元件的方法一樣，它一般要由具體專案來決定。能夠用於所有情況的唯一正確選擇是不存在的，我在工作中很少只用到其中一種方案。即便如此，在遊戲開發中，我還是更偏重於使用光柵影像而非向量影像。很多遊戲都需要在螢幕上快速地渲染出遊戲物件，這才能讓玩家有一種淋漓酣暢的遊戲體驗，而如果使用帶有大量細節的向量影像，則會因為渲染太慢而無法達到這一點。通常在我參與開發的遊戲中，美術設計部分的80%是由光柵影像來實現的，而向量影像則會佔到20%。遊戲角色、背景、粒子效果等全都是由光柵影像來完成的，而選單、遊戲內的各種顯示介面與文字則都是由向量影像來完成的。
5.3　常用的光柵影像格式
　　Flash常用的兩種最佳的光柵影像格式是JPEG與PNG。當影像不需要有任何透明部分時，用JPEG就很不錯，因為你可通過外部程式如Photoshop來處理影像，而這要比在Flash內部處理具有更低的壓縮率及更好的影像質量。由於它們缺少透明通道，所以也會降低Flash渲染器的開銷。而當你需要影像的透明通道時，PNG格式則是不二之選，但其檔案尺寸及所佔用的運算能力也會變大。
　　多數專案會混合使用這兩種格式。任何資源，只要其可以作為一個矩形形狀來使用，並且不包含任何透明通道，那麼就對其使用JPEG格式吧（見圖5-3和圖5-5）。這樣的資源包括以下幾種。
    遊戲與選單介面的背景。
    在點陣圖填充中被用作材質的影像。
    遮罩形狀所覆蓋的影像。
    在遊戲中用作某種影像特效的覆蓋層，比如靜電干擾或無線電干擾效果。
　　行動式網路影像（PNG）（見圖5-4和圖5-6）是表現空白透明效果的不二之選，且更適用於表現較小的遊戲元素，這些元素包括以下幾種。
    遊戲角色，特別是那些運動角色。
    需要與背景分離的遊戲內元素。
    使用者介面元素，比如按鈕及其他不規則形狀。
    有著細緻邊線的影像，這種影像需要達到畫素完美（pixel-perfect）的精確性（JPEG有變模糊的傾向，或者說影像的畫素細節很模糊）。

　　技術隨筆：帶有透明通道的8位PNG
　　PNG影像分為兩種——32位（包含1600萬色並帶有一個完整的8位透明通道）與8位（256色）。有一點似乎不為人所知，那就是Adobe Fireworks能夠生成一種特殊的PNG影像，它帶有一個8位顏色通道與一個8位透明通道（有時也被稱為PNG8+8）。如果你想使用一種顏色相當少的影像，或者說是一種減少顏色數目也不會降低太多品質的影像，那麼選用這種格式就很不錯。儘管這會使檔案尺寸減少一多半，但它卻能使影像保持細緻清晰的邊界與透明效果，而這就多虧了其準確的透明通道。事實上，這種格式的影像尺寸往往會比Flash內部生成的經壓縮的32位PNG影像尺寸還要小，其最終影像也更為美觀。這種格式可望最終會出現在Photoshop的“儲存為Web格式”功能中。不過在此之前，可以一直用Fireworks將32位PNG影像批處理為8位PNG影像（見圖5-7）。
    當然這些僅是參考，並非硬性規定，但如果組合使用預先考慮好檔案尺寸的格式，則會在優化階段節省大量的時間。有關光柵影像的另一方面問題是Flash在編譯遊戲時會如何處理它們。Flash有幾個不同的影像匯出選項，遊戲的觀感取決於此。在庫中只需雙擊一幅影像即可檢視它的屬性。你也可以同時選擇多個影像（CS4中的新功能）並同時調整所有影像的屬性（圖5-8）。
　　圖5-8　你可通過“點陣圖屬性”皮膚來調整一幅特定影像或多個影像的屬性
5.3.1　壓縮
　　當你匯入一個已經用另一程式優化過的JPEG檔案時，Flash預設情況下會照其原樣來使用它。PNG影像卻不一樣。如果影像是256色或更少的顏色，Flash會自動將其降低為8位的PNG檔案，檔案尺寸立刻降低，然而其品質無損（也稱為無失真壓縮）。如果影像包含的顏色超出了256色，Flash就會在編譯該檔案時將其轉為Flash所自有的JPEG壓縮格式。壓縮率可以在文件中通過“釋出設定”來進行控制（預設為80%）（見圖5-9），並且這是針對每個影像進行壓縮的。對於一段時間內在螢幕上保持靜止的一些影像來說，我建議將壓縮率設定為70%~80%，這樣可保證其品質不會降低太多。而對於用在快速運動的動畫序列中的影像，比如角色動畫，我建議將其壓縮率降低為50%，因為你根本注意不到由此產生的品質下降。事實上，當每秒30幀時，人眼是察覺不到足夠多細節的，JPEG經壓縮後形成的自然模糊效果就會帶來良好的運動模糊感覺。永遠不要使影像壓縮率超過90%，除非要將遊戲顯示到一個解析度極高的顯示器上，而且你可能判斷不出由此造成的品質差異，但檔案尺寸卻會飆升。
5.3.2　平滑
　　預設情況下，當你在舞臺上對影像施加任何方式的形變時（包括傾斜、縮放甚至旋轉——以任何不能被90整除的角度進行旋轉），Flash都不會重新渲染它們。由此導致在運動較慢的影像上產生很明顯的鋸齒塊狀效果。如果遊戲需要時不時地旋轉一些影像或調整其尺寸，那麼你可以考慮在它們的“點陣圖屬性”（Bitmap Properties）皮膚中選中“允許平滑”（Allow Smoothing）選項（見圖5-10）。儘管這樣做後影像看上去邊緣更為平滑，但確實會更耗費計算資源，所以要少用這個選項。如果遊戲在以後測試時開始變得遲滯，就要考慮在一些影像中禁止使用這個選項。
5.3.3　解塊
　　這是CS4中的新功能。當你啟用瞭解塊功能後，它能對那些JPEG品質被設得極低（如被設為30或更低）的影像使用一些額外的平滑操作以改善影像品質。除非所用影像被極度壓縮，否則你可能根本不會用到這個功能。
5.3.4　外部的影像編輯工具
　　與我共事的美工通常會使用Adobe Photoshop與Adobe Fireworks來建立遊戲的光柵影像。這兩種軟體能將JPEG壓縮得極好，並且能使生成的PNG檔案十分整潔。如果因預算有限而買不起Photoshop（或不需要其所有高階功能），那麼你可選用Fireworks，它會讓你十分滿意的。截至本書寫作時，它的價格是300美元。
　　關於向量影像，我曾認識幾個美工，他們能用Flash中的工具做出非常好的向量效果。在Flash中建立向量影像不需要額外任何工具，向量影像在建立時就能被自動優化。另外，Fireworks有一套非常好的向量工具，它能將做好的向量影像輕鬆地匯入到Flash中。多年來，我也曾跟一些喜歡用Adobe Illustrator的美工一起工作過，但我發現對於大多數遊戲所需的影像細節程度而言，Illustrator確實有點大材小用。另外，用其做出的效果（如複雜的混合與漸變效果）並不都能很好地轉化到Flash中。
5.4　要點
　　在編輯大量遊戲影像時，它們很容易就會亂套，不僅混亂無序，而且檔案大小也不理想。所以你要記住以下幾點。
    要在整個開發過程中密切關注影像。
    在庫中用資料夾來組織影像。
    檔案系統中的影像要有條理，以便能在Flash中“更新”影像，這樣你就不會在影像發生了任何改變時不得不再將其全部重新匯入。
    寧可讓影像的尺寸與檔案尺寸更小一些，特別是對於製作全幀速率（full-frame-rate）動畫來說。
　　想想吧，若是直到最後時刻你才急忙降低所有影像的JPEG壓縮率，將檔案尺寸縮減，遊戲往往會變成一團糟。相比之下，一絲不苟地預先對影像進行優化就要好得多。最終，你不懈的努力也會帶來圓滿的回報。