锁定老帖子 主题:策略型网页游戏的服务端计算能力瓶颈
精华帖 (0) :: 良好帖 (7) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2008-12-27
数以万计的玩家,每个玩家手上几十个对象(资源出产,建筑,单位,行动单位,战斗),不管所有这些玩家上线不上线,服务器都必须保持这些数据实时更新正确完整,这是最要命的。 因为这种机制,所有“我行动的时候必须时刻判断是否会改变附近的对方的状态,或者因为附近对方的状态改变我的行动方式”的设计全部都死了,比如说巡逻和视野。甚至地形对行动速度的影响也基本没人做了。游戏平白的减少了无数交互可能性。现在都是采取各种偷懒赖皮的简化方法,比如行军一旦开始那么到达目的地前就无法阻止也无法改变之类。 现在有一个具体的场景,比如说一万个可移动对象(属于不同玩家),在大地图上行动,统统有坐标,每个对象都有战斗半径。那么有没有可能做出一个碰撞算法来,保证每秒钟或者每几秒钟遍历撮合一次,算出所有这一瞬间遭遇而触发战斗呢? 这种性能是不是只能用C做了?JAVA行不行?数据库基本上没可能考虑了?内存数据库呢? 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2008-12-27
瓶颈在数据库上吧
|
|
返回顶楼 | |
发表时间:2008-12-27
游戏向来都是用内存数据库的吧,在存档点保存到文件,直接写库的话你会看到硬盘灯狂闪,webgame就更应该是这样了
|
|
返回顶楼 | |
发表时间:2008-12-27
数据库是成熟的状态管理方案,不用数据库的话,用什么?
1.替代方案尽量要技术成本要低,正因为数据库开发成本低,所以几万块做一个网页游戏才变得可能。 2.替代方案需要支持持久化,服务器停机甚至非正常停机的场合下数据必须能够最大程度的恢复 3.替代方案应该支持并发过程里的锁和事务 4.替代方案最好有实际应用的案例,作为产品开发而言,没有实际案例的技术风险太大了。 |
|
返回顶楼 | |
发表时间:2008-12-27
最后修改:2008-12-27
Julien 写道 对于策略型webgame来说,界面那一块应该没有什么flash都搞不定的高级要求,问题就是在服务器的绝对计算能力上面。
数以万计的玩家,每个玩家手上几十个对象(资源出产,建筑,单位,行动单位,战斗),不管所有这些玩家上线不上线,服务器都必须保持这些数据实时更新正确完整,这是最要命的。 因为这种机制,所有“我行动的时候必须时刻判断是否会改变附近的对方的状态,或者因为附近对方的状态改变我的行动方式”的设计全部都死了,比如说巡逻和视野。甚至地形对行动速度的影响也基本没人做了。游戏平白的减少了无数交互可能性。现在都是采取各种偷懒赖皮的简化方法,比如行军一旦开始那么到达目的地前就无法阻止也无法改变之类。 现在有一个具体的场景,比如说一万个可移动对象(属于不同玩家),在大地图上行动,统统有坐标,每个对象都有战斗半径。那么有没有可能做出一个碰撞算法来,保证每秒钟或者每几秒钟遍历撮合一次,算出所有这一瞬间遭遇而触发战斗呢? 这种性能是不是只能用C做了?JAVA行不行?数据库基本上没可能考虑了?内存数据库呢? P2P来作这种几成万对象的.... 单服务器.....得银河来作.... |
|
返回顶楼 | |
发表时间:2008-12-28
楼主去盛大。。。就知道怎么回事了。。。
|
|
返回顶楼 | |
发表时间:2008-12-28
最后修改:2008-12-28
我得强调普通MMORPG网游没这么大负荷,那点子计算客户端都匀光了
玩家下线就不再处理玩家对象数据,服务端根本吃不到这种计算压力 所以从传统网络游戏里找解决方案就别想了…… |
|
返回顶楼 | |
发表时间:2008-12-28
考虑多了,网页游戏不用实时计算,可以分布的很均匀的进行处理。
|
|
返回顶楼 | |
发表时间:2008-12-28
需要那么多的实时运算?
|
|
返回顶楼 | |
发表时间:2008-12-28
需要多个服务器吧,cluster
还有就是分区,一个区多少个人。 大致均匀的降压。 |
|
返回顶楼 | |