YosukeM's

非同期に対するUIの戦略

ファイルやネットワークなどの比較的遅い処理を伴うアプリケーションにおいて、ユーザーには処理の遅さを感じさせないようにしたい。そんなときどうするか。

・とりあえずユーザに応答
　ウェブアプリケーションでよくやる。とりあえず、ユーザに対するUIの応答（画面への描画や効果音の再生）だけ先にやっておき、実際の書き込み処理はバックグラウンドでやる。
　書き込み処理が失敗した場合に、画面表示をリセットしたり、書き込みキューをクリアしてやる必要がある。
　これをより推し進めて、書き込みキューをGUIで操作できるようにしているソフトウェアもあるが、これを有効に使えている人を僕は見たことがない。

・単一画像/テキストの表示
　読み込み/書き込み中に一枚絵を表示する。いわゆるスプラッシュスクリーン。手抜きっぽいが、何もしないよりは遙かにマシである。
　よくあるパターンとして、ロード画面を利用して、操作説明やヒントを表示するものがある。なんども同じヒントが表示されると、ユーザは飽きてしまい、まともに読まなくなるので、効果が薄れるという欠点がある。

・進捗状況の表示
　ダウンロード率や、プラグインXXを読み込み中……といった情報を表示する。ダウンロード率を表示することによって、ユーザーは残り時間を予測し、他の作業をすることができる。待ち時間が非常に長い場合には効果的。
　インストーラやダウンローダなど、事務的なアプリケーションでは、こうした表示を出した方が信頼感があってよい。
　一方で、待ち時間が短いことがあらかじめわかっており、かつ、ユーザにシステムを意識させたくない場合には、この手法は適していない。

・アニメーションを表示
　アニメーションを再生して、読み込みが終わるまで待つ。一口にアニメーションと言っても、いくつかのパターンが考えられる。

・ループアニメーション
　昔のゲームでよくあった。開始と終了をなめらかに結ぶために、フェードイン、フェードアウトくらいはつけることもある。フェードイン途中でロードが完了した場合どうするのか。フェードアウトはどのタイミングで開始するのか、などが問題になる。完全にロードが完了するのを待ってフェードアウトしていると、ユーザーを拘束する実時間は長くなってしまう。ロード時間が極めて短い場合には、あえてアニメーションを流さない方が体感時間を短くできる。

・ノンループアニメーション
　近年採用例が多い。見せ方によっては、読み込みを全く意識させず、2つのシーケンスがきちんと繋がっているように見せることができる。
　アニメーションがロード時間より早く終わってしまった場合はどうするのか考えておかなければならない。よくあるパターンは、ブラックアウトしてごまかすか、ループアニメーションに移行するかのいずれかである。

・画面のスナップショット
　これもノンループアニメーションの一種だ。現在の画面のスナップショットを取り、それをフェードアウトさせることによって、アニメーションの代わりにする。スナップショットを取った瞬間に現在のシーンに関する情報を破棄することができるので、メモリを無駄遣いしない。WiiとGCで出てたゼルダ（タイトルは忘れた）がこれだった。クラッシュバンディクーもこれだった。

・インタラクティブアニメーション
　開き直ってロード中もユーザに操作する余地を与える。採用例は少なくないし、ユーザの反応も悪くないが、ユーザ体験に大きな影響を与えるので、企画段階からそれなりに考えておく必要がある。

・音楽を流す
　BGMのあるソフトウェアであれば、ロード中も音楽を流し続けることによって、ユーザの体感時間を短くできる。ロード前とロード後で同じBGMを使うことが許されるならこれでいい。問題は、BGMを変えたい場合だ。音楽が演出に与える影響は大きいので、なるべく細かく制御できることが望ましい。

　変更すべきBGMが事前に分かっているかどうかによっても、取り得る対応が異なる。
　二つ以上のサウンドを同時に読み込むのが苦しい環境では、前のサウンドをある程度バッファリングしておく必要がある。バッファが切れたときはどうするのか。ストリームしながら読み込むと、当然のことながらロードにかかる実時間は長くなる。悩みが多くなるので、機械の性能が限られているときは、素直に音を消した方がいいと思う。

・BGMを繋ぐ音を生成する
　インタラクティブミュージック的なアプローチ。採用例は少ない。JSRFとか。

・逐次表示
　ウェブブラウザなどで採用されている方式。読み込みの完了を待たず、今あるリソースを使って、不完全でもいいので画面を描画する。今コンピュータが頑張ってますよ感をアピールできる。プログレッシブJPEGやLoDなど、これを意識したデータ構造を用意するとよりよい。
　利点としては、ユーザを待たせる実時間が最も短くなる。データの先頭が重要で、それ以外は子葉末節であるという場合に効果的だ。
　欠点としては、不完全な画面をユーザに見せてしまう。どうしても見せたくない場合には、他の手法と組み合わせる必要がある。それから、自分で実装しようと思うと結構大変。

・隣接ノードの先読み
　これまでに上げた手法は、UIのシーケンスが非連続的に繋がることを前提としていた。しかし、メモリに十分な余裕があるのであれば、連結可能なシーケンスを先読みすることによって、シーケンス間の断絶を避けることができる。
　この応用の最たる例としては、ワンダと巨像のオープンフィールドなどがある。しかし、きちんと実装するのは非常に難しい。例えば、先読みが間に合わなかった場合にどうするのか。遠景をどのようにして描くのか。メモリの断片化を避けるにはどうすればいいのか。考慮すべき事柄は多い。

・全部一律で遅くする
　UIの応答をあえて遅くするという方法がある。重要なのは、一時的に遅くするのではなく、常に遅くするということだ。ユーザーの操作に対して、画面が常に2〜5フレーム程度遅延していたら、人は遅延になれてしまう。そこで、処理時間を稼ぎ、ファイルやネットワークに関する処理を行う。
　複数のフレームの処理を並列に行うための仕組みを用意する必要があるが、それさえ用意してしまえば、そこから先は早い。全てのユーザー入力が遅延するため、柔軟性に乏しいのが欠点だ。
　何かのアーケードゲームでこの方法を使っていた。たしか、バーチャファイター5だっただろうか。

・読み込まれる情報の予測
　これはUIには応用しがたいかも知れないが、一応書いておく。具体例はPSOである。PSOでは、味方プレイヤーの位置をネットワークから持ってくるよりも先に、位置を予測して描画してしまう。
　この位置の予測はそれほど狂わない。なぜならPSOのキャラクターの動きはもっさりしていて、慣性によるところが大きいからだ。それに、PSOではプレイヤー同士が殴り合ったりするわけではないので、多少、位置がずれていても問題ない。
　Google Mapの読み込み戦略はこれにあたる。

・まとめ
　なんとかがんばって一般化できるんじゃないかと考えたけど、難しい。

最初は、義務を増やせば部として安定するだろうと思った。
たとえば、展示会を定例化するとか、年一回は作品を出すよう部員に義務付けるとか。
だけどそれをやってしまうと、発展性がない。自由な発想の余地がない。
同じことの繰り返しの中から、生じるクリエイティビティもあるかもしれないけれど、やっぱり、自分としては、常に環境に応じて変化を続けられるサークルであってほしいなと思った。
それに、サークル創立時のコンセプトからすれば、クリエイティビティを失った時点で、もはやこのサークルがサークルとして存続する価値はない。

というわけで、あまり義務を作らないことにした。

テントはぶっちゃけ失敗だったと思う。
参加者するといっていた人が予想を下回ったというのも正しいし、そうなることを予測できなかった運営の、事前のリサーチが足りなかったというのも正しい。
当初の目的を見失っていた感じがある。
つまり、黒字を出して利益を獲得することに対する意欲が足りない。
去年結局あまり利益が出せなかったという点も、それなりに影響を与えていると思う。
個人のポケットマネーになるはずが、部費になってしまったというのがよくない。
人にお金をあげて、自分が利益に貢献したという実感を与えるべきだった。

そう、実感。
所属意識がどうこうというのならば、まず先に、部員たちが部としての利益になんらかの形で関わってもらうことが必要だったかな、と思う。
たとえば、僕にとっては、春先にやったウェブサイト制作。あれが部としてのメリットになると同時に、自分の評価を高める材料として作用した。
そういう、部にとってメリットがあると同時に、各個人にとっても、役に立った！人から評価された！という感触が必要なのかな、という気がする。
結局、団体としてうまくまとまっていくためには、義務を増やす必要がある。
ただし、対外的な義務ではなくて、体内的な、もっとメンバーに運営側としての自覚を持ってもらうための義務だ。

昔やっていた某仮想週刊誌では、ある時期運営メンバーがものすごく不足して、それに危機感を感じた古株が、新人を編集部に引き込むキャンペーンを展開した時期があった。
そのときに引き込まれたメンバーは、今でも中心的ポジションで、腕を振るっている人たちが多い。
その理由を考えてみると、やっぱりなんだかんだといって、「編集部にはいった」というそのこと自体が、一番大きく関与しているのではないかと思われる。
編集部にいれば、何ヶ月かに一度、企画を立てようという話になるし、結果として運営に関わることになる。
そのときの経験が、後に愛着心となって、人を居残らせる。

というわけで、何かしら強制的に、今までなら運営がやっていたような仕事をヒラの部員にやらせるというフェイズが、必要なのかな。
責任の所属を明確にして、逆にいえば、この部分は俺がやったと、他人にアピールできるような部分を作ってやらないといけないのかな。

[めも]キャラクター操作感の分類

キャラクターを操作して何かをする、というインターフェースはたくさんあるけれど、それをミクロな視点で考察する語彙を持っているのは格闘ゲームだと思う。

格闘ゲームには、大きく分けて二種類のキャラクターがいる。一つは、技の発生が早いキャラクター、もう一つは、技の発生が遅いキャラクターだ。発生が早いというのは、モーションの再生開始から当たり判定出現までにかかるフレーム数が少ないということで、発生が早いほど初心者向けのキャラクターといわれることが多い。ゲームにもよるが、大体4～12フレームぐらいで判定が発生すると感覚的に操作できる気がする。スマブラは格ゲーの中ではかなり平均発生時間が短い部類だ。DMCもかなり短い。

逆に、判定の遅いキャラでは、「置き技」が重要になってくる。相手が距離を詰めてくることを見越して、先にコマンドを入力しておく。こういう「読み」が必要とされる場面が多いのが、上級者向けといわれるゆえんだと思う。

発生の遅い技は使うのが難しいが、モーション再生時間の極端に長い技もまた、使いこなしづらい。当たり判定が焼失した後の後スキが大きくなるからだ。モンスターハンターは発生も遅いが、モーション再生も長い。もっさりゲーともいわれるけれど、こういったゲームはプレイヤーの慣れで次第に強くなっていく手ごたえを味あわせることができる。

いずれにせよ、ゲームにおけるすべてのキャラクター操作は、
・モーションの再生
・当たり判定（ゲーム内での効果）の発生
・座標の移動
の三種類に分けて考えることができる。

たとえば、キャラクターを移動させる際は、まず歩き始めモーションを再生しながら座標を加速度的に移動させ、同時に当たり判定も移動させる。速度が最高速に達したら、歩き始めモーションを歩きモーションに移行させる、といった作り方をする。モーションと速度、加速度がきちんとかみ合っていることが、プレイ感覚にも重要だ。

座標移動には加速度運動、摩擦運動を伴わせることが多いが、移動し始めの加速度が大きいほど、操作しやすいことが多い。例えばマリオは、ソニックに比べて加速度が大きい(というか、ソニックの最高速度が加速度に対して大きい) U4の加速度が極端に大きいのもこのためだ。

大神のように、一定距離を走ると最高速度が段階的に引き上げられるゲームもある。

ゲームによっては、速度ベクトルのdThetaに制限を設けている場合もある。馬にまたがって世界を旅する系のゲームに多い気がする。上田作品。上田作品は座標移動だけでなく、モーションにもインタラクションを取り入れているので、ここで話すのとはレベルが違う気がするなあ。

ジャンプには二種類の挙動がある。等速ジャンプと物理ジャンプである。スーパーマリオは伝統的に等速ジャンプに近い挙動をするが、多くのゲームでは物理ジャンプをする。

星のカービィのように、落下距離に応じて落下の最高速度が段階的に引き上げられるゲームもある。

特定の操作に対して、カメラの移動が伴う、という操作体系がある。代表的な例は、バーチャロンのジャンプとダッシュ攻撃。こういったカメラ移動は、一見すると直感に反しているように思われるが、案外体感的に会得できる場合が多い。

ある程度の速度を持ってUターンしようとすると、独自のモーションが再生されるゲームもある。マリオ64などがそうだ。マリオ64のUターンはモーションと座標系の変異がきれいにかみ合っていて、とても心地がいい。Uターンとよく似た操作にブレーキがあるが、モーション終了後に速度ベクトルが0になる点が異なる。スマブラXのプリンは空中緊急回避後に速度ベクトルが0にならないため、まるでUターンのようにふるまえるが、スマブラDXのプリンで同じことをやろうとするとブレーキになってしまう。