新卒クソゲーコンテスト ~エンジニア・運営編~

今回は、2023年度新卒メンバー数人で社内のクソゲーコンテストに参加した際に作ったゲームについてお話しします。

このブログはエンジニア２名と運営１名の計3名でお届けします。少し長めになっていますが、ぜひ最後までお読み頂けましたら幸いです！

今回作ったゲームについて

TPSのローグライトなゲームです。
魔法とその魔法の性質を変えるエンチャントを集めつつ、オリジナルの魔法を構築し、ダンジョンの踏破と魔法の収集を目指します。

プレイ動画

インゲーム実装編

第一事業部でサーバーエンジニアをしている堀江です。
今回は、魔法とエンチャントに関する実装の一部についてお話しします。
Unity/C#に関しては独学で得た知識がほとんどのため、暖かい目で見てくれると助かります。

魔法・エンチャントを作る

このゲームのメインの遊びである、魔法とエンチャントの組み合わせによる魔法の性質の変化の実装について紹介したいと思います。

作りたいもの

このゲームでは魔法を駆使して敵を倒しつつ奥へと進んでいきます。
そして、魔法に装備できるエンチャントがあります。魔法の性質に変化を与えるものです。
ダメージ量や速度などのパラメータを変化させたり、着弾時に爆発を発生させるようにしたりなど、様々です。

大まかな設計

魔法が自身に装備されているエンチャントの配列を持ち、魔法の発動時に魔法が持つエンチャントのEnchantメソッドに、魔法クラスが持つSpellStatusを渡しエンチャントを実行します。

Enchantメソッドは加工したSpellStatusを返り値として返します。魔法の速度の変更など、魔法のパラメータを変えるようなものはこの時点で効果が反映されます。

その後、発動時/発動中/何かにぶつかったタイミングで、エンチャントによって魔法に登録されたアクションが発動するようになっています。

反省点

いきなりですが、このゲームでは反省すべき実装が多く生まれてしまいました。
1つ1つ挙げてもキリがないため、どうしてそうなったのか？という話をしたいと思います。

実装イメージが固まっていない

実装を進めていく上で、実装イメージを固めてから実装するということをしていませんでした。
実際にコードを書いてみて、修正が必要そうだったら都度修正するといった感じです。
拡張性のない実装が生まれるのもそうですが、根本的な部分を後から変更したくなることが出てきます。

そうして自分で自分を苦しめた結果、１つのクラスに複雑な役割を持たせることになり、クソコードが生まれていきました。
仕様に対して、懸念点などないか検討し、実装イメージを沸かせてから手を動かすことが大事です。

色々やろうとし過ぎた

今回は多くのライブラリや試してみたかった実装パターンなどにチャレンジしてみました。
結果としては、多くのことが中途半端になってしまいました。
自分の経験の浅さもありますが、どれだけ時間を費やせるかをあまり考えれていなかった部分もあります。

作るゲームの規模を考え、与えられた時間を考え、学習コストを踏まえ、今回のゲームは何が重要で、どこを頑張るかということをしっかりと考えておくべきでした。
そうすることによって、後々自分が苦しまずに済んだかも…?

UI実装編

第一事業部、クライアントエンジニアの鈴木です。
今回のクソゲーコンテストでは主にUIの実装を担当しました。
制作を通して頑張ったことや感じたことを書かせていただきます。

UniRxを使った実装

UIの実装では、私が所属しているプロジェクトでも使われているUniRxというライブラリを活用しました。
UniRxは今まであまり使ったことがなく、実際に私が所属しているプロジェクトで触ることが多いので、勉強する良い機会だと思いました。

エンチャント交換画面

ほぼ全てのUIでUniRxを使っていますが、特に多用したエンチャント交換画面を紹介します。
主な流れは、敵がドロップしたエンチャントに触れると発火するObservableを購読し、流れてきたエンチャントのモデルクラスを基に新しいエンチャントをUIに反映させます。
後は好きなスロットをクリックすることで取得したエンチャントがプレイヤーに反映されて、UIも更新されます。

コードリーディング

今回のチームはエンジニアが2人なので、必然的に堀江君が書いたコードを読みながら実装することになります。
エンチャントの取得やプレイヤー周りの処理は堀江君が作ってくれていたので、それをもとにエンチャントやステータスなどをUIに反映する必要がありました。
コードは人によって特徴があるので、自分だったらこうするけどこんなやり方もあるんだな～と勉強になることが多かったです。
業務でもコードを読む力は非常に重要なので、これからはもっとコードを読む習慣をつけていきたいと思いました。

ゲームを完成させよう編

第一事業部、運営の島です。
今回のクソゲーコンテストではスケジュール進行と成果物のレビューとゲームタイトル命名を担当しました。
このゲーム制作で特に感じた「ゲームを完成させる」について書かせていただきます。

誰がゲームを完成させるのか

コンテストに制作物を提出して発表するということは、もちろん締め切りというものがあります。
締め切りまでにゲームを完成させなければなりません。
ここで問題となったのはどの程度のクオリティを「完成」とするかです。
今回の制作ですと、ゲーム全体の仕様が固まらないまま完成させようとしていたのです。
風呂敷は大きく広げて、「あれもこれも実装したい！」に対して「いいね！」だけの会議が行われていました。
誰かがコンテンツを削る役になれていれば短期間でスムーズに仕様書を決めれて、そのあとのスケジュールも上手くいっていたかもしれません。
ですが、なかなか人の案に対して「ダメ」とは言いにくかったです。
自分がヘイトを受けつつも、ゲームを完成させる責任をとれるようになりたいですね。

責任をとれる楽しさ

とはいっても、責任を取ることは正直やりたくないし、失敗したとき誰かのせいにしたいと思います。
自分もミーティングで物事を決定することを避けていました。
この仕様で行くぞ！って決めて実際ゲームを作って面白くなかったら自分のせいになっちゃいますからね。
でも、逆に言えば責任さえとればゲームの方向性を自分の一存で決められるってことです。（一存はかなり大げさですが）
責任をとれる立場に今いるかは置いておいて、自分好みのゲームをメンバーの手を借りて作れるのは楽しいことですよね。

メンバーのモチベーション

それじゃあ自分の独断でメンバーにあれやってこれやってとなると、なんか嫌な奴ですよね。周りからのヘイトも溜まります。
周りの意見を聞く気が無いならミーティングする意味も無くなります。
一人ひとり大なり小なり作りたいゲーム像があるのでそこをしっかり聞いてあげましょう。
今回のゲーム制作では「聞きすぎた」ところが問題でした。
メンバー間の亀裂を生まないように、全員の提案を聞きながら折衷案を導き出して、結果ふわっとした仕様書が完成しました。
そしてふわっとしたゲームが完成してしまったわけです。

結局どうしたらよかったの？

ここまで失敗談をつらつらと書いていますが、結局どうしたらよかったのか。
簡単な解決方法は実績がある人が責任を取ることだと思っています。
「すごく面白いゲームを作った人」が、周りの意見を聞きながら物事を決定してくれるのであれば信頼できます。
ですが、今回の制作では「すごく面白いゲームを作った人」が見当たりませんでした。
となると「締め切りを意識」して、「責任を取ることを恐れず」、「周りの意見も聞き」、「進むべき方向に舵をとれる」人間になれればうまくいっていたかもしれません。
なんか文字に書き出すと大仰な感じがしますが、実際やってみるとやりがいがあるかもしれません。
いつか舵をとれる人間になって、さらに先で「すごく面白いゲームを作った人」になってみたいですね。

まとめ

メンバーそれぞれが今回のゲーム制作を通して感じたことをまとめたいと思います。
堀江

鈴木

島

最後に

ここまで記事を読んで頂きありがとうございました！
例え少人数での開発であったとしても、メンバー間でのコミュニケーションや目標意識の共有はとても大切だということが分かりました。