开发日志前言

我目前正在开发一个我认为可能会优先考虑多人在线的PVP/PVE rougelite游戏，但我不想讨论这个游戏本身。只是想谈谈我游戏中的制胜系统，以及将来所有开发决定的驱动力，我正在开发的程序化武器生成系统。具体来说，我想在开发过程中经常听取反馈和看法，并看看我对系统的理解是否正确。并且我想将自己的逻辑解释写下来，以确保它的合理性。

过去几个月，我一直在开发一个程序化的武器生成系统，这个系统的目标超过了典型的统计修改以及相同武器的重色绘定和重新涂漆。这个系统可以生成一套程序化的动作/攻击序列，基于已生成的武器类型，并且这些动作/攻击序列也是由基于武器的动作/攻击序列生成的，可以说是基于语言的。这个系统部分 受inspired Noita 以及 Elden Ring 的模块武器系统。

我十分肯定，有一个正式的名称这个类型的程序化系统，它基于语言，这就是为什么我想研究它。所以我可以继续进行下一步骤。

程序化系统-武器

我对程序化武器的前景中，觉得只重复颜色绘制以及两维像素艺术的内容不够。因此我制作了一个系统，包含“武器段类型”和“语法规则”（以下简称为“语法”），将武器拆分成一个一个的段，根据这些段和语法规则来控制武器的组装方式。

程序化系统-动作组

简单来说，一个武器包含一个动作组，一个动作组是一组动作，这些动作是由具体的组成构成的。

从一个完美的武器开始时，我系统首先根据武器中已经生成的语法和生成的Weapon Query来确定必不可少的动作组的组成，以便我知道我应该生成哪些武器。

接下来，如果我确定了可以产生的一系列动作组的组成部分，而且有一个武器Query，那么我用这些动作组来生成整个动作组。

但是，如果你只是想要知道整个系统的具体细节，那么这里是如何工作的。

程序化系统分为两个主要部分：武器和动作组

我已经开始了Weapons Segment System来处理武器生成和Weapon Query生成。每个武器段都包含一个语法系统以及一个语法解释函数来解释Weapon Query。每次当你想要生成一个武器时，你就需要从一个Weapon Segment开始，根据语法规则和你已经确定的Weapon Query来生成一个新的Weapon Segment。由于你也可以使用其他段来组成新的段，所以最终生成的武器也是由一个段生成的树形结构。

程序化系统-动作组

使用上述系统生成的最终结果是Weapon Query以及动作组的描述，根据这个结果动作组的描述我系统就可以动态生成一个新的动作组。

我通过一些抽象逻辑来表示动作，这些抽象逻辑可以在动作上执行，当动作结束时就会停掉这段逻辑。

这个动作组包括动作组中的动作，也就是说，每个动作组有一个树形结构，树的根节点是动作组，子节点是动作。每个动作的树形结构和上面动作组的树形结构是类似的。

我可以通过Weapon Query来生成不同类型的动作组，并且我可以根据当前的Weapon Query来生成不同的动作组。

最后，当你生成了一个动作组后，你就可以在动态生成的动作中执行这些抽象逻辑。因为当执行动作用时，一旦动作结束，那么这块抽象逻辑立即就会停掉。

我在程序化系统中的困扰

系统本身没有逻辑上的问题，而且形成一个视觉武器以及对应的Weapon Query的系统也是工作的。但是当我把这些系统结合起来时，就会遭遇一些麻烦和困难。有几个原因可能导致这些麻烦。

首先，当系统变得越来越复杂时，就会变得越来越难以维护和添加新的功能，尤其是你还没有把所有的代码都测试过，那么增加新的功能就会增加错误的风险。

如果你有很多独立的系统组成你的游戏，那么你就需要把每个系统都维护好，不然就容易出问题。

目标和意图

如果我能够成功的开发好这个程序化武器生成系统，那么我就可以动态生成无限多种的武器，并且我可以根据玩家的不同喜好来生成不同的武器。

如果我可以成功的开发好这个程序化武器生成系统，那么我就能够实现对武器的真实感染和扭曲，这将是一个很大的挑战。

在开发程序化武器生成系统的过程中，我要做到快速迭代，也就是说，要能够快速的完成系统的测试和改进，以便能让玩家能够更快的玩到自己的武器。

我还希望能够推理出如何从玩家获取的信息来动态的生成新的动作组和抽象逻辑。

如果我能够这样做，那么就意味着玩家可以从自己的喜欢的武器中获取一些不同的属性，例如动作方式，攻击范围等等。

此外，如果我能够推理出如何动态生成新的动作组和抽象逻辑，那么我就可以让玩家根据自己的喜好来动态的生成新的动作组和抽象逻辑。

因为只有当玩家能够对自己喜欢的武器进行各种不同操作和配置，那么就会增加对游戏内容的投入感和拥有感。

其他的问题和困扰

因为程序化武器生成系统是一个复杂的系统，所以也会存在一些问题和困扰。

首先，程序化武器生成系统可能会变得太过复杂，甚至是难以维护了。

所以我需要在系统的设计时，权衡系统的复杂度和易用性，以便让玩家可以尽可能容易的玩起来。

此外，如果系统过于复杂，那么就会增加开发错误的风险，就算我们有最好的测试流程，最好的测试人员，如果系统过于复杂，那么就很难完全测试系统的完整性。

因此，为了避免这些问题，我需要在系统的设计和开发中坚持“简单易用”的原则。

最后我需要确定系统中哪些部分可以动态的变化，而哪些部分需要固定。