VRChatのワールドを作った話 ～ワールド制作技術編
初めてのVRCワールドを作ったのですが、分かりづらいことがあまりに多すぎた！
今回はこれからワールドを作ろうとする人のためになるかもしれない情報をとりまとめます。
必要なとこだけ読めばいい系の記事だよ。
あくまで制作初心者目線なので、気をつけてね。
作ったワールドは以下のやつ。
今回は、検索等で見つかって助かる人が出たらいいな～って内容なので、構成や順番は結構雑多だったりします。
ワールド作り、その工程の多さ
やることが…やることが多い…！
でも、だいたい何をやるか把握することで、ワールド制作の流れを掴んだり、ぬけもれがないか確認できると思います。
大体こんな感じのはずだ！
ワールドのラフスケッチ
床置き。ワールドの広さざっくり決め
SkyboxやDirect Light等の広めの光源設置
効果音、BGMの方針決め（特に3D調整）
繰り返し出てきそうなオブジェクトやギミックのあたり付け
（変数表示等のデバッグ用ギミックの用意）
お部屋作成
素材集めや作成。クレジット用メモ
オブジェクト配置とオプション設定
（ギミック作成とプチテスト）
仕上げとテストプレイと調整
ライトベイク（したりしなかったり）
オクルージョンカリングベイク（したりしなかったり）
テクスチャのサイズや圧縮率の調整
テストプレイと調整
（ポストエフェクト調整）
（Quest対応の検討や調整）
公開に向けた作業
サムネ作成
（ワールド紹介文や紹介用スクショ等の準備）
これでも内容は絞ったつもりですが、それぞれに時間かかってしまって大変でした。
それぞれに色々注意することがあったりするんで、ワールド制作の手順がまとまった記事ってもっとほしいなあ……と、切に思うのでした。
このうち、ワールドのテストプレイや調整も見るべき点が結構あって。
大体こういうとこ見てました。
難易度等のコンテンツの内容そのもの
プレイヤーとのコライダーの大きさが適切か。意図しない箇所の通り抜けが無いか。歩行の邪魔になったり、足元のガタガタさで動きにくいポイントが無いか
インタラクトやギミック間のコライダーの判定が適切か
LightingやCullingによって、変な見え方になるところが無いか
解像度を落としたり圧縮したテクスチャの見栄えに問題無いか
曲や効果音の音量や、3Dのパラメーターで聞こえ方が変だったり聞こえにくいところが無いか
写真スポットがあれば、文字や景色等が写真の枠内に収まる画面になるか
同期処理系で複数人がUseした場合や、Late Joinerに対する挙動の確認
結構、実際にVR等で入って確認しないと分からないことが結構あるんですよね。
完成間近でウキウキしたら、本当の戦いはこれからだってなりました。
頑張れ！ 頑張ろう！
最初からグローバルギミックには手を出すな
こんなワールドを最初から作ろうとしないでください！！
グローバルギミックの難易度が！ 高すぎるから！！
最初は全ローカル動作を前提として作るほうがよいと思いました。
理由は以下の通り。
挙動や書き方で習得すべき知識がさらに増える
コード量が多くなる
デバッグしづらい
同期ずれ等の問題を完全に潰しきれない心理的負荷
資料としては、だいたい以下の記事を参考にしました。
公式のワールドサンプル：
ぶっちゃけギミック系作ってみたい人はこれで触って遊ぶのが一番早いと思う。Packages>Samples>UdonExampleScene>UdonExampleScene.unity
をHierarchyにD&Dで展開できる。
特にUdon Variable Syncがグローバルギミックの参考に多いに助かる。
作成中のワールドを汚さずにお試しギミック作って確かめる用の適当ワールドとして持っておくのもかなりオススメ。
公式ドキュメント：意外と参考になる。
RequestSerialization()の挙動：
実装例など：
グローバルギミックのさわりのさわり
それでもグローバルギミックを作る必要があるって時は、大体次のパターンになるってのを押さえればよいと思います。
ぶっちゃけ公式のワールドサンプル見たほうが早いかも。
オーナー変更パターン：
ラグは少ないが、挙動が若干あやしい方法。
自分がオーナーになってしまえば、自分が押した結果を即座に反映しやすいと。
ボタンをクリックして、反応にラグがあると気持ち悪い時に。
レスポンスの良さって案外大事。ラグがあると「反応しないな…？（ｶﾁｶﾁｶﾁｶﾁｶﾁ」と連打されたりして、結果的に不安定なことが起きやすくなるかも。
弱点はSetOwnerというメソッドが完璧な動作を保証しないこと。
先の公式ドキュメントにあるのですが、SetOwnerは実際には、他のプレイヤーにオーナー移行の要求をさせて、通る/通らないの判断が入ります。
つまり、状況によっては（現オーナーが処理中とか？）オーナーの移行に失敗するケースが有ります。
失敗した時の挙動の再現や対策が難しく、どうしようかなあってなります。なりました。
凄腕の方がここの対処法を色々語っているのをXで見たりしましたが、今の僕には理解できないやつなので、これ以上はすごく頑張れる人向きになる気がしてます。
あと、誰も書いていなかった事項として。
Networking.IsOwnerがFalseならばNetworking.SetOwnerとすると、SetOwnerが失敗しやすいのか、挙動が不安定になりました。
公式のWorld例もIsOwnerの確認をしていないので、こう書くのが前提なんでしょうかね。
他の人のサンプルコードで見かける表現ですが、私の環境だとうまくいかなかったので、どうも変だと思った方は是非ご確認ください。
この辺、本当に何なのかよくわからなかったので、有識者求めたいところ。
オーナーに処理を委託するパターン：
オーナーだけが値の変更を行うが、オーナー以外が触るとラグがある方法。
SetOwnerが出てこないので、処理はこちらの方が安全に行われます。
ただ、オーナー以外の人は、以下のような手順を踏んでしまいます。
1. ボタンを押して、オーナーに処理をお願いする
2. オーナーが処理する
3. オーナーのRequestSerializationにより結果が返る
と、往復分の通信が必要になります。
ちょっとしたラグでも結構気になるので、ボタン系には向いていないかも。
ハイスコアの更新だとか、協力プレイのクリア判定のチェックとか、多少ラグが出ても違和感が無いときには積極的に使いたいかも。
グローバルギミックのデバッグ方法
1人だと同時押しのテストって難しい。結構気づきにくかったのですが、以下の方法で確認できました。
VR機器を用意し、steamVRでVRChatに入れる状態の手前にしておく。
VRChat SDKのLocal Testingで、Number of Clientsを1、Force Non-VRにチェックが無い状態でBuild & Testする。
もういちどLocal Testingで、Number of Clientsを任意の数、Force Non-VRにチェックを入れてTest Last Buildする。
2回Testボタンを押しても、同じインスタンスに入ってくれます。
こうすると、VR機器で1人目の自分、デスクトップ環境で2人目移行の自分として操作できます。
通常、デスクトップ複数人でも簡単なデバッグができるのですが、複数窓を同時操作できないため、ボタンを同時に押すのは不可能です。
そこで、VR機器のコントローラーとデスクトップ側のマウスの両手持ちをしてボタンとかをUseすることで、同時押しデバッグを実現できます。
私の環境ですと、3人以上インした状態で、SetOwner関数を含むオブジェクトに2人同時押しを連続100回ぐらい連打すると、うち一人が一生SetOwnerに成功しなくなるバグを起こしたりできました。裏技かよ。
そんなこと誰もしないやろと思うのですが、何かのきっかけでこういうことが起こり得るってのは怖い……。
あと、右シフト + 半角/全角 + 上段の6とか8でお役立ち情報が色々出るのももっと知られていい。
結局Udon Node Graphってどうなのよって話
今回のワールドはUdon Node Graphのみで作ってみました。
評判はかなり悪い一方、公式サンプルはGraphになっており、検索で引っかかる資料も案外充実しています。
むしろ、下手にUdon Sharpで調べようとすると、新旧混沌とした状態なので、整理された情報をかなり得づらいです。始めにくい。
今回、実際どうなのか確かめようというモチベもありました。
ここがすごい参考になる：
メリットはこんな感じかと思います。
使うべきノード（特に接続前後）を素早く検索、設置できる
公式サンプルワールドからの流用が簡単
海外クリエイターのギミック動画解説が割とGraphだったりする
プログラムっぽくないので、抵抗を和らげたり本業から気分転換できる
（Udon Sharpと比較して）古い記事が引っかかりにくくい。多分。今のところ。
ぶっちゃけ、ルーム系ワールドの軽いボタンギミック程度ならGraphで十分なんじゃないかと思います。
ただ、ギミック要素強めワールドは普通にコード書いた方がいいんじゃないかなあと思いましたので、オチとしてスクショを上げて占めたいと思います。
メンテナンスも何もあったもんじゃない！
以上！！