不使用插件

, , , ,

大家觉得不依赖插件,或者至少不依赖第三方插件来做游戏怎么样?

使用引擎自带的插件,以及自己编写的插件都没问题,但我主要好奇的是避开社区制作的第三方插件。

5 个赞

好消息是,这会让你的游戏在编码和设计上变得更加容易。由于游戏涉及的组件更少,出现棘手 bug 的可能性也更低,因此调试工作会简单得多。

这种情况之所以非常罕见,是因为大多数人并没有在制作类似《勇者斗恶龙》(DQ)的游戏。此外,你还错失了一些可以提升玩家体验、简化操作的生活质量改进。

主要的风险在于,如果你试图巧妙地利用事件系统来编码游戏机制,而实际上使用插件会效果更好。事件系统最适合在类似过场动画的场景中使用。

4 个赞

当然可以 非常简单 制作想要的效果 bug很少

4 个赞

因此从长远来看要容易得多,尤其是当你非常擅长使用事件来处理各种事务时。尤其是依赖更少的插件,甚至完全不依赖插件。

4 个赞

对于像我这样使用大量插件的用户来说,想出更具创意的活动解决方案是一项非常有趣的挑战。

4 个赞

这些都是非常有道理的观点,我确实之前没考虑到。

我最初的想法是,人们主要使用插件来扩展引擎的功能,让他们的游戏脱颖而出。但我开始怀疑,有时候情况可能会相反。当大家都在使用 Yanfly、Galv 和其他知名开发者制作的热门插件时,某些机制、菜单和 UI 元素就会频繁出现在许多游戏中。这可能会让项目显得千篇一律。

因此,我在想,通过事件编写和/或自己编写插件,反而可能让游戏更具特色。你可以构建符合自己游戏设计的系统,而不是为了适应别人的插件来调整自己的游戏。

大家怎么看?

1 个赞

这不是使用插件的正确方式。

_这_才是使用插件的正确方式。如果你想制作某个系统,你应该做的第一件事(除了可能寻找通过事件系统实现的方法)是搜索一下是否已经有人制作了相关的插件。当别人已经做出了你需要的插件时,何必浪费时间去自己编写呢?但是如果你找不到合适的,或者找到的插件不完全符合需求,那么当然可以自己制作。

插件只是另一种工具。如果它们适合你的游戏,就使用它们;如果不适合,就别用。而且,理想情况下,应避免使用像 Yanfly/VisuStella 这样的大型单体插件,因为它们包含的功能过多。这样做不好,因为在一个插件中,可能只有十项功能适合你的游戏,而另外十二项并不适合。

4 个赞

刚开始时,你应该专注于 RPG Maker 本身能做什么。利用事件指令来创建你想要的机制和系统。
与使用插件相比,你的游戏会更稳定,系统和机制之间也不会产生冲突。而且你可以轻松地替换机制或让它们协同工作。

对我来说,在游戏中拥有多种不同的事件驱动战斗系统,并在游戏内(从一个事件到另一个事件)切换它们,或者让它们协同工作,是非常容易的。这与使用不同插件开发者提供的不同战斗系统插件,并试图让它们相互兼容相比,要简单得多。(菜单系统也是如此。)

很多人过度依赖插件,甚至为了完成引擎本身只需稍加努力就能实现的功能而安装插件。他们用不必要的进程和代码使游戏臃肿,最终用固定且僵化的系统替换了引擎中原本可以通过事件指令灵活调整的灵活系统,并且还在游戏中采用了成千上万其他人在自己游戏中使用的系统。

但我主要好奇的是如何避免使用社区制作的第三方插件

一旦你精通了事件制作(即使用事件指令创建系统和机制),那么,与其获取那些创建整套系统、机制并对游戏 UI 进行彻底改造的插件(这些插件也被很多人使用),不如使用那些增强你事件制作能力、让你能够创建自己系统的插件。

例如,在 MV 中有一个插件允许我裁剪显示的图片。还有另一个插件允许我在设定移动路线时改变行走精灵的角度。还有一个插件允许我通过十六进制代码更改“显示文本”中文字的颜色,而不是局限于 1-32 的数字代码。
^~ 这些不是完整的系统,而是对基础事件指令系统的补充。

我认为你或任何人都不应避免安装这类插件。:open_mouth:

然而,你应该避免安装完整的战斗系统、移动系统或菜单系统等。
同时,也要避免任何“核心”插件或混淆过的插件。
要知道,许多这些插件是由那些自己并不开发完整游戏的人制作的。因此,他们没有在发布和打磨过的游戏中使用过自己的插件,也没有确保其在所有方面的功能和稳定性。所以你会发现,创建完整系统的插件可能存在严重缺陷,而这些缺陷往往在开发后期才会被发现,那时已经无法将其移除。

当你只安装那些在此处和彼处添加小型事件指令增强功能的插件时(如我上面提到的那些),如果你发现严重缺陷,移除(其中单个插件)就会变得非常容易。

2 个赞

我不喜欢使用别人的插件。我觉得唯一让我满意的插件是 MZ3D,而且这也不是我会在我做的每个项目里都扔进去的东西。

我平时不太怎么用 MZ,但上次我弄了这么个东西。一个从头开始搭建的类迷宫探索游戏。

当然,问题在于工作量。但如果是为了搭建基础系统,我觉得自己花点时间做也不那么糟糕。

3 个赞

我倾向于使用插件,然后根据自己的视觉风格进行调整,有时还会对功能进行小幅修改。使用插件可以节省大量的开发时间,同时也能让我学习其他开发者的思路。当然,这主要适用于功能性插件,且仅针对未被混淆的插件。另一个优势是,在使用插件时,其代码和功能已经过众多用户的严格测试。

4 个赞

我其实有个游戏创意,就是完全不用任何插件(仅使用 RPG Maker 引擎自带功能)来制作一款完整的 RPG 游戏!这主要是为了测试引擎的极限,看看我能用它做出什么来。

我认为这完全可行,因为引擎本身已经非常灵活了。你只需要跳出常规思维、多下功夫,如果真想深入的话,还可以学一点 JS 知识。比如,对于上面提到的那个游戏,我设计了一个共享 TP 系统,让所有队员共用同一个 TP 条,灵感来源于《空之轨迹》中的灵力条。我觉得,如果不尝试用“原版”RPG Maker 来制作游戏,你就会错过提升技能和加深理解的机会。

3 个赞

不。

之所以有这么多战斗系统插件,是有原因的。因为很多人不喜欢 RPGMaker 默认的战斗系统。如果你不喜欢,完全没问题,可以替换掉它。移动系统也是如此。

不过,我仍然认为,先制作一个没有任何此类大型插件的游戏(哪怕是个小作品)是个好主意,以便更好地了解默认机制是怎样的,以及你希望它们如何不同。

这本身并不是什么需要警惕的事情。事实上,开发插件可以说是一项与开发游戏略有不同的技能,所以有些人只专精其中一项而非两者兼修,这并不令人惊讶。当然,这仍然意味着他们需要负责测试插件的稳定性。但这并不需要他们发布过经过打磨的游戏——只需要提供一个全面且打磨良好的演示即可。

我觉得你这里有点误解了。引擎的灵活性如果不借助插件是无法充分发挥的——编辑器是固定且僵化的,它对设计师施加了引擎代码本身并不存在的限制。

例如,引擎完全支持元素吸收——只需添加一个具有负值的元素率(Element Rate)特性即可。它能完美运作,没有任何问题(除了两个吸收特性会相互抵消这一事实)。唯一的问题是,编辑器不允许你将元素率特性设置为负值,因此你需要一个插件来绕过这个限制。

不过,挑战自己避免使用插件是完全没问题的,而且正如你所说,这也是了解引擎能力的一种好方法。

4 个赞

其实我不太介意,虽然我个人更喜欢自己制作插件。自己制作插件确实更适合自己的游戏,但我理解并不是每个人都有能力做到这一点 ^^

3 个赞

我觉得自己并没有偏离主题,因为讨论的重点是我们对不依赖插件(至少是不依赖第三方插件)来制作游戏的看法。我分享了自己的观点,并结合我正在参与的一个项目讲述了一段相关经历。

无论如何,你说得对,我的表述可能夸大了引擎本身的功能。RPG Maker 在允许用户实现的功能上非常严格,毕竟如果不够严格,大多数初学者可能会感到无从下手。我只是想说,如果你清楚自己在做什么,那么你可以实现很多超出大多数人预期的功能。

5 个赞

你的话并没有夸大引擎的能力。引擎确实非常灵活。不灵活的是编辑器。不过正如你所说,这可能也有其合理的原因。

2 个赞