更多

《江湖X》开发笔谈2 - 技术选型 推荐作品

系统分类: 首页 开发 干货分享

本项目由 汉家松鼠 上传发表,如其侵犯了您的合法权益请联系我们!

广东省 / 独立游戏开发小组
2016-9-21 13:25:15

马上注册,结交更多的独立开发者,享用更多功能,让你轻松玩转INDIECN

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
本帖最后由 汉家松鼠 于 2016-9-21 13:34 编辑

210129l1wwjriatgoawtw9.png

写在开头,对于任何非尖端型研发项目的技术选型,我的忠告:
不要造次

江湖X技术选型
客户端: Unity(C#+lua)
服务器:SCut(C#)
数据库: redis、mysql

关于客户端游戏引擎
Unity目前是,未来几年内也将会是中小型游戏工作室的最佳游戏引擎选择。

从开始使用unity前,我对上面这句话,深信不疑。
到我们使用unity后,我对上面这句话,更加深信不疑。

技术选型的过程
使用unity其实我们没有太多的疑问。
Unity的强大之处,我就不赘述了,有兴趣的同学自行翻阅官方资料和业界评价。此处只说一下我当时的思路历程

在开始做《金庸群侠传X》以前,我就开始关注了一系列当时的游戏引擎或图形开发库(可以见我更早期的博客),包括SDL、HGE、FLASH等等。
后来尝试过使用silverlight/WPF框架(金X在0.6之前的版本,就都是使用silverlight开发的)
决定使用unity是当时需要将《金X》移植到手机平台,考虑到代码的通用性,我们便采用了同样使用C#编程语言开发的Unity。移植比较顺利,当时大概只花了2天左右的时间,就初步完成了。
我当时同样尝试了FLASH的方案 AIR/Starling框架,我花了大概4天时间将游戏初步移植,但发现其整体开发效率、直观性等一系列均落后与unity,考虑更多的是,unity社区非常繁荣,而flash正日薄西山,所以我放弃了FLASH体系。
众所周知,近几年主流的跨平台手机游戏引擎是cocos2d和Unity,cocos2d主要使用C++开发(最近貌似在大规模推cocos2d-js以及配套的大量集成开发环境),而Unity使用C#——在开发效率上,我认为unity几乎完胜。
而我认为,在小型独立游戏工作室,开发效率大于一切。

关于编程语言
我个人非常喜欢 C#语言,我曾经使用过非常多的编程语言(如C、C++、PASCAL、python、perl、C#、java、javascript、php、AS、ruby、lua、LOGO……),C#和python毫无疑问是我用的最爽的编程语言。
写在前面,当然C#毋庸置疑写代码的时候很爽,但实际跑在生产环境中的时候,坑还是不少。特别是很多写法在不知道实现原理的情况下,没有经验的程序员很容易写出性能非常低下或者开销非常大的代码、或者是Unity的.NET subset不支持、抑或是iOS的一些特性导致不支持的代码,这里我会在后续的博客中总结说明。
这种隐性约束的坑,不趟一遍永远是不会注意的。

另外,使用lua语言进行热更新已经几乎是行业标配:lua是非常非常适合游戏开发的脚本语言。
关于热更新这里简要说明一下:
热更新:在游戏中不升级客户端安装程序的情况下,对游戏进行更新。也称游戏内更新。

ulua提供了高性能的静态/动态绑定,来实现和C#的交互。(虽然也有很多坑!)
我们将在后面单独一节,讲解热更新机制的设计及实现。

关于UI系统
在Unity下,UI系统有若干解决方案。目前主流使用的是NGUI,大量基于unity的商业游戏也证明了NGUI的可用性。
我自己当时通过反复对比,认为UGUI一定是未来的发展趋势(毕竟官方支持),所以即使有非常多的坑,我也愿意和unity的成长一起来趟。
主要是我认为NGUI的很多实现方式感觉像在一个3D引擎上打补丁,而非优雅的解决方案。让我用起来非常别扭,而UGUI更加强大的所见即所得的编辑模式吸引了我。
在此插句话,我还是非常中肯的认为,微软的Expression Blend是我曾经用过的最好的UI builder工具!

所以我们第一时间入了当时并不成熟的UGUI的坑(Unity4.6),并且为之付出了非常沉重的代价(如中间很长一段时间的UI bug导致闪退)
目前来看,我还是认为值得。并且为坚持当时自己的选择感到欣慰。
Unity团队一直在很努力的改进UGUI,其以肉眼可见速度在完善。综合我们的开发效率来看,其易用性、性能均可,稳定性还有可提升空间,但目前及时开发商业级游戏,也属于完全可用状态。

关于服务器游戏引擎
不同于大部分游戏开发团队,我希望服务器和客户端使用完全一样的开发语言。

好处:
  • 程序员只需要学习/精通一门语言,利于后期扩展团队
  • 我并不希望严格的区分客户端和服务器程序,因为我认为两者本身就是一体的。一个合格的程序员应该从前端到后端可以独立完成一个模块。
  • 客户端和服务器可以共享同样的数据结构,并且是一份代码(甚至一个dll)
  • 可以随时将代码从客户端挪到服务器、或者从服务器挪到客户端,进行非常灵活的计算部署或数据验证(甚至可以像开发单机一样来开发网游)
通过调研后,我们挑选了国人写的游戏服务器引擎Scut作为开发框架。
当然,从一开始,我们就规划了服务器群组的概念,这个我会在后续的文章中讲解。
服务器结构,我们也划分了诸如账号服务器、游戏服务器、计算节点服务器等。基于更长远的业务逻辑规划,账号服务器我们目前使用J2EE的框架开发的,提供RESTful接口给游戏服务器调用,此处不赘述。

关于数据库
KV型数据库和关系型数据库各有合适的应用场景,所以我们两者同时使用。

Redis
一些高频访问、游戏业务逻辑严密相关的数据,我们均放在redis里。并且我们设计了一套原创的ORM框架,来实现C#的POJO到KV型DB的映射。
此框架极大的利于我们提升开发效率,我们永远只需要关注逻辑实现,而不用关心底层存储。为了节省传输带宽和计算资源,我们实现的ORM框架保证了所有的数据增量同步。
有时间的话,我将会在后续的文章中详细的介绍本框架。或者有必要的话,我们会考虑开源。
同时,我们还在依托于redis的查询性能做了大量活跃数据的存储(相当于充当了memcache的角色),这样比自己开发代码级缓存或在mysql里缓存性能要高许多。

MySQL
没有太多好说的,一些账号关键数据,我们使用mysql记录。

后续优化方案
为了提高服务器性能及单位硬件内支撑人数,合理的处理并发拥塞,我们后续会引入MQ(消息队列)、基于对象数据库或OSS的多级缓存机制,我会在后续的文章中详细说明。
热度
927
浏览:927次 收藏:0次 评论:2次
喜欢:0

广东省 / 独立游戏开发小组
2016-9-21 13:25:15 发布

您需要登录后才可以回复 登录 | 立即注册

本版积分规则

全部评论(0)

快速回复 返回顶部 返回干货分享