Download as PDF, PPTX
KLabのゲーム開発を支える開発環境
- 1.
- 2.
- 3.
- 4.
- 5. 5 業界でよくある開発環境 ● 共用サーバーを1台用意 ● 各作業者がローカルで開発・デバッグ ●出来たものを共用サーバーへ反映 ● 複数人の作業を共用サーバーで組み合わ せて確認 共用サーバー
- 6.
- 7. 7 KLabでの開発環境 ● 1人1台サーバーを用意し各々の作業を自 分専用のサーバーで行う ● この1人1台に用意されたサーバーの仕組 みをKLabではgodと呼んでいる ●規模の大きいプロジェクトでは、 100台以上のgodを使っていることも god1 god3 god2
- 8.
- 9. 9 godとは ● オンデマンドで増やすことのできるAmazon EC2を用いたサー バー環境のこと ●g on demandのイニシャルを組み合わせたもの ○ Gはプロジェクト名のイニシャル。神ではないよ ● KLabではローカル仮想マシンでの環境構築を廃止し、 1人1台用意されたgodにそれぞれsshで接続し開発を 行なっている 注) 全てのプロジェクトがこの環境で開発しているわけではありません
- 10. 10 godのいいところ ● 自分専用のサーバーなので、他の人への 影響を気にせず好きなペースで更新を反映 できる ● 自分の担当外のコードを触ってもOK ●コードやマスタ(ゲームに必要なデータ)の自 動生成を簡単なコマンドで実行可能 ● テストも簡単なコマンドで実行可能 god1 god3 god2
- 11. 11 godのいいところ ● オンデマンドなので必要な時にサーバーを 起動し不要になったら停止させられる Slack上でbotに指定することで可能 起動: @godstart 停止: @god stop 初期化: @god terminate ● 毎日22:00に自動停止する機能も搭載 god1 god3 god2
- 12.
- 13. 13 なぜgodが必要なのか ● KLab独自の設計思想による開発を行うのにgod環境の相性が 良かった ● デザインパターンとしてはMVVMと似た設計 ●クライアントとサーバーが密結合した設計方針 ● クライアントとサーバーが並行して開発を行う
- 14. 14 ViewとModelの 仲介 ViewModel ● クライアントがViewとViewModelの開発を担当 ● サーバーがModelとDB周りの開発を担当 画面表示・操作 各種データ処理 View Model DB クライアント サーバー
- 15.
- 16. 16 なぜgodが必要なのか ● クライアントとサーバーが密結合した開発体制 = クライアントとサーバーの環境が合わないと 正常に動作しないことが多い ●しかし開発者それぞれの作業過程で求める環境が異なること が多い ⇒ 従来の共用サーバー開発だと作業が止まる人が発生 ⇒ 自分の求める環境をgodに反映して作業可能
- 17.
- 18.
- 19. 19 なぜgodが必要なのか ● エンジニア以外のプランナー・デザイナーも使用 している ⇒ ローカル仮想マシンだと、 トラブルが発生した際の開発のフォローが大変 ● godはEC2にあるので誰でもアクセス可能 ⇒ エンジニアのヘルプが容易
- 20.
- 21.
- 22.
- 23.
- 24. 24 1. 設計を決めてMock(ダミーデータ)を用意する ○ クライアントとサーバーで相談して認識を合わせる ⇒ここで設計がずれてしまうと手戻りが発生するので重要 ○ 設計できたら仮データを取得できるようMockを実装する ⇒ クライアント・サーバーが それぞれMockを使って並行作業 godを使った開発例(エンジニア編)
- 25. 25 2. サーバー ● Mockの要件を満たすような、 テーブル設計などのDB周りや Modelロジックを実装 2.クライアント ● ゲーム画面のUIや操作ロジックを 実装 ● Mockで動作確認も可能 godを使った開発例(エンジニア編) Mockがあるのでクライアント・サーバー間の 作業は干渉しない
- 26. 26 3. Mockを本物のデータへ繋ぎ込み ○ 最初に用意したMockを消して、サーバーで用意した 本物のデータへ差し替え ○godの自動生成コマンドを使えば複雑な対応は不要 ⇒ クライアント・サーバーが並行作業したため、 足並みを揃えなくても本物のデータで動作する godを使った開発例(エンジニア編)
- 27.
- 28. 28 godを使った開発例(プランナー編) ● 未来のイベントデータを作成 ● 手順 1.マスタ(イベントデータ)を用意 2. Gitでブランチを作成しcommit 3. 自分のgodへcommit内容を反映 4. Unityから自分のgodへ接続し動作を確認 もしエラーなどが起きたら開発者に相談 5. 問題がなければPRを作成⇒マージして完了 god
- 29.
- 30.
- 31.
- 32. 32 godを使った開発例(個人環境以外での用途) ● デイリービルド用god ○ 最新の開発環境の動作確認を行うための環境 ●ステージング環境用god ○ 本番反映を行う直前の最終の動作確認を行うための環境 ● 版権元確認用god ○ KLabでは他社IPを使ったゲームが多いため、 版権元に提供する環境を用意しているプロジェクトもある
- 33.
- 34. 34 godを使った開発例(平尾編) ● 自分専用のgodがあるので色々と遊べる勉強できる ● 自分のメイン業務をする傍ら、担当外のコードを触って実際の ゲームの動作も確認することが可能 ⇒私はクライアントだけどサーバーにも興味あるから、 ちょっと触って実際の動作がどうなるか試してみよう！
- 35. 35 ● 実際に私がやったこと 1. サーバー側デバッグツールの改修 2.サーバーコードのリファクタリング 3. 新機能の実装 4. プランナーのお手伝い godを使った開発例(平尾編)
- 36. 36 1. サーバー側デバッグツールの改修 ○ python未経験だったのでコードを読んでみた ○ツール内で修正できそうな箇所を発見・修正 ○ 修正してPRを出してサーバー担当の人がレビュー ○ デバッグ用なので本番影響もなく練習に最適 godを使った開発例(平尾編)
- 37. 37 2. サーバーコードのリファクタリング ○ ちょっとpythonが書けるようになったので、 本番コードも触ってみる ○あくまで新規実装は行わず既存コードの修正のみ ○ 本番影響はあるが既存コードなので練習に godを使った開発例(平尾編)
- 38. 38 3. 新機能の実装 ○ 新機能を提案して実装の許可は出たが人員不足で保留 ○新機能の仕様書をプランナーの代わりに用意 ○ クライアントもサーバーも1人で実装 godを使った開発例(平尾編)
- 39. 39 4. プランナーのお手伝い ○ プランナーが人員不足なのでマスタデータ入力のヘルプ ○一応エンジニアなので、ただヘルプするだけではなく 併せて業務改善も実施 ○ 1.5人日程度かかっていた作業を1時間程度に改善 godを使った開発例(平尾編)
- 40.
- 41. 41 ● 従来の開発環境を思い切って変えてみたら メリットがたくさん ● KLabでは1人1台開発サーバーを完備 ●他の作業者の進捗に影響されず、自分のペースで作業可能 ● リモートワーク主流の昨今では、 ローカル仮想マシンよりもEC2上のgodの方が便利 まとめ