J.M

# プロジェクト概要 - Unity・C#・Go・AWSを用いた3DCGソーシャルゲームの開発 - 自由度の高い船舶のクラフトと造船した艦艇での対戦がテーマ (資料01) # 開発チーム規模(リリース時) - 約30名(内エンジニア8名程度) # コミット概要 新卒入社して初めてアサインされたプロジェクトです。約3年間、リリースまでの開発からその後の運用まで関わりました。最初の2年ほどはこのゲームアプリのメイン機能のひとつである「造船機能」のクライアントサイドの開発ほぼ全てを一人で任されました。造船機能実装には、第二次世界大戦時の旧日本海軍の船舶の各パーツに関する知識が必要だったので、プログラミングと並行してそちらの勉強もしました。造船機能はユーザーが快適に視認することが求められたため、プランナー・3DCGデザイナーと連携してシェーダーの記述も行いました。リリース後の約半年間はサーバーサイドエンジニアとして関わりました。もともとクライアントサイドを経験しての配置だったため、一つの機能をクライアント・サーバの両面任されました。そのコミットの結果として社内MVPとして表彰されることもありました。 # 主な実装内容 造船機能画面クライアントサイドのほぼ全ての開発 【概要】 3DCGモデルで表示される船体に砲台・艦橋・煙突などのパーツを立体的に組み立てていく機能の画面(資料02) 【どのような実装か】 主な注意すべき実装のひとつにパーツ同士が接触している際に配置不可表示を行う必要がありました。 【課題】 接触判定はパーツの造形に沿って詳細に判定を行うには処理負荷が大きい問題がありました。また、青写真のような表示にしたいという企画要望とユーザーの視認性を両立する必要がありました。 【解決策】 これらの課題を解決するため、接触判定はゲームでは軽負荷で一般的に用いられるボックスの当たり判定を採用しましたが、大量のパーツに対してボックス当たり判定を編集する必要があったため、当たり判定編集ツール(Unity)も並行で開発を進めました。オブジェクトの表示の視認性については、企画とデザイナーの双方と相談を重ねつつ、シェーダー(HLSL)を記述していくことで、課題を解決した美しいCG表現を達成することができました。 # 資料 - [資料01_艦つく -Warship Craft- 公式HP](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwj87I_s5sODAxVLcvUHHdfNDQgQFnoECCUQAQ&url=https%3A%2F%2Fkantsuku.jp%2F&usg=AOvVaw0ZzJ21Tqa3eNOxSMltBWHB&opi=89978449) - [資料02_私が担当した造船機能のプレイ動画(YouTubeより)](https://www.youtube.com/watch?v=-tgZFXyU0eI)

# プロジェクト概要 - Unity・C#・AWSを用いた3DCGオンラインマルチプレイゲームの開発 - キャラクターを召喚して最大12人4チームでリアルタイム対戦する内容のゲーム # 開発チーム規模(2024年1月時点) - 約50名(内エンジニア12名) # コミット概要 新卒入社した会社で、2つ目にアサインされたプロジェクトです。プロジェクトの立ち上げ時期からのアサインであったため、リードエンジニアとしてアサインされ、リリース時は10人以上のエンジニアをまとめました。立ち上げ時期は、自分ともう一名のクライアントエンジニアの2名しかいなかったため、クライアント・サーバサイドを0から作り始めるところから関わりました。プロジェクトは「城とドラゴン」を制作した森山尋氏をゲームデザイナーとして招き、会社として大規模開発のプロジェクトとなりました。森山氏の制作スタイルとして「仕様書を書かない、作っては壊す開発」であるため、エンジニア目線での仕様提案及び、スピーディーなプロトタイプ開発が求められました。また、会社としても初めての本格的なオンラインマルチプレイのゲーム開発であったため、そのサービスのクオリティを担保すべき大きな責任を感じながらプロジェクトを進めました。 # プロジェクト立ち上げ時の対応内容 【概要】 プロジェクト立ち上げ時は技術選定と経営陣への説明を行いました。 【課題】 当初、会社の方針としてサーバサイド開発に用いる言語をGoで統一する命令がありました。しかし、Unity・C#を用いたオンラインマルチプレイゲーム開発のサーバサイドにGoを用いることは当時のチーム体制として非常に開発コストが大きいという問題がありました。 【解決策】 リアルタイム通信フレームワークであるMagicOnionは当時、サーバサイドもクライアントサイド同様にC#で開発できるものとして盛り上がりはじめており、他社事例の存在と開発難易度の易しさからこれを用いることが開発を円滑に進められると判断しました。しかし、会社の方針はGoによる開発を推進していたため、サンプルプロジェクトによりGoとC#による処理速度の違いを測定し、MagicOnionを用いた結果が優れていることや実装コストを抑えられることを取締役に直接説明することで許可を得ることができました。 # 主な実装内容 インゲーム開発全般 【概要】 外部ゲームデザイナーの仕様の無い要望に応えるインゲーム(オンラインバトル画面)開発 【どのような実装か】 オンラインマルチプレイのインゲームの開発は、プレイヤーによる不正行為(チート)に対して強固である設計にしたかったため、主要なロジックをサーバサイドループ(LogicLooperライブラリ)で対応しました。 また、外部ゲームデザイナー森山尋氏の開発スタイルは仕様を用意せず、おもしろいものが出来るまで1週間単位でスクラップアンドビルドするものであったので、スピーディーな実装を実現するPubSubとデータ指向の考えの一部(UnityのEntityComponentSystemの付け替え容易なSystem)を用いた設計を行いました。 【課題】 作っては壊すを1週間単位のサイクルで回すの開発スタイルであったので、コードが散らばり問題があったのと、エンジニアメンバーの士気をケアする必要がありました。 【解決策】 コードの散らばりについては、設計によりある程度軽減がされていましたが、エンジニアメンバーの士気のケアについては、定期的な面談やエンジニア夕会を週に3日10分程度定期開催して改善を試みました。夕会では直接業務とは関係の無いLT時間を設けて、雑談の場を用意することで、エンジニア間のコミュニケーションの活性化を促すことができました。 # 資料 - [資料01_機兵とドラゴン 公式HP](https://kidora.jp/?openExternalBrowser=1) - [資料02_インタビュー記事(写真右J.M)](https://www.wantedly.com/companies/donuts2007/post_articles/380256)