2006/7/24

敢えて“標準”スクロールを作ろうとすることの意味  VRMスクリプト禅問答
45-50s氏が反応してくれたようなので、少し話を進めましょう。

標準スクロール(仮称)の開発プロジェクトは当面「スクリプト禅問答」カテゴリで扱います。また、このプロジェクトはボクや45-50s氏の占有物ではありませんから、絡んだり、別処で火の手を挙げて下さって結構です(可能なら適当にトラックバックしてください)。暫時ピックアップしていきますので。

いきなりテクニカルな話に飛び込んでしまうと多くの人にとって取り付く島がなくなってしまうようにも思うので、少し「自己弁明」も兼ねて寄り道しておくことにします。
ghostさんの入門的なレイアウト製作へのスタンスを2つ読みとることができます。

1)理想のレイアウトは量、質共に大き過ぎることが多く、製作は難しい。そこでレイアウトを現実的な範囲で製作するには、質の削減より量の削減を検討するべきであり、質は可能な限り維持せねばならない。

結論から言うと、上記は45-50s氏にはそう見えた、という話であって、ボクの真意とは異なります。つまり、ボク自身は他のVRMユーザーに対して質を要求も期待もしていません。
一方で、45-50s氏に「ghostは他ユーザーに質を要求している」と思わせた何か、がボクにあるはずです。それはボクが(特にこのVRM入道を書き続けるにあたって)VRMユーザー諸兄の「欲するところ」に敏感であろうとしているところに起因するのではないか、と思います。
つまり、高い質(ここでは専門誌などに見られる巨大・精密レイアウトをVRMでも作りたい、の意)を要求しているのは、ボクではなく、総体としてのVRMユーザーです。もちろん、個々人の好みには差異があるでしょうが、平均するとやはり巨大精密レイアウトを作りたいという願望が(実際には出来ないのだけれども)支配的だと理解しています。ボクはそれを感じ取って、銘々がそれを実現するための手がかりを提供し続けてきたに過ぎません。

先のエントリにおいて敢えて違和感を表明したのは、45-50s氏の言う「VRMの1つの楽しみ方=盆栽レイアウトの提案」が、ここでいう「ユーザー総体の欲するところは何か?」という視点とごっちゃになったまま進行しているように読めたからです。盆栽は盆栽で面白いし価値があるので大いに唱導されるべきだと思いますが、その唱導の手段として「ビネットやパイクによる入門は空虚」という言明をするのは「前向きではない」というのがボクの主張です。まぁ、神学論争は神学論争で面白いですけど。

*     *     *

話を戻します。

スクロールも然りで、この観点に留意が必要です。いや、むしろそうでなければなりません。これは以前にこちらのエントリで別角度から述べた通りです。「こういう遊び方もできるよ」という提案はそれはそれであるべきです。「こんなスクロールが書けるオレはすごいだろう!」と言う自慢も大いに結構。
ただし、「標準」として耐ええるスクロールを作ろう、つまり本来個々の他のユーザーが背負い込むべき苦労を進んで肩代わりして道を拓こう、という場合、想定されるユーザーが「総体として」何を望んでいるのか、どこまでが一般的なニーズでどこからが個人に特化したニーズなのか、を把握することが重要になります。それを意識しないのであれば、ハナから「標準」などと謳う必要はありません。
もちろん、厳密には「総体のニーズ」などという抽象的なものを正確に把握するなどということは不可能ですから、現実にはこれに代わる「仮説」をスクロール作者側が持ち、それにある意味での「責任」を負うことが必要です。そして、その仮説が計測不能な真実に近ければ、結果論としてそれは総体としてのユーザーに受け入れられるでしょうし、そうでなければ知らん顔をされて終わりです。配布されたスクロールは、たとえばそれがどんなに高機能であったとしても、唯一この観点でのみ評価されるべきです。
拙作スクロール群は明らかにその評価に耐えれていません。要するに利用されていません。これはボクのVRMユーザー総体のニーズを読み取る能力の限界を示しています。これが、ボクが単にスクロールを書くだけならば一人で勝手に作った方が圧倒的に早いことを百も承知の上で、敢えて衆人に晒しつつ進めようとしている真意です。早い話、他の人の意見も聞きながらやらないと、自分のアイデアが普遍的なのか突飛なのかが判断がつかない、という当たり前の話です。

以上の思索から、標準スクロール開発に際して以下の2つの基本方針を導くことができます。

・目指すところは「VRMの機能をすべて使う」ことではなく「ユーザーの欲する(であろう)ところを満たす」ことである。
・個々人のアイデアはいかなる意味でも歓迎されるが、それが普遍的でない(とスクロール作者たちの多くが判断する)場合、必ずしも実現されない。しかし、実現されないアイデアを提出することは罪ではなく、むしろ後日の資産となる。

たとえば、拙作「ポータブル編成ギミック一発組み込み」に関して言えば、僕が想定したユーザーニーズは以下のようなものでした。

・オリジナルの編成ファイルを(所有パッケージ以外の組み込み条件制約なしで)配布したい。
・すべての編成に同じキー操作を割り当てたい。
・可能な限り簡単な方法で、複雑かつ格好良く見えるギミックを組み込みたい。

一方で、ボクが「特殊解」であると判断して、同スクロールへの組み込みを敢えておこなわなかった機能もあります。

・(甲種回送等を想定し)個々の車両毎に灯火制御をおこなうこと。
・個々の車両毎に任意の画像リソースを割り当てること。

大雑把に言えば、これらが同スクロール開発に際してボクが拠った「仮説」であり、結果論から言えば、この仮説は正しくなかったのでしょう。多くのVRMユーザーに同規格の編成ファイルをネット上にバラ撒いてもらう、という意味でのポータブル編成プロジェクトは事実上頓挫してますから(ボクは当面は勝手にポータブル編成をリリースし続けますが、これはボクの勝手な趣味です)。

音声系の標準スクロール開発に際しても、同様の仮説構築が必要です。この仮説に沿ってフレームワーク(基本的な枠組み)を作り、これに準拠するスクロール群を積み上げれば、一般的なユーザーが実現したいと願う音声ギミックを一通りカバーできる仕組みが提供できるはずです。また、共通したフレークワークが用意できれば、スクロールを提供する側の開発や説明の負担軽減も期待できます。

で、長くなってしまったので、現時点でボクが抱えている実装アイデアは明日以降に譲ります。少なくとも、
音声リソースは号車順の画像リソースと違って、必ずしもリソースIDの1から順番に使われるものではないんですよね。例えば走行音だけカスタマイズしたい人や、一方で走行音は据え置き、ブレーキ緩解音とかノッチ投入音だけ使いたい人もいるでしょう。

45-50s氏が提起されている上の設問に対しては暫定解が既に見えていますので、これを中心に進めていこうかと思います。
0

コメントを書く

この記事にはコメントを投稿できません




teacup.ブログ “AutoPage”
AutoPage最新お知らせ