スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ゲーム制作日記<54> デフォルト計算式

みなさん、こんばんは。
ネコタです。


最近、ご無沙汰していますが、細々とツクツクしております。
とは言っても、いろんなものが中途半端ですけどね(笑)

さて、中途半端とはいえ、いろんなものが出来てきたので、そろそろ戦闘関連にメスを入れ始めようかと思いました。


今、デフォルト素材だけで作るプロジェクトを進めているのですが、戦闘もデフォルト計算式にこだわりたい。

ということで、ダメージの計算式は、デフォルトの式である

a.ATK*4-b.DEF*2

に決定。この計算式は、凄くシンプルで分かりやすい。
けど、シンプル故に、ユーザーは割といじりたがる(笑)


今回は、このデフォルト計算式のお話をしようかと思います。



■ツクールMVデフォルト計算式


RPGツクールMVの基本ダメージ計算式は、先ほど示した通り。

a.ATK*4 - b.DEF*2


さて、まずはこの計算式の意味ですが、とっても単純な構造をしています。

・ユーザーの攻撃力が1上がる→ダメ―ジは4増える。

・対象の防御力が1上がる→ダメージは2減る。


これだけ。

ダメージを完璧に相殺するには、相手の攻撃力に対して2倍の防御力があれば良い計算になります。

分かりやすいですね。



しかし、戦闘の計算は、これで完結するわけではありません。
ダメージの処理には、他にもいくつかの処理が関わっているんですね。

それらをちゃんと把握していないと、上手いゲームバランスを組み立てることが難しいんです。


では、他にどんな処理があるのか見てみましょう。

・命中判定と回避判定(命中率)
・会心率(クリティカルによるダメージUP)
・バフ・デバフによる強化・弱体化
・分散(ダメージのブレ幅)


これらの処理が、どのように行われているか、ご存知でしょうか?

実は、デフォルト戦闘の設計には、これらが固定で設定されています。

順番に見ていきましょう。


命中率
攻撃の命中判定は、命中率による命中判定の後に、回避率による回避判定を行います。

具体的には、ユーザーの命中率95%、ターゲットの回避率5%とした場合、

命中判定:95%の確率で命中
回避判定:(100%-5%)で命中


命中率による命中判定を先に処理しますので、まずは、命中率を計算します。

命中率①:100%×95%=95%

このフィルターを通ったものに対して、さらに回避判定による命中率計算を行います。

命中率②:95%×(100%-5%)=0.95*0.95=0.9025

したがって、トータルした命中率は、90.25%の命中率となるわけですね。

命中率と回避率は、職業や敵キャラで設定されているので、その数値を変更すれば良いのですが、この計算式自体は固定となります。

※参照するのは、ユーザーの命中率と対象の回避率の組み合わせとなります。


簡略化したいときは、回避率を削除するいか、命中率を100%にすればどちらか一方だけの計算となるため、分かりやすくなります。


会心の一撃
固定で3倍のダメージです。変更するためには、スクリプトを弄るかプラグインの導入が必要となります。


バフ、デバフについて
バフ・デバフによる数値変化は1段階につき25%です。そして、2段階までとなっています。

1段階バフ・デバフをかけると、数値が25%増減して計算されます。

この幅や重ねがけの回数を変更するためには、スクリプトを弄るか、プラグインの導入が必要となります。


分散
ダメージの幅です。

たとえば、分散20%、ダメージ計算の結果が100の場合、実際のダメージは100から前後20%(80~120)の値になります。


以上が、戦闘に関わる固定設定です。


あとは、防御しているかどうかもありますが、これは防御状態の時に応じて最終ダメージに50%を掛け算したりします。


で、これらの仕様が分かるとですね。

実際にテストプレイをしなくても、Excelなどの表計算ソフトを利用してシミュレートすることが出来ます。

計算に必要な設定項目は、以下の通りです。

・a.ATK(スキル使用者の攻撃力)
・b.DEF(ターゲットの防御力)
・命中率(ユーザー)
・回避率(ターゲット)
・分散
・会心率
・バフ・デバフ効果(25%)


これらを使うと、ダメージの期待値を割り出すことが出来ます。



■期待値計算


まずは、期待値が何なのかというと、

ここで言う期待値とは「無限回数この計算式で攻撃した場合において、ミス(0ダメージ)やクリティカル(3倍ダメージ)も含む、毎回の平均ダメージ」を言います。

期待値の数式的な定義ですが、

(数値*発生確率)の総和

です。理屈は簡単ですね。

これを計算できると、実際にテストをしなくても、計算だけでおおよその戦闘の経過をシミュレートでき、実際に組んでから数回テストするだけで済みます。

なので、計算できるようになっておくとすごく便利。


で、さっそく期待値を出したいんですが。

これを出すために、まずは各攻撃の発生確率を調べなければなりません。


各攻撃って何かというと、

・通常のヒットした時(1倍ダメージ)
・攻撃がミスした時(0ダメージ)
・クリティカルヒットした時(3倍ダメージ)


この3つですね。それぞれが、どのくらいの確率で発生するかを考えていきます。



●攻撃がミスした時

まず、攻撃がミスした時を考えてみましょう。

攻撃がミスする場合というのは、命中判定で命中しなかった場合を考えます。

即ち、先ほど出した命中率を全体から引いた値ですね。

全体は100%で、トータル命中率は90.25%でしたね。


ミス発生率:100%-90.25%=9.75%


よって、9.75%の確率で0ダメージとなります。



●クリティカルヒットの時

次に、クリティカルヒットの時の発生確率を出してみましょう。

クリティカルヒットは、攻撃が命中した場合に、会心率の確率で発生します。

会心率は、デフォルトだと4%に設定されているので、これで計算してみましょう。


まずは、攻撃が命中する確率ですが、


命中率:90.25%


これに対して、会心率は4%ですので、


会心発生率:90.25%*4%=3.61%


よって、この攻撃をしたときの会心発生率は3.61%の確率となります。



●通常の攻撃ヒット時

さて、通常のヒット時について発生率を考えてみましょう。

これは、ミスでもクリティカルでもないときには通常のヒットとなりますから、全体から今までのものを差し引くことで計算できます。

全体の確率は100%、ミスは9.75%、クリティカルは3.61%ですので、


100%-9.75%-3.61%=86.64%


すなわち、通常のヒットは86.64%の確率で発生することが分かりました。



さて、以上でそれぞれの発生率が分かりましたので、下に一旦まとめておきましょう。

・通常ヒット:86.64%
・ミス:9.75%
・クリティカルヒット:3.61%



それでは、いよいよ期待値の計算です。

今回は、a.atk=120、b.def=80として計算します。

まず、デフォルトのダメージ計算式からダメージを計算します。


 a.ATK*4-b.DEF*2=120*4-80*2
=480-160
=320


次に、それぞれ通常ヒット時、ミス時、クリティカルヒット時の倍率を掛け算します。


・通常ヒット時:320*1=320
・ミス時:320*0=0
・クリティカルヒット時:320*3=960


そして、それぞれに発生確率を掛け算します。


・通常ヒット時:320*0.8664=277.248
・ミス時:0*0.0975=0
・クリティカルヒット時:960*0.0361=34.656


最後にこれらを全て足し算します。


277.248+0+34.656=311.904
≒312


よって、期待値は312ダメージとなります。


●期待値計算結果

RPGツクールMVのデフォルト計算式である、下記計算式

a.ATK*4-b.DEF*2

について、

命中率:95%
回避率:5%
会心率:4%
a.atk:120
b.def:80

上記の条件において攻撃を行った場合には、平均すると

約312ダメージ

が、毎回入ると考えられます。


これを基に、例えば、1回の戦闘を平均3ターン程度としたい場合には、

312*3=936

敵のHPを936程度に設定すると、大体3ターンで倒せるということになります。


今回は1対1の戦闘を想定しましたが、このように、期待値を用いて実際の戦闘をシミュレートすることで、戦闘テストを何度も行わずに、平均的な戦闘結果を知ることが出来ます。

また、この考え方を応用すれば敵のHP・ATK・DEFの決定にも利用できます。

少し難しい話だったかもしれませんが、ぜひ試してみてくださいね。



■デフォルト計算式用サンプル


私が考えた、デフォルト計算式用の基本設定サンプルをここに提示しておきます。どうしようか迷ったら、参考にしてみてください。

ちなみに、期待値の計算結果が元の計算式になるようになっていますので、この設定にしておくと、期待値計算をしなくても数値を把握できるようになっています。


●標準型
命中率:98%
回避率:3%
会心率:3%

(トータル命中率: 約95%です)


●ギャンブル型
命中率:95%
回避率:5%
会心率:6%

(トータル命中率: 約90%です)


●安定型
命中率:99%
回避率:1%
会心率:1%

(トータル命中率: 約98%です)



■分散


スキルに分散を設定しておくと、計算結果に対してダメージの値に範囲を持たせることが出来ます。

例えば、基準となるダメージが100、分散が20%だった場合、ダメージは100±20の範囲で決定されます。

分散がどのくらいになろうとも、平均ダメージは概ね計算式の通りとなりますが、実際にダメージがばらつくとプレイヤーの印象が変わってきます。

例えば、先ほどの例の場合には、最低ダメージが80で、最高ダメージが120となりますから、設定した側からすればたった20%のつもりでも、プレイヤーからすると80と120で1.5倍ほどのブレがあるように見えるわけです。

なので、設定する分散の値によって、どのくらいの振れ幅になるのかは把握しておいた方が良いでしょう。


ざっと、一覧を載せてみますので、参考にしてみてください。
個人的にオススメは5%です。


●分散範囲一覧
分散・・・範囲 (プレイヤー視点の範囲格差)
1%・・・99%~101% (2%差)
3%・・・97%~103% (6%差)
5%・・・95%~105% (10%差)
10%・・・90%~110% (22%差)
15%・・・85%~115% (35%差)
20%・・・80%~120% (50%差)
25%・・・75%~125% (67%差)
30%・・・70%~130% (86%差)
33%・・・67%~137% (2倍差)
50%・・・50%~150% (3倍差)
60%・・・40%~160% (4倍差)
67%・・・34%~167% (5倍差)
72%・・・28%~172% (6倍差)
75%・・・25%~175% (7倍差)
78%・・・22%~178% (8倍差)
80%・・・20%~180% (9倍差)
82%・・・18%~182% (10倍差)
91%・・・9%~191% (21倍差)
94%・・・6%~194% (32倍差)
95%・・・5%~195% (39倍差)
96%・・・4%~196% (49倍差)
100%・・・0%~200% (カオス)



■バフ・デバフを考慮した能力値設定


RPGツクールMVには、ステートとは別にバフ・デバフというものがあります。

バフ:数ターンの間、能力値が上がる。1段階につき25%UPする。(最大2段階)

デバフ:数ターンの間、能力値が下がる。1段階につき25%DOWNする。(最大2段階)



バフとデバフは、それぞれ各能力値に付与することができますが、とりわけATK(MAT)やDEF(MDF)は計算式に直接かかわってくるため、この影響は無視できません。

最大で50%~150%まで変動させることが出来るので、何も考えずにバフ・デバフを付与できるようにすると、戦闘バランスが大きく崩れることになります。

そこで、バフとデバフの影響があるときの、基本ダメージ式の変化を見てみましょう。

ここでは、a.ATKとb.DEFについてのみ考えてみます。


●a.ATKを強化(バフ)

基本式: a.ATK*4-b.DEF*2

a.ATKが関わるのはa.ATK*4の部分ですね。ここがバフによって変化します。

1段階:a.ATK*4*1.25=a.ATK*5
2段階:a.ATK*4*1.5=a.ATK*6

a.ATKにバフをかけると、ダメージがa.ATKの値ずつ増えていくことになります。結構な影響力ですね。


次に、a.ATKにデバフをかける場合を見てみましょう。

●a.ATKを弱体化(デバフ)

1段階:a.ATK*4*0.75=a.ATK*3
2段階:a.ATK*4*0.5=a.ATK*2

このように、デバフをかけていくと、a.ATKの値ずつダメージが減っていきます。2段階もかかると、計算式がb.defと同じになってしまうため、値が同じ場合にはダメージが0となってしまいますね。


このことから、a.ATKはb.DEFよりも大きい値の方が良いと分かります。同じ値以下だと、デバフで完封されかねないということになりますから、慎重に導入する必要が出てくるわけですね。


次に、b.DEFに注目してみましょう。

●b.DEFを強化(バフ)

基本式: a.ATK*4-b.DEF*2

b.defが関わるのはb.DEF*2の部分ですね。ここがバフによって変化します。

1段階:b.DEF*2*1.25=b.DEF*2.5
2段階:b.DEF*2*1.5=b.DEF*3

b.DEFにバフをかけると、元数値の50%ずつダメージが減少していきます。a.ATKの時に比べて効果は小さくなりますので、実はb.DEFを操作するバフ・デバフは単純に考えるとa.ATKに対するバフ・デバフの劣化版となるんですね。


では、同様にb.DEFにデバフをかける場合を見てみましょう。


●b.DEFを弱体化(デバフ)

1段階:b.DEF*2*0.75=b.DEF*1.5
2段階:b.DEF*2*0.5=b.DEF*1

もう分かるかと思いますが、b.DEFの50%ずつ減少ダメージが減っていくので、結果として、b.DEFの50%ずつダメージが上がっていきます。





さて、ここまで見て来ると、バフとデバフが最大の効果を発揮する状況というのが、想像できてこないでしょうか。

すなわち、

・a.ATKに2段階のバフをかけ、b.DEFに2段階のデバフをかけた場合
・a.ATKに2段階のデバフをかけ、b.DEFに2段階のバフをかけた場合


この2つの状況ですね。

これらについて、確認してみましょう。

●a.ATKに2段階のバフ&b.DEFに2段階のデバフ

a.ATKに2段階バフ:a.ATK*4→a.ATK*6
b.DEFに2段階デバフ:b.DEF*2→b.DEF*1

よって、ダメージ式は、

a.ATK*6-b.DEF*1

上記のように変化して計算されます。能力値の差によって、カッチリ何倍になるという比は出せないのですが、

・a.ATK=b.DEFの場合:2.5倍
・a.ATKがb.DEFの1.5倍:2倍
・a.ATKがb.DEFの2倍:1.7倍

というように、a.ATKがb.DEFに対して大きくなっていく毎に、バフ・デバフによる効率は減っていきます。



次に、a.ATKに2段階のデバフをかけ、b.DEFに2段階のバフをかけた場合を見てみましょう。


●a.ATKに2段階のデバフ&b.DEFに2段階のバフ

a.ATKに2段階デバフ:a.ATK*4→a.ATK*2
b.DEFに2段階バフ:b.DEF*2→b.DEF*3

よって、ダメージ式は、

a.ATK*2-b.DEF*3

上記のように変化して計算されます。こうなると、a.ATKとb.DEFの関係が逆転していますので、もともとのa.ATKがb.DEFの1.5倍は無いとダメージが通らなくなってしまいますね。


よって、a.ATKはb.DEFに対して、少なくとも1.5倍よりは大きくないと、バフ・デバフだけで封殺される可能性が出てきます。


このギミックをあえて仕込むのも一興ですが、意識していないと思わぬ落とし穴となりそうな問題です。

バフ・デバフを導入する場合には、能力値についても注意しておく必要があります。



■おわり


以上、RPGツクールMVのダメージ計算式について、現時点での考察でした。


世の中には、いろんなダメージ計算式があります。

自分が扱う計算式の特徴をしっかりと理解することが、戦闘バランス調整の第一歩となります。

どの数値がどのように変化するのか。
それによって、ダメージにどの程度の変化がもたらされ、どの程度期待されるのか。

きちんと把握して、より良い戦闘バランスになるよう心がけたいものですね。


ではでは、今日はこの辺で。
ネコタでした。
スポンサーサイト

ゲーム制作日記<51> ポイントカードシステム

op.png



みなさん、こんばんは。
ネコタです。



今回も恒例の『 コモンイベントで作るちょっとしたシステム 』 のご紹介です。

が、今回はぶっちゃけコモンイベントを使っていません(笑)

ただ、内容的にはコモン化して使ってもよさそうなので、ここでご紹介させていただきます。


さて、今回紹介させていただくシステムは、
『ポイントカードシステム』です。

今時、大体のお店はポイントカードやスタンプカードってありますよね。会員になって、ある程度買い物したら割引してくれる、みたいなサービス。

平たく言うと、アレっぽいものをショップに導入します。



それでは、実際の例を見てみましょう。

tc37-001.png

現在、新しいプロジェクトを立ち上げて制作しています。

長編物を作っていて思ったんですが、開発が大変すぎる(笑)

いつ完成できるか分からない事態になっています。

子供もまだ小さくて、肝心のプラグイン作成できる妻もプロジェクトを休止していますし。

ちょっと、今のところ目途が立たなくなってきたんですね。

そこで、短編物で少し色んなことを試してから、再度作っていこうと思いました。

べ、別にエターなったわけじゃないんだからね!


ということで。

画像の武器屋は、試験的に導入してみたポイントカードシステムを入れたショップです。

tc37-002.png

まずは、普通にお買い物してみましょう。

tc37-003.png

とりあえず、お金はいっぱいあるので全部1個ずつ購入しました。
持っている数は、プラグインの設定の関係でバグってます(笑)

このブログを書こうと画像を撮っていたら、気が付きました。
そのうち、直った画像が出てきます。

tc37-004.png

で、実例紹介を続けますね。
今回、武器屋の利用が初めてですので、初回イベントが働きました。

tc37-005.png

どうやら、何か貰えるようです。

tc37-006.png

予想できていたと思いますが、ポイントカードを貰いました。
これがないと始まりませんからね。

あとは、ポイントカードのシステムについて店員さんがつらつらと説明してくれます。

とりあえず、説明を載せておきますね。

tc37-007.png

tc37-008.png

tc37-009.png

tc37-010.png


はい。説明は以上です。

今回の例では、700G以上のお支払いで1P付与され、5Pたまったら700Gキャッシュバックというシステムとなっております。

ただし、アイテムを売るとその分が買い物金額から差し引かれてしまいます。お店の利益を考えたら当然かもしれません。

tc37-011.png

とりあえず、今回の買い物では1P付与されたみたいです。


tc37-012.png

これで、お買い物終了です。



今回の例では、ポイントがたまると一部の金額をキャッシュバックというシステムにしましたが、ちょっと頑張れば割引もできます。

システムが分かれば、付与されたポイント(変数)を条件分岐にできますので。分岐先で金額を再設定したショップを開くという方法があります。が、結構面倒です。なので、やりません(笑)


それでは、挙動を確認できましたので、準備するものを確認しましょう。


【準備】
変数 ×6


はい、これだけです(笑)
単に、変数の操作でポイントと金額を計算するだけですので。


【推奨】
コモンイベント(ショップの処理)


今回は、ショップの処理をコモンイベントで作っています。
実行内容は下のような感じ。


【実行内容】
条件分岐:【req】progress ≥ 8
ショップの処理:ショートソード
ショップの処理:ロングソード
ショップの処理:ファルシオン
ショップの処理:ミスリルソード
ショップの処理:ドラゴンブレード
ショップの処理:ウッドスタッフ
ショップの処理:マジックワンド
ショップの処理:フォースワンド
ショップの処理:ミスリルロッド
ショップの処理:ドラゴンスタッフ
ショップの処理:ショートスピア
ショップの処理:ロングスピア
ショップの処理:ハルバード
ショップの処理:ミスリルスピア
ショップの処理:ドラゴンスピア
ショップの処理:ストーンフレイル
ショップの処理:ブロンズフレイル
ショップの処理:モーニングスター
ショップの処理:ミスリルフレイル
ショップの処理:ドラゴンフレイル
ラベルジャンプ:終了

分岐終了
条件分岐:【req】progress ≥ 6
ショップの処理:ショートソード
ショップの処理:ロングソード
ショップの処理:ファルシオン
ショップの処理:ミスリルソード
ショップの処理:ウッドスタッフ
ショップの処理:マジックワンド
ショップの処理:フォースワンド
ショップの処理:ミスリルロッド
ショップの処理:ショートスピア
ショップの処理:ロングスピア
ショップの処理:ハルバード
ショップの処理:ミスリルスピア
ショップの処理:ストーンフレイル
ショップの処理:ブロンズフレイル
ショップの処理:モーニングスター
ショップの処理:ミスリルフレイル
ラベルジャンプ:終了

分岐終了
条件分岐:【req】progress ≥ 4
ショップの処理:ショートソード
ショップの処理:ロングソード
ショップの処理:ファルシオン
ショップの処理:ウッドスタッフ
ショップの処理:マジックワンド
ショップの処理:フォースワンド
ショップの処理:ショートスピア
ショップの処理:ロングスピア
ショップの処理:ハルバード
ショップの処理:ストーンフレイル
ショップの処理:ブロンズフレイル
ショップの処理:モーニングスター
ラベルジャンプ:終了

分岐終了
条件分岐:【req】progress ≥ 2
ショップの処理:ショートソード
ショップの処理:ロングソード
ショップの処理:ウッドスタッフ
ショップの処理:マジックワンド
ショップの処理:ショートスピア
ショップの処理:ロングスピア
ショップの処理:ストーンフレイル
ショップの処理:ブロンズフレイル
ラベルジャンプ:終了

分岐終了
ショップの処理:ショートソード
ショップの処理:ウッドスタッフ
ショップの処理:ショートスピア
ショップの処理:ストーンフレイル
ラベル:終了


条件の【req】progressですが、これは、ゲーム上でストーリーが進行した時に増える変数です。つまり、進行度ですね。

ゲーム制作における1つの方法ですが、私は、進行度用の変数を1個作っておくようにしています。

メインのストーリーの分岐や、今回のようにショップの処理を進行度によって分岐する、といった用途で使えるので、あると便利です。イベント管理をしやすくする工夫の1つです。



それでは、ショップの準備が整いましたので、実際のイベント内容を見てみましょう。


【実行内容】
変数の操作:#0057 【Shop】stamp_moment = 0
変数の操作:#0054 【Shop】Money_b = 所持金
スイッチの操作:#0022 【req】Map21-Ev4 = ON
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「いらっしゃいませ。
文章 どうぞ見ていってください。
コモンイベント:【Shop】武器屋
条件分岐:セルフスイッチ AがOFF
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「おや、武器屋のご利用は初めてですね。
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「これを差し上げますので、よろしければご利
文章 用ください。
SEの演奏:Item3 (90, 100, 0)
文章:なし, ウィンドウ, 中
文章
文章\>       \c[21]武器屋ポイントカード\c[0]をもらった。
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「お買い物の際、当店のポイントカードをご提
文章 示いただければ\c[21]700G\c[0]につき\c[29]1P\c[0]付与させ
文章 ていただきます。
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「\c[29]5P\c[0]につき\c[21]700G\c[0]返金いたします。
文章 どうぞご利用ください。
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「ただし、ポイントの付与は\c[27]売買した結果\c[0]の金
文章 額に対してお付けしております。
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「品物をお売りいただいた場合、金額によって
文章 はポイントが付与されないことがあります。
文章 お気を付けください。
セルフスイッチの操作:A = ON

分岐終了
変数の操作:#0055 【Shop】Money_a = 所持金
変数の操作:#0054 【Shop】Money_b -= 【Shop】Money_a
ループ
条件分岐:【Shop】Money_b ≥ 700
変数の操作:#0057 【Shop】stamp_moment += 1
変数の操作:#0054 【Shop】Money_b -= 700

それ以外のとき
ループの中断

分岐終了

以上繰り返し
条件分岐:【Shop】stamp_moment ≥ 1
条件分岐:パーティが武器屋ポイントカードを持っている
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「いつもありがとうございます。
文章 今回は\c[29]\v[57]P\c[0]お付けいたしますね。

それ以外のとき
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「それでは、今回は\c[29]\v[57]P\c[0]お付けいたしますね。

分岐終了
変数の操作:#0058 【Shop】stamp_weapon += 【Shop】stamp_moment

分岐終了
条件分岐:【Shop】stamp_weapon ≥ 5
変数の操作:#0062 【Shop】momentNumber = 【Shop】stamp_weapon
変数の操作:#0058 【Shop】stamp_weapon /= 5
変数の操作:#0061 【Shop】momentGold = 700
変数の操作:#0061 【Shop】momentGold *= 【Shop】stamp_weapon
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「今回のお買い物で\c[29]\v[62]P\c[0]になりましたので、
文章 \c[21]\v[61]G\c[0]お返しいたしますね。
所持金の増減:+ {【Shop】momentGold}
SEの演奏:Coin (90, 100, 0)
文章:なし, ウィンドウ, 中
文章
文章\>           \c[21]\v[61]G\c[0]もらった。
変数の操作:#0062 【Shop】momentNumber %= 5
変数の操作:#0058 【Shop】stamp_weapon = 【Shop】momentNumber
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「残りのポイントは\c[29]\v[58]P\c[0]になりました。

分岐終了
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「ありがとうございました。
文章 また、いらしてください。
条件分岐:パーティが武器屋ポイントカードを持っている

それ以外のとき
アイテムの増減:武器屋ポイントカード + 1

分岐終了
スイッチの操作:#0022 【req】Map21-Ev4 = OFF



(ちなみに、スイッチの操作:#0022 【req】Map21-Ev4ですが、気にしなくていいです。このマップでは自立動作しているイベントがいるので、そいつの挙動をこのスイッチで制御させているために、入っています)


処理の詳細を解説する前に、まずは処理の内容をザックリ説明しますね。

・所持金を変数に代入します。
・お買い物します。
・所持金の差額を求めます。
・差額に応じて、スタンプの計算処理を行います。
・スタンプ数に応じて、返金額を計算します。
・返金処理を行います。


こんな流れとなります。



それでは、上から順番に解説していきましょう。

変数の操作:#0057 【Shop】stamp_moment = 0
変数の操作:#0054 【Shop】Money_b = 所持金


変数57はとりあえず初期化しておきます。
そして、変数54所持金を代入します。


文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「いらっしゃいませ。
文章 どうぞ見ていってください。
コモンイベント:【Shop】武器屋


ここで、適当な会話とショップの処理ですね。

条件分岐:セルフスイッチ AがOFF
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「おや、武器屋のご利用は初めてですね。
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「これを差し上げますので、よろしければご利
文章 用ください。
SEの演奏:Item3 (90, 100, 0)
文章:なし, ウィンドウ, 中
文章
文章\>       \c[21]武器屋ポイントカード\c[0]をもらった。
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「お買い物の際、当店のポイントカードをご提
文章 示いただければ\c[21]700G\c[0]につき\c[29]1P\c[0]付与させ
文章 ていただきます。
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「\c[29]5P\c[0]につき\c[21]700G\c[0]返金いたします。
文章 どうぞご利用ください。
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「ただし、ポイントの付与は\c[27]売買した結果\c[0]の金
文章 額に対してお付けしております。
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「品物をお売りいただいた場合、金額によって
文章 はポイントが付与されないことがあります。
文章 お気を付けください。
セルフスイッチの操作:A = ON

分岐終了


ショップの処理の後にあるこの会話は、ポイントカードを持っていないときの処理です。

初回説明の処理ですので、不要であれば省略して構いません。

変数の操作:#0055 【Shop】Money_a = 所持金
変数の操作:#0054 【Shop】Money_b -= 【Shop】Money_a
ループ
条件分岐:【Shop】Money_b ≥ 700
変数の操作:#0057 【Shop】stamp_moment += 1
変数の操作:#0054 【Shop】Money_b -= 700

それ以外のとき
ループの中断

分岐終了

以上繰り返し


お買い物が終わったら、その時点での所持金変数55に代入します。

そして、最初の変数54から変数55引き算することで、差を出します。

その後のループ処理ですが、何となく変数が分かりづらくなりそうだったので、あえて変数を分ける処理にしました。

結果的には、このちょっとした処理は必要なくて、単純に変数を700で割り算するだけで良かったんですけどね(笑)

一応、ここでは何をやっているかといいますと、差額から700を何回引いているかをカウントしています。
ここでは700Gにつき1P付くので、変数55(お買い物金額)が700(G)以上かを確認し、700(G)以上なら、ここから700(G)を差し引いて、変数57+1(1P付与)します。これをループ(700より小さくなるまで繰り返)させることで、何P付与されたかを計算しています。


条件分岐:【Shop】stamp_moment ≥ 1
条件分岐:パーティが武器屋ポイントカードを持っている
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「いつもありがとうございます。
文章 今回は\c[29]\v[57]P\c[0]お付けいたしますね。

それ以外のとき
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「それでは、今回は\c[29]\v[57]P\c[0]お付けいたしますね。

分岐終了
変数の操作:#0058 【Shop】stamp_weapon += 【Shop】stamp_moment

分岐終了


で、付与するP数が決まったので、付与できるポイントが1P以上ある場合に、ポイント付与されたことをアナウンスします。

そして、手持ちのポイントカード(変数58)にポイントを加算します。


条件分岐:【Shop】stamp_weapon ≥ 5
変数の操作:#0062 【Shop】momentNumber = 【Shop】stamp_weapon
変数の操作:#0058 【Shop】stamp_weapon /= 5
変数の操作:#0061 【Shop】momentGold = 700
変数の操作:#0061 【Shop】momentGold *= 【Shop】stamp_weapon
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「今回のお買い物で\c[29]\v[62]P\c[0]になりましたので、
文章 \c[21]\v[61]G\c[0]お返しいたしますね。
所持金の増減:+ {【Shop】momentGold}
SEの演奏:Coin (90, 100, 0)
文章:なし, ウィンドウ, 中
文章
文章\>           \c[21]\v[61]G\c[0]もらった。
変数の操作:#0062 【Shop】momentNumber %= 5
変数の操作:#0058 【Shop】stamp_weapon = 【Shop】momentNumber
文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「残りのポイントは\c[29]\v[58]P\c[0]になりました。

分岐終了


ポイントカードに今回のお買い物で得られたポイントが付与されましたので、最後にポイントを精算します。

今回のショップでは5P以上の時に精算されます。

始めに、変数58を一時的に変数62へ入れておきます。

この後の処理で変数58を計算するのですが、この値はその更に後(会話の中、返金後の処理)で必要となるため、一時的に別な場所にも保存しておきます。

返金額の計算方法ですが、5Pにつき1単位(700G)返金するため、まずは変数58を5で割り算します。

また、変数61は700に設定しておきます。これが、1単位あたりの金額(G)です。

これで、返金される単位数と金額が出ましたので、変数61変数58を掛け算します。返金額が計算できました。

それをプレイヤーに取得させて返金処理は完了。今度はポイントの精算に移ります。

ポイントは変数62に一時保管しておきましたので、これの剰余を出します(剰余とは、割り算した余りの事です)。

今回は5Pにつき1単位精算されているので、ポイント(変数62)を5で割ったときの余りが残ったポイントとなります。

それを、ポイントカード(変数58)に戻して、精算完了です。

プレイヤーには、残りのポイントをアナウンスしておくと親切でしょう。

文章:People1(2), ウィンドウ, 下
文章武器屋の男性
文章「ありがとうございました。
文章 また、いらしてください。


ショップ終了の会話を入れて、クローズします。


条件分岐:パーティが武器屋ポイントカードを持っている

それ以外のとき
アイテムの増減:武器屋ポイントカード + 1

分岐終了


最後の最後にポイントカード取得の処理を入れているのは、その前でポイントカードを持っているかどうかで会話を分岐させているためです。

初回の買い物ではポイントカードを持っていないはずなので、最初の解説の直後に取得させてしまうと、ポイントカードを持っているときの処理となってしまうため、最後に持ってきています。


処理内容は以上です。

ではでは、今日はこの辺で。
ネコタでした。





↓お役に立ちましたら、クリックをお願いします↓
にほんブログ村 ゲームブログへ
にほんブログ村

にほんブログ村 ゲームブログ ゲーム制作へ
にほんブログ村

ブログランキング・にほんブログ村へ
にほんブログ村

ゲーム制作日記<50> ランダム出現シンボルイベント

op.png



みなさん、こんばんは。
ネコタです。


ゲーム制作日記も、遂に50回目の投稿ですね。
気付けば、今年ももう残りわずか。

ちょうどキリがいいので、これを今年最後の投稿にしようかと思います。



さて、それでは今回も恒例の『 コモンイベントで作るちょっとしたシステム 』 のご紹介。


今回は、アイディアを御味噌屋さんからいただきました(というか、依頼です)。ありがとうございます。

今回のように委託されての作成は初めてですが、いやぁ、頼まれてシステム作るって、思ったより大変ですね。

何が大変って、色々聞き取りが必要なこと。イメージでこんなことをやりたいなぁという漠然としたものはあると思うんですが、それを形にするためには、とても具体的な事柄が必要です。それが固まっていないと、頼むのも難しいし、頼まれた側も難しい。

こういうやり取り、個人的には割と好きですが、お互いの協力が必要なもんですから結構大変です。

お互いに、相手を思いやる気持ちと、正確にストレートに伝えること(遠慮はいけません。納得いくものが納品されないとお互いに不利益でしょうから)。このさじ加減が難しいですが、上手にコミュニケーションをとれるようにしたいものです。


さて、それでは本題に入りましょう。


今回紹介するシステムは、
『ランダム出現イベントシステム』です。

どういうシステムかというと、マップを一定数歩くと、マップのどこかにイベントが現れるというものです。


なんとなくイメージがつきにくいかもしれないので、画像で説明しますね。

tc36-009.png

ここに、「ネコタの不思議なダンジョン」っぽいマップがあります。

ちょっと日本語がアレな女の子が、機能を簡単に説明してくれました。

これでシステムが動きだしたので、あとは歩き回ってみます。



tc36-010.png

とにかく歩き回ってみます。
いつか、何かが現れると信じて・・・

ちなみに、右下のウインドウですが、機能を確認するためにプラグインで変数を表示しています。

画像では64歩あるいたことが確認できますね。


tc36-011.png

ついに、何者かが現れました!

画像を見ると歩数が0にリセットされています。
イベントが出現すると、歩数がリセットされる仕組みです。

この出現したイベントはとりあえず無視して、さらに歩き回ってみましょう。



tc36-012.png

すると、また別なイベントが出現しました。

では、この出現したイベントに触ってみましょう。



tc36-013.png

どうやら、彼女は男に触られると呪いにかかって倒れてしまう体質のようです(笑)

とんだ男嫌いでした(笑)


そんな彼女には酷なことですが、もう一度話しかけてみましょう。



tc36-014.png

ご親切に、システムの内部処理情報を教えてくれました(笑)

どうやら、彼女が出現するまでに、出現場所を計算した回数は12回、出現までにかかった歩数は159歩だったようです。



tc36-015.png

ちなみに、最初の女の子に話しかけると、動作テストを終了できます。

終了すると、内部情報をリセットしてまた最初からテストができます。



tc36-016.png

選択肢の「出現歩数を確認したい」を選ぶと、それぞれのキャラクターが出現するのに必要な歩数が確認できます。

とまあ、こんな感じで「歩数が乱数で選ばれて、その歩数に到達したら順番にイベントが不特定の箇所に出現する」というイベントシステムでした。


さて、イメージがつかめたところで、改めて仕様を説明します。


・システムが起動した時点で適当な歩数が自動で設定され、その歩数に到達したら順番にイベントを出現させます。
・出現するイベント自体は、普通のイベント同様に機能します。
・プレイヤーの上やイベントの上には出現しません。
・イベントは勝手に消えませんのでご注意ください。
・それぞれのイベント自体は独立していますので、条件を満たせば次々に出現します。
・ただし、順番を飛び越しての出現はしません。
・内部処理の情報表示は動作確認のために用意したものですので、削除して困ることはありません。


また、編集できる項目ですが、


・各イベントの出現歩数の範囲を設定できます(定数も可能)。
・条件分岐を使えば、全部のイベントが出現するまでの上限歩数を設定できます。
・出現させるイベントは追加可能です。
・出現させられる場所は、地形タグで編集します。

こんな感じですね。



それでは、まずはいつも通り必要なものの確認から行きましょう。


【必須】
スイッチ*4(コア用)
スイッチ*出現させるイベントの数だけ)
変数*15
コモンイベント*1(条件設定用)
イベント*1(コア用)
イベント*必要な分だけ(出現させる対象)


【推奨】
プラグイン:OuterSelfSwitch(準公式プラグイン)
コモンイベント:プレイヤー情報取得


【デバッグ用】
変数*2



まず、【推奨】のプラグインですが、

プラグイン:OuterSelfSwitch
tc36-005.png

準公式プラグインで、同梱のサンプルゲーム「ニナと鍵守の勇者」に導入されています。

このプラグインを使うと、プラグインコマンド任意のセルフスイッチを操作することができます。

【必須】の中に(・スイッチ*イベントの数だけ)とありましたが、このプラグインを導入していればセルフスイッチで代替することが可能です。

1つのMAPで沢山のイベントを出現させる必要がある場合は、このプラグインを導入しておくとスイッチの数を圧迫しなくなります。使い道は多いプラグインですので、とりあえずでも導入しておくとよいと思います。


コモンイベント:プレイヤー情報取得
tc35-013.png

<実行内容>
変数の操作:#0004 プレイヤーの位置X = プレイヤーのマップX
変数の操作:#0005 プレイヤーの位置Y = プレイヤーのマップY
変数の操作:#0002 プレイヤーの向き = プレイヤーの向き


もう何度書いたか分かりませんが、プレイヤーの位置情報向きを取得するコモンイベントです。プレイヤーの座標や向きなどを取得したい場合にあると便利ですので、作っておくと良いでしょう。今回の処理でも使っています。

(なお、今回の処理では向きを使用していないため、向きを格納する変数は必要な変数の数に入れておりません。)



それでは、イベントの中身を見ていきましょう。

まずは、設定用のコモンイベントから。


コモンイベント:【出現EV】出現歩数設定
tc36-002.png

トリガー:自動実行
スイッチ:0030 【条件】出現設定起動

<実行内容>
注釈:出現上限参照用の乱数合計値をリセットします。
変数の操作:#0417 【数値】乱数合計 = 0
注釈:各出現イベントの出現歩数を設定します。
変数の操作:#0421 【数値】乱数A = 乱数 1..199
変数の操作:#0422 【数値】乱数B = 乱数 1..199
変数の操作:#0423 【数値】乱数C = 乱数 1..199
変数の操作:#0424 【数値】乱数D = 乱数 1..199
変数の操作:#0425 【数値】乱数E = 乱数 1..199
注釈:参照用変数を計算します。
変数の操作:#0417 【数値】乱数合計 += 【数値】乱数A
変数の操作:#0417 【数値】乱数合計 += 【数値】乱数B
変数の操作:#0417 【数値】乱数合計 += 【数値】乱数C
変数の操作:#0417 【数値】乱数合計 += 【数値】乱数D
変数の操作:#0417 【数値】乱数合計 += 【数値】乱数E
注釈:乱数合計値の上限を設定します。この値が、全イベント出現までにかかる歩数の合計値となります。
注釈:条件分岐に外れた場合は、条件に該当するまで試行を繰り返します。
条件分岐:【数値】乱数合計 ≤ 500
変数の操作:#0426 【数値】出現数 = 1
スイッチの操作:#0028 【条件】歩数出現A = ON
スイッチの操作:#0030 【条件】出現設定起動 = OFF

分岐終了


この処理では、出現のための歩数を設定しています。

出現時に乱数取得せず、あえて最初に決めているのには理由があります。

それは、あらかじめ全体の歩数を決定することで、条件分岐で上限を設けるためです。

たとえば、今回の例では期待値として100歩となるような数値を設定しています。

ただ、期待値はあくまで期待値です。場合によっては何度も長い歩数が選択されてしまうケースがあるでしょう。

それを防ぐために、まず全体として「これ以上は歩いてほしくない」という数値を条件付けしておくことで、乱数をそれ以下になるような条件のみ選択されるようにしています。

条件に当てはまらないと当てはまるまで何度も試行を繰り返す処理となっていますので、あまりギチギチな条件は組まない方がよいでしょう。試行を繰り返す回数が多くなるほど、処理に時間がかかります

ちなみに、このくらいの条件であれば平均1.5回転ほどで決定されました。ほぼノータイムです(27回ほど試行した結果です)。



それでは次に、コアとなるマップ上のイベントを見てみましょう。

まず、マップにはこんな具合にイベントが配置されていました。

tc36-001.png

プレイヤーの下にいるイベントが、システムの起動や終了を担当しているイベントです。これは、テストのために用意したイベントなので、通常は場所移動のタイミングなどでスイッチ操作をすればOKです。

で、右上の人たち出現させられるイベント達です。

コアイベントは、左上の透明なやつですね。イベント達の移動を制御している大事なイベントです。


コアイベント
tc36-008.png

トリガー:並列処理
出現条件:0028 【条件】歩数出現A

<実行内容>
注釈:参照用の歩数を一時格納します。イベントが出現すると再度格納しなおします。
条件分岐:【条件】歩数出現BがOFF
変数の操作:#0418 【数値】参照歩数 = 歩数
スイッチの操作:#0029 【条件】歩数出現B = ON

分岐終了
注釈:現在の歩数を格納します。
変数の操作:#0419 【数値】現在歩数 = 歩数
注釈:イベント出現のために歩いた歩数をカウントします。
変数の操作:#0419 【数値】現在歩数 -= 【数値】参照歩数
注釈:出現数によって出現させるイベントを指定します。
注釈:なお、出現させるイベントによって必要な歩数が異なります。
条件分岐:【数値】出現数 = 1
条件分岐:【数値】現在歩数 ≥ 【数値】乱数A
ラベルジャンプ:出現処理

分岐終了

分岐終了
条件分岐:【数値】出現数 = 2
条件分岐:【数値】現在歩数 ≥ 【数値】乱数B
ラベルジャンプ:出現処理

分岐終了

分岐終了
条件分岐:【数値】出現数 = 3
条件分岐:【数値】現在歩数 ≥ 【数値】乱数C
ラベルジャンプ:出現処理

分岐終了

分岐終了
条件分岐:【数値】出現数 = 4
条件分岐:【数値】現在歩数 ≥ 【数値】乱数D
ラベルジャンプ:出現処理

分岐終了

分岐終了
条件分岐:【数値】出現数 = 5
条件分岐:【数値】現在歩数 ≥ 【数値】乱数E
ラベルジャンプ:出現処理

分岐終了

分岐終了
ウェイト:2フレーム
注釈:歩数が規定に達しない場合は、ここで処理終了です。再度、処理を先頭から繰り返します。
注釈:以下、ゲーム中ではONになることが無いスイッチを条件に設定してください。
注釈:これにより、ラベルジャンプ以外では処理されなくなります。
条件分岐:使用不可がON
ラベル:出現処理
注釈:以下、ランダムの箇所にイベントを出現させる処理です。
ループ
注釈:デバッグ用の変数です。
注釈:ループ処理の試行回数をカウントします。
変数の操作:#0427 【デバッグ】試行回数 += 1
注釈:X軸、Y軸それぞれ乱数の下限を0、上限をマップの幅-1に設定します。
注釈:例えば、X17*Y13マスのMAPの場合、
注釈:X軸=0~16
注釈:Y軸=0~12
注釈:となります。
変数の操作:#0415 【座標X】出現予定 = 乱数 0..16
変数の操作:#0416 【座標Y】出現予定 = 乱数 0..12
注釈:以下、出現処理です。出現させる箇所が見つかるまで処理を繰り返します。
注釈:出現させることが出来る箇所がMAP全体に対して少ないと時間がかかることがあります。
指定位置の情報取得:【ID】地形タグ, 地形タグ, ({【座標X】出現予定},{【座標Y】出現予定})
条件分岐:【ID】地形タグ = 1
指定位置の情報取得:【ID】イベント, イベントID, ({【座標X】出現予定},{【座標Y】出現予定})
条件分岐:【ID】イベント = 0
コモンイベント:プレイヤー情報取得
条件分岐:【座標X】出現予定 ≠ プレイヤーの位置X
ループの中断

それ以外のとき
条件分岐:【座標Y】出現予定 ≠ プレイヤーの位置Y
ループの中断

分岐終了

分岐終了

分岐終了

分岐終了

以上繰り返し
注釈:デバッグ用の変数です。
注釈:かかった歩数の合計をカウントします。
変数の操作:#0428 【デバッグ】歩数 += 【数値】現在歩数
条件分岐:【数値】出現数 = 5
SEの演奏:Absorb2 (90, 100, 0)
注釈:出現させるイベントを指定してください。
イベントの位置設定:EV006, ({【座標X】出現予定},{【座標Y】出現予定})
注釈:次の出現処理を行うために、変数とスイッチを操作します。
注釈:出現数を0にすると、出現処理を行わなくなります。
スイッチの操作:#0029 【条件】歩数出現B = OFF
スイッチの操作:#0113 【EV】イベントE = ON
変数の操作:#0426 【数値】出現数 = 0

分岐終了
条件分岐:【数値】出現数 = 4
SEの演奏:Absorb2 (90, 100, 0)
注釈:出現させるイベントを指定してください。
イベントの位置設定:EV005, ({【座標X】出現予定},{【座標Y】出現予定})
注釈:次の出現処理を行うために、変数とスイッチを操作します。
スイッチの操作:#0029 【条件】歩数出現B = OFF
スイッチの操作:#0112 【EV】イベントD = ON
変数の操作:#0426 【数値】出現数 += 1

分岐終了
条件分岐:【数値】出現数 = 3
SEの演奏:Absorb2 (90, 100, 0)
注釈:出現させるイベントを指定してください。
イベントの位置設定:EV004, ({【座標X】出現予定},{【座標Y】出現予定})
注釈:次の出現処理を行うために、変数とスイッチを操作します。
スイッチの操作:#0029 【条件】歩数出現B = OFF
スイッチの操作:#0111 【EV】イベントC = ON
変数の操作:#0426 【数値】出現数 += 1

分岐終了
条件分岐:【数値】出現数 = 2
SEの演奏:Absorb2 (90, 100, 0)
注釈:出現させるイベントを指定してください。
イベントの位置設定:EV003, ({【座標X】出現予定},{【座標Y】出現予定})
注釈:次の出現処理を行うために、変数とスイッチを操作します。
スイッチの操作:#0029 【条件】歩数出現B = OFF
スイッチの操作:#0110 【EV】イベントB = ON
変数の操作:#0426 【数値】出現数 += 1

分岐終了
条件分岐:【数値】出現数 = 1
SEの演奏:Absorb2 (90, 100, 0)
注釈:出現させるイベントを指定してください。
イベントの位置設定:EV002, ({【座標X】出現予定},{【座標Y】出現予定})
注釈:次の出現処理を行うために、変数とスイッチを操作します。
スイッチの操作:#0029 【条件】歩数出現B = OFF
スイッチの操作:#0109 【EV】イベントA = ON
変数の操作:#0426 【数値】出現数 += 1

分岐終了

分岐終了


条件分岐が多いのでなかなかしびれる内容ですが、条件分岐はイベントの数だけ増える仕組みです。それが無ければ、実はそんなに複雑な内容ではありません。

順番に見ていきましょう。


注釈:参照用の歩数を一時格納します。イベントが出現すると再度格納しなおします。
条件分岐:【条件】歩数出現BがOFF
変数の操作:#0418 【数値】参照歩数 = 歩数
スイッチの操作:#0029 【条件】歩数出現B = ON

分岐終了
注釈:現在の歩数を格納します。
変数の操作:#0419 【数値】現在歩数 = 歩数
注釈:イベント出現のために歩いた歩数をカウントします。
変数の操作:#0419 【数値】現在歩数 -= 【数値】参照歩数


最初にいくつかある変数の処理は、イベント出現のための歩数をカウントする処理です。

条件分岐の中にある変数は、イベントが出現した時点(あるいは、一番最初の何も出現していない時点)の歩数です。出現時点の歩数は更新されませんが、現在の歩数は常に更新されていきます。

これにより、歩くたびにこの2者間の差が広がっていくことになりますが、この差こそがイベント出現時から現在までで歩いた歩数となります。





注釈:出現数によって出現させるイベントを指定します。
注釈:なお、出現させるイベントによって必要な歩数が異なります。
条件分岐:【数値】出現数 = 1
条件分岐:【数値】現在歩数 ≥ 【数値】乱数A
ラベルジャンプ:出現処理

分岐終了

分岐終了
条件分岐:【数値】出現数 = 2
条件分岐:【数値】現在歩数 ≥ 【数値】乱数B
ラベルジャンプ:出現処理

分岐終了

分岐終了
条件分岐:【数値】出現数 = 3
条件分岐:【数値】現在歩数 ≥ 【数値】乱数C
ラベルジャンプ:出現処理

分岐終了

分岐終了
条件分岐:【数値】出現数 = 4
条件分岐:【数値】現在歩数 ≥ 【数値】乱数D
ラベルジャンプ:出現処理

分岐終了

分岐終了
条件分岐:【数値】出現数 = 5
条件分岐:【数値】現在歩数 ≥ 【数値】乱数E
ラベルジャンプ:出現処理

分岐終了

分岐終了


この部分は、イベントによって出現する歩数が違うため、それぞれで条件分岐を分けています。

条件分岐の変数を見ると、【数値】乱数A、【数値】乱数B・・・となっていることに気付くと思います。

ここが、イベント毎に増やさなければいけない項目となります。

条件に合致したら、出現処理にラベルジャンプします。

【数値】出現数は後に使われますが、便宜上イベントのナンバリングに使用されています。出現数=1は最初に出現するイベントを指し、以降、=2は2番目、=3は3番目・・・といった具合です。




ウェイト:2フレーム
注釈:歩数が規定に達しない場合は、ここで処理終了です。再度、処理を先頭から繰り返します。
注釈:以下、ゲーム中ではONになることが無いスイッチを条件に設定してください。
注釈:これにより、ラベルジャンプ以外では処理されなくなります。


歩数監視の処理は、これで終わりです。これ以降の処理はページを切り替えてやっても構いませんが、今回は「使用不可」のスイッチを条件にすることで「ページを切り分ける」ことと同じように扱っています。

条件分岐:使用不可がON
ラベル:出現処理


イベントページを余計に作りたくないときや、セルフスイッチが足りないとき、処理的にはループさせたい部分だけれど特定の条件でなければ処理をさせたくないなど、割といろんなところで使えるテクニックです。

特にこの形にする必要はありませんでしたが、今回はついでに紹介しようと思って使ってみました。

この中にラベルが入っていますので、上記の条件を満たしたときにのみ行われるという形になっています。(ゲームではONになることのない「使用不可」のスイッチを設けることで、この中の処理は、普段処理されることがなくなります。それを利用して、ラベルジャンプのみで処理が行われるという形に変えることができます)

それでは、中の処理を見てみましょう。




注釈:以下、ランダムの箇所にイベントを出現させる処理です。
ループ
注釈:デバッグ用の変数です。
注釈:ループ処理の試行回数をカウントします。
変数の操作:#0427 【デバッグ】試行回数 += 1
注釈:X軸、Y軸それぞれ乱数の下限を0、上限をマップの幅-1に設定します。
注釈:例えば、X17*Y13マスのMAPの場合、
注釈:X軸=0~16
注釈:Y軸=0~12
注釈:となります。
変数の操作:#0415 【座標X】出現予定 = 乱数 0..16
変数の操作:#0416 【座標Y】出現予定 = 乱数 0..12
注釈:以下、出現処理です。出現させる箇所が見つかるまで処理を繰り返します。
注釈:出現させることが出来る箇所がMAP全体に対して少ないと時間がかかることがあります。
指定位置の情報取得:【ID】地形タグ, 地形タグ, ({【座標X】出現予定},{【座標Y】出現予定})
条件分岐:【ID】地形タグ = 1
指定位置の情報取得:【ID】イベント, イベントID, ({【座標X】出現予定},{【座標Y】出現予定})
条件分岐:【ID】イベント = 0
コモンイベント:プレイヤー情報取得
条件分岐:【座標X】出現予定 ≠ プレイヤーの位置X
ループの中断

それ以外のとき
条件分岐:【座標Y】出現予定 ≠ プレイヤーの位置Y
ループの中断

分岐終了

分岐終了

分岐終了

分岐終了

以上繰り返し


ループ処理となっていますが、ここでは、イベントが移動される場所を探しています

条件としては、乱数でX座標とY座標を設定します。
この時の範囲は、自分でマップの幅を設定する必要があります。
マップごとに数値を弄ってください。


注釈:デバッグ用の変数です。
注釈:ループ処理の試行回数をカウントします。
変数の操作:#0427 【デバッグ】試行回数 += 1


ちなみに、この部分は無くても良いです。
ここで、試行回数を判定していました。


指定位置の情報取得:【ID】地形タグ, 地形タグ, ({【座標X】出現予定},{【座標Y】出現予定})
条件分岐:【ID】地形タグ = 1
指定位置の情報取得:【ID】イベント, イベントID, ({【座標X】出現予定},{【座標Y】出現予定})
条件分岐:【ID】イベント = 0
コモンイベント:プレイヤー情報取得
条件分岐:【座標X】出現予定 ≠ プレイヤーの位置X
ループの中断

それ以外のとき
条件分岐:【座標Y】出現予定 ≠ プレイヤーの位置Y
ループの中断

分岐終了

分岐終了

分岐終了

分岐終了



ここの条件分岐で、イベントを出現させていいかを絞りこんでいます。

まず、地形タグで判定。ここの数値をいじることで、地形による出現判定を編集することができます。

tc36-017.png

地形タグは、タイルセットから設定することができます。今回は、地面のタイルに1番を設定しています。

ちなみに、地形タグはその位置の最も大きいものが取得されるようです。なので、今回の場合は地形タグが2番に設定されているものを乗せると、条件に引っかからなくなりますので気を付けてください。逆に、これを利用すると特定の場所だけ出現しないように設定できます。

指定位置の情報取得:【ID】イベント, イベントID, ({【座標X】出現予定},{【座標Y】出現予定})
条件分岐:【ID】イベント = 0


次に、イベントIDを読み込んでいますが、ここではイベントの上にかぶらないように振り分けしています。

イベントが被らないようにするための措置ですが、これを逆に利用すると、出現させたくない箇所に透明なイベントを置いとくだけで出現範囲から除くこともできます。


コモンイベント:プレイヤー情報取得
条件分岐:【座標X】出現予定 ≠ プレイヤーの位置X
ループの中断

それ以外のとき
条件分岐:【座標Y】出現予定 ≠ プレイヤーの位置Y
ループの中断

分岐終了

分岐終了


ここの部分は、プレイヤーの上に被らないようにする処理です。

プレイヤーのX座標とY座標を取得し、乱数で設定された座標が完全一致でない場合に、ようやくループを中断させます。


これで座標が決定したので、ようやく場所移動させることが出来ます。





条件分岐:【数値】出現数 = 5
SEの演奏:Absorb2 (90, 100, 0)
注釈:出現させるイベントを指定してください。
イベントの位置設定:EV006, ({【座標X】出現予定},{【座標Y】出現予定})
注釈:次の出現処理を行うために、変数とスイッチを操作します。
注釈:出現数を0にすると、出現処理を行わなくなります。
スイッチの操作:#0029 【条件】歩数出現B = OFF
スイッチの操作:#0113 【EV】イベントE = ON
変数の操作:#0426 【数値】出現数 = 0

分岐終了
条件分岐:【数値】出現数 = 4
SEの演奏:Absorb2 (90, 100, 0)
注釈:出現させるイベントを指定してください。
イベントの位置設定:EV005, ({【座標X】出現予定},{【座標Y】出現予定})
注釈:次の出現処理を行うために、変数とスイッチを操作します。
スイッチの操作:#0029 【条件】歩数出現B = OFF
スイッチの操作:#0112 【EV】イベントD = ON
変数の操作:#0426 【数値】出現数 += 1

分岐終了
条件分岐:【数値】出現数 = 3
SEの演奏:Absorb2 (90, 100, 0)
注釈:出現させるイベントを指定してください。
イベントの位置設定:EV004, ({【座標X】出現予定},{【座標Y】出現予定})
注釈:次の出現処理を行うために、変数とスイッチを操作します。
スイッチの操作:#0029 【条件】歩数出現B = OFF
スイッチの操作:#0111 【EV】イベントC = ON
変数の操作:#0426 【数値】出現数 += 1

分岐終了
条件分岐:【数値】出現数 = 2
SEの演奏:Absorb2 (90, 100, 0)
注釈:出現させるイベントを指定してください。
イベントの位置設定:EV003, ({【座標X】出現予定},{【座標Y】出現予定})
注釈:次の出現処理を行うために、変数とスイッチを操作します。
スイッチの操作:#0029 【条件】歩数出現B = OFF
スイッチの操作:#0110 【EV】イベントB = ON
変数の操作:#0426 【数値】出現数 += 1

分岐終了
条件分岐:【数値】出現数 = 1
SEの演奏:Absorb2 (90, 100, 0)
注釈:出現させるイベントを指定してください。
イベントの位置設定:EV002, ({【座標X】出現予定},{【座標Y】出現予定})
注釈:次の出現処理を行うために、変数とスイッチを操作します。
スイッチの操作:#0029 【条件】歩数出現B = OFF
スイッチの操作:#0109 【EV】イベントA = ON
変数の操作:#0426 【数値】出現数 += 1

分岐終了


ここでは、それぞれの条件によって移動させるイベントを指定し、決定した座標へ移動させる処理を行います。

ここでの注意点ですが、最後のイベントから順番に条件分岐を作っていきます

その理由ですが、最初の条件分岐以外では移動処理を行った場合に、

変数の操作:#0426 【数値】出現数 += 1


と記述しています。

これを出現数の若い順から作っていくと、次の分岐の条件を即座に満たしてしまい、結局一か所に全てのイベントが出現してしまいます。それを防ぐためにはいくつか手段がありますが、一番手っ取り早いのは、番号の大きい順に並べ替えてしまう事です(処理は通常逆行して行われないため)。



これで、ランダムに出現させる処理が出来ました。

システム自体はこれで完成です。

後のイベントは適当に組んで構いませんが、一応、見ていきましょうか。

今回は、デバッグできるように、必要そうな情報を表示したり、リセットしたりするための処理を置いています。


tc36-003.png

<実行内容>
文章:なし, ウィンドウ, 下
文章イベントをランダム歩数でランダム箇所に出現させるわ。
注釈:歩数カウントによるイベント出現テストを開始します。
スイッチの操作:#0030 【条件】出現設定起動 = ON
セルフスイッチの操作:A = ON


まずは、システム起動用の女の子のイベントですね。

システム起動のためのスイッチをONにするだけです。


tc36-004.png

<実行内容>
文章:なし, ウィンドウ, 下
文章テストを終了する?
選択肢の表示:はい, いいえ, 出現歩数を確認したい (ウィンドウ, 右, #1, #2)
はいのとき
文章:なし, ウィンドウ, 下
文章テストを終了し、初期化します。
注釈:以下、テストを終了し、初期化します。
変数の操作:#0428 【デバッグ】歩数 = 0
変数の操作:#0427 【デバッグ】試行回数 = 0
スイッチの操作:#0028 【条件】歩数出現A = OFF
イベントの位置設定:EV002, (12,0)
イベントの位置設定:EV003, (13,0)
イベントの位置設定:EV004, (14,0)
イベントの位置設定:EV005, (15,0)
イベントの位置設定:EV006, (16,0)
スイッチの操作:#0029 【条件】歩数出現B = OFF
スイッチの操作:#0109 【EV】イベントA = OFF
スイッチの操作:#0110 【EV】イベントB = OFF
スイッチの操作:#0111 【EV】イベントC = OFF
スイッチの操作:#0112 【EV】イベントD = OFF
スイッチの操作:#0113 【EV】イベントE = OFF
プラグインコマンド:OuterSelfSwitch off all A

いいえのとき

出現歩数を確認したいのとき
文章:なし, ウィンドウ, 下
文章出現歩数:
文章イベントA \v[421]歩,  イベントB \v[422]歩,
文章イベントC \v[423]歩,  イベントD \v[424]歩,
文章イベントE \v[425]歩,  合計   \v[417]歩

分岐終了


初期化の選択と、決定された歩数を見ることが出来ます

出現まで待たなくても、初期化と歩数確認で、きちんと目論見通りの数値になっているかを確認することができます。

今回は出現イベント達のページ出現条件を普通のスイッチで行い、ページ切り替えをセルフスイッチで行いました。

プラグインOuterSelfSwithを導入していれば、プラグインコマンドだけで操作できますので、【EV】イベントA~Eのスイッチは用意しなくても構いません。



tc36-006.png

出現条件:109 【EV】イベントA

<実行内容>
SEの演奏:Attack2 (90, 100, 0)
セルフスイッチの操作:A = ON


これは、出現されるイベント達の一人です。他のイベント達の中身も同じですので、他の方たちの処理は割愛させていただきます。

出現条件のスイッチはプラグインを導入している場合にはセルフスイッチでも操作できます。

内容は特にないので、適当な音を鳴らしてページを切り替えています。


tc36-007.png

出現条件:セルフスイッチA

<実行内容>
文章:なし, ウィンドウ, 下
文章出現処理の総試行回数は\v[427]でした。
文章総歩数は\v[428]でした。


取得した出現処理の試行回数と総歩数を表示しています。

最初の女の子が話している歩数(現在出現したイベントまでの合計)と、この歩数が一致していれば、処理がスムーズに行われている証拠です。異なる場合には、処理が重くなっているため必要以上に歩いている可能性があります。

出現処理の試行回数は目安として用意しましたが、たしか100回を超えても歩数がずれなかったので、相当数の試行回数にならない限りは大丈夫だと思います。



以上、デバッグの仕方も含めての解説でした。

こんな感じでいかがでしょう?


実際に作ってみて思いましたが、使い道はいろいろとありそうなシステムです。

さり気に、過去に作ったシンボルエンカウントの出現や無限ミミックの出現処理としても使えそうですね。

私も、自分の作品で使ってみようかと思います。




ではでは、今日はこの辺で。
ネコタでした。

それでは良いお年を!





↓お役に立ちましたら、クリックをお願いします↓
にほんブログ村 ゲームブログへ
にほんブログ村

にほんブログ村 ゲームブログ ゲーム制作へ
にほんブログ村

ブログランキング・にほんブログ村へ
にほんブログ村

ゲーム制作日記<49> 場所移動できる場所移動システム

op.png



みなさん、こんばんは。
ネコタです。


ようやくインターネットがつながり、システム公開できるようになりました。
いやー、長かった。


さて、それでは早速。
今回も恒例の『 コモンイベントで作るちょっとしたシステム 』 のご紹介です。


今回ご紹介するシステムは、制作の補助システム。
『場所移動できる場所移動システム』です。

どういうことかというと、普通の場所移動イベントは、下記のような形のイベントだと思います。

tc35-011.png

<実行内容>
SEの演奏:Move1 (90, 100, 0)
場所移動:場所移動ラボ (5,2)


これは簡易作成で作れるイベント内容です。

場所移動では、普通、座標を指定してそこにプレイヤーを移動させるかと思います。

挙動はこれだけなのですが、このイベントには1つの問題点があります。

移動先の場所や移動元の場所がすでに決定していれば、これで何の問題もありません。

しかし、例えばMAPを作りながら「ここに階段を作りたいな」と思って作成した後、「やっぱり、あっちが良いな」なんて思うことがあるかもしれません。

また、テストプレイをしてみると思っていたよりも場所移動イベントの位置が近かったり遠かったりして・・・
位置を変えたいなぁ~、ということが制作中たびたび起こるかもしれません。

ただ、位置を変えると、イベントの座標指定を再設定しなおさなければなりませんよね!


これが、結構面倒くさいんです・・・。


よくあるのが、街でのショップの配置。

最初は武器屋を入口近くに置いていたけど、宿屋の方が近くにあった方がいいな、とか。

過去に描いたMAPが今見ると微妙に見えてきて、再度描きなおした。その結果、いくつもの建物の配置を変えた。

そういった場合に、たくさんの場所移動イベントの内容を書き換えないといけなくなります


そこで、こういった問題を一挙に解決してくれるのが、今回のシステムとなります。

なんと、一度制作した場所移動イベントの中身を書き換えなくても、イベントの位置をそのままひょいっと移動してやるだけであら不思議。

自動で移動先も移動元も座標を変えてくれるじゃありませんか!


今回紹介するシステムは、そんな制作補助システムとなっています。


それでは、準備するものを確認していきましょう。



【必要なもの】
スイッチ ×1
変数 ×5
コモンイベント ×1
場所移動イベント


【推奨】
ドア・スイッチ挙動用コモンイベント
場所移動時挙動用コモンイベント
マップ範囲取得用コモンイベント
プレイヤー情報取得用コモンイベント
変数 ×4



まずは、【推奨】のコモンイベントを見ていきましょう。


ドア挙動用コモンイベント
tc35-002.png

<実行内容>
条件分岐:このイベントが下を向いている
SEの演奏:Door1 (90, 100, 0)
移動ルートの設定:このイベント (ウェイト)
移動ルートの設定:◇すり抜けON
移動ルートの設定:◇向き固定OFF
移動ルートの設定:◇左を向く
移動ルートの設定:◇ウェイト:5フレーム
移動ルートの設定:◇右を向く
移動ルートの設定:◇ウェイト:5フレーム
移動ルートの設定:◇上を向く
移動ルートの設定:◇向き固定ON

それ以外のとき
SEの演奏:Door1 (90, 90, 0)
移動ルートの設定:このイベント (ウェイト)
移動ルートの設定:◇すり抜けOFF
移動ルートの設定:◇向き固定OFF
移動ルートの設定:◇右を向く
移動ルートの設定:◇ウェイト:5フレーム
移動ルートの設定:◇左を向く
移動ルートの設定:◇ウェイト:5フレーム
移動ルートの設定:◇下を向く
移動ルートの設定:◇向き固定ON

分岐終了


ドアやスイッチの挙動を予めコモンイベントにしておくと、制作が少し楽になります。
大抵の場合、ドアやスイッチの挙動は全部同じ挙動をするはず。

ちょっと挙動に違和感があったりして修正が必要となった場合に、コモンイベントで挙動を設定していると、これ1つ修正すれば事足ります。いちいち全てのイベントを回る必要がないので、修正の手間が大きく省けるんですね。


場所移動時挙動用コモンイベント(階段移動)
tc35-010.png

<実行内容>
条件分岐:【移動】階段移動 = 1
SEの演奏:Move (90, 100, 0)
条件分岐:プレイヤーの向き = 4
移動ルートの設定:プレイヤー
移動ルートの設定:◇すり抜けON
移動ルートの設定:◇移動速度:2
移動ルートの設定:◇左上に移動

分岐終了
条件分岐:プレイヤーの向き = 6
移動ルートの設定:プレイヤー
移動ルートの設定:◇すり抜けON
移動ルートの設定:◇移動速度:2
移動ルートの設定:◇右上に移動

分岐終了

分岐終了
条件分岐:【移動】階段移動 = 2
SEの演奏:Move (90, 90, 0)
条件分岐:プレイヤーの向き = 4
移動ルートの設定:プレイヤー
移動ルートの設定:◇すり抜けON
移動ルートの設定:◇移動速度:1
移動ルートの設定:◇左下に移動

分岐終了
条件分岐:プレイヤーの向き = 6
移動ルートの設定:プレイヤー
移動ルートの設定:◇すり抜けON
移動ルートの設定:◇移動速度:1
移動ルートの設定:◇右下に移動

分岐終了

分岐終了


このコモンイベントは何かというと、階段移動をする場合にプレイヤーのモーションを設定しているイベントです。

何となく、階段を上り降りする際に動かないのは味がないなぁ・・・と思いまして。

このコモンイベントを挿入しておくと、階段に触ったときにプレイヤーが階段を上っている(あるいは降りている)ように動きます。

ちなみに、変数【移動】階段移動=1は上り階段、=2は下り階段を表します。

プレイヤーの向きは、
2=↓
4=←
6=→
8=↑

を表しています。


コモンイベント:マップ範囲取得
tc35-012.png


<実行内容>
変数の操作:#0164 マップX範囲 = $gameMap.width() -1
変数の操作:#0165 マップY範囲 = $gameMap.height() -1


以前に紹介したシステムでも何度か紹介していますね。無限ミミック畑システムアイテムを使った採集システムでも利用しているコモンイベントですが、この処理では、今いるマップのX軸とY軸の範囲を取得しています。

色んな場面で利用する処理ですので、コモンイベントにしておくとちょっとだけ便利です。

この処理内容自体は、今回のシステムに必須のものとなります。


コモンイベント:プレイヤー情報取得
tc35-013.png

これは、プレイヤーのマップ上での位置情報や向きを取得するコモンイベントです。

先に紹介した階段移動演出にプレイヤーの向きを使用するので、これを挿入してあげるだけでシュッと情報を取得できます。

これも、システムを作るうえでそこそこ使うコモンイベントですので、用意しておくといいでしょう。

(なお、今回のシステムではプレイヤーのX座標とY座標は使用しないため、用意するものの変数には含まれていません)




さて、推奨コモンイベントはこんなところで。

それでは、イベントの作成に入っていきましょう。

まずは、システムのコアとなるコモンイベントを作ります。


コモンイベント:ポジション設定
tc35-003.png

<トリガー> 自動実行
<スイッチ> 0032 【移動】ポジション設定

<実行内容>
注釈:画面を暗転させ、移動の処理を開始します。
画面の色調変更:(-255,-255,-255,0), 15フレーム (ウェイト)
注釈:指定したMAPへ移動します。この時の場所はどこでも構いません。
場所移動:{マップID} ({【移動】移動先X},{【移動】移動先Y}) (フェード: なし)
注釈:検索する移動先のX座標とY座標を左上端に設定します。
変数の操作:#0408 【移動】移動先X = 0
変数の操作:#0409 【移動】移動先Y = 0
注釈:移動先MAPの左上端から順に、指定されたイベントIDを探します。
コモンイベント:マップ範囲取得
ループ
指定位置の情報取得:【移動】イベントID, イベントID, ({【移動】移動先X},{【移動】移動先Y})
条件分岐:【移動】イベントID = 【移動】移動先EV
ループの中断

分岐終了
条件分岐:【移動】移動先X ≠ マップX範囲
変数の操作:#0408 【移動】移動先X += 1

それ以外のとき
変数の操作:#0408 【移動】移動先X = 0
条件分岐:【移動】移動先Y ≠ マップY範囲
変数の操作:#0409 【移動】移動先Y += 1

それ以外のとき
変数の操作:#0409 【移動】移動先Y = 0

分岐終了

分岐終了

以上繰り返し
注釈:指定されたイベントIDの位置へプレイヤーを移動します。
場所移動:{マップID} ({【移動】移動先X},{【移動】移動先Y}) (フェード: なし)
注釈:移動の種類により、移動した位置からのポジションを調節します。
移動ルートの設定:プレイヤー (飛ばす, ウェイト)
移動ルートの設定:◇移動速度:4
移動ルートの設定:◇歩行アニメOFF
移動ルートの設定:◇すり抜けON
移動ルートの設定:◇一歩前進
移動ルートの設定:◇すり抜けOFF
移動ルートの設定:◇歩行アニメON
注釈:移動の種類、向き情報をリセットします。
変数の操作:#0412 【移動】階段移動 = 0
変数の操作:#0002 プレイヤーの向き = 0
注釈:移動終了の処理を開始し、移動を終わらせます。
画面の色調変更:(0,0,0,0), 15フレーム (ウェイト)
スイッチの操作:#0032 【移動】ポジション設定 = OFF


この処理は何をやっているかというと、移動そのものを行っています。


ざっと内容を説明すると、

画面をフェードアウトさせて、その間にプレイヤーの移動先を探し出し、プレイヤーを移動させています。

移動が完了したら、画面をフェードインし、処理を終了します。




ここで出てくる幾つかの変数(マップID、イベントID)は、場所移動イベントの方で指定します。

また、このコモンイベントはトリガーとしてスイッチ0032 【移動】ポジション設定を指定しています。


すなわち、場所移動イベント移動先のマップイベントIDを指定し、このスイッチONにすることで移動が開始される、という仕組みとなっています。



それでは、準備が整ったところで、実際の場所移動イベントを見ていきましょう。


今回はデモ用として、こんなマップを用意しました。

外観
tc35-004.png

内観1F
tc35-005.png

内観2F
tc35-006.png


沢山のお家と内装を用意しました。
階段もいっぱいありますね。

これらの場所移動イベントは、全て最初に紹介したコモンイベント1つで動作します。



まずは、外観のドアイベントを見てみましょう。

tc35-001.png

<実行内容>
コモンイベント:【ドア】ドア挙動
変数の操作:#0018 マップID = 12
変数の操作:#0411 【移動】移動先EV = 3
スイッチの操作:#0032 【移動】ポジション設定 = ON


内容は簡潔ですね。

コモンイベントドア挙動でドアを開く動作をさせ、変数を設定して、移動用コモンイベントトリガースイッチON

あとは、最初につくったコモンイベントがプレイヤーを指定したマップの指定したイベントに移動させてくれます。



次に、内観の1F出入り口のイベントを見てみましょう。

tc35-007.png

<実行内容>
注釈:ドアの挙動を行います。
注釈:下向き=ドアが開く
注釈:それ以外=ドアが閉まる
移動ルートの設定:このイベント (ウェイト)
移動ルートの設定:◇上を向く
コモンイベント:【ドア】ドア挙動
注釈:移動先のMAPと、このイベントに紐づいているイベントIDを設定します。
変数の操作:#0018 マップID = 11
変数の操作:#0411 【移動】移動先EV = 1
注釈:移動の処理を開始します。
スイッチの操作:#0032 【移動】ポジション設定 = ON


まあ、ドアイベントなので、やってることは同じです。

ドアの演出をして、移動先のイベントIDを指定して、スイッチON

それだけでした。



次に、内観1Fの階段イベントを見てみましょう。

tc35-008.png

<実行内容>
注釈:階段による移動、上り下りの判定を行うための変数を設定します。
注釈:0=階段ではない移動
注釈:1=上り階段
注釈:2=下り階段
変数の操作:#0412 【移動】階段移動 = 1
注釈:プレイヤーの向きを取得します。
コモンイベント:プレイヤー情報取得
注釈:階段移動のSEを鳴らします。
コモンイベント:【移動】階段
注釈:移動先のMAPと、このイベントに紐づいているイベントIDを設定します。
変数の操作:#0018 マップID = 13
変数の操作:#0411 【移動】移動先EV = 1
注釈:移動の処理を開始します。
スイッチの操作:#0032 【移動】ポジション設定 = ON


コモンイベントの詳しい内容は、【推奨】コモンイベントを見て頂ければと思います。

演出の内容を変数でちょいちょいと指定し、ドアイベントと同様に移動先を変数で指定してスイッチON。

慣れてくると、簡単設定です。


最後に、2Fの下り階段イベントを見てみましょう。

tc35-009.png

<実行内容>
注釈:階段による移動、上り下りの判定を行うための変数を設定します。
注釈:0=階段ではない移動
注釈:1=上り階段
注釈:2=下り階段
変数の操作:#0412 【移動】階段移動 = 2
注釈:プレイヤーの向きを取得します。
コモンイベント:プレイヤー情報取得
注釈:階段移動のSEを鳴らします。
コモンイベント:【移動】階段
注釈:移動先のMAPと、このイベントに紐づいているイベントIDを設定します。
変数の操作:#0018 マップID = 12
変数の操作:#0411 【移動】移動先EV = 1
注釈:移動の処理を開始します。
スイッチの操作:#0032 【移動】ポジション設定 = ON


ぶっちゃけ、上り階段をコピペして、変数をちょちょいと変えただけです。

階段や扉を1個ずつ作ってしまえば、あとはコピペ変数操作で作れるので、実質的な負担は少なかったりします。



以上、こんな感じでコモンイベントを介して、イベント同士を変数で紐づけすることができます。

マップ編集をよく行う方は、ぜひ導入してみてください。

きっと、制作が楽になると思います。




ではでは、今日はこの辺で。
ネコタでした。





↓お役に立ちましたら、クリックをお願いします↓
にほんブログ村 ゲームブログへ
にほんブログ村

にほんブログ村 ゲームブログ ゲーム制作へ
にほんブログ村

ブログランキング・にほんブログ村へ
にほんブログ村

近況報告

皆さん、こんばんは。
ネコタです。

ちょっと、今はネットが繋がらない環境にいるため、ケータイを使っての記事投稿になります。


まず、2人目の子供が産まれそう。
やったね!

という事なので、まあ、妊娠が発覚した時点で頭に浮かんだのが「金策を練らねば!」という事(笑)


という訳で、製作によってしばらく封印していた伝家の宝刀を抜き出し、ちょっとお金作りに奔走してました(笑)


半年ほど留守にしましたが、お陰様でうん十万くらいのそこそこな資金は確保できたので。まあなんて言うか、いざと言う時の為の奥の手は持っておくもんです。

で、ようやくまとまったお金が手に入りました。そこで、子供が増えると部屋が狭くなるため、引越しをしました。

で、お引っ越しして子供たちも遊べる大きなお家、そして、公園やスーパーが近いという、子育てするにあたっての条件が整えられたのは良いのですが、買い物が多すぎる。

このお家、それなりに安くて大きいのは魅力なんですが、実際に住んでみると前とえらく環境が違うので、ちょっと困ってます。まず、インターネットないし(笑)


最近の新築って、結構至れり尽せりだったんだなぁと実感しているところ。前住んでたところは新築だったのよ。

また大きい買い物がいくつか必要なのでもう、お金がいくらあっても足りません(笑)結婚してから、生活環境整えるためにどんだけ使ってると思ってるんだか(笑)

まあでも、ようやく製作に戻ってこれたので。
幸いなのは、私のツクールはsteam版ではない事かな。

インターネットなしでも作れる環境なので、リハビリがてらこっそりとシステムを作り始めてます。


とりあえず、予告として。

ランダムエンカウントシステム
ゲーム内時間システム

この2つを作ってみました。
ネットが繋がったら、記事を書いていこうと思います。


ではでは、今日はこの辺で。
ネコタでした。
プロフィール

猫民のんたん

Author:猫民のんたん

ネコタ:ゲーム作りが趣味の薬剤師。本職とゲーム作りの2足の草鞋を履きこなそうと日々奮闘。

毎週曜日or曜日に更新予定。
-------------------------

ミノン:ゲーム作り初心者で2児の母。前職はSE/PG。子育てをしながらゲーム作りを行おうと、日々奮闘中。

育児中のため活動休止中

最新記事
最新コメント
月別アーカイブ
カテゴリ
フリーエリア
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QR
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。