Game_SelfSwitches :
用途：用Hash表（可以理解为特殊的数组）形式保存地图中所有事件的独立开关的值。
实例：$game_self_switches 游戏开始前产生的唯一一个实例。
属性、方法省略
心得：与Game_Switches的形式上基本相同，不过调用的关键字是由[地图ID，事件ID，事件独立开关值]这样的数组组成的，而Game_Switches的关键字则是自然数。
要想在自定义脚本中直接设定某个独立开关会有点麻烦，因为必须先在事件中设定过独立开关操作才能让该独立开关生效。
调用方法的例子（请先确定存在该事件独立开关的操作）：
key = [1, 5, "A"]
$game_self_switches[key] = true
（打开地图编号001中的事件编号005的独立开关A。）
修改：没研究出突破事件的独立开关数量上限的方法，即使研究出来，事件页也无法调用(条件页的下拉框只支持4个独立开关)。其它也没什么好修改的。
Game_Screen :
用途：使某个视口的画面发生变化（视口viewport，通常viewport数字越大显示在越前面，不同viewport显示的东西互不干扰，类似于层的概念），这些变化包括（色调渐变、画面闪烁、画面震动、图片更新）。
实例：$game_screen 游戏开始前产生的唯一一个实例。该实例在两个主要场景：地图场景和战斗场景更新时同时更新。
属性：
共6个，都是只读属性
tone：色调改变，对应地图场景和战斗场景的viewport1
flash_color：闪烁颜色，对应地图场景viewport3，战斗场景的viewport4
shake：震动的中心点横坐标，对应地图场景和战斗场景的viewport1
pictures：图片集，对应地图场景viewport2，战斗场景的viewport3
weather_type：天气类型（0：无，1：雨，2：风，3：雪）对应地图场景和战斗场景的viewport1
weather_max：表示天气效果图像的数量，对应地图场景和战斗场景的viewport1
方法：
start_tone_change：开始更改色调，记录需要改变成的色调和持续的时间，赋给类的内部变量，Game_Screen每次经过Update方法更新后都会根据这些内部变量算出新的tone。Tone是RGSS的内部负责纪录色调的类，和同样属于RGSS内部的Color类很象，前三个属性分别是红、绿、蓝，第四个属性Tone是灰度，Color则是alpha透明度。
start_flash：开始画面闪烁，记录要闪烁的颜色和持续的时间，同上，Game_Screen更新后计算新的颜色。闪烁是在最高视口显示的效果，可以起到遮盖所有其他图片的效果。所谓闪烁是通过依次改变颜色的透明度来实现的，所以强度为0的闪烁等于不闪烁。
start_shake：开始震动，记录震动的强度，速度和持续的时间，同上，Game_Screen更新后计算画面新的原点坐标。所谓震动就是通过改变画面的原点横坐标使画面左右晃动。由于震动是在最底层viewport1进行，所以如果有天气效果图像的话，也会跟着一起震动。
weather：设置天候，记录天候的类型，强度和到达指定强度的时间，这和上面三个略有不同，因为气候一旦启动在该场景会一直保持下去，直到重新设定气候为止，所以这里的时间是指到达指定强度的时间。Game_Screen更新后计算的是表示天气效果图像的数量，该数量根据指定的时间逐渐增加，一直到指定强度。RMXP最多同时显示40个表示天气效果的图像，最少是8个。这个在游戏内部就限定死了，无法修改。
update：更新，Game_Screen最主要的方法了。主要是根据当前的内部属性来计算以上画面发生各种变化所需要的数值，同时对图片集进行更新。关于图片集会在下个类Game_Picture里面讲到，这边就不多说了。唯一需要说明的是地图场景和战斗场景各自最多只能同时设定50个图片。
心得：Game_Screen主要是用来保存和计算画面变化的数据。(废话，注释好像就是这么写的)，具体算法在update里面，心得都在上面的方法里面讲了。
修改：色调、闪烁、天候好像没什么可改的，唯一可改的是震动，如果哪位觉得RMXP自定义的震动强度不够（请表有不好的联想... ...）可以改，不过改的地方不在这，改地图震动的话在Spriteset_Map的149行，@viewport1.ox = $game_screen.shake，后面乘上个数字就能使震动幅度增加。战斗震动在Spriteset_Battle的124行。喜欢上下震的将ox改成oy，喜欢斜着震的就把ox，oy都加上，什么，还有喜欢上下左右绕着圈子震的？，自己研究吧，我的眼睛已经震花了。
Game_Picture：
使某个图片发生变化，这些变化包括（图片显示、图片消除、图片移动，图片缩放、图片旋转、透明度变更、色调变化、合成方式变化）。
实例：$game_screen创建的时候在$game_screen内部创建@pictures的属性，该属性是一个数组，里面存放了100个Game_Picture的实例。
属性：
11个只读属性看注释就可以明白。
方法：
和Game_Screen的性质类似，通过接受外部参数来设定内部属性，同时在update更新的时候计算新的内部属性。
show：记录图片的初始数据，主要是图片名字（name）的设定。初始化涉及以下动作的内部属性为不发生变化时的值（变化时间、移动、缩放、透明、色调、合成、旋转）。
move：记录图片移动（含移动、缩放、透明、合成）的数据。
rotate：记录图片旋转速度
start_tone_change：记录需要改变成的色调和持续的时间。
erase：将图片名字设为空白字符串。Sprite_Picture会根据名字的变化更换使用的位图，空白文件名则设为不可见。
update：根据当前的内部属性来计算图片发生各种变化所需要的新的内部属性。除了合成方式之外，其他图片变化都需要计算。
心得：这里除了update，其他方法都是在事件解释器里用的，事实上RMXP在游戏一开始就准备了100个空的Sprite，用来显示图片，50张用于地图场景，50张用于战斗场景。因为只有通过Sprite（精灵）才能让RMXP在屏幕上描绘出图形来，所以真正操作图片是在Sprite_Picture这个类里面。Game_Picture所做的只是设定图片的各种属性。
修改：如果要制作射击类或动作类图片要求比较高的游戏的话，这里在算法上可以做一些改变，另外RMXP对图片的释放也做的不是理想。想要更先进点的话（比如缓存常用图片）修改的地方也不是在这里，就先不讲了。
RGSS脚本研究报告是自己一边研究RGSS脚本一边整理的类似于笔记又类似于说明的东西，本文并不适合没接触过程序或对面向对象完全没有概念的人。如果觉得这些东西对你有帮助我很高兴，请多给我点鼓励让我继续写下去。但请不要任意转载，本人保留本文及其系列的所有版权。
|
