【Unity道場京都スペシャル】あんさんぶるスターズ!の開発方針

3865d333f9dc02cd417575c2cfa1606f?s=47 unitydojo
November 05, 2016
3.4k

 【Unity道場京都スペシャル】あんさんぶるスターズ!の開発方針

3865d333f9dc02cd417575c2cfa1606f?s=128

unitydojo

November 05, 2016
Tweet

Transcript

  1. あんさんぶるスターズ! の開発⽅針 1 Happy Elements株式会社 草苅 景

  2. 資料について • 資料は後ほど公開させて頂きます 2

  3. ⾃⼰紹介 3

  4. ⾃⼰紹介 • 草苅 景(くさかり けい) • @kusakari • Happy Elements株式会社

    • チーフエンジニア • あんさんぶるスターズ!グループリーダー 4
  5. Happy Elements • 本社は北京 • 代表作「Anipop」 • 2015年の中国のiOSゲームで、ダウンロード数1位、 ⽉間アクティブユーザー数1位、収益10位。 •

    パブリッシャーとしては、2015年の中国のiOSゲームで、 ダウンロード数4位、収益7位。(※App Annie調べ) 5
  6. Happy Elements株式会社 • 京都市下京区 • 11⽉1⽇の移転を機に京都オフィスは「カカリアスタジ オ」という名称になりました。 • 東京は経理系のみ。 •

    代表作 • メルクストーリア -癒術⼠と鈴のしらべ- • Google Play ベストゲーム2014 • あんさんぶるスターズ! • Google Play ベストゲーム2015 どちらもUnity製です! 6
  7. Happy Elements株式会社 • Make The World Happy • ゲームの提供を通じて世界を幸せに •

    クリエイターにとって理想的な環境を⽬指す • ⼀⼈⼀⼈の個性を最⼤限活かせる組織 • チームの裁量が⼤きいボトムアップ型組織(全体最 適<チーム最適) 7
  8. Happy Elements株式会社 • 2010年設⽴。 • 独⾃に⽇本市場向けにアプリを開発。 • 中国が⽇本に、あるいは⽇本が中国に展開の際には プロモーションなどで協⼒。 8

  9. Happy Elements株式会社 9 55 53 உੑ ঁੑ 4 18(8) 26(8)

    56(28) 4(1) ࣾ௕ࣨ ϓϥϯφʔ ΤϯδχΞ σβΠφʔ αϙʔτ • 108名(社員63、アルバイト45) • 2016年3⽉時点 • イラストレーターの割合が⾼い • おそらく同業他社と⽐較して⼥性⽐率が⾼い • おそらく同業他社と⽐較してプランナー、エンジニア数が少ない • 下記表の()は数字内のアルバイト数 • 現在、アプリは5ライン
  10. Happy Elements株式会社 • ⼀緒にゲームを作る仲間を募集中! • happyelements.co.jp から応募お願いします! 10

  11. ⽬次. A g e n d a 11 • ⾃⼰紹介

    • あんさんぶるスターズ!とは • 開発⽅針 • おわりに
  12. あんさんぶるスターズ! とは 12

  13. あんさんぶるスターズ!(あんスタ!)とは 13 項⽬ 内容 ゲーム内容 スマートフォン向け「アイドル育成プロデュースゲーム 」 ダウンロード数 累計200万ダウンロード(2016年9⽉) リリース⽇

    Google Play版2015年4⽉28⽇ App Store版 2015年5⽉1⽇
  14. Google Play 2015年ベストゲーム50に選出 • GCRESTさんの「夢王国と眠れる100⼈の王⼦様」(夢 100)と同時に選出。 • ⼥性向けゲームが選出されるのは初めて。 14 INSIDEΑΓҾ༻

    http://www.inside-games.jp/article/2015/12/05/93714.html
  15. App Storeのトップセールス1位に 15 • 2016年9⽉15⽇App Storeのトップセールス1位。 • リリースから約⼀年半。

  16. 現在のチーム規模 • エンジニア×4(+2) • デザイナー×1(+1) • プランナー • コンテンツ×2、コンテンツアシスタント×1(+1) •

    レベルデザイン×1、プロモーション×1、グッズ×1 • イラストレーター×10(+1) • Live2Dアニメーター×2(イラスト兼任) • Sprite Studioアニメーター×2 • 社外発注(シナリオ、サウンド、⼀部背景) 16 ※ʢʣ͸ֶੜͳͲඇৗۈͷΞϧόΠτ਺ ࣾ಺߹ܭ: 30ਓ
  17. 開発チーム 17

  18. 開発チーム • リリース前のエンジニア数 • 社員×3(草苅含む) • 学⽣アルバイト×3 • リリース後のエンジニア数 •

    社員×4 (草苅含む) • 学⽣アルバイト×2〜3 • 得意、苦⼿はあるにしても、基本的に誰でもクライアン ト(Unity)、サーバー(Ruby on Rails)両⽅を対応で きるようにしています。 18
  19. 開発環境 • Unity(クライアント) • リリース時は4.5.x、現在は5.3.x • NGUI 3.x、Live2D、Sprite Studio、Bugsnag •

    Ruby on Rails(サーバー) • Ruby 2.2.x、Rails 4.1.x • サーバーミドルウェア • MySQL、Cassandra、Memcached、Redis、 Redshiftなど 19
  20. チーム内の情報共有 • Slack • チーム内コミュニケーション • GitHub • リポジトリー、PRコードレビュー •

    GitHub Issue • タスク管理 • Qiita:Team • 全社情報共有 20
  21. 開発⽅針 21

  22. 会社の統⼀ルール 22

  23. 開発⽅針 • 会社の統⼀ルール • Unity(C#)の利⽤ • スタイルガイド • チームのルール •

    前提知識の統⼀ • 開発ルールの統⼀ 23
  24. Unityを選択した理由1 • 2013年12⽉〜2014年1⽉くらいに調査。 • Unityの⽅が情報量が多かった。 • ウェブ上もそうだが、社内にも2アプリ分(マイポ ケットバー、メルクストーリア)の実績があった。 • Cocos2d-x

    (特にC++以外)は情報が少ない上に、 中国語だったり。 • 3.x への切り替えのタイミングであったこともマイナス要素。 • 周辺ツールの完成度 • Cocos2d-xは個⼈がメンテしているものもあり、不 安要素の⼀つ。 24
  25. Unityを選択した理由2 25 Unity Cocos2d-x ։ൃޮ཰ ˕ ˓ ࣾ಺ϊ΢ϋ΢ ˓ º

    ࣾ֎ϊ΢ϋ΢ ˓ ˚ ύϑΥʔϚϯε ˕ ˓ पลπʔϧ ˓ ˚ ಈతΞοϓσʔτ º ˓ ྉۚ º ˓ ࣗ༝ͳιϑτ΢ΣΞ º ˓ • 開発⾔語はUnityはC#、Cocos2d-xは基本的にLuaを想定。 • 開発効率についてはCocos2d-xはC++で◦、Luaで△という 評価。 • 2Dのパフォーマンス測定でも計測時はUnityに軍配。
  26. Unityを選択した理由3 • ⾃動アップデート • Cocos2d-xの場合、Luaで実装するとアプリを丸ごと ⼊れ替えられるのが⼀つのメリットだった。 • 各OSにアプリの⾃動アップデートが追加され、アプ リのアップデートによる利⽤ユーザーの減少の⼼配 が少なくなった。

    • 実際の使⽤感 • ⾃由なソフトウェア主義者2⼈に、実際にデモゲーム を両⽅で作ってもらったところ、⼆⼈ともUnityの⽅ が作りやすいと回答した。 26
  27. Unityを選択した理由4 • 2014年1⽉の段階では、Cocos2d-x を使うメリットは 「⾃由なソフトウェア」であるということくらい。 • 開発者としてそこを⼤事にしたい気持ちもあったが、 ネイティブアプリ開発について、技術的に先⾏して いる他社を追いかけている段階で、そこにこだわっ ても仕⽅がないと感じた。

    • プロジェクトによって選択するという案もあったが、全 社的にUnityで統⼀。 27
  28. 開発⽅針 • 会社の統⼀ルール • Unity(C#)の利⽤ • スタイルガイド • チームのルール •

    前提知識の統⼀ • 開発ルールの統⼀ 28
  29. スタイルガイド1 • 独⾃のC#コーディング規約 • 以下の3つがベース • Microsoft C#コーディング規約 • Microsoft

    クラスライブラリ開発のデザインガイドライン • Unity Gems Coding Conventions • Not Found… • 会社標準とすることができる基本的な部分のみ記述 • 独⾃規約というよりは重要なポイントだけを抜粋。 29
  30. スタイルガイド2 • 以前所属していた会社ではJavaの独⾃コーディング規約 • 転職先では「SunのCoding Conventionsで」 • わかりやすくて世界標準 • 標準があるならそれに従う

    • ⾔語やフレームワークの流儀に従った書き⽅を推奨 • C#にRubyの流儀を持ち込まない • 例えば、to_sではなくToString • ⾔語を⼀つしかしらないエンジニアはそれを盲信し がち 30
  31. チームのルール 31

  32. 開発⽅針 • 会社の統⼀ルール • Unity(C#)の利⽤ • スタイルガイド • チームのルール •

    前提知識の統⼀ • 開発ルールの統⼀ 32
  33. 前提知識の統⼀1 33 • より良いコードを書くためのシンプルで実践的なテクニック 例えば… • コードは他の⼈が最短時間で理解できるように書かなければ いけない • ⼀貫性のあるスタイルは「正しい」スタイルよりも⼤切

    • コードからすぐにわかることをコメントに書かない • ひどい名前はコメントを書かずに名前を変える • 制御フローはできるだけ「⾃然」にする • ⾏数を短くするよりも、他の⼈が理解するのにかかる時間を 短くする • 最も読みやすいコードは、何も書かれていないコード リーダブルコード
  34. 前提知識の統⼀2 34 • HRT(ハート) • 謙虚(Humility) • 尊敬(Respect) • 信頼(Trust)

    • あらゆる⼈間関係の衝突は、謙虚・尊敬・信頼の⽋如に よるものだ。 • 円滑な開発コミュニケーションのための⼼がけ • 特にSlackやGitHub上でのコードレビュー時 Team Geek
  35. 前提知識の統⼀3 • あんスタチームではエンジニアはこの2冊を初めに読ん でもらうようにしている。 • 前提が⼀致していない状態で、同じゴールに向かうこと は⾮常に難しい。 • 「リーダブルコード(Team Geek)に書いてあったで

    しょ」という形でスムーズにコミュニケーションが取れ るようになることには⼤きな価値がある。 35
  36. 開発⽅針 • 会社の統⼀ルール • Unity(C#)の利⽤ • スタイルガイド • チームのルール •

    前提知識の統⼀ • 開発ルールの統⼀ 36
  37. 開発ルールの統⼀ • ⼀番⼤事なことを決める • 決定者を決める • エディターの統⼀ • クライアントの構造 37

  38. 開発ルールの統⼀ 38 • 新しく⼊ったメンバーにわかりやすいことが最重要 • 基本的にリーダブルコードに従う • 想定スキルはUnity C#を理解しているレベル •

    初⼼者に合わせるわけではなく、Unity経験者がチームに加 わったときにわかりやすいことが重要 • 標準や⾔語の流儀に従う • Unityらしさ、C#らしさを⼤事にする • 負債を残さない • ⾃分が⼀番やりやすいやりかたは、⼀般的ではないかもしれ ない ⼀番⼤事なことを決める
  39. 開発ルールの統⼀ 39 • 基本的に実装の⽅向性は実装者に任せているが、コード レビュー時などにどうしても好みの問題となることがあ る。 • 好みの問題となったら、最終的に誰が判断するのかは予 め決めた上で周知しておく。 決定者を決める

  40. 開発ルールの統⼀ 40 • エディターを統⼀しないと、コーディングスタイルを合 わせる難易度が⾼くなる。 • チームはMonoDevelopで統⼀。 • policyファイルも共有。 エディターの統⼀1

  41. 開発ルールの統⼀ 41 • 会社のスタイルガイド • ハンガリアン記法を使わない • 右辺から型があきらかな場合はvarを使う • MonoDevelopを使⽤していれば型はすぐにわかる

    • リーダブルコード • ⻑い名前を⼊⼒するのは問題じゃない • 短い命名にこだわる必要はない • 「⼊⼒しにくい」は問題にならない • 例えば、このあたりの話も、前提としてエディターが統⼀で きていなければ、話が噛み合わない場合もある • スタイルガイドを守れていれば、エディターは⾃由。 エディターの統⼀2
  42. 開発ルールの統⼀ 42 • GameKitという開発基盤を作って利⽤。 • 元々全社で使うためにあんスタで開発を進めていた が、⼤きくなりすぎたため必要最低限のコア部分の みに縮⼩。 • 結局、⼀部のアプリでのみ利⽤。

    • 開発効率を上げるためには、開発基盤が必要だとは 考えているものの、全社で使うには成熟度が⾜りな い。 クライアントの構造
  43. GameKit 43

  44. Unityを使った開発でありがちなこと • ⾃由度が⾼すぎて全社で利⽤するような共通化がし⾟い • 同じアプリ内でも、開発者ごとに別々のコードに • 例えば、画⾯を切り替える⽅法は?ボタンが押されたときの 処理はどこに記述する? • エントリーポイントがわかりづらい

    • 処理の流れが追いづらい • Sceneの切り替えが重い • 5.xでは改善? • 分業開発効率 • SceneやPrefabがコンフリクトしがち 44
  45. GameKitのコンセプト • Railsの考え⽅を参考に開発効率を上げる • 設定より規約を重視(Convention over Configuration) • 規約を作ることで、開発効率・メンテナンス効率を上げる •

    例えば、RailsならURLとソースコードが紐付いている • /cards/create • CardsController#create • GameKitでは画⾯とソースコードが紐付くように • Controller名からソースコード、Prefabがすぐにわかる • RailsはMVCだが、GameKitではMVVMという構造 45
  46. GameKitが解決すること • アプリ構造の(⼀定の)統⼀。 • MVVM。 • 画⾯遷移と画⾯のライフサイクルの管理。 • アプリ起動時の流れの明確化。 •

    画⾯遷移をわかりやすく。 • 画⾯のライフサイクルをわかりやすく。 • サーバー連携 • サーバーデータとのスムーズな連携。 • 通信暗号化。 46
  47. あんスタのクライアント構造 ໊শ ໾ׂ ྫ Controller جຊతʹҰͭͷը໘(Prefab)Λද͢ɺ ը໘ͷ੍ޚΛߦ͏Ϋϥε TitleControllerɺ MyPageController Entity

    αʔόʔ͔Βऔಘͨ͠σʔλΛද͢ Ϋϥε UserɺCardɺStory Model ΫϥΠΞϯτଆݻ༗ͷσʔλΛͻͱ ·ͱΊʹͨ͠΋ͷ BattleProcessɺ ServerConnectionɺ StoryBackgroundEffect or ViewModel EntityͱUIͷڮ౉͠Λ͢ΔΫϥε EntityΛηοτ͢ΔͱUIʹ஋Λදࣔ UserViewModelɺ CardViewModel View ෳࡶͳUIͷͱ͖ͳͲʹ෦඼Խ͞Εͨ Ϋϥε BackButtonɺ CardInfoViewɺ CardScrollViewItem 47
  48. 画⾯遷移と画⾯のライフサイクルの管理するクラス • 画⾯遷移を管理するクラスAppApplication。 • アプリの処理は必ずここから開始される。 • 必ずAppApplicationクラス経由で画⾯遷移を⾏う • AppApplication.SwitchControllerを使⽤ •

    初回の画⾯起動のみAutoControllerActivatorクラス がControllerのActivateを⾏う 48 ໊শ આ໌ AppApplication ը໘ભҠͱը໘ͷϥΠϑαΠΫϧΛ؅ཧ ControllerActivator ControllerͷॳճىಈΛ࣮ߦ
  49. 初回起動時 49 ॳճͷΈController͕࠷ॳ͔Β ͋ΔͨΊɺActivator͕ඞཁ

  50. アプリの起動時の流れの明確化 50 • 1つのScriptに順番に処理(AddComponent)を書く • メリット • わかりやすい • 必ず書いた順番で実⾏される

    • 例えば初期化後にAutoControllerActivatorをアタッチした い • デメリット • Unity的にHierarchyで「Add Component」することが標準的 で、通常はそういう期待をするように感じる 処理の順序をどこで制御するか問題
  51. アプリの起動時の流れの明確化 51 • Script Execution Order • メリット • Unityの流儀に沿っている

    • デメリット • Unity初⼼者にはわかりづらい →Unityは理解しているという前提であるべき形に 処理の順序をどこで制御するか問題
  52. Controllerの仕組み1 • 画⾯(Prefab)とController(Script)が1対1で対応 • PrefabControllerを継承してControllerを作成 • Controllerを⾒れば、その画⾯の処理の流れがわかる。 • 例えば、ボタンが押されたときの処理は基本的にコントロー ラーに記述する。

    • ControllerとPrefabの紐付けはデフォルトはクラス名 だが、ディレクトリー指定やPrefab名指定など柔軟 に対応可能。 • 処理は基本的にControllerのライフサイクルに沿った Callbackメソッド内に記述する。 52
  53. Controllerの仕組み2 • AppApplication.SwitchController<TitleController>() が実⾏されると画⾯遷移時にGameKitが⾃動で Resources/Prefabs/TitleController.prefabをインスタ ンス化する • 画⾯遷移時に該当ControllerのCallbackが呼ばれる • 必要なアセットなども⾃動ロードされる

    • 起動失敗時には呼び出し元の起動失敗Callbackが呼 ばれる • SwitchされたControllerは破棄される 53
  54. 画⾯遷移 AppApplication.SwitchController<TitleController>(param, false, Loading.LoadingViewType.None); 54 SplashController GKUIRootҎԼʹ͋Δ Controller͕Switch

  55. Controllerのライフサイクル • OnWillAppear(ControllerParameter controllerParameter, Action<IControllerTransitionStatus> completion); • 画⾯描画の準備段階 • completion(ControllerTransitionStatus.Completed);呼

    び出しで完了を知らせる。 • OnAppear(); • 画⾯描画の準備ができたとき • OnDisappear(); • Controllerが削除されるとき • OnCancelWillAppear(); • 描画がキャンセルされたとき 55
  56. 例.カード詳細画⾯1 56 ControllerͱPrefab͕ 1:1Ͱඥ෇͍͍ͯΔ ΠϯελϯεԽ PrefabControllerΛ ܧঝͨ͠Controller

  57. 例.カード詳細画⾯2 57 ViewModelΛ࢖ͬͯ σʔλΛදࣔ

  58. 例.カード詳細画⾯3 58

  59. 例.カード詳細画⾯4 59 CardViewModel͸ ͍Ζ͍Ζͳը໘Ͱ ࢖͍ճͤΔ

  60. 画⾯ごとの開発 • 画⾯ごとに開発⽤のSceneを作って開発。 • 他の開発者にあまり影響されることなく開発できる。 • 基本的にすべての画⾯がSceneになっており、単独 で起動可能。 • アプリは単⼀Scene(MainScene)となっており、

    Controllerが切り替わるだけでSceneは切り替わらない。 60
  61. 開発⽤Sceneの起動 61 CardDetailScene ControllerActivatorΛΧελ ϚΠζͯ͠ɺcard_id=746 Λࢦఆͯ͠දࣔ ControllerҎԼ͕ Prefabʹͳ͍ͬͯΔ

  62. その他のGameKitの提供クラス例 • HttpClient • .Netの⼀番標準的な通信クラスであるHttpClientを模して 作ったクラス • Unityが.Net 4.0に対応したとき、可能な限り切り替えや すいように実装

    • 内部実装はUniRxとThreadNinjyaを切り替え可能 • UniRxを使いたかったがUnityのバージョンアップ時に動かなく なる場合があり、リスクが⾼かったため切り替え可能に • GKHttpClient • ⾃動暗号化と⾃動シリアライズ化に対応 • シリアライズはJson、MessagePackに対応 • ⾃動で暗号化されるため、クライアント開発者は暗号化・ 復号化を意識しない。 62
  63. 会社で統⼀して(いる|いこうとしている)部分 63 • 通信暗号化(GameKit組み込み) • 対応済みだが改善の余地あり • UUID の⽣成⽅法 •

    統⼀されているがライブラリー化されていない • データ引き継ぎ(Game Center、Saved Game) • ⽅法含め改善の余地あり • 課⾦(Google Play、App Store) • Unity IAP(Unity5.3以降)に移⾏するかも。 • 弊社の新しいアプリでは利⽤。 汎⽤ライブラリー
  64. 開発⽅針を伝える • 新しいエンジニアスタッフが⼊ったら… • 開発環境を構築してもらう。 • 次に開発⽅針を伝える。 • 会社のルール •

    スタイルガイドの把握(Rubyもあります) • チームのルール • リーダブルコード、Team Geekを読んでもらう • クライアントの構造の把握(サーバーはRailsなので説明は 少ない) 64
  65. おわりに 65

  66. まとめ • あんスタにおけるクライアントの開発⽅針の⼀部を紹介しま した。 • コードを書く際には「新しく⼊ったメンバーがわかりやす いこと」を重要視していて、そのために標準や流儀に従う ことを⼤切にしています。 • 開発コミュニケーションではHRTを意識するようにしてい

    ます。 • Unityに関する具体的な実装についても⼀部紹介しました。 • Unityは様々なゲームに対応するため、汎⽤性の⾼いツー ルとなっているので、開発効率を上げるためには、⽬的と なるアプリの仕様に合わせて規約を作り、アプリの⾃由度 が失われない範囲で効率化するようにしています。 66
  67. Happy Elements株式会社が今後強みとしたいこと • ウェブのソーシャルゲームからスタートしたということ もあり、エンジニアもウェブエンジニアばかりです。 • コンシューマー経験者は⼀⼈もいませんが、Unityに ついても⾃分たちなりに頑張っています。 • サーバーサイドはある程度強いため、中⻑期ではUnity

    が⾃社の強みとなるように取り組んでいきます。 • あくまでゲームありきではありますが、開発のクオ リティでアプリの価値をひっぱっていけるようにし たいと考えています。 67
  68. ご静聴ありがとうございました! • ⼀緒にゲームを作る仲間を募集中! • Unityでゲームを作りたい⼈、happyelements.co.jp か ら応募お願いします! 68