ウディタでのシナリオフラグ管理を簡単にしてみる

前にちょこちょこ作ってたコモンが一応完成形になったので、
使い方を書いてみます。

イベントバラバラ状態

ウディタって、なんにもしてない状態だと
シナリオフラグの管理がしにくいんですよね。
このイベントの条件なんだっけ、とか。どこからこのイベント繋がってるんだっけ、とか。
私も一回ぐっちゃぐちゃになってエターなったことがありました。


イメージ

そこでこんな風に構造化してしまおうというのがこのコモンとDB

シナリオというのは一応一つ一つのイベントの間に何らかのつながりがあるのが普通だと思うのですね。
川に行く→桃が流れてくる→割る→子供が出てくる、みたいに。
この形でフラグを整理してみようというコンセプトです。

もちろん、一本になっていなくて、
複数のラインがあるとか、分岐・合流するシナリオにも対応できます。

これをやるには頭の中である程度シナリオができている必要がありますが、
フラグ管理自体はだいぶ楽になるのではないかと思います。



久々に人様の役に立てそうなコモンができたので張り切って画像つき導入説明書を書いてしまいました。
ウディタのサンプルゲームを題材に説明させていただきます。
導入のしかた
【DB側の設定】
手順1
・可変データベースのあいているところにフラグリスト.dbtypeを読み込みます


手順2
・「タイプの内容設定」を開いて、項目名2「接続元のフラグ」の「▼特」を開いてください
 「可変DB のタイプ『○○』番」のところを、フラグリスト.dbtypeを読み込んだタイプ番号に書き換えてください。
 (例:21番に読み込んだらタイプ21に書き換える)


手順3
・全シナリオフラグをフラグリストに打ち込みます。フラグ名は「数字だけのもの」「まったく同じもの」を避けてください。
 一旦csvに書き出してエクセル等で打ち込むと楽でしょう


手順4
・シナリオフラグを接続していきます。「接続元のフラグ」を入力してください
 (例:Aイベントが終わったらBイベントへ…という場合、Bイベントの接続元にAイベントを指定)
もちろん、前のフラグと何のつながりもなければ「なし」のままでかまいません。



【コモン側の設定】
手順5
・コモンイベントのあいているところにフラグチェッカー.commonを読み込みます。
・「入力の数/結果を返す」のところの「設定」を開いて、数値1の参照データベースを先ほどと同様にフラグリスト.dbtypeを読み込んだタイプ番号に書き換えてください。(例:21番に読み込んだらタイプ21に書き換える)



【イベント側の設定】
手順6
・フラグを立てたいイベントでコモンを呼び出します。「フラグチェッカー」を名前で呼び出ししてください。
 呼び出したいフラグと「やること」を設定します。「やること」は普通は1のままでいいと思います。
・返り値をイベント側の好きな変数に読み込んでください。返り値が0以下ならフラグが立つときのイベントを用意、 それ以外なら通常時のイベントを用意します。





もう少し具体的な使い方については追記で。
で、これはどう使うかといえば
基本的にはイベントの頭で呼び出して、
「フラグが立てられる状態かどうか」を判別し、可能なら立てます。
立てられないならその理由も返します。
イベント設置の段階
「ええっと、前のイベントどこだったっけ」
「ええっと、何が何個あったら通れるんだっけ」
悩まなくてもいいのがミソ(シナリオ設計段階では大いに悩んでください)。

「フラグが立ったか否か」はデータベースに、「既読かどうか」はコモンセルフ変数に格納されているため、
周回時にデータベース側を初期化することで「フラグは立っていないが既読」の状態を作り出せます。
これによって「既読イベントをスキップしつつ、フラグを立てること」が可能になります。
このコモンにおいて「既読」というのは周回のためにある概念だと思ってくださればいいと思います。

たとえば、分岐するイベントの作り方
分岐説明

分岐はそんなに難しくありません。
ひとつの接続元に二つのイベントを接続するだけです。



分岐説明分岐説明

分岐したときのフラグAとBを両方前のイベントに繋いで…


分岐説明

一番手っ取り早い分岐が選択肢なので選択肢を使っていますが、
この場合は選択肢の中でそれぞれチェッカーを呼び出せばいいです。



追加条件について
追加条件(接続元イベントを2つ指定したい、レベルを条件にしたい)がある場合、追加条件を設定できます。
追加条件に使う変数・a,b,c値・閾値・条件を放り込むだけです。
(例:基本システムでキャラクター0がレベル10以上ならイベントAのフラグを立てたいとき、
イベントAの追加条件は上から「1100:CDB」「0」「0」「4」「10」「1:以上」になります)

基本的にはCDBを使えば事足りると思います。

弱点
条件判定の際にデータベースや変数一発で判定できるものしか追加条件にできないところがウィークポイント。
説明用の画像を見て、「あれ、サンプルゲームのパン屋さんがいない」と気づかれた方もいらっしゃると思いますが、
あのイベントのように「主人公がある技能を持っているかどうか」のような複雑な条件は判断できないわけです。
そこら辺は素直に別のコモンで判定して分岐していただくしかありません。

返り値の意味
 8のビット満たす=追加条件1不足
 4=接続元未読
 3=接続元未立
 2=日数不足
 1=このフラグ既立
 0=フラグ立て可
 -1=スキップ
 つまり返り値を8で割った余りが3以下なら接続元既読ということになります。
 「やること」が0ならフラグを立てずに返り値のみ取得できるので
 「接続元を読んでいれば出現するイベント」などにどうぞ。

ここで、「日数」ってなんぞと思われると思いますが、
デフォではプレイ時間(sys変数29[読]プレイ時間(1秒単位))を使ってフラグを立てています。
これによって、「接続元フラグが立ってから100秒経たないと発生しないイベント」などが作れたりします。
「日数」になってるのは元々プロトタイプでゲーム内日数を入れていたからですが、
改造される際(コモン142,182行目)もおそらくここは日数が入ることが多いだろうなぁと思って説明文はそのままにしてあります。
(なんか他にいい呼び方ないかなぁ)

検索機能
コモンの「やること」を-1にして呼び出すとコモンセルフ側のログを検索できます。
例えば「END」を含むフラグが「END1」「END2」「END3」の3つあったとして、
「END1」で検索すれば「END1」というフラグを立てた回数が分かりますし、
「END」で検索すれば「END」を含むフラグを立てた回数が分かります。周回カウントなどにどうぞ。

このコモンとDBはこちら
関連記事
スポンサーサイト

Comment

Comment Form
公開設定

Trackback


→ この記事にトラックバックする(FC2ブログユーザー)
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。