题主解锁了成就——引战成功 ：）

1、游戏引擎不纯粹

游戏引擎并不是那种特别短小精悍、几个神奇的算法加起来构成稳定健壮的系统的那种程序。比方像Git、Lua、SVN类似的程序或者系统，虽然看似高深，但是功能边界非常清晰。

现代游戏引擎，除了一些小而美的2D引擎，都是无可避免地走向越来越复杂、越来越集成化的方向。很多功能早就脱离了“渲染”这个核心任务，而是要考虑逻辑扩展、编辑器接口、资源管理、资源编辑器的集成、嵌入脚本引擎等等繁琐的功能中去。

而且很多引擎还要从底层支持UI系统，UI这东西可真不小，而且是典型的特别适合用经典面向对象实现的系统。

2、规范约束，释放C++的潜能

既然如此，如何进行良好的工程管理，如何让大量思想不完全一致的人协作起来，是更重要的任务。如果其他人的思路和你不一致，总不能指责别人“你语言没用对”吧……怎么才算用对，难道你用的就一定对？

C++在统一观念上不见得更好，甚至问题更大，因为支持多种编程范式……但是如果在工程中做出良好的规定，什么能用，什么不能用。经过限制之后C++的语法特性真的能解决很多问题，毕竟有原生的继承，好用的泛型，特别是C++11之后泛型变得越来越好用了。

C++语言特性过于太多，以至于很多地方都被人批判。但是实际工作中，我们总能通过交流沟通、制定规范、代码审查来避免绝大多数坑，其实某些“缺点”都是可以解决的。

反观C，在参与者多了之后问题挺大的。比如：1、用C写面向对象程序，每个guru都有自己独到的见解； 2、指针、类型的转换过于跳脱，互相审查代码有心智负担。当然guru不怕这个。

3、用的人少不见得就不好

话还要两面说，用的人少就不代表不好。

如果进行良好的封装，不要考虑“大而全”，其实C+Lua的方式来制作引擎也特别好。兼顾了底层效率和灵活性。

总之，具体用哪种技术路线其实还要看引擎的设计目标吧。


技术选型这事，说到最后更像是经济学问题，不是纯技术问题。

（上图为示意，不严谨）