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

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