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

Happy Elements Make The World Happy! あんさんぶるスターズ！ の開発方針 Happy Elements株式会社 草苅 景 1

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

自己紹介 3

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

Happy Elements ・本社は北京 ・代表作「Anipop」 ・2015年の中国のiOSゲームで、ダウンロード数1位、 月間アクティブユーザー数1位、収益10位。 ・パブリッシャーとしては、2015年の中国のiOSゲームで、 ダウンロード数4位、収益7位。（※App Annie調べ） 2015年のトップゲーム：中国 iOSダウンロード数 順位 ゲーム名 パブリッシャー 1 Anipop Happy Elements 2 Landlord Poker Tencent 3 We Fire Tencent, Garena Online, Netmarble 4 Asphalt 8: Airborne Gameloft 5 Craz3 Match Tencent 2015年のトップゲーム：中国 iPhone 月間アクティブユーザー数 順位 アプリ名 パブリッシャー 1 Anipop Happy Elements 2 Landlord Poker Tencent 3 Craz3 Match Tencent 4 WeChat Dash Tencent 5 Clash of Clans Supercell 5

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

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

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

Happy Elements株式会社 ・108名（社員63、アルバイト45） ・2016年3月時点 ・イラストレーターの割合が高い ・おそらく同業他社と比較して女性比率が高い ・おそらく同業他社と比較してプランナー、エンジニア数が少ない ・下記表の（）は数字内のアルバイト数 ・現在、アプリは5ライン 4(1) 4 18(8) 26(8) 56(28) ■社長室 ■プランナー ■エンジニア ■デザイナー ■サポート 53 55 ■男性 ■女性 9

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

目次. Agenda ・自己紹介 ・あんさんぶるスターズ！とは ・開発方針 ・おわりに 11

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

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

Google Play 2015年ベストゲーム50に選出 ・GCRESTさんの「夢王国と眠れる100人の王子様」（夢 100）と同時に選出。 ・女性向けゲームが選出されるのは初めて。 Google Play「ベストゲーム」受賞作品に初の女 性向けゲーム、『夢100』『あんスタ』快挙果た す INSIDEより引用 2015年12月5日(土) 22時00分 http://www.inside-games.jp/article/2015/12/05/93714.html 14

App Storeのトップセールス1位に ・2016年9月15日App Storeのトップセールス1位。 ・リリースから約一年半。 15

現在のチーム規模 ・エンジニア×4(+2) ・デザイナー×1(+1) ・プランナー ・コンテンツ×2、コンテンツアシスタント×1(+1) ・レベルデザイン×1、プロモーション×1、グッズ×1 ・イラストレーター×10(+1) ・Live2Dアニメーター×2（イラスト兼任） ・Sprite Studioアニメーター×2 ・社外発注（シナリオ、サウンド、一部背景） 社内合計: 30人 ※（）は学生など非常勤のアルバイト数 16

開発チーム 17

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

開発環境 ・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

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

開発方針 21

会社の統一ルール 22

開発方針 ・会社の統一ルール ・Unity(C#)の利用 ・スタイルガイド ・チームのルール ・前提知識の統一 ・開発ルールの統一 23

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

Unityを選択した理由2 Unity Cocos2d-x 開発効率 ◎ 〇 社内ノウハウ 〇 × 社外ノウハウ 〇 △ パフォーマンス ◎ 〇 周辺ツール 〇 △ 動的アップデート × 〇 料金 × 〇 自由なソフトウェア × 〇 ・開発言語はUnityはC#、Cocos2d-xは基本的にLuaを想定。 ・開発効率についてはCocos2d-xはC++で〇、Luaで△という 評価。 ・2Dのパフォーマンス測定でも計測時はUnityに軍配。 25

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

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

開発方針 ・会社の統一ルール ・Unity(C#)の利用 ・スタイルガイド ・チームのルール ・前提知識の統一 ・開発ルールの統一 28

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

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

チームのルール 31

開発方針 ・会社の統一ルール ・Unity(C#)の利用 ・スタイルガイド ・チームのルール ・前提知識の統一 ・開発ルールの統一 32

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

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

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

開発方針 ・会社の統一ルール ・Unity(C#)の利用 ・スタイルガイド ・チームのルール ・前提知識の統一 ・開発ルールの統一 36

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

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

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

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

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

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

GameKit 43

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

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

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

あんスタのクライアント構造 名称 役割 例 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

画面遷移と画面のライフサイクルを管理するクラス ・画面遷移を管理するクラスAppApplication。 ・アプリの処理は必ずここから開始される。 ・必ずAppApplicationクラス経由で画面遷移を行う ・AppApplication.SwitchControllerを使用 ・初回の画面起動のみAutoControllerActivatorクラス がControllerのActivateを行う 名称 説明 AppApplication 画面遷移と画面のライフサイクルを管理 ControllerActivator Controllerの初回起動を実行 48

初回起動時 初回のみControllerが最初から あるため、Activatorが必要 49

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

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

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

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

画面遷移 SplashController AppApplication.SwitchController<TitleController>(param, false, Loading.LoadingViewType.None); GKUIRoot以下にある ControllerがSwitch 54

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

例.カード詳細画面1 PrefabControllerを 継承したController ControllerとPrefabが 1:1で紐付いている 56

例.カード詳細画面2 ViewModelを使って データを表示 57

例.カード詳細画面3 public override void OnWillAppear(ControllerParameter controllerParameter, Action<IControllerTransitionStatus> completion) { this.controllerParameter = controllerParameter; var request = new CardDetailRequest(controllerParameter.GetValue<int>(ParameterKey.UserCardID)); CommunicateServerOnWillAppear(request, (_response) => { cardDetailResponse = _response as CardDetailResponse; assets = cardDetailResponse.AssetDictionary; userCard = cardDetailResponse.UserCard; character = cardDetailResponse.Character; growthTotalPoint = cardDetailResponse.GrowthTotalPoints; userCardViewModel.AssetDictionary = assets; userCardViewModel.UserCard = userCard; cardDetailTitle.UpdateView(userCard); }, completion); } public override void OnAppear() { SetAlbumOrPlayableState(userCard.InAlbum, character); SetEvolveState(userCard.Evolution, userCard.IsNotEvolvedImage); } 58

例.カード詳細画面4 CardViewModelは いろいろな画面で 使い回せる 59

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

開発用Sceneの起動 CardDetailScene Controller以下が Prefabになっている ControllerActivatorをカスタ マイズして、card_id=746 を指定して表示 61

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

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

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

おわりに 65

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

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

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