現代和風RPG開発日記2017[No.5774]

 舌の根が乾かぬうちに二転三転するが、前述の左右分離方式だと画面外の移動が多くて無駄なので、結局D1D2は一体化させることになった。
 この方式だと、軌跡は8の字に似ているけど交差しない。鉄アレイのような蝶々のようなリボンのような…そんな形を描く。中央の部分が横に長くて画面内に入ることになるので、これらのたとえだと鉄アレイに最も近いか…。移動コマンド総数は200を超えてしまうので、イベント1ページでは収まり切れない。画像の切替があるので最初からそのつもりであった。
 さて、今回は左右の画面外の移動が共通で、画面内の移動はスイッチでページを切り替えて画像を変更しながら、コピペで同じ軌跡を描く方式を採用する。今までやったことが無いのでまずはテストから始まったが、またしても未知の仕様により試行錯誤を繰り返したのであった。

現代和風RPG開発日記2017[No.5773]

 D2はD1より更に手前に配置される。、D1が左から右へ画面上を水平移動するのに対して、D2は逆に右から左へ移動する。
 計画当初、D1とD2は1本の軌跡でループさせる予定だった。言い換えれば、D1で右へ移動して画面右外へ出た後、画像を切り替えて進行方向を変えて、今度はD2で左へ移動して画面左外へ出た後、画像を切り替えてD1に戻る…これの繰り返しである。
 テストではこれでも十分動作するのだが、方向転換が必要だし、軌跡の設定が少々面倒になり
そうなので、D1とD2を分けてそれぞれ一方通行で2つのループを描く方式とした。こうすると軌跡が長くなるのでマップの寸法を大きくする必要があるが、処理落ちするほどの影響は無いだろう。

現代和風RPG開発日記2017[No.5772]

 C1のイベント配置がとりあえず済んだので、1段階手前に表示されるD1の配置が始まった。こちらはABと同様に画像が大きいので、動作指定の設定も再び難儀なものとなる。てなわけで、作業の流れも同様に進めることにした。
 まずはイベントの移動ルートとなる軌跡をマップ上に描く作業から始まった。やはり3列で整列させながら動かすことになるが、画面上ではABが縦方向へ動くのに対して、Dは横方向への移動となる。イベント1個当たりの画像が1マス分しか無いので、ABと違って1マス間隔の空白が無い。とはいえ、1つの大きな画像に対して多くても十数個のイベント配置で済むので、さほど面倒にはならないだろう。後は1個のイベントを動かしてテストして、問題無ければコピペで調整しながら配置を増やしていけばよい。

現代和風RPG開発日記2017[No.5771]

 チームプレーのスポーツでは、選手層が薄いほど不利になる。それはともかくとして、たとえエキストラの通行人といえども、同一人物を何度もマップ上に出してしまうと、いかにも「ツクール製のフリゲですから…」な苦し紛れの演出になってしまう。それでも用意できるキャラ素材の数には限界があるし、常時並列処理で動きを止められないから、ある程度ループさせれば再び同じキャラを登場させなければなるまい。それを極力目立たせないようにするにはどうすればよいか?ループに気付かないぐらいに大量のエキストラを導入させるしかない。
 月本國素材の16規格歩行グラはそれなりの数があるものの、実は年齢層や職業によって数にばらつきがある。今回使うような演出では普段着レベルでよいのだが、これが思ったより少ないらしい。又、道路を通行するのは歩行者だけでなく自転車もそれなりの数が居るはずだが、この素材がまた絶望的に少ないではないか…。ここは演出用なので律儀に4方向用意する必要は無いので、急ごしらえで量産させてみるか…。

現代和風RPG開発日記2017[No.5770]

 AとBはイベント制御でスイッチをONにするとマップ上に出現し、移動して画面外へフェードアウトするとOFFになる仕様である。よって意図的にONにしない限り並列処理は発動しない。それに対してCとDは、あらかじめマップイベントエディタの「移動タイプ」で「移動ルート指定」を選択し、「移動ルートの設定」で指定したルートを延々と移動している。言わばマップにおける川の流れや波の動作のようなものだが、ここでもまた一筋縄ではいかない制御になっている。
 CとDの動作をばらしてしまうと、移動ルートは延々と同じでも、画面外へフェードアウトしたら別の画像に切り替わる動作を繰り返すことになる。たとえるならば、一度舞台へ出たキャラが裏方へ隠れると早着替えを行って再度舞台へ立つような、そんな動作になる。
 だけど画像が毎回変わるとなると、同一人物が何度も舞台へ出るわけでなく、全く別の人物が入れ替わるように見えてしまう。何人ものキャラを1つのイベントの制御で往復させることになるが…ありゃ、既にばらしてしまっているではないか!?そう、CとDはマップ演出におけるエキストラの通行人なわけである。

現代和風RPG開発日記2017[No.5769]

 CとDの構築によってスイッチの数が足りなくなったので、新たに数百個ほど追加することになった。ツクール2000はMAX5000個用意できるので容量には全く問題無い。どうせツクールを扱うのもこれが最後だし、一切ケチることなく使い込むとしよう。用途は全部共通なので、名前は全部同じでコピペしたが、IDが異なっているので区別は付く。かくしてスイッチの準備ができたところで、C1から順番にマップイベントを構築することになった。
 ところで、もしウディタならば、こんな大量のスイッチを用意する必要も無く、大幅に少ない数の変数で済んでしまうところである。(そもそもウディタにスイッチは存在しないのだが…。)ツクールではマップイベントページの開始条件で、変数がどうにも使いづらい。今回は構築上イベントページの数だけスイッチが必要になるので、10ページあれば10個のスイッチが必要になり、そのイベントを10個配置すれば100個のスイッチが必要になる…という計算である。こんなことをしていたら数百どころでは済まないかもしれないが、そこは適当な数で切り上げるとする。

現代和風RPG開発日記2017[No.5768]

 AとBに関してはまだ計画通りの完璧な仕上がりとは言えないが、正常に動作するものを組み合わせればそれなりの演出になるので、時間に余裕があれば更に突き詰めるとする。とはいえ現状でそれは厳しいので、次なる行程へ進むことにする。
 てなわけでイベントを動かすのはAとBだけでなく、引き続きC1・C2、D1・D2の設定に取り掛かっている。最終的にはABCDのイベントが同時に動くことになるわけだが、正常動作するかどうかはやってみなければ分からない。今の一般的なPCの性能ならば問題無いと思われるが、さてどこまで作り込めるのやら…!?
 このCとDだが、表示優先順位を考慮すると、C1<D1<D2<C2の順に構築する必要がある。マップのY座標の大きい順に並べるとこうなるわけで、別に順番が入れ替わっても問題無いのだが、マップのIDの管理も考慮してセオリー通りに進めるとする。

現代和風RPG開発日記2017[No.5767]

 A1に対してB1とB2を片方又は両方組み合わせる分には正常に動く。一方、A2に対してBを1つでも追加するだけで拒絶されるらしい。更に検証したところ、Aの画像切替が動作不良を引き起こす原因であることも分かった。A1・A2に対してそれぞれ全く画像切替を行わないでテストしたところでは、すべての組み合わせに対して正常に動作したのであった。
 う~む…やはりマップイベントが数百にも及ぶとなると、画像の切替はシステム制御に負担を及ぼすことになるのか…? とはいえ、A1は正常でもA2に限って動かないというのは、どうにも釈然としない。
 更に色々と検証しているが、これ以上時間を費やすのも現実的とは言えない。既に妥協案は色々挙がっているので、それに取り掛かった方がいいかもしれない。それでも未解決のまま逃げたくないのもまた本音である。

現代和風RPG開発日記2017[No.5766]

 Aの方はイベントの数が多いので、複数のページを用いて途中でフラグ制御にて画像を切り替えている。一方、Bはそれを行わずに終始1枚の画像のみである。
 一度に4個同時に動かすのでは無理があるので、ここは順を追って2個同時から検証してみる。
まずはA1とA2で試したところ、正常に動いた。次にB1とB2でもやはり正常に動いた。どうやらコマンドの数にミスは無いものと思われる。次にA1とB1を同時に動かしたところ、これも正常…。
A1とB2、A2とB1…と順番に試してみても、2個同時ならばすべて正常に動いた。では更に増やして3個ではどうか? B1・B2とAのどちらか一方では正常に動いたものの、 A1・A2とBのどちらか一方では動かなかった。
 どうやらAの方が画像の切替が発生する分だけシステムが複雑になるせいで、そこにBが追加されることで何らかの不具合が生じるという結論に達した。ここまで分かったとなれば、引き続きAの制御を細かく調べれば答えは見えてくるだろう。

現代和風RPG開発日記2017[No.5765]

 動作テストが予想に反した結果となり、原因究明中ながら現時点で分からずじまいである。テスト開始から序盤は予想通りパーフェクトの出来だったものの、途中で怪しい動きとなり、「指定動作の全実行」が発動された時点で一部のイベントが止まってしまうと思われる。
 コマンドの数は全部一致させたつもりだが、どこかで数え間違えが生じているのか?いや、一部を抜き出してテストしてみても、それは否定されている。となるとフラグ発動時に何らかのタイムラグのようなものが生じているのか?これも一部を抜き出してみれば正常に動いている。
 もう少し分かりやすく説明すべく、ここではA1・A2・B1・B2の4個を同時に動かすものとする。A1とA2、B1とB2はそれぞれマップイベントの数が同じで、構造が似たもの同士と考えてよい。A1とA2の同時動作テストは正常、同様にB1とB2も正常に動く。だが、A1とB1の組み合わせだとうまく動かない。最終的にこの4個を同時に動かす予定なのだが、それにはまずAとBを同時に動かせなければ無理な話だろう。

現代和風RPG開発日記2017[No.5764]

 部分的に直しているうちに一度バグが発生してしまうと、原因の究明で時間を費やしてしまいがちである。なかなかミスに気付かないとどんどん時間が無駄になる。ならばいっそのこと、大規模に削って最初からやり直した方が手っ取り早いほどである。
 作業用のエディタ領域の確保も案外気を遣うものである。いっそのこと新たにイベントを配置して、その1ページ目で編集したほうが間違いが少ない。それはマップ上でイベントを開くと、最初は常に1ページ目が表示されるからである。2ページ目以降で編集していると、開いた時にページをめくらなければならない。そんなわずかな時間さえもったいないし、どのページも同じような動作指定の羅列ばかりだと、間違えて別のページのコマンドを編集してしまうおそれがある。そんな凡ミスを避けるべく、目立つ注釈の多用も忘れてはなるまい。

現代和風RPG開発日記2017[No.5763]

 ほんの10数行の動作指定を直すだけで、1周分の全コマンドをやり直しする事態に陥っている。あらかじめある程度分割されていたので、直す必要の無いイベントを全部拾い出して使い回しているが、それでも残りの部分は数百行単位の書き換えとなってしまう。コマンドのコピペができないという仕様が、連日じわりじわりと負担をかけている有様である。
 とにかく修正の必要な部分を書き換えているものの、こまめにテストをする時間も惜しい。だが、1行でも間違えるとそれ以降はすべてやり直しになってしまう。そんなジレンマが繰り返され、気付いたらもう夜になっているのであった。
 よりによって今は繁忙期ときているので、まとまった時間の確保が難しい。ほぼ1日おきに全く作業ができないのもじれったい。極力区切りのいいところまで進めたいものだが、寝不足は仕事に響くので困ったものである。

現代和風RPG開発日記2017[No.5762]

 ここでは仮にA・B2つのイベントを同時に動かすとする。動作コマンドの総数がAは240個、Bは320個として、スイッチを入れればマップ上の指定ルートを何度でも移動させられるようにする。前述の通り並列処理のイベントは1つに集約させるとして、そもそもそんな制御は可能なのだろうか?
 このように動作コマンドの総数が異なる上にどちらも200行MAXを超えている場合、「キャラクターの動作指定」を複数に分割させる必要があるが、そこで少々頭をひねる必要がある。それぞれ前後で2分割するならば、前半はABのコマンド数を完全に一致させなければならない。両者の総数が合わない場合、後半は残りのコマンドを全部入れれば差が生じても問題無い。この例の場合、前半は200個限界まで入れても問題無いが、後で編集するかもしれないので余裕を持って150ぐらいで分けるとよいだろう。
 この例では2分割すれば収まり切れるが、もしコマンド総数が400を超えたらどうするか?その場合は最低限前中後で3分割する必要があるが、そのうち前と中のコマンド数を一致させればよい。尚、コマンド総数が200未満であっても、途中のコマンド数が一致してさえすれば、もっと細かく刻んでも問題無く動作する。又、並列処理させるイベントの数がABC…といくら増えても問題無いが、あまりに増やすと当然ながら処理落ちするおそれもある。

現代和風RPG開発日記2017[No.5761]

 複数のイベントを並列処理で同時に移動させるとするには、複数の並列処理を用いても可能である。とはいえ、できる限り1つの並列処理の中に動作指定を集約させた方がよい。
 突然何をどうしたいのか!?と思われるだろうが、「キャラクターの動作指定」は数百個ものマップイベントに対して複数同時に並列処理できるとしても、「指定動作の全実行」はそれができない。こいつをたった一度でも発動すると、その時点で実行中のイベントの動作がすべて終わるまでは、次の新たな動作指定は一切開始されずに待たされることになる。
 動作指定のコマンドには200行MAXの仕様があることは以前書いたが、これを超える数のコマンドを指定したい場合、200個以内に抑えた数で「指定動作の全実行」を発動後、引き続き間髪入れずに新たな動作指定を行えば、滑らかな連続動作は可能である。だがそれは1つの処理に対しては問題無いにせよ、今回はそれを複数同時に行うことになる。こんなイレギュラーな制御は滅多に使う場面も無いだろうが、今まさにそういうマップを組んでいるということである。

現代和風RPG開発日記2017[No.5760]

 移動コマンドの羅列の区切りに印を付けるとは書いているが、コマンドの中に注釈の機能は無い。では一体どうやって印を付けるというのだ?
 率直に答えるならば、他のイベントに全く影響しないコマンドならば、とりあえず何でもいい。「○に移動」が延々と続いている中で1つだけ異なるコマンドがあれば、それだけで十分目立つからである。
 とはいえ、構築している時点では影響しなくても、マップイベントを大量に組んでいけば、そのうちド忘れして影響を及ぼしてしまうかもしれない。あくまで目印として使うので、最終的には削除してしまうわけだが、ここは何か1つのコマンドに統一するのが現実的だろう。
 そこで当局が採用しているのは「効果音の演奏」→「(OFF)」である。リストの一番右下にあってすぐに選べるし、これほど他のイベントに影響しないコマンドは無いだろう。実行時点で何らかの効果音が演奏されているならば鳴り止んでしまうだろうが、効果音自体はほんの数秒で終わるものである。コマンドの実行時間は無いに等しいので、移動コマンドの間にいくつも割り込ませても滑らかに動作するのある。
管理人

ごとりん

  • 著者:ごとりん
  •  現実的世界観のRPG開発と普及を目指して、日々の生活で戦闘を続ける貧乏クリエーター。このブログの毎日更新が途切れない限り、無事に生存しているものと関知して下さい。
Simulation Country GAPAN 月本國


現代和風RPG「月影の駅」
 RPGツクール2000製フリーウェア。駅から始まり駅で終わる人間模様。オトナのドライな難易度につきお子様は十分御注意あれ。

「Made in GAPAN 歩 ~Ayumu~」
 2D-RPG向け歩行グラフィック合成ソフト。当局開発の32規格8方向部品セット他、一般的な部品セットも利用可能。各使用環境に合わせた既存素材の組み直しや、顔グラ等の合成もOK。
(上記の管理人画像はこれで合成したものです。)

 「月本國」では、2D-RPG向け現代和風素材の無償配布の他、開国(平成13年12月16日)~平成17年2月28日までの過去ログ「旧月本国政府広報」を扱っています。
 又、連載物「RPG制作雑記」「徒然なる200x裏技集」(↓のカテゴリーで★が付いているもの)等のwardファイル版過去ログを扱っています。このblogの過去ログが読みにくい場合は是非御利用下さい。
ブログ内検索
カテゴリー(★:「月本國」にward版あり)
カレンダー
09 | 2017/10 | 11
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 - - - -
月別アーカイブ
最近のコメント
最近のトラックバック
リンク
RSSフィード