レポート一覧

講演ファイル

アジェンダ

会社紹介
開発スタイルと特徴
開発環境の構築プロセス
STFramework紹介
今後の課題

開発スタイルと特徴

スマートフォン/タブレットに特化
Android/iOSのマルチプラットフォーム対応
コンシューマー向けの3D技術を使用可能
全世界のユーザーへ、スピーディーにクオリティの高い3Dゲームを提供できる

コミュニケーション駆動開発

いつでもどこでも話して解決
会議のようなフォーマットはすべて撤廃
問題点、疑問点をその時その場で即解決する
話した内容についてはすぐにメモして共有
常に思考がクリアな状態を作ることで各タスクの効率化へつながる

全員がフラットな立場で話し合う

アイディアの良しあしと立場や経験は無関係
一人一人が主体性を持ったものづくり
メンバー全員が自分の頭で考えることでクオリティアップにつながる

少数精鋭のスピード重視

各プロジェクトに3名のメンバーをアサイン
- PG1
- 3Dアーティスト1
- 2Dアーティスト1
コアメンバーを少数に絞ることで意思決定の速度と柔軟性が向上
プロジェクトの規模や開発フェーズに応じて柔軟に対応
量産が必要なタイミングで人員追加
コアメンバーが少数でも安定したクオリティとボリュームを担保

最小限のルールで柔軟に変化

特にスマートフォン市場の成長は早い
時代の流れや環境の変化に合わせたその時その時の最良を追求

開発環境の構築プロセス

サマータイムスタジオに入る直前のこと
- スマートフォン向けに3Dのゲームを開発しようと試みた
- Android SDKとEclipseでゲーム開発
- これは1人では無理だと気づいた
- そんなときに思い出したのがUnity
Unityの存在は以前から知っていた
- あっという間にプロトタイプが完成した
今までは自分で作ることが多かった
- そもそもゲームに限らず動くものを作るのは楽しんでやれる
- 自分で作れば自由に最適化できる
- 過去から作ってきたものの蓄積で意外と何とかなってしまう
- 一人になって新しい環境で挑戦して今までの固定概念を捨てることができた
まずはUnityを素直に使ってみる
- そもそもUnityが立派な開発環境
実感したUnityの弱み 3.x当時
- LoadLevelで画面が止まってしまう
- 特定の端末で不具合が出やすい
- それを補うUnityの強みとして、プラグインなどのアセットの充実

自分たちの開発スタイルに合わせるために

スマートフォン/タブレット向けの効率化
- Unityの中で起きている問題は対応不可
マルチプラットフォーム対応の効率化
- アプリ内課金の実装
- アチーブメント、リーダーボードの実装
- モバイル向け広告の実装
タイトル固有部分以外の効率化と安定化
- ゲームのメインロジック以外は大体同じ
- 特にメニュー周りは共通化しやすい
- 端末の解像度、アスペクト比への対応
- メニューとしての動作制御
- ローカライズ対応
このあたりの機能をどのプロジェクトでも簡単に導入できて、
アップデートも反映できるものを用意することにしました
- STFrameworkの誕生

STFramework紹介

初期化方法
- STFramework.Initialize()を呼び出すだけ
- 配置しておくのはUI用のカメラだけ
  - これだけは出しておかないと、エディタ上でレイアウトの確認ができないため
- とにかく簡単に使えるようにしたかった
Input Manager
- Input.GetTouch()を使うとエディタ上で動かない
  - UnityRemoteは不安定かつ準備が必要(当時の話)
- エディタ上でも気軽に動作確認したかった
- マウス入力をタップと同じフォーマットにして返すだけ
  （残念ながらマルチタップはUnityRemote必須）
Scene Manager
- Scene切り替えをスムーズにしたい
  - LoadLevelで一定時間画面が止まってしまう
  - 大量のInstantiateは時間がかかる
  - スマートフォン上で動かすととくに顕著に感じる
- UnityのSceneはマップ構築用に特化
  - LightMapやNavMeshを使いたいため
  - Sceneに含めるオブジェクトを最小限にする
- ゲームシーンの遷移や管理を自動化
  - 初期化、破棄処理をコルーチンで実装
  - シーンの遷移状態でのコールバック処理
  - Sceneごとにクラス定義が若干手間だが、
    オブジェクトの初期化順序も簡単に制御できる
UI Manager & UI Components
- 多彩な解像度とアスペクト比に対して各UIを自動調整
- 親となるMenuコンポーネントで子になる各UIコンポーネントをハンドリング
- 広告表示、非表示のレイアウト自動調整機能
Purchase Manager
- 課金用のインターフェイスを共通化
  - Android/iOSをタイトル側で意識しないで作る
- どのタイトルでも課金処理のフローは一緒
  - タイトルごとに入り口が違うくらい
- リクエストと結果だけを処理できればOK
XML Importer
- データ構造を定義したXMLをアサインし
  ワンボタンで自身のメンバーに対応させて読み込む
  - 最初はデータテーブルをパブリックメンバとして直接編集
  - 配列のデータ位置の入れ替えや修正がかなり面倒
- Excelなど、データ全体を把握しやすい状態で編集したい
  - ExcelからXMLを出力して読み込むことで解決
- Unity4.x時代に拡張
  - ScriptableObjectに対応し、余計なコンポーネントの作成を不要に
  - 一定の規則に従いクラスとXMLを作成することで
    XMLのインポートとデータの更新を自動化
  - XMLをアサインする手間やビルド時に外す手間を削減
    - XML更新後の反映忘れなどがなくなった
その他の機能
- ゲーム内時間管理（秒、フレーム秒とtimeScale依存、非依存）
- サウンド管理
- シングルトンコンポーネント
- 状態マシン（FSM）
- オブジェクトプール（リソースプール）
- ゲーム内文字列管理
- セーブデータ管理
- ゲームサービス管理
  - アチーブメント、リーダーボード、フレンドアクセス
- デバッグ機能
  - 汎用デバッグメニュー管理、ログ管理

【Unity】Unite 2015「Unityを利用したスマートフォン向けゲームアプリ開発へのアプローチ方法」レポート

レポート一覧

講演ファイル

アジェンダ

開発スタイルと特徴

コミュニケーション駆動開発

全員がフラットな立場で話し合う

少数精鋭のスピード重視

最小限のルールで柔軟に変化

開発環境の構築プロセス

自分たちの開発スタイルに合わせるために

STFramework紹介