スポンサーサイト

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

ゲーム制作日記<17> リージョン階層

op.png



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



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



今回紹介するシステムは、リージョン階層です。


前回のゲーム制作日記<16> リージョンコモンイベントの技術を応用し、リージョンによるエリアの区別を作ることで、疑似的な段差(階層)のようなものを生み出そう。そういう発想です。


アイディアが抽象的なので、ピンと来ないかもしれません。
例えば、こんな使い方があります。


tc16-1.png


崖の向こう側に、人がいます。
この男性は、プレイヤーにひたすら近づいてくるウザイ奴です。


tc16-2.png


しかも、崖の向こう側から話しかけてきます。
あろうことか、その態度はとても高圧的。

初対面のくせに「おい」とか言ってくる無礼っぷりです。


tc16-3.png


あんまりウザイので、プレイヤーはレバーを倒してリージョン階層のシステムを起動させます。


tc16-4.png


すると、どうでしょう。

彼は、向こう側から話しかけることが出来なくなったじゃありませんか。


tc16-5.png


気まぐれで、自分のエリアに彼を招き入れてあげたプレイヤー。
しかし、彼の態度は変わりませんでした。


おしまい。




というように、もともとの仕様では崖の向こうからでも接触されたらイベントが起動してしまいます。

ところが、こういう状況では困る!といったことが往々にしてあると思うんです。


それを解消するために、今回のシステムが利用できるわけです。



では、今回のシステムの仕掛けをみてみましょう。


tc16-6.png


このように、プレイヤーの居るエリアはリージョン12番となっています。


このリージョン12番イベントのいるリージョン外はシステムによって区別されているため、イベントの内容が働かない。そんな仕掛けです。

もちろん、最後に話しかけられたように、同じエリアにいればイベントは動くようになっています。



それでは、今回のシステムで必要なものの確認からいきましょう。




【必須】
変数 ×3 (プレイヤー位置X、Y、リージョンID格納用)
変数 ×3 (イベント位置X、Y、リージョンID格納用)
(他、MAP内で追加するイベントの数だけ変数×3が必要)


【推奨】
プレイヤー情報取得用コモンイベント




まずは、コモンイベントの内容を見てみましょう。


tc16-7.png


いくつか方法は考えましたが、今回は一番簡便な方法を紹介します。

はじめに、プレイヤーの位置情報を取得します。
コモンイベントで書いていますが、中身は下の通りです。


コモンイベント : プレイヤー情報取得
tc3-8



これでプレイヤーX軸の位置Y軸の位置を取得できたので、
指定位置の情報取得で、その場所のリージョンID変数プレイヤー階層に格納します。


指定位置の情報取得
tc16-9.png


同様に、注釈内のような形でイベントの位置情報を取得し、変数に格納。
それを使って指定位置の情報取得で、変数イベント階層に格納します。


あとは、これを対象となるイベントの数だけ書いていきます。



全マップに共通する内容であれば、コモンイベントを1個作ればよいですが、実際には全マップ共通にならないことの方が多いかもしれません。

対象のイベントIDが全MAP共通ということは無いでしょうし。


その場合は、


イベント
tc16-10.png


このように、並列処理プレイヤー位置とイベント位置を監視するイベントを各MAPに設置し、場所に応じて内容を変えてください。



これで、プレイヤーイベントリージョンIDは取得できました。
次は、実際の対象となるイベントの内容を見てみましょう。


ウザイ男
tc16-8.png


条件分岐『プレイヤー階層=イベント階層』の時にのみ、イベントの中身が起動するようにします。

こうすることで、接触判定自体は成立しても、条件が整わなければイベントの内容自体は動かないようにできます。



このやり方の場合の注意点ですが、
残念ながら立体交差のところでは通用しません

リージョンIDとしては、キャラクターの層が上だろうと下だろうと、同じリージョンを取得してしまいます。

これについて、何となく対処法の構想はありますが・・・
また必要になったら考えてみます。ちょっと、面倒くさそう。







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





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

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

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

続きを読む

スポンサーサイト

ゲーム制作日記<16> リージョンコモンイベント

op.png



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



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



さて、今回紹介するシステムは、
名付けてリージョンコモンイベント


・・・・・・って、
それ既にプラグインあるやんっ!


YEPさん作 : RegionEvents
tc15-8.png


いやー、そうは言いましてもね~。

このプラグインってば、プレイヤーが乗ったときしか起動しないじゃないですか?




と、勘のいい方なら気が付いたはず。




そう、今回のコモンイベントは、なんと、
プレイヤー以外が乗っても起動できます!


てか、コモンイベントでプラグインと同じ挙動のものを作っちゃった!(笑)


いやー、なんていうか。
やろうと思えば、こういうこともできるんですね。

コモンイベントって、すごいや~。



それでは、今回は使い道も思いつかなかったので(←おい)
適当に、お馬さんを走らせてみました(笑)


tc15-2.png


ここに、一頭のお馬さんがいます。


tc15-1.png


中身は、空っぽです。


tc15-3.png


それでは、このスイッチを押してみましょう。


tc15-4.png


ものすごく分かりづらいですが、
お馬さんが、高速でぐるぐると周回しています。




で、これがどういう構造をしているかというと、


tc15-5.png


実は、こんな感じ。
リージョン11番のところを、ひたすらぐるぐると回るようにイベントを組んでいます。



今回はスイッチを使って起動させましたが、スイッチの中身はこんな感じ。


スイッチ
tc15-6.png


変数リージョンIDを設定して、スイッチリージョン起動をONにします。

これにより、起動条件を満たしたリージョンコモンイベントが動きだし、お馬さんをぐるぐる回した。と、いうことです。



さて、リージョンコモンイベントの内容を見る前に。
まずは準備するものから。


【必須】
変数 ×4 
(リージョンID設定、リージョンID格納、イベント位置情報格納×2)






それでは、リージョンコモンイベントの中身を見てみましょう。


コモンイベント : リージョンイベント
tc15-7.png
tc15-9.png
マークからが続きです)


内容としては、そんなに難しくなかったりします。


まず、イベントの位置情報変数X・Yにそれぞれ格納します。
もう、ここら辺は常套手段ですね。

そして、指定位置の情報取得という、新しいコマンドが出てきました。


指定位置の情報取得
tc15-10.png


これはプレイヤー用に用意した変数だったんですが、イベントも動かせることに気が付いたので、そのまま流用しています。

変数X・Yの位置にあるリージョンIDを、変数リージョンID(player)に格納します。


その後、スイッチ起動の時に設定していた変数リージョンID(コモン設定)で指定したIDと、先ほど取得したリージョンIDが『等しいとき』という条件分岐を組み、中身に仕様を突っ込めば完成です。


今回の中身は、4フレームごとにお馬さん向きを判別して、任意の方向に向かせたのち一歩前進を繰り返す、というものでした。



今回はデモのため適当な内容にしましたが、これをうまく利用すると、

・イベントが指定位置にやってきたときに自動でストーリーが進む。
・イベントが指定位置に来た時に、プレイヤーが強制で動かされる。
・イベントの動きで他のイベントを制御する。

などのギミックも考えられます。



ちなみに、穴の上を通ることができなかった光イベントですが、このコモンイベントによって穴の上を通るように制御することも可能でした。ちょっとカクつくのはどうしようもなかったので、妥協しましたが・・・。


光イベント : 追記
tc15-11.png
tc15-12.png
マークからが続きです)
(スイッチは適当なのを使っています。というか、適当なのを今回のデモに使っています(笑))


このリージョンイベントですが、コモンイベントに入れなくても使えるので、このように光イベントに組み込んで使うことも可能だったりします。


また、マップ上にある他のイベントなどに並列処理で組み込んでも構いません。

そうすれば、起動条件はスイッチだけじゃなくて、
アイテムアクターだっていけちゃいます。


光イベント
tc15-13.png



思ったよりも応用の幅が広いですので、よかったら何かに利用してみてくださいね。




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





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

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

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

ゲームシステム制作日記


mp-title


 こんばんわ。ミノンです♪
 さてさて、ゲームシステム制作日記の第三段ですね。今回も宜しくお願い致しますm(_ _)m

 まずは、先週の宿題である「調合するためのレシピに必要なものって何でしょう?」についてです。皆さん、考えはまとまりましたか?

 私が考える「調合するためのレシピに必要なもの」とは...。
 ①調合で出来るアイテム名
 ②調合で出来るアイテムに必要な道具ID
 ③調合で出来るアイテムに必要な道具の数量
 ④調合のレシピ本のID

 上記の内容ですね。勿論、以下の事だって考えられます。
「調合する際に、道具だけではなく武器や防具を使って道具が作れるようにしたい!」「調合する際に、『大事なもの』の中にあるアイテムを使いたい!」
 これらについては、応用で出来るので応用編としてやってみましょうね。

 ではでは、早速作っていきたいと思います。


ちょっと待ったぁ

 その前に、Javascriptって皆さん知っていますかね...?

 恐らく、知らない方もいるかと思います。

 なので、次回からは作り方を解説 + ツクールmvでのJavaScript講座を行いたいと思います。
 要は、ツクールmvでのJavaScriptを作りたい人専用講座という所でしょうかね...。

 次回は、「gameItem」フォルダを新たに作って、その中に「PreparationItem.txt」を作ってその中に値を入れる事」を作ってみましょう!

 教え方としては、以下の方法を取ろうと考えております。
 ①まずは、私が作ったものを見せる
 ②その考え方を解説する

 この方が、作りたい方にとっては良いかと思いましてね…。

 では、今回はこの辺で失礼致しますm(_ _)m

 ではでは、ミノンでしたm(_ _)m

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

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

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

ゲーム制作日記<15> 風水システム

op.png



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



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



今回のシステムは、FF(ファイナルファンタジー)シリーズにあった、ちょっと微妙なあのシステム『風水』です。


FFT_Geomancer.jpg





『風水』とは、マップの地形に応じて効果が変わるスキルで、場所によっては混乱を与えたりストップを与えたりと、状態異常+ダメージを与えるアビリティ(スキル)です。



これが、使いづらくて(笑)
出てくる技も、地形によってランダムだし。


システム的には面白いんだけど、使い勝手が悪い&分かりづらいシステムだったので・・・

自分は原作ではあんまり使っていませんでした。



でも、個人的には面白いと思ったシステムなので、
私のゲームでは採用(笑)


システム的には風水と同じなのですが、
『暗技』というスキルにしようかと思っています。

(システムだけ先行して、他はまだ制作段階ですけど)



私の作品では「生きる為に何でも使う」というスタンスのキャラクターが使うスキルなので、何でも使うなら、地形すらも利用してやろうっていうね。


ハングリー精神が旺盛で、さらに応用力がある。その場にあるものを利用できる機転の利く性格だからこそ、図太く生きていける。そんな感じ。



ところで、FFの『風水』では、いくつか候補がある場合に攻撃がランダムで選択されてしまいます。個人的にはそこがちょっと煩わしかった。


なので、自作ではそれを撤廃して使います。
なんちゃって風水システムです。


まあ、ランダムにしようと思えばできそうですけど。
ご要望があれば、コメントにどうぞ。




それでは、今回のなんちゃって風水システムは、どういった挙動になるか見てみましょう。


例えば、これが森でのスキル選択画面。


戦闘 : 森
tc14-1.png


名前は適当ですが、草原用、森用のスキルが使えます。



例えば、水がある場所でのスキル選択画面。


戦闘 : 水上
tc14-3.png


水上や森でのスキルが使用可能になります。
草原用は、今回使えません。




例えば、火山でのスキル選択画面。


戦闘 : 火山
tc14-5.png


このように、場面によって使えるスキルが変わるという、ちょっと変わった戦闘スタイルのキャラクターに仕上がります。




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

【必須】
スキル  × いっぱい(必要な数だけ)
スイッチ × いっぱい(状況の数だけ)
コモンイベント ×2(スキル取得用、スキルリセット用)

【推奨】
コモンイベント(地形に合わせたスイッチ操作用)



では、作り方の紹介です。
システム導入にあたり、準備がたくさん必要になります。


まずは、スイッチを必要な数だけ準備しておきます。


スイッチ
tc14-15.png


スキルも、必要な分だけ用意しておきましょう。


スキルデータベース
tc14-16.png


これは必須ではありませんが、状況に合わせたスイッチONイベントコモンイベントとして作っておくと良いでしょう。


条件スイッチ
tc14-19.png
(コモンイベント:2バネッサ用暗技は後述します)


スキルをリセットするためのコモンイベントも用意しておきましょう。
操作中、いったん全リセットする必要があります。


コモンイベント : スキルリセット
tc14-8.png


準備は以上です。



ここからが、風水システムの内容になります。


コモンイベント : スキル取得用
tc14-11.png


自分の作品では、バネッサというアクターしかこのスキルを使いませんので、条件分岐を入れています。

なくても構いません。


内容としては、今持っているスキルを全リセットし、状況に合わせたスイッチがONであるときに、そのスキルを覚えていく。

それだけです。


戦闘テストではスイッチがONにならないので、このようにデータベースコモンイベントを起動させています。


データベース : 敵グループ
tc14-20.png



実際に使用する際には、


tc14-17.png

あるいは、

tc14-21.png


といったように、場所移動の際に設定しておくと良いでしょう。


ダンジョンの構成が変わるたびにこれを入れておかなければいけないので、導入は結構大変ですけどね。







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





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

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

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

ゲーム制作日記<14> 床スイッチ拡張

op.png


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



さて、今回は予告通り、床スイッチの拡張です。

前回のゲーム制作日記<13> 床スイッチで、仕組みと基本的な考え方をお話ししました。


しかし、全ての場合の数を並べて、ひとつひとつ考えて条件分岐を作っていたのでは、とても作業が大変です

(とはいえ、1つのスイッチに対して、5個も6個も対象が乗っかる場合を考える機会というのは、そう無さそうですけども)



そこで、今回は拡張の仕方を紹介します。

仕組みを理解すると、とても簡単な方法で条件分岐を作ることができます。


まずは、一番基本的な形


tc12-3.png


これの作り方は、以前紹介しましたね。


内容はこんな感じでした。

tc12-5.png


必要な物として、まずはプレイヤーの位置情報スイッチの位置情報を取得します。

あとは、条件分岐を組んで、プレイヤーの位置情報(X、Y)スイッチの位置情報(X、Y)一致する場合にのみイベントのセルフスイッチをONするだけ。



では、今度はプレイヤー特定のイベント(動く置物など)が乗った場合にスイッチがONになるようにします。


とりあえず、理屈はさておき。
まずは、作り方を説明します。


作成を始める前に、先ほどの内容を、作成するところとは別のページに作成しておいてください。


それでは、下の画像から始めていきます。

tc12-1.png


何もないところからで構いません。
最初に、条件分岐を選択します。

tc13-4.png


条件は、イベントのX座標の位置を格納している変数スイッチの位置を格納している変数にします。

条件を満たさないときの分岐を作成にチェックを入れておきましょう。


tc13-5.png


条件分岐を作成すると、以下のようになると思います。


tc13-7.png


次に、あらかじめ用意していた内容(条件分岐の部分から)をコピーします。


tc13-8.png


それを、先ほど作成した条件分岐『それ以外のとき』の下に貼り付けます。


tc13-9.png


これで、スイッチのX=イベントのXではないときが、完成です。



次に、スイッチのX=イベントのXの時(条件分岐の直下)を作成していきます。


まずは、先ほどと同様に条件分岐を選択します。


tc13-10.png


今度は、Y座標を指定します。
条件を満たさないときにもチェックを入れておきましょう。

すると、下の画像の青くなっている部分のようになると思います。


tc13-11.png


そして、先ほどと同様、あらかじめ作成しておいた内容をコピーします。


tc13-8.png


それを、作成したY座標の条件分岐『それ以外のとき』の下に貼り付けます。


tc13-12.png


その後、貼り付けたところから、条件分岐の内容だけをコピーします。


tc13-13.png


そして、Y座標を参照している条件分岐(一致する場合)の下に貼り付けます。


tc13-14.png


これで、16通り分の条件分岐の作成は完了です。

最後に、一番上に、必要な変数を取得しておくコマンドを入れておきましょう。

これ忘れると、動きませんからね(笑)


tc13-15.png




このように、前の内容を使いながら、ほとんどコピペだけで作成することができます。

しかも、これがどれだけ膨大な場合の数になろうとも、全て同じ操作で作成可能です。


これならば、作業が大幅に軽減されるうえに、小難しいことを考える必要もありませんね。




さて、とは言え。
理屈が分からなければ、誤作動を起こしそうで怖いですよね。

というわけで、ここからは、この作成方法で問題ない理由を説明します。



まず、スイッチの位置プレイヤー位置イベント位置が同じかどうか。
その場合の組み合わせは前回の記事で示した通り、16通りあります。


tc12-4.png


この図を、よーく見てみましょう。


tc12-3.png

tc13-2.png


分かりやすくするために、赤線で囲ってみました。

この部分は、プレイヤーだけの時と同じ組み合わせになっているのに気が付いたでしょうか。


そして、緑の枠の中をみてください。


tc13-3.png


この中には赤枠の内容が2つ入っていると思います。

そして、プレイヤーY○か×かに関わらず同じ構成になっているはずです。


さらに拡大して、全体像を見直してみてください。
緑枠の構成が、上下に1つずつあると思います。

しかも、プレイヤーX○×に関わらず同じ構成です。



このように、条件を1つ増やした場合、その○×に関わらず、その1つ前の内容がそっくり中に入っていくのです。


これで、全部コピペで作れるという理屈は分かっていただけたでしょうか。

ちなみに、プレイヤーX・YイベントX・Yの名前が逆になったところで、内容は変わりません。

名前がついてると少しこんがらがるので、単純に条件A条件Bみたいに考えて頂ければよいかと思います。



ところで、これだけだと条件分岐をたくさん作成していかなければなりません。が、それはそれで少し面倒です。

そこで、更に作業効率を上げるため、余計な条件分岐を省きました。



もう一度、16通りの表を見てみましょう。

tc13-3.png


緑枠のところですが、プレイヤーYが○のときは、それ以下の内容が○か×かかかわらず、判定はONになります。

つまり、プレイヤーXとYを参照した時点で、両方が○ならすでに結果は確定するという事です。

というわけで、下の内容ですが、


tc13-14.png


一番上の位置X・Yが共に一致する場合の内容は、スイッチONの操作だけでOKです。


プレイヤーY×(不一致)の時は、イベントの位置判定に依存するので、内容をコピペする必要があります。


次に、プレイヤーX×(不一致)の場合になりますが、そこの部分をよく見ると、プレイヤーYの○×に関わらず、下位の内容と判定が変わらないことに気が付くと思います。

よって、ここにはプレイヤーY条件分岐不要で、そのままイベントの位置を判定する内容(コピペした内容)でOKということになります。



ちょっと難しかったと思いますが、以上が、コピペで問題なく作れる理由となります。


更にイベントを増やし、スイッチの上にプレイヤー・イベント1・イベント2が乗った場合に・・・というものを作る場合。

同様の理由から、条件分岐で新しく追加するイベントの位置Xを作成し、プレイヤー・イベント1が乗った場合の内容をコピペしていく・・・という作業でサクッと完成します。



これなら、何通りの条件分岐になろうとも、楽に作成できますね!
(処理速度的にはどうなるか分かりませんけども)





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





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

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

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

ゲームシステム制作日記


mp-title


 こんばんわ。ミノンです♪
 さてさて、ゲームシステム政策日記の第二段ですね。今回も宜しくお願い致しますm(_ _)m

 先週から始まった「調合システム」の開発。まずは、おさらいとして主人であるネコタからのオーダーをおさらいしてみましょう。

 <調合システムについて>
 (1)調合のイメージは、アイテム同士をくっつけて新たなアイテムを作る事。イメージはFF10でいう、リュックの特技
 (2)調合するためには、レシピ本が必要。そのレシピ本が無いと、調合できないようにしたい
 (3)調合システム導入時から、調合が出来るようにしたい

 この内容を実現するためには、どういう考え方をすれば良いのでしょうかね…。私が考えた答えは、以下の通りです。

 (1)調合のイメージは、アイテム同士をくっつけて新たなアイテムを作る事。イメージはFF10でいう、リュックの特技
  ①アイテム同士をくっつけるという事は、そのアイテムを持っているかどうか確認をしなければならない
  ②アイテム同士をくっつけるという事は、何と何をくっつけるのか?調合のレシピを記載したものを何処かに保存しなければいけない
 
 (2)調合するためには、レシピ本が必要。そのレシピ本が無いと、調合できないようにしたい
  ①調合するために必要なレシピ本を入手しているかどうかの確認をしなければならない

 (3)調合システム導入時から、調合が出来るようにしたい
  ①調合するためのレシピ本を持っている必要がある
  ②調合する材料と調合できる内容を何かに保存しなければならない

 という事を考えました。さて、ではこれを実現するためにはどうすれば良いでしょうか…。私はこう考えます。

 <調合システム実現のために>
 (1)調合するレシピ本を、アイテムカテゴリ「大事なもの」の中にいれる必要があること
  ※アイテムカテゴリ「大事なもの」の中身は売れない為
 (2)調合するためのレシピは、「gameItem」フォルダを新たに作って、その中に「PreparationItem.txt」を作ってその中に値を入れればよい
(3)調合で必要なアイテムを持っているかどうか?については、既にあるメソッドを使用して確認する

 勿論、他の方法もあります。例えば...。
 (2)調合するためのレシピは、「gameItem」フォルダを新たに作って、その中に「PreparationItem.txt」を作ってその中に値を入れればよい
この方法の代替えバージョンとしては、アイテムのメモ欄に調合で必要なものを記載するというやり方もあります。

 さてさて、これらの方法を実現するためにはどうすれば良いか?という事ですが…。

 画面を作る上で、先に必要なシステムを作ってしまいましょう♪
 
 そのシステムとは、「(2)調合するためのレシピは、「gameItem」フォルダを新たに作って、その中に「PreparationItem.txt」を作ってその中に値を入れればよい」です。

 調合するためのレシピ本が無ければ、調合システム自体動きませんものね…。

 という訳で、このシステムを作ってみたいと思います。

 ではでは、調合するためのレシピに必要なものって何でしょう?さあ、皆で考えようm(_ _)m
 
 答えは、次のブログ記事でお伝えしますね。

 ではでは、ミノンでしたm(_ _)m

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

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

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

ゲーム制作日記<13> 床スイッチ

op.png


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


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



今回のシステムは、床スイッチです。


え、床スイッチなんて、簡単だって?


だって、こうすれば作れますからね。


床スイッチ
tc12-7.png



いやいや、そんな普通の床スイッチだったら、わざわざこうしてブログなんて書きません




私が作る床スイッチは、これです。


床スイッチ : 1ページ目
tc12-1.png

床スイッチ : 2ページ目
tc12-2.png



なんにも書かれていないフォーマットです。
ただ、ウエイト15しているだけ・・・

ですが、よく見てください。


トリガーが『並列処理』になっています。


このスイッチ。
実は、自動で他のイベントを動かすための床スイッチです。


ほら、よくあるじゃないですか?
スイッチを踏んでいる間だけ開く扉とか。

あれを実現させるためのスイッチになります。



というわけで、今回のシステムは
スイッチ扉用の特殊なスイッチのご紹介です。


まずは、必要なものの確認です。



【必須】
変数 ×4 (プレイヤー情報格納用、床スイッチ位置情報格納用)


【推奨】
プレイヤー情報取得用コモンイベント
スイッチ挙動用コモンイベント



プレイヤー情報取得用コモンイベント
tc3-8


スイッチ挙動用コモンイベントの例
tc12-8.png


上記のようなコモンイベントを用意しておくと、製作が楽になります。
色んなところで使えるので、作っておくと損はないですよ。




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


床スイッチ : 3ページ目
tc12-5.png

床スイッチ : 4ページ目
tc12-6.png


内容としては、それほど難しくありません。


3ページ目の内容から解説します。

まず、プレイヤーの位置情報(X、Y)と、スイッチの位置情報(X、Y)を取得し、変数に代入します。

あとは、条件分岐プレイヤースイッチ位置(X,Y)が一致している時に、セルフスイッチをONにするだけです。

何か他の仕様がある場合には、一緒に書き込んでおくと、スイッチONによりイベントを起動させることができます
(例えば、扉が動くためのスイッチをONにするとか)


4ページ目の内容は、3ページ目のスイッチOFF版。

プレイヤーが乗っていないときに、セルフスイッチをOFFにします。


あとは、これを先ほどのフォーマット(1ページ目、2ページ目)にコピペでドーン!


床スイッチ : 1ページ目
tc12-9.png

床スイッチ : 2ページ目
tc12-10.png


終わりです。




内容としてはこれだけなのですが、このスイッチを作るときの
考え方が、結構ややこしい


今回は、プレイヤーが乗っているとき・降りた時の分岐なので、内容は単純です。

ところが、これが他のイベントorプレイヤーが乗っているとき・降りた時の分岐は、すぐに作れるでしょうか?

そのイベントが複数ある場合条件分岐は、さらに複雑になってきそうではありませんか?


今回は、その考え方の基礎も紹介します。


まず、床スイッチの位置に対して、プレイヤーの位置の組み合わせがどのようなパターンになっているのかを考えます。


以下の図が、その一覧表です。

tc12-3.png

○ = 床スイッチと対象(プレイヤー)のX軸あるいはY軸が一致している。
× = 上記が一致していない。
判定 : スイッチがONになるかOFFになるか。




床スイッチの位置に対して、プレイヤーのX軸の一致か否かで2通り
プレイヤーのY軸の一致か否かで2通り

2通り × 2通り = 4通り

の組み合わせとなります。


スイッチがONになる組み合わせは、プレイヤーの位置XYが共に○(一致)している時のみです。

プレイヤーの位置XあるいはYのどちらかが×(不一致)の場合は、もう片方が○(一致)だろうが×(不一致)だろうが、スイッチはOFFとなります。



それでは、今度は一段階レベルが上がります。
たった一段上がるだけで、一気にレベルが高くなるので覚悟してください。

今度は、床スイッチに対して、プレイヤー(PL)あるいは他のイベント(EV1)がのっかった場合の組み合わせです。


tc12-4.png


組み合わせは、プレイヤーの位置Xの一致あるいは不一致で2通り、プレイヤー位置Yで2通り、イベント位置Xで2通り、イベント位置Yで2通りですから、

2×2×2×2 = 16

全部で16通りになります。


もう、この時点で条件分岐を組むのが嫌になりますよね。
すごく難解になりそう(笑)




次の段階は、イベントがもう1個追加になったパターンですが、これは

2×2×2×2×2×2 = 64

64通りの条件分岐とか、もう考えるのも嫌なレベルです(笑)




ちなみに、更にもう1個イベントを増やすと、256通りになります。
もう、考えられないレベルです(笑)



ですが、発想を転換すると、これらも簡単に作ることができます。
それどころか、もっとたくさんの数であっても扱うことができます。



次回は、その方法を説明しましょう。





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





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

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

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



ゲーム制作日記<12> レーザー発射&位置交換

op.png


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


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



今回は、自分自身、こんなのがあったらいいのになぁ~って思っていたシステム。
レーザー発射システムによる位置交換システムです。


実は私、ヴァルキリープロファイルシリーズが大好きでして。
光子のようなものができたらいいなぁ~。
誰かプラグイン作ってくれないかなぁ~。
なんて、思ってました。


自分で開発しといてなんですが、まさか、普通のイベントを使って作れるとは思ってなかったです(笑)



それでは、どのような挙動をするのか見てみましょう。


まず、普通にを撃ちます。


tc11-5.png


の向かった先には、銀色の像がありますね。
このがぶつかると、


tc11-6.png


光の柱のエフェクトが現れました。
そして、


tc11-7.png


プレイヤーの位置が、交換されました。


おお、すごい。
これだよ、私が求めていたものは(笑)




ところで、すんごい今更なんですが。

コモンイベントを使って~シリーズなのに、この光イベントって、コモンイベントじゃないことに気が付きました(笑)

まあ、フォーマットがあるし、
コモン化されてるようなもんですけどね。






閑話休題。
それでは、イベントの中身を見る前に、まずは必要なものの準備から。


【必須】
エフェクト用の空イベント ×2
変数 ×1(マップID格納用)
光イベント


光イベントの確認をしたい方はこちら↓
ゲーム制作日記<9> レーザー発射(発射台→プレイヤー)



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


光イベント : 11ページ目
tc11-11.png
tc11-12.png

マークからが続きです)



内容は少し濃いですが、ほとんどが演出の内容です(笑)



まず、いつものごとく、トーチの位置情報を変数に格納し、イベントの位置を引き算します。

そして、条件分岐X座標Y座標向きを指定します。

ここについては、前にも説明した内容なので端折りますね。
(要するに、光が対象に突進してきたとき、という内容になります)


詳しく内容を確認したい方はこちら↓
ゲーム制作日記<8> レーザー発射&反射


条件分岐の中身に入りますが、
まず、マップID格納用の変数に、マップIDを格納します。

tc11-8.png


ゲームデータのところをクリックすると、以下のダイアログが出てきます。この操作で、現在のマップIDを取得できます。


tc11-9.png


次に、位置情報用の変数(X、Y)トーチ(対象物)位置情報(X、Y)を格納します。同時に、プレイヤーの位置情報を取得しておきます。


ここから、しばらくイベントの演出になります。


まず、移動ルートの設定 : このイベント : 透明化ON (ウエイト) をしておきます。

処理中はイベントが消失ポイントまでいかないので、勝手に消えてくれません。なので、この処理で一時的に見えなくしておく必要があります。(処理が終わると、勝手に消失します)

そして、エフェクト用に用意していた2つの空イベント(画像なし)トーチ(対象物)プレイヤーにそれぞれ移動させます。

その後、移動ルートの設定でエフェクト用画像を光の柱に変更します。
この際、1個目のエフェクト用の処理には「完了までウエイト」にチェックを入れません

完了までウエイトを入れない場合、その下のコマンドが同時に処理されます。

エフェクト用画像を同時に変更したいので1個目のエフェクト用にはウエイトを入れませんが、変更が終わるまでは処理を進ませたくないため、「2個目には完了までウエイト」にチェックを入れておきます

画像の処理が終わったら、移動ルートの設定 : トーチ で10フレームのウエイトを入れた後に透明化ONして、画像を一時的に消します。ここも、「完了までウエイト」を入れません


10フレーム待ってもらっている間にプレイヤーとトーチの位置を交換します。


tc11-13.png


場所移動プレイヤー変数X、Y(トーチの位置を格納した変数です)に飛ばします。フェードなしにするのを忘れないでください。


tc11-14.png


同時に、トーチプレイヤーの位置に移動させます。

そして、先ほどのトーチの透明化を外します。



最後に、エフェクト用の画像を消去しておしまいです。



さて、これで位置交換用のフォーマットができたので、ページの内容を件の光イベント2ページ目にコピー&ペーストします。


光イベント : 2ページ目(コピペ前)
tc11-15.png


光イベント : 2ページ目(コピペ後)
tc11-16.png



初期の状態で作っている場合は、発射開始位置をプレイヤー起点にしておくのも忘れないようにしましょう。


光イベント : 2ページ目(起点)
tc10-4.png


そして、忘れてはいけないのが、これ。


光イベント : 2ページ目(透明化OFF)
tc11-17.png



イベントの頭の方に、移動ルートの設定 : このイベント : 透明化OFFを挿入するのを忘れないようにしましょう。

処理が終わるまで消した光を戻したくないので、光が透明になりっぱなしですから。



今回は例として一方向のみ作りましたが、実際に使う場合はコピペして4方向作成しておきましょう。








ところで、今回のシステムを作成して気が付いたことなのですが。
この光イベント、なんと、穴の上を通過できません!
(結構、致命的ですw)



なので、穴の上を通過させたりなんだりする場合は、下のyanflyさんのプラグインを導入する必要があります。

Region Restrictions
tc11-18.png

(たしか、ツクールMV購入時に同梱されているかアップデート時に追加されてるプラグインだったと思います。それか、サンプルゲームの中で使われているものです)


ただ、これだとシンボルエンカウントなど動くイベントと併用している場合に、それまで一緒に通れてしまうという弊害があるんですよね・・・。



一応、レーザー発射の技術を応用して通過させることができなくもないのですが・・・少々カクカクするのが玉に傷。






というわけで、非常に惜しいところでイベントの限界を感じたので、妻に専用プラグイン作成を依頼しました(笑)
そのうち、アップしてもらおうと思います。




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





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

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

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



ゲームシステム制作日記

 お久しぶりです。ミノンです♪

 結構お久しぶりになってしまいました(;´・ω・)待っていてくれた皆さん、すみませんです(;´・ω・)

 これからは週一回のペースで更新していきたいと思いますので、何卒宜しくお願い致しますm(_ _)m

 ではでは、早速ゲームシステムを作りましょう♪


mp-title



 今回、皆さんと一緒に作ろうと思っているシステムは…。

「調合システム」


 今、主人のネコタが作っているゲームでも使われている「調合システム」。これを一緒に作ってみましょう♪

 では早速…。と行きたいのですが、それは難しい注文なんですね…。

 まずまず、システムを作る上でおおざっぱで良いので以下の事を考えてください。

<考える事>
 ①調合システムってどんなシステムなのか?
 ②調合する際に何が必要なのか?

 ①について。どういうシステムが欲しいのか?きちんと整理する事が必要です。
 (1)どんな機能があるのか?
 (2)どういうレイアウトが良いのか?
 
 ②について。調合する際に、何が必要なのか?アイテムだけで調合するのか?など、調合をするうえで何が必要なのか?きちんと整理する事が重要です。

 ではでは、主人であるネコタからのオーダーを見てみましょう。

 <調合システムについて>
 (1)調合のイメージは、アイテム同士をくっつけて新たなアイテムを作る事。イメージはFF10でいう、リュックの特技
 (2)調合するためには、レシピ本が必要。そのレシピ本が無いと、調合できないようにしたい
 (3)調合システム導入時から、調合が出来るようにしたい

 まあ、当時は色々オーダーがありましたね…。

 さてさて、ではこのオーダーを叶える為にはどうすれば良いでしょうか?さあ、皆で考えようm(_ _)m

 答えは、次のブログ記事でお伝えしますね。

 ではでは、ミノンでしたm(_ _)m

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

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

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

ゲーム制作日記<11> TP式

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


ツクールMVには、戦闘中にいくつかのパラメーターが用意されています。

デフォルト設定で、3つのゲージが用意されているのがわかるのがわかるかと思います。

tc12.png


HP、MPは言わずもがな。

・・・で、TPって、なんぞや?


このTPというのは、正式にはタクティカルポイントと呼びます。
用途は特に決まっていません(笑)


ただ、デフォルト設定でいくつか仕様が決まっています。

0~100の範囲で変動する。
戦闘開始時に0~24でランダムに設定。
HPの減る割合に応じて、TPを獲得する。(最大HP100%ダメージで50獲得)


更に詳しくは、下のサイトを参考にしてください。
MVでも仕様はVX aceと同じなようなので。

昨日の全体回復魔法の制限としてTPを使うのはどうか、ということを書いたので今回はRPGツクールVXAceのTPの仕様を調べてみました。簡潔にまとめるとⅠ.TPが増えるとき・・・  
ツクールVX Ace TPのデフォルト仕様研究



このTPシステムですが、一般的な使い方は、スキルの使用に制限をつけるために用いられることが多いと思います。

例えば、MPの代わりとしてTPを使用する。あるいは、強力なスキルがあり、TPがある程度溜まらないと使えないようにする、など。


他にも、考えてみると幾つか面白い使い方があるかと思います。
私もアイディアはいくつか考えてみましたが、今回制作しているゲームのために開発した使い方をご紹介します。


私のゲームでは、戦闘での基本ダメージ計算式にTPを組み込んでみました。

名付けて、TP式です。

式の内容は、

a.atk * ( a.atk + a.tp ) / ( b.def + b.tp )

a.atk = プレイヤーキャラの攻撃力
a.tp = プレイヤーキャラのTP
b.def = 敵の防御力
b.tp = 敵のTP



どういう式かというと、まず、基本のダメージはa.atkです。
つまり、プレイヤーの攻撃力ですね。これが、そのままダメージになります。

これに補正値をかけてダメージを変動させるわけですが、
その補正値が ( a.atk + a.tp ) / ( b.def + b.tp )となります。

これは、プレイヤーの攻撃力にTPを足した値と敵の防御力にTPを足した値のになります。


例えば、プレイヤーの攻撃力が100として、現在のTPが50としましょう。敵も同様に防御力100に現在のTPが50である場合、


(100+50)/(100+50)=1


となります。a.atk=100ですから、最終的なダメージは、


100×1=100


というように、お互いの条件が同じであれば与えるダメージは攻撃力そのままとなります。



しかし、状況は刻一刻と変化していきます。
TPは敵の行動、味方の行動によって常に変化していく値です。

敵からの集中攻撃を受け、プレイヤーのTPが80、敵のTPが55くらいになったとしましょう。

すると、先ほどと状況は変わり、


(100+80)/(100+55)=1.16
100×1.16=116


このように、与えるダメージが大きくなりました。



また、極端な状況を想定してみましょう。

プレイヤーのTPが100、敵のTPが0の場合。
理論上の最大ダメージとなりますが、


(100+100)/(100+0)=2
100×2=200


最大2倍のダメージとなります。
スキルも使ってないのに。


これが、もっともっと序盤で、プレイヤーの攻撃力が20、敵の防御力が20といった、数値が小さい場合は、どうなるでしょうか。
理論上の最大値を考えてみると、


(20+100)/(20+0)=6
20×6=120


最大で6倍のダメージとなります。


このように、攻防がまだ低いゲームの序盤においては、TPがかなり物を言う仕様となります。


TPの性質上、ダメージを受ければ受けるほど、TPはすごい勢いで溜まっていくことになります。

そうなると、プレイヤーが運悪く総攻撃を受けて一瞬で瀕死になったとしても、これだけ攻撃力が上がると一撃で逆転のチャンスが出てくる。そういう仕様となります。



ところで、ゲームの終盤になってくると、攻撃力が高くなってきます。
すると、式からはTPの影響力は少なくなってくるように見えます。


例えば、味方の攻撃力1000、敵の防御力1000としましょうか。
理論上の最大ダメージは、


(1000+100)/(1000+0)=1.1
1000×1.1=1100


それでも、10%くらいは上乗せされますが、最初に比べるとかなりインパクトは小さいですね。


しかし、ゲーム終盤ともなれば、ステータスUP&DOWN系のスキルも頻繁に出てくる時期です。

大抵のRPGでは中盤以降贔屓にしていたステータスUP系も、終盤ではそれほど威力を発揮しないことが珍しくありません(他のスキルが圧倒的に強かったりするため)。

しかし、この式ではこの手のスキルが猛威を振るいます


例えば、攻撃力を20%増しにしてみましょう。
敵と味方のTPは50とします。


(1200+50)/(1000+50)=1.19
1200×1.19=1428


ダメージは1.4倍になりました。



今度は、敵の防御力を20%下げてみましょう。


(1000+50)/(800+50)=1.24
1000×1.24=1240


ダメージは1.2倍くらいになりました。
これくらい上がれば、スキルを使ったことによる効果も実感できるでしょう。


このように、ステータスUP&DOWN系にも対応した式となっています。



さらに、まだあります!
この式は、もう一段階奥が深くなっている仕様なんです。


究極に攻撃、防御を操作した時
つまり、攻撃力をとんでもなく上げたり、防御力を1にしてみたりということをした時。

ものすごいインフレが起きるのが、この式の面白いところです。
なんと、ダメージインフレにも対応しています。


仮に、攻撃力を10倍にしてみましょう。

(10000+50)/(1000+50)=9.57
10000×9.57=95700

攻撃力10倍にしたら、ダメージは95倍になりました(笑)


今度は、防御力を1にしてみましょう。

(1000+50)/(1+50)=20.6
1000×20.6=20600

ダメージは20倍です(笑)


防御力を極端に低くすると、最初のTPによる補正が復活してきます。
ということは、防御力1にするスキルなんか使用したものなら、ひとつの戦闘内でとんでもないダメージの振れ幅になってきます。

究極の状況として、プレイヤーのTP100、敵の防御力1、TP0の状況を考えてみると、

(1000+100)/(1+0)=1100
1000×1100=1100000

110万ダメージになりました(笑)
多分、ここまでくると(敵のHPが)カンストしているので、瞬殺されます。プラグインで最大値を増やさないといけなくなりますね。


この状況で、敵のTPが10増えるだけで、計算上はダメージが10分の1になります。

防御力が小さい状況でのTPは非常に重要な意味を持ちます。
この手のスキルが横行する戦闘では、TPの重要性が一気に高まることになりますね。



以上が、TP式となります。

序盤から終盤まで、さらに戦闘中というリアルタイムにも対応した、幅広い戦術を扱えるようにした式です。



TPの使い道はほかにもたくさんありそうです。
みなさんも、特徴を理解して色々試してみてください。



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





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

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

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





プロフィール

猫民のんたん

Author:猫民のんたん

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

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


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

毎週曜日にブログ更新予定♪

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

この人とブロともになる

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