コードレビューとは?
コードレビューとはコードを書いた際に人に見てもらい(レビュー)問題がないかをいろんな視点で確認してもらうというのが目的になります
PurpleMandrillでの開発はとりあえず遊べる状態を目指して、ゴリゴリ作っていました
なので作った処理自体は、一応動くものの処理効率が悪い箇所などがいくつかある状態になっていました
こういった状態を解決する一つの手段としてコードレビューというものが存在します。
大規模開発になればなるほど、人数が増えるため技術的なレベルは様々になってきます
なのでばらつきを防ぐためにチーム内で事前にコードを書くためのルールが存在する場合もあります(変数名の命名規則やプログラムの構造など)
処理自体は問題ないが、新しく作られたコードがそのルールに沿っているか?などを確認してもらうこともあります
また人によって得意な分野が設計だったり、通信周りだったりと違うため、お互いに知っている部分を共有しあってゲームを開発していくことがほとんどです
作った処理を見てもらうことで新しい知見が得られたりもしますが、何よりバグを未然に防ぐなどの効果もあるのでゲーム制作にとってはかなり大事になってきます
そんなコードレビューがどういった流れで行われ改善されていくのか、ぴっくるの一例を交えて紹介します!
HPゲージの処理周り
![](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/11/purpleMandrill_gaugeFirst-1024x477.png)
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_egao.png)
HPゲージのアニメーション実装できました!
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_hohoemi.png)
1秒間で指定した分量分、ゲージの幅がアニメーションして変化
するようにしましたがどうでしょう?
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_komaru.png)
うーん、この実装だとちょっとマズイね…
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_komaru.png)
この処理で問題なく動いているように見えますが、どの辺りがまずいでしょうか?
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_komaru.png)
これだとハードのスペックや環境、状況によって差が出ないかな?
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_hohoemi.png)
例えば60FPSの時と55FPSの時で同じ1秒でもそれぞれ処理回数が違うと思うんだけど。
その時のゲージの動き方・見え方は同じになるかな?
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_komaru.png)
なるほど、現在の処理だとフレーム毎での処理になっているので確かに環境によって差が出てしまいますね…
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_hohoemi.png)
経過時間に合わせて処理するように直します
![](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/11/purpleMandirll_gaugeSecond-1024x634.png)
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_egao.png)
DateTimeを使って、経過時間を計算して処理するよう修正しました
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_komaru.png)
方向性は悪くないけど、DateTimeを使うのは一般的ではないね。
DateTimeは処理負荷が高いから。
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_hohoemi.png)
現実世界の時刻と合わせるといったパターンでは使用してもいいかもしれないけど、
今回の処理の場合はTime.deltaTimeを使うのが最適だと思う。
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_komaru.png)
それは考慮していませんでした、確かに毎回処理するような場合では
負荷が少ない方がいいですもんね。処理見直します。
![](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/11/purpleMandrill_gaugeThard-1024x675.png)
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_egao.png)
Time.deltaTimeを使う形に修正しました!
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_hohoemi.png)
いい感じになったね
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_hohoemi.png)
がんちゃんは気になるところはないですか?
![がんちゃん](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/iwata_hohoemi.png)
そうですねー
HPゲージの表現処理であればTween使って書いちゃえばいいかな?とは思いました
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_egao.png)
そうだね、このぐらいならDOTween使って作っちゃうのもありだね
アニメーションパターンも色々指定できるし
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_egao.png)
Tween使って書いたら1行で書けちゃいました
便利なアセットは今後も使っていきたいですね
![](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/11/purpleMandrill_gaugeLast-1024x130.png)
パフォーマンスの改善から、最終的には1行でプログラムが書けるようになりました!
【DOTweenについて】
DOTweenとはUnityでよく使われるフリーのアセットで、開発の現場ではよく利用されています。
みなさんがゲームでよく目にするちょっとしたゲージの伸縮だったり、簡単なオブジェクトの移動ぐらいであれば大体の処理はTweenを使うと上記のように1行で書くことが可能になります
今回使用したDOScaleは対象のオブジェクトのScale値を指定した値まで増減させる処理になります
その他にもPositionを移動させたり、Rotationを変えたりする事ができる処理も入っているのでかなり便利に使えますのでまだ使ったこと無い!という方は是非調べて使ってみてください!
敵のHPゲージの表示バグ
![](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/11/purpleMandrill_gaugeDispFirst-1024x154.png)
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_komaru.png)
新しく実装された敵のHPゲージだけど敵が画面外に行ったらバグっちゃうね
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_komaru.png)
本当ですね、チェック不足でした…原因調査します
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_komaru.png)
何故だろう…?間違いなくターゲットにしている座標は敵のもので
そのままWorldToScreenPointをしているだけなのに…
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_hohoemi.png)
ちなみにゲージが写りこんでいるときのZ座標はどうなってる?
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_komaru.png)
マイナスで出てます。なんででしょう??
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_hohoemi.png)
ベースにしている敵のオブジェクトがカメラの後ろにあるからだね
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_komaru.png)
なるほど…
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_hohoemi.png)
当然マイナスのZ座標をWorldToScreenPointしてもZ座標はマイナスのまま出力されるけど
ゲージはUIとして表示させているからZ座標がマイナスであっても画面上に表示されるね
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_hohoemi.png)
そうか、Z座標がマイナスということはカメラの後ろ側にある
つまり写す必要がない
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_egao.png)
ということは、Z座標がマイナスの時にアクティブをオフにすればいいですね
![](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/11/purpleMandrill_gaugeDispSecond-1024x179.png)
無事解決!
敵のHPゲージの座標バグ
この位置辺りにHPゲージを表示したい
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_komaru.png)
今、敵ゲージの表示の高さってどうなってる?敵キャラの種類によっては敵オブジェクトとゲージの表示が重なっちゃってるんだけど…
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_hohoemi.png)
あ、今は一律で同じ数値で高さ調節しちゃってますね…敵の座標の上に+2という
固定値で設定してます
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_komaru.png)
それだとさっき言ったように、敵の高さによっては表示が乱れてしまうので
改善できないかな?
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_hohoemi.png)
わかりました、対応します
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_komaru.png)
とはいったもののどう設計すればいいんだろう?敵のオブジェクトの高さを取得で
きればいいけど…手軽に実装できそうもないな…かといって時間もかけられないし…
![ほっしー](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/hoshiyama_hohoemi.png)
じゃあこういう手法もあるよということでヒント
敵モデルにゲージの高さを設定したオブジェクトを追加するのはどう?
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_egao.png)
あ、それだと時間かけずに簡単に対応出来そうです。やってみます。
![みんの](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/mizuno_egao.png)
敵モデルの中に、それぞれ敵の頭の上に来るようにオブジェクトを設定しました。これをコード側で取得すれば、個別に高さを調整した位置にゲージが表示できるようになりますね
個々のモデルにGaugeHeightオブジェクトを設定
![](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/11/purpleMandrill_gaugeHeight-1024x219.png)
スクリプトでGaugeHeightを探して、そのポジションにゲージを設定することで解決
ポジションの難しい座標計算等を行わずに実装が可能になりました
まとめ
いかがでしたでしょうか?
ぴっくるの一例を交えてコードレビューの流れを書かせていただきました
- まずは実装してみる
- 見てもらって意見をもらう
- 問題点や改善方法を相談
- 最終的な実装を行う
というのが一連の流れになります
レビューをしてもらうことで、パフォーマンスが改善したり、ゲームを公開する前にバグを見つけられて直すことができたりとゲームに対していいことだらけです
また、分からないところを知っている人に聞くことでそういう手法もあるんだ、と自分のスキルアップにも繋がります
コードレビューに限らず「どういう実装をしようとしていて、わからないところはここ」という形で事前に質問をしてみるのもいいでしょう
ゲーム全体の品質が上がるので、積極的にお互いの書いたコードを見ていきましょう!
![](https://pgdc.pickle.ne.jp/wp-content/uploads/2022/09/03c5f24e931cda326932a7d3ca5b4662-1024x377.png)
有限会社ぴっくるとは?
ゲーム開発を行って19年目になる会社です。
他のデベロッパー会社と一緒にプロジェクトに参加して、いろいろなゲーム開発に携わっています。
音声収録・動画配信スタジオを運営し、会社・スタッフともに色々な情報発信を行っています。
そんなぴっくるではゲームプログラマースタッフを絶賛募集中です。
コメント