from :
原著：radu privantu
翻譯：panic
2023年5月11日
原文出處：a beginner』』s guide to creating a mmorpg
我注意到很多人在不同的論壇發帖子尋找團隊開發mmorpg。他們中的大部分是這樣：「我們成立了乙個公司/遊戲工作室，需要3個美工，兩個程式，1個 **製作，等等。為了創新，不要看過去的mmorpg，你有全部的自由用來創造你想要的世界，等等。 我們會在專案完成並賺到錢的時候付給你酬勞，等等」。不幸的是，以現有的技術和頻寬，你無法擁有乙個動態的世界。 朝向無法到達的目標前進只會導致失敗。正確的做法是拿出一些小規模的，功能性強的，可擴充套件的設計和構架。,
基本軟體構架
首先，嘗試建立乙個簡單的c/s模型，有如下功能：
建立乙個新角色；
儲存那個角色(伺服器端)；
用那個角色登陸；
能夠和其他人交談；
能在3d空間遊覽；
儲存角色看起來簡單，其實不然。 例如，有兩種方式儲存角色：使用資料庫服務或者使用檔案。兩者有各自的優缺點：
又是看起來很簡單，其實不然。你不能只是傳送』』\0』』結尾的串。因為你需要乙個通用的協議，能同時適用字串和二進位制資料。用0(或其他字元)做結 束符是不明智的，因為那個結束符可能是你要傳送的資料的一部分。此外，如果你傳送20位元組，然後再20位元組，伺服器極有可能收不到兩個20位元組的包。取而 代之的是，它會一次性收到40位元組，為了避免浪費頻寬在不必要的頭上。 而且，你可以傳送1kb的包，但伺服器會以兩個小包的形式收到它。所以你必須知道**是乙個包的開始，**是結束。在 「永恆大陸」(譯者注：原文： ete
al 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 。沒有做這些會嚴重挫傷你和其他使用者。類似的，要檢查超出地圖座標。如果你的伺服器有某種尋路演算法，並且客戶端通過點選地面來移動，確保他們不要點選在地 圖外部。
第六步：獲得乙個團隊
這篇文章作者是 radu privantu, 永恆大陸(eteal lands) www.eteal-lands.com 的主程式和專案規劃, 永恆大陸是一款免費，客戶端開源的mmorpg。作者可以通過 [email protected] 聯絡。
MMORPG開發雜談（二） 訊息處理框架
這樣做的乙個好處是，可以有子模組向上申請自己關心哪些訊息，避免父模組越來越複雜。附code list 1 pragma once class msgdelegate virtual msgdelegate int m msgid class nontypedelegate public msgdel...
MMORPG大型遊戲設計與開發（規範）
一件事如果沒有規範 章法，那麼做這件事起來往往會遇到許多難題，特別是在多人協作的時候，沒有到規範通常讓每個人多多少少都面臨著頭疼的困難。舉個例子，多個人要做一桌美味的餃子，有買材料 做麵皮 弄肉 菜 餡等。如果沒有分工，做麵皮的人也可以去弄肉餡，買材料的人也可以由弄肉餡去，這樣一來可能導致這一桌香噴...
MMORPG負載均衡機制
mmorpg負載均衡機制 1.靜態分布玩家到伺服器 平均分配玩家給每個server，使每個server有相同數量的玩家。這種方法的優點是演算法簡單，但玩家在地圖上移動，因此過一段時間，最差的情況下，server之間可能有大量的網路流量，因為當玩家在完成乙個動作後，所有的server必須獲得另乙個se...