ゲームを本格的に開発する前に考えてみたいこと
- 個人的にこんな開発してみたいなぁ、ということを最近考えたのでメモ
- コンテキストとしては「中期的な運用を見据えたスマホゲームを開発するプロジェクト」
- コンシューマ/カジュアルゲー等には適応出来ない箇所や不向きな内容もありそう
前提条件
- プロダクトを立ち上げるにおいて絶対に変更出来ない条件を考慮/明示する
- 例えば、納期/予算/人/技術要因 ... etc
コアバリュー
コアバリューとは
- コアバリューはそのプロダクトにおける中心価値
コアバリューの一例
www.slideshare.net
- 「消滅都市」が持つコアバリューは「人の感情を動かすために手段を選ばない」みたいなことを外部勉強会で聞いた記憶がある
- どういう手段で達成されているかは以下のスライドから垣間見れる
- それぞれのイベントに対する入れ込み具合、バグのような演出... etc
コアバリューを定義する事のメリット
- PMはコアバリューの達成に際しタスクの優先度を適切に設定出来る
- PMはメンバーに対してプロダクトの生み出す価値を共有出来る
- メンバーがプロダクトに対して思い描くものが異なると開発時に混乱を招く可能性がある
- アクティブなメンバーはコアバリューを満たすために主体的にアイデアを出す
- コアバリューはプロダクトの持つ武器となり、他のアプリとの差別化が図れる
目標とゲームサイクル/ビジネスモデル
目標
- ゲームにユーザが没入し継続するための動悸を提供する
- 目標がクリアになっていないとユーザは早期に飽きる (作業感)
- 直近目標/中間目標/長期目標を用意する
- [直近目標] ゲームのメインとなる動作
- [中間目標] 直近目標を飽きさせず長期目標まで継続させるための目標
- [長期目標]プレイヤーに最終的に達成させたいゴール
ゲームサイクル
- 目標に関しては達成するためのボトルネックとなりえる部分を明示する
- 各目標/ボトルネック/解決手段を可視化して紐付けたのが「ゲームサイクル」
- この時点でイベントの位置づけ等、長期的な運用プランも考慮出来ると良さそう
ビジネスモデル
- 目標達成におけるボトルネックを解消する手段としてビジネスモデル (課金ポイント) を設定
- ユーザは目標達成のために納得感を持ってお金を払う事が出来る
ペルソナ
ペルソナとは
blog.kairosmarketing.net tech.pepabo.com
- 製品やサービスの理想の顧客の人物像のこと
- ペルソナを定めるとユーザ視点での意思決定がしやすくなる
ペルソナについて思うこと
- チームメンバーもしくは身近に居る人(例えば社内にいる人)を設定したい
- 後述のテストプレイにおいて有力なデータが取れる存在
- 意思決定に迷ったらその人に聞けば良い
プロダクトレビュー
- 自分が考えたものについて、良い物が出来たと思い込みがち
- これまでの決定事項について論理破綻や抜けが無いか見てもらう機会
スクラップアンドビルド/テストプレイ
- ゲームにおける「楽しさ」を見つける難しさ
- 面白いと思ったゲームも実際に作ると面白くない
- アイデアの7割は蜃気楼
- 後戻りと再出発を許容する必要がある
- 開発終盤で「なんか違うな」となっても取り返しがつかない
- 「これだけ時間をかけて頑張ったんだから失敗しても仕方ない」を防ぐ
- 再出発のダメージを減らすために意識すること
- YAGNI原則 : https://ja.wikipedia.org/wiki/YAGNI
- KISS原則 : https://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87
- コアバリューに基づくゲームサイクルに最低限必要な機能実装のみを行う
- テストプレイ
- ペルソナを中心にFBを貰う
- そして高速でスクラップアンドビルド(作り直し)
スモールスタート
- 少人数(〜5人)でのスタートが理想
- 人数が多い場合にはコミュニケーション/意見が拡散しがちで収束に難
- スクラップアンドビルドを許容する場合、角度が低い内はコストをなるべく小さく収める
- これは行ける!と思ってから規模を拡大しても遅くない
【Unity道場05】モダンなUIの提案と実装 に参加しました
概要
- 資料が公開されるかもという話なので私的メモレベル
- 10minくらい遅れて行ったので漏れがあるかも
- 講演者は @ivoryfunc さんと @tsubaki_t1 さん
追記: 資料公開されました!
昨今のUI界隈で起きていること
- 進んで行く専門性
- スキューモグラフィック/自己回帰性/身体性/透明性
- それに対してUnity
- uGUIの正式なリリース、武器はある
環境が変われば読みやすいフォントも変わる
- ディスプレイフォントの主流変化
- 72dpi: ビットマップフォント
- 96-250dpi アンチエイリアスは一般化したもの
- 300dpi やっぱり一般な紙面で読みやすいフォントが良いよね
そもそもUIって何?
- あっちの世界とこっちの世界をつなぐものと表現
- PCを使用するのであれば、IFの存在は不可欠
- コンピュータと人間という異質なもの同士をつなぐもの
- 大まかに2種類存在する
- ヒューマンインターフェイス
- ハードウェアを指す事が多くソフトウェアでは手出し出来ない
- ユーザーインターフェース
- ヒューマンインターフェイス
誰のためのデザイン?
http://www.amazon.co.jp/%E8%AA%B0%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3-%E2%80%95%E8%AA%8D%E7%9F%A5%E7%A7%91%E5%AD%A6%E8%80%85%E3%81%AE%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E5%8E%9F%E8%AB%96-%E6%96%B0%E6%9B%9C%E7%A4%BE%E8%AA%8D%E7%9F%A5%E7%A7%91%E5%AD%A6%E9%81%B8%E6%9B%B8-%E3%83%89%E3%83%8A%E3%83%AB%E3%83%89%E3%83%BB-%E3%83%8E%E3%83%BC%E3%83%9E%E3%83%B3/dp/478850362Xwww.amazon.co.jp
- 道具がうまく使えなかったら、それは道具のデザインが悪いせい
- デザインはそもそも「問題を解決する」という意味
- 問題が解決されていない時点で道具が悪い
理想的なインターフェイス
- ヒューマンインターフェイスとユーザインターフェイスが一致している
正しくアフォーダンスが設定されている
画面上のキューブを自由に操作するための最も適切なインターフェイスはなんだろう?
- 手を突っ込んで直接動かす
- 抽象化を挟む
- スワイプで回転/日本指で移動
- 指先のメタファーであるカーソルをマウスで遠隔調査
抽象化を挟む毎に、ユーザインターフェイスとヒューマンインターフェイスにギャップが生じる
- 理解してもらうための仕組みが必要になる
- 習熟に時間が掛かる様になる
République
- OMNIビューのUI
- 初期段階: ダメだった
- タップ可能領域がユーザに伝わらない、ボタンだと気付かれない
- きわめてシンプルな物に変更
- 初期段階: ダメだった
タッチデバイスに対する理解
理解度の低下を補うヒント
メタファー
- 物理的なボタンを模した形にする
- 新しいインターフェース環境の誕生時に有効なアプローチ
- そもそもPC自体はメタファーの山のような存在
- カーソル/デスクトップ/フォルダ/ゴミ箱…
-
- アイコンを行間文字として使えば、プレイヤーは概ねボタンと見なしてくれる
上記の手段が使えないケース
- タップした場所によって行動が変化する
- 隠れる/立ち止まる/攻撃/ドアに入る….
- 事前に伝えるのが難しい
- タップ後にアイコンを出して行動をユーザに知らせた
- 事前に知らせる事をあきらめ、事後に伝える様に変更した
脱メタファーの話
iMacいまむかし
- だんだんシンプルになってる、スッキリした印象
OSのUIはどうあるべき?
- 見た目の印象をハードウェアに合わせるべき?
- あるいはデバイスを意識せず存在すべき?
スクリーンをプロダクトの延長の実平面か、仮想的な空間をのぞく窓と捉えるか
- iOS6の頃
- OSは素材感、質感、光といったフェイクに満ちている
- ハードウェアは無駄を省いてシンプルになっていった
- ここに乖離が生じている
- ユーザインターフェイスとヒューマンインターフェイスの乖離
- 理想的に近しい方が望ましい
UIをプロダクトの延長に存在し得るための試み
とりあえず見た目を合わせてみる
- ミニマルなデザインならルックアンドフィールの無駄を省く
動きを変える
結果どうなったか
フラット以降を学ぶテキスト
様々なものの意味合いが変わった
- 影の深さによって、後ろのオブジェクトとの無関係性を伝える
- スキューモグラフィックとの相性の悪さ
- 動きには意味がある
- すいこまれることで画面が開く / ジニーエフェクト
- 閉じてもアプリが終了しないので、吸い込まれる事でまだ生存している事を伝える
- 搭乗時に動く事でスワイプ出来る事を伝える
- すいこまれることで画面が開く / ジニーエフェクト
フラットデザインに移行した理由
- 成熟度による要因
- ユーザはPCのデスクトップ等に慣れた
- メタファーの限界
- 現実世界に似たような物が無いが溢れる様になった
- メタファーの弊害が顕著になった
- ユーザに類推や先入観を与えてしまうことで損させるケース
ゲームのUIはどうなんだ
- 世界観を模したアートスタイルを作るという考えが主流
- アイコン等のインフォグラフィックは統一化しようという動きが強い
- 他のアプリやOSのネイティブなUIを意識すべき?
Unityで制作したサンプルプロジェクト
- 以下のゲームUIの実装方法/使用アセットの紹介
追記: 上記プロダクトのGitHubが公開されました
サンプルで使用したアセット
- DOTween
- iTweenはレガシーなものになりつつある
- 置き換わるような位置づけ
- C#の拡張メソッドを使用
- Typeface Animator
- テキストを動かすためのアセット
- Image Deformer
- Spriteをいい感じに歪ませるアセット
第5回サウンドゲームジャム/LudumDare#35成果物「RhythmicalCreation」
2週間前ですがサウンドゲームジャムに参加してきました!
第5回サウンドゲームジャム
- 2016年4月16,17日に開催のサウンドに特化したゲームジャム
- 今回で5回目の開催
- 一昨年(第3回)のときに初参加して2回目
- 当時は音の波形でステージ生成する横スクロールアクションを作った
- 他のチーム/メンバーの成果物に関しては動画としてアップされている
LudumDare#35
http://ludumdare.com/compo/ludumdare.com
- ルーダムデア、と読む(らしい)
- 年に3回実施されていて、今回で35回目の開催
- 世界中の人が参加するオンラインゲーム開発イベント
- 以下の二つのルールがある
- テーマがユーザの投票によって決められる
- 今回のテーマは「Shapeshift」
- 以前から存在は知っていて興味はあったので初参加
成果物「RhythmicalCreation」
- LudumDare: http://ludumdare.com/compo/ludum-dare-35/?action=preview&uid=84331
- Play(PC/ブラウザ): https://lycoris102.site44.com/unity/rhythmical_creation/index.html
- Source: https://github.com/lycoris102/RhythmicalCreation
使用アセット
企画/仕様
- 今回考えたことをつらつら書いて行きます
音ゲー + Shapeshift
- サウンドゲームジャム参加前に師弟系の音ゲーを作ろうと考えていた
- 今回のLudumDareのテーマが「Shapshit」
- 現状メッシュの変形周りとかのアプローチに疎いので置き換え系
- 何の変哲も無い■が色とりどりの物質に変形して行くの楽しそう
建物モチーフ
- プレイヤーに「意味のある行動」をしていると思わせる
- 神が万物の原型となる物質となる■を置いて行く
- あなたはその動きを模倣して■に意味を与える
- 無駄に壮大に
- スペースキーを押すという小さな体験で大きな事を成すことによる快感
- レパートリーの作りやすさ
- 家、ビル、タワー....
とにかくシンプルに
- LudumDare = (プレイヤーからすると) 一期一会の感覚
- 難しいゲームはよっぽど引きが無い限り直ぐに離脱される印象
- 複数のキーによる操作を排除
- そもそも実装時間が限られている
- サウンドゲームジャムの作業時間は概ね20時間程度
実装
MusicEngine
- @geekdrums さんによる音楽同期スクリプトを使用
- 何小節目の何泊目かという情報にアクセス出来たり
- 小節や拍が切り替わったタイミングを取得することが出来たり
- 以下の用途で使用
- 音に合わせてオブジェクトの大きさを変形する
- 音に合わせてカーソルが動く
- 音に合わせて建物が飛び出てくる
- スペースキーを押した時にどの建物が該当するか判定する
ステージ生成
- Start時に32個のGameObjectを作成しておき、非アクティブにしておく
- CSVを読み込み二次元配列に格納しておく
- タイミングに合わせた出現
- 曲再生中
Music.IsNearChanged()
を使用してUnitが切り替わる直前に出現させる - https://github.com/lycoris102/RhythmicalCreation/blob/master/Assets/Scripts/StageCreator.cs#L40
- 出現処理は
SetActive(true)
/ ■のサイズ変更 / 生える演出 / カメラシェイクによって構成 - https://github.com/lycoris102/RhythmicalCreation/blob/master/Assets/Scripts/StageCreator.cs#L73-L116
- 曲再生中
判定処理
- スペースボタンを押した地点にActiveなGameObjectがあれば当たり判定
- Justの地点にObjectが存在しなければNearで判定するようにしている
- XXX 最初のノーツに関してはNear判定取れてないので厳しめ....
- https://github.com/lycoris102/RhythmicalCreation/blob/master/Assets/Scripts/Player.cs#L17-L34
- https://github.com/lycoris102/RhythmicalCreation/blob/master/Assets/Scripts/StageCreator.cs#L146-L154
当たり判定
- 縦に延ばしたSpriteを戻す/建物生やす/建物Sprite変更/パーティクル発生
次のループへ
- スコアの加算/建物を非アクティブに
音楽
- とにかく思いつかなかった...
- 深夜3時くらいまでフレーズ考えてたけど結局ボツにして翌朝作り直した
- 展開(レベルデザイン)だけ意識して後は割と自分の好きなよう作った
- 前半はとにかく緩やか
- 徐々に音数増やして行く
- ブレイクタイム設ける (裏打ち地点)
- 後半でスパート掛ける
感想/反省
実装
- 1つのクラスがデカい = 適切な名前空間に分割出来ていない
- 最初のノーツの判定が厳しい = Near判定が最初のノーツだけ効いていない
- 全体的に判定が厳しい
- 判定の取り方をUnitで判定するのではなく時間で判定すると良さそう
- 特にBPMを早くするに従って、判定の幅が狭くなるので固定秒で
- 各ノーツの前後何秒に含まれているからそのノーツを消すといったような
- LudumDareのコメントで判定周りの指摘はたくさん頂いているのでもう少し制度上げる工夫をすれば良かった
- 今思うと少しシンプル過ぎた気がする
- 演奏感が足りない
- 複数(2-3)のキーを使用しても良かった気がする
- 演出的には空に浮いているオブジェクトを作ったりしたら良さそう
サウンドゲームジャムについて
- Unityや音に関して強い豪華なメンバーが集まった印象
- 多分分からない事あったら誰かに聞けば直ぐにレスポンス来ると思う
- 学生さんもとても尖っていて才能を感じた
- そんな人たちに自分のゲームを見てもらう/プレイしてもらう幸せ
- 「これいいね!」って言って貰えて地面に頭をめり込ませたい気分だった
- そういえば久しぶりのジャム1人参加だった
- コミュニケーションによる摩擦無く自分の作りたい世界を作れた感覚
- ただし時間とクオリティを犠牲にして成り立っているのを改めて実感
- 専門職集まった方がよりクオリティの高いものが作れただろう
- とても楽しかったので、機会があればまたお邪魔させてください...!!
LudumDareについて
- 初参加、英語分からず、ドキドキ
- ゲームアップのフロー等余力あればどこかでまとめたい気分
- 多くの人に遊んでもらえる/コメント貰える幸せ
- 海外の方はリアクションがオーバーかつポジティブ
- Amazing music and graphics. とか言われたら泣いちゃう
- (他のゲーム見てもわりとそういうリアクション付いてるが多い)
- 互いに評価し合う仕組みなので、コメントから自分のゲーム見てね!って意図はあるかも
- こんなに楽しいイベント、もっと早く参加すれば良かったなぁ、という感じ
次回
- 暫くは外務のゲームジャムに出る予定は無いです
- SPAJAMの予選の様子やUnityのTIPS、勉強会の様子辺りのブログは記載するかも