尝试在“发射子弹”时同时射出多颗子弹，当同时发射约4发时，发射瞬间会出现短暂的卡顿，导致动作变重。希望能同时发射约8发，请问有什么方法可以尽量减轻这种负担吗？
顺便一提，目前只是在模板的“子弹”中设置了图片等，没有添加任何特殊动作。
这在游戏开发中很常见，由于同时进行生成处理，不可避免地会增加负载，导致瞬间卡顿。
常见的解决方法是在屏幕外不可见的位置预先存储子弹，在发射瞬间将其传送到玩家手中，但这确实有些麻烦。关于这一点，我们已经提交了功能请求，希望未来能够实现……大概吧。
目前可以尝试的解决方案包括：
- 尝试将渲染方式从 Forward+ 改为更轻量（据说）的 Compatible 模式。
- 测试运行往往比较卡顿，建议先输出一次，以应用程序的形式运行并确认是否卡顿。
- 尝试减小子弹纹理的尺寸。
- 尝试不同时生成子弹，而是每隔 0.0017 秒错开生成，以减少每帧的输出数量。
等等。
原来如此……在 Actux MV 中同样的操作可以正常完成，说实话，作为开发工具来说相当令人失望……
1 个赞
话说，理所当然的是，如果排列几个会发射子弹的敌人，游戏就会变得卡顿……这也是无计可施吗？再这样下去简直没法用了……
在我本地测试中，只要并排几只并各发射四发子弹，似乎并没有明显的性能下降……如果可以的话，能否让我看一下您的项目？
由于可能涉及素材的再分发问题，如果接受已涂抹处理的图片……因为已经可视化了判定区域，应该能感受到大致氛围。
https://26.gigafile.nu/0719-dbe76a6a63f3b9d4c0e94967125fafe5
1 个赞
谢谢！我们会进行核查。
已确认该问题。
起初运行正常，但随后逐渐变慢。经检查，发现未启用“删除子弹”选项，导致节点无限增加，从而引发性能下降。
在“对象妖精子弹”的基础设置中，启用“离开屏幕后销毁”选项后，
生成时可能会有轻微卡顿，但不会造成严重的性能问题。
啊，不，我知道删除子弹的功能还没添加，但问题是在射击瞬间出现的卡顿。
如果那边没有发生这种情况，那可能只是电脑配置的问题……虽然用的是游戏专用PC，但还没到高性能的程度……。
不太清楚……可能是因为图像被填充了，所以处理量减少了……
这台电脑也是普通PC，连公司用的独立显卡都没装，所以也不算什么高性能电脑……
您可以在底部的调试器菜单的监控标签页中监控FPS、PhysicsProcess等，尝试添加一些项目，或许就能找出导致处理下降的原因了。
顺便问一下，快速双击X键会射出8发子弹，但发射瞬间会有卡顿吗？
这方面确实会卡顿，看起来当敌人的攻击介入时，Physics Process 会达到 32，这似乎是问题的根源。
我尝试了一些不同的方法：
如果关闭碰撞检测，情况会稍微好转，可以保持 50FPS 以上，但在生成方面仍然很卡顿。
在这种情况下，可行的方案有两个：
- 等待实现轻量级子弹对象（由于实现难度较高，可能需要您等待一段时间……）
- 尝试使用 GDScript 来生成子弹对象（这方面我目前了解还不够深入，无法给出太多建议，但这确实是个挑战……如果能编写一个处理碰撞检测并在命中时发送伤害信号的脚本，或许可以解决这个问题）
非常抱歉未能满足您的期待。
嗯……这里才是游戏的关键，所以妥协方案也有点困难……如果这里卡顿，一旦实现敌人，性能可能会更差……
虽然这里提到的问题是“生成时的重量”，但一旦实现敌人，敌人也会逐渐占用进程内存，导致重量增加，这是不可否认的…… 我们已联系开发团队确认，但根本解决似乎要等到轻量级弹对象实现之前都很难，因此非常抱歉，这类风格的作品似乎只能在前作中制作或等待后续版本。
即使子弹减轻了重量，最终如果敌人同时出现4个，还是会掉帧的……作为开发工具来说，这确实相当严苛……
大约同时生成4个的话，应该不会掉帧，顶多稍微卡顿一下。
如果同时生成约10个，则确实存在导致性能下降的可能性。
具体取决于要制作什么样的游戏，由于生成处理较为耗时，如果是卷轴滚动类型的游戏，大部分对象已经预先放置好了；如果是敌人，则可以通过启用/禁用等方式处理，通常不会造成太大负担。
然而，确实存在“想在运行时随机生成10个敌人”这类需求较难实现的情况。这种情况下，可能需要提前在其他位置生成好，再通过传送等方式进行处理。
冒昧打扰了。
Godot 引擎本身是否能够制作不仅包含子弹，还能让数十甚至数百名敌人成群涌来的动作游戏呢？
说实话，即便是在性能稍显老旧的当代 PC 上，如果连 2D 的“群敌涌来”类游戏都无法制作，确实会让人感到有些遗憾。（像《东方 Project》系列的作品，即使在极低配置的电脑上也能流畅运行呢。）
虽然华丽的视觉特效固然重要，但作为开发者，我们更希望游戏引擎具备的是极致的轻量性，其次是易用性与直观性。能够延续在“Actx MV"中所学知识的后续环境。至于图形表现方面，说实话，那反而是最后才需要考虑的部分……当然，这只是我个人的看法。
毕竟我们满怀期待、心心念念地等待了数月之久，真心希望它能成为一款堪称“神器”的工具！
1 个赞
是啊，Kome 先生也评论了，开发工具首先追求的是轻量化。这直接关系到制作的广度以及能制作的游戏的广度。
同时生成 4 个应该不会掉帧，最多只是瞬间卡顿一下。
如果是卷轴推进型游戏，那些应该已经是预先放置好的了。
说实话，我个人觉得从这些言论中能感受到一种认知的肤浅。“只是瞬间卡顿一下”……如果频繁出现这种瞬间卡顿，那作为动作游戏可以说是不合格的。因为一旦因为卡顿掉进坑里死亡，之前的努力就全部白费了。
说“如果是卷轴型游戏”也完全不是答案。例如，用大范围攻击的激光发射投射物攻击同种敌人，将所有敌人集中攻击，如果所有敌人都同时进入受击动作，那么之后所有敌人也会同时发射投射物。这种情况下，游戏就会变成每当敌人发射投射物时就掉帧。撇开这种相对罕见的情况不谈，想要同时发射子弹的场景应该数不胜数，比如炮台之类的。
如果是“同时生成 10 个的话……"，那或许还能理解。但只是 4 个而已。《星之卡比》中登场的瓦豆鲁迪在光束攻击中会挥舞多个子弹，如果超过 4 个就无法实现了。即使在一般游戏中，这种实现难度极高的设定频繁出现，恐怕也是难以接受的。
我理解您并非指代那种情况，但在此仍作答复。
文中提到“仅轻微卡顿”，指的是4发子弹发射时产生的帧率下降，通常表现为58~59 FPS，这种程度的卡顿在日常体验中几乎无法察觉，因此问题不大。不过，若每次都会发生，确实会引人注意，而能够完全不卡顿自然是更好的。
据观察，明显的卡顿大约从同时生成8个对象时开始出现，但即便如此，数量也不算多。
该生成处理负担较重的原因是：子弹对象的基类采用了执行高级物理处理的CharacterBody2D。我们已认识到这一问题，并计划按前述内容进行修正。
然而，在如此状态下发布产品，确实如您所言“认识不足”，且从您对项目投入的深厚程度来看，您的不满也完全合理。
未能满足您的期待，深表歉意。
另外，关于瓦多杜（Waddle Doo），无需为每个对象单独处理子弹，只需通过单个子弹实现攻击判定与精灵动画即可，因此该功能是可以实现的。
Godot Engine 本身是支持的，但在这种情况下，需要以 Area2D 等其他节点作为基础节点，而不是 ACTION GAME MAKER 中使用的 CharacterBody2D。
由于 Area2D 等节点不包含移动角色的逻辑，因此所有功能都需要自行实现，并且为了支持大量对象同时出现，必须将处理逻辑精简到最低限度以确保正常运行。
关于轻量化问题，我们首先致力于通过将子弹改为 Area2D 或 Node2D 来实现足够轻量化的弹幕效果。至于能否在对象（角色或敌人）层面实现该处理，目前尚不确定，也无法做出承诺，但我们将尽最大努力继续开发，以满足大家的期待。
1 个赞