七月中旬，O3DE开源了，这一大家子齐活了。
它们仨的关系，差不多算得上是套娃。CryTek在快不行的时候，把CryEngine3卖给了AWS，拿了一笔钱，然后大重构出了CryEngine5。AWS封装魔改CryEngine3做出了一个Lumberyard，Lumberyard没有盘活（星际公民难产到现在还生不出来），然后AWS就几乎把这个项目割了。O3DE目前是开源组织维护的，他们把Lumberyard拿了过来，疯狂重构衍生出了O3DE，同时Lumberyard并没有就此尘封，还在慢腾腾地往前更新。
21世纪10年代的时候，游戏如日中天地发展，亚马逊也想插足一脚进来，但是亚马逊是做云平台起家的，思维方式和做游戏的完全不一样，亚马逊想把游戏引擎架设在它自家的云上，这大概是最早的云游戏思想了吧。亚马逊本身此时对游戏引擎的开发是没有技术积累的，而亚马逊最核心的需求也不在于游戏引擎本身的技术而在于用游戏来推广它自家的云服务器，因此收购一个当时现有的引擎，在上面改造就成了最快的解决方案，但是选了一个会让人哭的引擎，就算是亚马逊，也没能把它整笑，还差点把自己给玩死了。难怪大家吐槽，亚马逊的最大贡献，就是开源了CryEngine3的源码。
在亚马逊拿着Lumberyard快玩不下去的时候，O3DE站了出来，原先Lumberyard的大批人马，走的走、到O3DE的到了O3DE，还留在Lumberyard的所剩无几了。随后O3DE开始在这上面重构，首先重构了Lumberyard操蛋的构建方式，这年头基本没人会选WAF做构建，用WAF在Lumberyard里加个东西相当要命，另外Lumberyard的编译如果没有IncrediBuild支持，那能耗上5个小时，而且它自己提供的脚本还只有全部clean和全部build，预编译了一堆头，改点底层的东西想调试，就得全部重新编译一趟，十分操蛋，另外Lumberyard还有一些模块间的依赖关系没有指明清楚，导致IncrediBuild加速编译的时候有时候编一半会出错，重新再编译一次又正常了（没明确定义好依赖关系，会让IncrediBuild对项目生成的依赖关系图出现问题，放到多个agent上并行编译的时候，依赖的模块放在了另一个agent上还没生成出来，重新再编译一次时，在当前基础上增量构建让IncrediBuild重新生成了顺序，这个问题就不出现了）。当然Lumberyard也不是一无是处，Gems模块化的思路，通讯组件等等这些做的都非常好，毕竟这些才是AWS拿手的东西嘛。O3DE明智地选择了大家熟悉的CMake，把框架依赖全部撸了一遍，增量编译都变得容易了不少。然后O3DE几乎摒弃了CryEngine，开始自己重写游戏引擎渲染模块Atom，我认同重写的需要，只有自己的东西才有完全的掌控力，尤其是游戏引擎（但是不代表所有的都要重写，比如标准库就完全没有必要，亚马逊没有重写游戏引擎，居然重写了一套标准库AZStd，用来替换C++的STL，我没明白为啥要这么做。掌控力应该是掌控核心产品的实现方法，而不是所有的东西，何况是一个标准库，而且Lumberyard里面还写了三套序列化库…阿西巴）。周边的游戏功能还是继承Lumberyard的设计，以Gems插件化的形式加进来，这种策略也是正确的，模块化和按需动态加载能应对各种扩展需求。
总的来说，O3DE让我看到了一点盘活的希望，目前来说是取其精华去其糟粕的重构，希望O3DE能逐渐做出点东西来~
