分布式 MMO Framework ---- DarkStar
Kasicass/汤泽江
不知道有没有做过'分布式'项目的同学，给点资料、经验么，谢谢~ 呵呵~
最近发现 Sun 的这个项目，兴趣颇浓。
http://www.projectdarkstar.com/
Yidong Fang
Darkstar不错，貌似是我一直要找的东东, 呵呵.
我在看一篇有关Paper, 分享一下:
SEMMO: A Scalable Engine for Massively Multiplayer
Online Games
ACM的, 不过应该是conference性质的, 不算学术性很强的文章. 我感兴趣的一个原因是这个作者好像是Alan Demers的学生(Alan Demers是第二作者). Alan Demers之前在Xerox实验室, 比较早把流行病学数学模型引入到分布式计算(后来的gossip).
--
JSON: Action in AJAX!
JSON - http://www.json.org
JSON.simple - http://code.google.com/p/json-simple/
Kasicass
最近写了一遍小小的总结，分享下。目前我自己实际中使用的还是第一种“单服结构”，不过是多线程版，减少进程间通讯的开销。
http://kasicass.blog.163.com/blog/static/3956192009570434695
只是最近看到 DarkStar，觉得比较有意思，就问问看有没有同学在实际项目中使用分布式~ :-)
虽然公司其他项目有使用分布式引擎，不过非项目组的人是看不到的代码的，呵呵。只能找开源的来自己研究了。
对于 MMO 的网络库，知名且开源的还有 RakNet、TNL(Torque Network Lib)。
Yidong Fang 写道:
> 泽江同学之前不是也一直做MMORPG吗？
> Darkstar不错，貌似是我一直要找的东东, 呵呵.
> 我在看一篇有关Paper, 分享一下:
> SEMMO: A Scalable Engine for Massively Multiplayer
> Online Games
>
> ACM的, 不过应该是conference性质的, 不算学术性很强的文章. 我感兴趣的一个
> 原因是这个作者好像是Alan Demers的学生(Alan Demers是第二作者). Alan
> Demers之前在Xerox实验室, 比较早把流行病学数学模型引入到分布式计算(后来的
> gossip).
>
> 2009/6/6 Kasicass/汤泽江 <kasi...@gmail.com <mailto:kasi...@gmail.com>>
>
> :-) 这个 list 里面，用java的同学比较多吧。
> 不知道有没有做过'分布式'项目的同学，给点资料、经验么，谢谢~ 呵呵~
>
> 最近发现 Sun 的这个项目，兴趣颇浓。
> http://www.projectdarkstar.com/
>
>
>
>
> --
> JSON: Action in AJAX!
>
> JSON - http://www.json.org
> JSON.simple - http://code.google.com/p/json-simple/
>
> >
--
Best regards！
Kasicass/汤泽江 <kasicass_at_gmail_dot_com>
Yidong Fang
Kasicass
Yidong Fang 写道:
> Cool.
>
> 2009/6/8 Kasicass <kasi...@gmail.com <mailto:kasi...@gmail.com>>
>
> ...
Yidong Fang
2.1 System Architecture
The SEMMO system consists of many computational farms—
a high-bandwidth low-latency network of machines that are
geographically dispersed throughout the world. It also consists
of a central server farm. The virtual world is partitioned
into multiple zones. In the server farm, each zone is
mapped onto one server, called its zone server. One designated
server handles fringe effects; we call this server the
fringe server. The servers in the computational farms are
similarly partitioned, and each server in the computational
farm is associated with one server in the server farm. The
computational farms are geographically located in a manner
that minimizes the average network latency for the clients.
Kasicass
按目前多服常用的划分方式，就是一个游戏场景一个zone server(独立进程），那么玩家很多的场景，就是瓶颈了。
而按照存分布式的设计，无论是一个场景，还是一个场景中的某块区域，或则是几个场景，都可以放到一个zone server去负责计算。
而如何划分这些区域，则是manager server根据情况自己调度，把任务分派的具体的zone server上，实现动态的平衡。
比如：一个场景有很多玩家，运算量较多，则这个场景可能被分派到多个zone server中；而一个场景很少玩家，则可以把几个这样
的场景分派到一个zone server中。据说WOW就是类似此种的分布式。
SEMMO 还是比较有意思的，可惜看不到实现细节。:-P 好像没有代码下载吧~
Yidong Fang 写道:
> 它好像是基于zone来分解吧？
>
> 2.1 System Architecture
> The SEMMO system consists of many computational farms--
> a high-bandwidth low-latency network of machines that are
> geographically dispersed throughout the world. It also consists
> of a central server farm. The virtual world is partitioned
> into multiple zones. In the server farm, each zone is
> mapped onto one server, called its zone server. One designated
> server handles fringe effects; we call this server the
> fringe server. The servers in the computational farms are
> similarly partitioned, and each server in the computational
> farm is associated with one server in the server farm. The
> computational farms are geographically located in a manner
> that minimizes the average network latency for the clients.
>
> 2009/6/8 Kasicass <kasi...@gmail.com <mailto:kasi...@gmail.com>>
>
> 看完 SEMMO，大概的意思是客户端计算，服务器只负责转发，不过论文里面细
> 节基本没涉及到，感觉不到具体的使用价值。
>
> Yidong Fang 写道:
> > Cool.
> >
> > 2009/6/8 Kasicass <kasi...@gmail.com <mailto:kasi...@gmail.com>
> <mailto:kasi...@gmail.com <mailto:kasi...@gmail.com>>>
Yidong Fang
按照文中的意思, zone应该是按照场景来分的吧. 它比较有意思的一点是提供computational farms, 按照地理分布, 这样用户可以连接比较近的服务器, 减少网络延迟.
Yidong Fang
Kasicass
玩家就近选择服务器登陆。同时支持电信/网通双线接入(VPN)，比如服务器在电信的，可以在网通架一个服务器，专门
作为VPN中转，避免走电信<==>网通自己的中转，那个比较慢。
Yidong Fang 写道:
> 刚才看了文中一个截图, 好像是一个场景中不同的区域可以是独立的zone. 但是我
> 想这只是粒度上的一个考虑了, 不同游戏可以设定不同粒度.
>
> 2009/6/8 Yidong Fang <fangy...@gmail.com <mailto:fangy...@gmail.com>>
>
> 呵呵, 有提到一个游戏原型:Manhattan Pals.至于提不提供代码下载就不知道了.
> 按照文中的意思, zone应该是按照场景来分的吧. 它比较有意思的一点是提供
> computational farms, 按照地理分布, 这样用户可以连接比较近的服务器,
> 减少网络延迟.
Yidong
做client一般用C++ Builder还是VC++?
server端呢?有用Java的吗？
On 6月8日, 下午8时07分, Kasicass <kasic...@gmail.com> wrote:
> 恩，computational farms 的概念还是不错的。对于我们实际中的情况，就是把服务器放到全国不同的机房，然后鼓励
> 玩家就近选择服务器登陆。同时支持电信/网通双线接入(VPN)，比如服务器在电信的，可以在网通架一个服务器，专门
> 作为VPN中转，避免走电信<==>网通自己的中转，那个比较慢。
>
> Yidong Fang 写道:
>
> > 刚才看了文中一个截图, 好像是一个场景中不同的区域可以是独立的zone. 但是我
> > 想这只是粒度上的一个考虑了, 不同游戏可以设定不同粒度.
>
> > 2009/6/8 Yidong Fang <fangyid...@gmail.com <mailto:fangyid...@gmail.com>>
Kasicass
卖也卖不掉，个人觉得快退出历史舞台了。其实 java 也可以做，比如：jMonkeyEngine。
http://www.ardor3d.com/, jMonkeyEngine 的一个分支，作者原来在韩国 NCSoft 就是用 java 做的 MMO。
http://webservices.ctocio.com.cn/wsare/214/8887714.shtml
http://www.linkedin.com/in/jslack, :-) 工作经历是在这里看到的
服务器：主流的是 C/C++ 配合 Lua/Python。很多 webgame 后台都是 java，webgame 对服务器性能上相对要求低一些。
个人认为语言是次要的，对哪个语言更熟悉，一般都能开发出好的稳定的程序。不过 C/C++ 偏低层一点，优化起来
可以做得更彻底。
如果是第一次开发游戏，建议做 2D 而非 3D，webgame 是一个不错的选择。因为 3D 比 2D 复杂了太多，就如同服务器
“单进程单线程”到“分布式负载均衡”类似的巨大跨越。
2D库比较有名的就是云风GG的 windsoul 了。很多游戏都在用 windsoul。当然，webgame 目前是 flex(flash) 的天下。
而“回合制”与“即时制”游戏的差别也很大，服务端/客户端同步频率，后者要求高很多。
Yidong 写道:
> 问一个实现方面的问题:
> 做client一般用C++ Builder还是VC++?
> server端呢?有用Java的吗？
Yidong Fang
Kasicass
自己只做过“回合制”，“即时制”能碰到的复杂度，自己也没有多少概念。
Yidong Fang 写道:
> 专家就是专家啊，不错，谢谢分享.
Yidong Fang
我最近写了一个win32程序, 用了MFC, 感觉很糟, 有N种字符串: LPTSTR, BSTR, CString, LPBYTE (UTF8); 然后是N种数字转换函数: atoi, wtoi, ttoi; 接着是N种时间格式: CTime, SYSTEMTIME,time_t .....然后要自己算好内存需求, LocalAlloc或者CString::SysStringAlloc(), 用完要释放, 但是有些给了UI component指向之后又不能马上释放, 然后考虑在什么时间地点如何释放比较伤脑筋, 而且增加额外工作量. 有时候考虑自动变量然后用引用吧(通过CString cs, 然后传给&参数的方法), 层层传递之后, 如果有一个地方转换为LPTSTR, 打算长久指向, 如果随后那个自动变量出了scope自动销毁, 后果很严重.....如果是复制吧, 一来stack变量的快速优点没了, 二来还是得考虑内存释放问题.....
另外那些wrapper如CString, _variant_t, _bstr_t不知道他们怎么管理传递给他们的BSTR或者LPTSTR, 该谁来释放....这个可能是知识的问题.....
但是如果不用MFC, 纯API写工作量就更大了..... 你们用MFC吗？
呵呵, 发了一通牢骚, 可能是因为用惯了Java, 习惯了这种单纯性 (基本类型和句柄从stack来, 所有对象从heap来), 确定性, 健壮性, 简单性(大量很优美的类, 不用考虑include依赖冲突, 不用一个方法名字在头文件和cpp文件各写一次, 不用考虑COM版本兼容/redistribute问题) ..... 感觉VC++编程, 很多时间浪费在业务无关的代码上面了, 也许可以用boost来简化很多东西, 但是模板函数的debug和错误信息跟踪会慢慢变成一个恶梦....
如果要依靠不断的对象复制来减缓内存管理的压力, 或者不断alloc/free内存, 那么Java的机制也许提供更有竞争力的performance.... Java唯一的问题在于它垃圾回收器.....
最后, 觉得微软的开发环境IDE还是不错的.
Kasicass
其实 MFC M$ 自己也不维护了，都交给一家做 BCGControlBar 的公司。
官方的另一种选择，就是 ATL，据说对 win32api 的封装很不错，不过我没用过，不评价。T_T
国内有一个类似 ATL 的东西吧，叫 WinxGUI，是许同学(http://blog.csdn.net/xushiweizh)做的，
金山CTO，经验丰富，不过我也没用过。T_T
http://www.winxgui.cn/
下面来说说我们常用的东西。我们用的最多的是 wx。
如果只是做界面程序，其实 wxWidget(MFC-like, but simple) 或 gtk+(pure C) 都是不错的选择。
wx 就算用 C++ 来写，都还是十分方便的。一个熟悉 C++ 的新同学，一两周也可以用 wx 写出一个
内部工具的框架了。
如果熟悉某个脚本语言，使用 wxLua, wxPython 开发界面，逻辑都交给脚本来写，也是
十分方便的事情。我们就是这么干的，和 java 写界面基本上感觉差不多。
撤远一点。对于游戏内部来说，UI都是自己实现的，并不依赖 win32api or mfc，整个游戏
窗口就只有一个 win32 native window，里面所有的东西，都是自己实现了消息的传递、
基本窗体元素(button, combobox...)的绘制。
脚本中写逻辑，类似：
win = ui.uwindow()
win:set_pos(100, 100)
win:set_size(640, 480)
win:set_visible(true)
win:set_transparent(true)
local btn1 = ui.ubutton(win, 10, 200, "normal.png")
btn1:set_active(true)
btn1.on_mouse_leftclick = function (self)
print("up...")
win:set_title("haha")
end
--------- 河蟹的分割线 --------
http://groups.google.com/group/pongba/browse_thread/thread/4a4378960e8418a6/4780291cefb035ab
最后引用一个讨论中某个GG的一段，以供参考：:-)
我主要是做服务器开发的。平台也是Linux为主。
但是，界面库，也用过很多。主要是做工具用的。
包括 Tk, iuplua , wxPython, wxWidgets/C++, Qt, .Net Form
综合各种需求来看：
Qt是最佳选择了。可惜学习曲线比较陡峭。
如果是从MFC过度来的，还是wx好一些。
如果熟python，推荐BOA,这个工具。(基于wxPython)
如果熟lua,推荐iuplua.
如果熟C#,推荐.Net Form.(通过Mono也可在Linux下运行)
Yidong Fang 写道:
> 再交流一个技术问题.
>
> 我最近写了一个win32程序, 用了MFC, 感觉很糟, 有N种字符串: LPTSTR, BSTR,
> CString, LPBYTE (UTF8); 然后是N种数字转换函数: atoi, wtoi, ttoi; 接着是N
> 种时间格式: CTime, SYSTEMTIME,time_t .....然后要自己算好内存需求,
> LocalAlloc或者CString::SysStringAlloc(), 用完要释放, 但是有些给了UI
> component指向之后又不能马上释放, 然后考虑在什么时间地点如何释放比较伤脑
> 筋, 而且增加额外工作量. 有时候考虑自动变量然后用引用吧(通过CString cs,
> 然后传给&参数的方法), 层层传递之后, 如果有一个地方转换为LPTSTR, 打算长久
> 指向, 如果随后那个自动变量出了scope自动销毁, 后果很严重.....如果是复制
> 吧, 一来stack变量的快速优点没了, 二来还是得考虑内存释放问题.....
>
> 另外那些wrapper如CString, _variant_t, _bstr_t不知道他们怎么管理传递给他
> 们的BSTR或者LPTSTR, 该谁来释放....这个可能是知识的问题.....
>
> 但是如果不用MFC, 纯API写工作量就更大了..... 你们用MFC吗？
>
> 呵呵, 发了一通牢骚, 可能是因为用惯了Java, 习惯了这种单纯性 (基本类型和句
> 柄从stack来, 所有对象从heap来), 确定性, 健壮性, 简单性(大量很优美的类,
> 不用考虑include依赖冲突, 不用一个方法名字在头文件和cpp文件各写一次, 不用
> 考虑COM版本兼容/redistribute问题) ..... 感觉VC++编程, 很多时间浪费在业务
> 无关的代码上面了, 也许可以用boost来简化很多东西, 但是模板函数的debug和错
> 误信息跟踪会慢慢变成一个恶梦....
>
> 如果要依靠不断的对象复制来减缓内存管理的压力, 或者不断alloc/free内存,
> 那么Java的机制也许提供更有竞争力的performance.... Java唯一的问题在于它垃
> 圾回收器.....
>
> 最后, 觉得微软的开发环境IDE还是不错的.
>
Yidong Fang
Kasicass
Yidong Fang 写道:
> 是啊，微软后来决定力推C#应该也是觉得原来那一套不好使. 不过用C#觉得有点
> 怪, 心里会一直想: 如果用C#, 为什么不选择Java呢?
Yidong Fang
Jason Sung
http://blog.guykawasaki.com/2009/06/24-hours-at-sea-on-the-uss-nimitz.html