开发笔记 (1)
折腾了好久,终于可以开始正式项目开发了。
之前的这段日子,我们陷落在公司的股权分配问题中,纠结于到底需要几个人到位才启动;更是反复讨论,到底应该做个怎样的游戏。林林总总,终于,在已经到位的几位同学的摩拳擦掌中,叮当决定自己挂帅开始干了。
就这么不到十个人,空旷的办公室,跟我们起先想像的情况不太一样。尤其是主策划还没有落定。我说,叮当,你好歹也是一资深游戏玩家,带了这么多年的游戏部,跟了这么多成功的项目,没吃过猪肉总见过猪跑吧,我就不相信你干着会比别人差。若不是我必须盯着程序实现这块,我都想自己做主策划了。不过有你干,我放心。
主策划的位置,咱们可以先空着,前期工作不能延。产品经理代理一下游戏主策划的位置也是创业公司必须的;正如我这挂牌的 CTO ,除了负责系统架构以外,也得兼个程序员做实现嘛。
经过两天对项目计划表的讨论后,我们今天就算正式开工了。
游戏是怎样的?半保密,不在这里多写,怕大家骂。再说了,这个东西现在说是怎样的,一两年后肯定有变化,多说无益,多解释无益。简单说呢,就是一个战斗系统类似魔兽世界,但系统核心玩法差异很大,更为轻松,更偏重 PvP 的 MMORPG 。为什么是这样一个东西,不想解释,反正不是拍脑袋想出来的。
既然是开发笔记,就写写现在在做些啥,打算怎样做下去。
我们先集体玩了一周魔兽世界,虽然大部分人已经是 wow 老玩家,但还是有一两个人玩的比较少,大家一起熟悉一下。主要是熟悉战斗系统,还有美术风格的感觉。培养点兴趣,对未来我们自己做的东西至少在表层上大家都有点感觉,有爱。
瞥开美术和策划的计划不谈,主要写写程序的计划。
在 Closed Beta 前,有 8 个历程碑,到一期截至,就开始有内部运行的版本。这次完全抛弃以往在网易积累的任何一点成品,全部从零开始做。但是,对于程序员来说,一切都在脑子里,其实工作量并不大。有机会重头来,恐怕是大部分程序员梦寐以求的机会。
当然,我们购买了一套 3d engine (不介绍,不解释),起点高一些。服务器也会尽量用一些成熟的开源库。
一期打算实现基本的用户登陆,场景漫游,包括在场景中做各种跑、跳、走、骑乘等动作。
一期程序员三人:
云风:负责总体规划,总体协议设计,以及部分服务器模块的实现。
怪物公司:负责客户端的设计与实现。
蜗牛:负责服务器的细节设计与实现。
吵架是我们的传统,自今天就开始了。按照惯例,我无法说服项目组认可我的所有设计和技术选择。不过大家妥协的结果是,先按我的想法做,一期雏形在下周末前完成,根据实现过程中遇到的问题,我们在修正甚至全部重构目前的设计。一周半时间的代价是目前我们可以承受的。
ps. 程序员就是这么一种奇怪的生物。好的程序员都有自己独立的思想。对自己实现或即将实现的代码有爱。按照别人的思想去实现是件无比痛苦的事情,会觉得在浪费自己的生命。所以,大部分有活力的项目开始都是一个人建立起来的。在大公司,好多老程序员都喜欢招聘所谓有潜力的新人,认为他们白纸一张,好塑造。说到底就是听话。但事实的结果一般是,要么培养出来一个庸才,无法担当;要么,在技术选择上最终分道扬镳。我总是对他们说,想想你愿不愿意总听着别人的意见干活?如果你不愿意,那么就别指挥别人干。自己不愿意做的事情,就别让别人帮你做。
我的设计草稿是这样的:
整个游戏系统(一期工程需要的)大体由这样一些部分组成:
客户端,运行在玩家的终端上,用一条 TCP 连接和系统通讯。它接入游戏服务器网关。
网关,负责汇总所有客户端,大体上和我很多年前的想法一致 ,虽然会有一些实现上的小改变,但思想没有根本变化。
客户代理(Agent) ,运行在网关的后端,在逻辑上,每个客户端都有一个 agent 负责翻译和转发客户端发来的请求,以及回应。众多 agent 可以实现在同一个进程中,也可以是多个不同的进程里。可以用脚本虚拟机的形式跑,也可以是别的形式,这些都不太重要。这一次,我们最大可能使用独立的 lua state 来实现单个 agent。
数据服务,保存玩家数据,场景数据等。前端用自己的代码和协议同系统其它部分沟通,后端这次想采用 redis 做储存。
场景管理器,用于管理静态场景和动态副本。
若干场景服务器,用于玩家在里面做漫游。
网关之后的服务是相互信任的,并组成一个虚拟网络可以相互通讯。通讯底层暂时采用 zeromq ,通讯协议采用 google protobuf 。
客户端到 agent 的通讯协议与网关后各个逻辑结点之间的通讯协议将隔离,分开设计。甚至不保证采用一致的技术实现方案,以及协议设计风格。
这里的设计关键在于 Agent 的设计,大部分的工作量是围绕它而来的。
单个 Agent 的工作流程代表了项目一期的结果会展现的东西,大体上逻辑流程如下:
等待用户认证
把认证系统交给认证服务器认证,失败则返回 1 重试。
从数据库获取用户数据(一期数据很少,仅有默认的用户名,用户形象) ,并转发给客户端。
取得用户所在场景号,从场景管理器取得场景服务的位置,并申请加入场景。
从场景服务器,同步环境。
转发用户在场景中漫游的请求,并同步场景的实时数据。
一旦客户端发生异常或得到推出消息,通知场景服务器离开。
这里,和历史上我们的游戏服务器设计有一个小的不同。我认为,用户的角色在场景中的位置,动作状态,甚至以后的战斗数值状态,都是属于场景数据的一部分,而不是用户数据的一部分。
用户数据中,和场景有关的只包括他当前所属的场景。由场景自己来保存角色在场景中的状态数据。简单而具体的说,类似网易历史上的西游系列,玩家的坐标是玩家的属性之一,是会在持久化时存放在玩家数据里的。经过我这两年的思考,我觉得这种设计方法是有问题的。
从我现在的直觉上来说,虚拟角色的属性不应包括角色的地理位置信息。那是角色的外在约束。而场景更应该拥有在它其中的 PC 和 NPC 的位置以及各种状态。PC 下线只应该认为是 PC 处于一种特殊状态(不被周围的 PC/NPC 所见或影响),而并没有脱离这个场景。所以我更愿意把 PC 下线定义成 detach ,而上线则是 attach 的操作。在这点上,场景,作为一个实体,拥有它自己的数据逻辑。
agent 相关的协议粗略的设计如下:
- auth 登陆认证
- user/pass 取得 userid ,返回成功或各种失败
- userdb
- 用 userid 取得 avatar list
- 用 avatar 取得 avatar data (包括场景名)
- scene manager
- 用 场景名 取得 scene id
- 用 scene id 取得场景状态,返回允许进入或各种拥堵状态
- scene
- 把 avatar attach 到场景
- 取得 avatar 的场景上下文
- 把 avatar detach 出场景
- avatar 设置坐标,速度,行为(跑,走,站立),方向
- avatar 骑乘状态改变
- avatar 做特定动作
好吧,未来一周的工作任务就是这些了。需要明天再做细化整理。然后就是实现了。
Comments
厉害的,11年就思考的这个有深度,架构设计现在还在用
Posted by: tiandee | (48) January 19, 2022 06:05 PM
11年的设计思想了。。。将坐标从角色移到场景,这个设计我估计现在也应该得到了检验了,我是觉得没啥意义,而且违反最小惊讶原则。
设计很多时候不光要追求正确(黑就是黑,白就是白的认知),更多时候还要向传统妥协。做设计不是做“创”新,而是为了让东西更好用。
但很显然将坐标从角色移到场景带来的麻烦要多一些,比如跨场景要做一些额外的数据交割。
Posted by: shawhen | (47) June 22, 2015 09:23 PM
一个偶然的机会再群里看到了此文的地址,写得很不错,我本来就想学习游戏服务器的设计与开发.
谢谢.!
Posted by: OR | (46) March 4, 2015 08:27 PM
欣赏这个做风,期待爱因斯坦的第一个板凳。
Posted by: 远风 | (45) November 9, 2012 08:50 AM
觉得你们太急了,游戏最重要的还是设计,魔兽世界这种立项初期也不会这么着急就开始做,我倒觉得你们应该核心成员坐下来好好商量,花一,两个月把作品的方向和思路定下来,磨刀不误砍柴工
Posted by: 祝川 | (44) May 24, 2012 04:25 PM
游戏最重要的就是策划啊。
Posted by: luck | (43) January 12, 2012 07:21 PM
用户数据中,和场景有关的只包括他当前所属的场景
干脆和场景有关的数据都不要不存到用户数据里了。直接把场景管理器自己保存avatar在场景中的位置。登陆的时候场景管理器自己查询。这样是不是可以快速开发出多个游戏,换换场景管理器和客户端就可以了。
Posted by: shark926 | (42) December 30, 2011 11:16 AM
@zicjin
DOOM3开源引擎是GPL授权的, 商业用途直接用还是要花钱.
Posted by: dwing | (41) November 24, 2011 11:31 AM
开始关注这个系列的博文,一个骨子里都是完美主义的程序员的作品总是让人那么好奇。玩家下线,内存不清洗吗?只是更改场景状态?这样的意义是?
关注,持久关注。。。
Posted by: zuhd | (40) November 24, 2011 10:27 AM
外行不太明白,有了DOOM3的开源引擎为啥还要买其他引擎,买来的能比DOOM3好多少?
Posted by: zicjin | (39) November 23, 2011 07:36 PM
属于在不同进程间Agent的玩家,交互时数据怎么同步互斥的?
Posted by: dulm | (38) November 23, 2011 01:35 PM
能把wow当作工作来玩,多幸福。一直怀念玩wow的时光,可惜自己自制力太弱,花费了太多时间,还是afk为妙。
Posted by: flysnowxf | (37) November 19, 2011 11:10 PM
如果是MMO,场景数据和玩家数据绑的很死,如果是房间制的,这么设计倒很好,只是还是纠结网关上要不要放太多逻辑的东西。
Posted by: thumbor | (36) November 19, 2011 02:58 PM
=-= 我希望可以变成UO...如果是普通OL的话市面上的同类产品太多了……
Posted by: 沉风 | (35) November 18, 2011 06:33 PM
好料啊,云风分享精神令人鼓舞!
Posted by: windmeup | (34) November 18, 2011 06:12 PM
请问云风如何设计数据数据版本变更。redis 能很好的应付?
Posted by: irons | (33) November 18, 2011 05:56 PM
能具体说一下角色属性里包含地理位置的坏处吗? 如果信息放在场景里的话,那么场景还得保留一份角色位置的持久化数据,这样在保存数据的时候会不会容易产生一些数据一致性的问题?
Posted by: 风中客 | (32) November 18, 2011 02:26 PM
牛啊,不到10个人就开始做MMORPG了。
Posted by: 果伦 | (31) November 18, 2011 01:36 PM
wow都出来这么多年了,还模仿人家的战斗,既然主打pvp,为什么不在战斗系统上多做写创新呢
Posted by: saidi | (30) November 18, 2011 11:11 AM
这篇文章提到了很多新想法新思路,但是里面的代码量也太大了吧。这里有两个我比较感兴趣的:
一、google protobuf , 之前有试验过这个库,但是客户端说消息解析太耗时,导致不敢全面使用。
二、Player部分数据移到场景数据,这个其实可以减少很多Player的代码,实际上Player越到后面感觉越来越庞大了,不过照这个想法的话,场景数据是不是也要存储到数据库中了?
Posted by: eva | (29) November 18, 2011 06:28 AM
请问云风,你的这种数据分离设计如何处理大世界中跨cell(场景边界)的情形? avatar可以分real和ghost,每个cell也会分real和ghost么?
Posted by: 肥葵葵 | (28) November 17, 2011 11:42 PM
连续的地图和分开的地图不同的,断开的地图可以设计更高的玩法,比如键盘上的操作,连续的地图需要更高的配置~
Posted by: icicle198514 | (27) November 17, 2011 09:30 PM
不知道能不能把你说的这些思路画个图出来, 我是一个干web开发, 一直想自己写个游戏服务端框架出来, 可惜没有啥经验, 看了你的这篇blog,了解了一点点, 期待你的架构图. 从而能让我慢慢设计, 搞出点东西来, 也就当练练手, 入入门了.
Posted by: 黑夜搜 | (26) November 17, 2011 02:17 PM
贵公司招人不?
Posted by: Jiff Chen | (25) November 17, 2011 02:00 PM
潜水好多年了,期待云风的大作,不过你们的开发效率真够快的
Posted by: 不愁礼 | (24) November 17, 2011 01:38 PM
挺好,学习了 zeromq & protobuf
Posted by: hongye | (23) November 17, 2011 01:18 PM
除了lua脚本控制的agent以外的服务器端是用什么实现的呢?看之前云风的文章,难道是用的Golang?
Posted by: wooki | (22) November 17, 2011 12:14 PM
把entity的部分数据放在scene中很新颖。想起以前看过一个关于设计模式的文章,类的规划不是按照具体的猫啊狗啊动物啊这些客观实体去做,而是把对象之间的操作也抽象成了类,也许某些应用用这种大部分人第一直觉想不到的模型会很适合,但毕竟这种方式是“反人类直觉”的。我想说的是,也就是那么一个很小但不容易跨过的小坎,造成了设计风格的迥异,整体流程和部分细节想清楚了就放手去做吧,也许会得到新的好东西。
Posted by: paladin_t | (21) November 17, 2011 10:01 AM
叮当是我在网易最喜欢的人,只可惜自己实力不济,否则,真的希望跟着你们干
Posted by: BoneHard | (20) November 17, 2011 09:46 AM
开发效率这么高啊,这大概有多大的代码量啊?
Posted by: zhangst | (19) November 17, 2011 09:18 AM
一周半的时间做出server和client的雏形,这个开发效率还是很惊人的!
Posted by: zerotty | (18) November 17, 2011 09:12 AM
全是做些毒害人的东西,有种做个游戏engine啊,为什么这些高难度的东西总是老外能做
Posted by: 123 | (17) November 17, 2011 09:01 AM
pvp容易导致较大流失,但易提高arpu值,慎思。
Posted by: Rogers2008 | (16) November 17, 2011 08:06 AM
期待风云大哥的分享!!!!
Posted by: evisd | (15) November 17, 2011 07:39 AM
强烈关注技术细节!!!
Posted by: sz | (14) November 17, 2011 03:31 AM
叮当老大做策划?有意思。
Posted by: 李恒 | (13) November 17, 2011 01:02 AM
哥们,看看这个战斗系统吧=P
http://v.youku.com/v_playlist/f7183895o1p7.html
Posted by: darkfall | (12) November 17, 2011 12:34 AM
角色数据的设计很有意思,很赞同。服务器数据组织,甚至可以设计成全固定预设,完全抛弃动态分配的设计。
Posted by: zwinger | (11) November 17, 2011 12:19 AM
我想问下,那玩家的数据被加载到内存后,是打算放脚本层呢还是引擎里?
Posted by: Roc | (10) November 17, 2011 12:05 AM
avatar 身上装备的数据,CD状态这些也放到场景中么?
Posted by: hrrr | (9) November 17, 2011 12:05 AM
@Comx
avatar 的最高 HP MP 以及各种能力值属于 avatar
avatar 的当前 HP MP 身上的 buf debuf 属于场景数据。
Posted by: Cloud | (8) November 16, 2011 11:41 PM
战斗属性等也归属于场景数据?
Posted by: Comx | (7) November 16, 2011 11:39 PM
希望你们可以做出一个突出常规且容易上手的游戏。我是游戏白痴级别的,但是《植物大战僵尸》和《愤怒的小鸟》我还是玩的很开心。希望你们可以做出这样类似的游戏。
Posted by: bingsongmy | (6) November 16, 2011 11:37 PM
学习一下。学习你的项目管理和系统工程。也期待你们的游戏。
Posted by: bingsongmy | (5) November 16, 2011 11:35 PM
计划很明确,逻辑很清楚,值得学习,哈哈,,,菜个沙发
Posted by: 小何 | (4) November 16, 2011 11:30 PM
不知道你们会招人么?新人招么?
Posted by: 宸小苇 | (3) November 16, 2011 11:25 PM
沙发?坐等云风大作
Posted by: Jagie | (2) November 16, 2011 11:23 PM
其实就是 龙之谷类似的嘛~~~
Posted by: sun nix | (1) November 16, 2011 11:22 PM