Project1

标题: 老鹰的RGSS3学习历程 [打印本页]
作者: 百里_飞柳    时间: 2020-9-22 22:07
标题: 老鹰的RGSS3学习历程
本帖最后由 百里_飞柳 于 2020-9-23 09:19 编辑

老鹰的RGSS3学习历程


自从我2014年发布了第一个短篇游戏《夜之章》，都过去6年了，感觉时间飞快，
周围一个个都已经成功变身大触，没变成的也拖成了前辈，而我依然是又菜又懒的模样。

这天在不经意之间又翻到了几年前自己写的与RM相遇的回忆文——“【个人总结】老鹰与RM的一路走来~”，
看完一遍后不禁害怕自己的安利属性，通篇下来一万个链接，全是各种安利hhhhh

为了保持良好习惯，悦己利人，所以我又来写一篇回忆文卖安利了！（x

题外话：感觉自己的文风完全变了，不再是以前纯真的我了呜呜呜


前言

本文大概会从我最开始使用RM进行创作写起，
之后按照时间顺序依次讲述我是如何学习RPG Maker Vx Ace的默认脚本框架RGSS3，
最后依然会是熟悉的卖安利环节。

由于这个脚本学习的回忆录可能不会有之前那一篇来得有趣，我会尽量结合我自己的一些游戏坑中的设计实现来写。

1 初入手

RM最初能够活下来，我敢肯定“事件”功能独揽一大半功劳。
对于基础RPG类型游戏的创作，默认事件页涵盖了从变量处理、对话、移动、战斗等几乎全部的不可缺少的功能，
结合通俗简洁的指令界面，能够让任何人快速上手，并立刻制作出以自己角色为中心的剧情演出。

但是小白化的代价就是几乎没有任何扩展性，对于稍微复杂一点的逻辑，写起来异常艰辛，事后如果要修改，更是灾难级的体验。


图为我自己的追逐战练习中的事件

为了制作跨地图的追逐战，每个地图的出入口都要放置一个敌人事件，同时利用开关决定该敌人是否需要被激活显示……
不过如果自己真的尝试制作过类似的，虽然非常麻烦，后续也不可能得到优化，但总会让自己的事件编写能力得到提升的。


图为我同期制作的事件ARPG中的敌人处理

可以看到，在该事件中甚至只能处理箭矢事件与某一个指定的敌人事件的碰撞，如果同一张地图上有多个敌人事件，这个事件的复杂程度将会直线上升，而且日后要修改什么的话更是让人原地去世。
那时每天逛论坛，总能看到大佬们发布各种有趣的插件或是各种插件的整合“【VA】超级脚本整合+说明（诈尸补个新链接）”，甚至是由于专门的脚本整合大赛的获奖作品（然后各种违反某些脚本的利用规约），于是我下载了十多个这类工程，一个个脚本去尝试使用，哪怕根本不可能用到，也会乐此不疲地玩（x
同时我还抱着制作传统JRPG的念头，又看到了这样一个讲解VA的技能公式的帖子”我跟你讲，VA的计算公式，赞！通过公式实现一些功能“，已经冒出了”居然可以这样写“，”这样方便的设置也可以吗？“的念头（后话：当然这样写扩展是非常危险的，不仅因为报错位置会让人分不清，更是因为技能公式有时会被反复调用，需要比较好的高层设计，才能不出现奇怪伤害）。


图为来自帖子里的经典防御减伤公式


2 趣味摸索

之后，事件脚本进入了我眼中：“【推广向】这个世界将是我们事件脚本流的天下！RMVA小脚本”。

由于直接打开脚本编辑器总让人畏惧，看到那一排排整齐划一的字母，总觉得自己稍微的一点修改都是一种亵渎，
但是好色哦打破那样的整齐使它们变得凌乱（打住）。

但是事件脚本就不一样了！排在事件最后一个指令的脚本，打开后就是一个朴素的小框，
里面直接就能编写将会被运行的脚本，是完全属于自己的空间呢（低语）。

可以说，事件脚本就是一个非常好的摸索用的地方，
至少对于只会F1里讲解的基础脚本知识的人来说，能够对这一段脚本到底什么时候执行了如指掌：
触发这个事件，执行到这个事件脚本指令，才会生效。
而孜孜不倦的实验，才是日后熟练掌握的基石。

但注意，不是为了加入事件脚本而使用事件脚本，我觉得这一点必须先确定，
因为使用事件脚本是为了节约事件指令的编写，不能只纠结事件脚本怎么写而直接放弃使用基础的事件指令。
由于事件脚本中一般会被用到的都是一些常用的全局变量，所以我觉得当你用得足够多时，自然就能摸索出一些规律。

比如事件脚本：打开1号开关
  1. $game_switches[1] = true
复制代码

和事件脚本：获得1号变量的值
  1. $game_variables[1]
复制代码

这是两句非常简单的指令，但是我们可以在它的基础上扩展，使得它成为一句无法用默认事件写出来的指令：
打开1号变量对应值的开关
  1. $game_switches[ $game_variables[1] ] = true
复制代码

事件脚本给事件增添了更多的可能性，极大简化了一些操作。
当然，也要求作者自己稍微了解一些Ruby知识（至少F1中的Ruby介绍要全部看过），比如知道
  1. []
复制代码
符号代表是获取数组中的某个元素。

由于我自己是计算机专业的，在大学期间系统性学习过C语言和C++语言，
因此一开始入手Ruby时，惊觉竟然有这么方便的编程语言，弱变量类型、动态运行、万物皆对象。

编程的核心是逻辑思想，因为大部分的程序都是单线进行的，也就是从头一条条执行到尾部，
RM游戏更是依靠一个无限循环，在每一帧更新并刷新画面。



图为《日落归》中选择无毒的酒的谜题，其中在公共事件中利用事件脚本将酒瓶所在事件的独立开关A打开，这是由于玩家可以触发的事件是椅子，但显示酒瓶的事件是相邻ID的事件。利用这个策略，我将4个事件的内容整合成了1个公共事件。（好吧其实根本没啥必要，毕竟这也就4个事件hhhhh）


3 构思设计

如果一直想着怎么去用“高大上”的事件脚本，却忽略了基本的事件逻辑，最终必然导致两头不讨好。

事件脚本的引入，可以说拓宽了我的思路。
之后在制作一些事件功能时，我不再从事件已有功能出发，而是先设计好一个大致目标，再一步步去想该怎么实现。
比如最为经典的事件标题，其本质是利用事件的自动执行与指令循环，去处理玩家的按键和图片的显示移动，
具体的一些特效，需要并行的事件去处理，
而更具体的一些功能，就需要结合事件脚本去执行（比如开始新游戏）


图为《谎言之屋》一周目无存档时的标题事件



图为真结局通关后、重新开启以进行新游戏介绍图片的标题事件

之前我也分享过一个简单的事件标题样例，如果有感兴趣的人，可以自己去试一试。

但是事件脚本框总是有大小的限制，如果一次性写的东西太多没法放下呢？
而且事件脚本框之间也只能通过全局变量来传递数据，有时的确也不方便。

在简单的学习和了解后，知道了事件脚本是在 Game_Interpreter类 的 command_355 方法中被解析的。
既然如此，那写在了 Game_Interpreter类里的方法肯定就能够被当做事件脚本调用。


图为《映月奏》中处理BGM切换的事件脚本，由于默认的在地图属性中设置BGM总有些许不便，而且有时不需要BGM反复播放，因此我全部统一放到了事件中处理。



图为《映月奏》中处理结局LOGO显示的部分，由于结局logo由两张图片构成，一张背景，一张文字，为了减少一点事件的编写，便统一放在了事件脚本中。

可以看出此时大部分使用的都是一些事件指令所对应的原始脚本，
由于事件指令需要一条条去设置，且修改时又必须一条条去修改，
（想起我之前编写《谎言之屋》的对话时，里面的全部立绘都是显示图片啊啊啊啊啊），
珍爱生命，真的要学一点方便的东西Orz

4 进一步探究

在基本能够熟练将事件指令运用到自己的事件UI上、将事件指令打包变成事件脚本后，我自然就开始尝试写自己的脚本了。
其实这真的是很顺其自然的发展，毕竟默认的窗口总是有点呆板或者冗余，
而默认的注释也非常清晰直观，除了类的继承会拦住妄图想一步跳到修改脚本的人，的确没有什么特别难的地方。

首先，我并没有去理更深层次的脚本原理，那些都还比较难，
最简单的，其实就在F1帮助手册-脚本入门-实践篇-改造Timer，也就是对默认的计时器的修改。

由于计时器是一个几乎完全独立于其他任何东西的模块，
它有自己的数据类Game_Timer，也有自己的显示类Sprite_Timer，
如果能在F1中的介绍下完全掌握这两个，同时理解类的继承到底是怎么一回事，比如Sprite_Timer就继承自 Sprite，
那就可以说是已经踏入门内了。


图为《Fidelis/Tilting the Balance》中对计时器的扩展，使其变成一组各自独立的计时器，且每个都能绑定一个开关，还能有自定义的背景图片。这个插件已经被重写为 计时器扩展 。

在这段时期，我继续熟悉掌握Ruby的奇妙用法，同时也会尝试写一些自己的继承自默认窗口、精灵的东西。
而在编写自己的Scene的时候，我直观感受到了RGSS的基本运行逻辑，
即执行当前Scene的main方法，其中更是在不切换Scene时不断循环执行当前Scene的update方法。
每一次调用update，都会调用udpate_basic，
也就会刷新当前游戏画面Graphics.update、刷新按键状态Input.update。

5 更大的空间

于是最后，我终于对默认的大框架下手了hhhhh
由于之前的填坑也创作出了非常多的可独立的脚本，我将部分挑了出来并进行开源分享，构成了我自己的代码仓库：


同时，我也专心致志编写了一个大型插件：对话框扩展。
由于之前每次开坑都要改一遍yami的pop message，实在是太令人难过了，
于是我直接把我想要的东西都丢到了转义符里面，然后逐渐扩展、功能逐渐增加，最终成为了一个大体量的对话框插件。

而在填《弱水愿》时，我再次回归初心，尝试了地图上的事件ARPG的制作，
最近也在编写一套属于自己的，专门扩展于事件脚本的简易事件ARPG系统。


图为《弱水愿》中的寻常小怪事件，其中使用了 事件消息机制 来执行事件页中的指定指令


后记

唔，果然写得很枯燥无味嘛，明明在这么长久的学习过程中，有很多有意思的地方呢。
比如⑨姐姐之前的事件帖子：歪门邪道事件心得[1]：为什么我的事件标题手感不好、歪门邪道事件心得[2]：文字格式与魔法 ，
就都是很有意思的细节。

通过逐步学习、深入了解RGSS3，越来越多以前的谜团都能得到解释，
同时也愈发感慨麻雀虽小五脏俱全，
一个简单的2D的RPG游戏就已经需要这么多的精妙处理，对于3D的游戏，那需要考虑的就更加多了。


最后，感谢RM作为这样一个精巧、简单又不简陋的玩具，陪我度过了一个又一个奇思妙想的夜晚！
虽然以前是熬夜写剧本，现在是熬夜写插件hhh


谨以此贴献给所有造梦人！
作者: 涅炎    时间: 2020-9-22 22:21
以后变成熬夜写教程。
作者: 坏数据    时间: 2020-9-23 00:06
看了一遍又一遍 包括里面链接的帖子
竟一时语塞 不知道该说什么好

更像是玩rm的心路历程
除了期待下一部作品还能干嘛呢

那期待下一部作品就完事了！
作者: congwsbn    时间: 2020-9-23 04:11
什么，老鹰纯真过？
作者: BCJT    时间: 2020-9-23 08:49
老鹰的粉丝之一
脚本特点非常地可靠，实用。
感谢默默无闻的大神们。
作者: 世界第一中二    时间: 2020-9-23 16:28
是鹰大，tql
作者: W.Q.C.    时间: 2020-9-23 21:58
老鹰，强，期待老鹰下一个坑！不会脚本的我默默留下泪水
作者: fux2    时间: 2020-9-23 22:09
老鹰光一个对话框都比我10个游戏还强了
作者: 火锅深处    时间: 2020-9-24 16:49
对话框脚本的功能酷炫到就算出现兼容问题也还是很难割舍，真是罪孽深重的脚本（
咳，但仍然是我觉得最好用的气泡对话框。



欢迎光临 Project1 (https://rpg.blue/) Powered by Discuz! X3.1