yumeの日記: Unity制作 メデューサ・ゲーム #36
ステージ追加。
現在のステージ総数:30
--
●ブロック
新しいギミック「ブロック」を追加しよう。
鏡のように拾って自由な位置に配置しなおせる。でも小さな範囲の視界を遮るだけ。
直感的には移動を遮るのもありなんだけど……。それを使ったおもしろいステージが浮かばないのでなし。
仮にそれが必要になったら、拾うタイプではなく押すタイプで作ってみよう。倉庫番みたいになっちゃうけど。
しかしこれが案外厄介だ。
今のところ、視界を遮るポリゴン(というかそれによってできる視界メッシュ)は:
1. オブジェクト生成時に、自分のポリゴンの頂点座標をすべてFOVManagerに送る(仮想座標リスト)
2. プレイヤーや鏡のFieldOfViewはFOVManagerに保存された仮想座標リストを参照し、自分の位置から各座標への相対的な角度をチェックして、その順に座標をソートする(相対座標リスト)
3. ソートされた相対座標リストの座標にRayCastを飛ばし、実際のColliderにぶつかった衝突点を記録してリストを作る(衝突点座標リスト)
4. 衝突点座標リストから視界メッシュを作る
という順でできている。
この時、実体のColliderの座標は単にUnity上で動かすだけで当然動くが、仮想座標が更新されないと
「本当はポリゴンががあるはず」という位置にRayを飛ばして、でも実際にはなかったり思ったより手前にあったりするので、想定外の衝突点座標が返ってくる。
そうすると視界がゆがむというバグが起きる。
(ドアはどうやってんだよ、というとアレの場合はポリゴンを単に非アクティブにしているだけで、仮想頂点にはRayが飛んでいても最終的なメッシュの形がおかしくはならない)
ん~~~。なんだかこの仮想座標という概念がちょっと回りくどい気がしてきたなぁ。ここが仮想座標じゃなくて実座標を参照するなら、仮想と実座標のズレも発生しない。
でも仮想座標を挟まないと、FOVManagerが一人で一つの仮想座標リストをステージ開始時に1度だけ生成して持っているところを、すべての鏡とプレイヤーが毎フレーム個別に作ることになって、計算量的にちょっとマヌケな感じになる気がする。
一旦おいておこう。とにかく、ここで必要なのは、「実際の座標が動いたオブジェクト」の仮想座標も同じだけ動かすことだ。
あるポリゴン(Block)が、仮想座標リストの何番目かに登録されたとして、そのポリゴンが動いたなら、自分の番号から頂点数分だけリストの値を更新すればいい。
例えばBlockは4頂点、仮想座標リストの[20]~[23]に保存されていたとすると、Blockが動いたならリスト内のその部分を更新する。
ということはBlockは自分が仮想座標リストの何番から登録されたかを覚えている必要がある。
……。うん、ちょっと世界座標とローカル座標の扱いでつまづいたが、案外なんとかなった。
●カーソル
カーソルをたまに見失う。特にmacの全画面でやると顕著だ。
試しに変えてみよう。Unityにビルトインでマウスカーソルを変える仕組みがある。
UnityEngine.Cursor.SetCursor(cursorTexture, hotSpot, CursorMode.Auto);
CusorMode.Auto
で、カーソルモードをハードウェアマウスカーソルベースか、それが使えない場合ソフトウェアマウスカーソルを使う、という仕組みになるそうだ。
ForceSoftwareで強制的にソフトウェアマウスカーソル(ようするにマウスカーソルを非表示にして、テクスチャをバーンと表示する)にすることもできる。
試しにAutoでやるが、Autoの場合、windowsはカーソルサイズが32x32が前提なので、必然的にカーソルもそのサイズにすることになる……。
これじゃあんまり大きくならないな。試してみたがmacだと結局小さいままで、あまり意味がない。
ソフトウェアマウスカーソルに強制する場合、テクスチャのサイズをどうするかが問題になる。
現状、WebGL版はブラウザでの表示サイズ(960x540)でプレイするか、最大化して1920x1080で遊ぶかを選べるが、
マウスカーソルはどちらの場合でも全く同じサイズを指定してしまう。960だとでかすぎて、1920だと小さすぎる。
うーむ。解像度を変える方法をこっちで作って、解像度を変えたタイミングでマウスのサイズも変えればうまくいくかな?
ちょこっと変えるだけのつもりだったけど……。まぁいいか。やってみよう。
解像度やフルスクリーンモードの切り替えは、ビルトインの関数一本でどうにかなるので、問題はコンフィグの設定の仕方だな。
設定はTabキーから出るメニューの中に入れて、タイトル画面からも同じものを呼び出すとすれば、同じコンフィグをゲームを通して保持できる。
ただし、メニューの内容は:
・音量
・画面設定
・リスタート(ステージをリスタートする)
・タイトルへ戻る
・戻る(タイトル画面上でコンフィグを閉じるということ)
と最大で5つあるうち、タイトル画面で使うものとゲーム中に使うものが混在してしまう。
そこで、二つのゲームオブジェクトリストを作る。
inTitleとinGameリストだ。このリストはそれぞれ、各状況で必要なコンフィグメニューのリストとなる。
Tabキーないしタイトル画面の「Config」ボタンを押すと、メインメニューがアクティブになる。
メインメニューはOnEnableアクションで、リストに登録しておいたゲームオブジェクトを、現在のシーンに応じて選んですべてアクティブにする。
そうするとメインメニューの枠やボタンの配置も自動化したい。
ここではVertical Layout Group(子オブジェクトを自動的に縦に並べる)と、Content Size Fitter(枠の大きさを子要素に応じて伸ばす)を使った。
そうしてやっとメインメニューができたので、画面設定ではドロップダウンメニュー(といっても二つしかないが)から、解像度を選ぶ。
960x540を選んだ場合はウィンドウモードで。1920x1080を選んだ場合はフルスクリーンになる。
また、それぞれ選んだ時点でマウスカーソルのサイズも32px版と64px版に切り替える。
まだ問題がある。WebGLでのフルスクリーンはユーザーがESCキーで独自に元に戻してしまえる。
マウスカーソルのサイズはフルスクリーンを切り替えたときだけ変えているが、ユーザーが変えたかどうかは検知できない。
マウスカーソル管理オブジェクトが、毎フレームフルスクリーンの状況をチェックし、管理オブジェクトの記録(isFullscreen)と齟齬があった場合、齟齬を均してカーソルサイズを適した方に直すという仕組みにした。
未解決の問題は:
・フルスクリーン確定がワンテンポ遅い
フルスクリーンを決定した瞬間には切り替わらず、一度画面をクリックして初めて反映されるようだが、これはどうもブラウザ側の問題で、好き勝手にフルスクリーンにできたらまずいからかなぁ。回避策もあるにはあるようだが今後検討しよう。たぶんドロップダウンメニューではダメ。
というか、もともとビルド時についてきてたフルスクリーンボタンをやっぱり使うべきじゃないかな……。ブラウザ版ならフルスクリーンボタンがワンクリックでいつでも使えるのは合理的だし。マウスカーソルの大小切り替えはこのボタンを戻しても使えるからね。
・mac版でマウスカーソルがありえないくらい小さい。
あれ、というか解像度960x540の状態でも想定の半分くらいのサイズになってしまっているぞ。
もしかすると、mac側の解釈では、ゲームの解像度は2倍に薄めてても(Retinaで値通りにやると小さくなる)マウスの解像度は値通りで受け取ってしまうのか。
とすると、今プレイしている環境がmacなのかどうかも確認しなきゃいけない? これは明日やろう。
--
●ゲームのテンポ
BGMを再生しながらゲームプレイをチェックしたが、このゲームは全体的に少しスピードが速い。
歩く速度とか石化の速度をもう少し調整する必要がありそうだ。
ついでにミスティや兵士の加速度も直して、もっと人っぽい動きになおしていこう。
Unity制作 メデューサ・ゲーム #36 More ログイン