「社内のエンジニアが提案してゲームに反映されることってどのくらいあるんですか？」と採用候補者の方から聞かれたことがあったので、社内でヒアリングをしてみました。
まだリリース前のタイトルでの提案もあり詳しく書けない部分もあるのですが、弊社エンジニアの働き方が少しでもイメージできたら嬉しいです。
機密事項でスクショが載せられないので代わりにオフィスのある秋葉原の写真
- リアルタイムユーザバトルの実装見積り
- タイトル表示や場面転換の演出案
- ストーリースクリプトの実機確認手法
- 描画負荷を下げる改修
- バトルリプレイ機能の実装
- 自作フレームワークの実装
- 画面遷移のひと手間を減らす
- キャラクターの新スキルレビュー
リアルタイムユーザバトルの実装見積り
ディレクターはリアルタイムユーザバトルを実現したかったのですが、社内で実装を経験したメンバーがおらず難易度や工数を見積もれないでいたため、別の機能で代替しようとしていました。
そこで「実装難易度を見積もることを目的としたテスト実装に1週間使う」ことを提案しました。事前に通信ライブラリのドキュメントにも目を通していたので、これを使えばいけるかもという感触がありました。
その時点で検討していたゲーム仕様も、通信タイミングが少なくて済むゲームルールだったため実装がスムーズに進み、異なるPC間で対戦できるところまで3～4日でいけました。これを見てディレクターがリアルタイムユーザバトルをゲームのエンドコンテンツする仕様に変えることができました。
（サーバサイドエンジニア Oさん）
タイトル表示や場面転換の演出案
ストーリーを表示するアドベンチャーパートで、タイトル表示や場面転換の演出について素案を作成し、採用されました。
タイトル表示は、キャラとタイトルが一緒に出るといい感じになるのではないかという案を考え、フェードのみの簡単なアニメーションを作成してメンバーに共有しました。結果その案が採用され、デザイナーに作成の依頼を行いました。
場面転換は、VTuberの配信開始時や画面の切り替わる時に使われている演出が作品のイメージに合うのではないかと思い、演出をまとめて共有したところその一つが採用されました。
（ネイティブエンジニア Mさん）
ストーリースクリプトの実機確認手法
シナリオチームがスクリプトを作成するツールはUnityを使って実装されているのですが、実際のゲームはcocos2d-x上で動作していました。当初はUnity上でLive2Dや演出も確認する想定だったのですが、スクリプトを実機で確認するとLive2Dのモーションやwaitの秒数がボイスとずれてしまうということがありました。
そこで、スクリプトツール上では値を設定してスクリプトを出力する機能のみとし、演出の確認は実機で行うように提案して改修しました。実装としてはUnityをSocketサーバーとして立てて、そこに実機を繋いてUnityで作ったスクリプトのjsonを送るようにし、受け取ったjsonでストーリーを再生するようにしました。
それまでは何か新規の演出を実装する場合、cocos2d-x側とUnity側で二重に実装する必要がありコストが高かったのですが、演出表示部分を実機にまとめることで実装コストも下がりました。
（ネイティブエンジニア Sさん）
描画負荷を下げる改修
ゲーム内に登場するアバターキャラは、部位ごとにパーツを結合しているため描画処理が重くなっていました。
そこで、動的にメッシュとテクスチャを結合してキャラクターのドローコールを削減するように努めました。また、非圧縮テクスチャとしてテクスチャ結合していたものを、圧縮テクスチャのまま結合するように改修して、メモリと描画負荷を軽減しました。
（ネイティブエンジニア Oさん）
バトルリプレイ機能の実装
バトルをリプレイ再生したいというプランナーの要望があり、実装方法を検討しました。
結果、バトル内部の計算結果などをjsonデータにして保持することで、そのデータを元にバトルを再生する機能を実現できました。
（ネイティブエンジニア Oさん）
自作フレームワークの実装
そのプロジェクトではwicketというテンプレートエンジンを採用していたのですが、そこにbackbone.jsを組み合わせるかどうかという議題が上がりました。画面作成のコストを考えると少し効率悪そうな感じがしたので、backbone.jsまでの機能はないけれど、wicketに合わせた簡略化したライブラリを作り採用されました。
プレゼント受け取りやフレンド一覧、ミッション一覧など画面を切り替えて描画していた部分は、jsonデータのやりとりだけで再描画できるようになりました。
（フロントエンドエンジニア Rさん）
画面遷移のひと手間を減らす
画面遷移のひと手間を減らすような提案をよく行っています。
例えばクエストのループ状態について、毎回設定がリセットされていたのを設定状態が保持されるように変更しました。
あとはイベントの中でキャラクターのチーム編成を変更する頻度がかなり低いにも関わらず、フローに必ず編成させる処理が挟まっていたのが気になったので、UIチームにフローの変更を提案し、初回だけ編成をするよう改修しました。
（フロントエンドエンジニア Mさん）
キャラクターの新スキルレビュー
僕自身ゲームが大好きで多くのゲームをプレイしています。
自分が関わっているプロジェクトに関して、メイン担当はクライアント開発ですがゲーム設計部分で気になる部分があればディレクター・プランナーに伝えています。
例えば、既存のスキルと組み合わせると無限に必殺技が出せるようになってしまう、似たようなステータスを持つキャラクターの上位互換になっていてそのキャラが活躍できなくなってしまう、などです。
（フロントエンドエンジニア Yさん）
実際にヒアリングをしてみると、ゲームルールに関する提案だけでなく、実装方法やUI/UXの改善、ゲームバランスを踏まえたチェックなど、ゲームに関連する様々なことにエンジニアが関わっているんだなと感じました。