ET介绍——为什么使用C# .net core做服务端？
为什么使用C# .net core做服务端？
游戏服务端从早期的单服到分布式，开发越来越复杂，对稳定性，开发效率要求越来越高。开发语言的选择也逐步发生了变化，C 到 C++ 到 C++ + PYTHON 或者C++ + LUA 到现在 很多公司开始使用erlang，go，java，c#。目前是一个百花齐放的局面。
但是如果是要你重新做一个网游server，不考虑对公司或者已有的东西兼容性，你会怎么选择？我仔细想了一下这个问题，大概有这个几个方面需要考虑：
1. 语言的稳定性（致命性）
游戏服务器的特点是高负载低延时。所以一般服务端进程都是带状态的，一旦挂掉就意味着数据丢失，这点是无法容忍的。
2. 运行时热更（致命性）
游戏服务器逻辑极其复杂，很容易出现bug，但是又不能经常停服，所以热更修复bug就显得十分必要。出现错误开发人员可以立即编写代码，然后热更修复，线上用户完全感觉不到。
3. 是否有协程支持（重要性5星）
分布式服务器架构，进程与进程之间必然会有大量交互。由于游戏逻辑很难拆分成多线程，所以一般来说都是逻辑单线程。如果没有协程支持，必然产生大量回调，代码维护会变得非常困难。
4. 编译速度（重要性5星）
使用c++开发，30%的时间都浪费在编译上。假如编译很快或者不需要编译，必定大大提高开发效率。
5. 跨平台（4星）
一般游戏服务器都架设在linux上面。但是平常开发，使用windows会更加方便，如果跨平台，开发以及测试效率会大大提升，并且不需要单独搞一个开发机，本机电脑就可以满足平常开发
6. 可阅读性，可重构性（3星）
代码可以重构能大大减轻写代码的难度
7. 库是否齐全，生态是否完善（3星）
库齐全，生态好，自己需要造的轮子就少
8.跟客户端统一语言（3星）
客户端服务端共用语言，优势十分明显，很多代码可以复用，逻辑程序员不再需要区分前后端，双端都可以写，一个人即可完成一个功能，大大减少了沟通的时间成本。
9. IDE的支持（3星）
代码提示，重构等支持，优秀的IDE能提高几倍的开发效率。
10. 语言的性能（1星）
目前服务器性能都不是太大问题，不过性能好总比性能差要强。
| 语言 | C# | C/C++ | Java | Go | Lua | Python | Erlang |
|---|---|---|---|---|---|---|---|
| 稳定性 | 稳定 | 容易挂 | 稳定 | 稳定 | 稳定 | 稳定 | 稳定 |
| 运行时热更 | 支持 | 较难支持 | 支持 | 不支持 | 支持 | 支持 | 支持 |
| 跨平台 | 支持 | 较难支持 | 支持 | 支持 | 较难支持 | 支持 | 支持 |
| 协程 | 有 | 需要自己实现 | 支持不好 | 支持 | 支持 | 支持 | 支持 |
| 编译速度 | 快 | 慢 | 快 | 快 | 不需要编译 | 不需要编译 | 快 |
| 阅读性重构性 | 好 | 一般 | 好 | 一般 | 差 | 差 | 差 |
| 游戏库跟生态 | 好 | 好 | 一般 | 一般 | 差 | 好 | 一般 |
| 客户端统一语言 | Unity | Unity、UE4 | 暂无 | 暂无 | Unity、UE4 | UE4 | 暂无 |
| IDE的支持 | 好 | 好 | 好 | 普通 | 差 | 差 | 差 |
| 语言的性能 | 好 | 极好 | 好 | 好 | 差 | 很差 | 差 |
从表格可以看出:
- C/C++稳定性差，编译速度慢，存在致命缺陷
- Go不支持热更，由于不支持泛型，重构性较差，无法跟客户端共享代码，存在致命缺陷
- Java协程支持差，无法跟客户端共享代码
- Lua库少，性能差，代码可阅读性可重构性差，跨平台完全依赖C/C++，处理起来麻烦，ide支持差
- Python 性能很差，代码可阅读性可重构性差，无法跟客户端共享代码，ide支持差
- Erlang 性能差，函数式风格不好上手，ide支持差
- C# .net core各个方便都非常优秀，不过跟UE4无法共享代码
当前Unity是最火的游戏引擎，C#服务端搭配Unity完全是天作之合，基本上找不到缺陷。
ET开源地址地址：egametang/ET: Unity3D Client And C# Server Framework (github.com) qq群：474643097
