火影忍者OL后台的国际化与本地化

发表于2016-01-22
评论6 3.9k浏览

一、火影忍者OL出海面临的问题

  火影忍者OL从2014年11月10日开始公测,至今在国内已经运营一年多。火影忍者OL几乎每周都有迭代版本,目前已迭代60多个版本,发展出形式多样的玩法,包括单服、跨服和联服。后台系统架构采用分区分服的设计模式,网络模型为星型结构。前端TGW接入,逻辑server框架采用tapp,数据库使用mysql。其中运用了大量的TSF4G组件,包括TBUS、TORM等。运行稳定,效果良好。但是后台架构在设计之初没有考虑到国际化的需求。对语言支持并未提供一个好的解决方案。2015年7月启动了火影忍者OL海外版的计划。运营的需求是交付第三方联合运营,根据语种分出多条线。由于国内已经运营一年多,游戏内容已被大部分玩家熟知,因此游戏内容的消耗数据会快于国内版本。在这样的背景下,我们开始国际化与本地化的运营之旅。

二、语言国际化

  语言国际化是我们前期筹备需要做的第一个工作。由于历史原因,代码中有许多hardcode的中文,首先要做的就是替换这些中文。
虽然运营侧是按照语种分线部署运营。但是我们还是希望做一个国际化的版本,适应所有语种,以减小后续开发的工作量。以这个目标为出发点,我们制作了一套自动化工具和消息替换代码类。流程如下图。

1、自动化工具提取代码中的中文消息,在消息替换代码类中增加一个ID。另外,ID和中文消息的映射保存在一张excel表中,提供给策划,进行相应语种的翻译
2、自动化工具会根据原来的代码生成相应的使用消息替换代码类的代码块。代码的逻辑是根据ID找到对应的文字内容,填入到buffer中
3、将新生成的代码块替换原来的代码
4、策划使用excel根据不同的语种进行翻译
5、将翻译后的excel编码成程序的配置文件
6、正常编译相应代码
7、在程序启动后加载翻译配置到消息替换代码类中。

这个流程的完成了语言国际化的需求,也方便了策划配置后台返回提示语。

三、运营本地化

  在运营商确定后,后台就开始和对方的平台进行对接,主要是登录和支付的对接。为了后续工作更加顺利的进行,我们请求了互娱运营部和计费平台部的支持。在登录方面,运营部提供了IMSDK解决方案,游戏测只需将原来的PTlogin替换成IMSDK。和运营商的平台对接的工作交由IMSDK处理。接入流程入下图:

  • IMSDK前端登录系统将平台的帐号转化成游戏侧的UID,并校验平台的登录key,将平台的key转换成IMSDK的key
  • 游戏前端把UID和IMSDK的key带到游戏侧后台进行鉴权,成功后完成后续的登录流程

  在支付方面,火影忍者OL一直采用计费平台部的midas,海外版同样将元宝托管在midas。midas和海外平台对接,游戏侧的几乎不需要变更。用户在平台充值成功后,平台通知imdas发货,midas发货成功后发送同步消息到游戏侧,完成支付流程。非常感谢互娱运营部和计费平台部专业支持,大大提高了系统的可靠性、可用性。另一方面,策划会和对方商讨运营的规划。这个规划定下来后,后台就需要对初始版本做本地化的内容。主要工作内容包括基线版本的规划和本地化运行活动的定制。本地话运营活动和国内的开发方式一样,策划根据运营需求写出策划案。一部分为新增活动。这部分内容需要和国内指定的规则保持一致,同时做好区别,避免后续合入代码冲突。另一部分为移植活动。这部分内容可能是完全移植,也可能是部分移植。在部分移植的地方做好标记,方便后续的代码合入。基线版本的合入工作量较大。合入代码的流程如下图:

  我们采取的方案是将基于上一个版本的差异合入新的基线版本中。具体做法是在svn库中基于上一个基线版本创建一个新的分支,删除内容,将新的基线版本拷贝到这个目录中。然后将上一个基线版本到本地化最新版本的变更内容合入到新的基线版本中。合入的过程可能会遇到冲突,需要人工进行合并代码,这时候本地化的标记会起到非常大的作用。如果两个本地化版本有数据结构的变更,则需要验证数据升级是否正常。因为基线版本可能跨了几个国内的迭代版本,一些兼容性的代码可能会删除。因此这部分是很有必要进行验证的。我的做法是把现网数据拉取的测试环境,在测试环境模拟一个现网,再做变更。

三、总结

  国际化是国内游戏发展的一个趋势,因此在后台开始架构游戏的时候最好能考虑到这方面的需求。需要做的只是符合相关规范,语言国际化,代码版本控制,需要持久化的数据一定要做好兼容,最好能使用tdr、protobuf等编码工具,这样后续能避免许许多多的坑,为国际化运营做好支撑。

如社区发表内容存在侵权行为,您可以点击这里查看侵权投诉指引