コーディングの癖を直すのはやっぱりあのタイミング【ゲーム開発】

コーディングの癖を直すのはやっぱりあのタイミング【ゲーム開発】

ゲーム開発ではコーディングを行うことがあります……というかコーディングしている時間が多いですが、コーディングを行う時の手癖ってありますよね。

もちろん変えなくて良いこともありますが、スムーズな開発のために綺麗なコードを書く方法を知っているならそれに越したことはありません。

他の人のコードを見たり、リーダブルコードなどの本で学んだりと、新しいコードの書き方を学ぶ機会は多々あります。

学んだ知識はどのタイミングで自分のコードに反映すべきでしょうか。

 

 

コーディングの癖を直すならこのタイミング

個人的にちょうどいいタイミングだと思うのがプロジェクトの切れ目。

ちょうど終わったプロジェクトを振り返って、コーディングで直した方が良さそうな癖を見つけ、超小規模なゲームを作ってそこで反映します。

大きなプロジェクトが開始するタイミングでコーディングの方法を変えると結構戸惑ったりもするので、その前にリハーサルとして小規模なゲームで一度試してみるのが良いと思います。

私は最初はJavaでAndroidアプリを作っていたので、UnityでC#を使い始めた時にもJava風の書き方をしていました。

このブログで昔書いた記事でもそれを引きずっている部分がありましたが、C#ならC#でより一般的に共通して使われる書き方としてマイクロソフト社のコーディング規則があるので、これを見ながら小規模な(リリースしない)ゲームでコーディングの癖を直しました。

昔のプロジェクトからモジュールを引っ張ってくると「なんて書き方をしてるんだ……」と苦笑しながら今のプロジェクトに合わせた書き方に直したりすることもあります。新しい書き方に慣れてくると、昔の書き方を直したくなってしょうがなくなるんですよね(笑)

 

変えない方がいいタイミング

逆にプロジェクト期間内、今作っているゲームがあるのなら、そのゲームを作っている間は変えない方が良いです。

一部を変えちゃうと、他の部分も合わせないと見辛くて大変なので、その修正に時間を取られたりしますからね。修正中にうっかり必要な記述を削除してしまったりの凡ミスもあり得ますから、なるべくプロジェクト中は今の書き方で進行した方が良いでしょう。

「そんな凡ミスするわけないっしょ! HAHAHA!」とお思いのあなた、疲れているとまさかのミスをしてどこを修正したのか分からなくなり、ひとつ前のコミットまで戻した結果大幅に手戻りしてしまった、なんてこともあるんですよ(1敗)

リファクタリングの時にコードの書き方を変えるのもちょっと危ない気もしていますが、デグレを検知できるテストを作った後なら挑戦してみても良いかもしれません。

というわけで、ひとつのゲームを作り終わったら、コードの書き方も見直してみるとより見やすいコードを書けるようになります。

 

昔作ったゲームのコーディングは直す?

昔作ったゲームのコードがスパゲッティコードとは限りませんが、「3日後の自分は他人」理論からすると昔書いたコードはスパゲッティコードのように感じられるかも、というイメージ画像です。

コーディングの書き方を変えたあとに気になるのが「昔作ったゲームのコーディングは今の書き方に合わせた方がいいのかな?」という点。3つくらい前のプロジェクトだと昔のコーディングの癖が残っていたりして、ちょっと気になります。

個人的な考え方ですが、個人で作っているゲームで、かつ今後アップデートしていく予定があるのならコーディング方法を現在の書き方に変えるのもアリだと思います。ゲームに機能を追加していくときにコードを読むことになりますが、今の慣れている書き方でないとちょっと解読に時間がかかったりするんですよね。

変えない場合は一貫して昔の書き方で統一するようにしましょう。スタイルの混在は避けたいところ。

「個人で作っているゲーム」と区切ったのは、他の人と組んでゲームを作る際はプロジェクトでのコーディング規約を決めておくことが多いためです。コーディング規約が決まっているのであればそれに沿ってコーディングしていかないと混乱を招いてしまうことになるため、逆に変えるべきではありません。

書き方を変えるだけであっても、うっかりミスすることはあり得ますから、

  • ファイルのバックアップ
  • バージョン管理
  • テストの自動化

などを検討しておく必要があります。

現在ゲームがストアなどでダウンロードできるのであれば、動きを変えないようにするのも大切なことです。この辺りはリファクタリングの考え方も参考にすると良いと思います。

 

慎重に変更するので時間がかかる

昔作ったゲームのコーディングを今のスタイルに書き換えるのは結構時間がかかります。というのも、既存の動きを変えないように変更するので丁寧に見ていく必要があるためです。

最近直したプロジェクトだと、60個くらいのファイルでコーディングスタイルを直すのに1、2日かかりました。「このプロジェクトだとどんな風に動きを作っていたっけ?」なんて思い出しながらというのもありましたが、ある程度の時間は見込んでおいた方が良さそうです。

変更する際にはテーマごとに修正していくと安心です。例えばかっこの書き方を下記コード内の上段のスタイル(Java風)から下段のスタイル(C#風)に変更しようと思ったら、全てのファイルでかっこの書き方について直していきます。

途中でフィールド名の命名規則などを直したくなっても我慢して、まず全てのファイルでかっこを直す、と言った形で修正することで漏れを防ぐことができます。

2つのコーディングスタイルが混在するコードは読みにくいので、なるべく漏れが少ない形で修正できるのが望ましいですね。

 

まとめ

なんだか思わせぶりなタイトルになってしまいましたね。

コーディングの癖を直すタイミングはプロジェクト終了後がベストです。大きなプロジェクトではなく、超小規模なプロジェクトとしてミニゲームを作り、その中で新しいコーディングスタイルを試してみると良いでしょう。

 

     

ゲーム開発の攻略チャートを作りました!

CTA-IMAGE

「ゲームを作ってみたいけど、何から手を付けていいか分からない!」


そんなお悩みをお持ちの方向けに、todoがアプリをリリースした経験を中心に、ゲーム作りの手順や考慮すべき点をまとめたe-bookを作成しました。ゲーム作りはそれ自体がゲームのように楽しいプロセスなので、「攻略チャート」と名付けています。


ゲームを作り始めた時にぶつかる壁である「何をしたら良いのか分からない」という悩みを吹き飛ばしましょう!