用戶5493735505294
第一，選擇什麼樣的架構。
不同的遊戲適用不同的架構。卡牌遊戲架構、MMO遊戲架構、MOBA遊戲架構、FPS遊戲架構
第二，選擇單線程還是多線程。
操作系統的同步與異步，進程與線程。
第三，如何在遊戲中使用腳本。
lua語言、lua與C、C++的交互
第四，如何處理網絡通訊。
消息隊列（zmq等）、epoll（libevent等）
兩種處理方式：
一種是跟遊戲服務器耦合帶一起，遊戲服務器既處理問落接入相關的邏輯，也處理遊戲邏輯。
一種是把網絡通信部分剝離住來，向遊戲服務器提供一種以消息為單位的、非阻塞的、有Qos能力的中間服務，遊戲服務器看不到網絡的細節。
第五，如何處理遊戲通信協議。
序列化（protobuf等，lua的pbc庫）包頭包體設計
第六，如何設計存儲結構。
sql（mysql）、nosql（redis）、文件服務器（hdfs，fastdfs等）
從遊戲來講，所有的在線遊戲通常使用數據庫來存儲用戶數據。通常MMO使用關係型數據庫來存儲數據，後面主要針對MMO進行存儲方式的討論。會有兩種方式：一種是把遊戲的每一個數據對象的屬性看成一個單獨字段，遵循RDBMS的要求來設計數據庫表和索引，儘量符合3NF。以MMO為例，有帳號表、角色基本信息表、物品表、裝備表等等，這是一種方式。
還有一種方式更具體，角色的列表類數據儘量採用blob來存儲而不是另一個表。原則是這些列表數據只被角色自身所擁有，就是這個玩家所擁有，其他玩家不會擁有個數據，它的生命週期跟玩家是一致的，不存在其他的交叉擁有情況，技能、物品、裝備、任務、好友等等都屬於這種情況。
優點是存儲表結構簡單，通常幾張表就可以玩一個遊戲，不超過10個。存取交互簡單，角色登錄或者推出時通常只需要存取一到二條記錄。同一個角色的數據易於保持一致，易於多版本數據共存。我們把這些數據存到數據庫的時候，會把編碼存到數據庫裡面。所以在數據庫裡面做完的數據可能會不一樣，不過不會影響，它會共存。
這種方式也會有缺點，數據維護工具、客服工具實現相對複雜，需要提供特殊的API來操作數據。如果手上工具是通用的，可能比以前要直白一點。某些類型的統計相對要麻煩一些，有些常用的數據，比如說角色的等級，在這方面可以用一些方式解決你的問題。
第七，如何設計網絡同步。
網絡同步面臨的主要問題：第一如何減少網絡波動對同步的影響；第二如何減少外掛對同步的破壞。
為了解決問題我們有一些基本方法：首先要探測玩家的網絡質量；第二在玩家機器與服務器之間進行時鐘同步；第三基於遊戲特點，設計合理的同步機制。
第八，如何定義性能基準。
可以通過經驗的方式，或者計算的方式來確確定理論上限。網絡IO，可以分析，取悅於由遊戲類型、遊戲設計所形成的業務模型，可估算。內存，相對來講更簡單，取決於用到的主要數據結構，相對來講更聚焦，更能估算出來支撐多少人。CPU計算能力，其實也不是計算，需要更多對CPU的支撐，簡單的方式，這個遊戲取決於遊戲類型導致的邏輯複雜性。推過這三點，可以有一個目標，大概需要多少人。
（細節：數據結構與算法，整體：整個遊戲的內存管理和網絡IO，吞吐量）
第九，如何在不同項目間進行代碼複用。
把共用的代碼收歸一個獨立的組織來開發和維護，形成公共組件
小迷弟糖豆
手遊頁遊和端遊的服務端本質上沒區別，區別的是遊戲類型。
類型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），成為眾多網遊的鼻祖： 類型3：第二代遊戲服務器 2003
2000年後，網遊已經脫離最初的文字MUD，進入全面圖形化年代。最先承受不住的其實是很多小文件，用戶上下線，頻繁的讀取寫入用戶數據，導致負載越來越大。隨著在線人數的增加和遊戲數據的增加，服務器變得不抗重負。同時早期 EXT磁盤分區比較脆弱，稍微停電，容易發生大面積數據丟失。因此第一步就是拆分文件存儲到數據庫去。
MUDOS採用 C語言開發，因為玩家和玩家之間有比較強的交互（聊天，交易，PK），MUDOS使用單線程無阻塞套接字來服此時遊戲服務端已經脫離陳舊的 MUDOS體系，各個公司在參考 MUDOS結構的情況下，開始自己用 C在重新開發自己的遊戲服務端。並且腳本也拋棄了 LPC，採用擴展性更好的 Python或者 Lua來代替。由於主邏輯使用單線程模型，隨著遊戲內容的增加，傳統單服務器的結構進一步成為瓶頸。
玥娛樂解說
一般在遊戲界面會有切換線路的地方，也可以組隊，點擊都有信息，右鍵單擊跟隨分線
小貓老師888
哈哈哈，端遊是使用鍵盤裡的字母來切換路線的
