作者： Radu Privantu
譯者：pAnic 2005年5月11日
原文鏈接：http://www.devmaster.net/articles/building-mmorpg/
譯者序：這是一篇講解如何開發一款MMORPG的入門文章，作者本人也是一款游戲的開發者，文中的內容源于實踐，有很高的參考價值。很多人都想擁有自己的游戲，這篇文章對那些想自己開發游戲的人來說可能是一紙福音，也可能是一盆冷水。無論如何，開發游戲都不是一件簡單的事情。
以下是翻譯正文：
|
[/td]
|
文章的中心是如何起步開發你自己的 大型多人在線角色扮演游戲( 原文：Massive Multiplayer Online Role Playing Games) (MMORPG)(譯者注：俗稱：網絡游戲，網游)。 針對的讀者是經驗和資源有限的開發者。 讀完文章之后，你應該懂得如何起步， 還有一些關于什么是應該做的和不應該做的忠告。第一步是評估你的能力和資源。你必須對自己誠實，因為做你力不從心的事情會浪費你的時間并讓你心灰意冷。
第一步：評估你的能力必須的技能:
- 懂至少一種編程語言。 迄今為止， C++因為性能和效率的優越性成為游戲開發者的首選。 Visual Basic, Java 或者 C# 可能也是不錯的選擇。
- 熟悉一種圖形庫。通常的選擇是SDL, OpenGL, 或者DX/D3D。(譯者注：網上也有很多免費/付費引擎下載和出售)
- 選擇一種網絡通訊庫。 你可以從WinSock, SDL_net, 或DirectPlay中選擇。(譯者注：很多人喜歡開發自己獨特的網絡庫，這并不復雜，似乎ACE也是一種選擇)
- 對游戲開發有大體的經驗。 例如，事件循環， 多線程， GUI 設計，等等。
強烈推薦的技能:
- C/S結構通訊。
- 多平臺開發。 你可能希望設計一個MMORPG, 尤其是服務器能運行在多種操作系統。為此，我推薦使用SDL, OpenGL 和SDL_net。
- 網站開發。如果你想讓用戶通過網站查看玩家統計，服務器信息和其他信息，這是必須的。(譯者注：其實網站可以交給其他人開發，如果有必要的話)。
- 安全管理。 你當然不想因為有人攻擊你的服務器而浪費時間！
- 團隊組織能力。 你需要一個你能成功領導和管理的團隊。
第二步：初步規劃我注意到很多人在不同的論壇發帖子尋找團隊開發MMORPG。他們中的大部分是這樣：“我們成立了一個公司/游戲工作室，需要3個美工，兩個程序，1個音樂制作，等等。為了創新，不要參考過去的MMORPG，你有全部的自由用來創造你想要的世界，等等。 我們會在項目完成并賺到錢的時候付給你酬勞，等等”。 不幸的是，以現有的技術和帶寬，你無法擁有一個動態的世界。 朝向無法到達的目標前進只會導致失敗。正確的做法是拿出一些小規模的，功能性強的，可擴展的設計和構架。
基本軟件構架首先，嘗試創建一個簡單的C/S模型，有如下功能：
- 創建一個新角色
- 保存那個角色(服務器端)
- 用那個角色登陸
- 能夠和其他人交談
- 能在3D空間游覽
保存角色看起來簡單，其實不然。 例如，有兩種方式保存角色：使用數據庫服務或者使用文件。兩者有各自的優缺點：
|
數據庫 |
文件 |
| 優點 |
- 添加新域或者修改現有的都很簡單。
- 更新玩家統計數據非常簡單(從游戲外)。
- 你可以通過SQL查詢方便的獲取不同種類的統計結果。
- 無需自行完成I/O操作，數據庫會替你做好。
- 易于更新/恢復。
|
- 高速操作(讀/寫)。
- 實現簡單。
- 無需額外的庫。
- 不依賴數據庫服務器。因此你不必擔心數據庫升級或安全問題。
|
| 缺點 |
- 容易出錯。 例如，做一個更新查詢的時候遺漏了'where'子句。會導致慘痛的損失，尤其是你沒有備份的時候。
- 數據庫會比打開/寫入一個玩家檔案文件慢。你查詢一些數據的時候會耗費幾個毫秒，尤其是大量玩家同時登入/登出的時候。
- 需要額外的代碼進行游戲和數據庫間的數據轉換。
- 需要操作數據庫和SQL的經驗。并且需要一個程序和數據庫之間的接口庫。
- 如果因為某些原因數據庫文件損壞，那算你倒霉，你可能會丟失所有的玩家數據(尤其是短期內沒有備份的時候)。
|
- 很難添加新的域，除非一開始就很小心的設計了文件的格式/結構。
- 沒法做全體玩家的查詢。(這可以通過每天晚上用程序把重要字段添加進一個數據庫間接實現)。
- 如果你想更新/檢查玩家狀態，你必須額外寫代碼。
- 更新和還原比較復雜。
|
現在你決定了如何存儲角色，你還得選擇C/S通訊的網絡協議：TCP 還是 UDP？,我們都知道TCP速度慢，但是更準確，并且需要額外帶寬。我實際使用TCP并沒有遇到什么問題。 如果你有充足的帶寬，TCP是個好選擇，至少對初學者是這樣。 UDP 會很麻煩，尤其是對新手。 記住，游戲或引擎的初步測試會在你的局域網進行，所有的包都會按順序依次抵達。在Internet上無法保證這一點。雖然包會按順序到達，但是有時候會丟包，這通常是個麻煩事。 當然，你可以設計你的協議使得C/S能夠從丟包中恢復。但這對初學者來說很痛苦，不值得推薦。
第三步：選擇數據傳輸協議又是看起來很簡單，其實不然。你不能只是發送'\0'結尾的串。因為你需要一個通用的協議，能同時適用字符串和二進制數據。用0(或其他字符)做結束符是不明智的，因為那個結束符可能是你要發送的數據的一部分。此外，如果你發送20字節，然后再20字節，服務器極有可能收不到兩個20字節的包。取而代之的是，它會一次性收到40字節，這是為了避免浪費帶寬在不必要的頭上。 而且，你可以發送1KB的包，但服務器會以兩個小包的形式收到它。所以你必須知道哪里是一個包的開始，哪里是結束。在 “永恒大陸”(譯者注：原文： Eternal Lands，本文的作者正在開發的一款MMORPG)中，我們用如下的方法：
- Offset 0: 1 字節 表示傳輸的命令。
- Offset 1: 2 字節，傳輸的數據長度。
- Offset 3: 變長，消息內容。
這種方法有一致的優點：所有的數據傳輸有統一的標準。缺點是有些命令有固定已知的長度，浪費了一些帶寬。以后我們會改成混合的方法。
下一件事是決定服務器模型： “非阻塞soket,不使用線程”，或者“阻塞soket，使用線程”。兩種方法(使用線程 vs 不使用線程)各有優缺點。
線程:
- 服務器響應會更加平滑，因為如果一個玩家需要大量時間(例如從數據庫中讀取數據)，這會在它自己的線程中完成，不會影響其他人。(譯者注：也許作者的意思是每個玩家都有獨立的線程，但這對MMORPG不太現實)
- 難以恰當的實現和調試：你可能需要大量同步，并且一個小疏忽就會導致災難性的后果( 服務器癱瘓，物品復制，等等)。
- 可以利用多處理器。
無線程:
在我的公司，我們使用無線程的方法，因為我沒有足夠的資源和人力處理線程模式。
第四步：客戶端你打算做2D還是3D游戲？有些人認為2D游戲做起來簡單。我兩者都做過，并且我傾向于3D游戲更簡單。容我解釋。
2D下，你通常有一個幀緩沖，也就是一個巨大的象素點數組。象素點的格式會因顯卡的不同而不同。 有些是RGB模式，另一些是BGR模式，等等。每種顏色的bit數也會不同。只有在16bpp模式才有這個問題。8-bit和24-bit模式簡單一些，但有他們各自的問題(8-bit顏色數太少(256)，而24-bit速度更慢)。同時，你需要制作你的精靈動畫程序，不得不自己排序所有對象，以便他們以正確的順序繪制。 當然，你可以用OpenGL或者D3D制作2D游戲，但通常這并不值得。并不是所有人都有3D加速卡，所以使用3D庫開發2D游戲一般會帶給你兩者的缺點：不是所有人都能玩，你也不能旋轉攝像機，擁有漂亮的陰影，和3D游戲炫目的效果。(譯者注，目前絕大部分顯卡都支持565的16bpp格式，這個也成為目前16位色的業界通用格式，有不少文章和代碼都是講述這一格式下圖像處理的，尤其是使用MMX技術)
3D的途徑，正如我所說，更簡單。但是需要一些數學(尤其是三角)的知識。現代的圖形庫很強大，免費提供了基本的操作(你不需要從后到前排列對象，改變物體的色彩和/或帖圖都十分簡單，對象的光照會按照光源和它的位置計算(只要你為它們計算了法向量)，還有更多)。并且。3D給了你的創作和運動更多的自由度，缺點就是不是所有人都能玩你的游戲(沒有3D卡的人數可能會讓你大吃一驚的)，并且，預渲染的圖片總是比實時渲染的更漂亮。(譯者注：市面上想買不支持3D的顯卡目前很困難，只是高性能的3D卡價格也不低)
第五步：安全顯然，不能相信用戶。任何時候都不能假設用戶無法破解你精巧的加密算法(如果你使用了的話)或者協議，用戶發送的任何信息都要通過驗證。極有可能，在你的服務器上，你有固定的緩沖區。例如，通常有一個小(可能是4k)緩沖區用來接收數據(從soket)。惡意用戶會發送超長數據。如果不檢查，這會導致緩沖區溢出，引起服務器癱瘓，或者更壞的，這個用戶可以hack你的服務器，執行非法代碼。每個單獨的消息都必須檢查：緩沖區是否溢出，數據是否合法(例如用戶發送“進入那扇門”，即使門在地圖的另一端，或者“使用治療藥水”盡管用戶沒有那種藥水，等等)。 我再次強調，驗證所有數據非常重要。一旦有非法數據，把它和用戶名，IP，時間和日期，和非法的原因記錄下來。偶爾檢查一下那個記錄。如果你發現少量的非法數據，并且來自于大量用戶，這通常是客戶端的bug或者網絡問題。然而，如果你發現從一個用戶或者IP發現大量非法數據，這是明顯的跡象表明有人正在欺騙服務器，試圖hack服務器，或者運行宏/腳本。同時，決不要在客戶端存儲數據。客戶端應該從服務器接收數據。換句話說，不能發送這樣的消息“OK，這是我得物品列表”或者“我的力量是10，魔法是200，生命值是2000/2000”。 而且，客戶端不應收到它不需要的數據。例如：客戶端不應該知道其他玩家的位置，除非他們在附近。 這是常識，給每個人發送所有玩家會占用大量帶寬，并且有些玩家會破解客戶端從中獲取不公平的利益(像在地圖上顯示特定玩家的位置)(譯者注：就像傳奇的免蠟燭外掛)。所有這些似乎都是常識，但，再次，你會驚奇的發現有多少人不知道這些我們認為的常識。
另一個要考慮的問題，當涉及到安全：玩家走動的速度必須在服務器計算，而不是客戶端。(譯者注：這是重要的原則，但是會耗費大量服務器資源。魔獸世界沒有這樣做，它采用類似其他玩家揭發的形式掩蓋這個事實，導致加速外掛可以用，但是在有其他玩家的時候會暴露)。服務器應該跟蹤時間(以ms為單位)當客戶最后一次移動的時候，并且，移動的請求如果比通常的極限更快到來，這個請求應該被拋棄。不要記錄這類虛假請求，因為這可能是因為網絡延遲(也就是玩家延遲，過去的10秒內發送的數據同時到達了)。
檢查距離。如果一個玩家試圖和100億公里以外的玩家交易(或者甚至在另一張地圖上)，記錄下來。如果一個玩家試圖查看，或者使用一個遙遠的地圖對象，記錄它。小心假的ID。例如，正常情況下每個玩家都會分配一個ID(ID在登陸的時候分配，可以是持久的(唯一ID)。 如果ID在玩家登陸的時候賦予9或怪物被創建的時候)，顯然可以用玩家數組(保存玩家)的位置(索引)作為ID。
所以第一個登陸的玩家ID是0，第二個是1，依此類推。現在，通常你會有一個限制，比如說2000個索引在玩家列表里。所以如果一個客戶端發送一條命令類似：“查看ID200000的角色”，這會使服務器當機，如果沒有防備的話，因為服務器會訪問非法的內存區域。所以，一定要檢查，就像這樣： "if actor id<0 or if actor id> max players 然后記錄非法操作并且斷開玩家。如果你使用C或者C++，注意或者定義索引為'unsigned int' 并且檢查上限，或因為某些原因定義為int(int,默認是有符號的)，記得檢查 <0 and >max 。沒有做這些會嚴重挫傷你和其他用戶。類似的，要檢查超出地圖坐標。如果你的服務器有某種尋路算法，并且客戶端通過點擊地面來移動，確保他們不要點擊在地圖外部。
第六步：獲得一個團隊制作游戲需要大量的工作(除非是個Pong and Tetris游戲)。尤其是MMORPG。你無法單靠自己。理論上，一個完整的團隊組成是這樣：
- 至少3 個程序員： 1 個做服務器，兩個客戶端(或者一個客戶端，一個負責工具，例如美術插件，世界編輯器，等等)。有6個程序員是最好的，更多就沒必要了。這取決于你的領導能力。最少一個美工，2到3個更合適。如果這是個3D游戲，你需要一個3D美工，一個2D美工(制作帖圖，界面，等等)，一個動畫師，和一個美術部負責人。美術部應該由有經驗的人組織和安排，除非你就是個藝術家。,
- 少數世界構建者:創建所有地圖是個漫長的過程， 并且直接關系到游戲的成敗。再次，你需要一個世界構建部的負責人。你的世界需要協調一致，所以不能只有一個意氣用事的人。
- 一個 網站管理員是必須的，除非你精通網站設計，并且愿意花時間做網站。音效和音樂不是必須的，但是有音效和音樂的游戲比沒有的會更吸引人。
- 一個游戲經濟系統 設計師.。你也許覺得那很簡單，可以自己來做，但事實上那是最復雜的工作之一。如果經濟系統設計不良(比如物品沒有平衡，資源在地圖上隨意放置，等等。)玩家會覺得無聊并且退出游戲。我們早期的進展存在很大的問題，尤其是因為經濟系統主要是由我(一個程序員)設計的，它沒有被恰當的計劃。 于是，我們花費了兩個月來重新思考和建立一整個新的經濟系統。這需要一次完全的物品清除。我告訴你，玩家會很不樂意你刪除他們的物品。幸運的是，大部分玩家贊同這個想法，但是這么多小時的爭論，妥協，解釋和時間的浪費還是讓我們喪氣。以后會更多。
如前所說，你需要一個10~15人的團隊，不包括協調員和管理者。這10~15人必須是有經驗的。如果都是新手就不值得，因為你需要花大量時間解釋要做什么，怎樣做，為什么他現在的做法不好，等等。
一開始就湊齊10~15人幾乎是不可能的。不管你在不同的論壇發多少帖，你也無法找到合適的團隊成員。畢竟，如果一個人在他/她的領域得心應手，為什么在你無法拿出任何東西的時候他/她要加入你的團隊？很多人有遠大的想法，但是實現它們需要大量時間和努力，所以他們寧可從事自己的工作也不會加入你。那如果你需要10~15人，但是無法讓他們加入你的團隊，你如何才能制作一款MMORPG呢？ 好，事實上，你一開始不需要所有人都到位。你真正需要的是一個程序員和一個美工。如果你是個程序員，只要找個美工就可以了。請求懂美術的朋友幫忙，花錢請大學生/朋友做一些美術或者其他工作。
現在你有了一個美工，你期待的游戲的樣子，現在可以開始實現了。一旦你有了可以運行的C/S引擎，一些用來展示的截圖(或者更好，玩家可以登陸你的世界，四處走動，聊天)，更多的人會愿意加入你的團隊。更恰當的是，除非你使用獨有的技術，否則你的客戶端可以開源。許多程序員會加入(作為志愿者)一個開源工程而不是非開源項目。而服務器不應該開源(除非你打算做一款完全開源的MMORPG)。
其他一些忠告：在有東西可展示之前，不要夸大你的游戲。最惹人煩的事情之一就是一個新手發一個“需要幫助”的請求，并且解釋這個游戲到底有多酷，最后要求一個巨大的團隊加入他的游戲制作。一旦你擁有了網站廣告(通常是在一個免費主機)，你會看到一個吸引人的導航條，包含“下載”，“截圖”，“ 原畫”(譯者注，原文：Concept art，概念藝術，在游戲應該指美工的原始設計)，“論壇”。你點擊下載鏈接，然后看到美妙的“建設中”頁面(或者更糟糕，一個404錯誤)。然后你點擊截圖，得到同樣的結果。如果你沒有東西給人下載，就不要放下載鏈接。如果沒有截圖展示，不要放截圖鏈接。然而更好的是，在工程進展10%(程序和美工)之前，不要浪費時間在網站上。
第七步：打破某些神話
- 你無法制作MMORPG, 只有大公司才可以。
我不同意。雖然制作一款像魔獸世界(World of Warcraft)，無盡任務2(Ever Quest 2)，亞瑟王的召喚2(Asheron's Call 2)，血統2(Lineage 2)，和其他一些游戲對一個小型的自發團隊是不可能的，但是做一款像樣的游戲還是可以的，只要你有經驗，動機，和時間。,你需要1000小時的編程來制作一個可運行的測試版，大概10~15k小時完成幾乎完整的客戶端和服務器。但是作為團隊領導者，你不能只編程。保持團隊團結，解決爭執，維護公共關系(PR)，技術支持，架設服務器，懲罰搗亂分子，自由討論，等等都是你的職責。你可能會被非編程的任務淹沒。你很可能需要上班/上學，這減少了你花費在項目上的時間。我們很幸運，沒有成員離開團隊，但是如果這種事情發生，那的確是大問題。假設你的美工半途離開。或者更糟糕，他/她沒有給你使用他/她作品的許可。當然這可以通過和他們簽訂合同來解決，但找另外一個美工仍然很麻煩。一個工程中有兩種不同的美術風格也是問題。
- 需要大筆金錢(通常 4-6 位數) 用來架設一個 MMORPG 服務器.
當然，這不是真的。我見過專業服務器，1000GB/月，不到100美元/月(2~300美元的初裝費)。除非你的數據傳輸協議設計非常不合理，1000GB/月對一個1000玩家在線(平均)的服務器來說足夠了。當然，你還需要另一個服務器做網站和客戶端下載(客戶端下載會占用大量流量，當游戲變得流行的時候)。我們的客戶端有22MB，有時候會有400GB/月的傳輸量。而我們還沒有很流行(仍然)。另一件事，我們不需要另一臺專用服務器開啟這個工程。ADSL/cable服務器可以勝任，直到你的同時在線人數達到20~30。然后要么找一個友好的主機公司，用廣告交換免費主機，要么就只能自己掏腰包了。
- 制作一個MMORPG很有趣。
這不是真的。你可能認為每個人都會賞識你，玩家會支持你，你標新立異，并且，當然，很多玩家都玩你的游戲。玩家可能讓人討厭。即使是完全免費的游戲，他們也能找到理由抱怨。更糟糕的是人們經常會抱怨矛盾的事。戰士會抱怨升級太難，商人會對戰士掠奪大量錢財很失望。如果你減少怪物掉落物品，有些玩家就會威脅說要退出游戲。如果你增加，同樣的一群人會不滿新手能更簡單賺錢的事實。 真是左右為難。改革和改進是必須的。如果你決定改變某些東西，例如給加工物品增加挑戰性，有些人會說太難了。如果你不做，他們又會說太簡單無味。你會發現滿意的玩家通常不會說什么并且感到滿意，同時破壞者會怨聲載道。
MMORPG的經濟比單機版難以平衡的多。在單機游戲，你可以逐漸改良武器，只要玩家進展，他/她可以使用更好的裝備，丟棄(或者賣掉)舊的。另一方面，在多人游戲里，這種觀點不成立，因為每個人都試圖得到最好的武器，而跳過低等級武器。大部分玩家寧可空手省錢，直到他們能買游戲中最好的武器。經濟系統設計要參考相關的文章。
迄今為止我列舉的所有事情，加上額外的工作和挑戰，足以讓你在決定涉足這個工程之前三思而行。你必須知道你的決定意味著什么。
總結希望這篇文章能給你足夠的知識。我的下一篇文章將介紹如何建立一個經濟系統(更明確的，要避免哪些錯誤)，還有一些調試服務器和客戶端的信息。
關于作者這篇文章作者是 Radu Privantu, 永恒大陸(Eternal Lands) www.eternal-lands.com的主程序和項目規劃, 永恒大陸是一款免費，客戶端開源的MMORPG。作者可以通過 chaos_rift at yahoo dot com 聯系。 |
posted on 2009-01-23 13:36
小王 閱讀(1457)
評論(0) 編輯 收藏 引用 所屬分類:
游戲服務器端開發