mieki256's diary



2005/01/26(水) [n年前の日記]

#8 [game] ゲームのロード時間についての夢想

ROMカセットでゲームを遊んだ体験が無い層が増えてくれば、 *1 今後、ゲームのロード時間の長さは、肯定される風潮になるのだろうか。などと夢想したり。

なわけないか。TVという受動的なメディアですら、CMが入ると客はコンテンツへの没入を停止する。ましてやゲームは、客が能動的に働きかけるメディアなのだから、ロード時間が長い=コンテンツへの没入の分断をより強く意識させられる。ロード時間は短いにこしたことはないよな。

が。凝った画面を見せようとすると、必然的にデータ量は多くなり、同時にロード時間は長くなる。さりとて、ロード時間が短くなるような少ないデータ量では凝った画面を見せられず、商品の訴求力を失う。 *2

ということで、本当はロード時間が長いんだけど、客はそう感じない ―― つまりはロードの長さを誤魔化すテクニックの洗練が必要になるわけで。つーことで素人ながらぼんやりと案を考えてみたり。

CMを入れる :

TV番組の真似というか、ロード中の時だけ受動的メディアに変化するというか。静止画を数枚、エフェクトを加えながら表示してみたり。一枚じゃたぶんダメ。飽きるから。

別にCMでなくてもいいか。開発者のインタビュー映像が流れるとか。ってドライブをロードで使ってるのに映像流せるわけないじゃん(爆) じゃあ、せめて静止画とか…。

画像情報だけじゃダメだろうな。テキストも混ざってないと。画像情報だけでは、パッと見ただけで、ユーザが認識したつもりになっちゃうから。テキストを与えて、ユーザ自身のロード時間(?)も稼ぐ、みたいな。

テキストにはトリビアが入ってないとダメ。ユーザが読みたくなるようなテキストじゃないと時間稼ぎができない。でも、テキストが充実し過ぎちゃって、「もっとロード時間を長く!」「ロードが早すぎて読めないよ!」という声がユーザからあがってきて本末転倒に。…それはないか。

開発者の開発日記が読めると面白いかもしれないなぁ。企画スタート→開発難航→内紛→意思統一→マスターアップのプロジェクトX的流れを追体験してロード中に涙を流すユーザが続出。…ぶっちゃけありえない。

正直に告白する :

ユーザにとっては、情報の提示なく待たされることがもっとも苦痛であると想像するわけで。現在、何の処理をしてるのか、事細かに説明してみるとか。
「データのロードを開始します」
「プレイヤーキャラのデータをロードします」
「テクスチャデータをロードします」
「テクスチャデータは xx:xx:xx.xx に存在します」
「現在、ピックアップ(?)は xx:xx:xx.xx にあります」
「ピックアップを xx:xx:xx.xx から xx:xx:xx.xx まで、xx:xx:xx.xx 分移動します」
「ピックアップの移動速度は平均 xx:xx:xx.xx /secです」
「xx:xx:xx.xx 分を移動するのにかかると思われる予想時間は xx.xxx sec です」
「ピックアップ移動中。終了を待っています。 xx.xxx sec お待ちください」
「エラーが発生しました。リトライします」
「コマンドを再発行しました」
「エラーが発生しました。リトライします」
「コマンドを再発行しました」
「エラーが発生しました。リトライします」
「コマンドを再発行しました」
「エラーが発生しました。リトライ回数を超えました」
「ドライブ初期化コマンドを発行します」
「ドライブ初期化コマンドは xx.xx sec ほどかかります。お待ちください」
「コマンドが受信されました。処理を続けます」
「現在、ピックアップ(?)は xx:xx:xx.xx にあります」
「ピックアップを xx:xx:xx.xx から xx:xx:xx.xx まで、xx:xx:xx.xx 分移動します」
「ピックアップの移動速度は平均 xx:xx:xx.xx /secです」
「xx:xx:xx.xx 分を移動するのにかかると思われる予想時間は xx.xxx sec です」
「ピックアップ移動中。終了を待っています。 xx.xxx sec お待ちください」
「ピックアップ移動が終了しました」
「テクスチャデータ読み込みを開始します」
「テクスチャデータ容量は xxxxxxx byteです」
「読み取り速度は平均xxxx byte/sec です」
「読み取りにかかると思われる予想時間は xx.xxx sec です」
「読み取り中。終了を待っています。 xx.xxx sec お待ちください」
「読み取りが終了しました」
「xxxxxx byte の圧縮データをメモリ上に展開しています」
「データ展開速度は、約 xxxx byte /sec です」
「xxxxxx byte を展開するのにかかると思われる予想時間は xx.xxx sec です」
「データ展開中。 xx.xxx sec ほどお待ちください」
…ムキーッ! やりすぎじゃ。

やりすぎではあるけど、ユーザから、「こんなに色んなことをしてるなら時間がかかってもしょうがない」と思ってもらえるかもしれない。…嘘。「わけわかんねーメッセージを表示してる暇があったら、さっさとロードしろよ!」とか怒られそう。…メッセージを表示OFFにしたところで、ロードは早くならないんですけどね。

ていうかゲームって、舞台裏をユーザに極力見せないように努力してるメディアで。この方法はその基本姿勢に真っ向から反対するやり方。いや、ゲームに限った話じゃないけど。娯楽コンテンツはどれも同じ。それは当たり前の話で。ユーザがコンテンツに没入してる瞬間に、それ以外の情報を与えてしまうと、コンテンツへの没入が分断されてユーザはストレスを感じる。故に舞台裏は極力隠すんだけど。

しかしロード中は、否応無くコンテンツへの没入を分断される。であれば、ゲーム本編とは異なる情報提示の姿勢が求められてしかるべきな予感。

計算でBGVモドキを見せる :

前述の鬱陶しいメッセージの一つ一つを、図形描画に必要な数値情報に置き換えて、アニメにできないだろうか。要するに、Windows Media Player 等で音楽再生したときに見られるようなエフェクトを表示して、ロード待ちのイライラを少しでも緩和できないかと。

既にどこかでやってそう。音楽データを読み取ってステージにしちゃうゲームもあったはずなので、それに近いことをやってる商品があってもおかしくないような気が。

中途半端に読んで中途半端に表示する :

インターレスGIFみたいに、読んでる途中でもどんどん表示しちゃう。最初はモザイクみたいな荒いテクスチャだけど、ゲーム本編を遊んでるうちにだんだん真っ当なテクスチャになってきて。ついでにモデルデータも同様に。最初はただの箱だったのが、だんだんそれらしい形に。

ってどうやって。無理ですな。…本当に無理かしら。いやー、でも、ゲーム本編を動かしながらロード・データ展開って、重いだろうなぁ。ゲーム本編を動かすだけで精一杯なのに。

ていうかユーザからクレームがつきそう。「ゲームを始めると画面がギザギザするんです」とか。サポートの電話鳴りっぱなし。たぶん。

視覚情報を極力そぎ落としたデータも同梱する :

モデルは箱ばかり。メニューはテキストオンリー。テクスチャはなし。全部生ポリゴン。そういうデータを用意して、レスポンス重視のユーザにはそっちを選んでもらう。嘘。1つのデータを作るだけでも大変なのに、2つも用意してられませんがな。バグチェックが2倍の量になる。地獄。

ていうかハードウェアが変わるとガラリと速度が変わるからなぁ :

いっそ、グレードの違うゲーム機を用意しちゃうとか。安い機種はドライブが4倍速だけど、高い機種は16倍速、とか。メーカ製PCみたいな戦略。ってスペックが固定されてるからかろうじてゲームが作れてるのに、これ以上対応しなきゃいけないハードを増やしてみてどうするねんという気も。コントローラの種類が1つ増えるだけでも、ヒイヒイ言うのに。

ということで、やっぱり寝言しか出てきませんでした。グゥ。

*1: 携帯ゲーム機で残りそうな気もするけれど>ROMカセット、もしくはそれと同等のメディア。
*2: でも、視覚的な訴求力を絶えず得なければならないかというと、場合によっては、それは嘘で。ゲームの場合、例外が多々見られるのだけど。ユーザが能動的に働きかけることで成立するメディアだから、実はちょっと違う。

以上です。

過去ログ表示

Prev - 2005/01 - Next
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

カテゴリで表示

検索機能は Namazu for hns で提供されています。(詳細指定/ヘルプ


注意: 現在使用の日記自動生成システムは Version 2.19.6 です。
公開されている日記自動生成システムは Version 2.19.5 です。

Powered by hns-2.19.6, HyperNikkiSystem Project