關於遊戲開發（轉）

1、造個什麼遊戲
　　造一個什麼樣的遊戲？若是叫您來答，您會答什麼？是角色扮演仍是即時戰略？對於廣大遊戲編程愛好者來講，答案確定會是角色扮演。
　　那麼，咱們要造一個什麼樣的角色扮演型遊戲呢？相信這個問題也是毋庸質疑的，你們確定都會說：「《仙劍》式」。的確，《仙劍奇俠傳》自1995年出世以來，在遊戲界中已經成了一個不敗的神話。
　　咱們也許會問：「誰來打破這個神話呢？」個人答案是：「咱們！由咱們廣大的遊戲愛好者來打破。」我和一羣同窗創立了絕情電腦遊戲創做羣，從1997年6月開始致力於電腦遊戲的製做。我想，正在看這篇文章的您，也許您和咱們的「同行」吧？ 　　再問：「打破這個神話要怎麼作呢？」首先，咱們須要一批工做人員，造一個遊戲至少須要如下工做人員：
　　策劃：負責對遊戲製做進行策劃指導。
　　編劇：負責遊戲的劇本編寫。
人物設計：設計遊戲中的人物形像。
場景設計：對遊戲中的地圖、場景、物品進行設計製做。
電腦美工：將設計好的全部圖片輸入電腦。
動畫設計：設計遊戲中的各類動畫，包括片頭、片尾等。
招式設計：根據劇本設計戰鬥人員的各類招式、法術。
程式設計：負責對遊戲中的各類程式進行編寫。
地圖製做：用設計好的地圖編輯器製做遊戲中所使用的地圖。 
腳本製做：根據劇本對遊戲情節數據進行編寫。
聲音製做：錄製遊戲中所使用的各類音樂及音效。
　　測試：對製做好的遊戲進行各類測試工做。
宣傳發行：對測試完成後的遊戲進行宣傳與發行工做。能夠找代理。
　　這些工做，能夠適當的進行兼職。好比策劃與程式設計兼職，可別兼職太多哦！
2、遊戲策劃 
　　策劃，是一個遊戲創做羣(小組、工做室)的總指揮。他將負責整個遊戲的具體安排工做，好比開發環境、遊戲運行條件、遊戲風格、等等工做。要製做一個合格的遊戲，若是沒有一個好的策劃，那麼這個遊戲可能很難作成。不過通常的小創做羣都是策劃兼程式設計的，好比我就是。
　　那麼策劃要作些什麼呢？
肯定運行遊戲的操做系統。各類操做系統的優缺點見下表：操做系統 優勢 缺點 推薦編程語言 
DOS系列 直接控制硬件、速度快、編程方便。 對於一些多媒體設備，須要本身製做驅動程序。（顯卡按VESA，聲卡按SB16進行編程便可解決此問題） WatcomC/C++11.0或更高 
Windows3.x
Windows9x 編程與硬件無關，多媒體控制方便。 速度慢，消息式編程不方便，沒法直接控制硬件進行快速處理。DirectX太複雜，太慢。 Visual C/C++、Borland C/C++ 
OS/2 同Windows9x差很少
LinuX系列 網絡操做方便，可直接控制硬件、速度快 缺乏軟件支持，遊戲程式源代碼開放 狀況不明。 
UNIX系列 若是你選UNIX，我推薦你換LinuX
MacOS 能夠直接控制硬件、編程與硬件無關、能夠很方便的控制各類多媒體設備 必須使用Mac系列計算機 　 
FC-OS 日本任天堂公司的家用遊戲機平臺，編程使用匯編語言。 
SEGA-OS 日本世嘉公司的家用遊戲機平臺，在電腦上使用專門的編程工具進行製做。 
PS-OS 日本索尼公司的家用遊戲機平臺。本站無詳細資料。 
CPS-OS CAPCOM公司的街機運行平臺(大明鼎鼎的《街霸》便出生於此)。本站無詳細資料。 
NEO-GEO 日本SNK公司的家用遊戲機與街機運行平臺。本站無詳細資料。 
有一點請你們注意：不要把遊戲的運行機型設的過高。由於如今還不是人人都用PentiumⅢ加Vodoo的時代。
順便提一句：絕大多數據的電腦玩家不多去理會遊戲運行在什麼操做系統下，千萬不要認爲DOS版的遊戲就沒有人玩了。《俠客英雄傳3》和《江湖任我行》不就運行在DOS下嗎！。
肯定遊戲的畫面清晰度。
咱們將使用標準VGA便可實現的清晰度稱爲低清晰度；須要SVGA才能實現的清晰度稱爲高清晰度。畫面清晰度見下表：
　 低清晰度 高清晰度 
分辨率 300x200x25六、*0x480x16等 *0x480x25六、*0x480x65536等表明做 《仙劍奇俠傳》 《風雲》 
優勢 數據量少、不分頁。顯示標準統一。動畫速度快、可實現多層卷軸動畫。用來作遊戲中的片頭、片尾動畫是再好不過的了。 畫面效果好、視角範圍大。 
缺點 非動畫的畫面效果很難作好，鋸齒明顯 數據量太大，顯存要分頁操做，速度慢。若是不使用VESA則需爲每一種顯卡編寫一種驅動程序。 
　　如今來看，若是要製做一個商業化的遊戲，選擇低清晰度是不行的。最低也得是*0x480x256色才行。如果編程人員能力不夠的話，選擇低清晰度也是何嘗不可的。好比造一個「《街霸》」，就能夠選擇320x200x256色的清晰度。
　　若是選擇256色的清晰度，就必須調配一個超級調色板(站長調配了一個，可供下載。1851字節)，以適應各類複雜的圖片。若是您的編程人員有能力的話，能夠選擇65536色的清晰度。由於65536色是直接向顯存送三原色，能夠表現任何顏色。不過編程人員要處理的的數據量比256色大了一倍，顯示速度也就只有256色的一半了。
　　在下自1997年7月以來，一直致力於一個角色扮演型遊戲的製做。採用的畫面清晰度是800x600x65536色，效果好到極點，速度比 Windows9x下的DirectX還快，放動畫每秒種可達42.7幀(酷吧！在下的機型只不過是AMD K5-PR13三、內存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遊戲，主要有鍵盤、鼠標和、手柄三種操做方式。在這三種操做方式中，以鍵盤操做的技術最爲成熟，實現最爲簡單，一樣效果也是最好的。因此我推薦您選擇鍵盤操做方案。
　　到此，咱們能夠看出。這五種選項中，除了第四個以外。其它四個選項都和程式設計有重大關連，因此您必定要與程式設計人員好好溝通一下。值得慶幸的是，咱們的大多數遊戲創做羣(小組、工做室)都是策劃兼程式設計。

3、編劇與腳本製做
　　編劇在這裏的意思是編寫遊戲所需的劇本。能夠是自行創做，也能夠拿現成的小說、故事進行改編。對於後者，您可必定要在遊戲中註明：「本遊戲的劇本做者×××請與本創做羣聯繫，咱們保留了您的稿費x元(人民幣，如需外匯按當日銀行排價計算)，請在xxxx年xx月xx日前找本創做羣的財務負責人×××領取。」
　　好了，玩笑開的也差很少了！不過您要是真的拿別人的小說當遊戲劇本的話，上面那句話千萬不能少。
　　因爲編劇負責的是整個遊戲的劇本編寫，而腳本製做是負責按劇本編寫遊戲情節發展的。因此他們的工做是很重要的。想一想當年的《仙劍奇俠傳》是怎樣以情動人的，您就應該知道一個好的劇本對遊戲是多麼的重要。可是，有了好的劇本並不表明這個遊戲就可以打動玩家。腳本製做也是至關重要的。想一想當年的《新蜀山劍俠》您就應該知道若是將一個好劇本交給一個水平不高的腳本製做人員的話，那麼製做出來的遊戲是否依然可以打動玩家呢？ 　　因爲編劇和腳本製做的工做幾乎是密不可分的。因此我推薦您的創做羣(小組、工做室)最好是讓編劇去兼任腳本製做，在編寫劇本時直接按遊戲腳本進行編寫。這樣即能減去一道工序，同時也能取得十分好的效果。
　　那麼一個遊戲的劇本應該怎樣編寫呢？這個問題我沒法說清楚，由於時代在進步，玩家對劇情的要求也愈來愈高，因此這個問題就讓您的編劇本身去想吧！我只能將編劇的要點給您說一下。 在遊戲中用來表現人物和劇情的主要是對話，因此在編寫劇本時必定要注重人物對話，要用對話充分表現出每一個人(起碼是主角)的性格和習慣。
根據上一點發展而來，在遊戲中要注重的是對人物刻畫；而不是戰鬥動做描寫。因此在劇本中，每一場戰鬥直接寫戰鬥結果便可。
遊戲劇本中，沒有必要過細的去描寫場景、人物外貌、物品形狀和人物動做(特殊狀況除外，好比戰勝最終魔頭後的一節戰鬥動畫)。這些工做是屬於場景設計和人物設計的。
劇本若是是拿別人的小說改編的(好比《西遊記》)，就必定要尊重原著，對原著中的內容最好不要變更。
若是劇本是根據真實故事改編的(好比《花木蘭》)，則不但要尊重原著，還要尊重歷史。可不能改寫歷史哦！
若是劇本是根據神話傳說改編的(好比《天仙配》)，那麼就千萬不能泄漏時代。若是是有時代的，就必定要注意當時的風俗，不然就是改寫歷史。注意：泄露時代是多方面的，不光是年號。
若是劇本是自行創做的，千萬不要將別人小說或遊戲(只限於有著做權的)中的劇情和人物拉進來，否則別人跟你打官司我可無論。 
自行創做劇本，若是和已有的故事有聯繫，最好不要改寫原有的內容，包括人物性格和寶物特性等等。好比您在寫《後西遊記》時，孫悟空的性格可不能和《西遊記》中的孫悟空不同哦！自行創做劇本時，若是使用了真實地名，就要注意真實地理位置和當地的人民風俗習慣。《仙劍奇俠傳》就犯了一個嚴重錯誤：從杭州去大理應該向西南走，而李逍遙這個大白癡卻一直向北走。
自行創做劇本時，要確保不和任何已有的故事發生衝突。更不要把不可能在一塊兒的寫在一塊兒。好比在您的遊戲出現了諸葛亮(三國時代)巧鬥劉伯溫(元朝)的場面。專門打亂時空的遊戲除外(好比《金庸羣俠傳》)。 
自行創做劇本時，若是把兩個絕不沾邊的傳說或故事聯繫在一塊兒。就要注意聯繫必定要得當，不然是要被人笑話的。
自行創做劇本時，若是使用了傳說中的人物，必定要注意這些人物是屬於那一類傳說的(傳說人物分類見下表)。若是同時出現了兩類或兩類以上傳說中的人物，則必定要安排好根據，不可亂來，不然是要鬧笑話的。傳說 表明人物 能夠聯繫在一塊兒的傳說 
中國上古傳說 女媧、盤古 中國道教傳說 
中國道教傳說 玉皇大帝 中國上古傳說、佛教傳說 
佛教傳說 西天如來、南海觀音 中國道教傳說 
希臘傳說 宙斯、雅典娜 　 
基督教傳說 上帝、耶穌
4、美工與電腦美工
　　美工與電腦美工，一樣都是美工，曲別隻在於美工是在紙上繪畫；而電腦美工是在電腦上繪畫的；一樣都是繪畫，因此我建議您：讓您的美工與電腦美工互相兼職。
　　無論美工與電腦美工是否互相兼職，都有一個問題，那就是：電腦遊戲中的畫怎麼畫？通常來講分三步完成：1、由美工人員在紙上畫好原畫。2、由電腦美工將原畫繪製在電腦上。3、由美工指點，電腦美工對電腦上的畫做進一步修改。若是您有掃描儀的話，那麼就要輕鬆一些了。
　　下一步是決定遊戲的畫面風格。在第二章《遊戲策劃》裏，咱們介紹了四種繪畫風格，日式、美式、中式和中式漫畫。由效果來說，最好是採用中式。可是有一個問題就是：您的美工和電腦美工有這麼高的水平嗎？不是我刻意貶低，而是這種畫面風格確實太難做到了。因此我推薦您採用中式漫畫的畫面風格。中式漫畫，是由中國的傳統漫畫和日式漫畫融合演變而來的。它的特色是線條細而多、可以充分表現出人物的特色。因爲其色彩使用簡單明瞭，因此特別適合高清晰度(*0x480及以上)遊戲的製做。可是，因爲中式漫畫的線條要求細膩、清晰。並且細條的數量明顯要比日式漫畫多的多(大約在10倍左右)。何況咱們的一些「畫家」也畫慣了日式漫畫，因此無形中加大了美工人員的難度和工做量。 　　這裏列舉了幾條美工和電腦美工人員在繪畫時所要注意的要點，請參閱：
日式漫畫只要求外形同真實一致，而忽略了立體感；而中式漫畫不但要求外形同真實一致，還要求可以經過線條來表現出立體感。因此美工在繪畫時必定要注意立體感。
線條要求細膩、流暢。
美工在繪畫時要注意，有些繪畫手法是不能使用的。好比模糊效果，由於這些效果到了電腦上是沒法完成的。
同時美工還要注意到，在繪畫時，應儘可能保證線條清晰。若是線條不清晰，到了電腦上也是沒法完成的。
電腦美工在電腦上繪畫時，首先要作到的是圖畫比例。通常來講，人物寬度與屏幕寬度的比例是1:10，即10我的物正好放滿一屏。人物寬度與人物高度的比例是1:5。
人物或物品以及場景的大小比例應和真實世界一致。 
電腦美工使用繪畫軟件繪畫時，應在真彩色模式下做圖，並將軟件的Antialias(鋸齒平滑)功能打開。可是，在畫一些透明的畫時，人物或物品與透明區域交界處的線條在畫時應將Antialias功能關閉。
電腦美工將圖畫畫好後，應將畫中的部分輪廓線抹去。
不要去力求逼真，由於那樣純粹是自找麻煩。
　　若是您本身不是一位「畫家」的話，能夠去找別人幫你畫。可是別找的太遠，由於那樣您對他就很難進行管理。還有最重要的一點，若是您要造商業化的遊戲的畫，千萬不要從別人的遊戲中「竊取資源」，後悔藥可很差吃哦！
5、程式設計一──選擇一種計算機語言(編譯器)
　　選擇一種合適您的計算機語言和編譯器，這對遊戲製做來講但是至關重要的。若是在遊戲製做到半中央發現這一語言編程不方便或編譯器很差，豈不讓人傷心。因此在造一個遊戲前必定要選擇好編程語言和編譯器。
　　我做爲同行，固然要向您推薦最好的語言與編譯器了，請看下錶：
　 語言 編譯器 優勢 缺點 
DOS C/C++ Borland C/C++ 至關普及，學習簡單。編程簡單，出錯少。 16位程序、速度慢、有*0k基本內存限制。 
HIGH C/C++ 速度快、性能好。 難學、太專業化。 
Microsoft C/C++ 　 16位程序、速度不是很快、有*0k基本內存限制。太專業化。 
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++的類哦！

6、程式設計二──是面向對象仍是面向過程
　　這一章，看題目應該知道，這是一個比較重要的選擇。
　　面向對象，是近幾年來新興起的一種編程手段。因爲其在Windows系統的幫助下迅速崛起，成爲明日之星的可能性與日俱增。照理說，面向對象的編程手法的確要比面向過程的手法要先進的多。然而，面向對象的編程也有着它的致命弱點。就拿C++在Windows98下編遊戲來講：若是以面向對象的形式進行編程的話，那麼在遊戲運行時，程序自動建立的類將會變的很是多。並且在進行消息循環時，有大部分的運行時間是掌握在Windows系統手裏。這將會大大影響遊戲的運行速度，《風雲》就是一個很好的例子，在一臺Pentium133上玩《風雲》慢的就像烏龜，而相同清晰度的《大富翁Ⅳ》在這一機型上卻奔跑如飛。固然，你也能夠在你的遊戲配置中標明「本遊戲最低配置爲PentiumⅡ300+*MB內存」
　　若是一個遊戲以面向對象形式編程的話，那麼它用到的類將會有成百上千個。此時若是將這一遊戲以面向過程的形式從新編寫的話，那麼它用到的類不會超過20個(Windows下的遊戲不會超過100個)。如此多的類固然會將遊戲的速度降到很慢。
　　固然，我不是故意貶低面向對象的編程手段。面向對象的編程手段用來編寫應用軟件那將是上上之選，而用來編遊戲可就有些不如面向過程了(如今)。
　　下面咱們以在面向過程的編程手法說明一下在一個角色扮演型遊戲中所須要的模塊(類)。
遊戲內部所用模塊
遊戲外部所用工具

圖片管理器
地圖編輯器
動畫編輯器
人物信息管理器
物品信息管理器
劇情腳本編輯器
音樂管理器
聲音管理器
　　在上表中，左邊的結構圖是一個角色扮演型遊戲中至少要用到的模塊(類)，右邊的是你本身所要用到的幾個工具。這些模塊和工具在一個遊戲中能夠說是必不可少的，有些編程人員喜歡將這些全部的模塊和工具造在一些，便出現了所謂的調試模式。其實這是一個很很差的習慣，由於一個遊戲原本就是一個很大的程序集合。光是遊戲自己所必須的模塊就已經使遊戲程序變得很大了，若是再加上一些對玩家來講沒有用的工具，那你想一想：這個遊戲程序會變得多麼大。因此我認爲遊戲模塊應與工具徹底分開。 　　下面按步驟講一下每一個模塊與工具的工做範圍。
顯示控制：對顯示器、顯示卡進行管理，負責初始化顯示模式及畫面的高速顯示。提供基本的操做函數，有畫點、畫垂直線、畫水平線、畫空心矩形、畫實心矩形這幾個函數便可。再提供幾個特殊處理的函數，好比淡入淡出、屏幕閃爍等。 
字符管理：故名思義，管理對字符的顯示操做。負責讀取字庫，並使用顯示模塊提供的基本操做函數顯示字符。(若是您以爲在顯示字符上也要提升速度的話，那麼您能夠將字符管理模塊和顯示控制模塊編寫到一塊，在顯示字符時搞直接寫屏。能提升字符顯示速度15%)
窗口控制：別理解錯了，這一模塊主要用於在遊戲中菜單、選擇項、提示信息的顯示。
圖片管理：這一模塊按每一個人遊戲的習慣不一樣分爲兩類：
1、有些人造遊戲沒有圖片管理模塊，而在窗口控制、人物管理、物品管理、地圖控制、動畫控制這幾個模塊中各自創建相互獨立的圖片庫。這樣作的好處是每一個圖片庫相互獨立，不會混淆。壞處是必須給以上每一個模塊都配備一個圖片管理模塊，使遊戲程序變大。並且每一個圖片庫之間的圖片不能互相調用，有時會形成沒必要要的浪費。
2、我推薦使用第二種方法：只造一個圖片管理模塊，將全部的圖片(動畫圖片能夠除外)，包括提示圖像、人物、物品、地圖及其它圖像均放於一個圖片庫中。好處是減小了圖片控制模塊，並且一個圖片能夠供多個模塊調用。
動畫控制：很好理解的，控制動畫的嗎！
地圖控制：必定要注意，這一模塊只負責管理地圖庫、組建地圖，但並不負責顯示地圖。
人物管理：管理每一個人物的信息(不包括對話信息)。
物品管理：管理每一個物品的信息。
音樂管理：管理全部的音樂及其播放，音樂文件通常使用MIDI格式，若是你水平高點可使用MP3格式。
聲音管理：管理全部的聲音及其播放，聲音文件是WAV和VOC格式任選。
劇情控制：最大、最難、最複雜的一個模塊。管理其它的所有模塊，負責整個遊戲的劇情發展。
戰鬥控制：負責站鬥啦！
本身用的工具嗎，介紹一下：
圖片管理器：負責管理圖片庫，要求能夠隨意加入、刪除圖片，爲圖片庫創建索引以便遊戲調用。
地圖編輯器：編輯地圖用的嗎！用它來造地圖，而後造成專用的文件格式。
動畫編輯器：造動畫用的，若是懶的造動畫那就算了。 
人物信息管理器：編輯人物信息的工具。
物品信息管理器：編輯物品信息的工具。
劇情腳本編輯器：又是最大、最難、最複雜的一個，用來編寫劇情文件用的。
音樂管理器：管理音樂庫的工具。
聲音管理器：管理聲音庫的工具。 
　看完了，是否是要趴下了！沒事，慢慢來嗎！一我的造個遊戲最快也要2年！
程式設計三──顯示方面的程式設計
　　上一章裏，咱們說明了做爲一個遊戲的程式設計所須要完成的工做。在這一章，咱們將有關圖形方面的程式設計內容詳細給你們說一下。
　　首先申明一下，不管您的遊戲採用那一種清晰度，本文所說的內容都適用於您。
　　1、2D驅動程序
　　若是是編寫Windows9x下游戲的話，2D顯示驅動程序的表明做主要有Microsoft公司推出的DirectX中的DirectDraw和SciTech公司的WinDirect、MGL。
　　在DOS 下就顯得有些問題，如今市面上的顯示卡類型很是多，若是咱們給每個顯卡都編寫一個驅動程序的話，那恐怕是至關困難的。再說咱們也不可能擁有每一種顯卡的詳細資料。幸虧在各類SVGA顯示卡出現不久，由各大廠家聯合推出了一個VESA標準。如今的顯卡幾乎能夠說是所有都只持VESA標準。因此，咱們只要按VESA標準進行顯示卡編程，就能夠得到最大的兼容性。
　　2、3D驅動程序
　　編寫3D遊戲的話，3D驅動程序接口無非就是OpenGL和Direct3D兩種。若是你想編寫Windows下的遊戲的話，那麼選擇那一個都同樣。若是編寫DOS遊戲的話，使用OpenGL固然不會錯。
注：因爲3D遊戲所涉及的範圍較大，因此在之後咱們將不討論3D遊戲的製做。
(到SciTech公司的網頁上去轉轉，這個公司提供的WinDirect、MGL開發庫提供了完整的2D與3D支持(DOS/Windows9x)，並且還提供了DOS下的OpenGL 3D引擎)注：MGL開發庫同時有DOS版和Windows9x版。
　　3、無規則圖片庫的管理
　　這裏所說的圖片庫包含了整個遊戲所使用到的任何圖片，想必您也能夠猜到，這個圖片庫將會變得至關大。如何管理這樣一個數據量極大的圖片庫，成了如今的首要問題。
　　遊戲中所使用的圖片有大有小，也就是說，圖片庫中的圖片數據長度不固定。這也爲咱們管理圖片庫增長了難度。
　　圖片管中的圖片位置是無規律的，可是咱們能夠創建一個有規律的索引表來管理這個圖片庫。由於每一個圖片的索引長度是同樣的，也就是說是有規律的。這樣一來，管理就容易多了。 
　　索引文件的基本結構以下：
文件頭，圖片個數，第1個圖片在圖片庫中的地址，……，最後一個圖片在圖片庫中的地址
　　圖片庫的基本結構以下：
文件頭，第1個圖片的數據，……，最後一個圖片的數據
　　然而，就算是這樣，整個圖片庫的管理仍然不方便。好比說有一張圖片的編號是105，而在中途咱們刪除了第85張圖片。當下次再調用第105張圖片時，就會發現調用的是原來的第106張圖片。爲了解決這個問題，咱們將索引文件的結構改進以下： 
索引結構:
struct PicIdx
{
char PicName[10]; //圖片名稱
unsigned int high,width; //圖片大小
unsigned long offset; //圖片在圖片庫中的地址
};
圖片索引文件結構:
文件頭,圖片個數,第1個索引(PicIdx),……,最後一個索引(PicIdx)
　　能夠看出，咱們爲索引增長了一個項目：圖片名稱。這樣作的好處是，咱們在調用圖片時，能夠按圖片名稱進行調用。之後不管是增長仍是刪除圖片庫中的圖片，均可以保證圖片調用正確。
　　4、有規則圖片庫的管理
　　有規則圖片庫相對於無規則圖片庫來講管理起來就要方便的多了。這裏說的有規則是說每個圖片的大小都一致，也就是說數據長度都一致。這樣的圖片庫最點型的就是人物圖片庫，以人物圖片庫爲例，圖片索引文件結構以下： 
文件頭，圖片個數，第1我的的姓名，……，最後1我的的姓名
　　5、對話框的處理
　　在遊戲中，對話框是少不了的，特別是角色扮演型遊戲。對話框的主要類型有：菜單、信息顯示框、邏輯選擇框、多項選擇框、買賣物品框、人物信息框等等。在這一點上，設計者能夠按本身的意欲隨意設計。不過要注意的是風格要保持一致。
　　從下一章開始，將細緻講述有關顯示方面的程式設計，分別是《圖片庫的壓縮保存》、《虛擬屏幕的編程》、《地圖引擎的製做》、《屏幕特殊效果的處理方法》。 
程式設計四──圖片庫的壓縮保存
　　咱們知道，隨着遊戲畫面清晰度的不斷提升，遊戲所佔用的硬盤空間也在不斷增大。爲此，咱們有必要將有些大容量的數據作壓縮保存，圖片庫就是一個很好的例子。
　　首先要談到的就是壓縮算法問題，如今的壓縮算法不少，選擇那一種好呢？你們必定會想到在網頁上經常使用到的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，通過隔行抽絲後，在顯示時的大小就是800x300。因此在保存時咱們能夠將圖像或動畫保存成800x300的，這可謂正宗的隔行抽絲了，惋惜效果很差。其實，咱們只要將圖像或動畫保存成400x300的就能夠了。在顯示時將寬度放大一倍，不但節省了硬盤佔用空間，並且效果很不錯。不過會使裝入速度減慢，但也不失爲良策。
　　我另有一個建議，隔行抽絲通常是使用在動畫上的。若是使用隔行抽絲技術，將畫面保存成400x300，顯示時不但會使動畫裝入速度減慢，並且效果遠不如隔行抽絲前的好、播放的速度也快不了多少。我認爲，使用隔行抽絲技術在800x600顯示模式下播放400x300的動畫，還不如直接將顯示模示動態的改成400x300。不但效果很好，並且在速度上比使用隔行抽絲技術要快的多。反正是放動畫，在切換顯示模式時的屏幕閃爍也並沒關係。
　　(有一個事實，在《超時空英雄傳說Ⅱ復仇魔神》中，是將動態的將顯示模式由*0x480切換爲320x240放動畫的。而在《超時空英雄傳說Ⅱ外傳北方密使》中，是使用的隔行抽絲技術播放動畫的)

--------------------------------------------------------------------------------
16位加強色顯示模式下的淡出處理
　　淡入淡出，想必各位同行、玩家不會不清楚。在256色等使用調色板的遊戲中，淡入淡出的實現很是簡單，直接修改調色板就能夠了。在24位或32位真彩色顯示模式下，雖不使用調色板，但實現也很簡單，直接修改顯示的數據就能夠了。但畢竟24位或32位真彩色顯示模式使用的很少，而漸漸被使用的是16位加強色顯示模式。在16位加強色顯示模式下，因爲它並不使用調色板，因此要實現淡入淡出也必須直接修改顯示數據。
　　但因爲在16位加強色顯示模式下，三原色數據被段存放在二個字節中。若是不使用MMX技術，在操做時必須按位分解出來才能進行操做，但這樣一定會使操做速度變慢。雲風提意將每一個點的數據擴展成32位再進行操做，但速度也不會很快。
　　這裏，我提出一種方法，自行測試效果不錯，速度也不慢。可是很不容易說清楚，列個表給你們看吧！將純白色變成純黑色。
數聽說明：1111111111111111，左邊16位數據中，0-4位(佔5位)表示紅色，5-10位(佔6位)表示綠色，11-15位(佔5位)表示藍色。
步驟 數據 解釋說明

1 1111111111111111 本來數據

2 1111111111011111 將綠色第六位變成0，因爲綠色多一位，因此先寫它 3 1111011111011111 將紅色第五位變成0 4 1111011110011111 將綠色第五位變成0 5 1111011110011110 將藍色第五位變成0 6 1110011110011110 將紅色第四位變成0 7 1110011100011110 將綠色第四位變成0 8 1110011100011100 將藍色第四位變成0 9 1100011100011100 將紅色第三位變成0 10 1100011000011100 將綠色第三位變成0 11 1100011000011000 將藍色第三位變成0 12 1000011000011000 將紅色第二位變成0 13 1000010000011000 將綠色第二位變成0 14 1000010000010000 將藍色第二位變成0 15 0000010000010000 將紅色第一位變成0 16 0000000000010000 將綠色第一位變成0 17 0000000000000000 將藍色第一位變成0 　　不管顯存中的數據是什麼，咱們都按這個順序將16位數據均寫入0便完成了淡出的效果。