赞 | 0 |
VIP | 186 |
好人卡 | 0 |
积分 | 1 |
经验 | 5829 |
最后登录 | 2012-12-21 |
在线时间 | 83 小时 |
Lv1.梦旅人 龙皇
- 梦石
- 0
- 星屑
- 50
- 在线时间
- 83 小时
- 注册时间
- 2007-8-8
- 帖子
- 2956
|
加入我们,或者,欢迎回来。
您需要 登录 才可以下载或查看,没有帐号?注册会员
x
本帖最后由 TERENCE 于 2009-8-26 01:18 编辑
原始帖:
http://rpg.blue/viewthread.php?tid=131958
◎前言
要写著个教程其实不太容易,虽然没比我曾写过的变身系统复杂
因為如果依照我以前图文流程教程习惯的方法,要解释到有点难诠释......
另最主要的原因不像之前有单一的流程,
这次纯事件製作分成两大核心:主公共事件与子公共事件,
请耐心把教程读完就可以懂得加以利用及改造
◎效果
随机出现五个方向,要在特定的时间内按完五个方向。
不管是应变能力的小游戏or类似KOF 的操作以及ARPG等等利用
这种思路还能继续扩展且用途很广,不见得只有五个方向或一定要随机
本教程是依照原始帖本范例的流程而写。
◎流程图
第一次搬出很论文的东西(= =),不过也是我的心血,
但看完这个图,对於连续性按键组合操作的解析也可以有具体的了解。
以下教学请配合该图......
◎流程解析
一、首先从流程图左上方的初始化设定来看
基本上就是初始化一些计时器、速度、最大时限等等
(这裡建议加上失败开关初始化成OFF)
下面的公共事件,就是待会要交代的部份
(等待是必须的,否则事件中的图片不容易生成显现出来)
二、随机生成五个方向值
对於类似KOF 的操作,大可以不必有随机生成,
如果有自己特定的组合键,这个流程可以省略
生成时间槽图片应该比较属於初始化设定的流程,
这裡我必须给定键值,例如像我在这裡就是...
上=>0 下=>1 左=>2 右=>3
然后根据值 显示对应的图片
并记得要带入变数中储存
依此类推,就可以得到五个变数的键值
三、子事件的流程(按下键值处理)
我们可以看到流程图中,到子事件处理是虚线......
那是代表该子事件是同一个可重复使用的独立公共事件
就像function(函式/方法)一样
绿色的部份(--请注意教程の思路疑惑解析的部份)
就是流程图Trigger按键前缘触发的条件判断与根据所暗的键
带入按下键值这个变量之中的部份
综色的部份(--请注意教程の思路疑惑解析的部份)
流程图Input.update(更新输入信息)与累计计时器的部份- a = $game_variables[9]
- b = $game_variables[10]/100
- $game_screen.pictures[7].show("TimeBar(2)",0,0,50,a/b,100,255,0)
- @wait_count = 1
复制代码 这个部份专门是為时间条做的设计
变数($game_variables)9号跟10号分别就是计时器、最大时限
而a/b就类似是X方向放大率的百分比
不断循环(刷新)的结果就是可以看到时间条在时间槽裡在跑
@wait_count = 1就是等待一禎的画格,使时间条有一禎的时间生成
P.S.- # name : 文件名
- # origin : 原点
- # x : X 坐标
- # y : Y 坐标
- # zoom_x : X 方向放大率
- # zoom_y : Y 方向放大率
- # opacity : 不透明度
- # blend_type : 合成方式
- 显示图片
- $game_screen.pictures[number].show(name, origin, x, y, zoom_x, zoom_y, opacity, blend_type)
复制代码 红色的部份
流程图子事件的计时器是否达到最大时限条件判断的部份
四、主事件的流程(按键处理)
按下键值的公共事件就是子事件
紫色的部份
流程图主事件的计时器是否达到最大时限条件判断的部份
这裡建议加上刚刚提起的失败开关,使之為ON
这个开关可以判断你是否失败
绿色的部份
流程图的按下键值与预订(乱数)键值是否相同条件判断的部份
红色的部份
方向正确图片变色等处理的部份
综色的部份
这裡也建议加上刚刚提起的失败开关,使之為ON
这个开关可以判断你是否失败
依此类推,五个键值的操作流程
五、按键结束处理
这裡就不用教了吧,全程最简单的地方
◎思路细节疑惑解析(有疑惑再看,否则这裡文字颇多)
一、子事件Trigger按键前缘触发的条件判断思路疑惑
Q:
在子事件(按下键值)的处理中有这麼几段Input.trigger?的条件判断
為什麼不使用一般事件中的按钮条件判断??
ANS:
在这裡必须先解释Input.trigger?与Input.press?的差别
其实事件中的按钮条件判断就是Input.press?
由上图可以看到
Input.trigger?是只有在按键按下去的瞬间才会回传TRUE
这就是所谓的前缘触发
想下一下,程式执行事件的速度是非常的狠快
如果你使用了Input.press?来判断,虽然这时本判断执行是没问题的
但在下一个执行按键判断的时候,你所按的键是不可能放开的,
这时你的逻辑就是错误了
甚至你以為只按了一下,其实五个键值判断早已经跑完了
换句话说
『程式执行的速度,远大於人类的反应速度』
所以这裡才使用按键前缘触发的条件判断
防止下一个执行按键判断直接通过跳出子事件的循环
二、子事件时间条事件脚本中的@wait_count与Input.update的思路疑惑
Q:
有仔细看完以上教学的同学可能会问两个问题
@wait_count就相当於等待的效果,為啥不直接使用事件本身有的就好??
这时候為什麼要调用Input.update(更新输入信息)??
ANS:
这两个问题其实也困扰了许久,
但是如果用了事件本身有的等待或不使用Input.update
流程就会卡死在这(按键反应不是特别灵敏)
不使用@wait_count等待的话时间条图片生成会来不及
以下是我的见解(有错的话,希望高人指导纠正)
使用Input.update的原因是
在执行事件时(尤其是循环),单靠Scene_Map脚本中的Input.update
没办法即时更新输入讯息,所以这裡才要强迫更新输入讯息
在时间条事件脚本中可以看成单一个事件的执行
而@wait_count与事件本身有的等待还是有所差别
如果使用了事件本身有的等待,
会造成子事件Input.trigger?判断延迟(按键反应不是特别灵敏)
三、使用了两个判断计时器是否达到最大时限条件的思路疑惑
Q:
有仔细观察思考流程图的人,可能会问.....
為什麼用了两个判断计时器是否达到最大时限条件?
為什麼子事件的该判断(TRUE)不直接到按键结束的地方?
这样不是就执行同样的东西两次了吗??
ANS:
切记~~事件执行是流水式的,子事件跟按键结束处理是各别独立出来的
一旦子事件的该判断(TRUE)直接到按键结束的地方,执行结束....
会回到主事件继续执行下去,
使用中断事件处理也只是中断独立的公共事件
◎工程范例
原始帖就有,请自行去那下载
6R RM附件现在又有问题....= =
压缩文件损坏修复方法:
http://rpg.blue/viewthread.php?tid=130263
http://rpg.blue/viewthread.php?tid=130261 |
|