“大家好！我是《群星》内容设计师之一的Caligula，我基于叙述性写作和脚本执行各种任务-“脚本”是我们做与编程类似的工作的术语，换句话说，我做的是Modder们的工作（尽管我有一个很大的优势，那就是能够窥探源代码并在需要时进行更改）。每一个内容设计师都有自己的定位，而我的观点是，当一个特别复杂的系统需要编写脚本时（或者，更常见的情况是会给我带来麻烦的“噩梦”——天堂之战），我就进入了突破口。

现在，我们将在接下来的几周或几个月内展示很多激动人心的新内容，但是今天，受上一篇开发人员日记之后提出的一些问题的启发，我将为modder们和有“野心”的modder们写一篇关于脚本技术方面的文章，特别是关注什么会导致性能问题以及如何避免编写糟糕的脚本。

群星脚本语言是一个非常强大的工具，可以用它完成很多工作，但首先要注意一点：仅仅因为某件事是可能的，并不意味着就应该去做。我再怎么强调也不为过，因为（以我的经验来看）这种态度几乎肯定会导致性能问题和无法阅读的脚本，六个月后，当你意识到它的某些部分被破坏时，你将无法解决这些问题。尽管需要记住的是，按照定义，用代码执行某些操作会更快：在代码中，您可以检查单个功能并完成该功能，但是如果希望通过脚本对其进行访问，则在检查功能之前，它必须经过的必要功能很少（将脚本行转换为代码命令，检查脚本是否在正确的范围内使用，等等）——因此，为什么要对某些东西进行硬编码，以及为什么对问题采用过分棘手的解决方案却最终变得非常糟糕。 因此，要考虑的第一个问题是，我真的应该这样做吗？

04

是什么导致性能问题？

每次运行检查或执行某个效果时，都会占用计算机极少量的处理能力。除了一些应该谨慎使用的例外情况（稍后我将讨论这些例外情况），这是完全可以的。当检查经常在许多对象上重复时，问题就会发生。实际上，这通常是人口的原因，在银河系中的所有行星上运行某些东西也是一个很糟糕的主意。

第一步，尽可能控制脚本的运行时间。 最好的方法是设置触发事件的位置，并在可能的情况下使用on_actions（或触发决策等事件），而不是平均时间发生，甚至更糟的是，将事件设置为每天尝试触发。如果需要一定程度的随机性，则还可以通过例如每年一次的脉冲触发隐藏事件，然后随机延迟触发所需的实际事件（例如，查看事件action.220）。 ”

更多请浏览

https://forum.paradoxplaza.com/forum/threads/stellaris-dev-diary-182-the-perils-of-scripting-and-how-to-avoid-them.1416409/