UI制作過程あるある① ゲーム上の通知方法でよく事故る

どーも! デザイナの大河原です!

「ゲーム開発のUI制作過程でのあるある」を書き溜めておこうかなと思う今日この頃。
あるあるを吐き出すことでUI制作の明るい未来にほんのちょっとでも繋がるといいなぁ。

さぁ、いってみましょう!
第1回目は「ゲーム上の通知方法でよく事故る」です。

ゲーム上の通知方法ってなんぞや? と思われるかと思いますが、
ここでは「ゲームからプレイヤーへ、ゲームの状況を通知する演出」のことを指します。

例えば、
・レベルが上った!
・仲間が増えた!
・いいアイテムが出た!
・仲間が死んでしまった…
など、多くのゲームでは「ゲーム上で何が起きているのか」を何らかの方法で「プレイヤーに通知」しています。

これらの通知の手段は様々ありますが、私なりに4つに大別しています。


①持ち上げ系通知
→ プレイヤーに高揚感、期待感を覚えてもらうための通知。
(演出が凝っていることが多い)

②注目系通知
→ プレイヤーがゲームをプレイする上で、支障の出ないようにする通知
(いわゆるUIと呼ばれるもの)

③垂れ流し系通知
→ プレイヤーが見落としてもゲームプレイはできる程度のゲーム内の出来事の通知

④通知しない
→ システム内部で更新はあるが、プレイヤーには開示されないもの
(いわゆる隠しパラメータ)


さて、この大別した通知、この使い分けはゲームによって変わります

・どんなところで期待が持てるのか?高揚感を得られるのか?
・プレイする上でこの場面で必要な情報は何なのか? 逆に阻害してしまう情報は何なのか?
・何をプレイヤーに伝えて、何を伝えないのか?

複数人での開発において、完成形が全く同じイメージを持っているというのはほんとに稀です。
そして、100%完成形のイメージを持っていることも稀です。

そんな稀が重なる開発中は様々な事故が生まれてしまいます。
・過剰な演出にするつもりはなかった
・さりげない演出にするイメージではなかった
・演出が多すぎてテンポが悪い
・演出がなくて楽しさが半減している
・表示されている情報が多すぎて見づらい
・表示されている情報が少なすぎてゲームプレイしづらい など

この事故を解決する回数が多いと開発チームは疲弊しますし、
通知方法がゲームにマッチしていないとプレイヤーにデメリットが多く発生します。

・想定外な制作コストが発生してしまう。
・イメージしてたゲームサイクルの体験がプレイヤーに伝わりづらくなってしまう。

いやほんとシャレにならないです。
多く重なると「やってらんねぇ」という気持ちが湧いてしまいます。

こうした事故は「アウトプットとコミッニケーションの結果」で発生しやすいため、
事故を防ぐためには「情報の共有のスムーズさ」が肝になります。

仕様書を作成する際に「通知の仕方」を意識して作成する。
デザインを作成する際にゲーム性を考慮して演出を作成する。
そしてそれらの情報を関係者全体で共有し、「ゲームにマッチした通知は何か」を把握する。 チームでのスムーズな共有方法を見つけることが近道なので、その方法もチームで模索していけるといいですね。

(ツーカーの仲だと楽だったりするんですかねぇ…)

(Visited 108 times, 1 visits today)

コメント投稿は締め切りました。