mud最新源碼

A. 哪個地方有俠客行100的MUD源碼

§人物水平：

掌門人：上上 exp >1000k lvl=100

一流高手：上 exp 500k-1000k lvl=80-100

高手：上偏下 exp 50k-500k lvl=60-80

重要人物、土匪大王、老虎、蟒蛇：中偏上 exp 10000-50000 lvl=40-60

官兵、打手、衙役、土匪小頭目、熊、鷹：中 exp 5000-10000 lvl=20-40

家丁、土匪、狼、毒蛇：中偏下 exp 1000-5000 lvl=10-20

工匠、流氓、狼狗、蛇：下偏上 exp 500-1000 lvl=10

農民、酒鬼、野狗、蝙蝠：下 exp 100-500

小孩、村姑、丫鬟、伙計、店小二、野貓、野兔：下下 exp <100

人物的神大約為其經驗的十分之一（即掌門人相當於十個曠世大俠或大魔王），正負視其正邪而定。動物沒有神。殺動物只長經驗。

同一水平的人物有不同的技能，各有特色。

§結婚：

男女雙方各花一張銀票向雜貨鋪老闆買戒指，再各花一張銀票給醉仙樓老闆辦酒席，當時在網上的玩家都可得到一隻烤鴨和一瓶女兒紅。然後雙方互相交換戒指戴上，就算結婚了。戒指會一直戴著，不會因為退出遊戲而消失，直到有一方死亡為止。

結婚的好處是可以互相學習武功，在能關門的地方就可以做愛而無需花錢到客棧，而且每次消耗的精減半。

§做愛：

玩家相互之間的，要由女方先發出love nick指令，男方回應love nick就行。非夫婦之能在客店二樓。夫婦只要找個能關門的地方即可。

嫖妓見麗春院說明。

英雄救美人：如果救出被財主關押的丫鬟、被土匪攔截的村姑，

對方示愛（只向神正的人示愛），回應love nick即可。

每次消耗一百點的精。如果服用春葯，在葯力有效期內，可減低為僅消耗五十點。（如果是夫婦，則相應減半）

好處：男女雙修，練精化氣，每次長10點精力和1點氣。

正派弟子若嫖妓，會損失十分之一的神。

§指令：

基本（所有的mud都有的）指令用英文：

alias, quit, save, passwd, who, finger, hp, look (l), n, w, s, e, d, u,

inventory (i), give, ask, drop, get, fight, kill, buy, go, open, set,

follow

特殊指令（本mud才有的）用漢語拼音。

常用物件英文、拼音兼用。

特殊物件用拼音。

人名、地名、功夫名用拼音。

§解謎能找到的寶物：

軟蝟甲：刀槍不入。

人形何首烏：增加1點悟性。

倚天劍

屠龍刀

避邪劍譜

連城訣

九陽真經

九陰真經

方舟子, 1995.10.

------------------------------------------------------------------------

科舉制度簡介

中國古代在大部分時期都是文官政府管理的（戰亂時期除外）。從隋朝開始，文官的挑選則採用科舉制度。對武官的挑選也有「武舉」，不過不象科舉那麼重要。

艱辛的科舉之路從五、六歲時便要開始。一般有錢人家會請一位教書先生到家裡給孩子啟蒙，沒錢請先生的便要去私塾上學。開始時總是先學「三百千」（三字經、百家姓、千字文），然後大些再學「四書」（論語、孟子、大學、中庸）「五經」（詩、書、禮、易、春秋）。到學得差不多了，就可以參加縣里的童生試，考過了便是童生。童生是科舉之途上的第一個台階。一般人在拿童生之後還要考些別的功名，可也有人一輩子就停在這，被戲稱為老童生。

通過了縣試，再去參加府試。府試通過了還是叫童生，不過就有了資格參加由省里的提督學院主持的院試，這是童生試的最後一關，考過了就成為生員，也就是俗稱的「秀才」。

秀才是正式成為知識分子的標志。當了秀才，就可以到縣里的學宮入學，領幾斗米補貼生活，也有一些特權，如見了縣官不用下跪。秀才沒官做，沒俸祿，又要一門心思准備考舉子，日子一般比較清貧，所以常聽到「窮秀才」之說。秀才每三年要參加兩次考試，稱為歲考，考得好的有獎，靠不好就要受罰，所以俗語說「秀才怕歲考」。如果一個秀才屢試不第，便會去教書，或幹些閑事而又自命不凡，如孔乙己；抑或一怒而反，如張角、王倫，或而當神仙了事，如呂洞賓。

秀才可到省城參加每三年一次的鄉試，通過了就是中舉，成為舉人了。舉人可算是高級知識分子，有了出身，通常可以做官，有俸祿，和秀才不可同日而語，所以也就分外得難

考。一但中舉，其父為（老）太爺，其人為老爺，其子為少爺，故有「一世中舉，三世為爺」之說。范進中舉之後的興奮當不難理解。鄉試的第一名叫做解元，比如唐伯虎就是解元。鄉試的前五名是從所考的五經中各取一名，叫做「五經魁」，合起來就是「五魁首」了。

各地的舉子每三年進京趕考趕考參加會試是全國高級知識分子最大的匯集，所以常要生些事，如「公車上書」。考中了就成為貢士。會試的第一名叫會元。貢士再參加殿士，由皇帝在殿廷上親自策問，以定甲第。一甲只有三名，賜進士及第，第一名叫狀元，第二名叫榜眼，第三名叫探花。我國歷史上的名人，象王維、柳公權、賀知章、張九齡、呂蒙正、張孝祥、陳亮、文天祥和楊慎，都是狀元。如過在鄉、會、殿三試中都得第一名，就叫連中三元，是科舉的最高榮耀了。二甲若干名，賜進士出身，第一名叫傳臚。三甲若干名，賜同進士出身。進士榜稱為甲榜，因為用黃紙書寫，所以又叫「黃榜」、「金榜」，中了進士，就叫「金榜題名」。

考中了進士就按規定授予一定的官職。狀元一般授予翰林院史館修撰，榜眼和探花授予翰林院編修，其他進士文章書法比較好的當翰林院庶吉士，學習當官。三年以後考試優良者，分別授予翰林院編修、檢討等職，未入選者或內用為六部主事、內閣中書，或外用為知縣。這些都是六、七品的小官。

如果留在翰林院，可以一級一級往上升，一直升到翰林院的「院長」－－正五品的學士。翰林也可能被選入內閣當大學士。明朝內閣共有四殿（中極、建極、文華、武英）和二閣（文淵、東閣）共六名大學士，其中領頭的稱為首輔，也就是宰相，象張居正就是最有名的內閣首輔。這是文官最高的榮譽了。

當然，真正的大學問家是不顯山露水的。他們寧可隱於山野而無爭於世，這大概是道家思想的影響。

（蒙人、方舟子，1996年9月）

B. 關於C++，Mud編程。謝謝各位了

1. 網路文庫（或豆丁網）中有一本書是《Mud游戲編程》，那個使用c++實現的，建議lz下載下來好好研讀。
2. Mud編程這方面我也不是很了解，不過我從事c++有好多年了，lz如有c++，linux 或 軟體設計的問題我可以鼎力幫助。

C. 端游，手游服務端常用的架構是什麼樣的

端游、手游服務端常用的架構是什麼樣的？
類型1：卡牌、跑酷等弱交互服務端卡牌跑酷類

因為交互弱，玩家和玩家之間不需要實時面對面PK，打一下對方的離線數據，計算下排行榜，買賣下道具即可，所以實現往往使用簡單的 HTTP伺服器：

登錄時可以使用非對稱加密（RSA, DH），伺服器根據客戶端uid，當前時間戳還有服務端私鑰，計算哈希得到的加密 key 並發送給客戶端。之後雙方都用 HTTP通信，並用那個key進行RC4加密。客戶端收到key和時間戳後保存在內存，用於之後通信，服務端不需要保存 key，因為每次都可以根據客戶端傳上來的 uid 和 時間戳 以及服務端自己的私鑰計算得到。用模仿 TLS的行為，來保證多次 HTTP請求間的客戶端身份，並通過時間戳保證同一人兩次登錄密鑰不同。

每局開始時，訪問一下，請求一下關卡數據，玩完了又提交一下，驗算一下是否合法，獲得什麼獎勵，資料庫用單台 MySQL或者 MongoDB即可，後端的 Redis做緩存（可選）。如果要實現通知，那麼讓客戶端定時15秒輪詢一下伺服器，如果有消息就取下來，如果沒消息可以逐步放長輪詢時間，比如30秒；如果有消息，就縮短輪詢時間到10秒，5秒，即便兩人聊天，延遲也能自適應。

此類伺服器用來實現一款三國類策略或者卡牌及酷跑的游戲已經綽綽有餘，這類游戲因為邏輯簡單，玩家之間交互不強，使用 HTTP來開發的話，開發速度快，調試只需要一個瀏覽器就可以把邏輯調試清楚了。

類型2：第一代游戲伺服器 1978

1978年，英國著名的財經學校University of Essex的學生 Roy Trubshaw編寫了世界上第一個MUD程序《MUD1》，在University of Essex於1980年接入 ARPANET之後加入了不少外部的玩家，甚至包括國外的玩家。《MUD1》程序的源代碼在 ARPANET共享之後出現了眾多的改編版本，至此MUD才在全世界廣泛流行起來。不斷完善的 MUD1的基礎上產生了開源的 MudOS（1991），成為眾多網游的鼻祖：

MUDOS採用 C語言開發，因為玩家和玩家之間有比較強的交互（聊天，交易，PK），MUDOS使用單線程無阻塞套接字來服務所有玩家，所有玩家的請求都發到同一個線程去處理，主線程每隔1秒鍾更新一次所有對象（網路收發，更新對象狀態機，處理超時，刷新地圖，刷新NPC）。

游戲世界採用房間的形式組織起來，每個房間有東南西北四個方向可以移動到下一個房間，由於歐美最早的網游都是地牢迷宮形式的，因此場景的基本單位被成為 「房間」。MUDOS使用一門稱為LPC的腳本語言來描述整個世界（包括房間拓撲，配置，NPC，以及各種劇情）。游戲裡面的高級玩家（巫師），可以不斷的通過修改腳本來為游戲添加房間以及增加劇情。早年 MUD1上線時只有17個房間，Roy Trubshaw畢業以後交給他的師弟 Richard Battle，在 Richard Battle手上，不斷的添加各種玩法到一百多個房間，終於讓 MUD發揚光大。

用戶使用 Telnet之類的客戶端用 Tcp協議連接到 MUDOS上，使用純文字進行游戲，每條指令用回車進行分割。比如 1995年國內第一款 MUD游戲《俠客行》，你敲入：」go east」，游戲就會提示你：「後花園 - 這里是歸雲庄的後花園，種滿了花草，幾個庄丁正在澆花。此地乃是含羞草生長之地。這里唯一的出口是 north。這里有：花待 阿牧（A mu），還有二位庄丁（Zhuang Ding）」，然後你繼續用文字操作，查看阿牧的信息：「look a mu」，系統提示：「花待 阿牧（A mu）他是陸乘風的弟子，受命在此看管含羞草。他看起來三十多歲，生得眉清目秀，端正大方，一表人才。他的武藝看上去【不是很高】，出手似乎【極輕】」。然後你可以選擇擊敗他獲得含羞草，但是你吃了含羞草卻又可能會中毒死亡。在早期網上資源貧乏的時候，這樣的游戲有很強的代入感。

用戶數據保存在文件中，每個用戶登錄時，從文本文件里把用戶的數據全部載入進來，操作全部在內存裡面進行，無需馬上刷回磁碟。用戶退出了，或者每隔5分鍾檢查到數據改動了，都會保存會磁碟。這樣的系統在當時每台伺服器承載個4000人同時游戲，不是特別大的問題。從1991年的 MUDOS發布後，全球各地都在為他改進，擴充，退出新版本，隨著 Windows圖形機能的增強。1997游戲《UO》在 MUDOS的基礎上為角色增加的x,y坐標，為每個房間增加了地圖，並且為每個角色增加了動畫，形成了第一代的圖形網路游戲。

因為游戲內容基本可以通過 LPC腳本進行定製，所以MUDOS也成為名副其實的第一款服務端引擎，引擎一次性開發出來，然後製作不同游戲內容。後續國內的《萬王之王》等游戲，很多都是跟《UO》一樣，直接在 MUDOS上進行二次開發，加入房間的地圖還有角色的坐標等要素，該架構一直為國內的第一代 MMORPG提供了穩固的支持，直到 2003年，還有游戲基於 MUDOS開發。雖然後面圖形化增加了很多東西，但是這些MMORPG後端的本質還是 MUDOS。隨著游戲內容的越來越復雜，架構變得越來越吃不消了，各種負載問題慢慢浮上水面，於是有了我們的第二代游戲伺服器。

類型3：第二代游戲伺服器 2003

2000年後，網游已經脫離最初的文字MUD，進入全面圖形化年代。最先承受不住的其實是很多小文件，用戶上下線，頻繁的讀取寫入用戶數據，導致負載越來越大。隨著在線人數的增加和游戲數據的增加，伺服器變得不抗重負。同時早期 EXT磁碟分區比較脆弱，稍微停電，容易發生大面積數據丟失。因此第一步就是拆分文件存儲到資料庫去。

此時游戲服務端已經脫離陳舊的 MUDOS體系，各個公司在參考 MUDOS結構的情況下，開始自己用 C在重新開發自己的游戲服務端。並且腳本也拋棄了 LPC，採用擴展性更好的 Python或者 Lua來代替。由於主邏輯使用單線程模型，隨著游戲內容的增加，傳統單伺服器的結構進一步成為瓶頸。於是有人開始拆分游戲世界，變為下面的模型：

游戲伺服器壓力拆分後得意緩解，但是兩台游戲伺服器同時訪問資料庫，大量重復訪問，大量數據交換，使得資料庫成為下一個瓶頸。於是形成了資料庫前端代理（DB Proxy），游戲伺服器不直接訪問資料庫而是訪問代理，再有代理訪問資料庫，同時提供內存級別的cache。早年 MySQL4之前沒有提供存儲過程，這個前端代理一般和 MySQL跑在同一台上，它轉化游戲伺服器發過來的高級數據操作指令，拆分成具體的資料庫操作，一定程度上代替了存儲過程：

但是這樣的結構並沒有持續太長時間，因為玩家切換場景經常要切換連接，中間的狀態容易錯亂。而且游戲伺服器多了以後，相互之間數據交互又會變得比較麻煩，於是人們拆分了網路功能，獨立出一個網關服務 Gate（有的地方叫 Session，有的地方叫 LinkSvr之類的，名字不同而已）：

把網路功能單獨提取出來，讓用戶統一去連接一個網關伺服器，再有網關伺服器轉發數據到後端游戲伺服器。而游戲伺服器之間數據交換也統一連接到網管進行交換。這樣類型的伺服器基本能穩定的為玩家提供游戲服務，一台網關服務1-2萬人，後面的游戲伺服器每台服務5k-1w，依游戲類型和復雜度不同而已，圖中隱藏了很多不重要的伺服器，如登錄和管理。這是目前應用最廣的一個模型，到今天任然很多新項目會才用這樣的結構來搭建。

人都是有慣性的，按照先前的經驗，似乎把 MUDOS拆分的越開性能越好。於是大家繼續想，網關可以拆分呀，基礎服務如聊天交易，可以拆分呀，還可以提供web介面，資料庫可以拆分呀，於是有了下面的模型：

這樣的模型好用么？確實有成功游戲使用類似這樣的架構，並且發揮了它的性能優勢，比如一些大型 MMORPG。但是有兩個挑戰：每增加一級伺服器，狀態機復雜度可能會翻倍，導致研發和找bug的成本上升；並且對開發組挑戰比較大，一旦項目時間吃緊，開發人員經驗不足，很容易弄掛。

比如我見過某上海一線游戲公司的一個 RPG上來就要上這樣的架構，我看了下他們團隊成員的經驗，問了下他們的上線日期，勸他們用前面稍微簡單一點的模型。人家自信得很，認為有成功項目是這么做的，他們也要這么做，自己很想實現一套。於是他們義無反顧的開始編碼，項目做了一年多，然後，就沒有然後了。

現今在游戲成功率不高的情況下，一開始上一套比較復雜的架構需要考慮投資回報率，比如你的游戲上線半年內 PCU會去到多少？如果一個 APRG游戲，每組伺服器5千人都到不了的話，那麼選擇一套更為貼近實際情況的結構更為經濟。即使後面你的項目真的超過5千人朝著1萬人目標奔的話，相信那個時候你的項目已經掙大錢了 ，你數著錢加著班去逐步迭代，一次次拆分它，相信心裡也是樂開花的。

上面這些類型基本都是從拆分 MUDOS開始，將 MUDOS中的各個部件從單機一步步拆成分布式。雖然今天任然很多新項目在用上面某一種類似的結構，或者自己又做了其他熱點模塊的拆分。因為他們本質上都是對 MUDOS的分解，故將他們歸納為第二代游戲伺服器。

類型4：第三代游戲伺服器

2007從魔獸世界開始無縫世界地圖已經深入人心，比較以往游戲玩家走個幾步還需要切換場景，每次切換就要等待 LOADING個幾十秒是一件十分破壞游戲體驗的事情。於是對於 2005年以後的大型 MMORPG來說，無縫地圖已成為一個標准配置。比較以往按照地圖來切割游戲而言，無縫世界並不存在一塊地圖上面的人有且只由一台伺服器處理了：

每台 Node伺服器用來管理一塊地圖區域，由 NodeMaster（NM）來為他們提供總體管理。更高層次的 World則提供大陸級別的管理服務。這里省略若干細節伺服器，比如傳統資料庫前端，登錄伺服器，日誌和監控等，統統用 ADMIN概括。在這樣的結構下，玩家從一塊區域走向另外一塊區域需要簡單處理一下：

玩家1完全由節點A控制，玩家3完全由節點B控制。而處在兩個節點邊緣的2號玩家，則同時由A和B提供服務。玩家2從A移動到B的過程中，會同時向A請求左邊的情況，並向B請求右邊的情況。但是此時玩家2還是屬於A管理。直到玩家2徹底離開AB邊界很遠，才徹底交由B管理。按照這樣的邏輯將世界地圖分割為一塊一塊的區域，交由不同的 Node去管理。

對於一個 Node所負責的區域，地理上沒必要連接在一起，比如大陸的四周邊緣部分和高山部分的區塊人比較少，可以統一交給一個Node去管理，而這些區塊在地理上並沒有聯系在一起的必要性。一個 Node到底管理哪些區塊，可以根據游戲實時運行的負載情況，定時維護的時候進行更改 NodeMaster 上面的配置。於是碰到第一個問題是很多 Node伺服器需要和玩家進行通信，需要問管理伺服器特定UID為多少的玩家到底在哪台 Gate上，以前按場景切割的伺服器這個問題不大，問了一次以後就可以緩存起來了，但是現在伺服器種類增加不少，玩家又會飄來飄去，按UID查找玩家比較麻煩；另外一方面 GATE需要動態根據坐標計算和哪些 Node通信，導致邏輯越來越厚，於是把：「用戶對象」從負責連接管理的 GATE中切割出來勢在必行於是有了下面的模型：

網關伺服器再次退回到精簡的網路轉發功能，而用戶邏輯則由按照 UID劃分的 OBJ伺服器來承擔，GATE是按照網路接入時的負載來分布，而 OBJ則是按照資源的編號（UID）來分布，這樣和一個用戶通信直接根據 UID計算出 OBJ伺服器編號發送數據即可。而新獨立出來的 OBJ則提供了更多高層次的服務：

對象移動：管理具體玩家在不同的 Node所管轄的區域之間的移動，並同需要的 Node進行溝通。

數據廣播：Node可以給每個用戶設置若干 TAG，然後通知 Object Master 按照TAG廣播。

對象消息：通用消息推送，給某個用戶發送數據，直接告訴 OBJ，不需要直接和 GATE打交道。

好友聊天：角色之間聊天直接走 OBJ/OBJ MASTER。整個伺服器主體分為三層以後，NODE專注場景，OBJ專注玩家對象，

GATE專注網路。這樣的模型在無縫場景伺服器中得到廣泛的應用。但是隨著時間的推移，負載問題也越來越明顯，做個活動，遠來不活躍的區域變得十分活躍，靠每周維護來調整還是比較笨重的，於是有了動態負載均衡。動態負載均衡有兩種方法，第一種是按照負載，由 Node Master 定時動態移動修改一下各個 Node的邊界，而不同的玩家對象按照先前的方法從一台 Node上遷移到另外一台 Node上：

圖11 動態負載均衡

Node Master定時查找地圖上的熱點區域，計算新的場景切割方式，然後告訴其他伺服器開始調整，具體處理方式還是和上面對象跨越邊界移動的方法一樣。但是上面這種方式實現相對復雜一些，於是人們設計出了更為簡單直接的一種新方法：

圖12 基於網格的動態負載均衡

於網格的動態負載均衡還是將地圖按照標准尺寸均勻切割成靜態的網格，每個格子由一個具體的Node負責，但是根據負載情況，能夠實時的遷移到其他 Node上。在遷移分為三個階段：准備，切換，完成。三個狀態由Node Master負責維護。准備階段新的 Node開始同步老 Node上面該網格的數據，完成後告訴NM；NM確認OK後同時通知新舊 Node完成切換。完成切換後，如果 Obj伺服器還在和老的 Node進行通信，老的 Node將會對它進行糾正，得到糾正的 OBJ將修正自己的狀態，和新的 Node進行通信。

很多無縫動態負載均衡的服務端宣稱自己支持無限的人數，但不意味著 MMORPG游戲的人數上限真的可以無限擴充，因為這樣的體系會受制於網路帶寬和客戶端性能。帶寬決定了同一個區域最大廣播上限，而客戶端性能決定了同一個屏幕到底可以繪制多少個角色。

從無縫地圖引入了分布式對象模型開始，已經完全脫離 MUDOS體系，成為一種新的服務端模型。又由於動態負載均衡的引入，讓無縫伺服器如虎添翼，容納著超過上一代游戲伺服器數倍的人數上限，並提供了更好的游戲體驗，我們稱其為第三代游戲服務端架構。網游以大型多人角色扮演為開端，RPG網游在相當長的時間里一度占據90%以上，使得基於 MMORPG的服務端架構得到了蓬勃的發展，然而隨著玩家對RPG的疲憊，各種非MMORPG游戲如雨後春筍般的出現在人們眼前，受到市場的歡迎。

類型5：戰網游戲伺服器

經典戰網服務端和 RPG游戲有兩個區別：RPG是分區分服的，北京區的用戶和廣州區的用戶老死不相往來。而戰網，雖然每局游戲一般都是 8人以內，但全國只有一套伺服器，所有的玩家都可以在一起游戲，而玩家和玩家之使用 P2P的方式連接在一起，組成一局游戲：

玩家通過 Match Making 伺服器使用：創建、加入、自動匹配、邀請 等方式組成一局游戲。伺服器會選擇一個人做 Host，其他人 P2P連接到做主的玩家上來。STUN是幫助玩家之間建立 P2P的牽引伺服器，而由於 P2P聯通情況大概只有 75%，實在聯不通的玩家會通過 Forward進行轉發。

大量的連接對戰，體育競技游戲採用類似的結構。P2P有網狀模型（所有玩家互相連接），和星狀模型（所有玩家連接一個主玩家）。復雜的游戲狀態在網狀模型下難以形成一致，因此星狀P2P模型經受住了歷史的考驗。除去游戲數據，支持語音的戰網系統也會將所有人的語音數據發送到做主的那個玩家機器上，通過混音去重再編碼的方式返回給所有用戶。

戰網類游戲，以競技、體育、動作等類型的游戲為主，較慢節奏的 RPG（包括ARPG）有本質上的區別，而激烈的游戲過程必然帶來到較 RPG復雜的多的同步策略，這樣的同步機制往往帶來的是很多游戲結果由客戶端直接計算得出，那在到處都是破解的今天，如何保證游戲結果的公正呢？

主要方法就是投票法，所有客戶端都會獨立計算，然後傳遞給伺服器。如果結果相同就更新記錄，如果結果不一致，會採取類似投票的方式確定最終結果。同時記錄本劇游戲的所有輸入，在可能的情況下，找另外閑散的游戲客戶端驗算整局游戲是否為該結果。並且記錄經常有作弊嫌疑的用戶，供運營人員封號時參考。

類型7：休閑游戲伺服器

休閑游戲同戰網伺服器類似，都是全區架構，不同的是有房間伺服器，還有具體的游戲伺服器，游戲主體不再以玩家 P2P進行，而是連接到專門的游戲伺服器處理：

和戰網一樣的全區架構，用戶數據不能象分區的 RPG那樣一次性load到內存，然後在內存裡面直接修改。全區架構下，為了應對一個用戶同時玩幾個游戲，用戶數據需要區分基本數據和不同的游戲數據，而游戲數據又需要區分積分數據、和文檔數據。勝平負之類的積分可以直接提交增量修改，而更為普遍的文檔類數據則需要提供讀寫令牌，寫令牌只有一塊，讀令牌有很多塊。同帳號同一個游戲同時在兩台電腦上玩時，最先開始的那個游戲獲得寫令牌，可以操作任意的用戶數據。而後開始的那個游戲除了可以提交勝平負積分的增量改變外，對用戶數據採用只讀的方式，保證游戲能運行下去，但是會提示用戶，游戲數據鎖定。

類型8：現代動作類網游

從早期的韓國動作游戲開始，傳統的戰網動作類游戲和 RPG游戲開始嘗試融合。單純的動作游戲玩家容易疲倦，留存也沒有 RPG那麼高；而單純 RPG戰斗卻又慢節奏的乏味，無法滿足很多玩家激烈對抗的期望，於是二者開始融合成為新一代的：動作 + 城鎮 模式。玩家在城鎮中聚集，然後以開副本的方式幾個人出去以動作游戲的玩法來完成各種 RPG任務。本質就是一套 RPG服務端+副本服務端。由於每次副本時人物可以控制在8人以內，因此可以獲得更為實時的游戲體驗，讓玩家玩的更加爽快。

說了那麼多的游戲伺服器類型，其實也差不多了，剩下的類型大家拼湊一下其實也就是這個樣子而已。

D. 游戲編程

學習游戲編程最好是有系統的學習方式，有老師帶領會高效得多。

當下互聯網行業發展迅速，與之相關的產業大多發展都很好，游戲設計的前景自然也是相當不錯的。一個游戲問世要經歷很多環節，劇本設計，原畫創作，場景建模，但核心部分還是編程語言開發。

主要學的內容如下：

1.游戲程序設計：C++程序設計入門；基本數據類型和輸入輸出；流程式控制制語句；數組、指針和引用、函數；程序結構和書寫規；范結構體和聯合體、類；繼承與多態；異常處理與程序調試。

2.演算法與數據結構：演算法分析；數據結構；基本演算法；STL的概念與使用；靜態庫與動態庫；XML庫的使用。

3.Win32程序設計：Windows程序入門；Windows消息；GDI繪圖游戲工具與MFC；網路編程基礎。

4.游戲數學和智能應用：游戲中的坐標系；矢量、矩陣；幾何碰撞；物理模擬；人工智慧與尋路演算法。

5.2D游戲技術與應用：2D游戲技術概論；游戲地圖系統；GUI系統；戰斗系統設計；任務系統；優秀的聲音引擎BASS；Cocos2D-X引擎；Box2D物理引擎。

互聯網行業目前還是最熱門的行業之一，學習IT技能之後足夠優秀是有機會進入騰訊、阿里、網易等互聯網大廠高薪就業的，發展前景非常好，普通人也可以學習。

想要系統學習，你可以考察對比一下開設有相關專業的熱門學校，好的學校擁有根據當下企業需求自主研發課程的能力，能夠在校期間取得大專或本科學歷，中博軟體學院、南京課工場、南京北大青鳥等開設相關專業的學校都是不錯的，建議實地考察對比一下。

祝你學有所成，望採納。

E. 關於MUD純文字游戲架設（回答得好加分100）

個人認為, 製作mud, 首先要玩過mud, 熟悉mud

mud架站比較容易, 你去 小熊泥苑, 上面有各種類型的單機

挑一個你熟悉類型的, 配個mudos 架設即可. 當然還存在mudos跟 代碼不匹配的問題

關鍵還是你想架設什麼類型的

F. mud源碼手機如何運行

首先選擇一種已有伺服器搭建好，用HTML5和APICloud（或者其他的可以打包H5app的框架）做客戶端，Websocket與伺服器通信，Sqlite3做資料庫。
1、用多個HTML頁面，這種方式會出現無法在多個頁面中通用WebSocket的問題。
2、用一個iframe改變src可以通在主頁面寫websocket，但是主頁面與子頁面部分js代碼會沖突。
每個頁面放到一個DIV中，然後用js控制DIV顯示與否。
屬性展示和功能按鍵布局主要用Table，這樣看起來整齊，那種類似控制台可以不斷滾動出一條條的內容的用div，設置成帶滾動條和自動定位到最新輸出信息。

G. 誰有 Mud 俠客行的源代碼

小熊泥苑