写在开头，对于任何非尖端型研发项目的技术选型，我的忠告：

不要造次

江湖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的多级缓存机制，我会在后续的文章中详细说明。