亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: 網絡游戲中的連接服務器 [打印本頁]

作者: bobozhang 時間: 2009-09-09 09:55
標題: 網絡游戲中的連接服務器
最近在看一些網絡游戲的源代碼，看到他們都喜歡用一個專門的連接服務器來管理大量的連接，這個服務器把大量(一般都是10左右)客戶端的數據轉發(fā)到內部的其它服務器中去。這些實現有些是用windows的完成端口，有的用freebsd的kqueue，有的用linux的epoll。但我有個疑問，這臺服務就相當于一臺路由器，負責包的轉發(fā)，但它工作在4層以上，與真正的路由器轉發(fā)包的效率相差甚遠，這會造成延遲，再則，比如一個進程(單線程)用epoll監(jiān)管10000個連接，在最壞時可能這10000個連接都有數據可讀，那么串行讀取，那么最后一個連接的延遲豈不是更嚴重？因為程序要先read() 9999次之后才來read最后一個，然后轉發(fā)。

在這些實現中，我感覺windows的完成端口要比其它模型要好些

我在這個領域一點經驗都沒有，希望向大家學習學習

作者: flw 時間: 2009-09-09 10:00
你是不是沒理清楚頭緒啊，
我做過的網游的連接服務器只是負責初始連接，
一旦進入某個具體的地圖的時候，客戶端會和具體的地圖服務器建立連接，初始的那個連接就斷開了。

作者: bobozhang 時間: 2009-09-09 10:17

原帖由 flw 于 2009-9-9 10:00 發(fā)表
你是不是沒理清楚頭緒啊，
我做過的網游的連接服務器只是負責初始連接，
一旦進入某個具體的地圖的時候，客戶端會和具體的地圖服務器建立連接，初始的那個連接就斷開了。

哦，可能你那個實現不太一樣吧。

我看得這個代碼大概是這樣的哈，首先用戶連接登陸服務器獲取sessionid和 game gate的(ip:port)，然后客戶端去連接這個game gate，之后只要不退出游戲，不管怎么換地圖都不會斷開這個連接，game gate之后還有個地圖管理服務器，所有的地圖服務器都連接到這個地圖管理服務器，所有客戶端發(fā)來的跟地圖相關的包都會由game gate轉發(fā)給地圖管理服務器，然后地圖管理服務器根據角色所在的地圖再次轉發(fā)給對應的地圖服務器。

我感覺這樣大量的轉發(fā)會造成很多延遲阿，感覺你那個實現要好些。

ps:如果你愿意不怕泄密，是否可以向我們講解一下mmorpg業(yè)界通用的服務器端的架構阿，謝謝！

作者: flw 時間: 2009-09-09 10:44
你剛才闡述的這種架構沒法分布式啊。只能在同一個機房里搞，
那南北互通的問題就很難解決了哦。

我說的那種架構就稍微好一些，可以把用戶分配到合理的地圖服務器上去。
而且不限制地圖服務器的物理位置。

作者: xhl 時間: 2009-09-09 12:50

原帖由 bobozhang 于 2009-9-9 09:55 發(fā)表
最近在看一些網絡游戲的源代碼，看到他們都喜歡用一個專門的連接服務器來管理大量的連接，這個服務器把大量(一般都是10左右)客戶端的數據轉發(fā)到內部的其它服務器中去。這些實現有些是用windows的完成端口，有的 ...

我給你解釋一下把，一般如果是基于tcp應用的網絡游戲，這種連接服務器其實可以看作是客戶端代理，一個clientproxy可以代理n個client, 看性能而定。

一般這種clientproxy是多個，由網絡服務的中心服務來負責分配負載均衡。每個clientproxy跟內部地圖或者gameserver之間建立固有的連接。

對于內部服務來說，他們看到的只有clientproxy, clientproxy 有一個重要作用就是做數據包的安全check, 保證進入游戲服務群組內的消息，都是正確的。
clientproxy 還可以分擔把邏輯server的廣播壓力。

至于說時延問題，其實大部分mmorpg類型的游戲，對時間要求都不是很高，除非是fps 或者竟速或者強pk類型的，可能要特殊處理一下。也就是同時使用tcp and udp兩種協議。主要的時延產生在client - clientproxy之間，而不是內部server之間，（可以用網絡通信，也可以用進程通信，甚至可以單進程，多thread）。

[ 本帖最后由 xhl 于 2009-9-9 14:14 編輯 ]

作者: anders0913 時間: 2009-09-09 13:42
LZ看的源代碼是很早很早以前的那套傳奇的代碼吧~~

作者: benjiam 時間: 2009-09-09 13:50
... 老嗎？

我們現在也是這么做的？

客戶端直接和map 服務器連接？好爛的設計。同時登陸2個服務器，安全性，帳號余額都將成為問題。

這樣的服務器可以說叫gateway, 好處很多，安全穩(wěn)定。當然 gateway 本身的壓力會很大。

作者: bobozhang 時間: 2009-09-09 14:32
to anders0913: 不是傳奇那套代碼哈，那個代碼是dephi的，看不懂，至于c++那套，聽人說本身寫得比較爛，沒看過

to benjiam：壓力大是否可以增加gate的個數來解決？我主要關心延遲的問題哈，這樣設計的話真的會如 xhl 所言的那樣不會造成過多的延遲嗎？

作者: bobozhang 時間: 2009-09-09 14:34
to flw: 南北問題應該不算大問題哈，在雙線機房里面電信布置一個gate，網通布置一個gate

作者: 翠羽黃衫 時間: 2009-09-09 15:00
最近也要看網絡游戲服務器相關的東西，看點啥好呢？各位前輩給介紹介紹唄。。就是會涉及到的相關技術。。

作者: anders0913 時間: 2009-09-09 15:07

原帖由 bobozhang 于 2009-9-9 14:32 發(fā)表
to anders0913: 不是傳奇那套代碼哈，那個代碼是dephi的，看不懂，至于c++那套，聽人說本身寫得比較爛，沒看過

to benjiam：壓力大是否可以增加gate的個數來解決？我主要關心延遲的問題哈，這樣設計的話真的 ...

那兩套都看過~~

[ 本帖最后由 anders0913 于 2009-9-9 15:09 編輯 ]

作者: xhl 時間: 2009-09-09 15:08

原帖由 bobozhang 于 2009-9-9 14:32 發(fā)表
to anders0913: 不是傳奇那套代碼哈，那個代碼是dephi的，看不懂，至于c++那套，聽人說本身寫得比較爛，沒看過

to benjiam：壓力大是否可以增加gate的個數來解決？我主要關心延遲的問題哈，這樣設計的話真的 ...

延遲問題是個比較復雜的問題，要看你做什么類型的游戲，什么類型的應用。

竟速類型的游戲跟wow這種rpg類型的，處理方法完全不一樣。沒有通用的架夠，要具體問題具體分析。

產生延遲有很多原因，但最主要的影響就是外網帶寬，還有就是如果想高instant, 不能采用tcp stream service, 應該采用udp, 采用關鍵frame思路。

只有關鍵frame才retransmit, 還有就是主邏輯服務的運算能力。因為很多游戲邏輯部分，存在大量的計算量。按里說cpu應該比網絡快的多，但大量的

運算會改變這個事實。至于你擔心的那點延遲，其實根本就不是關鍵的地方。

作者: benjiam 時間: 2009-09-09 15:13
udp 是關鍵

tcp 因為在棧里面要重新排序這一些系列復雜的計算所以局域網網絡里面測試流暢得很出去就卡了。

我們現在有這個問題，當時有個人提出要udp 被技術leader 否決，現在就很卡。很麻煩。唉，一場政治謀殺

作者: bobozhang 時間: 2009-09-09 15:18

原帖由 xhl 于 2009-9-9 15:08 發(fā)表

延遲問題是個比較復雜的問題，要看你做什么類型的游戲，什么類型的應用。

竟速類型的游戲跟wow這種rpg類型的，處理方法完全不一樣。沒有通用的架夠，要具體問題具體分析。

產生延遲有很多原 ...

哦，看來你是從實際經驗中得出的結論，可信性比較高哈，謝謝！

[ 本帖最后由 bobozhang 于 2009-9-9 15:22 編輯 ]

作者: bobozhang 時間: 2009-09-09 15:19

原帖由 benjiam 于 2009-9-9 15:13 發(fā)表
udp 是關鍵

tcp 因為在棧里面要重新排序這一些系列復雜的計算所以局域網網絡里面測試流暢得很出去就卡了。

我們現在有這個問題，當時有個人提出要udp 被技術leader 否決，現在就很卡。很麻煩。 ...

現在的網絡游戲不都是用的tcp嗎，rpg類型的用tcp應該不會卡阿, 當然游戲里面要采用prediction

作者: gz80 時間: 2009-09-09 15:23
gateway壓力大可以寫個gateway name server，客戶端用短連接向gateway name server獲取gateway地址，name server以負載均衡為原則分配gateway IP。
當然搞這套東西還不如flw的初始連接，畢竟你gateway轉發(fā)是應用層的，延遲比較大。

作者: net_robber 時間: 2009-09-09 15:27
放一臺“gateway”處理每個用戶實際鏈接到哪臺服務器不是挺好的么？？

沒有人規(guī)定這個鏈接必須一致保持

作者: net_robber 時間: 2009-09-09 15:28
另外，既然要做分布式的處理，為什么不把帳號驗證之類的流程也分出來到一臺/組單獨的服務器上呢？？

作者: xhl 時間: 2009-09-09 15:41

原帖由 gz80 于 2009-9-9 15:23 發(fā)表
gateway壓力大可以寫個gateway name server，客戶端用短連接向gateway name server獲取gateway地址，name server以負載均衡為原則分配gateway IP。
當然搞這套東西還不如flw的初始連接，畢竟你gateway轉發(fā)是應 ...

這個說法應該結合游戲邏輯，多人網絡游戲網絡上壓力最大的地方是什么？廣播壓力。

假如我周圍有50個人，每個人的走動，都要instant 的同步給周圍可見的其他人。這個壓力就是 50 * 50的。

這個廣播壓力，如果用地圖server一個去做，那即使沒有你說的所謂應用層轉發(fā)的延遲，基本你的邏輯server也卡的要死了。

用gateway(我喜歡叫clientproxy)的好處是，如果我現在有5個clientproxy, 沒個上面有10個人，我邏輯server只發(fā)5條同樣的消息給每個clientproxy,

在由clientproxy分別自己每人負責的client廣播到，是這樣效率好，還是計較那點轉發(fā)延遲效率好呢？

作者: benjiam 時間: 2009-09-09 16:08

原帖由 xhl 于 2009-9-9 15:41 發(fā)表

這個說法應該結合游戲邏輯，多人網絡游戲網絡上壓力最大的地方是什么？廣播壓力。

假如我周圍有50個人，每個人的走動，都要instant 的同步給周圍可見的其他人。這個壓力就是 50 * 50的。

這個 ...

的確我開始也不明白。后來明白了這樣可以大量減少server 和 gateway 之間的數據

server 發(fā)少量數據由 gateway 轉發(fā)。 gateway 壓力大很正常

作者: mikespook 時間: 2009-09-09 16:15
gateway 壓力也不會大，gateway 除了效驗和轉發(fā)，不做任何其他的工作。
就現在的硬件，頂得住～～～

然后你AI有AI專用服務器、尋路有尋路專用的服務器、資源有資源專用的服務器、聊天有聊天專用的服務器……

作者: benjiam 時間: 2009-09-09 16:31

原帖由 mikespook 于 2009-9-9 16:15 發(fā)表
gateway 壓力也不會大，gateway 除了效驗和轉發(fā)，不做任何其他的工作。
就現在的硬件，頂得住～～～

然后你AI有AI專用服務器、尋路有尋路專用的服務器、資源有資源專用的服務器、聊天有聊天專用的服務器……

ai 尋路都是map 里面做的。分開提高的性能并不明顯

作者: bobozhang 時間: 2009-09-09 16:33
要校驗，那就得解密吧，封包的加密解密是不是應該也在這里做，io密集可能本身cpu利用率就不是很高，做點運算也不錯？

作者: xhl 時間: 2009-09-09 16:37

原帖由 benjiam 于 2009-9-9 16:31 發(fā)表

ai 尋路都是map 里面做的。分開提高的性能并不明顯

我的觀點是，盡量不要在server邊做尋路，而是做速度邊界檢查, ai也一樣。

server就類似是警察局，當有人來報案的時候，在去檢查分析是否正確，如果正確，接受數據，不正確，拒絕。

而不是自己去輪訓去做。把大部分ai 與尋路這種比較費cpu的東西，放到client分布去做，因為每個client都有一個cpu,

然后server只做檢查。

作者: xhl 時間: 2009-09-09 16:48

原帖由 bobozhang 于 2009-9-9 16:33 發(fā)表
要校驗，那就得解密吧，封包的加密解密是不是應該也在這里做，io密集可能本身cpu利用率就不是很高，做點運算也不錯？

我見過的網絡游戲加密算發(fā)都不復雜，因為性能的原因。

通常有兩種做法，

一種是邏輯無關的數據加密。但要求運算量要很小。
二是邏輯相關的。我比較喜歡用這種。就是每個消息根據消息內的數據與邏輯， s11n的過程做手腳。這樣基本跟正常的s11n的開銷是一樣的。而且一旦被識破， update 一個補丁，更新掉規(guī)則，舊可以了。游戲要經常更新的，就不停的更新規(guī)則就可以了。

一般可以在gateway處把協議換成明文。

但我通常是這樣設計，因為經過gateway 的數據，進來的跟出去的，大小跟流量是不一樣的，進來的包很小，出去的一般包很大。而且進來的包可能是不安全的，出去的包一般認為是絕對安全的。
所以我進來的包都會解包，然后判斷是否有效。出去的，基本只解包頭，身體部分，直接在數據層拷貝。減少一次uns11n and s11n的過程。

因為我才用第2種方式加密，所以基本是無開銷的加密，所以我不在gateway處換名文。減少gateway的壓力。

作者: bobozhang 時間: 2009-09-09 17:20
受教了，太感謝了！

還有點問題：你的意思是從客戶端來的包在gate處全包解密，而對于發(fā)往客戶端的包加密已經在各個內部server做了，gate只需要轉發(fā)給對應的客戶端就行了？

作者: A.com 時間: 2009-09-09 17:48

原帖由 xhl 于 2009-9-9 16:48 發(fā)表

我見過的網絡游戲加密算發(fā)都不復雜，因為性能的原因。

通常有兩種做法，

一種是邏輯無關的數據加密。但要求運算量要很小。
二是邏輯相關的。我比較喜歡用這種。就是每個消息根據消息內的數據 ...

這個辦法是業(yè)內普遍采用的,游戲的數據很少加密,一般只用邏輯關聯性進行合法性校驗

作者: abcbuzhiming 時間: 2009-09-09 23:46

原帖由 xhl 于 2009-9-9 16:37 發(fā)表

而不是自己去輪訓去做。把大部分ai 與尋路這種比較費cpu的東西，放到client分布去做，因為每個client都有一個cpu ...

給client做？你的意思是交給客戶端每個電腦嗎？這不是助長作弊和本地改內存嗎，現在網絡游戲的設計不是盡量不把任何關鍵數據放本地的嗎？你交給本地客戶端，那對server算法設計就要相當嚴謹才行，不然一不留神就飛天循地瞬移秒怪的就來了

作者: xhl 時間: 2009-09-10 00:56

原帖由 abcbuzhiming 于 2009-9-9 23:46 發(fā)表

給client做？你的意思是交給客戶端每個電腦嗎？這不是助長作弊和本地改內存嗎，現在網絡游戲的設計不是盡量不把任何關鍵數據放本地的嗎？你交給本地客戶端，那對server算法設計就要相當嚴謹才行，不然一不留 ...

先更正一下我的說法，應該算是server 與 client 結合來完成的。

游戲本來就是很復雜的東西。不謹慎怎么能行。呵呵。給你解釋一下你的疑問。

首先你要先弄清楚什么是數據，什么是行為。尋路跟ai都是行為，不是數據。也就是行為可以隨便發(fā)生，但是否記分，要看server的臉色

瞬移很好屏蔽掉的，就是根據速度時間還有方向做個簡單的計算。client上報的位置不在這個檢測條件下允許下的，可以采取拉回到上次位置。
也可采取拉回到server認為應該合理的位置。你說的情況頂多是自己騙自己。別人看到你的狀態(tài)跟自己的是不一樣的。因為server不會相信client.

簡單的ai也是同樣的道理。我舉個最常見的ai, 就是場景內小怪物的自動攻擊能力。這個一般分3步：

1。怪物的出現以及隨幾的走動
2。按一定范圍巡警
3。跟中player進行攻擊

步驟1是server來控制的
步驟2是client來控制， server做檢查
步驟3基本也是server來控制的。

[ 本帖最后由 xhl 于 2009-9-10 01:46 編輯 ]

作者: bobozhang 時間: 2009-09-10 11:06
網上這方面的資料太少了，聽大家講解感覺不錯啊

作者: anders0913 時間: 2009-09-10 14:01

原帖由 xhl 于 2009-9-10 00:56 發(fā)表

先更正一下我的說法，應該算是server 與 client 結合來完成的。

游戲本來就是很復雜的東西。不謹慎怎么能行。呵呵。給你解釋一下你的疑問。

首先你要先弄清楚什么是數據，什么是行為。尋路跟ai ...

1。怪物的出現以及隨幾的走動
2。按一定范圍巡警
3。跟中player進行攻擊

步驟1是server來控制的
步驟2是client來控制， server做檢查
步驟3基本也是server來控制的。

是不是這樣？
1.server刷出一個怪在摸個坐標點，并以一個點為圓心，隨即自由走動；
2.client端執(zhí)行警戒代碼，以當前怪所在點為圓心，警戒，凡是進入此區(qū)域的Object，都想server報告一下，server來檢測此object是同類NPC，還是玩家object；
3.server根據報告，做邏輯判斷，是否攻擊，向NPC怪發(fā)送命令，并檢測結果，在做處理發(fā)送命令。。。；

作者: mikespook 時間: 2009-09-10 15:41

原帖由 benjiam 于 2009-9-9 16:31 發(fā)表

ai 尋路都是map 里面做的。分開提高的性能并不明顯

map 里直接做了 ai 和尋路這個 MMORPG 的比較常用吧～～其他一些類型的游戲不適合放 map 的～～

另外，物理上可以在一起，邏輯上分開，有很多好處，不光是性能問題啊～～

作者: blazewater 時間: 2009-09-10 15:43
flw的贊同。

作者: xhl 時間: 2009-09-10 16:05

原帖由 mikespook 于 2009-9-10 15:41 發(fā)表

map 里直接做了 ai 和尋路這個 MMORPG 的比較常用吧～～其他一些類型的游戲不適合放 map 的～～

另外，物理上可以在一起，邏輯上分開，有很多好處，不光是性能問題啊～～

尋路肯定是在map里做。 ai就不一定了。

我喜歡用專門的ai服務器來做, 其實就類似管理一群機器人的服務。可以把怪物看作是真實的一個玩家在那里控制著。只不過這個真實的玩家是機器人。

一般大型游戲里的ai服務器會有很種，每一種因為壓力問題，也會有很多個實例。

其實一切設計根源于產品的需求， mmorpg 有很多種類型，如果是選線類型的，每線活躍用戶2k以下，最高同時在線500以內，其實服務設計很簡單，一個進程就可以了。

如果是類似wow那種的，一個區(qū)是一個大世界（不一定是無縫的），整個區(qū)的活躍用戶10多萬人，最高同時在線2-5w, 這個規(guī)模的服務，設計就復雜多了。

[ 本帖最后由 xhl 于 2009-9-10 16:13 編輯 ]

作者: h0tr0ck 時間: 2009-09-11 00:07
有的AI是作為單獨的服務器為其他的邏輯服務器提供服務，它們之間消耗的網絡帶寬比較大，這樣也可以緩解一部分邏輯服務器的壓力。
我覺得網關服務器的壓力和連接數有關，可以根據具體的問題進行設計比較好一點。

作者: bobozhang 時間: 2009-09-11 09:33
ai和其它的邏輯處理都應該獨立出來吧

在網上和我看的這2份游戲源代碼來看都采用的是下面這個結構

地圖管理服務器
      /       \
   /          \
   /             \
地圖服務器1    地圖服務器2    ......地圖服務器n

在網上聽一個業(yè)內人士說，說這種結構有些地圖服務器壓力很大，現在他們不采用這種結構了，但他也不肯說到底怎么搞的，有知道內情的嗎，透露透露賽，讓我們這些門外漢也學習學習啊

作者: lethwei 時間: 2009-09-11 12:45
mark, 學到了很多東西

作者: 青蛙溪水 時間: 2009-09-16 12:19
向大家學習學習

作者: shenbo7 時間: 2009-09-17 09:19
EVE游戲，好像可以根據地圖服務器的壓力，手動調整地圖服務器；

最大，一張地圖，一個服務器；

作者: shenbo7 時間: 2009-09-17 09:21
補充說明下：

EVE游戲里，地圖都不是很大的，而且，游戲有點特殊；

作者: huyongzs 時間: 2009-09-17 11:38
好帖.

作者: zhhxidian2005 時間: 2009-09-17 14:35
標題: 回復 #41 huyongzs 的帖子
游戲的延遲包含兩部分，一個是網絡延遲，一個是程序延遲。game gate和地圖管理服務器的設計都要合理，否則會造成較大的延遲，同時也可能會成為真?zhèn)€架構的瓶頸。

作者: mandagod 時間: 2009-09-17 18:08
標題: 回復 #1 bobozhang 的帖子
串行讀��？應該是多線程讀取吧，多線程操作一些隊列吧。猜的。

作者: 微風輕哨 時間: 2009-09-19 23:48
頂起，學到了很多知識。

作者: GodPig 時間: 2009-09-20 22:56
關注一下～～～

作者: saiyy 時間: 2009-09-21 00:57
標題: 回復 #25 xhl 的帖子

原帖由 xhl 于 2009-9-9 16:48 發(fā)表

我見過的網絡游戲加密算發(fā)都不復雜，因為性能的原因。

通常有兩種做法，

一種是邏輯無關的數據加密。但要求運算量要很小。
二是邏輯相關的。我比較喜歡用這種。就是每個消息根據消息內的數據 ...

第二種方式加密中，s11n是不是一個缺陷？既然有可能被識破，就有可能再次很快被識破，update 一個補丁更新掉規(guī)則似乎治標不治本，那有沒有更合適的方式？或許這是游戲發(fā)展中的一個質變點？！

作者: anthony1983 時間: 2009-09-21 15:09
沒接觸過游戲開發(fā)的人過來受教了~

作者: xhl 時間: 2009-09-21 15:12

原帖由 saiyy 于 2009-9-21 00:57 發(fā)表

第二種方式加密中，s11n是不是一個缺陷？既然有可能被識破，就有可能再次很快被識破，update 一個補丁更新掉規(guī)則似乎治標不治本，那有沒有更合適的方式？或許這是游戲發(fā)展中的一個質變點？！

第一種方法也很容易被別人識破，因為你的client發(fā)給人家了。協議的一端在別人手上。而且如果真的有利可圖，就會有人去做這些事情。

但要清楚至少在現在設計的優(yōu)秀網絡游戲模型中，保護協議是為了服務不被攻擊, 或者是避免私服滿天，并不是防止外掛。

外掛是靠服務端的各種邏輯判斷來保護的。即使協議公開，別人做出來拖機外掛，但server控制邏輯比較嚴格的話，基本也站不到什么便宜。

我舉個算是比較下流的手段來防止拖機外掛或者按鍵精靈的方法：

一般策劃會根據游戲玩法，設計出一套以外系統。就是或者讓用戶做個小游戲，或者是詢問一個問題，或者是判斷一張圖片。

玩家做對了，就有寶箱可以開。沒做對或者沒做，基本無法進行下去。服務會拒絕一切請求。

這個有的是定時出現，有的是服務根據邏輯覺得這個client行為怪異，就出這個來判斷client邊是否有人在控制。

一般client沒人控制的話，靠外掛很難過這關，因為這個以外是隨幾的，而且會經常變化。

作者: benjiam 時間: 2009-09-21 20:13

原帖由 xhl 于 2009-9-21 15:12 發(fā)表

第一種方法也很容易被別人識破，因為你的client發(fā)給人家了。協議的一端在別人手上。而且如果真的有利可圖，就會有人去做這些事情。

但要清楚至少在現在設計的優(yōu)秀網絡游戲模型中，保護協議是為了 ...

理論上很難的，問題是開發(fā)這套外掛有多少利潤。

遙想當年mud 只要機器人做的好，一切都是自動的。

client 和 server 也就是個協議交互，只要處理的好 server 根本沒機會識別出來。

問題是做外掛的做這么智能的一個外掛，又要非常熟悉協議，它能獲利多少？

作者: sinlee 時間: 2009-09-21 22:16
問下,如果WEB游戲的話結構是啥樣的?

作者: xhl 時間: 2009-09-21 23:11

原帖由 sinlee 于 2009-9-21 22:16 發(fā)表
問下,如果WEB游戲的話結構是啥樣的?

web游戲主要分網頁的和flash的。

網頁模式的多半跟熱血三國類似。都是策略的。服務邊基本是在webserver上寫邏輯就可以了。client邊一般圖形是用js做的。

flash的目前可以做類似rpg的類型的游戲，但多半是選擇及時性比較低的玩法，例如回合制的戰(zhàn)斗等。 client邊一般是用flex + as .

服務邊可以用 java, c#, php 或者c/c++都可以。服務的設計相對簡單很多。因為flash是非硬件渲染，性能不行。

作者: bobozhang 時間: 2009-09-22 10:54
像天下貳那種無縫大地圖，服務器端的框架更難設計吧，聽說他們用的bigworld引擎

看云風的博客，他們好像自己也在開發(fā)那樣的引擎

作者: zsniper 時間: 2009-09-22 11:43
web游戲相對比較簡單，使用了大量的web2.0的特點。

更多的是 web(前臺邏輯)+后臺的app(可選)+memcache+db這種架構。

不過游戲架構相對于社區(qū)平臺或者IM來說，就是一個小型應用。

歡迎光臨 Chinaunix (http://72891.cn/)