本プロジェクトについて
本プロジェクトは、WPFの魅力が引き出され、Interactive Designerの実力が伝わるようなコンテンツを、主にクリエイターに向けて制作しよう、という目的の元で開始されたプロジェクトです。
機能を確認できるだけのデモンストレーションではなく、実際に楽しめるコンテンツを作ることで、WPFの可能性を実感してもらうことを目指します。
2006年10月22日
このブログについて
普段はAdobe Flashでコンテンツ制作を行っている私達が、いかにしてWPFを覚え、またチームとしてどういった役割分担で開発していったのか、他のクリエイターの方々が後で参照できるよう、進捗をblogに書き記していきました。
プロジェクトが始まって、最初はプロトタイピングを繰り返していたのですが、企画がドミノ軒の方向にある程度決まり、実際に手を動かし始めた7月から進捗を書き込み始めています。
また、8月末の一旦完成時までは、リアルタイムで進捗を記していますが、9月のブラッシュアップ期間は、後から振り返る形で書き加えています。
各メンバーが、それぞれの視点から、その時々の成果や悩みを書き残しています。
断片的な情報が多く、直接参考になる部分は少ないかもしれませんが、WPFについて何も知らないメンバーでも最終的にここまで作り込んだものを制作できるんだ、という実感を持っていただければ幸いです。
ドミノ軒について
ドミノ軒は、ラーメン屋の店主がドミノを置くリズムに合わせ、客の食べる動作が音楽になっていく、一種の音楽ムービーです。ユーザーはリアルタイムに描画される3D空間の店内を、あらかじめ編集されたカメラワークで閲覧することも可能ですし、自分でカメラを動かしながら、各キャラクターの動作を見ることも出来ます。
本プロジェクトがドミノ軒という企画に具体化していくまでには、長い紆余曲折があります。
これは、WPFを使うことが初めてだったため、開発の過程で判明した可能性や制限を、企画に修正・反映させる作業が頻繁に発生したことによります。
以下簡単に経緯を述べます。
まず最初に、WPFのどの機能をフィーチャーするか選択するところから始めました。
ビジュアル面でのインパクトがあること、Flashでは実現不可能な表現であること、の2点を念頭にWPFの機能を調べ、3Dを簡単にコントロールできる機能を企画の中心に据えることに、早い段階で決めました。
しかし、最初のテストの段階で、WPFの3Dコントロールの簡単さは、パフォーマンスとのトレードオフだという事実に突き当たります。ゲームで実現しているようは複雑な3D描画はほぼ不可能だと。
そこから、簡素で魅力的なオブジェクトの探索が始まり、やがて、ドミノというモチーフにたどり着きます。しかし、ドミノという直方体の簡単なモデルでも、3D機能をアピールできる規模の数量で並べることは難しく、根本的な打開策を考える必要がありました。
そこで、それまで想定していた、ドミノを使ったゲーム・アプリケーション的なコンテンツから、もっと作品性の高いものにすることで、既存のゲームなどとの3Dスペックの比較から逃れられるのではないか、と考えました。
ここで、兼ねてからクリエイターとして尊敬していた、qubiさんに企画から一緒に考えてもらえないかと、声をかけました。qubiさんは、ラーメン屋の店主にドミノを並べさせる企画を出しました。
そして、最初の底本となったのが、この企画メモです。
この面妖な企画を具体的に実装するために、どうしたら分かりやすくなるか、何日か話しあい、客が料理を注文することで音楽が生成されていく、インタラクティブなPVのようなモノに出来ないか、ということで話がまとまりました。
このblogでは、この辺りから書き込みが始まります。
そして８月の後半になり、仕上げの時期になって、結局音を同期させる方法を見つけられず、インタラクティブなPVから、PVへと方向転換することになります。これでようやく現在の公開されている企画にたどりつきます。
2006年10月21日
qubiプロフィール
アートディレクター役の勅使河原です。
今回はビジュアル上での方向性やら初期企画やらに携わりました。
2006年10月15日
ドミノ軒を振り返って（勅使河原版）
僕がこのブログに書き込むのは今回で3回目。他のみんなは数十回書いてる。まるでさぼってるみたいじゃないか。そんなことは無い。これでも一応あーだこーだと口では言っていた。
6月、ドミノを使ってなにかする、というのが決まっている段階から、僕はアートディレクション役として参加した。実際にドミノを配置し、そして倒れるまでのデモを見せてもらう。ここに何をすれば魅力的になるのか。そんなところから考え始めたように思う。
正直、こんなやり方は僕にとっては初めてのことだった。ドミノを並べ倒すという仕組みが出来上がっているのに対して、後付けで世界観なりを吹き込んでいく。更にいえば、これはドミノの紹介ではなく、WPFの魅力を伝えるということが目的。とりあえず、どうしてドミノなんだ、という疑問を抱くような隙を与えたくない、という思いがあり、いくつかの構想を出した。
※役柄的にWPF開発の参考になるようなことは何一つ書けないことをご了承下さいませ。
＜以下は2006/6中旬あたりにこの案件用に出した企画＞
そもそもドミノを並べる、倒すという行為自体が、あまり面白くない。ひやひやしながら並べて、倒して達成感を得て、という感覚をパソコン上で得るにはなかなか難しいものがある。しかしドミノを3D要素の魅力を伝える道具として使うというのが決まっているので、ドミノを使って面白みのあるコンテンツにしなければならない。並べ、倒し、そこで展開が止まるというステップの多さにも注目。説明的にもしたくないので、複雑な操作も強いたくない。並べる動作自体を省略することでどうにかテンポを良く、そしてわかりやすく出来ないか。
///////////////////////////////////////////////
A案 〜ありえないところでドミノ〜
本来ドミノを並べるような状況ではない時に並べる。いくつかの小さなボリュームのシーンからなる。スクリプトで自動的に人物等を操作し牌を並べさせる。ユーザーはそれを邪魔するなにか。邪魔をせずにみていれば30秒以内に終わるようなさらっとした奥行きにして、最後無事並べ終わったら牌は倒れ、VISTAのロゴなど宣伝的なビジュアルが表示される。そして次へ。？
ビジュアルの雰囲気としては、リアルなドミノの挙動に、平面的な3Dの場や人物の表現、実写でいけるならば実写で、関節ごとに外して人形的にスクリプト側で操作。ユーザーはクリックで邪魔、マウス移動でカメラ切替、移動。
◆会議室（食事中）にて討論中
会議室にて大人二人が討論。口はパクパク。徐々にカメラが引いていくと、討論なんか無視してもくもくと机の絵でドミノをやってる男。そーとそーっと、並べてるけれど、討論してる二人は興奮しだし、ドンと机を叩く。すると机のドミノはバンと跳ねてぐしゃぐしゃ。そのドン、がユーザー。
※音について
牌にセンサー的なものを用意して、音を鳴らさせる。
それぞれが最終的に一斉に倒れた時にメロディになるように仕組まれてる。擬似的で良い。
◆ラーメン屋さんでのカウンター、食べてる最中
画像参考。カウンター脇から。寂れたラーメン屋さん。客ははじめは1人。すでにラーメンの器を手に持ちながら食べてる。店長がカウンターにドミノを並べはじめる。邪魔役は布巾でテーブルをふくおばちゃん。ユーザーはおばちゃん。徐々に客が増えていいき、ラーメン！の声が一斉になったりする。もしくはドミノ的に連鎖したりとか。ラーメンメンメンメン。
◆公園にて親子が肩車して歩いてる最中
すがすがしい朝の公園。本当朝って感じ。親子。子供は肩車をしてもらっている。親子で笑ってる。なんかしゃべってる。口ぱくぱく。子供はお父さんの頭頂部をぺこっとして、そこにドミノをならべてる。お父さんが子供に何か問いかけながら子供を見上げようとするとドミノが崩れ落ちる。ユーザーはお父さん。ちなみに歩くたびにドミノ揺れ。
※ふとったお父さんが寝てるお腹の上でドミノ。ユーザーはお腹。
◆御神輿を担いでる最中
ショイヤショイヤとおみこし。担いでる神輿の中にカメラが入ってく。その中は暗くてひんやりしていて、でショイヤショイヤとかけ声がこもって聴こえる。神様がこっそり祭りの最中に実はドミノを並べてましたという設定。ただ神様はみえない。透明。ドミノだけが動いてる。担いでるんでそのたびにドミノが揺れる。クリックで思いっきり揺れてドミノが倒れる。でもまた並べだす神様。
///////////////////////////////////////////////
B案 〜箱庭的〜ドミノの仕組みを使った人々〜
画像参考。ユーザーが出来ることは倒す事、ドラッグして並べかえる事。入った時点でランダムな場所にユーザーも居る？小窓にユーザー視点？キャプチャ？
音は環境音とドミノ音。
B案はドミノを添付画像のような人にしてしまい、そいつらを並べる、倒す、倒すとふとんで寝る、という地球規模の自信作だったのだが、会議では箸にも棒にも掛からずに終わる。
A案はドミノを中心にし軽いインタラクションのある短いCM的なものをいくつも用意し、最終的にドミノが倒れて絵になるオチを迎えては次へ次へと連続的に展開していくものなのだが、その中のラーメン屋パターンのみを使って変更を加え、発展させていくことになった。後のドミノ軒である。（ちなみにA案神輿パターンとB案についてはいつか、僕自身何らかの形で再現したいと思っている）
ラーメン案を詰めていく過程で、何度もよぎった言葉が、ドミノは時、という朴さんの言葉。ここをしっかりと解釈し楽しみとして要素にすることが出来れば、ドミノは真の主役になったことだろう。企画の詰め期間である7月時点では少なくとも、それをまとめることが出来なかった。時間切れだ。こうして、大枠としては、音楽の力を借りて、WPFがもつ3Dへの能力を活かした、ラーメン屋を舞台にしたランダム性、インタラクティブ性を持つPV、という方向で進めることになる。ランダム性、というのは、個人的には常日頃から非常に魅力に思っている部分で、パチンコでフィーバーを夢見て玉が無駄に流れる様をただただぼーっと見るかのような、そんな感じをこのドミノ軒にも是非持たせたようとしていた。
そのランダム性は、完成されたドミノ軒には存在しない。ユーザーの介入はどこにあるのか、カメラだけで良いのか、という点で、ディレクターである馬場さんのアイデア、ドミノにビートを刻ませ、メニューをユーザーに選ばせることで音も変化し乗算される、シーケンサー的な楽しみを持たせる、というのを取り入れることで、その代わりに消えていったものだ。
そして今、最終的に出来上がったドミノ軒には、楽しみの中心になるはずの、そのシーケンサー的な仕組みも無い。これは言い訳になってしまうが、WPFは我々チームにとっては全てが、先の見えない、手探りの中での開発環境であり、更にWPF環境自体がβ版であるということが、目指していた到達点へ辿り着くことを拒んだ。
WPFの魅力という点については、十分に知る事の出来るものは仕上がったと思う。しかし、個人的には、どんな構成であれ、ドミノ＆ラーメン屋のカウンターという、不条理を飲み込むだけの不条理、リアルを追求し壊した上でのバランス。どうしてドミノなのか、ということに対しての答え、またはそもそも有無を言わさないだけの力を持つ作品に出来なかった事に、非常に悔いが残る。
2006年10月07日
3Dデータ（オブジェクト数、頂点数、材質数etc.）
コンテンツに実際組み込んで使用したモデルの情報です。
舞台：
人＋料理（他に８体、計９体）：
料理（他に７品、計８品）：
開発の後に想う事
何が大変だったかと言えば、プロジェクト全体の視点で言うと、
”開発環境のポテンシャルが全くと言っていいほど見えない状況から作らなければならない”
というのに尽きると思います。
自分の立場で言えば、最も気を使った点は、
”3Dモデルのクオリティと再生速度（処理負荷）のバランス”
でした。
しかし、いったい、３Dモデルのどのプロパティ（頂点数、オブジェクト数、テクスチャの解像度）にシェイプアップを施せば効果的なのか、そもそも全てのプロパティに施さなければしょうがない事なのか、あるいは特定のプロパティに関しては施したところで効果が無いというものがあるのかどうか、とにかく最初＊１は何も見えていない状況でした。
そんな中で吉川さんから、「じゃあ根拠は無いですが、これが効きそうだからこれをシェイプアップしてみましょう」とか「これはあまり関係ないようでした、今度はこれをシェイプアップしてください。よろしくお願いします。」とか「えー、これはほとんど関係ありませんでした。ですがおそらく、これはこうでないと駄目でしょう。この範囲に収めてください。」とまあ、吉川さんに組み込んでもらっては、その効果を見て、っていう作業を繰り返して各プロパティのポテンシャル空間の広さを測るというか、真っ暗な部屋で、壁までの距離を測るようなことを繰り返していました。それは結構プロジェクトの半ばまで判らなくて、あれこれ修正していて。結構疲れましたです。
自分の主な役割は、そこまでだったので、あとは本当に皆さんお疲れ様でした。
いい飯、いい酒、ましょう！
＊１
最終的にも”確証”までは持てていませんが、以下の記事を見ていただければ
「ああ、これぐらいのものは動くんだな」
というのがお分かりいただけるんではないと思います。
今後、EXPRESSIONで開発される方の参考になれば幸いです。
ドミノ軒を振り返って
作業完了した今、これがWPFの魅力を伝えるものになっているのか、自分で評価してみると、巷のサンプルよりもはるかに高度なモデリングやアニメーションを行っている点から、なんとか及第はもらえるのではないかと考えています。
ただ、コンテンツとして成立しているか考えてみると、最後の最後でインタラクティブな部分を削いだことが、驚きや楽しさを半減させてしまったのではないか、という不安が残ります。
一方で、もう少し冷静に考えると、ラーメン屋にドミノを並べる、その醍醐味を無視して強引にPVにした時点で根本的な分かりにくさが侵入して来たのかな、という大きな不安があります。
今回はどこに普遍性を持たせればよかったのか、ジクジクと考え続けてしまいそうです。
そういった不安を抱えつつも、とにかく最後まで作り切ることで、何か異様な存在感を持つところまで到達してはいるかなと思います。
新しい環境に、新しい可能性を見出せたか。皆さんにこのコンテンツを一つの参照点として利用していただいて、より完成度の高い、面白いコンテンツを作っていただければ幸いです。
2006年10月06日
料理テクスチャ
料理の３Dモデルに使用しているテクスチャ画像.
＊１部、縮小表示あり。
店内テクスチャ
店内の３Dモデルに使用しているテクスチャ画像.
＊１部、縮小表示あり。
人物テクスチャ
人物の３Dモデルに使用しているテクスチャ画像.
＊１部、縮小表示あり。
テクスチャの解像度
テクスチャに関して、処理速度との関係という側面から主に注意すべき点は「解像度」ですが、これはどうやらコンテンツが再生されるPCのグラフィックカード（特にメモリサイズ）が大きく関係しているようでした。
最終版のテクスチャ画像は、最大のもので1024×1024pxとなりました。
人物テクスチャ
店内テクスチャ
料理テクスチャ
どうやらこの大きさが一般的なグラフィックカードのメモリサイズとの絡みで最大値として妥当のようでした。以下に今回使用しているテクスチャのリストを挙げます。
1024×1024px：（合計１２枚）
・人物９人分
・店内３枚
（主に天井床壁、カウンター。調味料のテクスチャも最終的にはカウンターのテクスチャ内に納めている）
512×512px：（合計４枚）
・ビール瓶
・チャーハン
・ギョーザ
・ラーメン
256×256px：（合計２枚）
・ピータン（皿も含む）
・ザーサイ＊唯一、png形式
64×64px：（合計７枚）
・ビールカップ
・店内の照明２枚（テクスチャのプロパティで異なるグローの数値を与えたため。）
・なべの煮沸アニメ用２枚
・テレビのチラツキアニメ用２枚
他の3D環境での経験が無いのでこれが一般的なことかどうかは言えないですが、WPF上ではテクスチャは解像度が荒いものを貼り込んでも、アンチエイリアス的な処理が自動的にかかって表示されます。なので場所によっては極端に小さなテクスチャを使用してもそれなりに見せることが出来ます。
例えばこのコンテンツでは、上記リストのようにビールの瓶のテクスチャは512×512pxですが、そのとなりに置かれているグラスのテクスチャは64×64pxになっています。テクスチャの中にくっきりとした色面の境界を持たないグラスに関しては、思い切って解像度を落とす事が出来ました。
この様にして、クローズアップして見せる様な部分には高解像度化、ほとんど遠くにしか見えないような背景部分には思い切った低解像度化を図ることで、よりストレスの無い効果的な見せ方が実現できたと思います。
2006年10月02日
完成・完了
細かいことを見ていくと切りがないのですが、当初設定した最後の1ヶ月間が過ぎたので、こちらで完成、作業完了とさせていただきます。
最終的な作品は、本サイトでご覧いただけます。
今回目に付くところで大きく変わったのは、全体の色調と、動きの同期、カメラワークでしょうか。
色調は、最後まで調整を続け悩んだところなのですが、夜のラーメン屋なんだけど、強い光に照らされ妙な白昼夢感がある、現状の雰囲気に決まりました。
アニメーションと音の同期もかなりよくなっています。これは直接見ている時の気持ちよさにつながります。ずれていると、ムービーの内容以前にそのズレに意識が向いてしまうものです。
カメラは私が担当したのですが、やはりツールが変わったことで、作れるモノが大きく変わりました。
アングルとタイミングを同時に編集できるということは、実写で言えば、撮影と編集を同時に行うようなもので、映像に関する知識経験が皆無の自分にはなかなか荷が重かったです。しかも、みんなの努力が最終的に報われるかどうかは、カメラのセンスにかかっているような気もして、なかなか責任重大だなと。
そんな経験不足とプレッシャーから、2，3日でカメラをつけ終わるつもりが、結局10日くらい粘ってしまいました。結果的にはカメラをつけながら調整が必要な点を洗い出せたし、全体の尻を持てたということで、やってよかったなと思っています。
それから、冒頭でタイトルを出すことで、ムービーとしてぐっと締まりました。
そのほか、人物モデル形状やテクスチャの調整など、細かいところにたくさん手が加えられています。これらの作業は、あまり目立たないかもしれませんが、確実に全体の品をよくしていると思います。
9月の頭に設定した目標に、なんとか到達できたのではないかと思います。
やりきった、と言ってよいのではないでしょうか。