見出し画像

UXデザイナーが秘密にしているノウハウを丸裸にするよ

こんにちは。UXデザイナー兼ゲーム開発者の小泉ヒロカです。

私は今、15年前に流行ったブラウザゲーム「モバイルウォーズ」を、スマホアプリに移植しています。

開発を始めてから2ヶ月、こんな風に変わってきました。

スクリーンショット 2021-07-07 11.43.16

バトル画面は、このように変わりました。

スクリーンショット 2021-07-07 14.03.05

この記事は、ゲームを開発するUXデザイナーが試行錯誤する様子を丸裸にして、普段あまり語られないノウハウを共有します。

自由と選択肢の豊富さに溺れていないか?

15年前にブラウザゲームを開発していた頃は、HTMLを手書きしたり、物理サーバをオンプレミスで運用するのが当たり前でした。

それから技術は大きく進歩して、高かった有料サービスが無料で使えるようになり、周辺サービスは充実し、今は様々な環境に恵まれました。15年前と圧倒的に違うのは、自由度が高まり、選択肢が増えたことです

しかし選択肢が増えてくると、あれもしたいこれもしたいとなり、「何を選択しないか」という「捨てる」判断が難しくなってきます。

捨てて捨てて、捨てまくれるか?

UXデザイナーに求められるスキルは、重要なものと重要ではないものを選別し、ユーザにわかりやすく伝えるという、「捨てる」&「選ぶ」センスです。

スクリーンショット 2021-07-07 17.15.18

ゲームを開発すれば日常的に何度も捨てる判断に迫られるのですが、その時どういう方針で「捨てる」判断を下してきたかを、UXデザイナーを目指している方に役立つ活きた事例として共有したいと思います。

古いゲームを復活させて、プレイヤーの体験は変わるのか?

まず、15年前に開始して4年ほどサービスしていたブラウザゲームがありました。また遊びたいと言ってくださる当時のメンバーさんもいました。

私が、このゲームを復活させようと思ったきっかけは、古いゲームを現代の技術で復活させたら、プレイヤーの体験はどのように変わるのか?というUXデザイナーとしての興味でした。

ですので、昔のままのブラウザゲームではなく、今どきのスマホアプリとして復活させることを選びました。

画像14

15年前のブラウザでは、やりたくても出来なかったゲームっぽい動きが、やっと出来るようになるのか!とワクワクしたりもしました。しかしその期待は、早々に打ち砕かれることになりました。

新しい技術やリアリティが、体験を向上させるわけではない。

まず試したことが、バトルの操作方法です。元がカードゲームなので、カードをめくる、場に出す・拾うといった操作があるわけですが、もっと手触り感あるリアリティのある操作に変えられるのではないか?と思いました。

・新しい技術を使うこと
・操作にリアリティがあること
これらがあるとより良くなる、と何となく思っていたんですね。

以前の操作はこのようなものでした。

スクリーンショット 2021-07-07 11.39.40

これをUNITYを使って実装してみました。

UNITYでバトル

これまでただ画像を指で押すだけだった操作が、カードを手に持って場に出す、という現実のカードゲームに近い操作になりました。

ところが、繰り返しテストプレイをしたところ、どうしたことか、すぐに指を動かすのが面倒になってきました。

どうしてか?指を動かした結果どうなったかを見ると、実は、ただカードがオープンするだけでした。指を動かすことはプレイヤーにとって時間がかかるコストです。

だから、プレイヤーの指を動かす時間対価を上回るメリットを提供しなければいけません。

指を動かす労力より得られるメリットが下回ったため、プレイを続ける気持ちがなくなってしまったのですね。そのため、この「カードを持って動かす」操作は早々に没になりました。

以前のブラウザの操作方法のままアプリに実装したところ、まあまあ快適にプレイすることが出来ました。

つまり、新しい技術を使うことや、リアリティがあることは必ずしも体験の質を向上させない。それより重要な前提があります。

ユーザのかける労力 < 大きな変化(メリット)

どうやらプレイヤーの体験の本質は、以前の型ですでに完成されていたようなので、型は変えずに演出を強化することで体験の質を上げようという方針が決まりました。

2Dから3Dへジャンプアップして演出を強化

2Dのままでいるよりいっそ3Dにすれば、さらに演出を強化出来るのでは?もともと2Dに近い形状をしているカードのゲームをわざわざ3Dにするなんて、なんだか楽しそうです。

そこでまず、従来は画像とテキストで表現していたロボ(アバター)を、立体に出来ないかを検討して、ロボがキューブ型になりました。

スクリーンショット 2021-07-07 16.52.29

ロボなのだから、ローポリゴンやボクセルでやりたいという思い込みもありました。

ですが、実装にかかる時間と過去の資産を有効に活かすという両輪で検討した結果、UNITYのデフォルトのキューブにそのまま貼り付けて、「これがモバイルウォーズのロボです」にしようとなりました。

コンピューターの形はどんどん薄くシンプルになり、ユーザの目に見えない存在を目指している昨今です。ロボだからと言って人型である必要はありません

スクリーンショット 2021-07-07 17.20.44

ロボの本体はキューブで、カスタマイズ可能なアバターはロボのラッピングです。3Dにしたことで、世界観に広がりが生まれました。

スクリーンショット 2021-07-07 18.52.18

こうして作ったキューブ型のロボをランド(闘技場)に置くと、にぎやかで良い感じ。

スクリーンショット 2021-07-07 23.00.30

さて、これをバトルに配置するのですが、どこに配置するのが最適かを探します。

5回捨てて6回作る

まずはポケモンのように自分を手前、相手を奥に置きましたが、相手がカードの裏に隠れてしまいました。

スクリーンショット 2021-07-07 22.59.34

次は、格闘ゲームのように左右に配置しましたが、ロボが浮いているように見えるのが、いただけません。

スクリーンショット 2021-07-07 23.00.53

ロボを床の上に置きました。安定感は出たけれど、今度はカードが浮いているように見えます。

スクリーンショット 2021-07-07 23.01.13

さらに、ロボ2体で闘っているように見えるのは良いのですが、上の方で表示されるカードが自分のだけです。そこで、カードを両方表示しました。

スクリーンショット 2021-07-07 23.01.29

お互いのカードが左右に6枚表示されているので、2体が戦うことがひと目でわかります。

しかしこれでもまだダメです。カードの内容が片方だけ表示されているので、相手に見えているような印象を受けるし、カードはまだ浮いているように見えます。

なにより、相手のカードを表示しているスペースが大きくなりましたが、「これは相手のカードである」という情報しか伝わりません。これだけ大きなスペースで伝える情報量としては物足りません。つまり不要なはずです。

スクリーンショット 2021-07-07 23.05.09

不要な情報は思い切って削除し、テーブルのようなものの上にカードを置きました。奥行きも出たし、一見良かったのですが、肝心のカードを出したときに隠れて見えなくなりました。

画像18

プレイヤーが知りたいのは、カードであって、ロボはあくまでお飾りです。だけど、演出が途中で見えなくなるということは、なぜ演出が中断されるのか理由が必要です。中断する理由は特にないので、これは良くない演出です。

最終的に落ち着いた形

ロボが上部でダンスを続け、中央はカードと勝敗の表示、下部にコントロール部をまとめました。

スクリーンショット 2021-07-07 17.33.57

こうして出来たバトルは、画面の下をさわっているだけで全自動でプレイができるようになりました。プレイヤーは、操作のコストはほぼゼロで得られる変化が無限に続きます

昔のブラウザゲームとは違うけど、昔の楽しさは失わないまま新しい楽しさを提供できるようになったと思います。

おわりに

今回はプレイヤーのコストを下げるという視点でUXを語りましたが、コストは下げれば良い、というものでもなく、得られるメリットが大きければ喜んでコストを払うのがゲームの面白いところでもあります。

欲しいカードをゲットするためにガチャを回すだけでなく、ポケモンを捕まえるためにお出かけしたり、モバイルバッテリーを買ったり、最近だと馬券を買ったりするのですね。

次回の記事は、得られるメリットを最大化する視点で書いてみたいと思います。

楽しんでもらえるゲームを作る試行錯誤はまだまだ続きます。モバイルウォーズに興味を持たれたらフォローお願いします!


この記事が気に入ったらサポートをしてみませんか?