“We actually hire a lot of our best software engineers out of the gaming industry.”
--Elon Musk
马斯克早年搞过游戏，现在发火箭；卡马克一直搞游戏，业余发火箭。美国火箭行业有很多来自游戏行业的工程师，火箭是高科技，游戏是"儿戏“，何故？
在微软AAAA工作室 The Initiative 一个大佬的影响下，今年年初去面试/交流了一个洛杉矶的3D打印火箭公司，和技术总监（来自NASA）、首席软件（写当年了Falcon 9的系统）还一些组员（做Disney过山车的，和EE写硬件的）都聊了聊，受到了不少启发，这几天赋闲在家总结一下，保密协议的就不说了（也没啥大不了的，毕竟已经产业化了）。
概括起来，共通点有：
- 计算机系统构架
- 微软Xbox360是PowerPC架构，同样的架构也是SpaceX Falcon 9 引擎微处理器的架构。
- 同期索尼PS3是自己独特的CBE架构，由索尼、东芝、IBM共同研发，有多个类型的处理器和更细分的RAM规划。也正是因为如此，同期的PC要想达到类似的运行效果，往往价格会高出不少。原因在于前者的极致优化，而PC的通用性和强大计算能力，使得优化的必要性降低。
- Xbox One和PS4以后，大家都采用了类似的X86架构，这也是当代火箭计算系统的构架
- 火箭需要更可靠，所以多重冗余是必须，因为宇宙运行中会遇到一个bit被宇宙射线反转，不能影响指令。而游戏机可以出错，大不了像Cyberpunk 2077一样撂挑子不支持老机型。
- 物理模拟和实时计算
- 大型游戏引擎，都需要强大的物理模拟和计算能力，在专门的线程甚至在Microservice，以某种更新频率计算。这和火箭的物理模拟计算类似。
- 随着细化的物理模型引入，大型游戏引擎的计算精度已经不断提高，但重点还是计算“量”。而火箭在于计算精度和复杂的数理模型，比如对于质量求微积分，因为箭体的质量随着燃料消耗在减少，同时燃料在燃料箱里的晃动会带来物理属性的变化，这些在游戏中是很少考虑的。
- Microservice应用构架
- 网络通信和模块趋向于Microservice，这个是大型游戏应用层构架，包括Google Stadia都在发力的方向，因为可以on demand的进行请求和计算，同时分成一个个modular模块，方便代码的更新管理和维护。同样的，火箭公司也在做类似的构架。
- 跨进程通信（Inter process communication)，如此的架构，意味着不同进程间的通信是家常便饭。
- 编译器
- 火箭出于对准确性的需要，可以牺牲一些效率（因为其本身的计算强度和作业任务不算太复杂，比起一个MMO游戏），所以往往关闭编译器优化。
- 游戏会针对自己特定的部署环境，去有选择性的利用编译器的便利
- 火箭系统和游戏系统都有针对自己系统的一套语言，用来方便二次开发和Runtime改写，这一点在研发上编译原理是100%共通的
- 计算效率Performance
- 这一点是Hacker们最引以为豪的自己怎么优化了、或者巧妙地绕过了多少运算，人类之光的存在。
- 其他
- 网络安全性，数据加密
- 数据压缩，面对有限的带宽
- 控制器和微处理器，输入输出：机械操作，手柄、机械臂，LED灯、haptics、动力系统开合。
- 操作系统，发火箭改写更安全的linux kernal（linux也有bug），偏好单线程稳定性；游戏，处理海量数据，可以有错，尽量利用多核多线程。
- 写C++
总而言之， 游戏的底层的东西和火箭的软件系统，都是在一个资源有限的嵌入式系统进行输入输出和计算模拟。能够让各个功能模块协同合作、高效运行，让产品完成预期的任务是二者的共同目标。
所以，能够造一个高效、价格合适的专一任务的主机，并且有很多应用在跑、很多从业人员开发和优化，距离民用火箭是一个逼近，至少。从侧面可以反映一个国家的产学研能力吧。毕竟很多计算机科学的进步都是为了解决实际问题发明的。