ゲーム開発のプログラミングではコメント文で意図を伝えよう

ゲーム開発では多くの場合プログラミングするフェーズがあります。プログラミングで大切なのは、「なんでこの処理を入れたのか」という意図が分かるようにしておくこと。

コードだけで意図を伝えられるのは超スゴイ級のプログラマっぽくて憧れますが、コメント文があれば簡単に意図を伝えることができるので、ぜひコメント文を残しておきましょう。

他の人と協力して進めるプロジェクトではもちろんのこと、たとえあなたひとりのプロジェクトであっても、コメント文を残しておくのは大切です。なぜなら、3日前に書いたコードは別人が書いたコードというくらい頭から抜け落ちているためです。

将来のあなたのためにも、適切にコメント文を入れていきましょう。

コメント文の入れ方(おさらい)

コメント文はマシンが使うものではなく、人間がソースコードの意図を汲み取るために使われるもので、いってしまえばただのメモです。

コンパイルするときには使われないので、究極的には無くても問題ありませんが、人間がソースコードを書くときに「なぜそうしたのか」が分かるようにしておくのはプロジェクトを円滑に進める上で重要です。この点についは後述します。

Unityが使うC#でコメント文であることを示すには、以下のように「//」を使用します。また、「/* 文章 */」のように囲むことでもコメント文であると認識されます。

Microsoft社が公開しているC#のコーディング規約を見ると、推奨されるのは処理とは別の行に「//」を書く一番上の方式なので、特に理由がなければこの書き方が良いと思います。

docs.microsoft.com

 

120 Users

150 Pockets

C# のコーディング規則 - C# プログラミング ガイド

https://docs.microsoft.com/ja-jp/dotnet/csharp/programming-guide/inside-a-program/coding-conventions

ソースコードを書くときに使っている多くのIDEではコメント文の色を変えてくれると思うので、コメント文の部分はすぐに分かるようになっています。

処理の意図ってそんなに大事？

はい、とても大切です。

プログラミングではコードを書く前の設計がとても大切で、私たちが表現したい振る舞いを私たち人間が分かる言葉で決めておくことが大切です。

例えば、キーボードのキーを押したらキャラクターがジャンプするような動きを付けたいとします。ジャンプのために使うキーの決め方にも意図があります。

PCで操作するゲームなら、キャラクターがジャンプだけでなく移動することがあるかもしれません。その場合は右手で矢印キーを操作して、左手でジャンプさせると操作しやすいでしょう。

右手が矢印キーの上にあるなら、左手で操作できるキーはたくさんあります。Jumpの「J」を選ぶかもしれませんし、右手とは反対側の「Z」キーや「X」キーを選ぶかもしれません。

こうした意図は多くの場合設計書に記載しますが、個人で開発している場合はわざわざ設計書を書かないこともあるかもしれません。その場合には、なぜこのキーを選んだかの意図や理由をコメントに残しておきましょう。設計書がある場合でも、この処理が設計書のどの部分と対応しているのかを残すのは大切です。

この状態で、3ヶ月後にゲームのアップデートとして攻撃する機能を追加したくなったとしましょう。この時のキーの決め方は、コメント文が残っていればそれと同じ意図で選べます。

Jumpの「J」としてキーを決めたなら、同じ意図でAttackの「A」を攻撃ボタンにするかもしれませんし、操作のしやすさを考えてジャンプボタンを「Z」にしたら、その隣にある「X」を攻撃ボタンにするかもしれません。

意図が分かればそれに沿ってコードを書けばいいだけなので、アップデートの手間も軽減されます。これがもし何もヒントが残っていない状態なら……意図を把握するのに時間がかかりますし、前回の設計方針を変えてしまうことにもなりかねません。

このボタン1つの決め方を例に挙げましたが、実際にはこれが何十、何百と行われます。ノーヒントで意図を把握するのはかなりきついですよね。

コメント文がないとブラックボックスに

前の会社にいたときに、コメント文がほとんど書かれていないソースコードを相手にした話を何度も聞きました。(自分で体験したことも)

ある案件では、元々そのプロジェクトにいた人が退職してしまって、引き継いだメンバーで頑張って意図を読み解き、設計書に反映したこともありました。設計書もアップデートされていないという地獄のような話で、「今動いているソースコードが設計書」とまで言われる始末。意図の読み違えもいくつかあって阿鼻叫喚の様相を呈していました。

また別の案件で改修を行ったときには、そのソースコードを書いた人が「設計書は俺の頭の中」と言い放ったこともありました。ソースコードではコメント文もろくに残ってなく、中で使われている変数名も「a」とか「flag」とだけ書かれている名前が多く、意図を読み解く難易度が非常に高かったんです。

コナンになった気分で謎を解き明かして改修した結果、「とどちゃん変な風に変えたでしょ。ここ訳わからないことになってるよ」と私がいじってない部分(つまり本人が書いた部分)を指して怒られたこともあります。本人すら自分で書いた内容を覚えていないのですから、コメント文を残しておくのは大切ですね。

このソースコードはGitなどのバージョン管理ソフトで管理されていなかったという別の問題もありました。ちゃんとバージョン管理していないと、バグが起きたときに最後に触っていた人が犯人、なんていう風船爆弾ゲームになりますからね。

コメント文がないことで(他の人が)地獄を見た例をいくつか挙げましたが、こういった話はIT系の会社にいる人だったら聞いたことがあるかもしれません。

1週間前の自分は別人

プログラマの世界ではコメント文の大切さを伝えるために「1週間前の自分は別人」という戒めがあります。

同じ人間であったとしても、1週間前にソースコードを見たときには別人が書いたソースコードのように意図が分からないものになっています。

私は最初「自分は記憶力が良いし、大丈夫だろう」なんてたかを括っていましたが、実際に1週間後にコードを見ると「誰だよこんな訳のわからないコードを書いたのは……」となりました。ええ、もちろん自分が書いたコードに対して、です。

最近は1年前に自分で書いたコードを使いまわしてゲームを作っているのですが、コメント文を参考に必要な部分を抜き出して処理を組み上げています。コメント文がなかったらソースコードを見るたびに意図を汲み取る作業が必要になるので、時間がかかるわ、ストレスがたまるわで大変なことになっていたと思います。

コメント文があるおかげでスムーズに作業できているので、ぜひあなたにもコメント文を残す癖を付けていただきたいんです。

ゲーム開発ではなおのこと

仕事としてゲーム開発している人は毎日作業を行っているのでソースコードの内容は自然と頭に入っているかもしれませんが、趣味でゲーム開発をしている場合は、仕事の後とか週末のまとまった時間に開発をすることが多いですよね。

その場合は、前回ソースコードに触れてから時間が経っているので、思い出すのに時間がかかるかもしれません。1週間仕事を頑張って、さぁUnityでゲーム開発するぞ！　と気合いを入れてエディタを開いても、「なんでこんな処理入れたんだっけ……？」なんてことになってしまう可能性だってあります。

思い出すことに時間をかけていては、本来進めたかった作業が進まないことだって起こりえます。せっかく確保できた時間は、ゲーム開発を前に進めたいものです。

流石に全部の行にコメントを付けた方が良いとは思いませんが、ある程度の処理のまとまりでは、何を実現したくてこの処理を入れているのかを残しておくようにしましょう。