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

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

unitydojo
November 05, 2016
3.8k

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

unitydojo

November 05, 2016
Tweet

More Decks by unitydojo

Transcript

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

    View full-size slide

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

    View full-size slide

  3. ⾃⼰紹介
    3

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  17. 開発チーム
    17

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

  21. 開発⽅針
    21

    View full-size slide

  22. 会社の統⼀ルール
    22

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  31. チームのルール
    31

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  49. アプリの起動時の流れの明確化
    50
    • 1つのScriptに順番に処理(AddComponent)を書く
    • メリット
    • わかりやすい
    • 必ず書いた順番で実⾏される
    • 例えば初期化後にAutoControllerActivatorをアタッチした

    • デメリット
    • Unity的にHierarchyで「Add Component」することが標準的
    で、通常はそういう期待をするように感じる
    処理の順序をどこで制御するか問題

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  64. おわりに
    65

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide