Slide 1
Slide 1 text
あんさんぶるスターズ！
の開発⽅針
1
Happy Elements株式会社
草苅 景
Slide 2
Slide 2 text
資料について
• 資料は後ほど公開させて頂きます
2
Slide 3
Slide 3 text
⾃⼰紹介
3
Slide 4
Slide 4 text
⾃⼰紹介
• 草苅 景（くさかり けい）
• @kusakari
• Happy Elements株式会社
• チーフエンジニア
• あんさんぶるスターズ！グループリーダー
4
Slide 5
Slide 5 text
Happy Elements
• 本社は北京
• 代表作「Anipop」
• 2015年の中国のiOSゲームで、ダウンロード数1位、
⽉間アクティブユーザー数1位、収益10位。
• パブリッシャーとしては、2015年の中国のiOSゲームで、
ダウンロード数4位、収益7位。（※App Annie調べ）
5
Slide 6
Slide 6 text
Happy Elements株式会社
• 京都市下京区
• 11⽉1⽇の移転を機に京都オフィスは「カカリアスタジ
オ」という名称になりました。
• 東京は経理系のみ。
• 代表作
• メルクストーリア -癒術⼠と鈴のしらべ-
• Google Play ベストゲーム2014
• あんさんぶるスターズ！
• Google Play ベストゲーム2015
どちらもUnity製です！
6
Slide 7
Slide 7 text
Happy Elements株式会社
• Make The World Happy
• ゲームの提供を通じて世界を幸せに
• クリエイターにとって理想的な環境を⽬指す
• ⼀⼈⼀⼈の個性を最⼤限活かせる組織
• チームの裁量が⼤きいボトムアップ型組織（全体最
適＜チーム最適）
7
Slide 8
Slide 8 text
Happy Elements株式会社
• 2010年設⽴。
• 独⾃に⽇本市場向けにアプリを開発。
• 中国が⽇本に、あるいは⽇本が中国に展開の際には
プロモーションなどで協⼒。
8
Slide 9
Slide 9 text
Happy Elements株式会社
9
55
53
உੑ
ঁੑ
4
18(8)
26(8)
56(28)
4(1)
ࣾࣨ
ϓϥϯφʔ
ΤϯδχΞ
σβΠφʔ
αϙʔτ
• 108名（社員63、アルバイト45）
• 2016年3⽉時点
• イラストレーターの割合が⾼い
• おそらく同業他社と⽐較して⼥性⽐率が⾼い
• おそらく同業他社と⽐較してプランナー、エンジニア数が少ない
• 下記表の（）は数字内のアルバイト数
• 現在、アプリは5ライン
Slide 10
Slide 10 text
Happy Elements株式会社
• ⼀緒にゲームを作る仲間を募集中！
• happyelements.co.jp から応募お願いします！
10
Slide 11
Slide 11 text
⽬次.
A g e n d a
11
• ⾃⼰紹介
• あんさんぶるスターズ！とは
• 開発⽅針
• おわりに
Slide 12
Slide 12 text
あんさんぶるスターズ！
とは
12
Slide 13
Slide 13 text
あんさんぶるスターズ！（あんスタ！）とは
13
項⽬ 内容
ゲーム内容 スマートフォン向け「アイドル育成プロデュースゲーム 」
ダウンロード数 累計200万ダウンロード（2016年9⽉）
リリース⽇ Google Play版2015年4⽉28⽇
App Store版 2015年5⽉1⽇
Slide 14
Slide 14 text
Google Play 2015年ベストゲーム50に選出
• GCRESTさんの「夢王国と眠れる100⼈の王⼦様」（夢
100）と同時に選出。
• ⼥性向けゲームが選出されるのは初めて。
14
INSIDEΑΓҾ༻
http://www.inside-games.jp/article/2015/12/05/93714.html
Slide 15
Slide 15 text
App Storeのトップセールス1位に
15
• 2016年9⽉15⽇App Storeのトップセールス1位。
• リリースから約⼀年半。
Slide 16
Slide 16 text
現在のチーム規模
• エンジニア×4(+2)
• デザイナー×1(+1)
• プランナー
• コンテンツ×2、コンテンツアシスタント×1(+1)
• レベルデザイン×1、プロモーション×1、グッズ×1
• イラストレーター×10(+1)
• Live2Dアニメーター×2（イラスト兼任）
• Sprite Studioアニメーター×2
• 社外発注（シナリオ、サウンド、⼀部背景）
16
※ʢʣֶੜͳͲඇৗۈͷΞϧόΠτ
ࣾ߹ܭ: 30ਓ
Slide 17
Slide 17 text
開発チーム
17
Slide 18
Slide 18 text
開発チーム
• リリース前のエンジニア数
• 社員×3（草苅含む）
• 学⽣アルバイト×3
• リリース後のエンジニア数
• 社員×4 （草苅含む）
• 学⽣アルバイト×2〜3
• 得意、苦⼿はあるにしても、基本的に誰でもクライアン
ト（Unity）、サーバー（Ruby on Rails）両⽅を対応で
きるようにしています。
18
Slide 19
Slide 19 text
開発環境
• 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
Slide 20
Slide 20 text
チーム内の情報共有
• Slack
• チーム内コミュニケーション
• GitHub
• リポジトリー、PRコードレビュー
• GitHub Issue
• タスク管理
• Qiita:Team
• 全社情報共有
20
Slide 21
Slide 21 text
開発⽅針
21
Slide 22
Slide 22 text
会社の統⼀ルール
22
Slide 23
Slide 23 text
開発⽅針
• 会社の統⼀ルール
• Unity(C#)の利⽤
• スタイルガイド
• チームのルール
• 前提知識の統⼀
• 開発ルールの統⼀
23
Slide 24
Slide 24 text
Unityを選択した理由1
• 2013年12⽉〜2014年1⽉くらいに調査。
• Unityの⽅が情報量が多かった。
• ウェブ上もそうだが、社内にも2アプリ分（マイポ
ケットバー、メルクストーリア）の実績があった。
• Cocos2d-x （特にC++以外）は情報が少ない上に、
中国語だったり。
• 3.x への切り替えのタイミングであったこともマイナス要素。
• 周辺ツールの完成度
• Cocos2d-xは個⼈がメンテしているものもあり、不
安要素の⼀つ。
24
Slide 25
Slide 25 text
Unityを選択した理由2
25
Unity Cocos2d-x
։ൃޮ ˕ ˓
ࣾϊϋ ˓ º
ࣾ֎ϊϋ ˓ ˚
ύϑΥʔϚϯε ˕ ˓
पลπʔϧ ˓ ˚
ಈతΞοϓσʔτ º ˓
ྉۚ º ˓
ࣗ༝ͳιϑτΣΞ º ˓
• 開発⾔語はUnityはC#、Cocos2d-xは基本的にLuaを想定。
• 開発効率についてはCocos2d-xはC++で○、Luaで△という
評価。
• 2Dのパフォーマンス測定でも計測時はUnityに軍配。
Slide 26
Slide 26 text
Unityを選択した理由3
• ⾃動アップデート
• Cocos2d-xの場合、Luaで実装するとアプリを丸ごと
⼊れ替えられるのが⼀つのメリットだった。
• 各OSにアプリの⾃動アップデートが追加され、アプ
リのアップデートによる利⽤ユーザーの減少の⼼配
が少なくなった。
• 実際の使⽤感
• ⾃由なソフトウェア主義者2⼈に、実際にデモゲーム
を両⽅で作ってもらったところ、⼆⼈ともUnityの⽅
が作りやすいと回答した。
26
Slide 27
Slide 27 text
Unityを選択した理由4
• 2014年1⽉の段階では、Cocos2d-x を使うメリットは
「⾃由なソフトウェア」であるということくらい。
• 開発者としてそこを⼤事にしたい気持ちもあったが、
ネイティブアプリ開発について、技術的に先⾏して
いる他社を追いかけている段階で、そこにこだわっ
ても仕⽅がないと感じた。
• プロジェクトによって選択するという案もあったが、全
社的にUnityで統⼀。
27
Slide 28
Slide 28 text
開発⽅針
• 会社の統⼀ルール
• Unity(C#)の利⽤
• スタイルガイド
• チームのルール
• 前提知識の統⼀
• 開発ルールの統⼀
28
Slide 29
Slide 29 text
スタイルガイド1
• 独⾃のC#コーディング規約
• 以下の3つがベース
• Microsoft C#コーディング規約
• Microsoft クラスライブラリ開発のデザインガイドライン
• Unity Gems Coding Conventions
• Not Found…
• 会社標準とすることができる基本的な部分のみ記述
• 独⾃規約というよりは重要なポイントだけを抜粋。
29
Slide 30
Slide 30 text
スタイルガイド2
• 以前所属していた会社ではJavaの独⾃コーディング規約
• 転職先では「SunのCoding Conventionsで」
• わかりやすくて世界標準
• 標準があるならそれに従う
• ⾔語やフレームワークの流儀に従った書き⽅を推奨
• C#にRubyの流儀を持ち込まない
• 例えば、to_sではなくToString
• ⾔語を⼀つしかしらないエンジニアはそれを盲信し
がち
30
Slide 31
Slide 31 text
チームのルール
31
Slide 32
Slide 32 text
開発⽅針
• 会社の統⼀ルール
• Unity(C#)の利⽤
• スタイルガイド
• チームのルール
• 前提知識の統⼀
• 開発ルールの統⼀
32
Slide 33
Slide 33 text
前提知識の統⼀1
33
• より良いコードを書くためのシンプルで実践的なテクニック
例えば…
• コードは他の⼈が最短時間で理解できるように書かなければ
いけない
• ⼀貫性のあるスタイルは「正しい」スタイルよりも⼤切
• コードからすぐにわかることをコメントに書かない
• ひどい名前はコメントを書かずに名前を変える
• 制御フローはできるだけ「⾃然」にする
• ⾏数を短くするよりも、他の⼈が理解するのにかかる時間を
短くする
• 最も読みやすいコードは、何も書かれていないコード
リーダブルコード
Slide 34
Slide 34 text
前提知識の統⼀2
34
• HRT（ハート）
• 謙虚（Humility）
• 尊敬（Respect）
• 信頼（Trust）
• あらゆる⼈間関係の衝突は、謙虚・尊敬・信頼の⽋如に
よるものだ。
• 円滑な開発コミュニケーションのための⼼がけ
• 特にSlackやGitHub上でのコードレビュー時
Team Geek
Slide 35
Slide 35 text
前提知識の統⼀3
• あんスタチームではエンジニアはこの2冊を初めに読ん
でもらうようにしている。
• 前提が⼀致していない状態で、同じゴールに向かうこと
は⾮常に難しい。
• 「リーダブルコード（Team Geek）に書いてあったで
しょ」という形でスムーズにコミュニケーションが取れ
るようになることには⼤きな価値がある。
35
Slide 36
Slide 36 text
開発⽅針
• 会社の統⼀ルール
• Unity(C#)の利⽤
• スタイルガイド
• チームのルール
• 前提知識の統⼀
• 開発ルールの統⼀
36
Slide 37
Slide 37 text
開発ルールの統⼀
• ⼀番⼤事なことを決める
• 決定者を決める
• エディターの統⼀
• クライアントの構造
37
Slide 38
Slide 38 text
開発ルールの統⼀
38
• 新しく⼊ったメンバーにわかりやすいことが最重要
• 基本的にリーダブルコードに従う
• 想定スキルはUnity C#を理解しているレベル
• 初⼼者に合わせるわけではなく、Unity経験者がチームに加
わったときにわかりやすいことが重要
• 標準や⾔語の流儀に従う
• Unityらしさ、C#らしさを⼤事にする
• 負債を残さない
• ⾃分が⼀番やりやすいやりかたは、⼀般的ではないかもしれ
ない
⼀番⼤事なことを決める
Slide 39
Slide 39 text
開発ルールの統⼀
39
• 基本的に実装の⽅向性は実装者に任せているが、コード
レビュー時などにどうしても好みの問題となることがあ
る。
• 好みの問題となったら、最終的に誰が判断するのかは予
め決めた上で周知しておく。
決定者を決める
Slide 40
Slide 40 text
開発ルールの統⼀
40
• エディターを統⼀しないと、コーディングスタイルを合
わせる難易度が⾼くなる。
• チームはMonoDevelopで統⼀。
• policyファイルも共有。
エディターの統⼀1
Slide 41
Slide 41 text
開発ルールの統⼀
41
• 会社のスタイルガイド
• ハンガリアン記法を使わない
• 右辺から型があきらかな場合はvarを使う
• MonoDevelopを使⽤していれば型はすぐにわかる
• リーダブルコード
• ⻑い名前を⼊⼒するのは問題じゃない
• 短い命名にこだわる必要はない
• 「⼊⼒しにくい」は問題にならない
• 例えば、このあたりの話も、前提としてエディターが統⼀で
きていなければ、話が噛み合わない場合もある
• スタイルガイドを守れていれば、エディターは⾃由。
エディターの統⼀2
Slide 42
Slide 42 text
開発ルールの統⼀
42
• GameKitという開発基盤を作って利⽤。
• 元々全社で使うためにあんスタで開発を進めていた
が、⼤きくなりすぎたため必要最低限のコア部分の
みに縮⼩。
• 結局、⼀部のアプリでのみ利⽤。
• 開発効率を上げるためには、開発基盤が必要だとは
考えているものの、全社で使うには成熟度が⾜りな
い。
クライアントの構造
Slide 43
Slide 43 text
GameKit
43
Slide 44
Slide 44 text
Unityを使った開発でありがちなこと
• ⾃由度が⾼すぎて全社で利⽤するような共通化がし⾟い
• 同じアプリ内でも、開発者ごとに別々のコードに
• 例えば、画⾯を切り替える⽅法は？ボタンが押されたときの
処理はどこに記述する？
• エントリーポイントがわかりづらい
• 処理の流れが追いづらい
• Sceneの切り替えが重い
• 5.xでは改善？
• 分業開発効率
• SceneやPrefabがコンフリクトしがち
44
Slide 45
Slide 45 text
GameKitのコンセプト
• Railsの考え⽅を参考に開発効率を上げる
• 設定より規約を重視（Convention over Configuration)
• 規約を作ることで、開発効率・メンテナンス効率を上げる
• 例えば、RailsならURLとソースコードが紐付いている
• /cards/create
• CardsController#create
• GameKitでは画⾯とソースコードが紐付くように
• Controller名からソースコード、Prefabがすぐにわかる
• RailsはMVCだが、GameKitではMVVMという構造
45
Slide 46
Slide 46 text
GameKitが解決すること
• アプリ構造の（⼀定の）統⼀。
• MVVM。
• 画⾯遷移と画⾯のライフサイクルの管理。
• アプリ起動時の流れの明確化。
• 画⾯遷移をわかりやすく。
• 画⾯のライフサイクルをわかりやすく。
• サーバー連携
• サーバーデータとのスムーズな連携。
• 通信暗号化。
46
Slide 47
Slide 47 text
あんスタのクライアント構造
໊শ ׂ ྫ
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
Slide 48
Slide 48 text
画⾯遷移と画⾯のライフサイクルの管理するクラス
• 画⾯遷移を管理するクラスAppApplication。
• アプリの処理は必ずここから開始される。
• 必ずAppApplicationクラス経由で画⾯遷移を⾏う
• AppApplication.SwitchControllerを使⽤
• 初回の画⾯起動のみAutoControllerActivatorクラス
がControllerのActivateを⾏う
48
໊শ આ໌
AppApplication ը໘ભҠͱը໘ͷϥΠϑαΠΫϧΛཧ
ControllerActivator ControllerͷॳճىಈΛ࣮ߦ
Slide 49
Slide 49 text
初回起動時
49
ॳճͷΈController͕࠷ॳ͔Β
͋ΔͨΊɺActivator͕ඞཁ
Slide 50
Slide 50 text
アプリの起動時の流れの明確化
50
• 1つのScriptに順番に処理（AddComponent）を書く
• メリット
• わかりやすい
• 必ず書いた順番で実⾏される
• 例えば初期化後にAutoControllerActivatorをアタッチした
い
• デメリット
• Unity的にHierarchyで「Add Component」することが標準的
で、通常はそういう期待をするように感じる
処理の順序をどこで制御するか問題
Slide 51
Slide 51 text
アプリの起動時の流れの明確化
51
• Script Execution Order
• メリット
• Unityの流儀に沿っている
• デメリット
• Unity初⼼者にはわかりづらい
→Unityは理解しているという前提であるべき形に
処理の順序をどこで制御するか問題
Slide 52
Slide 52 text
Controllerの仕組み1
• 画⾯（Prefab）とController（Script）が1対1で対応
• PrefabControllerを継承してControllerを作成
• Controllerを⾒れば、その画⾯の処理の流れがわかる。
• 例えば、ボタンが押されたときの処理は基本的にコントロー
ラーに記述する。
• ControllerとPrefabの紐付けはデフォルトはクラス名
だが、ディレクトリー指定やPrefab名指定など柔軟
に対応可能。
• 処理は基本的にControllerのライフサイクルに沿った
Callbackメソッド内に記述する。
52
Slide 53
Slide 53 text
Controllerの仕組み2
• AppApplication.SwitchController()
が実⾏されると画⾯遷移時にGameKitが⾃動で
Resources/Prefabs/TitleController.prefabをインスタ
ンス化する
• 画⾯遷移時に該当ControllerのCallbackが呼ばれる
• 必要なアセットなども⾃動ロードされる
• 起動失敗時には呼び出し元の起動失敗Callbackが呼
ばれる
• SwitchされたControllerは破棄される
53
Slide 54
Slide 54 text
画⾯遷移
AppApplication.SwitchController(param, false,
Loading.LoadingViewType.None);
54
SplashController
GKUIRootҎԼʹ͋Δ
Controller͕Switch
Slide 55
Slide 55 text
Controllerのライフサイクル
• OnWillAppear(ControllerParameter controllerParameter,
Action completion);
• 画⾯描画の準備段階
• completion(ControllerTransitionStatus.Completed);呼
び出しで完了を知らせる。
• OnAppear();
• 画⾯描画の準備ができたとき
• OnDisappear();
• Controllerが削除されるとき
• OnCancelWillAppear();
• 描画がキャンセルされたとき
55
Slide 56
Slide 56 text
例.カード詳細画⾯1
56
ControllerͱPrefab͕
1:1Ͱඥ͍͍ͯΔ
ΠϯελϯεԽ
PrefabControllerΛ
ܧঝͨ͠Controller
Slide 57
Slide 57 text
例.カード詳細画⾯2
57
ViewModelΛͬͯ
σʔλΛදࣔ
Slide 58
Slide 58 text
例.カード詳細画⾯3
58
Slide 59
Slide 59 text
例.カード詳細画⾯4
59
CardViewModel
͍Ζ͍Ζͳը໘Ͱ
͍ճͤΔ
Slide 60
Slide 60 text
画⾯ごとの開発
• 画⾯ごとに開発⽤のSceneを作って開発。
• 他の開発者にあまり影響されることなく開発できる。
• 基本的にすべての画⾯がSceneになっており、単独
で起動可能。
• アプリは単⼀Scene(MainScene)となっており、
Controllerが切り替わるだけでSceneは切り替わらない。
60
Slide 61
Slide 61 text
開発⽤Sceneの起動
61
CardDetailScene
ControllerActivatorΛΧελ
ϚΠζͯ͠ɺcard_id=746
Λࢦఆͯ͠දࣔ
ControllerҎԼ͕
Prefabʹͳ͍ͬͯΔ
Slide 62
Slide 62 text
その他のGameKitの提供クラス例
• HttpClient
• .Netの⼀番標準的な通信クラスであるHttpClientを模して
作ったクラス
• Unityが.Net 4.0に対応したとき、可能な限り切り替えや
すいように実装
• 内部実装はUniRxとThreadNinjyaを切り替え可能
• UniRxを使いたかったがUnityのバージョンアップ時に動かなく
なる場合があり、リスクが⾼かったため切り替え可能に
• GKHttpClient
• ⾃動暗号化と⾃動シリアライズ化に対応
• シリアライズはJson、MessagePackに対応
• ⾃動で暗号化されるため、クライアント開発者は暗号化・
復号化を意識しない。
62
Slide 63
Slide 63 text
会社で統⼀して（いる|いこうとしている）部分
63
• 通信暗号化（GameKit組み込み）
• 対応済みだが改善の余地あり
• UUID の⽣成⽅法
• 統⼀されているがライブラリー化されていない
• データ引き継ぎ（Game Center、Saved Game）
• ⽅法含め改善の余地あり
• 課⾦（Google Play、App Store）
• Unity IAP（Unity5.3以降）に移⾏するかも。
• 弊社の新しいアプリでは利⽤。
汎⽤ライブラリー
Slide 64
Slide 64 text
開発⽅針を伝える
• 新しいエンジニアスタッフが⼊ったら…
• 開発環境を構築してもらう。
• 次に開発⽅針を伝える。
• 会社のルール
• スタイルガイドの把握（Rubyもあります）
• チームのルール
• リーダブルコード、Team Geekを読んでもらう
• クライアントの構造の把握（サーバーはRailsなので説明は
少ない）
64
Slide 65
Slide 65 text
おわりに
65
Slide 66
Slide 66 text
まとめ
• あんスタにおけるクライアントの開発⽅針の⼀部を紹介しま
した。
• コードを書く際には「新しく⼊ったメンバーがわかりやす
いこと」を重要視していて、そのために標準や流儀に従う
ことを⼤切にしています。
• 開発コミュニケーションではHRTを意識するようにしてい
ます。
• Unityに関する具体的な実装についても⼀部紹介しました。
• Unityは様々なゲームに対応するため、汎⽤性の⾼いツー
ルとなっているので、開発効率を上げるためには、⽬的と
なるアプリの仕様に合わせて規約を作り、アプリの⾃由度
が失われない範囲で効率化するようにしています。
66
Slide 67
Slide 67 text
Happy Elements株式会社が今後強みとしたいこと
• ウェブのソーシャルゲームからスタートしたということ
もあり、エンジニアもウェブエンジニアばかりです。
• コンシューマー経験者は⼀⼈もいませんが、Unityに
ついても⾃分たちなりに頑張っています。
• サーバーサイドはある程度強いため、中⻑期ではUnity
が⾃社の強みとなるように取り組んでいきます。
• あくまでゲームありきではありますが、開発のクオ
リティでアプリの価値をひっぱっていけるようにし
たいと考えています。
67
Slide 68
Slide 68 text
ご静聴ありがとうございました！
• ⼀緒にゲームを作る仲間を募集中！
• Unityでゲームを作りたい⼈、happyelements.co.jp か
ら応募お願いします！
68