【ゲーム開発】プログラミングは使い回しが肝！再利用性を意識しよう

Unityなどを使ってゲームを作っていて一番大変なのは最初のゲームを作るとき。なぜなら、多くの機能を自分で作ることになるからです。

自分が実現したいことをコードとして表現していかなければならないので、最初はゴリゴリ作っていくしかないんですよね。

ライブラリを使えって？

……そう、今日言いたいのはまさしくその点です！

既存のライブラリを使うのもそうですし、一度自分で書いたコードは自分用ライブラリとしてまとめておきましょう。

次の作品を作るときにそのライブラリを使えば開発期間が短縮できます。

プログラミングの鉄則

プログラミングでは、なるべく同じコードを書かないのが鉄則。

テストされたライブラリがあるのであれば、なおのことそれを使うべきです。

1作目のゲームを作るときにテストをしているのですから、2作目のゲームでそのコードを使うときにはある程度テストの負担は軽減されます。

他の人が作ったライブラリの場合は使い方を覚えるのに多少時間がはかかりますが、自分で1からコーディングしてテストすることを思えばかなりの時間短縮です。

プログラミングはなるべく分かりやすく、なるべく楽して、それでいて成果を上げるのがベスト。なので、一度書いたコードはライブラリとしてどんどん使いまわせるようにしましょう。

コードの再利用

最初のゲームではそれはそれは一生懸命コードを書くことになると思います。他の言語を使ったプログラミングに慣れていれば「いつものこと」と淡々と進めていけると思いますが、ゲーム開発で始めてプログラミングに触れる場合は結構大変な時期かもしれません。

それでもちょっとずつできるようになっていくと楽しさが生まれてきて、「自分、意外と開発いけるかも」みたいな自信がついてきたりします。

こうなってくると、ある機能を実装するためにコードを書いていくのが楽しくなってついつい1からコードを書きたくなります。しかし、ここでグッと堪えてコードを再利用することを検討しましょう。

他の人が作ったコードでもいいですし、自分が一度書いたコードでもいいのですが、これらのコードを再利用(平たくいえば使い回し)することによって、同じ機能を実装しつつ時間を短縮する、という夢のような行動が可能になります。

浮いた時間で新しくコードを書くなり、また別のライブラリを読み込んで理解したりと、さらに上のレベルのプログラミングができるようになります。

プログラミングが上手い人ほどこうした使い回しがうまくて、あっという間に機能を実現しちゃったりします。プログラミングが上手い=キーボードの入力スピードがめっちゃ早いみたいな風潮がありますが、実際にはライブラリや以前自分の書いたコードをうまく使って時間を短縮しているんです。

テストしてある強み

書いたコードはテストして機能を確かめます。以前書いたコードはテストしてあるはずなので、同じ条件であれば使いまわしても機能が担保されているはずです。(導入時にはもちろんテストしますが)

一度テストしてあるというのはとても大きなメリットで、動いたことが確認されているとなると、例え新しいプロジェクトで何か問題が起きたとしても、どの部分で問題が起きているのかを特定するのは簡単になります。以前動いていた部分はOKで、このプロジェクトで加工した部分が8割方問題になっていますからね。

コーディングと同じくらい時間がかかるのがテストですから、この部分を省力化できるのはでかいです。前の会社にいたときに先輩から教わったのは、「テストにかかる時間はコーディングの時間と同じくらいを見積もっておけ。なんならもう少し積んでもいい」ということでした。

実際にやってみたらその通りだったので今でもテストの時間はこんな感覚で見積もるようにしています。

この時間がもし短くできたら……というのがコードの再利用なんです。

しかも公開されているライブラリを使うのであれば、テストするのはライブラリの作者やコミュニティの人たちに任せることだってできます。こんなありがたいことはありませんね。

完全におんぶにだっこというのが気になるのなら、ライブラリを使ったときに出会ったエラーの報告などから始めてみるのも良いかもしれません。

ある程度抽象化しよう

もしあるゲームを作り終わって、別のプロジェクトでも使えるようにコードを加工する際は、ある程度抽象化するのがグッド。特定のプロジェクトだけで使えるライブラリだとちょっと使い回しがしにくいので、なるべくプロジェクト固有の処理を無くして多くのプロジェクトで使えるようにするとイケてるプログラマーになれます。

例えば元々のプロジェクトではただ単に文字列として戻り値を返すようなメソッドを作っていたとします。メソッドの中身となる処理が他の型(intやfloatなど)でも使いまわせるのであれば、それらの型にも対応した形で部品化するのが良いでしょう。

コードを書くときにもガッツリとプロジェクト内の情報やクラスに連携させるのではなくて、そのプロジェクトでなくても動く形にしておくととても良いです。ここは再利用のときに考えるというよりはプロジェクトの設計段階で考えておくと尚良いですね。

いきなり依存関係だの疎結合だのと意識するよりは、まずは不格好でもいいから1つゲームを作ってみて、次のゲームではその部品を使い回してみることを考えましょう。実際に使ってみるときに「ここはこうした方がいいかな」「もっとこうしたら使いやすいかも」と自分で感じる部分があると思うので、さらにその次のプロジェクトの設計で盛り込んでみると良いと思います。

この辺りはいきなりやろうとすると辛いです。実は私は油断すると頭でっかちなタイプになってしまうので、SEとして前の会社にいたときにプロジェクトの進め方みたいなことをめっちゃ調べて勉強していました。ゲームを作り始めて効率の良いプログラミング方法、プログラムの再利用性を考えていたのですが、「あ、これきついわ」とプログラミングが苦痛になりかけました。

このときには再利用性のことは一度置いといて、ゲームを完成させることだけに集中してことなきをえましたが、最初から全部うまくやろうとすると破綻する良い例を身を以て体験しました。

アセットも使い回す

Unityではゲームの素材となるファイルをアセットファイルと呼んでいます。このアセットもどんどん使い回していきましょう。

例えば一度作ったUIなどは、次のゲーム、あるいは間を置いてまた別のゲームで使うのも良いでしょう。

あ、流石にホラーゲーム用のUIをファンシーでキュートなゲームのUIとして使うのは無理ですよ。ゲームの雰囲気に合わせる事が大切ですが、開発者の「特色」が見えるようなパーツの使い回しはあるべきだと思っています。

デザインの4原則のひとつとして挙げられる「反復」の考え方からも、このアセットの使い回しは有効です。

あなたの作ったゲームに毎回「反復」して実装されている要素、機能があれば、それは「あなたらしさ」に繋がっていきます。

アセットやプログラムを使い回して時間を節約しつつ、「あなたらしさ」を表現できるのであれば一挙両得です。

という訳で最初に作るゲームでは使い回せる要素があまりないかもしれませんが、次に作るゲームでは「前作ったゲームから使い回せる要素はないか？」と考えてみると時間の短縮につながります。

まとめ

コードを書くときの「使い回し」は怠惰を意味する言葉ではなく、時間を短縮するための戦術のひとつです。うまく時間を短縮できそうならどんどん取り入れていきましょう。

自分のコードを再利用するのも大切ですし、他の方が作ってくれたライブラリを使わせてもらうことも大切です。

大事なのはコードを書くことそのものではなく、コードを使って表現されたゲームです。ターゲットユーザーにとってはコードが綺麗だとか複雑だとか関係なく、機能が実現されていることが大切なので、1からコードを書くのではなく既存のコードを使ってみることも検討してみましょう。