如何架構韓國游戲

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

端游、手游服務端常用的架構是什麼樣的？
類型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人以內，因此可以獲得更為實時的游戲體驗，讓玩家玩的更加爽快。

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

B. 怎麼玩韓國游戲

~http://server.cemsg.com/ 登陸這個網站,輸入你所知道的韓國那邊的官方網站網址,點回車,之後你可能會看到一些廣告,不要管那些,過一段時間你就可以進入網站了,在網站里下載到客戶端,和申請帳號,玩游戲的時候我想你可能要找到代理伺服器的IP地址和端,具體你可以在這里看到教程,因為我也沒試過玩外國的網路游戲~不敢亂說http://www.proxycn.com/html_proxy/viewthread-23.html

C. 我想玩韓國的游戲,我有了代理IP就是伺服器,我要怎樣設置啊.

有的，可以到hsot5156官網去看，到貨速度快，售後服務好，技術支持給力，挺不錯的。

D. 我想問一下，代理一款韓國游戲需要多少錢，需要那些硬體條件……

代理游戲前期投入最少要500W左右（僅限小游戲，大型的知名的都要幾千萬）。包括架設伺服器，代理費用，日常開銷，宣傳。後期還要追加。做游戲最重要的就是要有錢。

E. 如何才能玩韓國appstore里的游戲

把Apple ID國家切換成韓國就可以了

F. 策劃入門4:如何建立起你的游戲框架

（四）：為你的游戲建立起一個完整的主框架
在第二部分如何寫一個項目建議書中，我們提到了游戲主框架由哪些部分構成。作為一個游戲的設計者，你必須要時刻保持清醒的頭腦，知道游戲到底應該是什麼樣子的。如果連設計人員都搞不清游戲的模樣，那其他的程序、美術就更沒辦法開發了。為了保持清晰的思路，就要先給自己搭一個框架，讓自己在大量繁雜的工作中不至於迷失了方向。那麼從什麼角度入手來建立這個框架呢？
對於剛入門的策劃來講，通過任務體系下手是最直接的也是最有效的。任何游戲尤其是RPG類游戲都有一個故事背景和主要線索，通過這些東西就可以很巧妙的設計出遊戲的主要流程。首先要把主任務也就是主線索明確，這一點非常重要。很多游戲就是因為任務太散，進而沖淡了主題。整個游戲的跌宕起伏和曲折離奇都是通過劇情來推動的，如果在一開始不能把任務明確出來，在加入了分支劇情後各種因素集中在一起思路很容易就亂了。所以在設計的開頭就把整個任務的框架搭建起來對思路的整理很有好處。
任務體系和故事是緊密結合在一起的。如何把故事改編成符合游戲設計思路的腳本是游戲劇本編寫人員的工作。總體的任務框架是RPG類游戲的核心，其他的體系都可以依附在任務框架上。任務就好象寫記敘文，不外乎人物、地點、事件等等諸要素組成。而人物就涉及到生命、體力、魔法、攻擊力等屬性，各種類型游戲根據不同需要而設計；地點就是地圖體系，整個游戲的大地圖系統和進入到某個城鎮的場景設計都可以歸入這個部分；事件分為很多類，包括對話、戰斗、特殊事件發生、物品交換等。在這些諸多因素都已經在你的腦海中成型後，你大體上就把握住了游戲輪廓，一些相關的體系就隨之建立起來了。
前面所提到過很多系統，從任務系統入手只是一個方面。由於游戲類型的眾多，也很難統計出一種能夠適用於全部類型的設計模式。對於即時戰略類和策略類的游戲，更注重於游戲方法本身，那麼這時的切入點就偏重於玩法設計。戰斗系統和升級體系的建立就成為游戲主框架的核心，這時的任務就好象成了一個附屬品，但並不是說任務就不重要了，巧妙的數值變化是需要一個個的精心設計的任務來體現出來的。但是總體的游戲規則設計是這些類型游戲的核心，如果一開始沒有經過反復的演算把各種游戲數據變化進行平衡，最終的產品肯定是不堪一擊的。
一些其他類型的游戲，比如格鬥類、養成類、運動類等因為創意的玩點不同，所以設計的切入點也各不相同。在這里就不一一描述，本人也能力有限，有哪位高手對這些類型的游戲有研究的不妨一起探討。
在選擇好了切入點，接下來就是在核心設計的基礎上逐漸展開完善，並最終形成游戲的骨幹。其實游戲設計的每個模塊都是相互滲透的，並沒有絕對的主次之分，上面所說的其實只是尋找一個切入點以便能夠快速找到感覺並深入進去。各個模塊之間的關系大致如下：
上面的一個圖是描述各個模塊之間的關系圖。生存體系和地圖系統是整個游戲的基礎：生存體系中包括所有可能出現的角色屬性，可能會在設計過程中不斷添加新屬性。地圖系統是游戲中涉及到的全部位置和地點，是設計中最為頭痛的一個部分。這兩個系統構成了游戲的基礎，幾乎所有的游戲都有這兩個模塊。
升級系統的所有數據都要來源於生存體系中的人物屬性，如何設計升級演算法讓游戲更好玩，更耐玩是升級系統設計的關鍵。掌握好整個體系的平衡性，尤其在多人游戲時更為重要。升級體系的重要性也體現在游戲時間的控制上，既要讓玩家感受到升級後的變化，又要合理控制升級的速度，難度是相當大的。大量的時間被用在反復的演算上，這時先用程序設計個小模型是個比較好的辦法。
NPC設計和AI設計是一個整體，在這里把兩者分開來是有目的的。NPC的作用有很多，有時是放道具的箱子，有時是完成任務的觸發器，有時是你的敵人，有時是你的朋友。NPC設計和地圖位置也有關系，每個NPC都有一定的活動范圍，應根據劇情需要指定活動地點。AI是指游戲中的人工智慧設計，和NPC的設計結合很緊密。由於該系統往往由程序和策劃協調著設計，所以把這個部分單拉出來形成一個單獨模塊。一般的AI設計包括尋路演算法、戰斗方式選擇以及對話應答等，由於該部分極為復雜這里就不再詳細描述。

G. 如何實現游戲架構設計

既然架構設計有很多優點，如何做架構設計？游戲架構設計的產生不是異想天開，沒有固定的模式，每個項目產品不同，它的架構設計也是不同的，架構是根據需求設計的，在需求明確的情況下，開始架構設計，在這里要注意，不能為了架構而做架構設計。比如有的開發者開發一款24點小游戲，UI只有兩個，它還在做UI的架構設計，類似這種就不需要考慮架構設計了，注意力在演算法的實現以及優化上。在這里介紹的架構設計主要是針對一些比較大的項目，比如比較流行的大數據架構還有網路游戲的客戶端和伺服器架構等等。做架構之前首先要把產品的主要功能文檔設計好，架構是根據產品的需求做架構設計的，在這里給讀者介紹幾種常用的架構設計，以游戲為例，在游戲開發中，UI是一個體量比較大的系統，UI的主要功能是承載數據顯示，以及它自身的創建、顯示、隱藏、銷毀等功能。在這里不涉及到文檔需求，只是給讀者舉個例子。實現這些功能：一種方式是使用硬編碼，另一種是採用架構等等方式，顯然硬編碼並不適合產品開發，那隻能採用第二種架構設計，通過它的簡單功能介紹，它非常適合MVC設計模式，Model表示數據的更新，View表示的是界面顯示，Controller表示的是控制界面的顯示以及數據更新。最初MVC主要應用領域是在Web開發中，逐步被游戲開發採用，

H. 大型戰略類游戲如何架構

首先，你要架構這個游戲的世界觀，然後才是其他的東西吧。建議你去偷星貓下載幾款戰略游戲觀察一下別人的游戲是怎麼做的，戰爭藝術3、海島奇兵、部落沖突這幾款你可以看著學習一下。

I. DNF策劃表示限於韓服架構國服無權更改游戲內容，如何評價

DNF在近期體驗服更新有很多內容，玩家討論最多的除了增幅活動之外就要屬超界深淵掉落了，在這次更新中超界裝備加入到星空裂縫之中，也就是說玩家不再是通過刷旋渦的方式來畢業超界裝備，簡單的刷裂縫也可以畢業，不過這一次新增超界的掉落卻引發了不少玩家的爭議。

對於新增超界裝備深淵的掉落，在韓服那邊的深淵確實不能掉，但是在日服那邊早在很早之前就加入了超界裝備，所以這次深淵加入超界武無疑是照搬了日服，但是不管怎麼說深淵加入了超界裝備對於玩家來說也是比較好的，對於小號而言旋渦深淵兩頭刷，加快了超界裝備的畢業，只是對於通過超級加倍旋渦升級了超界的玩家會有點不爽而已，大家認為呢？

註：以上內容純屬小賢游戲醬的個人見解，觀點與平台無關！文章原創，圖片來源網路，如有侵權請聯系作者刪除。未經允許，禁止轉載！喜歡的玩家可以點贊關注，每天都有新的游戲資訊和技巧

J. 韓國為什麼網路游戲做的那麼成功

世界網游的聖地：韓國游戲產業探秘

http://www.fubusi.com 2006-4-11 10:14:00 tom游戲
當新興的游戲產業已然超過傳統的娛樂產業、在寬頻時代的舞台上翩翩起舞時，世界的聚光燈不得不集中到一個國家身上——韓國，因為「從來都沒有在一個領域韓國的一舉一動如此受世人矚目過，除了游戲。」危機的打擊、國家的扶持和寬頻的普及最後都促成了韓國網游產業的繁榮，而當全民沉浸在這場狂歡中時，網游也悄然超越了韓國任何一個產業而躍居第一。

街頭籃球

●產業發展規模和市場現狀

在世界網遊玩家心中，韓國可謂是不爭的「麥加之地」。韓國國內的游戲製作及經營企業已達到1500多家、網吧等游戲場所46900個、8個包括韓國政府部門下屬的韓國尖端游戲產業協會KESA、韓國游戲支援中心KGPC在內的游戲協會、在288家有IT相關學位的大學中由政府指定贊助的10家游戲大學及研究院、6家包括On Game Net、GameTV在內的有線電視和衛星廣播專業游戲頻道等組成的龐大的游戲產業群體。

以下數據同樣為韓國網路游戲業近年來驚人的發展速度提供了佐證：韓國整個網游市場規模從1997年之前只有100~200億韓元發展到2004年突破40，000億韓元。

韓國網路游戲公司2004年的銷售額達到了6.4億美元，是2001年2.33億美元的三倍。

韓國網路游戲玩家在所有游戲玩家中所佔的比例從2001年的23%上升到2003年的59%；玩游戲成了網民僅次於查資料之外的第二大上網目的。韓國遍布於全國各地的寬頻網路和網吧，以每年40%~50%的速度迅速增長。韓國網遊玩家每月平均費用達25美元，居最常見的網路收費內容之榜首。

韓國網游有鮮明的產業特徵。一是政府支持，這是其最大的特徵，可以說這樣的支持在世界各國都是極為罕見的。二是，本土化，韓國人遵循身土不二的原則，其本土游戲在國內占據了絕對的主導地位。網路化，空前發達的網路環境為游戲產業的運營提供了保駕護航的作用。系統化，游戲真正成了一項系統化發展的產業，並且與相關事業密不可分。

一方面，韓國是全球最大的單一游戲市場，在短短數年間網游已成為韓國國內老少咸宜的全民狂歡活動；另一方面，韓國通過網游的大量出口成為了繼北美、日本、歐洲之後的電子娛樂第四勢力。網游不僅為它帶來了可觀的經濟收益，也引起了全球媒體的極大關注和好奇。那麼，造成韓國網游如此繁榮的原因究竟何在呢？

●天時、地利、人和譜寫的奇跡

天時 實行政府主導的外向型經濟戰略起飛於上世紀60年代，之後的30多年一直保持了9%以上的高增長率。1996年韓國因加入經濟合作與發展組織而跨入發達國家門檻。然而1997年底爆發的金融危機使韓國的經濟倒退了5年。國內經濟的大蕭條對韓國上下造成了嚴重的沖擊，但出乎意料的是，幸運的韓國人憑借一招妙棋將危機變成了契機，成功打造了舉世矚目的網游產業。政府 金融風暴的打擊使韓國政府認識到僅靠汽車製造這樣的重型工業來支撐全國經濟的做法是片面的，其直接後果是經濟發展的單一化和脆弱的特徵，只有多元化的產業特徵才真正符合韓國的國情。

為了擺脫困境、尋求長遠的振興之路，韓國政府把採取推動高科技產業發展的措施提到了議事日程上來，並選擇寬頻互聯網作為一個明確的發展方向。2002年韓國所有地區開通了由高速光纜構築的主幹網，整個國家的互聯網信息傳輸速度比1998年提高100倍。目前韓國有超過60%的網民在使用ADSL、CABLE MODEM和專線等先進方式上網，這意味著韓國已成為世界領先的寬頻互聯網市場之一。

在推廣中，韓國人受到美國的《魔獸爭霸》游戲在韓國熱賣的啟示，開始把發展網路游戲產業奉為韓國國策，並制定了一系列的相關政策和優惠措施，鼓勵國內企業發展以寬頻、游戲為代表的信息產業。結果正如《新聞周刊》所言：「過去5年來投入數十億美元在地下和海底鋪設光纜，光纜所帶來的是比資料庫還要龐大的債務。但是游戲給網上經濟重新帶來了驅動力，成為『消費引擎』，而韓國則是『啟動器』。」

此外韓國政府在加大網路基礎建設的同時，還為游戲產業直接給予投資，比如韓國最早的幾部網游，其實用的都是韓國政府買來的引擎做出來的，所以，他們看起來都很像。韓國政府從歐洲買來游戲引擎，無償的提供給游戲公司，這無疑是快速構建網游產業基礎的捷徑之一。