在内部,对The Sims Online(EA,USA)和Second life(LL,USA)类型大家激烈争执不下,感觉他们是不一样的东西,
但是却无法说服对方,想在此求教与您,以解开困绕我们心中的疑惑,不知道能否得到您的无私帮助?
这个问题涉及的东西比较复杂,有软件系统、市场用户、商业策划等多层面的综合因素在内,由于繁忙的工作和有限的个人精力所限制,不可能通过一次讨论就能
将这个复杂的问题说得明白,不管如何,还是让我们抓紧有限的时间,开始不拘形式的尽情探讨吧。
On Jun 9, 7:57 pm, xMan <MESSAGE...@163.COM> wrote:
> > 但是却无法说服对方,想在此求教与您,以解开困绕我们心中的疑惑,不知道能否得到您的无私帮助?- Hide quoted text -
>
> - Show quoted text -
对Second Life虚拟世界有个最简单的判断,不管她怎么宣传自己,这类虚拟世界所谓"游戏性"最多只能进行简单的买地、DIY房子和换装.
如果你在他们的官网上看待包含这些字,就该明白无误地知道他们就是Second Life虚拟世界,而不是真正的MMORPG网络游戏,也不是The
Sims Online 那样的MMOG.
> > - Show quoted text -- Hide quoted text -
如果没有理解错的话,现在市场上的全视角全三维现代生活类MMORPG新网游产品没有出现的原因,就是国内绝大多数网游公司不具备这类产品的架构能力,
而只能在原始的传统产品上做山寨或者换皮产品,根本无法满足现在市场上的这类新MMORPG网游产品的需求?
如果你们要开发这样的MMRPG产品,如果没有这类产品的产品的整体架构能力的人才领导,将会付出很高的风险和成本,这些分析因素仅供参考。
On Jun 15, 2:37 pm, xiliu tang <xiliu.t...@gmail.com> wrote:
> 2009/6/15 lu <mdna...@gmail.com>
做一个MMORPG系统的整体架构,不仅要吸取传统架构的经验,也要善于总结传统架构的缺陷和重大限制,再综合MMORPG整体架构所需要具备的各类庞
杂的海量基础知识,对商业需求与公司总资源进行全面的权衡后,才可作出正确的决策,最大限度为公司减少风险,增加产品研发成功的几率。
On Jun 15, 2:37 pm, xiliu tang <xiliu.t...@gmail.com> wrote:
> 2009/6/15 lu <mdna...@gmail.com>
>
MMORPG网络游戏的特点是服务请求频繁而平均流量较小的明显特点,对服务器系统的实时性要求比较高。
On Jun 15, 5:46 pm, xiliu tang <xiliu.t...@gmail.com> wrote:
> 没有用Windows做过服务器,不过Google上百万台机器都是跑的protobuf rpc services.
>
> 2009/6/15 lu <mdna...@gmail.com>
Unix类开源系统做网络游戏特别是MMORPG网络游戏的服务器,存在综合效率比较低与某些重要功能的扩展上有重大架构缺陷”
在2009-06-15,lu <mdn...@gmail.com> 写道: >Unix类开源系统做网络游戏特别是MMORPG网络游戏的服务器,存在综合效率比较低与某些重要功能的扩展上有重大架构缺陷,对于想要实现xMan这 >类创新型MMORPG产品的架构确实不是最合适的选择。 > >做一个MMORPG系统的整体架构,不仅要吸取传统架构的经验,也要善于总结传统架构的缺陷和重大限制,再综合MMORPG整体架构所需要具备的各类庞 >杂的海量基础知识,对商业需求与公司总资源进行全面的权衡后,才可作出正确的决策,最大限度为公司减少风险,增加产品研发成功的几率。 >
在开始之前,想听听您认为MMORPG网络游戏的服务器的特点是什么,与其他功能的服务器相比有什么不同。
另外,假设我们要设计一个创新型的MMORPG网游,它是现代时尚生活的真实映射,在反映真实生活游戏场景的同时要大量内置商业广告,要求吸引最多的玩
家来共同参与。现存的知名的MMORPG网游架构对这个系统要求的实现有什么值得借鉴和通过已经表现出的系统缺陷而必须要做出突破性改造的地方。
On Jun 15, 11:58 pm, sjinny <sji...@163.com> wrote:
> "
> Unix类开源系统做网络游戏特别是MMORPG网络游戏的服务器,存在综合效率比较低与某些重要功能的扩展上有重大架构缺陷
> "
> 能不能具体说说这些缺陷是什么?
>
> 在2009-06-15,lu <mdna...@gmail.com> 写道:
>
>
>
> >Unix类开源系统做网络游戏特别是MMORPG网络游戏的服务器,存在综合效率比较低与某些重要功能的扩展上有重大架构缺陷,对于想要实现xMan这
> >类创新型MMORPG产品的架构确实不是最合适的选择。
>
> >做一个MMORPG系统的整体架构,不仅要吸取传统架构的经验,也要善于总结传统架构的缺陷和重大限制,再综合MMORPG整体架构所需要具备的各类庞
> >杂的海量基础知识,对商业需求与公司总资源进行全面的权衡后,才可作出正确的决策,最大限度为公司减少风险,增加产品研发成功的几率。- Hide quoted text -
您认为mmorpg主要是两个层面,一个是底层通信,一个是上层的逻辑划分这两点来看,还缺乏MMORPG整体架构的完整认识,特别是缺乏贯穿
MMORPG整体的"数字神经"的构建,其中在对各种级别的系统同步的具体系统设计的实现方式上的不同,是Unix类开源系统在MMORPG工程实现中
所存在的最大弊端。
不知道您对MMORPG整体的"数字神经"及MMORPG系统同步有一个什么样的概念,您对《一个高性能MMORPG网络游戏的架构实例》里所说的
Mutual synchronization(相互同步)是否有过实践经验?
目前中国山寨换皮的最大问题就是,根本无须了解MMORPG系统的基础原理,只需要照猫画虎也许可以通过资源的更换快速得到"新MMORPG产品",但
是相关技术人员却无法理解最基础的MMORPG的相关基本原理,所以根本无法具备创新架构的能力,只能让同质化的产品大量泛滥,随着进入者迅速膨胀和市
场利润的快速枯竭,最终还是会危及到这些技术人员的生存。
On Jun 16, 12:13 pm, sjinny <sji...@163.com> wrote:
> 不知道这里的"其他服务器"是什么样的概念,所以就不说不同之类的了。在我的认识中,mmorpg主要是两个层面,一个是底层通信,一个是上层的逻辑划分。底层-基于epoll、iocp之类的已经没有多大的技术难度了,毕竟asio都正式进了boost了......我现在主要是上层的模块划分还找不到好的方法,无论是进程层-面的划分还是进程内部模块的划分......
>
> 现在只要能把山口山山寨到位了,那么里面是放科幻还是奇幻还是现代题材对程序来说都没多大本质区别,只是模型动画、场景资源、机能设定这些的不同。
>
> 我现在比较倾向于多进程单线程的架构,进程根据逻辑功能来划分,尽量不按场景划分,绝对不按session划分,然后通过网关作为整体对客户端提供服务。这些主-要是受到云风blog的影响以及《UNIX编程艺术》这本书的影响。我自己做了个开源的网络层(http://sourceforge.net/projects/netgate),现在还在摸索多进程程序设计的基本方法。
>
> 在2009-06-16,lu <mdna...@gmail.com> 写道:
>
>
>
> >非常高兴能与您探讨这个问题。
>
> >在开始之前,想听听您认为MMORPG网络游戏的服务器的特点是什么,与其他功能的服务器相比有什么不同。
>
> >另外,假设我们要设计一个创新型的MMORPG网游,它是现代时尚生活的真实映射,在反映真实生活游戏场景的同时要大量内置商业广告,要求吸引最多的玩
> >家来共同参与。现存的知名的MMORPG网游架构对这个系统要求的实现有什么值得借鉴和通过已经表现出的系统缺陷而必须要做出突破性改造的地方。
>
> >On Jun 15, 11:58 pm, sjinny <sji...@163.com> wrote:
> >> "
> >> Unix类开源系统做网络游戏特别是MMORPG网络游戏的服务器,存在综合效率比较低与某些重要功能的扩展上有重大架构缺陷
> >> "
> >> 能不能具体说说这些缺陷是什么?
>
> >> 在2009-06-15,lu <mdna...@gmail.com> 写道:
>
> >> >Unix类开源系统做网络游戏特别是MMORPG网络游戏的服务器,存在综合效率比较低与某些重要功能的扩展上有重大架构缺陷,对于想要实现xMan这
> >> >类创新型MMORPG产品的架构确实不是最合适的选择。
>
> >> >做一个MMORPG系统的整体架构,不仅要吸取传统架构的经验,也要善于总结传统架构的缺陷和重大限制,再综合MMORPG整体架构所需要具备的各类庞
> >> >杂的海量基础知识,对商业需求与公司总资源进行全面的权衡后,才可作出正确的决策,最大限度为公司减少风险,增加产品研发成功的几率。- Hide quoted text -
>
> >> - Show quoted text -- Hide quoted text -
On 6月16日, 下午9时52分, lu <mdna...@gmail.com> wrote:
> 就让我们从您对MMORPG整体架构的认识开始讨论起吧。
>
> 您认为mmorpg主要是两个层面,一个是底层通信,一个是上层的逻辑划分这两点来看,还缺乏MMORPG整体架构的完整认识,特别是缺乏贯穿
> MMORPG整体的"数字神经"的构建,其中在对各种级别的系统同步的具体系统设计的实现方式上的不同,是Unix类开源系统在MMORPG工程实现中
> 所存在的最大弊端。
>
> 不知道您对MMORPG整体的"数字神经"及MMORPG系统同步有一个什么样的概念,您对《一个高性能MMORPG网络游戏的架构实例》里所说的
> Mutual synchronization(相互同步)是否有过实践经验?
>
> 目前中国山寨换皮的最大问题就是,根本无须了解MMORPG系统的基础原理,只需要照猫画虎也许可以通过资源的更换快速得到"新MMORPG产品",但
> 是相关技术人员却无法理解最基础的MMORPG的相关基本原理,所以根本无法具备创新架构的能力,只能让同质化的产品大量泛滥,随着进入者迅速膨胀和市
> 场利润的快速枯竭,最终还是会危及到这些技术人员的生存。
>
> On Jun 16, 12:13 pm, sjinny <sji...@163.com> wrote:
>
>
>
> > 不知道这里的"其他服务器"是什么样的概念,所以就不说不同之类的了。在我的认识中,mmorpg主要是两个层面,一个是底层通信,一个是上层的逻辑划分。底层 -基于epoll、iocp之类的已经没有多大的技术难度了,毕竟asio都正式进了boost了......我现在主要是上层的模块划分还找不到好的方法,无 论是进程层-面的划分还是进程内部模块的划分......
>
> > 现在只要能把山口山山寨到位了,那么里面是放科幻还是奇幻还是现代题材对程序来说都没多大本质区别,只是模型动画、场景资源、机能设定这些的不同。
>
> > 我现在比较倾向于多进程单线程的架构,进程根据逻辑功能来划分,尽量不按场景划分,绝对不按session划分,然后通过网关作为整体对客户端提供服务。这些主 -要是受到云风blog的影响以及《UNIX编程艺术》这本书的影响。我自己做了个开源的网络层(http://sourceforge.net/projects/netgate),现在还在摸索多进程程序设计的基本方法。
举个简单的例子,你肯定经历过使用手机在跨省或市火车旅行的时候,每当你一进入到一个城市的时候,就会接受到来自这个城市的移动或者网通的运营服务商发
来的欢迎信息.而这个移动通讯的系统就是MMORPG里采用的典型系统同步模式,当然在具体的实现上比中国移动的这套系统要复杂很多,你肯定没有想到
MMORPG系统会使用到如此高级的系统设计吧,呵呵.
On Jun 17, 12:11 am, sjinny <sji...@163.com> wrote:
> 呃......
> "其中在对各种级别的系统同步的具体系统设计的实现方式上的不同,是Unix类开源系统在MMORPG工程实现中所存在的最大弊端。"
> 这句看不明白......能不能举个例子......
>
> 那个相互同步是基于P2P的吧,貌似这个对MMORPG不太可行,因为可能有安全性问题,包括玩家篡改数据,以及把玩家的IP暴露出去后使玩家机器被攻击。我只-是用blender做过一个运动同步算法的模拟,主要做法就是服务器以一定频率把对象的速度、位置发送给客户端,并且打上时间戳,接着客户端会在收到消息时根据-时间戳预测客户端收到时这个对象在服务器端已经运动到哪了,这里是把对象当作匀速直线运动来预测,接着客户端计算出一个加速度来让客户端对象的对应对象逼近服务-器端对象的状态(包括位置和速度)。后来发现最关键的问题是,如果不预测,那么客户端看到的对象状态总是比服务器端对象的状态滞后一些,如果预测,那么对象总归-会因为玩家控制等因素发生运动状态的改变,并且总归会有某些改变是其他客户端预测之外的,这时又会产生不同步。后来查了一下,发现其实这是个典型的埃尔米特插值-问题,就是让客户端的对象在短时间内平滑地过渡到服务器端对象的状态上,并且要使速度也能够平滑过渡,但是埃尔米特插值算起来太麻烦,后来就懒得继续做了。
>
> 在2009-06-16,lu <mdna...@gmail.com> 写道:
>
>
>
> >就让我们从您对MMORPG整体架构的认识开始讨论起吧。
>
> >您认为mmorpg主要是两个层面,一个是底层通信,一个是上层的逻辑划分这两点来看,还缺乏MMORPG整体架构的完整认识,特别是缺乏贯穿
> >MMORPG整体的"数字神经"的构建,其中在对各种级别的系统同步的具体系统设计的实现方式上的不同,是Unix类开源系统在MMORPG工程实现中
> >所存在的最大弊端。
>
> >不知道您对MMORPG整体的"数字神经"及MMORPG系统同步有一个什么样的概念,您对《一个高性能MMORPG网络游戏的架构实例》里所说的
> >Mutual synchronization(相互同步)是否有过实践经验?
>
> >目前中国山寨换皮的最大问题就是,根本无须了解MMORPG系统的基础原理,只需要照猫画虎也许可以通过资源的更换快速得到"新MMORPG产品",但
> >是相关技术人员却无法理解最基础的MMORPG的相关基本原理,所以根本无法具备创新架构的能力,只能让同质化的产品大量泛滥,随着进入者迅速膨胀和市
> >场利润的快速枯竭,最终还是会危及到这些技术人员的生存。
>
> >On Jun 16, 12:13 pm, sjinny <sji...@163.com> wrote:
> >> 不知道这里的"其他服务器"是什么样的概念,所以就不说不同之类的了。在我的认识中,mmorpg主要是两个层面,一个是底层通信,一个是上层的逻辑划分。底层--基于epoll、iocp之类的已经没有多大的技术难度了,毕竟asio都正式进了boost了......我现在主要是上层的模块划分还找不到好的方法,无-论是进程层-面的划分还是进程内部模块的划分......
>
> >> 现在只要能把山口山山寨到位了,那么里面是放科幻还是奇幻还是现代题材对程序来说都没多大本质区别,只是模型动画、场景资源、机能设定这些的不同。
>
> >> 我现在比较倾向于多进程单线程的架构,进程根据逻辑功能来划分,尽量不按场景划分,绝对不按session划分,然后通过网关作为整体对客户端提供服务。这些主--要是受到云风blog的影响以及《UNIX编程艺术》这本书的影响。我自己做了个开源的网络层(http://sourceforge.net/projects/netgate),现在还在摸索多进程程序设计的基本方法。
一般这种方法会在MMORPFG极其核心的部分被采用,以满足系统对资源调度的极高效率的特殊要求,尽管实现难度确实极高,但是现在优秀的MMORPG
系统已经在实际产品中被应用,效果良好,最为大家所熟悉的就是EVE Online,它创造了同一游戏世界里可同时容纳数十万人的世界记录,这是任何类
UNIX MOORPG系统远远未能达到的水平,不过这种技术特点对于我前面提到的现代时尚生活的MMORPG产品是十分适合的选择,对于其他类型的
MMORPG产品这点也许没有这样的重要.
所以,从这些点滴就可以看出,对一个合格的MMORPG总架构师的要求该是多么地变态,呵呵.
On Jun 17, 12:15 am, sjinny <sji...@163.com> wrote:
> 其实个人不太喜欢多线程,因为要把多线程做对很难,要在做对的同时还要封装好,让使用者不需要知道这是多线程的、随便怎么用都不会出问题那就更难了(其实我觉得-这不太可能实现)。一但不能把多线程的相关概念封装好,那么可能会使多线程概念在使用了这个模块的项目里扩散得到处都是,结果就是可能很多地方都不得不去关心加-锁解锁、避免死锁......
On Jun 17, 6:44 am, lu <mdna...@gmail.com> wrote:
> 其实在我前面的文章里专门讲述了这个问题,P2P是典型的去中心化网络服务器的方案,与要求集中统一控制的MMORPG来说,是完全背道而驰的,自然
> MMORPG里的各种级别的系统同步就不会与它有什么关系,你说的方法,我见过很多种,都是实验性质的,最后都没能实际使用到任何一款MMORPG产品
> 里来.
>
> 举个简单的例子,你肯定经历过使用手机在跨省或市火车旅行的时候,每当你一进入到一个城市的时候,就会接受到来自这个城市的移动或者网通的运营服务商发
> 来的欢迎信息.而这个移动通讯的系统就是MMORPG里采用的典型系统同步模式,当然在具体的实现上比中国移动的这套系统要复杂很多,你肯定没有想到
> MMORPG系统会使用到如此高级的系统设计吧,呵呵.
>
> On Jun 17, 12:11 am, sjinny <sji...@163.com> wrote:
>
>
>
> > 呃......
> > "其中在对各种级别的系统同步的具体系统设计的实现方式上的不同,是Unix类开源系统在MMORPG工程实现中所存在的最大弊端。"
> > 这句看不明白......能不能举个例子......
>
> > 那个相互同步是基于P2P的吧,貌似这个对MMORPG不太可行,因为可能有安全性问题,包括玩家篡改数据,以及把玩家的IP暴露出去后使玩家机器被攻击。我只--是用blender做过一个运动同步算法的模拟,主要做法就是服务器以一定频率把对象的速度、位置发送给客户端,并且打上时间戳,接着客户端会在收到消息时根-据-时间戳预测客户端收到时这个对象在服务器端已经运动到哪了,这里是把对象当作匀速直线运动来预测,接着客户端计算出一个加速度来让客户端对象的对应对象逼近-服务-器端对象的状态(包括位置和速度)。后来发现最关键的问题是,如果不预测,那么客户端看到的对象状态总是比服务器端对象的状态滞后一些,如果预测,那么对-象总归-会因为玩家控制等因素发生运动状态的改变,并且总归会有某些改变是其他客户端预测之外的,这时又会产生不同步。后来查了一下,发现其实这是个典型的埃尔-米特插值-问题,就是让客户端的对象在短时间内平滑地过渡到服务器端对象的状态上,并且要使速度也能够平滑过渡,但是埃尔米特插值算起来太麻烦,后来就懒得继续-做了。
>
> > 在2009-06-16,lu <mdna...@gmail.com> 写道:
>
> > >就让我们从您对MMORPG整体架构的认识开始讨论起吧。
>
> > >您认为mmorpg主要是两个层面,一个是底层通信,一个是上层的逻辑划分这两点来看,还缺乏MMORPG整体架构的完整认识,特别是缺乏贯穿
> > >MMORPG整体的"数字神经"的构建,其中在对各种级别的系统同步的具体系统设计的实现方式上的不同,是Unix类开源系统在MMORPG工程实现中
> > >所存在的最大弊端。
>
> > >不知道您对MMORPG整体的"数字神经"及MMORPG系统同步有一个什么样的概念,您对《一个高性能MMORPG网络游戏的架构实例》里所说的
> > >Mutual synchronization(相互同步)是否有过实践经验?
>
> > >目前中国山寨换皮的最大问题就是,根本无须了解MMORPG系统的基础原理,只需要照猫画虎也许可以通过资源的更换快速得到"新MMORPG产品",但
> > >是相关技术人员却无法理解最基础的MMORPG的相关基本原理,所以根本无法具备创新架构的能力,只能让同质化的产品大量泛滥,随着进入者迅速膨胀和市
> > >场利润的快速枯竭,最终还是会危及到这些技术人员的生存。
>
> > >On Jun 16, 12:13 pm, sjinny <sji...@163.com> wrote:
> > >> 不知道这里的"其他服务器"是什么样的概念,所以就不说不同之类的了。在我的认识中,mmorpg主要是两个层面,一个是底层通信,一个是上层的逻辑划分。底层---基于epoll、iocp之类的已经没有多大的技术难度了,毕竟asio都正式进了boost了......我现在主要是上层的模块划分还找不到好的方法,-无-论是进程层-面的划分还是进程内部模块的划分......
>
> > >> 现在只要能把山口山山寨到位了,那么里面是放科幻还是奇幻还是现代题材对程序来说都没多大本质区别,只是模型动画、场景资源、机能设定这些的不同。
>
> > >> 我现在比较倾向于多进程单线程的架构,进程根据逻辑功能来划分,尽量不按场景划分,绝对不按session划分,然后通过网关作为整体对客户端提供服务。这些主---要是受到云风blog的影响以及《UNIX编程艺术》这本书的影响。我自己做了个开源的网络层(http://sourceforge.net/projects/netgate),现在还在摸索多进程程序设计的基本方法。
至于"用户之间有一些交互性,每天200W+的登录用户在同一个世界游戏"这种仅限于"登录"状态的简单游戏效果,确实与EVE Onlie 类的真正
让用户在一个世界实时交互和全方位进行各项深度娱乐操作的MMORPG效果有着很明显的区别。
要知道,中国移动早就实现了每天有2亿+的人登录用户在同一个世界玩语音+互动"游戏",可比你说的200W+的游戏要领先很多年了。
On Jun 17, 2:47 pm, Lei Gu <jackf...@gmail.com> wrote:
> EVE构架的硬件成本很贵(国内支持同样在线人数的10倍到100倍),如果同样的构架,同样的硬件,国内的游戏可能就没有利润了还是征途的体系结构更具有参考-性
> 另外,国内诸如开新农场之类的应用,其实也是有些参考性的
> 用户之间有一些交互性,每天200W+的登录用户在同一个世界游戏,跟一般的MMORPG还是有些区别的
>
> 2009/6/17 xMan <MESSAGE...@163.com>
在MMORPG里,甲用户、乙用户、丙用户先后顺序登录了网络游戏的相同场景,在同步系统实现的第一步,乙用户能不能看见丙用户?甲用户能看见谁?丙用
户又能看见谁?
另外,甲用户、乙用户、丙用户怎么才能相互看见彼此都在一个场景里?
如果你能正确回答以上问题,那么恭喜你,中国移动的"蜂窝"概念看来你确实是了解一点滴。
开源的实验性质的所谓"游戏架构"直接google就是一大把,这里就不要浪费网络资源了吧,呵呵。
On Jun 17, 2:49 pm, sjinny <sji...@163.com> wrote:
> 蜂窝我又不是不知道,只不过......貌似这不算很高级的系统设计吧......按地图划分服务器进程貌似是很常见的做法......
> "你说的方法,我见过很多种,都是实验性质的,最后都没能实际使用到任何一款MMORPG产品里来."
> 能不能说说具体有哪几种呢?
>
> 在2009-06-17,lu <mdna...@gmail.com> 写道:
>
>
>
> >其实在我前面的文章里专门讲述了这个问题,P2P是典型的去中心化网络服务器的方案,与要求集中统一控制的MMORPG来说,是完全背道而驰的,自然
> >MMORPG里的各种级别的系统同步就不会与它有什么关系,你说的方法,我见过很多种,都是实验性质的,最后都没能实际使用到任何一款MMORPG产品
> >里来.
>
> >举个简单的例子,你肯定经历过使用手机在跨省或市火车旅行的时候,每当你一进入到一个城市的时候,就会接受到来自这个城市的移动或者网通的运营服务商发
> >来的欢迎信息.而这个移动通讯的系统就是MMORPG里采用的典型系统同步模式,当然在具体的实现上比中国移动的这套系统要复杂很多,你肯定没有想到
> >MMORPG系统会使用到如此高级的系统设计吧,呵呵.
>
> >On Jun 17, 12:11 am, sjinny <sji...@163.com> wrote:
> >> 呃......
> >> "其中在对各种级别的系统同步的具体系统设计的实现方式上的不同,是Unix类开源系统在MMORPG工程实现中所存在的最大弊端。"
> >> 这句看不明白......能不能举个例子......
>
> >> 那个相互同步是基于P2P的吧,貌似这个对MMORPG不太可行,因为可能有安全性问题,包括玩家篡改数据,以及把玩家的IP暴露出去后使玩家机器被攻击。我只--是用blender做过一个运动同步算法的模拟,主要做法就是服务器以一定频率把对象的速度、位置发送给客户端,并且打上时间戳,接着客户端会在收到消息时根-据-时间戳预测客户端收到时这个对象在服务器端已经运动到哪了,这里是把对象当作匀速直线运动来预测,接着客户端计算出一个加速度来让客户端对象的对应对象逼近-服务-器端对象的状态(包括位置和速度)。后来发现最关键的问题是,如果不预测,那么客户端看到的对象状态总是比服务器端对象的状态滞后一些,如果预测,那么对-象总归-会因为玩家控制等因素发生运动状态的改变,并且总归会有某些改变是其他客户端预测之外的,这时又会产生不同步。后来查了一下,发现其实这是个典型的埃尔-米特插值-问题,就是让客户端的对象在短时间内平滑地过渡到服务器端对象的状态上,并且要使速度也能够平滑过渡,但是埃尔米特插值算起来太麻烦,后来就懒得继续-做了。
>
> >> 在2009-06-16,lu <mdna...@gmail.com> 写道:
>
> >> >就让我们从您对MMORPG整体架构的认识开始讨论起吧。
>
> >> >您认为mmorpg主要是两个层面,一个是底层通信,一个是上层的逻辑划分这两点来看,还缺乏MMORPG整体架构的完整认识,特别是缺乏贯穿
> >> >MMORPG整体的"数字神经"的构建,其中在对各种级别的系统同步的具体系统设计的实现方式上的不同,是Unix类开源系统在MMORPG工程实现中
> >> >所存在的最大弊端。
>
> >> >不知道您对MMORPG整体的"数字神经"及MMORPG系统同步有一个什么样的概念,您对《一个高性能MMORPG网络游戏的架构实例》里所说的
> >> >Mutual synchronization(相互同步)是否有过实践经验?
>
> >> >目前中国山寨换皮的最大问题就是,根本无须了解MMORPG系统的基础原理,只需要照猫画虎也许可以通过资源的更换快速得到"新MMORPG产品",但
> >> >是相关技术人员却无法理解最基础的MMORPG的相关基本原理,所以根本无法具备创新架构的能力,只能让同质化的产品大量泛滥,随着进入者迅速膨胀和市
> >> >场利润的快速枯竭,最终还是会危及到这些技术人员的生存。
>
> >> >On Jun 16, 12:13 pm, sjinny <sji...@163.com> wrote:
> >> >> 不知道这里的"其他服务器"是什么样的概念,所以就不说不同之类的了。在我的认识中,mmorpg主要是两个层面,一个是底层通信,一个是上层的逻辑划分。底层---基于epoll、iocp之类的已经没有多大的技术难度了,毕竟asio都正式进了boost了......我现在主要是上层的模块划分还找不到好的方法,-无-论是进程层-面的划分还是进程内部模块的划分......
>
> >> >> 现在只要能把山口山山寨到位了,那么里面是放科幻还是奇幻还是现代题材对程序来说都没多大本质区别,只是模型动画、场景资源、机能设定这些的不同。
>
> >> >> 我现在比较倾向于多进程单线程的架构,进程根据逻辑功能来划分,尽量不按场景划分,绝对不按session划分,然后通过网关作为整体对客户端提供服务。这些主---要是受到云风blog的影响以及《UNIX编程艺术》这本书的影响。我自己做了个开源的网络层(http://sourceforge.net/projects/netgate),现在还在摸索多进程程序设计的基本方法。
类UNIX MOORPG系统是业界内一种约定俗成的用法,很抱歉不能给你准确的定义。
On Jun 17, 2:51 pm, sjinny <sji...@163.com> wrote:
> 其实,多线程的缺点就在于复杂度太高以及健壮性不好,而这对于系统的核心部分恰恰是最致命的缺点。
> eve我没玩过,但是以前听说国服里打个大会战就容易卡死,不知道是否真的确有其事......
> "类UNIX MOORPG系统"是什么东西?你能给个定义吗?
>
> 在2009-06-17,lu <mdna...@gmail.com> 写道:
>
>
>
> >其实多线程在控制上是需要很高的技能来保证他的稳定性和维持它的功能,想要设计这样一套系统确实是件精细活,一般人很难有机会得到接触这样精细而复杂系
> >统的机会.
>
> >一般这种方法会在MMORPFG极其核心的部分被采用,以满足系统对资源调度的极高效率的特殊要求,尽管实现难度确实极高,但是现在优秀的MMORPG
> >系统已经在实际产品中被应用,效果良好,最为大家所熟悉的就是EVE Online,它创造了同一游戏世界里可同时容纳数十万人的世界记录,这是任何类
> >UNIX MOORPG系统远远未能达到的水平,不过这种技术特点对于我前面提到的现代时尚生活的MMORPG产品是十分适合的选择,对于其他类型的
> >MMORPG产品这点也许没有这样的重要.
>
> >所以,从这些点滴就可以看出,对一个合格的MMORPG总架构师的要求该是多么地变态,呵呵.
>
> >On Jun 17, 12:15 am, sjinny <sji...@163.com> wrote:
> >> 其实个人不太喜欢多线程,因为要把多线程做对很难,要在做对的同时还要封装好,让使用者不需要知道这是多线程的、随便怎么用都不会出问题那就更难了(其实我觉得--这不太可能实现)。一但不能把多线程的相关概念封装好,那么可能会使多线程概念在使用了这个模块的项目里扩散得到处都是,结果就是可能很多地方都不得不去关心-加-锁解锁、避免死锁......
这样吧,为了不乱,还是请你先回答一下我上面提出的问题吧。如果你确实不知道,只需要直说就可以了。反正这里都是是学术讨论,没有什么的,呵呵。
至于说道MMORPG的系统同步,我请教你一个基础的问题:
在MMORPG里,甲用户、乙用户、丙用户先后顺序登录了网络游戏的相同场景,在同步系统实现的第一步,乙用户能不能看见丙用户?甲用户能看见谁?丙
用
户又能看见谁?
另外,甲用户、乙用户、丙用户怎么才能相互看见彼此都在一个场景里?
On Jun 17, 6:19 pm, sjinny <sji...@163.com> wrote:
> 手机大多是1对1的交互,网游里会有很多广播,所以同样的用户数量产生的压力是不同的。而且电话对延迟不太敏感,网游对延迟是很敏感的。
>
> 在2009-06-17,lu <mdna...@gmail.com> 写道:
>
>
>
> >在3年前也许还能说硬件的成本是个主要考虑的问题,现在根本不成一个主要问题。而且现在的新MMORPG架构普遍在吸取EVE Online的精华的同
> >时,平衡了其他各种因素,取得了较好的综合效益。
>
> >至于"用户之间有一些交互性,每天200W+的登录用户在同一个世界游戏"这种仅限于"登录"状态的简单游戏效果,确实与EVE Onlie 类的真正
> >让用户在一个世界实时交互和全方位进行各项深度娱乐操作的MMORPG效果有着很明显的区别。
>
> >要知道,中国移动早就实现了每天有2亿+的人登录用户在同一个世界玩语音+互动"游戏",可比你说的200W+的游戏要领先很多年了。
>
> >On Jun 17, 2:47 pm, Lei Gu <jackf...@gmail.com> wrote:
> >> EVE构架的硬件成本很贵(国内支持同样在线人数的10倍到100倍),如果同样的构架,同样的硬件,国内的游戏可能就没有利润了还是征途的体系结构更具有参考--性
你自己想象的"典型的AOI问题,最简单的做法就是打格子,高级一点点的就是四叉树,松散四叉树对运动物体"这些个方法,仅仅是你在客户端
Pathing的时候能派上用场。根本没有任何一款商业MMORPG网游里采用你所设想的这种所谓的"同步"方式。
要参加讨论,应该具备基本正确的基础知识才好展开,否则是浪费双方时间.
On Jun 17, 6:24 pm, sjinny <sji...@163.com> wrote:
> 唉......你是在这做考官吗?你是来考别人的还是来这交流的?
> 你说的就是典型的AOI问题,最简单的做法就是打格子,高级一点点的就是四叉树,松散四叉树对运动物体的适应性更好点。
> 我说你除了提问之外能不能说点具体的,比如
> "你说的方法,我见过很多种,都是实验性质的,最后都没能实际使用到任何一款MMORPG产品里来."
> 还有
> "类UNIX MOORPG系统"
> 这些你都只是提出了个概念或者结论,然后没具体内容......
> 既然开了邮件列表,就该有交流的诚意,不具体讨论可就是没诚意了......
>
> 即使是约定俗成,那么也有个大致的说明吧,比如典型例子是怎样的,典型特征是怎样的,不属于这个概念的东西的典型特征是怎样的
>
> 在2009-06-17,lu <mdna...@gmail.com> 写道:
>
>
>
> >EVE 没有玩过就不用讨论了,等你玩过了咱们再来讨论不迟。
>
> >类UNIX MOORPG系统是业界内一种约定俗成的用法,很抱歉不能给你准确的定义。
>
> >On Jun 17, 2:51 pm, sjinny <sji...@163.com> wrote:
> >> 其实,多线程的缺点就在于复杂度太高以及健壮性不好,而这对于系统的核心部分恰恰是最致命的缺点。
> >> eve我没玩过,但是以前听说国服里打个大会战就容易卡死,不知道是否真的确有其事......
> >> "类UNIX MOORPG系统"是什么东西?你能给个定义吗?
>
> >> 在2009-06-17,lu <mdna...@gmail.com> 写道:
>
> >> >其实多线程在控制上是需要很高的技能来保证他的稳定性和维持它的功能,想要设计这样一套系统确实是件精细活,一般人很难有机会得到接触这样精细而复杂系
> >> >统的机会.
>
> >> >一般这种方法会在MMORPFG极其核心的部分被采用,以满足系统对资源调度的极高效率的特殊要求,尽管实现难度确实极高,但是现在优秀的MMORPG
> >> >系统已经在实际产品中被应用,效果良好,最为大家所熟悉的就是EVE Online,它创造了同一游戏世界里可同时容纳数十万人的世界记录,这是任何类
> >> >UNIX MOORPG系统远远未能达到的水平,不过这种技术特点对于我前面提到的现代时尚生活的MMORPG产品是十分适合的选择,对于其他类型的
> >> >MMORPG产品这点也许没有这样的重要.
>
> >> >所以,从这些点滴就可以看出,对一个合格的MMORPG总架构师的要求该是多么地变态,呵呵.
>
> >> >On Jun 17, 12:15 am, sjinny <sji...@163.com> wrote:
> >> >> 其实个人不太喜欢多线程,因为要把多线程做对很难,要在做对的同时还要封装好,让使用者不需要知道这是多线程的、随便怎么用都不会出问题那就更难了(其实我觉得---这不太可能实现)。一但不能把多线程的相关概念封装好,那么可能会使多线程概念在使用了这个模块的项目里扩散得到处都是,结果就是可能很多地方都不得不去关-心-加-锁解锁、避免死锁......
以前WOW在世界上的著名宕机案件也引起了我们的注意,所以在对性MMORPG系统进行选型的时候,特别注意了要规避的以前MMORPG系统架构上所发
生的典型设计错误。
On Jun 17, 6:35 am, lu <mdna...@gmail.com> wrote:
> kennywong兄说的这个问题确实是影响整体效率的一个因素之一.
>
> On Jun 16, 10:28 pm, kennywong <huangweil...@21cn.com> wrote:
>
>
>
在2009-06-17,lu 写道: >其实多线程在控制上是需要很高的技能来保证他的稳定性和维持它的功能,想要设计这样一套系统确实是件精细活,一般人很难有机会得到接触这样精细而复杂系 >统的机会. > >一般这种方法会在MMORPFG极其核心的部分被采用,以满足系统对资源调度的极高效率的特殊要求,尽管实现难度确实极高,但是现在优秀的MMORPG >系统已经在实际产品中被应用,效果良好,最为大家所熟悉的就是EVE Online,它创造了同一游戏世界里可同时容纳数十万人的世界记录,这是任何类 >UNIX MOORPG系统远远未能达到的水平,不过这种技术特点对于我前面提到的现代时尚生活的MMORPG产品是十分适合的选择,对于其他类型的 >MMORPG产品这点也许没有这样的重要. > >所以,从这些点滴就可以看出,对一个合格的MMORPG总架构师的要求该是多么地变态,呵呵. > >On Jun 17, 12:15 am, sjinny wrote: >> 其实个人不太喜欢多线程,因为要把多线程做对很难,要在做对的同时还要封装好,让使用者不需要知道这是多线程的、随便怎么用都不会出问题那就更难了(其实我觉得-这不太可能实现)。一但不能把多线程的相关概念封装好,那么可能会使多线程概念在使用了这个模块的项目里扩散得到处都是,结果就是可能很多地方都不得不去关心加-锁解锁、避免死锁...... >> >> 在2009-06-16,kennywong 写道: >> >> >> >> >恩,对Freebsd不熟悉,就针对linux吧 .记得曾经看过一个测试,windows critical section跟linux >> >mutex的性能对比.后者比前者性能相差很大. >> >究其原因,critical section是一个用户空间的同步原语,而mutex会切入到核态.但那个测试是基于2.4内核的.而2.6以后的内核 >> >引入了新的 >> >同步机制futex.只有很少的情况下才需要切入到核态.大多时候都是在用户态实现同步.所以即使与critical secton存在性能上的差距, >> >也 >> >肯定比2.6以前的mutex好了很多.那篇文章上还有测试代码,我等会实测一下. >> >> >On 6月16日, 下午9时52分, lu wrote: >> >> 就让我们从您对MMORPG整体架构的认识开始讨论起吧。 >> >> >> 您认为mmorpg主要是两个层面,一个是底层通信,一个是上层的逻辑划分这两点来看,还缺乏MMORPG整体架构的完整认识,特别是缺乏贯穿 >> >> MMORPG整体的"数字神经"的构建,其中在对各种级别的系统同步的具体系统设计的实现方式上的不同,是Unix类开源系统在MMORPG工程实现中 >> >> 所存在的最大弊端。 >> >> >> 不知道您对MMORPG整体的"数字神经"及MMORPG系统同步有一个什么样的概念,您对《一个高性能MMORPG网络游戏的架构实例》里所说的 >> >> Mutual synchronization(相互同步)是否有过实践经验? >> >> >> 目前中国山寨换皮的最大问题就是,根本无须了解MMORPG系统的基础原理,只需要照猫画虎也许可以通过资源的更换快速得到"新MMORPG产品",但 >> >> 是相关技术人员却无法理解最基础的MMORPG的相关基本原理,所以根本无法具备创新架构的能力,只能让同质化的产品大量泛滥,随着进入者迅速膨胀和市 >> >> 场利润的快速枯竭,最终还是会危及到这些技术人员的生存。 >> >> >> On Jun 16, 12:13 pm, sjinny wrote: >> >> >> > 不知道这里的"其他服务器"是什么样的概念,所以就不说不同之类的了。在我的认识中,mmorpg主要是两个层面,一个是底层通信,一个是上层的逻辑划分。底层 -基于epoll、iocp之类的已经没有多大的技术难度了,毕竟asio都正式进了boost了......我现在主要是上层的模块划分还找不到好的方法,无 论是进程层-面的划分还是进程内部模块的划分...... >> >> >> > 现在只要能把山口山山寨到位了,那么里面是放科幻还是奇幻还是现代题材对程序来说都没多大本质区别,只是模型动画、场景资源、机能设定这些的不同。 >> >> >> > 我现在比较倾向于多进程单线程的架构,进程根据逻辑功能来划分,尽量不按场景划分,绝对不按session划分,然后通过网关作为整体对客户端提供服务。这些主 -要是受到云风blog的影响以及《UNIX编程艺术》这本书的影响。我自己做了个开源的网络层(http://sourceforge.net/projects/netgate),现在还在摸索多进程程序设计的基本方法。 >> >> >> > 在2009-06-16,lu 写道: >> >> >> > >非常高兴能与您探讨这个问题。 >> >> >> > >在开始之前,想听听您认为MMORPG网络游戏的服务器的特点是什么,与其他功能的服务器相比有什么不同。 >> >> >> > >另外,假设我们要设计一个创新型的MMORPG网游,它是现代时尚生活的真实映射,在反映真实生活游戏场景的同时要大量内置商业广告,要求吸引最多的玩 >> >> > >家来共同参与。现存的知名的MMORPG网游架构对这个系统要求的实现有什么值得借鉴和通过已经表现出的系统缺陷而必须要做出突破性改造的地方。 >> >> >> > >On Jun 15, 11:58 pm, sjinny wrote: >> >> > >> " >> >> > >> Unix类开源系统做网络游戏特别是MMORPG网络游戏的服务器,存在综合效率比较低与某些重要功能的扩展上有重大架构缺陷 >> >> > >> " >> >> > >> 能不能具体说说这些缺陷是什么? >> >> >> > >> 在2009-06-15,lu 写道: >> >> >> > >> >Unix类开源系统做网络游戏特别是MMORPG网络游戏的服务器,存在综合效率比较低与某些重要功能的扩展上有重大架构缺陷,对于想要实现xMan这 >> >> > >> >类创新型MMORPG产品的架构确实不是最合适的选择。 >> >> >> > >> >做一个MMORPG系统的整体架构,不仅要吸取传统架构的经验,也要善于总结传统架构的缺陷和重大限制,再综合MMORPG整体架构所需要具备的各类庞 >> >> > >> >杂的海量基础知识,对商业需求与公司总资源进行全面的权衡后,才可作出正确的决策,最大限度为公司减少风险,增加产品研发成功的几率。- Hide quoted text - >> >> >> > >> - Show quoted text -- Hide quoted text - >> >> >> > - Show quoted text -- Hide quoted text - >> >> - Show quoted text - >>
征途运行在linux下,并且创造过单区4W人在线的记录.虽说征途也使用了多线程,但主逻辑循环仍然是单线程的.
征途的单服承载人数并不高,不会超过3000人.它单区能上这么多人是因为对场景的划分.分成了数个国家,每个
国家又有数块地图.
===== Original Message =====
On Jun 17, 6:49 pm, sjinny <sji...@163.com> wrote:
> 要不你说说这问题的答案?
> AOI跟path finding没关系的。
> 另外问一下,你参与过哪些商业mmorpg项目?能问下你现在是在哪家公司做架构师吗?
>
> >> >> >> 其实个人不太喜欢多线程,因为要把多线程做对很难,要在做对的同时还要封装好,让使用者不需要知道这是多线程的、随便怎么用都不会出问题那就更难了(其实我觉得----这不太可能实现)。一但不能把多线程的相关概念封装好,那么可能会使多线程概念在使用了这个模块的项目里扩散得到处都是,结果就是可能很多地方都不得不去-关-心-加-锁解锁、避免死锁......
On Jun 17, 10:21 pm, sjinny <sji...@163.com> wrote:
> 你都不知道这三人登录后在场景里的距离、三人的视野范围......怎么可能知道谁能看见谁呢......
> >> >> >> >> 其实个人不太喜欢多线程,因为要把多线程做对很难,要在做对的同时还要封装好,让使用者不需要知道这是多线程的、随便怎么用都不会出问题那就更难了(其实我觉得-----这不太可能实现)。一但不能把多线程的相关概念封装好,那么可能会使多线程概念在使用了这个模块的项目里扩散得到处都是,结果就是可能很多地方都不得不-去-关-心-加-锁解锁、避免死锁......
> ...
>
> read more >>- Hide quoted text -
个人感觉"整个区只使用了一台session服务器,用来处理好友,工会等功能."这个描述不准确。
想知道这台session服务器到底负责哪些具体工作,如保存了角色的哪些信息,与各个"场景服务器"要保持哪些信息和数据的交换,采用的通讯方式是什
么?只有在了解这些技术基础之上,才能知道这个系统到底能支持哪些功能上的实现,是否符合项目的需要。
如果假设真有好的技术,那么实现超过WOW、EVE、或者The sims之类的经典应该是件可以达到的事,不知道为什么巨人推出的产品还是那么毫无新
意,还要去代理国外的休闲游戏来运营。难道不知道自己研发产品的利润是代理的3倍以上吗?真搞不明白他们脑子里是怎么想的。
On Jun 17, 8:24 pm, kennywong <huangweil...@21cn.com> wrote:
> 不好意思不好思,邮件不好使,发了这么多重复的
On Jun 18, 10:14 am, sjinny <sji...@163.com> wrote:
> 打电话你是首先用电话号码来说明你要"看到"谁,而网游里你能看到谁不是由你来选择的,而是根据你在场景里的位置来决定的......
> >> >> >> >> >> 其实个人不太喜欢多线程,因为要把多线程做对很难,要在做对的同时还要封装好,让使用者不需要知道这是多线程的、随便怎么用都不会出问题那就更难了(其实我觉得------这不太可能实现)。一但不能把多线程的相关概念封装好,那么可能会使多线程概念在使用了这个模块的项目里扩散得到处都是,结果就是可能很多地方都不得-不-去-关-心-加-锁解锁、避免死锁......
"打电话你是首先用电话号码来说明你要"看到"谁,而网游里你能看到谁不是由你来选择的"
首先,你打电话说你要见谁,这个与MMORPG里的两个角色选择了网络登录是一个相同的动作.他们都有自己的号码(用户名).与电话系统一样,决定你能
不能通话是由中国移动的服务器决定的,你也遇到过"不在服务区\用户忙\不能接通"的通知吧?
这与MMORPG Server side里判断能不能看见你,完全是一个道理,这样讲你能理解吧.
On Jun 18, 12:46 pm, sjinny <sji...@163.com> wrote:
> 为什么你从来都不具体说明自己的观点呢?
> >> >> >> >> >> >> 其实个人不太喜欢多线程,因为要把多线程做对很难,要在做对的同时还要封装好,让使用者不需要知道这是多线程的、随便怎么用都不会出问题那就更难了(其实我觉得-------这不太可能实现)。一但不能把多线程的相关概念封装好,那么可能会使多线程概念在使用了这个模块的项目里扩散得到处都是,结果就是可能很多地方都不-得-不-去-关-心-加-锁解锁、避免死锁......
> >> - Show quoted text -- Hide quoted text -
xMan请及时查收邮件.
On 6月18日, 上午11时49分, xMan <MESSAGE...@163.COM> wrote:
> 做MMORPG架构哪怕是MMORPG服务器端的专业人士肯定回告诉你:"你被自己的直觉欺骗了"。
> 一般人肯定会做出与你一样的猜测,但是且慢,你先要弄清楚角色在MMORPG的Server side里是怎样被识别的。客户端场景里的位置与服务器端
> 的识别是种什么样的关系,这可不是两句话就能讲清楚的。不过你如果真明白中国移动网的整体架构,就是你说的"蜂窝我又不是不知道",如果你真明白这其中
> 的原理,你就会知道你现在对于世界最复杂软件系统的MMORPG架构还缺些什么知识,只有将这些知识一一不上,才有可能理解这些复杂的架构组成和操作原
> 理,否则你永远都是在猜测。
>
> On Jun 18, 10:14 am, sjinny <sji...@163.com> wrote:
>
>
>
> > 打电话你是首先用电话号码来说明你要"看到"谁,而网游里你能看到谁不是由你来选择的,而是根据你在场景里的位置来决定的......
>
同意 XMan 的观点!佩服LU的能力!
On 6月18日, 下午4时28分, lu <mdna...@gmail.com> wrote:
> 感谢xMan代我做出了回答,呵呵.最近比较忙,有时间一定会尽量与大家交流互动.
>
> xMan请及时查收邮件.
EVE Online是基于Windows系统的一个典型现代MMORPG应用,迄今已经取得了市场认可,特别是在单组服务器提供海量玩家在同一游戏世
界方面的领先性尝试取得了成功。个人认为EVE Online的成功是在经过一系列科学规划的MMORPG系统整体架构的基础之上,再配合上合理的商业
策略,经过多项工程优化而得到的一个综合结果,并不是单独某项的突出而能取得今天这样漂亮的成就的。
这个部分的说明准备配上些图片辅助,由于近来工作的关系,写作可能会有所延迟。
> > xMan请及时查收邮件.- Hide quoted text -
> > - Show quoted text -- Hide quoted text -
现在中国网游行业是以从来没有接触过网络游戏的初级玩家为用户的对象群体,通过数年爆炸性的膨胀长为基础,网游公司通过简单的低质量产品进行快速的规模
扩张为主要商业手段发展而来。
现在这个传统的网游市场很像传统的中医市场,在没有西医的冲击之前,暂时会维持这种传统的商业模式和市场规模。
现在的创新型网络游戏就像当年的西医从方法论入手进行革新,随着对人体细胞组织、人体NDA等微观事物的发现,推出了具有针对性的药物、疗法和大量的现
代医疗器械等产品,充分满足了人们的服务需求,同时也开辟了一个巨大的新市场。
同样,我们在MMORPG领域也首次初步绘制出了MMORPG DNA等微观世界的详细图谱,推出了满足中国纯消费型玩家的新网络游戏、内置广告市场和
面向国际的三维设计人员的新市场,充分满足了人们的各项需求,同时也打开了一个容量更加惊人的崭新市场。
所以很同意你的上述看法,同时也希望你们在网游行业的科学探索中取得良好的业绩。
> > - Show quoted text -- 隐藏被引用文字 -
>
> - 显示引用的文字 -
> > - 显示引用的文字 -- Hide quoted text -