Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

unitydojo
November 05, 2016
3.9k

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

unitydojo

November 05, 2016
Tweet

Transcript

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

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

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

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

    クリエイターにとって理想的な環境を⽬指す • ⼀⼈⼀⼈の個性を最⼤限活かせる組織 • チームの裁量が⼤きいボトムアップ型組織(全体最 適<チーム最適) 7
  5. Happy Elements株式会社 9 55 53 உੑ ঁੑ 4 18(8) 26(8)

    56(28) 4(1) ࣾ௕ࣨ ϓϥϯφʔ ΤϯδχΞ σβΠφʔ αϙʔτ • 108名(社員63、アルバイト45) • 2016年3⽉時点 • イラストレーターの割合が⾼い • おそらく同業他社と⽐較して⼥性⽐率が⾼い • おそらく同業他社と⽐較してプランナー、エンジニア数が少ない • 下記表の()は数字内のアルバイト数 • 現在、アプリは5ライン
  6. ⽬次. A g e n d a 11 • ⾃⼰紹介

    • あんさんぶるスターズ!とは • 開発⽅針 • おわりに
  7. 現在のチーム規模 • エンジニア×4(+2) • デザイナー×1(+1) • プランナー • コンテンツ×2、コンテンツアシスタント×1(+1) •

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

    社員×4 (草苅含む) • 学⽣アルバイト×2〜3 • 得意、苦⼿はあるにしても、基本的に誰でもクライアン ト(Unity)、サーバー(Ruby on Rails)両⽅を対応で きるようにしています。 18
  9. 開発環境 • 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
  10. Unityを選択した理由1 • 2013年12⽉〜2014年1⽉くらいに調査。 • Unityの⽅が情報量が多かった。 • ウェブ上もそうだが、社内にも2アプリ分(マイポ ケットバー、メルクストーリア)の実績があった。 • Cocos2d-x

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

    ࣾ֎ϊ΢ϋ΢ ˓ ˚ ύϑΥʔϚϯε ˕ ˓ पลπʔϧ ˓ ˚ ಈతΞοϓσʔτ º ˓ ྉۚ º ˓ ࣗ༝ͳιϑτ΢ΣΞ º ˓ • 開発⾔語はUnityはC#、Cocos2d-xは基本的にLuaを想定。 • 開発効率についてはCocos2d-xはC++で◦、Luaで△という 評価。 • 2Dのパフォーマンス測定でも計測時はUnityに軍配。
  12. スタイルガイド1 • 独⾃のC#コーディング規約 • 以下の3つがベース • Microsoft C#コーディング規約 • Microsoft

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

    • ⾔語やフレームワークの流儀に従った書き⽅を推奨 • C#にRubyの流儀を持ち込まない • 例えば、to_sではなくToString • ⾔語を⼀つしかしらないエンジニアはそれを盲信し がち 30
  14. 前提知識の統⼀1 33 • より良いコードを書くためのシンプルで実践的なテクニック 例えば… • コードは他の⼈が最短時間で理解できるように書かなければ いけない • ⼀貫性のあるスタイルは「正しい」スタイルよりも⼤切

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

    • あらゆる⼈間関係の衝突は、謙虚・尊敬・信頼の⽋如に よるものだ。 • 円滑な開発コミュニケーションのための⼼がけ • 特にSlackやGitHub上でのコードレビュー時 Team Geek
  16. 開発ルールの統⼀ 38 • 新しく⼊ったメンバーにわかりやすいことが最重要 • 基本的にリーダブルコードに従う • 想定スキルはUnity C#を理解しているレベル •

    初⼼者に合わせるわけではなく、Unity経験者がチームに加 わったときにわかりやすいことが重要 • 標準や⾔語の流儀に従う • Unityらしさ、C#らしさを⼤事にする • 負債を残さない • ⾃分が⼀番やりやすいやりかたは、⼀般的ではないかもしれ ない ⼀番⼤事なことを決める
  17. 開発ルールの統⼀ 41 • 会社のスタイルガイド • ハンガリアン記法を使わない • 右辺から型があきらかな場合はvarを使う • MonoDevelopを使⽤していれば型はすぐにわかる

    • リーダブルコード • ⻑い名前を⼊⼒するのは問題じゃない • 短い命名にこだわる必要はない • 「⼊⼒しにくい」は問題にならない • 例えば、このあたりの話も、前提としてエディターが統⼀で きていなければ、話が噛み合わない場合もある • スタイルガイドを守れていれば、エディターは⾃由。 エディターの統⼀2
  18. GameKitのコンセプト • Railsの考え⽅を参考に開発効率を上げる • 設定より規約を重視(Convention over Configuration) • 規約を作ることで、開発効率・メンテナンス効率を上げる •

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

    画⾯遷移をわかりやすく。 • 画⾯のライフサイクルをわかりやすく。 • サーバー連携 • サーバーデータとのスムーズな連携。 • 通信暗号化。 46
  20. あんスタのクライアント構造 ໊শ ໾ׂ ྫ 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
  21. 画⾯遷移と画⾯のライフサイクルの管理するクラス • 画⾯遷移を管理するクラスAppApplication。 • アプリの処理は必ずここから開始される。 • 必ずAppApplicationクラス経由で画⾯遷移を⾏う • AppApplication.SwitchControllerを使⽤ •

    初回の画⾯起動のみAutoControllerActivatorクラス がControllerのActivateを⾏う 48 ໊শ આ໌ AppApplication ը໘ભҠͱը໘ͷϥΠϑαΠΫϧΛ؅ཧ ControllerActivator ControllerͷॳճىಈΛ࣮ߦ
  22. アプリの起動時の流れの明確化 50 • 1つのScriptに順番に処理(AddComponent)を書く • メリット • わかりやすい • 必ず書いた順番で実⾏される

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

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

    • ControllerとPrefabの紐付けはデフォルトはクラス名 だが、ディレクトリー指定やPrefab名指定など柔軟 に対応可能。 • 処理は基本的にControllerのライフサイクルに沿った Callbackメソッド内に記述する。 52
  25. Controllerのライフサイクル • OnWillAppear(ControllerParameter controllerParameter, Action<IControllerTransitionStatus> completion); • 画⾯描画の準備段階 • completion(ControllerTransitionStatus.Completed);呼

    び出しで完了を知らせる。 • OnAppear(); • 画⾯描画の準備ができたとき • OnDisappear(); • Controllerが削除されるとき • OnCancelWillAppear(); • 描画がキャンセルされたとき 55
  26. その他のGameKitの提供クラス例 • HttpClient • .Netの⼀番標準的な通信クラスであるHttpClientを模して 作ったクラス • Unityが.Net 4.0に対応したとき、可能な限り切り替えや すいように実装

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

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

    スタイルガイドの把握(Rubyもあります) • チームのルール • リーダブルコード、Team Geekを読んでもらう • クライアントの構造の把握(サーバーはRailsなので説明は 少ない) 64
  29. まとめ • あんスタにおけるクライアントの開発⽅針の⼀部を紹介しま した。 • コードを書く際には「新しく⼊ったメンバーがわかりやす いこと」を重要視していて、そのために標準や流儀に従う ことを⼤切にしています。 • 開発コミュニケーションではHRTを意識するようにしてい

    ます。 • Unityに関する具体的な実装についても⼀部紹介しました。 • Unityは様々なゲームに対応するため、汎⽤性の⾼いツー ルとなっているので、開発効率を上げるためには、⽬的と なるアプリの仕様に合わせて規約を作り、アプリの⾃由度 が失われない範囲で効率化するようにしています。 66