《游戏开发策划》word版.doc

遊戲的開發無情公子一、造個什麼遊戲造一個什麼樣的遊戲？如果叫您來答，您會答什麼？是角色扮演還是即時戰略？對於廣大遊戲編程愛好者來說，答案肯定會是角色扮演。那麼，我們要造一個什麼樣的角色扮演型遊戲呢？相信這個問題也是毋庸質疑的，大家肯定都會說：“仙劍式”。的確，仙劍奇俠傳自1995年出世以來，在遊戲界中已經成了一個不敗的神話。我們也許會問：“誰來打破這個神話呢？”我的答案是：“我們！由我們廣大的遊戲愛好者來打破。”我和一群同學創立了絕情電腦遊戲創作群，從1997年6月開始致力於電腦遊戲的製作。我想，正在看這篇文章的您，也許您和我們的“同行”吧？ 再問：“打破這個神話要怎麼做呢？”首先，我們需要一批工作人員，造一個遊戲至少需要以下工作人員：策劃：負責對遊戲製作進行策劃指導。編劇：負責遊戲的劇本編寫。人物設計：設計遊戲中的人物形像。場景設計：對遊戲中的地圖、場景、物品進行設計製作。電腦美工：將設計好的所有圖片輸入電腦。動畫設計：設計遊戲中的各種動畫，包括片頭、片尾等。招式設計：根據劇本設計戰鬥人員的各種招式、法術。程式設計：負責對遊戲中的各種程式進行編寫。地圖製作：用設計好的地圖編輯器製作遊戲中所使用的地圖。 腳本製作：根據劇本對遊戲情節資料進行編寫。聲音製作：錄製遊戲中所使用的各種音樂及音效。測試：對製作好的遊戲進行各種測試工作。宣傳發行：對測試完成後的遊戲進行宣傳與發行工作。可以找代理。這些工作，可以適當的進行兼職。比如策劃與程式設計兼職，可別兼職太多哦！二、遊戲策劃 策劃，是一個遊戲創作群(小組、工作室)的總指揮。他將負責整個遊戲的具體安排工作，比如開發環境、遊戲運行條件、遊戲風格、等等工作。要製作一個合格的遊戲，如果沒有一個好的策劃，那麼這個遊戲可能很難做成。不過一般的小創作群都是策劃兼程式設計的，比如我就是。那麼策劃要做些什麼呢？確定運行遊戲的作業系統。各種作業系統的優缺點見下表：作業系統 優點 缺點 推薦編程語言 DOS系列 直接控制硬體、速度快、編程方便。 對於一些多媒體設備，需要自己製作驅動程式。（顯卡按VESA，音效卡按SB16進行編程即可解決此問題） WatcomC/C+11.0或更高 Windows3.x Windows9x 編程與硬體無關，多媒體控制方便。 速度慢，消息式編程不方便，無法直接控制硬體進行快速處理。DirectX太複雜，太慢。 Visual C/C+、Borland C/C+ OS/2 同Windows9x差不多LinuX系列 網路操作方便，可直接控制硬體、速度快 缺少軟體支援，遊戲程式源代碼開放 情況不明。 UNIX系列 如果你選UNIX，我推薦你換LinuXMacOS 可以直接控制硬體、編程與硬體無關、可以很方便的控制各種多媒體設備 必須使用Mac系列電腦 FC-OS 日本任天堂公司的家用遊戲機平臺，編程使用組合語言。 SEGA-OS 日本世嘉公司的家用遊戲機平臺，在電腦上使用專門的編程工具進行製作。 PS-OS 日本索尼公司的家用遊戲機平臺。本站無詳細資料。 CPS-OS CAPCOM公司的街機運行平臺(大明鼎鼎的街霸便出生於此)。本站無詳細資料。 NEO-GEO 日本SNK公司的家用遊戲機與街機運行平臺。本站無詳細資料。 有一點請大家注意：不要把遊戲的運行機型設的太高。因為現在還不是人人都用Pentium加Vodoo的時代。順便提一句：絕大多數據的電腦玩家很少去理會遊戲運行在什麼作業系統下，千萬不要認為DOS版的遊戲就沒有人玩了。俠客英雄傳3和江湖任我行不就運行在DOS下嗎！。確定遊戲的畫面清晰度。我們將使用標準VGA即可實現的清晰度稱為低清晰度；需要SVGA才能實現的清晰度稱為高清晰度。畫面清晰度見下表： 低清晰度 高清晰度 解析度 300x200x256、640x480x16等 640x480x256、640x480x65536等 代表作 仙劍奇俠傳 風雲 優點 資料量少、不分頁。顯示標準統一。動畫速度快、可實現多層卷軸動畫。用來做遊戲中的片頭、片尾動畫是再好不過的了。 畫面效果好、視角範圍大。 缺點 非動畫的畫面效果很難做好，鋸齒明顯 資料量太大，顯存要分頁操作，速度慢。如果不使用VESA則需為每一種顯卡編寫一種驅動程式。 現在來看，如果要製作一個商業化的遊戲，選擇低清晰度是不行的。最低也得是640x480x256色才行。若是編程人員能力不夠的話，選擇低清晰度也是未嘗不可的。比如造一個“街霸”，就可以選擇320x200x256色的清晰度。如果選擇256色的清晰度，就必須調配一個超級調色板(站長調配了一個，可供下載。1851位元組)，以適應各種複雜的圖片。如果您的編程人員有能力的話，可以選擇65536色的清晰度。因為65536色是直接向顯存送三原色，可以表現任何顏色。不過編程人員要處理的的資料量比256色大了一倍，顯示速度也就只有256色的一半了。在下自1997年7月以來，一直致力於一個角色扮演型遊戲的製作。採用的畫面清晰度是800x600x65536色，效果好到極點，速度比 Windows9x下的DirectX還快，放動畫每秒種可達42.7幀(酷吧！在下的機型只不過是AMD K5-PR133、記憶體40、PCI顯卡1MB顯存、無3D加速卡)。當然就全靠我的Watcom C+版超級圖形加速引擎，有興趣一同製作遊戲的朋友們可以與我聯繫。確定遊戲的畫面視角。見下表：視角 代表作 適用遊戲類型 2D 90度直視，也稱作橫版 街霸、阿貓阿狗、江湖 這一視角的引擎設計簡單，可用於製作2D格鬥、橫版動作類遊戲及RPG。 2D 45度俯視 俠客英雄傳3 這一視角的設計同前一種一樣，只是地圖要大些。可用於RPG的製作。 2D 斜45度俯視(推薦)仙劍奇俠傳、風雲 這一視角設計比前二種要複雜的多，但是效果可是當今2D遊戲中最好的。可用於RPG的製作。 3D第一人稱 Quake系列 3D第三人稱 古墓麗影 在此，在下向您強烈推薦第三種2D斜45度俯視的設計。雖然設計要麻煩一些，但想一想：如果不用會怎麼樣？您是選前兩種？還是後兩種？確定遊戲的畫面風格。見下表：風格 代表作 特點 日式 江湖、超時空英雄傳說2 以最少的線條和顏色表現出最好的效果，看起來很像日式漫畫。 美式 暗黑破壞神、風雲 立求逼真，遠點兒看起來像電影。 中式 仙劍奇俠傳 此乃日式和美式的融合。不注意時覺得很真實，仔細想一想，不對！ 中式漫畫 阿貓阿狗、赤壁 以細膩的線條來表現人物。 確定遊戲的操作方法。對於製作RPG遊戲，主要有鍵盤、滑鼠和、手柄三種操作方式。在這三種操作方式中，以鍵盤操作的技術最為成熟，實現最為簡單，同樣效果也是最好的。所以我推薦您選擇鍵盤操作方案。到此，我們可以看出。這五種選項中，除了第四個之外。其他四個選項都和程式設計有重大關連，所以您一定要與程式設計人員好好溝通一下。值得慶倖的是，我們的大多數遊戲創作群(小組、工作室)都是策劃兼程式設計。作了以上選擇。我想各位也累了，休息一下吧！好好想一想這個遊戲該是什麼樣的。我也累了，下次再見！三、編劇與腳本製作編劇在這裏的意思是編寫遊戲所需的劇本。可以是自行創作，也可以拿現成的小說、故事進行改編。對於後者，您可一定要在遊戲中注明：“本遊戲的劇本作者請與本創作群聯繫，我們保留了您的稿費x元(人民幣，如需外匯按當日銀行排價計算)，請在xxxx年xx月xx日前找本創作群的財務負責人領取。”好了，玩笑開的也差不多了！不過您要是真的拿別人的小說當遊戲劇本的話，上面那句話千萬不能少。由於編劇負責的是整個遊戲的劇本編寫，而腳本製作是負責按劇本編寫遊戲情節發展的。所以他們的工作是很重要的。想想當年的仙劍奇俠傳是怎樣以情動人的，您就應該知道一個好的劇本對遊戲是多麼的重要。但是，有了好的劇本並不代表這個遊戲就能夠打動玩家。腳本製作也是相當重要的。想想當年的新蜀山劍俠您就應該知道如果將一個好劇本交給一個水平不高的腳本製作人員的話，那麼製作出來的遊戲是否依然能夠打動玩家呢？由於編劇和腳本製作的工作幾乎是密不可分的。所以我推薦您的創作群(小組、工作室)最好是讓編劇去兼任腳本製作，在編寫劇本時直接按遊戲腳本進行編寫。這樣即能減去一道工序，同時也能取得十分好的效果。那麼一個遊戲的劇本應該怎樣編寫呢？這個問題我無法說清楚，因為時代在進步，玩家對劇情的要求也越來越高，所以這個問題就讓您的編劇自己去想吧！我只能將編劇的要點給您說一下。 在遊戲中用來表現人物和劇情的主要是對話，所以在編寫劇本時一定要注重人物對話，要用對話充分表現出每個人(起碼是主角)的性格和習慣。根據上一點發展而來，在遊戲中要注重的是對人物刻畫；而不是戰鬥動作描寫。所以在劇本中，每一場戰鬥直接寫戰鬥結果即可。遊戲劇本中，沒有必要過細的去描寫場景、人物外貌、物品形狀和人物動作(特殊情況除外，比如打敗最終魔頭後的一節戰鬥動畫)。這些工作是屬於場景設計和人物設計的。劇本如果是拿別人的小說改編的(比如西遊記)，就一定要尊重原著，對原著中的內容最好不要變動。如果劇本是根據真實故事改編的(比如花木蘭)，則不但要尊重原著，還要尊重歷史。可不能改寫歷史哦！如果劇本是根據神話傳說改編的(比如天仙配)，那麼就千萬不能洩漏時代。如果是有時代的，就一定要注意當時的風俗，否則就是改寫歷史。注意：洩露時代是多方面的，不光是年號。如果劇本是自行創作的，千萬不要將別人小說或遊戲(只限於有著作權的)中的劇情和人物拉進來，不然別人跟你打官司我可不管。 自行創作劇本，如果和已有的故事有聯繫，最好不要改寫原有的內容，包括人物性格和寶物特性等等。比如您在寫後西遊記時，孫悟空的性格可不能和西遊記中的孫悟空不一樣哦！自行創作劇本時，如果使用了真實地名，就要注意真實地理位置和當地的人民風俗習慣。仙劍奇俠傳就犯了一個嚴重錯誤：從杭州去大理應該向西南走，而李逍遙這個大白癡卻一直向北走。自行創作劇本時，要確保不和任何已有的故事發生衝突。更不要把不可能在一起的寫在一起。比如在您的遊戲出現了諸葛亮(三國時代)巧鬥劉伯溫(元朝)的場面。專門打亂時空的遊戲除外(比如金庸群俠傳)。自行創作劇本時，如果把兩個毫不沾邊的傳說或故事聯繫在一起。就要注意聯繫一定要得當，否則是要被人笑話的。自行創作劇本時，如果使用了傳說中的人物，一定要注意這些人物是屬於那一類傳說的(傳說人物分類見下表)。如果同時出現了兩類或兩類以上傳說中的人物，則一定要安排好根據，不可亂來，否則是要鬧笑話的。傳說 代表人物 可以聯繫在一起的傳說 中國上古傳說 女媧、盤古 中國道教傳說 中國道教傳說 玉皇大帝 中國上古傳說、佛教傳說 佛教傳說 西天如來、南海觀音 中國道教傳說 希臘傳說 宙斯、雅典娜 基督教傳說 上帝、耶穌四、美工與電腦美工美工與電腦美工，同樣都是美工，曲別只在於美工是在紙上繪畫；而電腦美工是在電腦上繪畫的；同樣都是繪畫，所以我建議您：讓您的美工與電腦美工互相兼職。不管美工與電腦美工是否互相兼職，都有一個問題，那就是：電腦遊戲中的畫怎麼畫？一般來說分三步完成：一、由美工人員在紙上畫好原畫。二、由電腦美工將原畫繪製在電腦上。三、由美工指點，電腦美工對電腦上的畫作進一步修改。如果您有掃描器的話，那麼就要輕鬆一些了。下一步是決定遊戲的畫面風格。在第二章遊戲策劃裏，我們介紹了四種繪畫風格，日式、美式、中式和中式漫畫。由效果來講，最好是採用中式。但是有一個問題就是：您的美工和電腦美工有這麼高的水平嗎？不是我刻意貶低，而是這種畫面風格確實太難作到了。所以我推薦您採用中式漫畫的畫面風格。中式漫畫，是由中國的傳統漫畫和日式漫畫融合演變而來的。它的特點是線條細而多、能夠充分表現出人物的特點。由於其色彩使用簡單明瞭，所以特別適合高清晰度(640x480及以上)遊戲的製作。但是，由於中式漫畫的線條要求細膩、清晰。而且細條的數量明顯要比日式漫畫多的多(大約在10倍左右)。況且我們的一些“畫家”也畫慣了日式漫畫，所以無形中加大了美工人員的難度和工作量。 這裏列舉了幾條美工和電腦美工人員在繪畫時所要注意的要點，請參閱：日式漫畫只要求外形同真實一致，而忽略了立體感；而中式漫畫不但要求外形同真實一致，還要求能夠通過線條來表現出立體感。所以美工在繪畫時一定要注意立體感。線條要求細膩、流暢。美工在繪畫時要注意，有些繪畫手法是不能使用的。比如模糊效果，因為這些效果到了電腦上是無法完成的。同時美工還要注意到，在繪畫時，應儘量保證線條清晰。如果線條不清晰，到了電腦上也是無法完成的。電腦美工在電腦上繪畫時，首先要做到的是圖畫比例。一般來說，人物寬度與螢幕寬度的比例是1:10，即10個人物正好放滿一屏。人物寬度與人物高度的比例是1:5。人物或物品以及場景的大小比例應和真實世界一致。電腦美工使用繪畫軟體繪畫時，應在真彩色模式下作圖，並將軟體的Antialias(鋸齒平滑)功能打開。但是，在畫一些透明的畫時，人物或物品與透明區域交界處的線條在畫時應將Antialias功能關閉。電腦美工將圖畫畫好後，應將畫中的部分輪廓線抹去。不要去力求逼真，因為那樣純粹是自找麻煩。如果您自己不是一位“畫家”的話，可以去找別人幫你畫。但是別找的太遠，因為那樣您對他就很難進行管理。還有最重要的一點，如果您要造商業化的遊戲的畫，千萬不要從別人的遊戲中“竊取資源”，後悔藥可不好吃哦！五、程式設計一選擇一種電腦語言(編譯器)選擇一種合適您的電腦語言和編譯器，這對遊戲製作來說可是相當重要的。如果在遊戲製作到半中央發現這一語言編程不方便或編譯器不好，豈不讓人傷心。所以在造一個遊戲前一定要選擇好編程語言和編譯器。我作為同行，當然要向您推薦最好的語言與編譯器了，請看下表： 語言 編譯器 優點 缺點 DOS C/C+ Borland C/C+ 相當普及，學習簡單。編程簡單，出錯少。 16位元程式、速度慢、有640k基本記憶體限制。 HIGH C/C+ 速度快、性能好。 難學、太專業化。 Microsoft C/C+ 16位元程式、速度不是很快、有640k基本記憶體限制。太專業化。 DJGPP+Allegro 速度快、多媒體遊戲庫豐富，非常適造遊戲。 不好學，幫助少。速度不如Watcom C/C+快。 Watcom C/C+ 速度最多、性能優越。 較專業化、不好學。 Windows9x Basic Visual Basic 學習簡單、編程方便。 太慢。 C/C+ Borland C/C+ Borland C+ Builder Visual C+ Microsoft C/C+ Watcom C/C+ Pascal Borland Pascal Borland Delphi 遊戲工廠 其代表作如下：Borland C/C+ for DOS仙劍奇俠傳 DJGPP+Allegro雷神之錐(Quake)DOS版(唯一一個出了名的)Watcom C/C+ for DOS三國演義、超時空英雄傳說、金庸群俠傳、紅色警報、古墓麗影，真多呀！還有一大堆呢！Visual Basic仙劍奇俠傳九八柔情版(我都想不到)Borland C+ builder風雲之天下會可以看到：在DOS下，Watcom C/C+可以說是一統天下。在Windows9x下，在這些C/C+中您隨便選一種就可以了。可我完完沒有想到：仙劍奇俠傳九八柔情版“居然”是用Visual Basic編的，真是出人意料。我們也可以看出，大部分的遊戲都是用C/C+編寫的。這可能已經成了一個不得不讓人承認的事實，起碼現在來說“想編寫一個好遊戲，必須用C+”。在DOS下編寫遊戲的朋友，最好去找些有關VESA顯示標準和SB16音效卡的編程資料。這樣一來，Windows的最大優勢與硬體無關性，就沒有了。您可盡情發揮DOS下編程可直接控制硬體的樂趣，那種感覺真是棒極了。在Windows9x下編寫遊戲的朋友，最好去下載一份DirectX SDK，再找些有關DirectX編程的資料。雖然Microsoft提供的DirectX SDK庫中有DirectX編程的示例程式，但按Microsoft的慣例來說，這些示例程式應該是很難看懂或根本看不懂才對(並非玩笑)。這一章不長，朋友們快去找資料吧！下一章我將告訴您遊戲大概分幾個模組，最好學一下C+的類哦！六、程式設計二是面向物件還是面向過程這一章，看題目應該知道，這是一個比較重要的選擇。面向物件，是近幾年來新興起的一種編程手段。由於其在Windows系統的幫助下迅速崛起，成為明日之星的可能性與日俱增。照理說，面向物件的編程手法的確要比面向過程的手法要先進的多。然而，面向物件的編程也有著它的致命弱點。就拿C+在Windows98下編遊戲來說：如果以面向物件的形式進行編程的話，那麼在遊戲運行時，程式自動創建的類將會變的非常多。而且在進行消息迴圈時，有大部分的運行時間是掌握在Windows系統手裏。這將會大大影響遊戲的運行速度，風雲就是一個很好的例子，在一台Pentium133上玩風雲慢的就像烏龜，而相同清晰度的大富翁在這一機型上卻奔跑如飛。當然，你也可以在你的遊戲配置中標明“本遊戲最低配置為Pentium300+64MB記憶體”如果一個遊戲以面向物件形式編程的話，那麼它用到的類將會有成百上千個。此時如果將這一遊戲以面向過程的形式重新編寫的話，那麼它用到的類不會超過20個(Windows下的遊戲不會超過100個)。如此多的類當然會將遊戲的速度降到很慢。當然，我不是故意貶低面向物件的編程手段。面向物件的編程手段用來編寫應用軟體那將是上上之選，而用來編遊戲可就有些不如面向過程了(現在)。下面我們以在面向過程的編程手法說明一下在一個角色扮演型遊戲中所需要的模組(類)。遊戲內部所用模組遊戲外部所用工具圖片管理器地圖編輯器動畫編輯器人物資訊管理器物品資訊管理器劇情腳本編輯器音樂管理器聲音管理器在上表中，左邊的結構圖是一個角色扮演型遊戲中至少要用到的模組(類)，右邊的是你自己所要用到的幾個工具。這些模組和工具在一個遊戲中可以說是必不可少的，有些編程人員喜歡將這些所有的模組和工具造在一些，便出現了所謂的調試模式。其實這是一個很不好的習慣，因為一個遊戲本來就是一個很大的程式集合。光是遊戲本身所必須的模組就已經使遊戲程式變得很大了，如果再加上一些對玩家來說沒有用的工具，那你想想：這個遊戲程式會變得多麼大。所以我認為遊戲模組應與工具完全分開。 下面按步驟講一下每個模組與工具的工作範圍。顯示控制：對顯示器、顯示卡進行管理，負責初始化顯示模式及畫面的高速顯示。提供基本的操作函數，有畫點、畫垂直線、畫水平線、畫空心矩形、畫實心矩形這幾個函數即可。再提供幾個特殊處理的函數，比如淡入淡出、螢幕閃爍等。 字元管理：故名思義，管理對字元的顯示操作。負責讀取字形檔，並使用顯示模組提供的基本操作函數顯示字元。(如果您覺得在顯示字元上也要提高速度的話，那麼您可以將字元管理模組和顯示控制模組編寫到一塊，在顯示字元時搞直接寫屏。能提高字元顯示速度15%)視窗控制：別理解錯了，這一模組主要用於在遊戲中功能表、選擇項、提示資訊的顯示。圖片管理：這一模組按每個人遊戲的習慣不同分為兩類：一、有些人造遊戲沒有圖片管理模組，而在視窗控制、人物管理、物品管理、地圖控制、動畫控制這幾個模組中各自建立相互獨立的圖片庫。這樣做的好處是每個圖片庫相互獨立，不會混淆。壞處是必須給以上每個模組都配備一個圖片管理模組，使遊戲程式變大。而且每個圖片庫之間的圖片不能互相調用，有時會造成不必要的浪費。二、我推薦使用第二種方法：只造一個圖片管理模組，將所有的圖片(動畫圖片可以除外)，包括提示圖像、人物、物品、地圖及其它圖像均放於一個圖片庫中。好處是減少了圖片控制模組，而且一個圖片可以供多個模組調用。動畫控制：很好理解的，控制動畫的嗎！地圖控制：一定要注意，這一模組只負責管理地圖庫、組建地圖，但並不負責顯示地圖。人物管理：管理每個人物的資訊(不包括對話資訊)。物品管理：管理每個物品的資訊。音樂管理：管理所有的音樂及其播放，音樂檔一般使用MIDI格式，如果你水平高點可以使用MP3格式。聲音管理：管理所有的聲音及其播放，音效檔案是WAV和VOC格式任選。劇情控制：最大、最難、最複雜的一個模組。管理其他的全部模組，負責整個遊戲的劇情發展。戰鬥控制：負責站鬥啦！自己用的工具嗎，介紹一下：圖片管理器：負責管理圖片庫，要求可以隨意加入、刪除圖片，為圖片庫建立索引以便遊戲調用。地圖編輯器：編輯地圖用的嗎！用它來造地圖，然後形成專用的檔格式。動畫編輯器：造動畫用的，如果懶的造動畫那就算了。 人物資訊管理器：編輯人物資訊的工具。物品資訊管理器：編輯物品資訊的工具。劇情腳本編輯器：又是最大、最難、最複雜的一個，用來編寫劇情檔用的。音樂管理器：管理音樂庫的工具。聲音管理器：管理聲音庫的工具。看完了，是不是要趴下了！沒事，慢慢來嗎！一個人造個遊戲最快也要2年！程式設計三顯示方面的程式設計上一章裏，我們說明了作為一個遊戲的程式設計所需要完成的工作。在這一章，我們將有關圖形方面的程式設計內容詳細給大家說一下。首先申明一下，無論您的遊戲採用那一種清晰度，本文所說的內容都適用於您。一、2D驅動程式如果是編寫Windows9x下遊戲的話，2D顯示驅動程式的代表作主要有Microsoft公司推出的DirectX中的DirectDraw和SciTech公司的WinDirect、MGL。在DOS 下就顯得有些問題，現在市面上的顯示卡類型非常多，如果我們給每一個顯卡都編寫一個驅動程式的話，那恐怕是相當困難的。再說我們也不可能擁有每一種顯卡的詳細資料。幸好在各種SVGA顯示卡出現不久，由各大廠家聯合推出了一個VESA標準。現在的顯卡幾乎可以說是全部都只持VESA標準。所以，我們只要按VESA標準進行顯示卡編程，就可以獲得最大的相容性。二、3D驅動程式編寫3D遊戲的話，3D驅動程式介面無非就是OpenGL和Direct3D兩種。如果你想編寫Windows下的遊戲的話，那麼選擇那一個都一樣。如果編寫DOS遊戲的話，使用OpenGL當然不會錯。注：由於3D遊戲所涉及的範圍較大，所以在以後我們將不討論3D遊戲的製作。(到SciTech公司的網頁上去轉轉，這個公司提供的WinDirect、MGL開發庫提供了完整的2D與3D支援(DOS/Windows9x)，而且還提供了DOS下的OpenGL 3D引擎)注：MGL開發庫同時有DOS版和Windows9x版。三、無規則圖片庫的管理這裏所說的圖片庫包含了整個遊戲所使用到的任何圖片，想必您也可以猜到，這個圖片庫將會變得相當大。如何管理這樣一個資料量極大的圖片庫，成了現在的首要問題。遊戲中所使用的圖片有大有小，也就是說，圖片庫中的圖片資料長度不固定。這也為我們管理圖片庫增加了難度。圖片管中的圖片位置是無規律的，但是我們可以建立一個有規律的索引表來管理這個圖片庫。因為每個圖片的索引長度是一樣的，也就是說是有規律的。這樣一來，管理就容易多了。 索引檔的基本結構如下：檔頭，圖片個數，第1個圖片在圖片庫中的位址，最後一個圖片在圖片庫中的位址圖片庫的基本結構如下：檔頭，第1個圖片的資料，最後一個圖片的資料然而，就算是這樣，整個圖片庫的管理仍然不方便。比如說有一張圖片的編號是105，而在中途我們刪除了第85張圖片。當下次再調用第105張圖片時，就會發現調用的是原來的第106張圖片。為了解決這個問題，我們將索引檔的結構改進如下：索引結構:struct PicIdxchar PicName10; /圖片名稱unsigned int high,width; /圖片大小unsigned long offset; /圖片在圖片庫中的位址;圖片索引檔結構:檔頭,圖片個數,第1個索引(PicIdx),最後一個索引(PicIdx)可以看出，我們為索引增加了一個專案：圖片名稱。這樣做的好處是，我們在調用圖片時，可以按圖片名稱進行調用。以後無論是增加還是刪除圖片庫中的圖片，都可以保證圖片調用正確。四、有規則圖片庫的管理有規則圖片庫相對於無規則圖片庫來說管理起來就要方便的多了。這裏說的有規則是說每一個圖片的大小都一致，也就是說資料長度都一致。這樣的圖片庫最點型的就是人物圖片庫，以人物圖片庫為例，圖片索引檔結構如下： 檔頭，圖片個數，第1個人的姓名，最後1個人的姓名五、對話方塊的處理在遊戲中，對話方塊是少不了的，特別是角色扮演型遊戲。對話方塊的主要類型有：功能表、資訊顯示框、邏輯選擇框、多項選擇框、買賣物品框、人物資訊框等等。在這一點上，設計者可以按自己的意欲隨意設計。不過要注意的是風格要保持一致。從下一章開始，將細緻講述有關顯示方面的程式設計，分別是圖片庫的壓縮保存、虛擬螢幕的編程、地圖引擎的製作、螢幕特殊效果的處理方法。 程式設計四圖片庫的壓縮保存我們知道，隨著遊戲畫面清晰度的不斷提高，遊戲所佔用的硬碟空間也在不斷增大。為此，我們有必要將有些大容量的資料做壓縮保存，圖片庫就是一個很好的例子。首先要談到的就是壓縮演算法問題，現在的壓縮演算法很多，選擇那一種好呢？大家一定會想到在網頁上常用到的JPEG格式和GIF格式，但是這兩種演算法都不適合在遊戲中使用。就遊戲開發來說，我們必須選擇一種壓縮率高、解碼速度又快的演算法。如果採用JPEG無損壓縮演算法，那麼壓縮率就不高，採用有損壓縮的話雖然壓縮率很高但在遊戲中圖像是不能有所損壞的。還有，JPEG演算法的一個最大缺點就是解碼速度太慢。GIF演算法性能很高，壓縮率高解碼又快，只可惜它不能壓縮超過256色的圖像。但如果您做的遊戲是256色的話，那麼使用GIF演算法是再好不過的了。如果您的遊戲畫面採用了真彩色或您想將圖像壓縮的再好一點，那麼無疑您得自己研製一套壓縮程式。這裏，我為大家提供了兩個方案：方案一：採用LZSS或LZH壓縮演算法。方案二：使用它方提供的壓縮程式。這個程式是本人在網路上無意發現的，使用非常方便，而且它不是壓縮檔而是壓縮記憶體中的資料又存放在記憶體中，所以非常適合在遊戲中使用。唯一的缺陷就是壓縮率不是非常高。以上兩方案的根源程式和開發包均可在資源下載處下載，方案二開發包名稱為DCL壓縮軟體發展包。程式設計五地圖引擎的製作地圖，在角色扮演型遊戲中也稱作場景，是整個遊戲中最重要的部分，製作方法也是最難的。按地圖組成方法的不同，大致可分為兩種：第一種：拼圖式，以仙劍奇俠傳為例。著名的角色扮演型遊戲仙劍奇俠傳對地圖的製作方法可以說是相當落後的了，但卻是十分實用的。左邊的這幅圖片綠色為透明部分，紅色為圖像部分。仙劍奇俠傳的地圖(靜態部分)就是由許許多多的這種圖片拼湊而成的，排列形式如右圖所示。 這種方法的好處是對記憶體的使用量少，讀盤時間少，處理速度快。但它的缺點也是十分明顯的，開發者必須將圖片用專用工具分解成一個個如左圖式的地圖元素放入圖片庫中，且這一圖片庫不能被其他模組使用。前面說了，這種方法雖然落後，但卻十分實用。不過要生成效果更好的地圖，還是使用後面的兩種方法為好。第二種：圖片式，以軒轅劍三(尚未推出)為例。軒轅劍三的地圖在所有的角色扮演型遊戲中效果可謂一流的，整個畫面渾然一體，絲毫看不出地圖元素組合的痕跡(如下圖)。為什麼DOMO小組能夠做出效果如此之好的畫面呢？原因很簡單：軒轅劍三的靜態地圖是非組合而成的，使用的是已經繪製好的圖片。直接使用圖片真的行嗎？當然不行，DOMO小組也不會認為就此便可以戰勝同門師兄仙劍奇俠傳。它還使用了另一個先進技術即時光影效果。即時光影效果在3D遊戲中很容易實現，而在2D遊戲卻非常難，幾乎可以說是無法辦到。那麼怎樣辦到呢？這裏我們暫時不考慮光線效果，只考慮影子。我介紹一種很弱智的辦法：假設陽光是從上方照下來的，那麼人的影子是橢圓形就可以了。可惜即使是這樣也無法達到很好的效果，解決的辦法也非常簡單：將橢圓形影子設定成黑色，然後與地表進行50融合處理。但有一點要注意，根據遊戲清晰度的不同，融合的方法也不一樣。這一點我將放在下一章螢幕特殊效果的處理方法裏為大家講述。這種方法的好處不必說了，效果是所有方法中最好的。那它的壞處呢？想必不說大家也知道了，佔用的硬碟空間、記憶體空間太多，地圖裝入慢。第三種：組合式，以劍客(本創作群製作，尚未推出)為例。這種方法是我自己想出來，我們創作群自行開發的遊戲劍客便是使用的這種方式。別人是否在我之前使用過，我不知道。這種方法是將場景所需的各種圖片，如草坪、花瓶、樹木、椅子之類，按照一定的層次進組合。組合完成後便成了玩家所看到的地圖，其效果也非常好，次於第二種方式，但優於第一種。由於其製作技術複雜，所以這裏不便於介紹。 當然這種方式也有它的缺點：佔用記憶體空間過大，地圖裝入速度很慢。大體上的地圖使用方式就只有這三種了，下面我列一個表供大家參考：地圖方式裝入速度佔用硬碟空間佔用記憶體空間拼圖式快，但由於地圖要進行組合所以不是很快 少 少 圖片式慢，資料量很大所以慢 很多 很多 組合式很慢，資料量不但很大而且地圖進行組合的過程也很複雜 很少 很多，雖然裝入速度最慢，但地圖組合完畢後佔用的記憶體量和圖片式一樣多 程式設計六螢幕特殊效果的處理這一章的內容很多，希望大家注意看。兩幅圖像的融合真正的兩幅圖像融合的實現方法並不複雜，但是如果不使用MMX技術的話，速度會非常慢。為了加快速度，這裏提出一種快速的偽融合方法。速度很快，但只能進行50%的融合處理。我們假設一幅圖片被紮了很多孔，只要這些孔即多又分佈均勻，我們就可以看清楚在這幅圖片的後面是什麼了。想必大家也想出來是什麼方法了。假設我們要將圖一與圖二進行融合，我們可以做如下處理。x，y分別表示行座標與列座標。步驟一：顯示圖像一，但只顯示(x%2)=(y%2)的點。注：x%2表示求X除2的餘數。步驟二：在同一位置顯示圖像二，但只顯示(x%2)!=(y%2)的點。注!=表示不等於。只此兩步，兩幅圖像的融合就完成了。瞧見左邊的這幅灰色圖塊了嗎，其實它是由黑色和白色兩種顏色進行上述融合後的產物。讓我們將它放大4倍再看看吧(右圖)。人物影子的即時生成想必很多程式師都為此問題煩腦過，其實很簡單。我這裏有一個解決辦法，同“雲風”工作室的解決辦法一樣。即採用即時生成的辦法，生成的效果很不錯。此時，我們設陽光從西南方照下，即影子在人的東北方。 步驟一：將原人物圖像非透明部分全部變黑。步驟二：將變黑後的圖像高度壓縮當原來的25%。步驟三：再將圖像右傾45度。經過以上三步，一個影子便完成了。如圖所示。原人物圖像全部變黑後的圖像高度壓縮四分之三後的圖像右傾45度後的圖像，即為生成的影子在遊戲中，直接將處理成的影子先於人像這前顯示出來，顯示時與背景進行50%融合。然後再顯示人像。斜視角遊戲中全屏雨雪效果的實現即使將地上鋪滿雪花，也比不上天上飄下兩朵雪花那麼讓人感動。這是筆者在雲風工作室讀到的一句話。此話得確不錯，可惜雪花並不那麼容易就會飄下來。其實在非斜視角遊戲中，全屏雨雪效果很容易實現。只是在斜視角遊戲中不容易實現。這裏介紹一種方法可以在斜視角遊戲中實現全屏雨雪效果。不知大家會不會用3DS MAX，不會用可糟了，我們這裏要用到它。使用3DS MAX的粒子系統生成一幅全屏雨雪下落的動畫，當然不要忘了將視角旋轉一下以便同遊戲中一致。然後將3DS MAX的渲染功能關閉，再生成連續的單幅圖像就可以供遊戲使用了。隔行抽絲隔行抽絲一般用在動畫上，使用的目的是為了減少佔用的空間。一般來說，隔行抽絲是在螢幕上顯示時，螢幕上的單數行或偶數行沒有內容。假設原本的圖像或動畫大小是800x600，經過隔行抽絲後，在顯示時的大小就是80