雑文録

とりあえず書いたものを置いておく用

■絶対にボツらせない！大型プロジェクト製作（VRChat4weekWC）前編

 

◆これは何

 

規模の大きい・ストーリー性や複雑なギミック等のあるワールドや、人の集まる体験型のコンテンツ・イベントなどの製作を、誰もが一度は夢見るにも関わらず、それらを行うのは限られた『すごい人』だけという現状があります。

それは能力的に製作不可能だと判断しているというよりも、膨大なリソースをかけた制作の果てに『ボツ』となって全ての労力が水の泡となるのが怖いから、諦めているということが多いのではないでしょうか？

 

 

以前の記事で『とりあえずワールドを作って、コミュニティラボに上げる』という段階の話について、自作ワールドを例にして扱ったものが好評を頂きました。今回自分はそこそこ大きな（※）プロジェクトを完成させたので、同じ方法で書いていきたいと思います。

 

 

（※ここで言う大きさは、単純なワールドの移動範囲や製作期間の長さではなく、後述の『コンセプト』の実現に際して複数の条件が求められる創作物、という意味です）

 

 

①前提：何故ボツるのか

これは私事ですが、2018年に最後の小説を書き上げてからの二年間ほど、毎日のうち２～３時間をかけて一年単位で執筆していた小説を、二作品ほどボツにしています。この『一定の製作期間を過ぎた作品のボツ』は限られた時間・精神的リソースを生活から削り出していく兼業創作者にとって非常にダメージが大きいです。

創作の道を歩き始めるには『最初の一つを完成させる』までの大きな壁がありますが、一方で歩み始めた後も『リソースをつぎ込んだ作品の連続ボツ』という、非常に転落しやすいモチベーションの崖際を歩いていくことになります。何故そんなことが発生するのか、どうにかしてそれを避けることはできないのか？

VRChatという場所柄、ゲーム制作の案件に関わる仕事をしている人や、個人でゲーム制作をした/しようとしたことのある方と話す機会が幾度かありました。そこで小説とゲームという全く異なる創作媒体において『ボツ』が発生する条件の、共通項を探していくことで自分なりの結論が出ました。

 

まず小説（というか物語媒体）では設定や登場人物を後から生やす（有ったことにする）こともできるので、進捗＝書いた量は基本的に『読み進めることのできる物語の進行度』とイコールになります。そして体力的なもの以外でボツが発生する時というのは、この舞台設定や登場人物から生まれた文章の続きを書いても自分が思う面白い部分、つまり盛り上がるクライマックスや題材に即した結末に辿り着くことができない、という状況に陥ってしまった時です。

一方で、ゲームという媒体はシステム面の実装がなければテストプレイもできないので、作業工程の前半はゲームの進行度順ではなく、それを動作させる基盤部分の実装が進捗＝やってきた工程になります。そして基盤となるシステムがある程度実装されてテストプレイを行った時に、このシステムでは何をやっても面白いゲームプレイ体験を提供できない、と判断せざるをえない場合に『ボツ』が発生するそうです。

 

これらに共通する点として『目指しているコンセプト＝面白いと思うゲームや、伝えたい題材を描写できる物語』と『積み重ねた進捗＝既存のシステム実装やストーリーの構造』の間にどう考えても修正不可能な乖離が発生している時、が『ボツ』の発生条件であると考えられます。

これは『コンセプトを実現するために、最初はこうすれば良い』というトップダウンでの逆算と、『この工程を積み上げて行けば、最終的にはこうなっているはず』というボトムアップの想定において、どちらか或いは双方にミスがあり、しかし双方に齟齬があると気付くのは進捗がある程度積み重なって修正が難しくなった後、という状態であるとも言えます。

f:id:karina-kamei:20220418113518p:plain

 

・今回の大コンセプトの設定（なんで作った）

さて、今回のワールドを構想し始めた切っ掛けは、某氏のツイートでした。

 

 

私は公開していないものを含めれば三作の長編と幾つかの掌編を完結させています。

そして情景描写がクドいと言われがちだったので、情景を描写したい欲をワールド製作に向けて執筆が進まない間はUnityを触る、という二輪の創作をここ一年半で回してきました。

ですが逆にモデリングやプログラミング等に関しては本業とも関係ないためからっきしで、なので皆々様の仰る『思想の強い』ワールドとやらは自分に創れんだろうし程々にやるわ……という気持ちもあったりました。ですが、あの『夏』に触れた後にツイートを読んで、

 

――あれ、行けんじゃね？と

 

「シナリオありきで不可逆に進行するワールド」に対して、恐らく一番の障害になるであろうシナリオの面に出来合いのもの（＝小説の過去作）があり、そもそもが『自著の情景描写』の代替としてワールド製作を始めたので自著の舞台となる世界の、景観を実現するための最低限のUnity技術と求めるジャンルのアセットは持っている。ただ、その一点において私はVRChatに居るワールド製作者、という枠組みの中で比較的有利な立ち位置に居る。

 

試してみる価値はあるな、と考え始めていた矢先にあるイベントの第二回が開催されます。

 

 

お題発表の前日に主催のtiwaさんの作業部屋に行き、あくまで雑談として『小説をシナリオ進行、文字演出まで含めてワールド化する』ことについて相談します。そこで、かなり課題点の列挙とやりたいことについての整理を手伝ってもらった、もとい私が好き勝手に話したことを文章化して実現のために必要なことを列挙していただきました。

 

この時点ではお題も未発表なので『可能であればやる』、『お題が合わなくても、その練習になるようなものを作る』という気持ちが定まります。で、お題が出ました。というわけで今回のワールド製作で、当初のコンセプトは『自作小説をシナリオ進行、文字演出まで含めてワールド化する』というものになりました。

 

上記のコンセプトをより噛み砕いて言うと、

・シナリオありきで不可逆に進行するワールド（上記参照）でありながら、異なる進行度にある各ユーザーが同じ場所に居ることができる（皆で集まって同じ小説の違う貢を読んでいるような景観変化のさせ方、空間の在り方の模索）

・『小さな世界の停車駅』というお題に対する解釈として『小さな世界＝抜け出せない生活の場としての閉塞感』と『停車駅＝小説における切り取られた劇的な場面のみを、駅＝貢として進行度に応じて乗り継がせていく』ような構造にする

・その素材として自著である『鋼の森のアリス（仮名仮名（カメイカリナ）） - カクヨム』を使用し、ストーリー性の担保にすると同時に文字媒体では行えなかった風景描写と、小説内の文章を使った文字演出などを行う

 

――というものでしょうか

②試行：コンセプトから複数段階に分けた達成目標を設定する

今までの製作では上記の『コンセプト』を最終目標として実際にはどんな工程を行えば良いのか、というトップダウンでの逆算を行って、それを実際の進捗と照らし合わせながらボトムアップで細かな修正を加えていました（仮説の図のような流れです）。

ですが、そうすると上記の『ボツ』が発生しやすくなります。

 

そのため今回のやり方では、最終目標のコンセプトの下位に『切り分けた各製作期間における目標』を置いて、これを『それまでの進捗』と擦り合わせて決めていきます。

f:id:karina-kamei:20220418113745p:plain

こうすることで『実際の製作進行度と、そこから各期間で実現可能なもの』と『各期間での目標』が実現不可能なほど隔絶することを予防して、逆に『当初のコンセプト』と『実際の製作進行度に照らし合わせて、修正された各期間の目標』の誤差についても許容範囲に収めることができます。

https://www.ryuzee.com/contents/blog/7124

f:id:karina-kamei:20220418113108p:plain

※各作業期間内におけるスケジューリングはこちらの記事の『スクラム』を参考にしていますが、金銭的利益を伴わない個人製作という異なる状況なので本記事を読み進めてもらった方が実際の工程として分かりやすいと思います。

 

こうすることでコンセプトの修正＝妥協を許容可能な範囲に収めつつ、定期的に製作進行度が『複数に分けたコンセプトの達成地点＝最低限出しても問題ない形』になる段階を設定しておくことで、体力面や現実の事情などでそれ以上の製作進行が不可能になった場合も『作品』として出すことを可能にしておく、という予防策の意味もあります。

 

※これは漫画『暗殺教室』の作者がいつ打ち切りを食らっても良いように、複数の終わらせ方を用意しているという話も参考にしました（元の記事が見つからなかった）

 

・実働期間（1weekWC）

一週間目の『切り分けた各製作期間における目標』は作品として最低でも満たしておきたい要素を設定して、一週間目の作業における達成度合いを参考にして二週間目以降での『各製作期間における目標』を決めていきます。

とりあえず一週間目の目標としては『同じ場所で変化していく景観』という小コンセプトと、それを実演するために必要最低限な規模の街、景観の変化を変化するセットの用意というところです。

 

そのために必要な工程として1week目の前半は『地形オブジェクトと、それぞれの景観セット（ライティング/スカイボックス/ポスプロ）を簡易的にスイッチで呼び出せる切り替えシステムの配置』を行いました。

 

そしてワールド入場時のアニメーションとして電車に乗ってワールドに訪れる、という演出方法を作ることで景観セットの切り替えの雛形を作ることを考えますが、目下の大きな問題として自分はワールド製作で『一切の演出・ギミックを自作したことがない』というものが認識されていました。

アニメーションに関しても前に『入室時からの時間経過で太陽が昇って沈み、それに応じて光源の色やポスプロが変わる』というアニメーター機能が一切関わらない方法で触ったきりで、景観から次の景観へと切り替わる際の動きや演出とその実現方法については、ほとんど思い浮かんでいなかったのが実情です。

 

この時のクレマテリアは1wWCの折り返し地点で行われたということもあり、ほとんどの方の話題が『小さな世界の停車駅』の解釈やその実現方法に関する相談でした。そして電車の停車音と同時に暗転が解除され、電車の扉がゆっくりと開くことで『電車が到着した』ことを表現し、電車の発進音と同時に暗転することで『電車が発進する』ことの表現とする方法を先達が行っていると聞いて、その方法を採用することに決めます。

 

実働week中に電車のモデルを吟味する時間的余裕はなかったので、豆腐ことCubeで代替してアニメーションを設定しました。

上記の通り、今回はあくまで『このweekの終了時点で、当初の切り分けたコンセプトを実現した作品として成立している』ことを最優先事項とします。つまり『とりあえず今週はそれで行』って、満足が行かなければ『次以降の週での達成目標』として方法の相談や吟味を行った上で改めて頑張ることにします。

 

上記の方法で電車の到着・発車を表現するアニメーションを作成し、そこに４つの景観×到着と発車２つのフェーズで計８個のオブジェクトを出し入れするようにしました（ユーザー視点だとフェーズ１と２では景観が変化しないため、電車のアニメーションだけが管理されているように見えます）というわけで1week目はかなり割り切った構成にしましたが、この時の『切り分け』という発想は2week目以降にも活きてきます。

※フェーズ設定（各オブジェクトが下記の順序でアクティブ化される）

曇り１：曇りの景観セット＋電車の発進アニメーション（乗ってきた電車が去る）

曇り２：曇りの景観セット＋電車の発着アニメーション（次の電車がやってくる）

夕暮れ１：夕暮れの景観セット＋電車の発進アニメーション（乗ってきた電車が去る）

夕暮れ２：夕暮れの景観セット＋電車の発着アニメーション（次の電車がやってくる）

異空間１：異空間の景観セット＋電車の発進アニメーション（乗ってきた電車が去る）

異空間２：異空間の景観セット＋電車の発着アニメーション（次の電車がやってくる）

夜明け１：夜明けの景観セット＋電車の発進アニメーション（乗ってきた電車が去る）

夜明け２：夜明けの景観セット＋電車の発着アニメーション（次の電車がやってくる）

 

一週間でこれらの景観作成とアニメーションに加えてUDONまで触る時間はないと判断して、使い慣れているLuraさんのポストプロセス切り替えスイッチを採用しました。これはボタンを押す度にポスプロの種類が設定された数の分だけ切り替わっていくというものですが、ご存じの通りポストプロセス用の『オブジェクト』を出し入れしているので各種景観セットとアニメーションを行うオブジェクトも同様に出し入れできます。

 

それぞれのフェーズ１では開始時点にのみ『去っていく電車』が存在し、一方フェーズ２では発着アニメーションが再生されてから『次の景観へ向かう電車』が存在しています。全ての景観セットには電車オブジェクトと各種アニメーションが配置されているにも関わらず、ワールド滞在者の主観視点で景観を見ている最中は『電車がない時間帯』の方がほとんどです。これはアニメーターやアニメーションのタイムライン管理が苦手な自分にとって、かなり作りやすい仕様でした。

 

 

これをもって1week目の工程を終了し、一つの『完成品』としてイベントに提出することになります。

 

③非実働（製作ソフトを触らないで、進捗内容や目的の実現方法を吟味する）期間を設ける

さて、このワールドを製作し始めた当初から想定していたことではありませんが、上記の工程は『ボツらずに完成させる』という目的において、かなり大きな役割を果たしてくれたので言及しておきたいと思います。

1week目終了の翌日から二日間、同じく1weekで製作されたワールドを製作者たちで話しながら見て回るイベントがあり、なおかつ濃密なスケジュールの製作による疲労からも一週間の休止期間を設けることにしました。

 

・1wWC発表会・クレマテリア閉店日（非実働week）

○成功した点と△課題点に分けて1week目の工程を振り返ります。

 

○移動可能エリアを変更しないまま、進行度によって景観のみを非同期で変化させるコンセプト。

 

謎解き・冒険ワールドは途中で参加してきたユーザーとの合流が難しかったり、VRライブ（パーティクルライブ・VRMV等）のワールドはその同期性を損なわないためにワールドの参加人数を制限するということが多いと思います。

ですが『同じ場所に居ながら違うものを見ている』という状態が、意図せずともVRChatのワールドという媒体では実現可能です。これはsuzukiさんの青空文庫ワールドで皆が『同じ場所に居ながら、違う小説を読んでいる』のを見た時に思いつきました。

 

それぞれのフェーズの進行度によって見栄えの良い方角や場所が全く違うことから、好き勝手に歩いている通行人のようにユーザーが分散し、それぞれが同じ場所に居ながら見えているものへの言及が食い違っているのは『してやったり』という感じでした。

この『混乱』に関しては青写真としてワールドを狭く作った1week目の方が感じやすかったかもしれません。

 

△システムの実装

Luraさんのポスプロスイッチ（SDK3対応版）は単純なオブジェクトの出し入れではないため、それぞれのスイッチの位置を変えるといったことはできない（見た目上のオブジェクトと判定用のオブジェクトが異なり、後者の位置は親オブジェクトに固定されている）ということが判明しました。これによって景色の切り替えと、そのトリガーとなるキーアイテムには別のツールを使う必要があると分かります。

 

△景観のためのマッピング

ワールドの西側（つまり夜明けの時に、日が昇る方向）の景観に不満がありました。街系のワールドを作る時に “果て”を意識させないため『曲がり角』という存在は大きく役立つのですが、一方で直角の曲がり角とそれに面して水平に立ち並ぶ建造物というのは『書き割り』っぽさを感じさせてしまい、最後のフェーズで見せる景色としては弱いなと感じます。

 

・次week以降の課題と、その実現方法を吟味する

一週間はUnityを触らない休止期間にする、と決めていましたが上記の課題について休止期間明けの2week目から取り掛からなければならないことは確定しています。それならば今のうちに何をすべきかを明確にして、場合によってはより簡単にそれを実現する方法について自分より知識がある人と相談することもできるのでは？ と考えました。

 

・１『まで』学ぶBlender

今回は坪倉さんの道路アセットを使用させていただき、その質感の高さにかなり助けて頂いております。一方でこちらの道路は10m×10m単位での升目区切りでワールドに配置することを想定されていて、曲がり角も同様に20m×20mの中で一辺から隣接する一辺へと直角に曲がるものしか用意されていません。ですが上記の課題点から『直角の曲がり角』ではなく45°程度の曲がり角が景観的に必要とされています。

 

ええ、分かっていますよ。動画を観てBlenderを勉強すれば良いのです。それくらいの努力もせずに、何がワールド製作者かと。ところで当時、私は医療系の就活と国家試験と卒業試験の勉強とコロナ禍における医療実習、それからVRSNSを題材にした小説の執筆を並行して行っており、過労から自律神経もかなりおかしくなってしました。

 

ですが勿論その二つ、つまり製作に求められる知識や勉強量と、残りリソース量の乖離から実現を『諦める』つもりなどさらさらありません。つまるところサボれる方法さえ見つければ、自分の負うべき（と誰かが決めつけた）労力をひたすら回避し、押しつけがましく助けを求めてでも完成させることが可能なら、それを優先させれば良いのです。

 

幸い、毎週行われていたワールド製作者の集会イベント（クレマテリア）は格好の場でした。ワールド製作における偉大な先達に上記のやりたい内容をそのまま伝えたところ『ブーリアンを使えば良いのではないか？』という回答を頂き、Qvペンを使って大体の使い方まで教えていただきました。

 

坪倉さんの曲がり角.fbxをBlenderで開き、デフォルトキューブを拡大したものを曲がり角の大体の対角線上に沿わせて『ブーリアン』を選択することで、45°の曲がり角を作ることができました。アセットに対するオブジェクト分割と頂点削除とブーリアン、それが私の二年間のワールド製作で私が覚えた、必要最小限のBlenderの機能です。

 

・模擬Triggerツールの選定

 

同じくシステム面の実装においても、自分でUDONのコーディングも、ノードとやらを触れる余裕もさらさらありません。

www.wicurio.com

ここで、以前SDK2のTriggerシステムをエディタ画面上でも模倣させるツールがあったことを思い出します。私はSDK2時代も出来合いのアセット以外でギミックを実装したことがないのでTrigger機能自体を目的としてはいませんでしたが、たった三つの設定項目でワールドに必要な大体のイベントを実装できる点から魅力的でした。

 

・電車のアセット

Subway Stations (6 Scenes) | 3D Urban | Unity Asset Store

こちらもアセットを使ったワールド製作が上手で、なおかつ以前のワールドで電車を用いたワールドを製作されていた方にお話を伺いました。このアセットが複数の電車と駅構内モデルを内包していて価格の割にボリュームが有るとお勧めして頂き、実際に使ってみて非常に良かったので、それありきでマッピングを大きく変えることになります。

 

・次週以降のスケジューリング（コンセプトの切り分け）

また1week目の時点で『一週間の実働で自分がどれだけの作業を行えるか』の大まかな目安が分かったので、次週以降に1週間単位で『とりあえず表に出せる形』になるように製作した場合、どこまでの進行度を出すことができるかのスケジューリングをします。

 

1week目：『同じ場所で変化していく景観』

前半で地形オブジェクトと、デバッグ用を兼ねた景色（それぞれのライティング/スカイボックス/ポスプロ）の簡易切り替えシステム（それぞれのポスプロ・オブジェクトをスイッチで呼び出せる）

後半で最初の電車の到着アニメーション（ジョイン時に発生）を作成して、それを基に景色が切り替わるごとに電車の到着・発車が行われるようにする（アニメーターによる管理を必要としない、景色の切り替えに応じたアニメーションの実装）

　↓

2week目：『ユーザーの動作によって不可逆に変化する』

電車のモデルとそれに応じた詳細なアニメーション、駅を前提としたマッピングと導線、それに必要なシステム面（マップ内にある何かをインタラクトすることで、次の景観へと向かう電車が到着する・次の景観に移ると電車が去って行く）の実装

　↓

3week目：『ストーリー性とその演出』

タイポグラフィ等の演出をマップ内にあるオブジェクトに連動させて、ストーリー性を強くする？自著からワールドに落とし込める量の文章だけを引用して、それを行う。

　↓

4week目：デバッグその他・それまでの週に行った工程のクオリティ向上・軽量化

 

④前半まとめ：実働期間と非実働期間を区切ることについて

最初は1weekWCの延長戦として何weekかけたか記録しておきたい、という動機で実働期間をweek単位で区切ったのですが、上記のように『非実働』と定めた期間のうちに実働後の途中完成品に対するフィードバックを吟味検証する効果が極めて高いことが分かりました。

課題点や次に実現すべきコンセプトのために情報収集や学習を行うことで『実働』と定めた期間には決められた作業を行うだけで良いようにする、というアプローチで参考元の一つである『スクラム』と似た工程を一人で実現できるようになります。

 

f:id:karina-kamei:20220418120059p:plain

・大コンセプトから達成したいコンセプトを細かく切り分ける

　↓

・一週間目で最低限達成したいコンセプトだけを満たした青写真（叩き台）を作る

　↓

・一週間目の製作進行度から、週ごとに達成する小コンセプトと最終期限を設定する

　↓

・それぞれの実働期間の後に、外からの意見を取り入れて小コンセプトの修正を行い、それぞれを達成する方法や労力の減らし方について情報を集める（非実働期間）

　↓

・二週目、三週目、四週目、とそれを繰り返す（実働期間の間は、基本的に非実働期間に決めた工程を行うだけで良い）

　↓

・当初の大コンセプトの達成度と自分のリソース残量を照らし合わせ、どこかのweekが終了した時点で『完成』とする。

 

（※かけた時間/労力(t)が一定量を越えた時点で、それに対する景観/プレイ体験の完成度をf(t)とした時の変化量f’(t)が加速度的に減少していきモチベーションk(f’(t)/t)に悪影響を及ぼすので、どこかの実働時間が終了した時点でパブリッシュ（≒基本的には製作終了）するのは確定してます。）

 

それぞれの実働期間の終了時点で各コンセプトを実現した『一つの作品』として、つまりワールドやゲーム制作の場合では『システム実装と最後までの導線』がとりあえず一通りできている状態にすることがこの方法の要点です。

 

それによって上記のスクラム性以外にも、

・それぞれの『完成物』に対してフィードバックを得ることができるので、コンセプト自体や全体像についてのフィードバックを得やすい

・コンセプトの実現に必要でない要素（トップダウンの誤算）や求めている完成度に必要でない進捗（ボトムアップの誤差）を修正しやすい

という利点があります。

 

作品（ワールドやゲームの場合はシステム面の実装、小説の場合は結末までの展開）が完成した状態でないと、他者にコンセプトの意図（何故そういうゲームを作ったら面白いと思うのか、その題材について小説で書く意義があるのか）を理解してもらうのは難しいです。

そのため大作にしようとするほど製作途中を人に見せてもコンセプトが伝わらず、全体像に対する望ましいフィードバックが得られない、という状況下でボトムアップとトップダウンの誤差が大きくなって『ボツ』が発生する危険が高いと言えます。

 

これについて優先度の高いコンセプトから実現させた『暫定の完成品』を期限を設けて製作することで、フィードバックを得てコンセプトと進捗の誤差を修正し、場合によっては優先度の低いコンセプトや進捗を切り捨てるアプローチで確実に完成させることを目指します。

 

（/前編：仮説と試行・1weekWCのイベント）