OpenRA到底是个什么样的引擎？是否有前景？下面给大家进行一些简单的评述。

首先，什么是欧盆RA：

引用自 https://cowlevel.net/article/1885075

“OpenRA是重新开源实现Westwood Studios的策略类游戏“命令与征服：红色警戒”游戏引擎，利用OpenGL的新一代显卡硬件加速功能。

根据github的记载，OpenRA最早的版本开始于2010年9月24日，但是很长一段时间他都处于非常初级的状态，应该说经过了7年的更新现在的openRA可以说已经到达了“可以顺畅玩下去”的程度。

目前OpenRA的发布版本已经支持了沙丘2000、红色警戒1、命令与征服1三个模组（开发版本正在研究支持命令与征服2）

OpenRA本身也是对西木的游戏的一种延续。

说了这么多，OpenRA有啥好处：

1.支持新windows系统、mac甚至是linux，不需要兼容性，不需要改变一些东西。

2.支持高分辨率

3.增加了很多后来RTS游戏的新特性，比如框选，比如集结点等等，CNC1和RA1的双边栏改为了RA2后来的组合边栏。

4.修复了平衡性

5.有联网机制，甚至是在线对战！

6.给CNC1增加了遭遇战（原版CNC1可是没有遭遇战的）。

7.可以自己选择关卡，同时在有原版资源的情况下可以看过场动画。

8.方便的可扩展性，以及地图编辑器！

9..（有可能可支持多国语言，如果支持多国语言有望这两个早期作品能够添加中文....）”

首先，欧盆RA并不是一个能和Ares相提并论的引擎。它的初始目的仅仅在于复刻沙丘2000、红色警戒1、命令与征服1这三个老古董游戏，而这三个老古董无论是画面还是游戏机制，现代的RTS玩家多半没有兴趣。将“复刻版RA1引擎”拿出来和“魔改版尤里复仇引擎”进行比较，并得出前者远高于后者的结论，某条杂鱼的脑袋想必不怎么好使。

那么，我们下面要明确一个评判的标准。作为一个游戏引擎，我们对它的评判不应涉及所谓的“情怀”之类无关要素。游戏引擎要评判的，应当仅仅和在上面制作游戏的难易程度，以及和做出来的游戏是否容易运行有关。

那么首先就要粉碎欧盆RA云舔狗们妄想出来的第一个优点：开源。

开源是优点吗？很遗憾，对于一般modder而言，开不开源无关紧要。有些崇拜者硬说“这样的话你就可以任意增添你需要的功能了”，然而这些云舔狗们并不知道的是，欧盆RA的整体架构无比操蛋，以至于想要加入任何功能都需要对引擎本身进行修改。某种意义上这也可以解释欧盆RA的冷门：对于一般modder而言，这个引擎实在是难用得要命，功能匮乏得不可思议，而如果你有足够去改这个引擎的编程能力，那么你为什么不用正儿八经的成熟引擎呢？

此外，看一看各种成熟引擎，你也会发现开源之类属性根本对它的用户毫无意义：魔兽争霸3的引擎从未有“开源”一说，上面却可以用编辑器写出DOTA来；星际2使用的银河引擎功能无比强悍，是公认的万能引擎，在编辑器玩家嘴里甚至有个“买银河编辑器送星际2”的笑谈。可见，是否开源，对于引擎本身的能力毫无影响。开源引擎不见得强，闭源引擎不见得弱。如果一个开源引擎本来就一塌糊涂，那么也只有开源有可能拯救它；而如果一个引擎本身已经足够强悍，那么为什么还需要期待某个不知身份的神仙来给它修修补补？遗憾的是，欧盆RA就属于那种本来一塌糊涂（或者说，引擎机能完全符合它的初始目的：复刻一个RA1级别的RTS，而高于RA1的部分就无能为力了），只能期待外面的神仙来救它的程度。只能说，开源不是优点，只是它还没有凉透的救命稻草。

那么说起开源的部分，有些云舔狗就要胡乱吹嘘一通，什么欧盆RA有一个庞大的开发团队，足足有250多人。这也是个能令一般路人瑟瑟发抖的数据，然而我等老油条看来也是胡吹一通，脸上贴金。点进欧盆RA的GayHub页面，可以看到的确有250多个contributor，然而不幸的是GayHub还会提供所有contributor的参与情况。我们简单看几个图：

至2019年，commit数量前十名还在活动的contributor仅有6人。

40开外，和后8名。可以说不仅早已停止活动，连对工程的参与度也可以说是相当低了。那么，这“250多个开发者”的说法，水分到底有多大，大约也不需要再详细解释了。你以为“250多个开发者”是个个都在全力投入地为这引擎添砖加瓦？当然是“做过任何一点参与的人加起来有250多个人，包括移植RA1美术资源什么的那些”啦。

何况，人多又如何？代码量大又如何？以这个引擎9年多的历史，和它现在的表现来说，也不过仅仅是个能玩程度的RA1，和RA2上已经实现的引擎机制相比还是差的太远，虽然我们不会说，欧盆RA的开发者和做Ares的比起来连提鞋都不配这种踩一脚捧一手的智障言论，但是RA2modder去欧盆RA上搞东西无疑是自讨苦吃。

欧盆RA作为引擎，在最底层的架构，乃至于设计思想上都是有巨大问题的。

1.首先，美术问题。在RA1/RA2这种级别的老游戏上，引擎对于美术资源能达成的表现能力并没有太多的影响，因为游戏中的“即时渲染”比重相当少，仅有游戏内VXL体素（一般坦克单位）的显示需要进行实时计算 (RA2甚至是缓存好放屏幕上的，不涉及太多实时运算，姑且假设欧盆RA全部是即时渲染吧)，而建筑、地形、步兵、爆炸动画等等完全依靠在3Dsmax中渲染出制作好的图像帧，并转成游戏识别的2D格式：SHP，游戏仅仅是把它们摆放到屏幕上而已。

这就是欧盆RA上的VXL，可以注意到，游戏中的模型似乎严重缺乏光照感，缺乏明暗对比。我对许多人根本不玩游戏，只关注车辆在斜坡上歪不歪的迷之举动表示嗤之以鼻，所以我不把车辆在斜坡上不倾斜视为缺点，而观众们可以自己决定。

但是，这某种意义上是断绝了欧盆RA上vxl对shp的最后一点“优势”。既然vxl放进去也是这样，为什么不全部SHP化呢？

可是，SHP是一种现代modder公认的垃圾格式。为了照顾ra2年代小得可怜的硬盘容量，美术素材不得不进行索引SHP化，以每个像素点对应一个256色色盘的方式减少文件体积。然而到了现代，不到0.5GB的游戏几乎算是小游戏了，大型游戏无不50GB起步，上不封顶，玩家也有足够的硬盘空间装下各类可怕的大型游戏，何况一个小小的红警。欧盆RA并未适应时代的变化，只是死死抱持着类似“祖宗之法不可变”的思想，游戏内支持的2D美术素材格式依然是老古董垃圾格式SHP。虽然他们自作聪明地为它增加了alpha通道支持，引来了各路井底之蛙的一片欢呼，但这完全是在一套完蛋的体系上修修补补而已。现代的2D引擎，没有一个不支持RGBAlpha的PNG序列，而这种格式支持也为开发带来了便利：3dsmax可以直接渲染出带alpha的png，可以说是渲染出来就能用，而欧盆RA弱智的复古操作使得任何绚丽的图形都无法使用，需要先为它生成一个256色的色盘，然后再强行转换成256色，既增加了大量无意义的转换步骤，又不得不损失画质。RA2modder使用SHP，并不意味着他们喜欢这个垃圾格式，而欧盆RA的支持alpha通道的SHP就像是慈禧太后皇宫里太监拉的火车一样尴尬。它本可以像其他引擎一样支持RGBA的。只因为它“是红警”所以就继承了红警的那些脱离时代的机制，实在是可笑之极。你说为了支持旧红警的美术素材？任何一个现代化的mod工具，包括最常用的SHPBuilder都可以批量导出SHP文件为PNG序列，适配“如果存在的”现代化素材格式。

2.引擎机制问题。总有些刚刚入门的菜鸡用户夸耀欧盆RA的所谓优点：引擎内没有注册表，没有烦人的注册机制，不会因为什么东西不注册了就从游戏内消失；无需重复复制具体某个模板，因为所有物体都可以继承自某个早就准备好，内置了一切属性的根模板，只需要声明和根模板的差异即可。

可能这些小鬼们还停留在对基础功能进行反复运用并且乐此不疲的程度吧。就像幼儿学习母语时候会反复告诉大人：这是xx，这是oo，这是□□。然而这些所谓的“优点”并不能让你在上面做出什么酷炫的机制，充其量能够减少modder在复制一大堆数值各不相同的犀牛坦克时候产生的烦躁感。是优点，不否认，但是根本不算什么革命性的优点。

下面就是要谈谈欧盆RA最大的缺陷：机制的匮乏。

银河编辑器作为公认的万能引擎，它的底层设计可以说是非常精致的。其核心思想是开放游戏内的一切底层逻辑和事件，允许用户将其自由组合，由此产生无限多的效果。你无需创造新的引擎机能，因为一切基础机能都有了。

然而欧盆RA的设计思想就十分古怪。它并不愿意设计开放的底层逻辑，而是要求所有用户将一切可能使用到的功能，可能发生的事件，都通过修改引擎的方式，每一个都单独写到单位上去。一切功能、事件从逻辑上都是单位的附属物。

这种说法可能对于一般人来说很难理解，下面给出一些具体的例子来展示。

拦截导弹。银河编辑器中，一切游戏内存在的东西，都属于可以互动的物体，只不过有一大堆标签决定了什么东西可以与它互动。歌莉娅的导弹和歌莉娅一样，都是游戏内的物体。下面大致解释一下星际2的拦截导弹的点防御无人机如何工作。由于时间过得太久，记得不太清，不过大致上是这样的流程：

无人机单位【创建时获得一个“拦截导弹”状态】，【此状态下】，无人机单位【定时】（每0.01秒）对自身周边X半径的圆形范围进行【区域搜索】，【搜索对象限定】为带有抛射体标签的物体。【对于搜索到的物体（此处为抛射体），使用效果】【造成x点伤害】，同时【减少自己的能量x点】。并有一个全局的，限定当无人机能量低于x时，令拦截导弹状态失效的验证器。

方括号标记的所有内容都是引擎内的机制。我们可以进行任意替换。比如将搜索对象限定中，限定抛射体的内容取消掉，搜索任意单位，并把【对于搜索到的物体，使用效果】接口中的【造成x点伤害】替换成【发射导弹：渡鸦炸弹】，或者改成【创建单位：蜘蛛雷】，或者【引用效果：动能冲击伤害】，或者【附加状态：状态：移动速度-50%】。可以想象这种功能全部都是打碎到最小逻辑的引擎，自由度是非常高的，而且为了创造各种效果，只需要改动调用的功能节点即可。

（根据上述内容，可以得到：一切AOE效果的核心机制就是区域搜索。搜索一个指定范围内合乎要求的对象。如果对搜索到的对象产生伤害，就是普通的AOE伤害，如果是附加状态，就是群体buff/debuff，如果是发射抛射体，就是分裂攻击）

而在欧盆RA中，拦截抛射体的实现要反智得多。首先，如上文所说，欧盆RA仅有单位这么一个核心，而体现在武器的方面，就是“单位并没有发射炮弹单位”。一切欧盆RA里的攻击效果都是预先计算好的演出。引擎读取攻击者和目标，并读取武器代码里的抛射体飞行参数（比如，是不是导弹），然后根据飞行参数，将对应的美术资源摆上屏幕，并按照计算好的轨迹线移动。既然是演出，导弹便不可能成为一个可互动对象，也不存在什么区域搜索的事情。它的实际进行方式如下：

单位有一个属性标签，叫做“拦截抛射体”。单位指定一个用于此情况的武器。当此单位被另一个单位攻击时，检查此武器是否可以使用(是否冷却中)。如果可以使用，则在抛射体飞到单位的“拦截抛射体半径”后，对计算好的位置发射这个武器。这个武器的爆炸效果在视觉效果上就是抛射体被拦截时候的爆炸。

虽然你可以说，这也的确是实现了视觉效果上的拦截抛射体，但是实现方式非常落后。其中用到的每个功能都是专属于这个“拦截抛射体”的功能，需要跑进欧盆RA的原引擎中动手动脚，大多数一般路过modder并没有这样的能力。而实现流程中也不涉及到任何对引擎现有机制的调用，而是直接增加了一大堆对于“攻击”有关演出的干预。可能在遥远的上世纪90年代，PC机能十分有限，频繁进行区域搜索这种运算会拖垮游戏速度，然而现在9102年即将过去，苹果的处理器A12都已经支持每秒5万亿次运算，这种90年代节省计算资源的算法早就毫无必要，只会使得引擎变得难以使用。

实例2：光环效果

银河：光环单位【创建时获得一个“光环”状态】，【此状态下】，单位【定时】（每x时间）对自身周边X半径的圆形范围进行【区域搜索】，【搜索对象限定】为带有己方标签的物体。【对于搜索到的物体，使用效果】【附加状态】，附加的状态为【持续y时间的比例/定值改变速度，生命值，等等】

可以说，银河编辑器中“光环效果”和“拦截导弹”效果总体上的差异并不大。

而在欧盆RA中，光环效果的实现方式又体现出了浓厚的90年代落后风格。

光环单位有一个属性标签：“光环”，另有一状态，叫做“光环启用”，如果单位不带有“光环开启”，就不会受影响，必须给每个潜在对象加入这一效果。当然，根据欧盆RA的“优越性”，你可以在根模板中加入。带有“光环”标签的单位会定时缓存自己身边的格子数据，如果有目标单位进入/退出，就更新缓存。进入区域内的单位随着缓存更新，激活身上的“光环启用”状态，并在这个状态内修改其生命值、速度，等等。

在这两个例子下，就能看出欧盆RA的明显不足了。

作为一个开源软件，开发者会往里面增加自己需要的引擎级机制。然而这个引擎的原生基建做得太差，许多只需要组合底层接口就能实现的东西必须通过改引擎实现。所以产生了非常严重的重复建设问题。在拦截导弹和光环上的确都存在着一个确定效果对象和效果来源的距离问题，然而因为这两个功能是不同人写的，距离的确定方法也就各不相同了。拦截导弹和光环，并不是直接调用一个“搜索区域”，而是各有各的奇葩做法，比如把单位坐标全部缓存这种落后方法也的确非常复古，非常90年代。

实例3：布雷。

欧盆RA里想要布雷，需要在引擎里写一个“布雷车“属性，然后令这个布雷车布一颗雷（就是RA1里面的那玩意），而如果你想实现将军式的炮弹发射雷场，在RA2的正常思路是调用一个刷步兵的机能，刷出一大堆地雷”步兵“。欧盆RA的话，还是得写一个全新的”雷场“属性，发射武器后标记一块区域为雷场，然后在有单位进入的时候直接对它的生命值进行操作。然后为此又得写一个判定单位进入这个区域的机制，再次发明一遍已经被发明过无数次的轮子，实在是笑煞旁人。

所以，欧盆RA的开源“优势”到底体现在哪里呢？恐怕不是什么优势，而实际上是所有人都可以给它做各不相同的稀奇古怪的算法，以实现某些通用的效果，而且各个机制之间的底层效果无法互相通用。毕竟代码数量过大，谁都不知道某种底层机制到底存在不存在，不如自己写。所以，拦截导弹用的距离算法，和光环的缓存，显然是不能通用的。本质上说欧盆RA的每个功能都是封闭功能，互相之间进行协同作用的可能性也算是几乎不存在。某种意义上说，这就像在语言中不使用基本的名词动词形容词，而是将“春哥纯爷们，铁血真汉子”  “やっぱり…嘘だったんじゃないですか…中に誰もいませんよ”  “噫，好了，我中了”之类的具体情况全部发明成单独的名词使用（而不是“春哥”“爷们”“铁血”“汉子”之类的单词组合起来）一样，还为它的“效率”沾沾自喜。以如此贫乏而僵化的体系，显然能实现的东西是非常有限的，而且每要增加一点新内容，就得跑进欧盆RA的引擎里敲敲打打。谁干啊？

现代的RA2mod基本是按照银河编辑器的思考方式制作的——区域搜索，创建物体，赋予状态，发射抛射体等等机能都可以在RA2的扩展引擎中找到对应的机制（av64357691，av64585033），而过滤目标这种东西也完全可以调用旧有的基础机制来制作——也就是RA2自有的护甲系统。欧盆RA无法调用这类原有基建，只能在所有单位上加上是否受影响，还得改动引擎才能写出这种目标过滤机制，噗噗。虽然它开源，也并没有哪位引擎大师突然灵光一闪，搞出了各种机制互动的可能性，搞出了可以直接调用的底层，大家都自顾自的搞封闭功能。

更搞笑的是上面所述的两个大功能甚至不是欧盆ra原生支持的。再次重复一遍：欧盆RA是一个立足于复刻RA1的引擎。那么你为什么需要什么魔兽争霸3的光环，将军的拦截导弹，炮弹布雷？欧盆RA的原开发团队秉持这种思想，对超出RA1范围的引擎机制都缺乏兴趣，更是对于增加通用的底层机制表示鄙夷。他们认为，如果modder想要实现什么东西，完全没必要搞什么底层机制拼装，直接在引擎里做一个这种机制就好了。此外，欧盆RA的目的很简单，就是要创造一个RA1的复刻版，以供国外的RA1遗老们游玩。往引擎里塞进RA1以外的机制甚至引起了RA1遗老的愤慨。

无疑，这种你不会编程还玩个屁的思想导致了欧盆RA用户的严重匮乏。你必须要掌握C井才能在欧盆RA上制作高级一点的mod（如果你不仅仅满足于RA1级别的贫乏内容），可是如果你已经掌握了C井，为什么还要在一个机能匮乏的老古董引擎上折腾呢？顶级开发者不玩欧盆RA。顶级开发者玩Unity或者其他成熟引擎。对组合底层机制的鄙夷是注定要把潜在用户赶走的，何况大部分modder都不是搞程序的，有语言学博士，有美工，有初中生高中生大学生，有B站up，有产品经理，有语法律师，其中不乏顶级modder，同样要从头学习一个引擎，那么为什么要去学习又不好用，又人气凉凉的欧盆RA呢？玩玩的话，纯英语INI的RA2在用户体验上可比欧盆RA不知高到哪里去了。RA2上手难度极低，这是公认的事实。

诚然，欧盆RA有许多第三方功能包，然而第三方功能包究竟从哪里获取可是个大麻烦。再次重申，官版欧盆RA能实现的机能仅限于RA1的层次，只能创造RA1级别的游戏，而RA2级别便已无能为力。而MODDB上的欧盆RA仅有7个在2019年尚有更新，其中4个是对旧CNC美术资源的简单移植，剩余一个看起来像是RA1的mod（质量从发布的图片来看只能说一言难尽），一个是复刻TS，一个是复刻RA2。想要获取能够实现RA2级别功能的第三方功能包，就得去搞对应的这些mod，找他们要修改授权之类之类的。

问题不仅仅在于这里。哪怕搞得到这些mod，拿得到授权，后续依然是个大麻烦：欧盆RA带RA1之外的mod启动非常蛋疼，常常会出现根本无法进入游戏的问题，更糟的是根本没有这些问题的中文解决方式，你得去discord上找人。官方更是对第三方功能包表示不屑一顾，认为并不是所有人都需要第三方功能（反正他们只想照顾RA1遗老，RA2这群人完全就是擅自跑来的，还老抱怨引擎太菜），而用户去搜寻第三方功能包本身都是个“问题”，而且第三方功能包也并没挂在什么显眼的地方提供下载，直接去欧盆RA主页，你只能找到RA1层次的玩意。在官方功能贫乏得不可思议的基础上这种“不该用第三方功能包”“不该找第三方功能包”的观点简直让人笑掉大牙。总而言之，官方并不欢迎不懂编程的一般用户，并且强行推广这种落后的引擎设计。如果你不愿意接受“每个功能都自己写”，官方甚至将其视为对官方开发者的个人攻击。

那么，还能怎么办呢？只要你会编程，你热心，你愿意参与这个“伟大”的计划，欧盆RA早晚能够成熟？别傻了。就这个架构设计，这个开发指导思想，这辈子不可能翻身了。现在的欧盆RA只适合RA1遗老，在可预见的将来也不太可能超出现代设计思想接近银河编辑器的Ares。RA2modder为什么要放弃在Ares上呼风唤雨的机会，跑到RA1上搞简单的白板炮复制品？就因为不用注册？盒盒盒盒。