忍者ブログ
       
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

       

ソーシャルゲームが市民権を得るようになり、家庭用のコンソールゲームを凌ぐほどの急成長を遂げてきましたが、実際はゲームと呼ぶにはまだまだ未熟なコンテンツが横行しているのが日本のSGサービスです。
ブラウザゲーム時代のUX設計や課金スキームから脱却できず、海外メーカーが打ち出すエンターテインメント性の高い作品に一歩引けを取っているのが現実です。

1SGはギャンブル

ブラウザゲームの登場とともに確立した新しい金儲けの仕組み”ガチャ課金スキーム”
国内のSGメーカーの多くがこのガチャスキームを採用し、国産ゲームのほぼ全てに組み込まれていると言っても過言ではないでしょう。
よくできたビジネスモデルなんですが、実はこれがSGをゲームで無くす根本原因を作っています。

ガチャスキームがゲームを崩壊させる

ガチャはただの運試しでしかありません。
ガチャをひいて強いアイテムが出るか否かでゲーム攻略の有利不利が決まってしまいます。
コンソールゲームのルールでは、ゲームの進行に応じてキャラもユーザーも少しずつ成長していくものですが、ガチャはこのルールを崩壊させます。
おみくじ

ユーザーの熟達度合いやテクニックとは関係なく、ガチャの結果で全てが決まってしまうのでUXの作り方として、ゲームというよりギャンブルの思考に非常に近いのです。


アプリ開発に移行してからは、よりゲームらしいものが作れるようになり、アクション性の高いものも実現できるようになりました。
そのためパラだけの勝負で十分だったブラウザのカードゲームとは違い、ユーザーのテクニックなどが介入できるゲームシステムだと、パラ推しのガチャスキームがゲームの楽しさという部分で足を引っ張ります。

これは余談ですが、同僚のエンジニアさんがこんなことを言っていました。
『我々が作っているのは集金システムだ』と。
まさにその通りです。ユーザーから効率よくお金を回収するシステム。それこそ日本のソーシャルゲームです。

2操作性の格差

そもそも、スマートフォンはゲームを遊ぶための端末ではありません。どちらかといえばブラウジングに特化した機械です。
スマートフォンの性能が上がり、コンソールにも匹敵する表現が可能にはなりましたが、操作そのもはマウスのカーソルがタッチパネルに変わっただけで、まだまだweb向きのデバイスと言えると思います。そのためウェブで培ったUX設計と画面設計の知識がどうしても必要になってきます。

ものづくり

ゲームクリエイターはよりゲームらしいものを作りたがりますが、コンソールのように複雑な操作ができるコントローラがあるわけでもなく、スペックもリッチなゲームをやるにはまだまだ足りません。
SGにはSGなりの遊び方の提供を考察し続けていく必要があるでしょう。

3不自然なUX

ガチャスキームがゲームらしさを阻害する根本原因を作っているわけですが、それというのもガチャはブラウザゲームに特化した仕組みのためだからだとも言えます。
ブラウザに比べてより柔軟な表現が可能なアプリでは、アプリにフォーカスしたUX作りが必要になってくるのですが、ブラウザ時代の成功体験から脱却できずに同じ作り方を続けているアプリが非常に多いです。

ゲームサイクルが作れていない

ブラウザ時代の遊びの提供方法として、期間限定のクエストやイベントなどはよく目にしましたが、アプリはブラウザのように簡単に追加/削除が行えないため、予め機能を作っておく必要があり、限定的なはずが定常になってしまうというジレンマに陥っています。
イベントは毎週/毎月のように行われるのでその都度ルールやUIを変更する必要に迫られ、どんどんゲームが壊れていきます。
サービスとして非常に不安定です。

ゲームサイクル

やってくれたらいいな、とかやりたい人がやればいい はサイクルではなくただの運用計画でしかありません。そういった機能は単純作業になってしまう場合が多く、使う人しか使わないので、最終的に無駄機能として負の遺産が残る危険性を孕んでいます。
ゲームサイクルとはユーザーがそれをしなければ先に進めない状況が連続し、なおかつ元いた場所に戻ってこれる状況を作り出すことです。

良いもの作ろうぜ!だけでもなんとかなると思うの

我々が作っているのはアプリであり、ゲームとは異質な物であると自分は認識しています。
アプリにはアプリ特有の遊び方や手軽さなどいいところもたくさんあるので、 ゲームクリエイターとしてのプライドが邪魔をして、今後広がるかもしれない新しい可能性までも 見失ってしまっていては、良いモノづくりは出来ないのではないでしょうか。

拍手[1回]

PR
[不定期連載] 不憫なSGデザイナー開発記 コメント(0)
       

不思議とこの仕事を始めてからというもの、嬉しい(?)ことに新規タイトルの開発に携わることが多く、
幾つかの大型タイトルのリリースも見届けてきました。

しかし、新規開発に慣れているメンバーが不足していることもあり、無駄な作業の繰り返しや開発の遅延が頻発することは日常茶飯事です。

そこで今回は、プロジェクトを効率よく、かつ安全に運営していくための原則をご紹介します。

1何を作るか決める

なにを当たり前なことをいっているんだ? と思われるかもしれませんが、 実はこれが出来ていないプロジェクトは非常に多いです。 何を作りたいのかが企画の段階で曖昧なために、開発を進めると次々と問題が発覚して、 開発が頓挫したり、遅延したりするのです。

作りたいものは何ですか?

例えば、家を建てようと思ったときに『どんな家にしようか』 というのは誰でも考えることだと思います。 伝統的な日本家屋や西洋の古城のようなレンガ造りなど、 特にこだわりたいひとは、どんな家にしたいかの 具体的なイメージまで思い描くことでしょう。

モノづくりの現場において この”最終的な完成系のイメージ”というのはとても重要で、 ゴールが見えているかいないかで プロジェクトの成功が大きく左右されます。

設計図イメージ

まずはゴールを決めよう!

まだ1項目目なのにもうゴール?と思われるかもしれませんが、実はこれが一番重要なんです。

ゴールの見えないマラソンなんて走りたくない!

目的地を決めずに船出すれば遭難します。設計図がなければ家は建ちません。ゴールが見えず、いつまで走り続ければいいのかわからない状態で全力疾走なんてしていたら、すぐにスタミナが切れて倒れてしまいます。
最終的に出来上がる完成予想図を明確にしておくことで、全員が目指すべき目標を見失わずにすむので、プロジェクトはスムーズに進みます。
到達目標を決めるだけで開発メンバーは不安を抱かなくなり、モチベーションの維持にも繋がるのです。
開発が長引きそうならチェックポイントを設けましょう。「つぎはここまで!」という中間ゴールが見えているだけで心理的なストレスは軽減されます。

無限マラソン

いきなり作り始めないで、まずはゴールを決めましょう。

拍手[0回]

[不定期連載] 不憫なSGデザイナー開発記 コメント(0)
       

2コンセプトを決める

どんなゲームを作るか? が決まれば、自然とゲームシステムや世界観などが見えてきます。
剣と魔法のRPGやSFシューティングなど、より具体性を持ったイメージを作ることは、
プロジェクトを効率よく進めるためのガイドラインになります。
開発中に迷ったり、立ち止まることがあっても、
予め定めたルールに則って軌道修正すればゴールには必ず辿り着けるのです。

コンセプト

コンセプトはすべての原点

→ゲームの世界観やキャラクターデザインなど、グラフィック(見た目)の指針になる

ファンタジー作品ひとつとっても ダークなものやコミカルな冒険譚など、テーマによって世界観やデザインは大きく変わります。
コンセプトでテーマを定義することでデザインやストーリーが作りやすくなります。

戦士

→ゲームシステムやレベルデザインなど仕様全般を決定する際の指針になる

コンセプトに沿って作られたゲームシステムは、一貫したUXをユーザーに提供し、ゲーム全体の構造をイメージしやすくしてくれます。
不自然な機能の付加などが起こりにくくなります。


→ターゲットユーザーやシナリオを想定したゲームデザインの指針になる

誰に向けて作るサービスなのか? はコンセプトが明確に定義できるものなので、
ユーザーシナリオやイベントを作る上で分かりやすい基準となります。

ターゲット

→エンジニアリングにおける機構や構造化の意思決定に大きく関わる

どんな機能がゲームに必要で、どんな構造をしていれば、ゲーム進行上最適なのか? がコンセプトにより定義されるので、
必要な用件を満たせるデータ構造やプログラムの機構を考えるうえでの判断材料になる。


→開発中の疑問や想定外の問題に対処できる明確なルールになる

目指すべきゴールと従うべきレールがしっかり見えていれば、迷っても混乱することはなくなります。

やばい・・・

コンセプトとはゴールを見失わないためのレールです。一度決めたコンセプトは絶対に変えてはいけません!

アクションゲームを作っていたはずが、気づくとパズルゲームになっていた・・・なんてこともよくあります。。。
当初の設計プランが崩れるのも当然ですよね。作り直しです。そうならないようにコンセプトの掘り下げはしっかりと行っておきましょう。

standbyme

コンセプトが不十分で無理やり推し進めるとどうなるか?

  • コンセプトが曖昧なので 開発メンバーは何を作ればいいのか 解らなくなって、いずれプロジェクトが暗礁に乗り上げる。

  • 何をするゲームなのか解らないものが出来上がり、普通に面白くない。

  • 作って、壊してをひたすら繰り返すので、 永久に作り続ける負のスパイラルに陥る。開発期間が無尽蔵に伸びていく。

拍手[0回]

[不定期連載] 不憫なSGデザイナー開発記 コメント(0)
       

3仕様決定&UX設計

ソーシャルゲームの開発はコンソールに比べると非常に早いですが、アプリ開発に移行してからはだんだんと開発期間が延びてきているのが現状です。
原因としては、ブラウザゲームのように頻繁に更新ができないため、一つの完成品として作品を作りきらなければリリースできないことが挙げられると思います。
そのため開発を始める前に、できるだけ詳細な仕様とUIUX設計を用意しておくことが重要になってきます。

細部にこだわる前に全体設計

ゲーム開発の場合、メインの機能を中心にゲームサイクルを形作る個々の機能を考えていくような方法をとることは多いですが、
メイン機能ばかりに目が向いてそこだけをひたすら掘り下げてしまうと、全体設計のフェーズに入ったときに、うまく繋げられなかったり、思わぬ矛盾や問題に気付くなど非常に苦労します。
『とりあえずメインの機能だけ作ってみる』という方法は袋小路に迷い込む要因になりえるのでやめたほうが無難です。

チェック

料理するには材料とレシピが必要

作る料理が決まってもレシピが無いと材料調達すらできません。
レシピ【仕様書】を書くことで必要な素材【UIやSE】を厳選し、
調理工程【ワークフロー】を整理できるので、作業を始める前に必ずレシピは用意しましょう。

調理(開発)開始後のメニュー(仕様)の変更は作り直しか、中断を意味します。
変更内容があっさり決まれば続行できますが、多くの場合はその状況下で試行錯誤を始めてしまうので最悪の場合、中止に追い込まれます。

カレーレシピ

開発開始前にある程度 詳細な仕様とUIUX設計をしておくことで、大きな問題には気づけるので無駄なビルド&スクラップを省けます。
開発中に気づく問題点もありますが、クリティカルなバグは事前に潰しているので、遅延や中断が発生しにくくなります。

準備はいいか?いや、ちょっと待て!

開発が始まると、実はあれもこれもと後出しで機能追加が増えていくことがよくあります。
こうなると、初期の設計が狂ってしまう上に内部的な構造やゲームサイクルが繋がらなくなるなど、製品としてのクオリティが担保できなくなっていきます。
既に作ってしまった機能に対して改造を行ということは、コンセプトレベルから丸ごと見直す必要が出てくるため、場合によっては作り直し。最悪開発中止です。
やりたいことは始める前に全部だす!ことがとても重要です。

手の内

後の追加を想定して作っておくことが大事なのですが、いざ開発が始まると見積もりが甘くて想定以上のボリュームだった。という事態に陥ることがよくあります。
これは追加内容がゲームサイクルに深く関わるほど顕著に顕れます。
このあたりは経験則からくる感覚が大きいので判断が難しいのですが、思いついた時点でできるだけ詳細まで詰めておけば回避できます。

現状維持のための中途半端な改修で本来想定したUXをユーザーに提供できなければ開発自体が無意味です。
既存機能との整合性をとるためのトライ&エラーや他機能の圧迫などが発生すれば、開発延期や中止を招く要因になります。

全ての機能を網羅した上で、具体的な内容を考慮し、それらに耐えうる拡張性を持たせた設計にしておくのが最も賢い方法です。

積み木崩し

事前の準備をしっかりしておきましょう。無計画に走り出して迷子にならないように。

拍手[0回]

[不定期連載] 不憫なSGデザイナー開発記 コメント(0)
       

4プロトタイプの制作

さて、ここまで綿密な事前準備を色々としてきましたが、実際に物を作り始めてから気づく問題や改善点はやはり出てきます。そこでまずはプロトタイプを作ってみましょう。
特に新規開発の場合はあらかじめ見本を作っておくことで、作業の流れや問題点などを前もって確認しておくことができるので大切です。

いきなり製品版は無理

仕様の精度がよほど高くなければ、いきなり製品クオリティを目指すのは無理です。
ここまで行ってきた事前の準備はあくまで脳内イメージです。
具体的にものづくりをしていくと見落としていたことや、書類上では見えなかったことが出てくるのは仕方がありません。
この段階で細かい部分まで突き詰めて作ろうとすると試行錯誤が始まってしまうので大幅なタイムロスとなります。この段階では全体の流れを把握するだけの”モック”レベルで留めておきましょう。

モック制作

主要機能だけ作ってもダメ

とにかくまず主要な機能だけ作りたい!・・・のはわかりますが、何度も言うように危険です。やめましょう。
プロトタイプでいいものができていたのに、リリース版に向けて他の機能を盛り込んだら、プロトタイプのいいところが全て削られてしまった。といった事態を何度も経験しました。
プロト時点で考慮されていなかった機能を開発開始後に無理に入れようよした結果、既存機能と辻褄を合わせるためにすでに出来上がっていた"いいところを食いつぶしてしまう"ありがちな失敗パターンです。
一部分だけ掘り下げるのでなく、全体のバランスに常に気を配りましょう。

UXもきちんと設計しよう

プロト開発をエンジニアとプランナーだけで進めて、プロト終了後にデザイナーがアサインする。という流れがよくありますがこれも危険なフローです。
UXの専門家がプロトに関わっていないので、出来上がったプロトタイプにユーザビリティが全く考慮されていないのです。
後付け的にUXを付与しようとすると、内部構造や画面仕様が邪魔をして最適なUXが提供できなかったり、UIありきの操作でありながらUIを組み込む余地がなかったりするので、ユーザビリティ向上のめにせっかく作ったプロトを崩壊させてしまいかねません。
それでいいものに仕上がれば問題ないのですが、たいていの場合はゲームが壊れてしまうので意味がありません。

余地なし

開発の初期段階からきちんとUXの専門家を招いてユーザビリティを考慮しておけば無駄を省けます。

UX不在のプロト開発

最近はアプリも3Dが主流になってきましたね。
プロト開発時にP/Eに3Dアーティストを加えた3者体制での制作が増えてきました。しかしここにもUXデザイナーが不在。
3Dの場合、カメラのアングルやズーム率、ライティングの都合など、ちょっとした修正でも大きな工数がかかるので、アーティストだけで画面構成を決めてしまうのは危険です。
また、3DオブジェクトにUIの機能を持たせるといった工夫も可能になるので、UXの専門家を交えて3Dビューの仕様を策定していくのが安全なワークフローになるでしょう。

3D

最後に必ず出来上がったものをチェックしましょう。作って満足。とはならないように。
思い描いていたイメージに近いものができそうか?必要な機能は揃っているか?ゲームサイクルが正しく繋がっているか?回りそうか?サービスとしてきちんと完成できそうか?などなど。
この時点で上手くいかなかったり、つまらなかったら、それは企画がよくない証拠です。
モックでつまらないものはどんなに精度をあげてもつまらないです。

拍手[0回]

[不定期連載] 不憫なSGデザイナー開発記 コメント(0)
<<前ページ ホーム 次ページ>>