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

Transcript

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

   View Slide

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

   View Slide

3. ⾃⼰紹介
   3
   

   View Slide

4. ⾃⼰紹介
   • 草苅 景（くさかり けい）
   • @kusakari
   • Happy Elements株式会社
   • チーフエンジニア
   • あんさんぶるスターズ！グループリーダー
   4
   

   View Slide

5. Happy Elements
   • 本社は北京
   • 代表作「Anipop」
   • 2015年の中国のiOSゲームで、ダウンロード数1位、
   ⽉間アクティブユーザー数1位、収益10位。
   • パブリッシャーとしては、2015年の中国のiOSゲームで、
   ダウンロード数4位、収益7位。（※App Annie調べ）
   5
   

   View Slide

6. Happy Elements株式会社
   • 京都市下京区
   • 11⽉1⽇の移転を機に京都オフィスは「カカリアスタジ
   オ」という名称になりました。
   • 東京は経理系のみ。
   • 代表作
   • メルクストーリア -癒術⼠と鈴のしらべ-
   • Google Play ベストゲーム2014
   • あんさんぶるスターズ！
   • Google Play ベストゲーム2015
   どちらもUnity製です！
   6
   

   View Slide

7. Happy Elements株式会社
   • Make The World Happy
   • ゲームの提供を通じて世界を幸せに
   • クリエイターにとって理想的な環境を⽬指す
   • ⼀⼈⼀⼈の個性を最⼤限活かせる組織
   • チームの裁量が⼤きいボトムアップ型組織（全体最
   適＜チーム最適）
   7
   

   View Slide

8. Happy Elements株式会社
   • 2010年設⽴。
   • 独⾃に⽇本市場向けにアプリを開発。
   • 中国が⽇本に、あるいは⽇本が中国に展開の際には
   プロモーションなどで協⼒。
   8
   

   View Slide

9. Happy Elements株式会社
   9
   55
   53
   உੑ
   ঁੑ
   4
   18(8)
   26(8)
   56(28)
   4(1)
   ࣾ௕ࣨ
   ϓϥϯφʔ
   ΤϯδχΞ
   σβΠφʔ
   αϙʔτ
   • 108名（社員63、アルバイト45）
   • 2016年3⽉時点
   • イラストレーターの割合が⾼い
   • おそらく同業他社と⽐較して⼥性⽐率が⾼い
   • おそらく同業他社と⽐較してプランナー、エンジニア数が少ない
   • 下記表の（）は数字内のアルバイト数
   • 現在、アプリは5ライン
   

   View Slide

10. Happy Elements株式会社
    • ⼀緒にゲームを作る仲間を募集中！
    • happyelements.co.jp から応募お願いします！
    10
    

    View Slide

11. ⽬次.
    A g e n d a
    11
    • ⾃⼰紹介
    • あんさんぶるスターズ！とは
    • 開発⽅針
    • おわりに
    

    View Slide

12. あんさんぶるスターズ！
    とは
    12
    

    View Slide

13. あんさんぶるスターズ！（あんスタ！）とは
    13
    項⽬ 内容
    ゲーム内容 スマートフォン向け「アイドル育成プロデュースゲーム 」
    ダウンロード数 累計200万ダウンロード（2016年9⽉）
    リリース⽇ Google Play版2015年4⽉28⽇
    App Store版 2015年5⽉1⽇
    

    View Slide

14. Google Play 2015年ベストゲーム50に選出
    • GCRESTさんの「夢王国と眠れる100⼈の王⼦様」（夢
    100）と同時に選出。
    • ⼥性向けゲームが選出されるのは初めて。
    14
    INSIDEΑΓҾ༻
    http://www.inside-games.jp/article/2015/12/05/93714.html
    

    View Slide

15. App Storeのトップセールス1位に
    15
    • 2016年9⽉15⽇App Storeのトップセールス1位。
    • リリースから約⼀年半。
    

    View Slide

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

    View Slide

17. 開発チーム
    17
    

    View Slide

18. 開発チーム
    • リリース前のエンジニア数
    • 社員×3（草苅含む）
    • 学⽣アルバイト×3
    • リリース後のエンジニア数
    • 社員×4 （草苅含む）
    • 学⽣アルバイト×2〜3
    • 得意、苦⼿はあるにしても、基本的に誰でもクライアン
    ト（Unity）、サーバー（Ruby on Rails）両⽅を対応で
    きるようにしています。
    18
    

    View Slide

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
    

    View Slide

20. チーム内の情報共有
    • Slack
    • チーム内コミュニケーション
    • GitHub
    • リポジトリー、PRコードレビュー
    • GitHub Issue
    • タスク管理
    • Qiita:Team
    • 全社情報共有
    20
    

    View Slide

21. 開発⽅針
    21
    

    View Slide

22. 会社の統⼀ルール
    22
    

    View Slide

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

    View Slide

24. Unityを選択した理由1
    • 2013年12⽉〜2014年1⽉くらいに調査。
    • Unityの⽅が情報量が多かった。
    • ウェブ上もそうだが、社内にも2アプリ分（マイポ
    ケットバー、メルクストーリア）の実績があった。
    • Cocos2d-x （特にC++以外）は情報が少ない上に、
    中国語だったり。
    • 3.x への切り替えのタイミングであったこともマイナス要素。
    • 周辺ツールの完成度
    • Cocos2d-xは個⼈がメンテしているものもあり、不
    安要素の⼀つ。
    24
    

    View Slide

25. Unityを選択した理由2
    25
    Unity Cocos2d-x
    ։ൃޮ཰ ˕ ˓
    ࣾ಺ϊ΢ϋ΢ ˓ º
    ࣾ֎ϊ΢ϋ΢ ˓ ˚
    ύϑΥʔϚϯε ˕ ˓
    पลπʔϧ ˓ ˚
    ಈతΞοϓσʔτ º ˓
    ྉۚ º ˓
    ࣗ༝ͳιϑτ΢ΣΞ º ˓
    • 開発⾔語はUnityはC#、Cocos2d-xは基本的にLuaを想定。
    • 開発効率についてはCocos2d-xはC++で○、Luaで△という
    評価。
    • 2Dのパフォーマンス測定でも計測時はUnityに軍配。
    

    View Slide

26. Unityを選択した理由3
    • ⾃動アップデート
    • Cocos2d-xの場合、Luaで実装するとアプリを丸ごと
    ⼊れ替えられるのが⼀つのメリットだった。
    • 各OSにアプリの⾃動アップデートが追加され、アプ
    リのアップデートによる利⽤ユーザーの減少の⼼配
    が少なくなった。
    • 実際の使⽤感
    • ⾃由なソフトウェア主義者2⼈に、実際にデモゲーム
    を両⽅で作ってもらったところ、⼆⼈ともUnityの⽅
    が作りやすいと回答した。
    26
    

    View Slide

27. Unityを選択した理由4
    • 2014年1⽉の段階では、Cocos2d-x を使うメリットは
    「⾃由なソフトウェア」であるということくらい。
    • 開発者としてそこを⼤事にしたい気持ちもあったが、
    ネイティブアプリ開発について、技術的に先⾏して
    いる他社を追いかけている段階で、そこにこだわっ
    ても仕⽅がないと感じた。
    • プロジェクトによって選択するという案もあったが、全
    社的にUnityで統⼀。
    27
    

    View Slide

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

    View Slide

29. スタイルガイド1
    • 独⾃のC#コーディング規約
    • 以下の3つがベース
    • Microsoft C#コーディング規約
    • Microsoft クラスライブラリ開発のデザインガイドライン
    • Unity Gems Coding Conventions
    • Not Found…
    • 会社標準とすることができる基本的な部分のみ記述
    • 独⾃規約というよりは重要なポイントだけを抜粋。
    29
    

    View Slide

30. スタイルガイド2
    • 以前所属していた会社ではJavaの独⾃コーディング規約
    • 転職先では「SunのCoding Conventionsで」
    • わかりやすくて世界標準
    • 標準があるならそれに従う
    • ⾔語やフレームワークの流儀に従った書き⽅を推奨
    • C#にRubyの流儀を持ち込まない
    • 例えば、to_sではなくToString
    • ⾔語を⼀つしかしらないエンジニアはそれを盲信し
    がち
    30
    

    View Slide

31. チームのルール
    31
    

    View Slide

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

    View Slide

33. 前提知識の統⼀1
    33
    • より良いコードを書くためのシンプルで実践的なテクニック
    例えば…
    • コードは他の⼈が最短時間で理解できるように書かなければ
    いけない
    • ⼀貫性のあるスタイルは「正しい」スタイルよりも⼤切
    • コードからすぐにわかることをコメントに書かない
    • ひどい名前はコメントを書かずに名前を変える
    • 制御フローはできるだけ「⾃然」にする
    • ⾏数を短くするよりも、他の⼈が理解するのにかかる時間を
    短くする
    • 最も読みやすいコードは、何も書かれていないコード
    リーダブルコード
    

    View Slide

34. 前提知識の統⼀2
    34
    • HRT（ハート）
    • 謙虚（Humility）
    • 尊敬（Respect）
    • 信頼（Trust）
    • あらゆる⼈間関係の衝突は、謙虚・尊敬・信頼の⽋如に
    よるものだ。
    • 円滑な開発コミュニケーションのための⼼がけ
    • 特にSlackやGitHub上でのコードレビュー時
    Team Geek
    

    View Slide

35. 前提知識の統⼀3
    • あんスタチームではエンジニアはこの2冊を初めに読ん
    でもらうようにしている。
    • 前提が⼀致していない状態で、同じゴールに向かうこと
    は⾮常に難しい。
    • 「リーダブルコード（Team Geek）に書いてあったで
    しょ」という形でスムーズにコミュニケーションが取れ
    るようになることには⼤きな価値がある。
    35
    

    View Slide

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

    View Slide

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

    View Slide

38. 開発ルールの統⼀
    38
    • 新しく⼊ったメンバーにわかりやすいことが最重要
    • 基本的にリーダブルコードに従う
    • 想定スキルはUnity C#を理解しているレベル
    • 初⼼者に合わせるわけではなく、Unity経験者がチームに加
    わったときにわかりやすいことが重要
    • 標準や⾔語の流儀に従う
    • Unityらしさ、C#らしさを⼤事にする
    • 負債を残さない
    • ⾃分が⼀番やりやすいやりかたは、⼀般的ではないかもしれ
    ない
    ⼀番⼤事なことを決める
    

    View Slide

39. 開発ルールの統⼀
    39
    • 基本的に実装の⽅向性は実装者に任せているが、コード
    レビュー時などにどうしても好みの問題となることがあ
    る。
    • 好みの問題となったら、最終的に誰が判断するのかは予
    め決めた上で周知しておく。
    決定者を決める
    

    View Slide

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

    View Slide

41. 開発ルールの統⼀
    41
    • 会社のスタイルガイド
    • ハンガリアン記法を使わない
    • 右辺から型があきらかな場合はvarを使う
    • MonoDevelopを使⽤していれば型はすぐにわかる
    • リーダブルコード
    • ⻑い名前を⼊⼒するのは問題じゃない
    • 短い命名にこだわる必要はない
    • 「⼊⼒しにくい」は問題にならない
    • 例えば、このあたりの話も、前提としてエディターが統⼀で
    きていなければ、話が噛み合わない場合もある
    • スタイルガイドを守れていれば、エディターは⾃由。
    エディターの統⼀2
    

    View Slide

42. 開発ルールの統⼀
    42
    • GameKitという開発基盤を作って利⽤。
    • 元々全社で使うためにあんスタで開発を進めていた
    が、⼤きくなりすぎたため必要最低限のコア部分の
    みに縮⼩。
    • 結局、⼀部のアプリでのみ利⽤。
    • 開発効率を上げるためには、開発基盤が必要だとは
    考えているものの、全社で使うには成熟度が⾜りな
    い。
    クライアントの構造
    

    View Slide

43. GameKit
    43
    

    View Slide

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

    View Slide

45. GameKitのコンセプト
    • Railsの考え⽅を参考に開発効率を上げる
    • 設定より規約を重視（Convention over Configuration)
    • 規約を作ることで、開発効率・メンテナンス効率を上げる
    • 例えば、RailsならURLとソースコードが紐付いている
    • /cards/create
    • CardsController#create
    • GameKitでは画⾯とソースコードが紐付くように
    • Controller名からソースコード、Prefabがすぐにわかる
    • RailsはMVCだが、GameKitではMVVMという構造
    45
    

    View Slide

46. GameKitが解決すること
    • アプリ構造の（⼀定の）統⼀。
    • MVVM。
    • 画⾯遷移と画⾯のライフサイクルの管理。
    • アプリ起動時の流れの明確化。
    • 画⾯遷移をわかりやすく。
    • 画⾯のライフサイクルをわかりやすく。
    • サーバー連携
    • サーバーデータとのスムーズな連携。
    • 通信暗号化。
    46
    

    View Slide

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
    

    View Slide

48. 画⾯遷移と画⾯のライフサイクルの管理するクラス
    • 画⾯遷移を管理するクラスAppApplication。
    • アプリの処理は必ずここから開始される。
    • 必ずAppApplicationクラス経由で画⾯遷移を⾏う
    • AppApplication.SwitchControllerを使⽤
    • 初回の画⾯起動のみAutoControllerActivatorクラス
    がControllerのActivateを⾏う
    48
    ໊শ આ໌
    AppApplication ը໘ભҠͱը໘ͷϥΠϑαΠΫϧΛ؅ཧ
    ControllerActivator ControllerͷॳճىಈΛ࣮ߦ
    

    View Slide

49. 初回起動時
    49
    ॳճͷΈController͕࠷ॳ͔Β
    ͋ΔͨΊɺActivator͕ඞཁ
    

    View Slide

50. アプリの起動時の流れの明確化
    50
    • 1つのScriptに順番に処理（AddComponent）を書く
    • メリット
    • わかりやすい
    • 必ず書いた順番で実⾏される
    • 例えば初期化後にAutoControllerActivatorをアタッチした
    い
    • デメリット
    • Unity的にHierarchyで「Add Component」することが標準的
    で、通常はそういう期待をするように感じる
    処理の順序をどこで制御するか問題
    

    View Slide

51. アプリの起動時の流れの明確化
    51
    • Script Execution Order
    • メリット
    • Unityの流儀に沿っている
    • デメリット
    • Unity初⼼者にはわかりづらい
    →Unityは理解しているという前提であるべき形に
    処理の順序をどこで制御するか問題
    

    View Slide

52. Controllerの仕組み1
    • 画⾯（Prefab）とController（Script）が1対1で対応
    • PrefabControllerを継承してControllerを作成
    • Controllerを⾒れば、その画⾯の処理の流れがわかる。
    • 例えば、ボタンが押されたときの処理は基本的にコントロー
    ラーに記述する。
    • ControllerとPrefabの紐付けはデフォルトはクラス名
    だが、ディレクトリー指定やPrefab名指定など柔軟
    に対応可能。
    • 処理は基本的にControllerのライフサイクルに沿った
    Callbackメソッド内に記述する。
    52
    

    View Slide

53. Controllerの仕組み2
    • AppApplication.SwitchController()
    が実⾏されると画⾯遷移時にGameKitが⾃動で
    Resources/Prefabs/TitleController.prefabをインスタ
    ンス化する
    • 画⾯遷移時に該当ControllerのCallbackが呼ばれる
    • 必要なアセットなども⾃動ロードされる
    • 起動失敗時には呼び出し元の起動失敗Callbackが呼
    ばれる
    • SwitchされたControllerは破棄される
    53
    

    View Slide

54. 画⾯遷移
    AppApplication.SwitchController(param, false,
    Loading.LoadingViewType.None);
    54
    SplashController
    GKUIRootҎԼʹ͋Δ
    Controller͕Switch
    

    View Slide

55. Controllerのライフサイクル
    • OnWillAppear(ControllerParameter controllerParameter,
    Action completion);
    • 画⾯描画の準備段階
    • completion(ControllerTransitionStatus.Completed);呼
    び出しで完了を知らせる。
    • OnAppear();
    • 画⾯描画の準備ができたとき
    • OnDisappear();
    • Controllerが削除されるとき
    • OnCancelWillAppear();
    • 描画がキャンセルされたとき
    55
    

    View Slide

56. 例.カード詳細画⾯1
    56
    ControllerͱPrefab͕
    1:1Ͱඥ෇͍͍ͯΔ
    ΠϯελϯεԽ
    PrefabControllerΛ
    ܧঝͨ͠Controller
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

61. 開発⽤Sceneの起動
    61
    CardDetailScene
    ControllerActivatorΛΧελ
    ϚΠζͯ͠ɺcard_id=746
    Λࢦఆͯ͠දࣔ
    ControllerҎԼ͕
    Prefabʹͳ͍ͬͯΔ
    

    View Slide

62. その他のGameKitの提供クラス例
    • HttpClient
    • .Netの⼀番標準的な通信クラスであるHttpClientを模して
    作ったクラス
    • Unityが.Net 4.0に対応したとき、可能な限り切り替えや
    すいように実装
    • 内部実装はUniRxとThreadNinjyaを切り替え可能
    • UniRxを使いたかったがUnityのバージョンアップ時に動かなく
    なる場合があり、リスクが⾼かったため切り替え可能に
    • GKHttpClient
    • ⾃動暗号化と⾃動シリアライズ化に対応
    • シリアライズはJson、MessagePackに対応
    • ⾃動で暗号化されるため、クライアント開発者は暗号化・
    復号化を意識しない。
    62
    

    View Slide

63. 会社で統⼀して（いる|いこうとしている）部分
    63
    • 通信暗号化（GameKit組み込み）
    • 対応済みだが改善の余地あり
    • UUID の⽣成⽅法
    • 統⼀されているがライブラリー化されていない
    • データ引き継ぎ（Game Center、Saved Game）
    • ⽅法含め改善の余地あり
    • 課⾦（Google Play、App Store）
    • Unity IAP（Unity5.3以降）に移⾏するかも。
    • 弊社の新しいアプリでは利⽤。
    汎⽤ライブラリー
    

    View Slide

64. 開発⽅針を伝える
    • 新しいエンジニアスタッフが⼊ったら…
    • 開発環境を構築してもらう。
    • 次に開発⽅針を伝える。
    • 会社のルール
    • スタイルガイドの把握（Rubyもあります）
    • チームのルール
    • リーダブルコード、Team Geekを読んでもらう
    • クライアントの構造の把握（サーバーはRailsなので説明は
    少ない）
    64
    

    View Slide

65. おわりに
    65
    

    View Slide

66. まとめ
    • あんスタにおけるクライアントの開発⽅針の⼀部を紹介しま
    した。
    • コードを書く際には「新しく⼊ったメンバーがわかりやす
    いこと」を重要視していて、そのために標準や流儀に従う
    ことを⼤切にしています。
    • 開発コミュニケーションではHRTを意識するようにしてい
    ます。
    • Unityに関する具体的な実装についても⼀部紹介しました。
    • Unityは様々なゲームに対応するため、汎⽤性の⾼いツー
    ルとなっているので、開発効率を上げるためには、⽬的と
    なるアプリの仕様に合わせて規約を作り、アプリの⾃由度
    が失われない範囲で効率化するようにしています。
    66
    

    View Slide

67. Happy Elements株式会社が今後強みとしたいこと
    • ウェブのソーシャルゲームからスタートしたということ
    もあり、エンジニアもウェブエンジニアばかりです。
    • コンシューマー経験者は⼀⼈もいませんが、Unityに
    ついても⾃分たちなりに頑張っています。
    • サーバーサイドはある程度強いため、中⻑期ではUnity
    が⾃社の強みとなるように取り組んでいきます。
    • あくまでゲームありきではありますが、開発のクオ
    リティでアプリの価値をひっぱっていけるようにし
    たいと考えています。
    67
    

    View Slide

68. ご静聴ありがとうございました！
    • ⼀緒にゲームを作る仲間を募集中！
    • Unityでゲームを作りたい⼈、happyelements.co.jp か
    ら応募お願いします！
    68
    

    View Slide