分享: 陈杰谈网游服务器的后端技术
benegg
http://docs.google.com/Present?docid=dds5zgx6_429v8d9crgc
另一个人总结了一些有用的东西:
1. 将独立的模块封装成单独的进程。
2. 进程间通讯(IPC)使用TCP，为什么使用TCP而不是其他更高效的本地IPC方式？一方面因为大部分项目都有现成稳定的TCP模块，另
外一方面更容易将一台服务器拆分到多个服务器，程序完全不用修改。
http://timyang.net/architecture/game-backend/
强烈推荐想要开发网游的朋友都好好看这两篇文章!
------
转自: http://www.benegg.com/?p=23
Kouga
Kouga
benegg
On Apr 23, 11:07 am, Kouga <ncwh...@gmail.com> wrote:
> 另外一個就是，將尋路算法分佈到用戶端，讓客戶幫忙計算。
>
> 2009/4/23 Kouga <ncwh...@gmail.com>
Kouga
还有就是，计算任务肯定不是让客户计算自己的数值，多半情况是交叉演算。这样就算想作弊，也得至少将整个GRID破坏10%以上才可能修改到一个节点的数据……
这种方法几乎不会被使用, 因为客户端是不可靠的, 很容易作弊.
--
签名是什么东西？？
Allen Jiang
qiaojie
只能支持单台寻路服务器，没什么伸缩性，用什么多进程共享内存方式，这个跟多线程没任何本质差别，还需要用调度程序来同步共享内存的访问，好愚昧啊。
其实在他的方案基础上稍做修改就能支持分布式的寻路系统了，我不知道是他故意不拿出来误导听众，还是脑子进水了才设计出一个这么傻的方案。
ShiningRay
ShiningRay
--
[]\ [] ShiningRay
[]\\[]
[] \[] http://shiningray.cn
sunway
> > 转自:http://www.benegg.com/?p=23- 隐藏被引用文字 -
>
> - 显示引用的文字 -
jacky zhao
qiaojie
Kouga
这组PPT讲述的就是一个系统设计的演变过程，主要讲述的思路的演进，如果非要硬搬过来用的——呃，这种“使用”方式合法性先不说，创造性就真的可以说是一点都没有，结果与楼主共享的意图直接大相径庭了。
我们欢迎提出更好的方案，哪怕只是设想而已，对这种动辄冷嘲热讽的态度不敢苟同，也请各位发言前三思。
--
签名是什么东西？？
Allen Jiang
qiaojie
你只不过没理解这个设计的坏处，等你哪天理解了，一样会对它不屑一顾。
wing
不过大家都是程序员，都包容理解一些，比如我觉得自己就是个sb，所以别人要说我非常sb时候，就没那么生气，不回应直接忽略过去，大家继续讨论这个服务器设计的如何，我很感兴趣，但是对寻路这些东西不太懂，更兴趣的是整个架构可以借鉴的部分。
qiaojie能不能具体说说这个方案可以优化或者你设为设计不良的部分，很有兴趣听听。
2009/4/23 Allen Jiang <jianggui...@gmail.com>:
--
wing
wing9...@gmail.com
Hope is a good thing, maybe the best of things.
ShiningRay
--
[]\ [] ShiningRay
[]\\[]
[] \[] http://shiningray.cn
wing
我不玩游戏，所以对寻路不懂，不敢多说，但是这个多进程共享内存，调度进程的设计，确实没看懂，不知道是不是因为游戏业务的需要？
能不能多解释一下，确实不太理解这种设计的好处。
2009/4/23 ShiningRay <shiningra...@gmail.com>:
qiaojie
Kouga
--
签名是什么东西？？
qiaojie
lijie
没必要纠结于别人怎么说，习惯不一样，关键是有没有料。个人觉得qiaojie指出了最大的问题，我看到这个地方也有这个疑问。
Kouga
--
签名是什么东西？？
Kouga
- 调度进程会周期性的控制寻路进程向共享Cache中更新数据。
--
签名是什么东西？？
peterfl
On Apr 23, 1:33 pm, ShiningRay <shiningray.nirv...@gmail.com> wrote:
> 他这招叫"嘲讽"，使围观群众有N%几率强制回帖
>
> 2009/4/23 wing <wing922w...@gmail.com>
>
>
>
>
>
>
>
> > 确实如此，程序员很多都有这个毛病，我也经常这么乱说话，得罪很多人，我觉得这就是糟糕的"UI"，也许本来你的建议非常有建设性，但是因为你说的太直接，对方-产生了反感，再好的建议也很难被顺利接受了。
>
> > 不过大家都是程序员，都包容理解一些，比如我觉得自己就是个sb，所以别人要说我非常sb时候，就没那么生气，不回应直接忽略过去，大家继续讨论这个服务器设计-的如何，我很感兴趣，但是对寻路这些东西不太懂，更兴趣的是整个架构可以借鉴的部分。
>
> > qiaojie能不能具体说说这个方案可以优化或者你设为设计不良的部分，很有兴趣听听。
>
> > 2009/4/23 Allen Jiang <jiangguilong2...@gmail.com>:
> > > 不瞒你说，凡是地球人都会朝这方向理解，可能这是你平时的说话习惯，言者无心，听着有意，但这种说话方式实在"设计"的不好。
>
> > > ----- Original Message -----
> > > From: qiaojie
> > > To: dev4s...@googlegroups.com
> > > Sent: Thursday, April 23, 2009 1:02 PM
> > > Subject: Re: 分享: 陈杰谈网游服务器的后端技术
> > > 好吧，其实我只是想说这个设计不好，对事不对人。
> > > 你一定要往人上面理解，那可以自动忽略我说的话。
>
> > > 2009/4/23 jacky zhao <jackyz.z...@gmail.com>
>
> > >> 巨傻啊、好愚昧啊、脑子进水了啊。
>
> > >> 讨论问题，最好不要带这种 "人身攻击" 型的话。
>
> > >> 2009/4/23 qiaojie <qiao...@gmail.com>
>
> > >>> 这个寻路系统的设计方案真是巨傻啊
> > >>> 只能支持单台寻路服务器，没什么伸缩性，用什么多进程共享内存方式，这个跟多线程没任何本质差别，还需要用调度程序来同步共享内存的访问，好愚昧啊。
> > >>> 其实在他的方案基础上稍做修改就能支持分布式的寻路系统了，我不知道是他故意不拿出来误导听众，还是脑子进水了才设计出一个这么傻的方案。
>
> > >>> 2009/4/23 benegg <ide...@163.com>
>
> > >>>> 西山居的陈杰的幻灯片, 讲了网游服务端寻路, 当然也包括网游服务器的架构. 有不少有用的概念.
>
> > >>>>http://docs.google.com/Present?docid=dds5zgx6_429v8d9crgc
>
> > >>>> 另一个人总结了一些有用的东西:
>
> > >>>> 1. 将独立的模块封装成单独的进程。
> > >>>> 2. 进程间通讯(IPC)使用TCP，为什么使用TCP而不是其他更高效的本地IPC方式？一方面因为大部分项目都有现成稳定的TCP模块，另
> > >>>> 外一方面更容易将一台服务器拆分到多个服务器，程序完全不用修改。
>
> > >>>>http://timyang.net/architecture/game-backend/
>
> > >>>> 强烈推荐想要开发网游的朋友都好好看这两篇文章!
> > >>>> ------
> > >>>> 转自:http://www.benegg.com/?p=23
>
> > --
> > wing
> > Hope is a good thing, maybe the best of things.
>
> --
> []\ [] ShiningRay
> []\\[]
> [] \[]http://shiningray.cn- Hide quoted text -
>
> - Show quoted text -
Kouga
--
签名是什么东西？？
bitjoe
实话说，我觉得，vista，不错。让我对windows 2007又有了期待。
linux桌面太不强劲了，啥时候再以界面为中心设计一个操作系统，可能有希望打败微软。
2009/4/23 qiaojie <qia...@gmail.com>:
Kouga
)<-突然發現Gmail有好玩的表情~Vista很難用很難用，非常難用——這是我的看法。用過Windows2007過後就直接拋棄了Vista~
Linux非常非常絢麗~~真的~而且一些高清播放還不需要特別設置就可以直接播放……
--
签名是什么东西？？
Linker
Nil
这一块到第二块，第二块再到第三块，在有cache的情况下往往只需要在其中几块上做寻路，其他的直接用cache做结果。这就造成每个寻路服务器要取
一部分cache出来，再算几个块，所以每个服务器自己要cache。
qiaojie的算法是一个比较标准的分布计算，统一cache的想法，存数据表格这样的东西很好用，但是如果一个Manager在持有一大堆
cache数据的情况下还是不能直接得出结果，而必须要一套寻路逻辑来补完的话，像ppt里那种样子的做法还是有点道理的。
PS:看到这个做法我倒是想到，在NavMesh固定的情况下，从一个mesh穿过另外一个到第三个的路径其实是固定的。当服务器运行足够长时间，那些
缓冲数据可以覆盖所有地图，这时候只要用个文件存起来，以后服务器运行只要算一头一尾，其他的全部从cache出，可能效果不错哦
On 4月23日, 下午6时15分, Linker <linker.m....@gmail.com> wrote:
> 非常同意qiaojie 的看法。这个寻路我是做过的，用的是NavMesh.
> 多线程领导跟随模式。
> 很简单就实现了。
> 上文资料中的方案实在是只学到Erlang的皮（多进程，其实是多协程），没学到骨（消息传递无共享模型）。
> 实在是南辕北辙，差劲的很！！！
>
> 2009/4/23 qiaojie <qiao...@gmail.com>
>
>
>
> > 这个寻路系统的设计方案真是巨傻啊
> > 只能支持单台寻路服务器，没什么伸缩性，用什么多进程共享内存方式，这个跟多线程没任何本质差别，还需要用调度程序来同步共享内存的访问，好愚昧啊。
> > 其实在他的方案基础上稍做修改就能支持分布式的寻路系统了，我不知道是他故意不拿出来误导听众，还是脑子进水了才设计出一个这么傻的方案。
>
> > 2009/4/23 benegg <ide...@163.com>
>
> >> 西山居的陈杰的幻灯片, 讲了网游服务端寻路, 当然也包括网游服务器的架构. 有不少有用的概念.
>
> >>http://docs.google.com/Present?docid=dds5zgx6_429v8d9crgc
>
> >> 另一个人总结了一些有用的东西:
>
> >> 1. 将独立的模块封装成单独的进程。
> >> 2. 进程间通讯(IPC)使用TCP，为什么使用TCP而不是其他更高效的本地IPC方式？一方面因为大部分项目都有现成稳定的TCP模块，另
> >> 外一方面更容易将一台服务器拆分到多个服务器，程序完全不用修改。
>
> >>http://timyang.net/architecture/game-backend/
>
> >> 强烈推荐想要开发网游的朋友都好好看这两篇文章!
> >> ------
> >> 转自:http://www.benegg.com/?p=23
>
> --
> Regards,
> Linker Lin
Nil
别？我猜想是不是两个不相干的锁在Lock的时候检查互斥也会造成资源消耗，而在不同的进程里没这个问题？关于锁的具体机制我没什么研究，请教一下各位
qiaojie
Nil
这个就可以缓存，然后再算一个地图3到终点的路径。有点像路由算法
On 4月23日, 下午9时27分, qiaojie <qiao...@gmail.com> wrote:
> 如果想用缓存数据加快寻路的话，PathFindingWorker内部也可以缓存，不过一般不太会这么做，没见过有什么寻路算法是利用缓存的路径来寻路的。至于缓存全部路径，这个基本上是不现实的，除非地图很小，否则很快会把内存耗尽。
>
> 2009/4/23 Nil <nil.t...@gmail.com>
qiaojie
Nil
On 4月23日, 下午9时39分, qiaojie <qiao...@gmail.com> wrote:
> 这个你应该首先去读一下NavMesh的相关算法，不然我们没有讨论的基础。
>
> 2009/4/23 Nil <nil.t...@gmail.com>
Linker
Kouga
--
签名是什么东西？？
Kouga
Sparkle
验证比生产的成本要低很多
2009/4/23 benegg <ide...@163.com>:
> 这种方法几乎不会被使用, 因为客户端是不可靠的, 很容易作弊.
>
> On Apr 23, 11:07 am, Kouga <ncwh...@gmail.com> wrote:
>> 另外一個就是，將尋路算法分佈到用戶端，讓客戶幫忙計算。
>>
>> 2009/4/23 Kouga <ncwh...@gmail.com>
>>
>>
>>
>> > 好東東~收下了~其實這些事情我們也會考慮，但是不是那麼完整就是了......
>>
>> > 2009/4/23 benegg <ide...@163.com>
>>
>> > 西山居的陈杰的幻灯片, 讲了网游服务端寻路, 当然也包括网游服务器的架构. 有不少有用的概念.
>>
>> >>http://docs.google.com/Present?docid=dds5zgx6_429v8d9crgc
>>
>> >> 另一个人总结了一些有用的东西:
>>
>> >> 1. 将独立的模块封装成单独的进程。
>> >> 2. 进程间通讯(IPC)使用TCP，为什么使用TCP而不是其他更高效的本地IPC方式？一方面因为大部分项目都有现成稳定的TCP模块，另
>> >> 外一方面更容易将一台服务器拆分到多个服务器，程序完全不用修改。
>>
>> >>http://timyang.net/architecture/game-backend/
>>
>> >> 强烈推荐想要开发网游的朋友都好好看这两篇文章!
>> >> ------
>> >> 转自:http://www.benegg.com/?p=23
>>
>> > --
>> > 签名是什么东西？？
>>
>> --
>> 签名是什么东西？？
> >
>
CoreWar
况且就算服务器生成路径，客户端发过来的走路信息还是要逐一验证的吧
On 4月24日, 上午9时19分, Sparkle <pope...@gmail.com> wrote:
> 其实多少还是可行的，客户端负责生成路径，服务器只用验证路径就行了
> 验证比生产的成本要低很多
老范
Regards
FanYun
yuliuxuanke
Kouga
--
签名是什么东西？？
Kouga
现在我终于明白，像这种层次上的差距是得下苦功才能补足的了，通过沟通可以解决一些问题，但是对于只有单向管道的同志来说就很抱歉了。自大到无以复加，是很难在一个团队中保持有效沟通和协作的。而这里，是一个论坛，本来就是用来沟通而不是炫耀或者泄愤的地方，所以请大家发言之前三思而后行，并记住“己所不欲，勿施于人”的道理。
--
签名是什么东西？？
sunway
On 4月24日, 上午1时46分, Linker <linker.m....@gmail.com> wrote:
> 缓存对静态障碍有用。如果需求涉及动态阻挡的话就不行了。
>
> On 4/23/09, Nil <nil.t...@gmail.com> wrote:
>
>
>
>
>
> > 寻路算法是不缓存的，但是我可以把地图分块，比方说我要从地图1到地图3，那么从地图1走到地图2的路要搜（起点），地图2到地图3的路其实是固定的，
> > 这个就可以缓存，然后再算一个地图3到终点的路径。有点像路由算法
>
> > On 4月23日, 下午9时27分, qiaojie <qiao...@gmail.com> wrote:
> >> 如果想用缓存数据加快寻路的话，PathFindingWorker内部也可以缓存，不过一般不太会这么做，没见过有什么寻路算法是利用缓存的路径来寻路的。至-于缓存全部路径，这个基本上是不现实的，除非地图很小，否则很快会把内存耗尽。
> linker.m....@gmail.com- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Linker
Nil
“看到他强调把独立模块封装成单独的进程，我有个疑问。如果一个模块完全独立，我把它扔到一个线程里自己跑，反正它也不用和其他线程互锁，那性能有多大
区
别？我猜想是不是两个不相干的锁在Lock的时候检查互斥也会造成资源消耗，而在不同的进程里没这个问题？关于锁的具体机制我没什么研究，请教一下各
位”
Kouga
在這種環境下，派生線程則要可憐的多，它本身不允許攜帶大量資源，只能使用進程提供的環境和一個小小的堆疊，所以只能為任務而生，為任務而滅，還不得不在使用進程的資源前拿到鑰匙上鎖而且時間不能太長……
此處有一個漏洞，其實線程自己也可以通過new堆空間來分配數據，不過那個東西相當不好管理，不小心洩露的問題極度容易發生(shared_ptr幫不了你，thread_special_ptr或許可以幫你解決這個問題)。
另外，再說進程所在的外部環境，即操作系統來說，它給每個進程能夠使用的資源也是限定了的，比如只能有4G內存空間，只能打開多少個句柄等等。在密集運算發生的時候，資源往往就是一個不小心就不夠用的局面。
最後，如PPT所述，一旦需要熱升級，或者需要後備運作系統，那麼開啟一個新的進程要容易的多(特別Windows這種系統還不允許你在程序運行的同時對它升級的情況下)，開啟線程……那個……似乎將簡單問題反而複雜化了不是么？
所以，用進程來分割是一個比較好的選擇，而且操作系統也對進程調度更加容易一點(你嘗試使用任務管理器去調度一個線程試試看？)
--
签名是什么东西？？
monkey ben_shan_
monkey ben_shan_
2009/4/24, Kouga <ncw...@gmail.com>:
--
祝工作顺利，身体健康。
高 敬上
sunway
On 4月24日, 下午5时57分, monkey ben_shan_ <benshan.mon...@gmail.com> wrote:
> 其实还是感觉服务器的寻路，在游戏中意义不是很大，要是做在客户端就可以了。
>
> 2009/4/24, monkey ben_shan_ <benshan.mon...@gmail.com>:
>
>
>
>
>
>
>
> > 呵呵，其实我觉得，正如老范，kouga所说的，游戏里面的路径搜索和现在都在用的地理信息系统，google的map都可以提供很精确，多方位的路径方案哦，-个人觉得交通站的设立还是可行滴。对地图数据进行预处理之后cache只要一次初始化，可以按照层次初始化，让寻路模块中留下的计算量最小，比如要从A
> > 到 B, 中间需要经过1，2，3，4 几个交通站，交通站之间的路径是在cache中的，寻路模块只计算A->1, 4->B,
> > 还有1,2,3,4之间的油画就可以了。然后在寻路模块中设立log，定期根据log更新交通站的位置和数量。 小弟愚见，欢迎拍砖。。
>
> > 2009/4/24, Kouga <ncwh...@gmail.com>:
>
> >> 這個問題其實可以這麼想：其實單個進程就是一個帶有資源的線程，它特殊在可以再開闢線程使用它的資源為它賣命。
>
> >> 在這種環境下，派生線程則要可憐的多，它本身不允許攜帶大量資源，只能使用進程提供的環境和一個小小的堆疊，所以只能為任務而生，為任務而滅，還不得不在使用進-程的資源前拿到鑰匙上鎖而且時間不能太長......
>
> >> 此處有一個漏洞，其實線程自己也可以通過new堆空間來分配數據，不過那個東西相當不好管理，不小心洩露的問題極度容易發生(shared_ptr幫不了你，t-hread_special_ptr或許可以幫你解決這個問題)。
>
> >> 另外，再說進程所在的外部環境，即操作系統來說，它給每個進程能夠使用的資源也是限定了的，比如只能有4G內存空間，只能打開多少個句柄等等。在密集運算發生的-時候，資源往往就是一個不小心就不夠用的局面。
>
> >> 最後，如PPT所述，一旦需要熱升級，或者需要後備運作系統，那麼開啟一個新的進程要容易的多(特別Windows這種系統還不允許你在程序運行的同時對它升級-的情況下)，開啟線程......那個......似乎將簡單問題反而複雜化了不是么？
>
> >> 所以，用進程來分割是一個比較好的選擇，而且操作系統也對進程調度更加容易一點(你嘗試使用任務管理器去調度一個線程試試看？)
>
> >> 2009/4/24 Nil <nil.t...@gmail.com>
>
> >>> 你们不要无视我这个问题嘛，谁说说？
>
> >>> "看到他强调把独立模块封装成单独的进程，我有个疑问。如果一个模块完全独立，我把它扔到一个线程里自己跑，反正它也不用和其他线程互锁，那性能有多大
> >>> 区
> >>> 别？我猜想是不是两个不相干的锁在Lock的时候检查互斥也会造成资源消耗，而在不同的进程里没这个问题？关于锁的具体机制我没什么研究，请教一下各
>
> >>> 位"
>
> >>> On 4月23日, 下午8时40分, Nil <nil.t...@gmail.com> wrote:
> >>> > 看到他强调把独立模块封装成单独的进程，我有个疑问。如果一个模块完全独立，我把它扔到一个线程里自己跑，反正它也不用和其他线程互锁，那性能有多大区
> >>> > 别？我猜想是不是两个不相干的锁在Lock的时候检查互斥也会造成资源消耗，而在不同的进程里没这个问题？关于锁的具体机制我没什么研究，请教一下各位
>
> >> --
> >> 签名是什么东西？？
>
> > --
> > 祝工作顺利，身体健康。
> > 高 敬上
>
> --
> 祝工作顺利，身体健康。
> 高 敬上- 隐藏被引用文字 -
>
> - 显示引用的文字 -
benegg
---------------
http://www.benegg.com
Linker
--
Kouga
--
签名是什么东西？？
monkey ben_shan_
Kouga
另外，主服务器的负担请设计在“服务”的进程内，表把所有问题都混合起来考虑，那样你永远无法设计一个完整的系统。
--
签名是什么东西？？
monkey ben_shan_
BB.Case
NPC逻辑相对好独立一点，扯上分布式游戏服务器就有扯淡的嫌疑了，好分的模块早都分了。
erlong的进程式安全用在NPC服务器上，感觉也有点牵强。
还有扯淡的“分派模块简单，消耗小”一说，既然是TCP，你工作都交给硬件了。
动态缓存寻路结果也不靠谱，都分布了，这么复杂的功能，加个机器就解决了。
sunway
不知道最新的《永恒之塔》是不是吸收了这个优点。
Linker
--
Kouga
说“官腔”还真不知道是基于哪点看出来的……请指教。
说实在的，TCP和硬件的关系，偶都有点朦胧~依稀记得TCP下面还有2层才是硬件吧？
缓存不靠谱……说实话，偶也觉得不是很靠谱，但是缓存只要命中就可以即时生效丫~
加个机器就解决了……如果要开多个服务器组，是不是都要多加一个机器？成本如何考虑？
另外说一个让人不快的说法，看完此回帖，感觉“临时打工仔腔”多一点。
--
签名是什么东西？？
Kouga
所以，如果要说“脚本”能让怪物强大很多……这个不假。但是智力这个问题——只与脚本编写人员的智力挂钩吧？呵呵。
另外，重复一次发言：怪物既然都“闹独立”了，它就是一个“特权玩家”而已~让它存活在服务器上就OK~同步的话，你如何与玩家同步，就如何与它同步。
--
签名是什么东西？？
sunway
而普通的怪物一般只有简单的AI，攻击离它一定范围内的玩家。
如果要让怪物具有更高等级的AI,把这部分逻辑独立出去是必然的，高等级
的AI可以增加游戏的乐趣。
On 4月28日, 上午9时22分, Kouga <ncwh...@gmail.com> wrote:
> 囧~就我所知道的，很多怪物、NPC都是基于脚本运作的，哪怕是单机都是如此。
>
> 所以，如果要说“脚本”能让怪物强大很多……这个不假。但是智力这个问题——只与脚本编写人员的智力挂钩吧？呵呵。
>
> 另外，重复一次发言：怪物既然都“闹独立”了，它就是一个“特权玩家”而已~让它存活在服务器上就OK~同步的话，你如何与玩家同步，就如何与它同步。
>
> 2009/4/27 sunway <sunhui...@gmail.com>
sunway
对事不要对人～
Kouga
另外，关于对人的评价，其实偶只基于一个准则“以彼之道，还彼之身”。
单机游戏用脚本很正常，网络游戏里面 任务、NPC等等这些用脚本很正常，
而普通的怪物一般只有简单的AI，攻击离它一定范围内的玩家。
如果要让怪物具有更高等级的AI,把这部分逻辑独立出去是必然的，高等级
的AI可以增加游戏的乐趣。
--
签名是什么东西？？
sunway
本论坛的最高宗旨～和谐～
On 4月28日, 上午10时48分, Kouga <ncwh...@gmail.com> wrote:
> 增加游戏乐趣的同时增加服务器负担~这是鱼与熊掌的关系~偶仍旧倾向于——让玩家的计算资源帮忙拓展服务器可用资源吧~(P2P计算网格- -?)
>
> 另外，关于对人的评价，其实偶只基于一个准则“以彼之道，还彼之身”。
>
> 2009/4/28 sunway <sunhui...@gmail.com>
BB.Case
那个清单，搞过服务器开发的有几个开不出来？个人觉得，真正能为逻辑减负的思路，还是应该在低耦合的代码组织上，就像上次巨人那位提到的，他们的国战服
务器，去掉了相当多的逻辑功能。只是觉得吧这种功能上的分化建立在进程这个级别，实在是太理想。
分派模块交给硬件这句话没说对，我只是觉得，既然都是进程间TCP通信了，还扯什么任务同步，难道他的TCP在应用层还是轮询等待的？？？
寻路的缓存算法，重用怎么评估？复杂度多高，又不是CPU的寻址命中这么简单的事情？易维护？可复用性有多少？这些不考虑么？这么大的成本，难道不是加
机器更划算？
总的来说，看完没收获！！！感觉像看报告，也许偶层次太低了-_-
On 4月28日, 上午9时19分, Kouga <ncwh...@gmail.com> wrote:
BB.Case
慕容家下场也不咋滴呢
开个玩笑哈，嘿嘿……
On 4月28日, 上午10时48分, Kouga <ncwh...@gmail.com> wrote:
> 增加游戏乐趣的同时增加服务器负担~这是鱼与熊掌的关系~偶仍旧倾向于——让玩家的计算资源帮忙拓展服务器可用资源吧~(P2P计算网格- -?)
>
> 另外，关于对人的评价，其实偶只基于一个准则“以彼之道，还彼之身”。
>
> 2009/4/28 sunway <sunhui...@gmail.com>
monkey ben_shan_
Linker
--
Linker
--
kennywong
On 4月28日, 下午7时29分, Linker <linker.m....@gmail.com> wrote:
> 同步数据太费。
>
> On 4/28/09, 蔚 <huangweil...@21cn.com> wrote:
>
> > 我想,大家做的游戏都是基于地图的吧.一个地图服务器处理某一区域的玩家.
> > 当要求进入这一区域的玩家超过单台服务器承载能力的时候怎么办.可以把
> > 这些玩家迁移到另一台空闲的服务器吗.两台服务器上的玩家,可以互相看到
> > 对方,并且实施某种行为.但操作的数据却并不在同一台服器上.这跟独立的
> > NPC服务器处理情况很相似.
>
> --
> Sent from my mobile device
>
> Regards,
> Linker Lin
那就要看一个对象到底有多少数据是需要其它对象关心,和怎么去同步了.当然目前
我还没想到很好的方法.但很显然,如果我们要突破单区域的人数承载限制,只有这样
做.
Kouga
在“和谐”如寺庙的地方，还有护法金刚存在。可见，一味河蟹只会横着爬，不会转弯的。
> 增加游戏乐趣的同时增加服务器负担~这是鱼与熊掌的关系~偶仍旧倾向于----让玩家的计算资源帮忙拓展服务器可用资源吧~(P2P计算网格- -?)
>
> 另外，关于对人的评价，其实偶只基于一个准则"以彼之道，还彼之身"。
>
> 2009/4/28 sunway <sunhui...@gmail.com>
>
> > 单机游戏用脚本很正常，网络游戏里面 任务、NPC等等这些用脚本很正常，
> > 而普通的怪物一般只有简单的AI，攻击离它一定范围内的玩家。
> > 如果要让怪物具有更高等级的AI,把这部分逻辑独立出去是必然的，高等级
> > 的AI可以增加游戏的乐趣。
>
> --
> 签名是什么东西？？
--
签名是什么东西？？
sunway
On 4月30日, 上午9时44分, Kouga <ncwh...@gmail.com> wrote:
> 没什么不合适的~当然~肯定不能让玩家有"篡改"的可能~也并不是因为玩家在该场景中，它分配到的计算任务就一定是他周围的妖怪~计算和实际游戏部分可以分割开-的~这个概念一定要确立起来，否则此类"计算"任务就是天方夜谭了。其次，需要计算的一定是一些"大运算量"的任务，如果只是简单如3+2-5的计算交给玩家节-点，无论怎么想都划不来。再次，我们可以建立有效的"验算服务"，如果发现连续"计算错误"则视为作弊~如此。
>
> 在"和谐"如寺庙的地方，还有护法金刚存在。可见，一味河蟹只会横着爬，不会转弯的。
>
> 2009/4/28 snway <sunhui...@gmail.com>
>
>
>
>
>
> > 怪物的AI让玩家计算恐怕不是很合适吧。
>
> > 本论坛的最高宗旨～和谐～
>
> > On 4月28日, 上午10时48分, Kouga <ncwh...@gmail.com> wrote:
> > > 增加游戏乐趣的同时增加服务器负担~这是鱼与熊掌的关系~偶仍旧倾向于----让玩家的计算资源帮忙拓展服务器可用资源吧~(P2P计算网格- -?)
>
> > > 另外，关于对人的评价，其实偶只基于一个准则"以彼之道，还彼之身"。
>
> > > 2009/4/28 sunway <sunhui...@gmail.com>
>
> > > > 单机游戏用脚本很正常，网络游戏里面 任务、NPC等等这些用脚本很正常，
> > > > 而普通的怪物一般只有简单的AI，攻击离它一定范围内的玩家。
> > > > 如果要让怪物具有更高等级的AI,把这部分逻辑独立出去是必然的，高等级
> > > > 的AI可以增加游戏的乐趣。
>
> > > --
> > > 签名是什么东西？？
>
> --
> 签名是什么东西？？- 隐藏被引用文字 -
>
> - 显示引用的文字 -
CoreWar
具体怎么分配就不是特别清楚了。这样做的后果就是外挂满天飞，吸怪，无敌等等。
sunway
对于当今强调团队合作的游戏，经常出现N个人组队打BOSS的场景，这种客户端计算怪物AI的策略几乎没有用武之地。
当然也不排除客户端计算AI，这个就是传统的单机版本游戏。做单机版本游戏和服务器端就没多大关系了。
Zoom.Quiet
http://ecug.org/agenda/
上的一个展示，并不是西山居真实的运营模式，是陈杰个人的思考结精，
非常有参考价值的...
2009/4/23 jacky zhao <jacky...@gmail.com>:
> 巨傻啊、好愚昧啊、脑子进水了啊。
>
> 讨论问题，最好不要带这种 “人身攻击” 型的话。
>
> 2009/4/23 qiaojie <qia...@gmail.com>
>>
>> 这个寻路系统的设计方案真是巨傻啊
>> 只能支持单台寻路服务器，没什么伸缩性，用什么多进程共享内存方式，这个跟多线程没任何本质差别，还需要用调度程序来同步共享内存的访问，好愚昧啊。
>> 其实在他的方案基础上稍做修改就能支持分布式的寻路系统了，我不知道是他故意不拿出来误导听众，还是脑子进水了才设计出一个这么傻的方案。
>>
>>
>>
>>
>> 2009/4/23 benegg <ide...@163.com>
>>>
>>> 西山居的陈杰的幻灯片, 讲了网游服务端寻路, 当然也包括网游服务器的架构. 有不少有用的概念.
>>>
>>> http://docs.google.com/Present?docid=dds5zgx6_429v8d9crgc
>>>
>>> 另一个人总结了一些有用的东西:
>>>
>>> 1. 将独立的模块封装成单独的进程。
>>> 2. 进程间通讯(IPC)使用TCP，为什么使用TCP而不是其他更高效的本地IPC方式？一方面因为大部分项目都有现成稳定的TCP模块，另
>>> 外一方面更容易将一台服务器拆分到多个服务器，程序完全不用修改。
>>>
>>> http://timyang.net/architecture/game-backend/
>>>
>>> 强烈推荐想要开发网游的朋友都好好看这两篇文章!
>>> ------
>>> 转自: http://www.benegg.com/?p=23
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
Free as in Freedom! 哲思自由软件社区:http://zeuux.org
bitjoe
但是微软宣传win7好像像win98，感觉突出了上网本。
你们也都在跑题，呵呵，我继续跑。
跑題太遠了……(但是偶決定跟著跑一跑~)<-突然發現Gmail有好玩的表情~
Vista很難用很難用，非常難用——這是我的看法。用過Windows2007過後就直接拋棄了Vista~
等windows 7出来和windows 2007比较下，是否哪个最优。像windows NT professional这样子的，最好用了。
Linux非常非常絢麗~~真的~而且一些高清播放還不需要特別設置就可以直接播放……
2009/4/23 bitjoe <darve...@gmail.com>有没有人觉得vista很好用的啊？
实话说，我觉得，vista，不错。让我对windows 2007又有了期待。
linux桌面太不强劲了，啥时候再以界面为中心设计一个操作系统，可能有希望打败微软。
2009/4/23 qiaojie <qia...@gmail.com>:
> 这个寻路系统的设计方案真是巨傻啊
> 只能支持单台寻路服务器，没什么伸缩性，用什么多进程共享内存方式，这个跟多线程没任何本质差别，还需要用调度程序来同步共享内存的访问，好愚昧啊。
> 其实在他的方案基础上稍做修改就能支持分布式的寻路系统了，我不知道是他故意不拿出来误导听众，还是脑子进水了才设计出一个这么傻的方案。
>
>
>
>
> 2009/4/23 benegg <ide...@163.com>
>>
>> 西山居的陈杰的幻灯片, 讲了网游服务端寻路, 当然也包括网游服务器的架构. 有不少有用的概念.
>>
>> http://docs.google.com/Present?docid=dds5zgx6_429v8d9crgc
>>
>> 另一个人总结了一些有用的东西:
>>
>> 1. 将独立的模块封装成单独的进程。
>> 2. 进程间通讯(IPC)使用TCP，为什么使用TCP而不是其他更高效的本地IPC方式？一方面因为大部分项目都有现成稳定的TCP模块，另
>> 外一方面更容易将一台服务器拆分到多个服务器，程序完全不用修改。
>>
>> http://timyang.net/architecture/game-backend/
>>
>> 强烈推荐想要开发网游的朋友都好好看这两篇文章!
>> ------
>> 转自: http://www.benegg.com/?p=23
>>
>
>
> >
>
--
签名是什么东西？？
Kouga
此时，有几种方案：第一是将每个洋葱皮对应一个场景，玩家见到的就是“多线服务器”
第二是将每层洋葱皮拿一个进程来服务，然后就有“同步问题”
第三是，玩家可以看到整个透明的洋葱层，然后在需要与其它层的玩家交互时，才和它取得联系——嗯？似乎光展示玩家的状况是不需要同步的了？
--
签名是什么东西？？
Kouga
Kouga
回题，咱们将游戏设计成“树”好不好？那么计算任务就是某些枝叶之间需要完成的了。通过区域划分后，将需要的运算直接分派到就近节点(从客户端到客户端，P2P)，计算完毕直接反馈，服务器只需要在根部“观察"这个世界是否符合规则就是了。
--
签名是什么东西？？
qiaojie
是根本没实现过，凭空yy出来的设计，难怪会如此不靠谱。反正yy么，怎么忽悠都是可
以的，吹的比他更神乎其神的多的是，sunway比较清楚吧，当初zona吹的怎么神，把
天桥忽悠的那是一愣一愣的，大把的往里砸银子，最后还不是连个泡都没见着。还有个
叫BigWorld的，刚出来的时候那个宣传，大有一统网游服务器市场的气势，用下来才发
现问题一堆，做出来的游戏还不及土制的服务器。
有空在这里yy些不靠谱的概念，不如自己去实践一下，成天yy是不会有什么提高的。
蔚
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
回题，咱们将游戏设计成“树”好不好？那么计算任务就是某些枝叶之间需要完成的了。通过区域划分后，将需要的运算直接分派到就近节点(从客户端到客户端，P2P )，计算完毕直接反馈，服务器只需要在根部“观察"这个世界是否符合规则就是了。
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
AI要做的计算到底是什么,只是寻路吗?
假设我的NPC有很多种攻击和防守手段,则NPC要根据他周围的N个目标的情况,例如血量,职业或等级之类的
做出决策.那么,NPC自身的这么多状态,和NPC周围目标的这些状态.我们怎么交给负责计算的客户端呢.
Kouga
谢昊阳
Kouga
wan...@svc.com.cn
-----邮件原件-----
发件人: dev4s...@googlegroups.com [mailto:dev4s...@googlegroups.com] 代表 Zoom.Quiet
发送时间: 2009年4月30日 11:14
收件人: dev4s...@googlegroups.com
主题: Re: 分享: 陈杰谈网游服务器的后端技术
Kouga
tao yuan
bitjoe
2009/5/9 tao yuan <yty...@gmail.com>:
tao yuan
Kouga
Horin153
ppt中已经讲明了为什么要共享内存：因为 nav_mesh 数据量太大，并且是只读的。如果每个进程都有份自己的 nav_mesh 数据，那一台
服务器可能开一两个寻路进程就内存紧张了。
如果寻路做得这样复杂，其地图数据量必然是庞大的。
网游服务器如果是按集群进行部署的，一个集群中如果逻辑服务器只有几台，有哪个必要也配几台寻路服务器吗？ppt中有附图说明了这种部署情况。
即使如你设计，实质上也是把共享cache移到manager进程，manager进程更新cache时，照样要考虑互斥问题，有时可能还要考虑更新
cache的时序问题。
只要是协作处理共享资源，逻辑上是绕不开同步互斥问题的。
On 4月23日, 下午1时42分, qiaojie <qiao...@gmail.com> wrote:
> 改进很简单，用单个PathFindingManager进程来接受逻辑服务器的寻路请求再转发给各个PathFindingWorker进程来处理，而Pat hFindingManager可以缓存PathFindingWorker发回的结果。改进以后，各个PathFindingWorker进程就是独立的工作 进程，不再需要任何同步操作，另外也不需要用共享内存，要多核处理的话可以开多个线程，这样就可以把PathFindingWorker部署到多个物理服务器上 了。寻路结果的缓存放到PathFindingManager上完成，PathFindingManager本身计算负载很小，所以用单进程单线程就可以完成， 不存在同步和锁的问题。PathFindingManager本身还可以承担PathFindingWorker的管理和负载均衡。
>
> 2009/4/23 wing <wing922w...@gmail.com>
>
>
>
> > 确实如此，程序员很多都有这个毛病，我也经常这么乱说话，得罪很多人，我觉得这就是糟糕的"UI"，也许本来你的建议非常有建设性，但是因为你说的太直接，对方 产生了反感，再好的建议也很难被顺利接受了。
>
> > 不过大家都是程序员，都包容理解一些，比如我觉得自己就是个sb，所以别人要说我非常sb时候，就没那么生气，不回应直接忽略过去，大家继续讨论这个服务器设计 的如何，我很感兴趣，但是对寻路这些东西不太懂，更兴趣的是整个架构可以借鉴的部分。
>
> > qiaojie能不能具体说说这个方案可以优化或者你设为设计不良的部分，很有兴趣听听。
>
> > 2009/4/23 Allen Jiang <jiangguilong2...@gmail.com>:
> > > 不瞒你说，凡是地球人都会朝这方向理解，可能这是你平时的说话习惯，言者无心，听着有意，但这种说话方式实在"设计"的不好。
>
> > > ----- Original Message -----
> > > From: qiaojie
> > > To: dev4s...@googlegroups.com
> > > Sent: Thursday, April 23, 2009 1:02 PM
> > > Subject: Re: 分享: 陈杰谈网游服务器的后端技术
> > > 好吧，其实我只是想说这个设计不好，对事不对人。
> > > 你一定要往人上面理解，那可以自动忽略我说的话。
>
> > > 2009/4/23 jacky zhao <jackyz.z...@gmail.com>
>
> > >> 巨傻啊、好愚昧啊、脑子进水了啊。
>
> > >> 讨论问题，最好不要带这种 "人身攻击" 型的话。
>
> > >> 2009/4/23 qiaojie <qiao...@gmail.com>
>
> > >>> 这个寻路系统的设计方案真是巨傻啊
> > >>> 只能支持单台寻路服务器，没什么伸缩性，用什么多进程共享内存方式，这个跟多线程没任何本质差别，还需要用调度程序来同步共享内存的访问，好愚昧啊。
> > >>> 其实在他的方案基础上稍做修改就能支持分布式的寻路系统了，我不知道是他故意不拿出来误导听众，还是脑子进水了才设计出一个这么傻的方案。
>
> > >>> 2009/4/23 benegg <ide...@163.com>
>
> > >>>> 西山居的陈杰的幻灯片, 讲了网游服务端寻路, 当然也包括网游服务器的架构. 有不少有用的概念.
>
> > >>>>http://docs.google.com/Present?docid=dds5zgx6_429v8d9crgc
>
> > >>>> 另一个人总结了一些有用的东西:
>
> > >>>> 1. 将独立的模块封装成单独的进程。
> > >>>> 2. 进程间通讯(IPC)使用TCP，为什么使用TCP而不是其他更高效的本地IPC方式？一方面因为大部分项目都有现成稳定的TCP模块，另
> > >>>> 外一方面更容易将一台服务器拆分到多个服务器，程序完全不用修改。
>
> > >>>>http://timyang.net/architecture/game-backend/
>
> > >>>> 强烈推荐想要开发网游的朋友都好好看这两篇文章!
> > >>>> ------
> > >>>> 转自:http://www.benegg.com/?p=23
>
> > --
> > wing
> > wing922w...@gmail.com
> > Hope is a good thing, maybe the best of things.
qiaojie
重点在于cache上，用多进程在共享内存里维护是非常糟糕的设计，把cache移到manager进程去维护就不存在互斥的问题，完全可以串行化的更新cache，
没人会傻到开几个线程去刷新cache。
至于部署的问题是这样的，假设你一个集群有10台逻辑服务器，他们共享1台寻路服务器，那么每台逻辑服务器平均只能获得10%的寻路服务器的计算资源，
既然只需要10%的计算资源就可以满足寻路的性能要求，在逻辑服务器上挤一挤牙膏（或者升级一下硬件）就轻松可以搞定了，何必花那么大力气把寻路服
务单独抽出来另外搞个进程？何况，分布式计算还有网络通讯开销，最后能够获得的性能收益基本可以忽略。
2009/5/15 Horin153 <hori...@gmail.com>:
Kouga
--
签名是什么东西？？