一个SLG游戏
2015年11月到2017年4月,我在公司的一个SLG游戏项目组工作。SLG应该是指策略游戏(Simulation Game)。
说的更具体一点,这几年手机游戏行业出现了两个标志性的SLG游戏。部落冲突(COC)和海岛奇兵(Boom Beach)。
加上后来Supercell另外一个游戏,皇室战争。游戏立项的时候,大概是2015年11月,目标是模仿这些主流SLG,
美术风格是星际风格的SLG游戏。游戏最终没有上线。因为封测的数据比较差,市场和老板觉得没有必要进行推广。
心里面有很多想说的,写在这里吧。虽然失败了,但是从技术上讲,反而比之前的ARPG换皮学到的多。
千头万绪从何说起,我是写逻辑代码的,先从技术开始,说到哪算哪。
项目组总共有11个程序。
我主要负责战斗模块开发,PVP,PVE系统开发,地理位置管理。包括客户端,服务端。其他小伙伴
一个人负责战斗寻路,战斗客户端系能优化,录像系统。
两个人负责建筑系统和一个特殊玩法联盟战。
一个人负责客户端场景和2d对象的表现效果,引擎上的支持。
一个人负责摄像头,客户端总体优化,引擎上的支持。
一个人负责兵营系统,联盟系统,及新手指引。(加一个最后一个月才来的新人)
一个人负责邮件系统,AI,和部分PVE副本玩法。
一个人负责SDK相关。
最后主程,统筹所有人的工作。一些框架上的改动。
跟我做的部分相关,技术上有几个大的难点:
1.服务端ARPG框架改为SLG框架。
公司的其他游戏全部是ARPG,没有其他代码可以借鉴。ARPG有大量的场景管理,副本管理,场景对象管理。
这些大块在SLG里只有一小部分。
SLG里只有两个主要场景,主场景和战斗场景(参考海岛奇兵)。
因此把原先在服务端的场景管理,副本管理,场景对象管理删掉。这些改到客户端管理。
以前ARPG专门有一个进程Gameworld管理场景,副本,场景对象,寻路,以及角色系统(个人的游戏逻辑)的进程。
有一个Global管理全服的活动,全服的逻辑的进程。
SLG框架去掉了Gameworld,把Gameworld里的角色管理部分移到了Global里面。
2.客户端cocos2d转Unity3d。
2015年以前只做过cocos2d的一个ARPG。这次需要变到Unity3d。刚开始是被Unity虐的,3d比2d多了很多东西。
不过好在Unity的编辑器比较专业,不像cocos2d的编辑器(公司自己的)有点简单。
第一次接触Unity,发现一个和cocos2d完全不同的概念。cocos2d里面的控件是整体性的,Unity里面控件是由Component组成的。
比如cocos2d里一个button就是button控件,它不能是label,不能是sprite。
但是unity里面控件,通过Component可以成为组合,一个button可以有label,也可以有sprite,可以有tween,可以有boxclider。
这其实只是概念上的差别。
虽然是换成unity客户端,但是脚本逻辑依然使用lua,所以实际编程而言区别不大。
游戏采用3d的场景(两个场景,主场景和战斗场景),2d对象。2d对象用的tk2d这个插件。
3.全球同服。
如同海岛奇兵一样的全球同服。以前的ARPG都是一个服一个服的,比如排行榜只能在一个服里面排名。
全球同服是世界的所有玩家都在一个服里。这在技术上是怎么实现的呢。
我不知道其他公司怎么样,我们公司本身有一套跨服框架。
游戏功能上,比如有一些副本可以让1服2服3服的玩家都进入,这种叫跨服副本玩法。
开启这种玩法需要多启动cross的两个进程。cross,crossmanager。全球同服就是逻辑上只有一个服务器。
通过跨服来实现所有服的玩家在一起玩耍。
4.战斗验证。
我们把战斗系统想象成黑盒。假设没有用户的操作,输入数据确定则输出结果确定。这样就是一个卡牌游戏的模型。
如果把战斗系统写在服务端,由服务端命令队列驱动客户端表现。那么就不需要战斗验证。
但是因为我们的框架服务端采用c++开发,写逻辑非常慢,而战斗系统注定改动非常大。
因此战斗系统改到客户端用lua写。服务端负责下发战斗数据,客户端上报战斗结果之后,服务端再下发战斗结果。
结果完全是由客户端计算的。那玩家作弊怎么办。所以必须有战斗验证这一步。
最后采用的是服务端c++跑lua模块的方式。服务端增加了一个战斗验证进程,单独处理验证需求。
在服务器下发战斗数据的同时,通过进程间通信将战斗数据传递给battleserver,battleserver理论上跑lua速度比客户端快,
也就是客户端战斗结束前服务端会有一个战斗验证结果出来。将这个验证结果和客户端上报的结果做比对。从而实现战斗验证。
这套战斗验证有几个问题。
a.客户端lua如果改到战斗模块需要重启服务器。一般客户端lua都是热更的。
现在因为战斗验证,假设策划需要微调一个兵种的数值,也需要重启服务器。
b.测试阶段会有大量数据验证异常,影响体验。由于战斗模块频繁改动,每一次改动都需要大量测试来保证战斗验证。
每一次修改战斗异常的bug后,合并到外网都需要重启服务器。
c.如果用户量大,战斗验证的请求多的时候,会不会出现阻塞,导致服务端没有验证完,客户端就已经出结果上报了。这种情况应该怎么处理。
5.战斗系统。
玩法上是这样,首先玩家在主场景的兵营摆放兵的阵型。3*5个位置。进入战斗场景之后,隔15秒出一波兵,此时玩家无法操作。
其实是模仿皇室战争,但是去掉了手动的操作。玩法好不好我不想讨论。商业游戏是为了赚钱,游戏火了才能赚钱。
游戏火不火和玩法好不好没有正相关的关系。同样是SLG游戏,有些游戏都没有战斗表现,全部是数值,一样是流水不错。
游戏能不能到达高流水,更大取决于市场和运营的能力和美术风格。玩法上当然是能抄则抄,因为游戏开发需要巨大的成本。
去抄袭一个玩法,比原创一个玩法的成功率高很多。
战斗系统是我全程从无到有写的逻辑。架构上讲,在客户端模拟了一套战斗命令队列。
客户端战斗模块收到服务端下发的战斗数据和战斗开始的协议,就开始进行战斗。
逻辑层会发命令给表现层(场景,对象)进行展现。逻辑层和表现层是分离的,逻辑层驱动表现层。
6.地理位置管理(四叉树)
可以参见我的另一篇 http://www.cnblogs.com/yao2yaoblog/p/5475231.html
我从这个游戏只有一个2d模型寻路,到满屏的对象,特效。
从pve只有一排排整齐的据点,到有云雾,有副本,各式各样的据点。
从pvp只有一个列表,到能旋转的星空,再到位置散列的星球。无论最后结果如何,我都感谢有过这段经历。
游戏成不成功不是我决定的,我能做的只有把代码写好,希望技术更好。能够理解更深的技术。
最近看到了余华的《活着》。生活本来就是个玩笑,怎么可能都如意顺心呢。
成年人的生活没有容易。但行好事莫问前程。