Skip to main content

2章:ソーシャルゲーム向けのUnityクライアント作成

Unityクライアントを作る時も、普通のゲーム同様気を付けることと、ソーシャルゲーム特有の気を付けることがあります。

特に後者を気にして書いていますが、既に知っている場合は読み飛ばして大丈夫です。

チュートリアルを作ろう​

一言で言うとどんなもの？

ユーザが操作説明を覚えるための専用シーン。かっこいいオープニングムービーを流したりもします。

と言うのが本来の流れですが、 最近はAppStore審査で、ゲーム開始後すぐにアセットバンドルなどのデータダウンロードさせるゲームはリジェクトされます。

なので、チュートリアルだけシーンを分けて、アセットバンドルダウンロード無しでチュートリアルまでは遊べるように考慮しておく事が必須です。

これの理解や実装が不完全だと何が起きるの？

  • 開発終盤に地獄を見ます
  • ユーザの初期離脱率がすごいことになります

詳しく知りたい人は、この辺の単語でググってほしい

  • 情報求む
  • 毎回死にそうになってます

インゲームを作ろう​

例えばリズムゲームならリズムゲームを遊ぶ部分、パズルゲームならパズルをする部分、などのインゲームを作る場合も、様々なコツがあります。

少し古い記事ですがこちらを参照しておくと（あなたがアウトゲーム担当であったとしても）得るものがあると思います。

スマホ向けゲームアプリにおける基本的なBattle(インゲーム)設計 https://qiita.com/JGS_Developer/items/34b27cc0a6ceff85bb84

アウトゲームを作ろう​

一言で言うとどんなもの？

インゲーム以外の部分を指します。ショップ、マイページ、プロフィール、クエスト、ガチャ、合成、etc…

つまり、ソーシャルゲームはメチャクチャにアウトゲーム領域が広いです。 その部分は ゲームの世界観に合わせつつ、山ほどある画面UIを量産 する必要があります。

これの理解や実装が不完全だと何が起きるの？

  • 画面量産でプレハブコンフリクトして死ぬ
  • タップ連打でバグる
  • 連続画面遷移でバグる

詳しく知りたい人は、この辺の単語でググってほしい

  • 情報求む

楽しい多解像度、多アスペクト、ノッチ対応​

一昔前は、世界がほとんど16:9のアスペクト比に統一されたかに見えました、幸せな時代でした…iPadも背景を一色置いて中身が16:9のままでも審査が通ったりしました。

最近は各社工夫を凝らしたノッチや、面白いアスペクト比の縦長端末 があります。iPad対応も割とちゃんと必要です。メチャクチャつらい… 最新のUnityであればDeviceSimulatorなどで見た目を確認できますが、Unityバージョンによってはノッチ対応用ライブラリや、アスペクト対応ライブラリを使って（あるいは作って）いきましょう。

Unity DeviceSimulator(2019.3~) https://docs.unity3d.com/Packages/com.unity.device-simulator@latest/

デザイナーさんが親切であればアスペクト比やノッチの時はどういうレイアウトを想定しているか、の資料があるのでアスペクト比を切り替えたときの見た目を合わせれば大丈夫です。 そうでない場合は、頑張って良い感じに見えるようにしましょう。

アウトゲームは良い感じにシミュレーションして確認できますが、インゲームの面白さや有利不利がアスペクト比によって変わるようだと、一気に考えることが増えてきます。
この文書ではインゲームについては触れませんが、メチャクチャ難しい要素があるので大変そうです。

多言語対応をしよう​

Unity標準でlocalizationライブラリがUPM経由で提供されようとしています。 Google SpreadSheetからのインポートも出来そうなので、今後はこれを使うプロジェクトも出てくるかも知れません。 https://docs.unity3d.com/Packages/com.unity.localization@latest/

UIライブラリの変遷​

UnityはメジャーなUIライブラリが数年単位で切り替わってきています。なので参加したプロジェクトで何のUIライブラリを使っているかを確認して、同じライブラリを使いましょう。UIライブラリの混在はダメ絶対！！！

NGUI期​

Unity4.x系から続いているプロジェクトとかは大体これ。Unity標準のUIシステムが不評で、サードパーティー製アセットのNGUIが事実上標準でした。この作者は一体幾ら売り上げたんでしょうね… さすがに今から新規で開発するプロジェクトではあまり採用されないかもしれませんが、CPU負荷が軽かったりして今も愛用している人やチームが居ます。

uGUI期​

Unity4.6以降で標準UIとして提供されたuGUIです。おそらく、この文書を読んでいる皆さんのほとんどはuGUIを使っているのでは無いでしょうか。 ボタンのロングタップやダブルタップを受け付けるためのInputModule拡張をする場合もありますが、基本的にuGUIは技術書も日本語で出ているので、キャッチアップしやすいと思います。 プレハブコンフリクトを避けるために各パーツは小分けにしてResources.LoadしたりGameObject.Instantiate()して親子関係をスクリプトで付ける。みたいなコードがあちこちに散らばっていたらこれです。

後期uGUI期​

Unity2018.3以降はNestedPrefabという仕組みが出来ました。後期uGUIはuGUI期+NestedPrefabです。 uGUIを使ったアウトゲームGUIでも、NestedPrefabを正しく採用することでスクリプトの記述量を減らしつつ、プレハブコンフリクトも減らせたりします。

開発しているUnityバージョンにもよりますが、今から新規開発をするなら後期uGUIを採用していることが多い予感です。

UI Toolkit(旧名称:UI Elements)期​

期待の新GUIシステムです。僕の周りではまだあまり採用例が無いのですが、1年後のリリースを見据えてるプロジェクトなどでは、使われているかも知れません。 特徴としてはEditorGUIも同じ書き方が出来ること、jQueryみたいなセレクタとcssみたいな修飾が出来ることです。

非同期通信がある場合のUI考え事​

一言で言うとどんなもの？

スタンドアロンゲームと異なり、サーバ通信の結果が返ってくる時間は保証できません。 なので通信結果が連続でまとめて返ってくる場合や、10秒以上返ってこない場合に、ゲームが壊れないようにUI側で配慮する必要があります。

これの理解や実装が不完全だと何が起きるの？

  • ダイアログが多重になる時に死ぬ
  • 画面遷移後に前の画面の通信結果が返ってきて死ぬ
  • バトル中に前の画面の通信結果が返ってきて死ぬ

詳しく知りたい人は、この辺の単語でググってほしい

  • 情報求む

ダイアログシステム​

誤タップ防止とUIアニメーション​

環境分けを作ろう​

デバッグログを確認したり、SRDebuggerなどを使える開発者モードと、ストアに公開するモード、というクライアントアプリ挙動を示すパラメータを内部で持っておきます。

#if DEBUG

みたいなifdefを切っておく、あるいはasmdef単位で切り分けておいて、ストア公開するバージョンではデバッグ機能がコンパイルされないようにしておきましょう。

また、通信相手のAPIサーバも開発環境APIサーバ、ステージング環境APIサーバ、製品環境APIサーバ、と3個くらい(あるいはそれ以上)のサーバURLがあったりするので、環境変数的な仕組みを用意しておいて切り替えられるようにしておきましょう。

つまり、クライアントの動作にはこれだけのバリエーションが考えられます。

　クライアントデバッグビルドクライアントリリースビルド
APIサーバ(DEV)よく使うアクセス出来ないのが正しい
APIサーバ(STG)めっちゃよく使うQA時、ストア審査時だけ使う
APIサーバ(PROD)互換性チェックに使うユーザが遊ぶのはここ

tips:このDEV, STG, PRODという環境の分け方はよく使われていますが、現場によって名付けルールが大きく異なることがあるので注意が必要です。例えば開発環境のDEVでもdevelop1, develop2...というような名付けの場合や、機能や施策ごとに開発環境を切り分けている現場ではfeature1, feature2...というような名付けがされていることがあります。
特に新しい現場やチームでは確認をした方が良いでしょう。

またステージング環境でも現場によっては意図が異なり、STGはQA(quality assurance)用環境のことを指す場合もあれば、PRODと同じバージョンがデプロイされているCS対応用環境の場合などもあります。
また、後述するApp Storeの審査の関係上ステージング環境という分類でありながら、次回リリース用のAPIサーバがデプロイされており、審査スタッフが問題なく審査を行うため、開発やQAのメンバーが触らない特別な環境が用意されていることがあります。この環境の呼び方もまた様々ですが、Review環境やJudge環境と呼ばれたりします。(　審査提出バイナリの罠と対策 を確認してください)

tips:更に、クライアントエンジニアの手元PCでAPIサーバのシミュレーションが出来るように整備されている事もあります。チームに参加したら「Dockerを使ったローカルAPIサーバもありますか？」と聞いてみましょう。これがあるとSTG相当のサーバ動作チェックを手元で行ったり、開発中にバグったと思ったときにサーバ側にログを仕込んでクライアント、サーバどちらに問題が起きているか切り分けたり、ということが出来ます。便利です！（その代わり、PHPとかDockerとかを覚える必要が出てきます。頑張って覚えましょう！）

DEV,STG,PROD​

ソーシャルゲームが初めてで、この3単語を初めて目にした方も居るかも知れません。

  • DEV…開発環境、バグがあるかもしれないし、壊れているかも知れない。最新のコードが含まれています。
  • STG…ステージング環境、次にリリースするバージョンが動いています。ここでテストやQAをして、問題なければPRODにリリースされます。
  • PROD…製品環境、ユーザが実際に遊んでいる環境です。ここでうっかり変な操作やバグを仕込むとメチャクチャ怒られるのでSTGでいっぱいチェックしましょう。

InHouseBuildとDeploygate​

QAの人や社内テスターの人に遊んで貰うために、専用のアプリ配布システムを社内に用意しておきましょう。もし社内に整備されていなければ、あなたが整備しましょう。 精神の衛生に大幅に好影響があります。チームのCI環境も、もし存在しなければあなたが用意しましょう。きっと感謝されます。

一方で所属したチームが既に環境整備済みだった場合はチームの人に「このCI環境や配布環境って誰が作ってくれたんですか？」と尋ねて、担当者の方に感謝を伝えておきましょう。本当にありがたいです。

審査提出バイナリの罠と対策​

特にApp Storeでよく問題になるのですが、審査通過後にバイナリを差し替えることは出来ません。つまりストア公開前の審査段階のバイナリと審査通過後の公開可能なバイナリは同一です。 同一のバイナリで、接続先を切り替えられる仕組みを用意しておきましょう。 典型的な実装としては、クライアント起動時にまずサーバに自らのバイナリバージョンを送信してどのサーバに接続すれば良いか問合せ、サーバがそのバイナリバージョンに応じた接続先を返すという物です。 このような仕組みを用意しておくと、バイナリの接続先をApp Storeの審査中はステージング環境、審査通過後は本番環境へと切り替えることが出来ます。 この仕組みを用意していないと、新機能実装など大規模アップデート時の審査に、本番環境ではバイナリが起動しないという状況でApp Storeのバイナリが本番環境に接続してしまうとアプリがクラッシュし、100%審査に落ちてしまいます。

（そうなってしまった場合は、苦肉の策としてゲームをアプリ審査している2週間くらい長期メンテにして、その間に本番環境を大規模アップデート版にアップデート、ユーザは2週間遊べないまま無視して、AppStore審査を無人の本番環境で遊んで貰うとなります。2週間のメンテ…考えるだけで胃が痛くなりますね…）

メジャーなライブラリを知ろう​

Unityのソーシャルゲーム開発、というよりUnityの大規模開発系だと以下のライブラリはよく使われます。それぞれUnityが苦手とする部分をカバーするライブラリなので、どういった用途で使っているかを確認して、似た用途なら積極的に使っていきましょう。

以下の3ライブラリを使わずにゲームを開発することは可能ですが、既にプロジェクトで採用されているなら積極的に覚えておきましょう。

UniRx​

  • Unityが.Net3.5系の頃からあるライブラリ
  • 非同期通信、イベントストリーム購読用途
  • 非同期通信については後述のasync,await+UniTaskを使うことが多いかも
  • 何も考えずに使うとゾンビストリームがメッチャ出るので勉強しましょう

Zenject​

  • DIフレームワーク for Unity的なもの
  • DIフレームワークと言いつつSignalBusやTickableも持っていたりする
  • どこまでZenjectを使う方針か確認しましょう
  • 最近のプロジェクトだとVContainer を使う事も多いです

UniTask​

  • Unity C#がC#7.x以降の構文を扱えるようになった結果、非同期処理にasyncとawaitが使えるようになった
  • 凄いコルーチン、みたいな感じの使い勝手(Task)
  • その凄いコルーチンは、オーバーヘッドが大きいし、Unity組み込み関数との繋ぎ込みが弱い
  • なのでasync awaitと組み合わせるUnity特化のTaskライブラリがUniTask

上記3種を触る資料​

  • UniRx・UniTask・Extenject・VContainer の簡単なハンズオンをクローズドコミュニティで行いました

メジャーなミドルウェア・ツールを知ろう​

Unityを使った大規模開発系では、以下のツール・ミドルウェアがよく併用されます。ライブラリ同様、Unityが苦手とする部分を補佐する製品群です。 以下に挙げたものは、いずれもUnityとは独立したツールでデータオーサリングを行い、Unity側ではSDKを通じて各種アセットを再生するものです。

開発規模が大きく作業者が多かったり複数社にまたがっている場合は、いちいちUnityのプロジェクトを全部共有して全員がUnityのライセンスを持って作業することが大変です。 自作ツールやExcelで頑張る道もなくはないですが、物量が多い2Dデータ、音声データ等の管理はいつか破綻します。こうしたツールを上手に使ってアセットパイプラインを構築することが重要になります。 有料ですが、ゲームで達成しなくてはならない機能とデータ量の見積もり、自作した場合の人月などを加味しつつ使うか判定すると良いでしょう。

Live 2D​

  • 2Dキャラクターを立体的にアニメーションできる技術
  • キャラ絵をパーツごとに分割して再構成する
  • キャラクターをイキイキさせたいという要望が上から来たら必須

OPTPiX SpriteStudio​

  • 汎用の2Dアニメーション作成ツール
  • ボーンアニメーション、エフェクト制作など
  • タイムライン機能を使ってワイプ・カットインの演出としても使える

CRI ADX2​

  • サウンドライブラリ＋サウンドオーサリングツール
  • Android端末での音の遅延対策が強く、音ゲーでは多く使われている
  • 曲やボイスデータが多いゲームでは、大量データをハンドリングするツールとして利用される
  • サウンドファイルが特殊形式なので、IPモノ等におけるデータ保護の意味で使う場合もある

Photon​

  • ネットワークマルチプレイミドルウェア
  • リアルタイムバトルがあるゲーム
  • バックエンド付きのCloud、自分で鯖立てするServerがある

mBaaS​

  • これは製品名ではなく製品カテゴリの名前
  • ログイン、ユーザーデータ保存、ログボ、ギルド等のサーバー側機能をまとめたサービス
  • 自社でバックエンドを組まない小規模タイトルや、プロトタイプ時のドライバ・スタブとしても活用価値あり

OSSの参考例を知ろう​

実際の画面遷移やシーン管理のコードはどうなるのかな？と気になってきた方は以下のものが参考になると思います。

アウトゲームのサンプル​

ミラティブでのアウトゲーム設計の紹介
https://tech.mirrativ.stream/entry/2023/09/22/112042

OutgameSample
https://github.com/mr-imada/OutgameSample

などを含みます。

シーン遷移管理フレームワーク​

Navigathena

Unityの最強シーン遷移管理フレームワーク『Navigathena』と画面管理の設計思想について解説