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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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