top of page
検索
  • ハッピーエンド過激派

「陰都見聞録」の工夫:ウディタ角度機能の拡張など

更新日:2022年7月16日

陰都見聞録の作成にあたり行った試行錯誤から得た知見を共有する記事です。CSVデータ等もできる限り共有します。前提となる話は一つ前の記事をご覧ください。


なお、ウディコン中に入口マップのみを対象にした非暗号化版を配布する予定です。




1ピクセル単位の3D移動


陰都見聞録の作成に際し、1番頭を悩ませたのが画面の謎のガタツキでした。描画ピクチャの座標を調査したところ、なぜか5ピクセル単位で動くなどの現象が起きていました。

この現象の原因はウディタの角度機能。
ウディタの角度機能は三角形の長辺と短辺から小数点第1位までの角度を計算してくれます。ただ、小数点第1位だと、1280ピクセルの画面いっぱいに描画したい場合は最小でも128°の視野角が必要になります。
ただ、角度を用いた3D描画は円柱の弧を平面のスクリーンに映す関係上、128°だとかなり歪みが大きくなります。「陰都見聞録」ではスクリーンの幅は25.6°に相当します。
画面は1280ピクセルなのに対応する角度は256個しかなかったため、5ピクセル単位で動いてしまっていたのです。

解決方法は色々検討しましたが、最終的に選択したのは、ウディタの角度機能を使わず、角度を小数点第2位まで求めるコモンを作る方法でした。
具体的には、Excelでアークタンジェント関数(ATAN)を用い、三角形の長辺と短辺の比と角度(小数点第2位まで)の対応表を作ります。さらに、ウディタの可変DBに読み込める形にします。可変DB[A:B:C]として、Bに10000:1までの角度比、Cの0に角度の整数部分、Cの1に角度の小数部分(2桁)を格納します。
この対応表を使うと、XとYから比を求め、整数部分[A:比:0]、小数部分[A:比:1]を求めることができます。なお、小数部分は何桁でも入るためさらなる拡張余地があります。

この方法の弱点は、比を可変DBに格納する仕様上、45°までしか対応していないことです。そのため、360/45=8 の場合分けをしてやる必要が出てきます。
処理上は±X、±Y、|X|>|Y|or|X|<|Y|の3要素が2パターンずつ、8通りに分け、それぞれのパターンごとに当てはめ方を変えています。
実際かなり面倒で、90°-135°と135°-180°の範囲で45°の正負が変わり、かつウディタの小数点切り捨て仕様により小数第2位を2ごとに1ピクセルとする処理のかかり方が正負で変わりガタツキを呼ぶなど、相当問題児な部分ではあります。

「陰都見聞録」では0°では正常に動くものの、実は3150°で微妙にガタツキが残っている状況です。次回作では小数第2位と対応するピクセル:角度比にして解決する予定です。なお、同じ方法で角度(小数第2位)に対応したsin,cos変換コモンも採用しており、(多分)なめらかな描画に寄与していると思われます。
sin,cos対応表は、整数部分+小数第1位(0~3600)を可変DB[A:B:C]のBに入れ、C0~9に小数第2位を入れる形式です。こちらは0~99の小数第3位まで拡張できます。

以下XY比に対応した角度表(小数第2位)とsin,cos対応表を貼りますのでご自由にお使いください。
角度表
.csv
ダウンロード:CSV • 146KB
角度別sinθ
.csv
ダウンロード:CSV • 199KB
角度別cosθ
.csv
ダウンロード:CSV • 199KB

描画処理のフレーム分散


ウディタ以外も多分そうだと思うんですが、重さの原因って1フレームあたりの処理が多すぎて1フレームが間延びしてしまうことが原因だと勝手に思っています。

実際に、「陰都見聞録」では計算負荷の大きい処理を1フレーム内に収めず、複数フレームにまたがる処理とすることでゲームを軽くすることができています。この方法の良い点は、処理間に1フレーム入れるだけで実現できるため、プレイヤー側に分散するかしないかを選ばせることも容易なところです。

「陰都見聞録」の描画関連処理の負荷は、恐らくA.ピクチャ描画>B.3D座標計算>C.陰面処理(コムソート)>D.主人公の所在タイル把握(通行判定やセーブ上判定に使う)>その他という感じです。
このうち、DはBに付随しているので分割できていませんが、B+D → C → A → ...とし、描画FPS20設定では各矢印のところに1フレームを入れ、処理を分散させています。描画FPS60では1フレーム内で全ての処理を終らせます。

操作感としては、描画FPSは落ちても内部FPS(主人公の操作)は軽いままにできるので、重いことによる理不尽な被弾や処理遅滞は避けられる、我ながら良いアイディアだと思っています。


3Dマッピング


3D座標の把握は前回の記事のとおり、中心座標と4点座標の把握により行っています。これに対応する形で、中心座標を入れるだけで複数のタイルの中心座標・4点座標を出力してくれるExcelファイルを作っています。これがあると3Dマッピングはだいぶ楽です。

例えば、中心座標を入れるだけで16枚の地面タイルの各座標を出力するファイルは超多用しました。立方体も角度を変えられるようにすると色々作れて便利です。あと階段とかですかね。

作成に使用したExcelファイルをアップロードするので、ご自由にお使いください。
建物作成_2
.xlsx
ダウンロード:XLSX • 277KB

その他:3Dならではの表現


ズーム
スクリーンの描画範囲を広げたり狭くしたりするだけで調整できます。「陰都見聞録」のズームはかくついていますが、計算量を少しだけ増やしてなめらかなズームにすることも可能です。

角度変更
主人公座標から視点座標を求めるようにすると、主人公の周りを視点がくるくる回る表現ができてダイナミックでした。

視点移動
指定キャラから指定キャラに視点が移るようにするとこれまたダイナミックで良いですね。幻想水滸伝I・IIあたりの戦闘画面はこんな感じの処理だったのかなと思ったりします。一騎打ちだと角度変更もしてますし。

8方向キャラクターのパターン変更
最近流行ってる4方向キャラクターを3次元の板に貼って板自体を斜めにするみたいな表現、結構嫌いなんですよね。8方向キャラクターを2Dで動かした方が自然です。ただ、素材が超限定され、特に歩行モーション以外がないのが辛いですね。角度を変えるとみんなの向きが一斉に変わる感じがいいですね。FFTを思い出します。
角度によって進む方向が変わる点は結構面倒です。当然基本システムは対応していないので歩行も1から自作する必要があります。パターン変換は多少処理は増えるものの、一旦テンキーに変換して回転させてからパターン変換するのが分かりやすくておすすめです。

素材
テクスチャは何とかなりますが1280×960のサイズに耐える8方向キャラクター素材がぴぽやさんの有料キャラチップと彩黄月さんのキャラチップだけなんですよね。これが解消されないと厳しい部分はあります。

限界
正直なところ、ウディタの限界よりは自分の表現力や気力の限界の方が近いくらいにはまだまだ表現の余地がありそうです。ズームと角度変更はもっとダイナミックに使いたいです。
描画限界はまあまあ厳しい印象です。ここはウディタの計算能力次第で変わる部分なので今後の開発に期待したいところです。

今後の展望


「陰都見聞録」は今の描画方針でやっていきます。

次回作は戦闘機(ジブリに出てくる感じのものは除く)の出てこない牧歌的フライトシミュレーター兼物流経営SLGを作りたいわけですが、そのゲームの負荷軽減措置は以下の内容を考えています。

3D座標計算を点→面とすることで重複する座標計算を減らしたいと考えています。ただ、描画範囲の特定が面倒になりそうなので方法は検討中です。

あと、全天表示、太陽と影、なめらかな全周角度変更あたりは入れたいところです。

このくらいでしょうか。アドバイスやご不明な点等があればDMいただけますと幸いです。


閲覧数:151回0件のコメント
bottom of page