RM系统设计的一般方法
前言：本教程不提供具体脚本内容，并且只有理论一没图二没具体脚本。只提供对于任何系统都应该具有的泛用思路，如同标题，理论上所有系统设计都能按照这个方法做下来，但具体的细分就需要自己思考和分析了。一：准备
首先，在系统设计之前需要准备一些纸和一支笔。
在初期设定的时候，可以先把需要使用的界面规划好，需要使用的流程规划好。这个步骤实际上是为了正式制作的时候发现在对应位置没有对应的地方安置界面/流程而准备的。如果缺少了这个步骤，可能会发生的：“纳尼这个窗口塞不进去了！要把之前做的图整个重做一遍啊！！！”“之前在哪儿缺了一步来着这东西前面该有的东西没有啊！”“我擦这个效果不对啊！”。
规划好需要使用的所有界面，流程后，便可以开始脚本的实际编辑了。
二、界面
根据在准备的时候确定的需要使用的窗口，制作所有在系统中需要使用的窗口，并为各个窗口定义好实际应当使用的变量以及相关需要使用的东西，另外就是可以善用现有的窗口（比如把里面的内容改掉就可以干很多事情了，比如有些功能比如最基本的选择框有自带的可活用的窗口）。在此之后，请把所有窗口应当在的坐标准备好，并制作需要的图片。（当然你要先做图再写窗口脚本也没关系的，只要你不怕计算错坐标。）
三、主框架
主框架应当包括：
1.数据，界面的图片，窗口的载入
2.主体循环
3.释放之前载入的东西
这个主体框架可借鉴现有的场景类脚本。其实，真正关键而且有用的，是主体循环部分啊……
四、主体循环
主体循环基本上是通过定义方法，然后再从这个方法分步分歧通过更多的脚本完成的，比如现有的脚本大多在循环节里面只调用了一个方法，然后再把所有需要处理的内容通过该方法处理，这个便是核心的效果处理。此时可以把最开始确定的流程按部就班地写成方法，然后根据需要的条件分歧和合适的顺序依次处理，便可达成效果。
五、效果处理的分节
在流程处理的过程中，有些较长而常被调用的过程可以通过定义新方法的方式解决，当然因为这个方式导致在不合适的时候引用方法而跳出什么BUG的话还请自己重新拆分。
过于复杂的系统可以通过分解为脚本列表中的，类名称相同的多个脚本来便于查询BUG位置，具体拆分方式可以根据脚本行数来确定，也可以通过方法内容的相关度来确定。
六、优化与BUG处理
仔细确认系统中所有引入的变量与单位的引入（定义）和消除的相对位置，确保在退出该系统之后能释放之前占用的所有内存，虽然就RM游戏而言一个变量，一个单位占用的内存极小……并且保证所有变量，单位在具体使用前已经经过引用，所有使用过的方法均已经定义。
七、最终处理
通过实际运行观看最终效果，并进行合适的微调。根据心情，必要性的问题爱分享可以分享，给私人的也可以给私人，自己留着一个人用也没人会怪你。
艾玛，黑猫的教程还是？ 最爱南宫煌 发表于 2013-9-20 23:20 static/image/common/back.gif
艾玛，黑猫的教程还是？
恩 是他的教程 他想申精来着 没脚本，，，，看不懂 看到这个……
稍微有点想拓展一下这个呢……
虽然可能也没人会需要看了吧 更一发呗，你不是想申精吗 虽然很想说如果明天有空明天就更明天没空就下周更了
不过我想果然下下周才会开始考虑怎么写这个的可能性更大呢 BlackFeather 发表于 2017-11-3 12:17 static/image/common/back.gif
虽然很想说如果明天有空明天就更明天没空就下周更了
不过我想果然下下周才会开始考虑怎么写这个的可能性 ...
话说论坛里就咱俩人，跟过家家似的，你发的主题我都回，我发的你能不能回一下，没人回我我很尴尬 最爱南宫煌 发表于 2017-11-3 12:48 static/image/common/back.gif
话说论坛里就咱俩人，跟过家家似的，你发的主题我都回，我发的你能不能回一下，没人回我我很尴尬
问题是不见得我都能想出回什么好啊 BlackFeather 发表于 2017-11-3 14:05 static/image/common/back.gif
问题是不见得我都能想出回什么好啊
“好顶赞”
“啊南瓜真棒”
“我去，几分钟不见你又变帅了”