経緯

昨年の夏頃に人生で初めてゲームを作りました
なんとか動くものは作れたものの、コードの設計等には一切配慮しない作りとなっていた
また生成AIに頼りっきりな部分が大きく、自分でもよく分からずに実装しているところもあった
- コーディングや設計の経験に乏しい人が生成AIを使うと、いわゆる「汚いコード」となり可読性やメンテナンス性が著しく落ちることを自らの経験から学んだ
そういった経緯もあり、今回はあえて 生成AIを使用を禁止する という制限を自らに課して、その上でゲームを作るということに挑戦してみました
- ちなみに、これは課の先輩からの提案でもあります。「生成AIに頼り過ぎている」ということは自分でも薄々感じていたのですが、第三者目線で言ってもらうことで再認識できたのが良かったです

製作に関する情報

製作期間

2024年末～2025年始にかけて
ある種「冬休みの宿題」的な感じで取り組んでいました

製作物

ブロック崩し
- https://github.com/ryota37/BrickBreaker
  - READMEに動画があります
- 見ての通り、オーソドックスなブロック崩し。最低限の実装

製作物についてのコメントなど

前述の通り、生成AIを使わずに製作した
前回作ったゲームは Main.cppに全てのコードを記述したが、今回は Ball, Bar, Blockの３つのオブジェクトごとにファイルを分割した
Barについて、Ballとの接触判定のみを取得している
- Barの動きとは無関係にBallが反射する実装
接触判定の実装は前回のゲームでもやったが、今回は複数のオブジェクト(Block)について接触と壊れているかどうかの判定(isBroken)を管理しなければならず、そこが難しかった
- 参照ではなくコピーを渡すという実装にしていたせいで、ボールが当たってもブロックが壊れないという挙動になってしまい、少し製作に詰まっていたフェーズがあった。気づけばどうということはないのだが、中々気づけないものである

余談

やたらとBが多い。

「ブロック崩し」を意味するBrickBreakerが頭文字を取ると BB
オブジェクトもBall, Bar, Blockと全部Bで始まっている
人生で2番目に作ったゲームなので、アルファベットの2番目の文字であるBが多いのは上手くハマってる感じがしてよかった。偶然だけど

生成AIを縛ってみてどうだったか

生成AIを縛ってプログラミングをする経験をできたのは良かったと思う
プログラミングを始めたのとほぼ同時期に生成AIが出てきたため、筆者は生成AIなしでプログラミングをする機会がほぼなかった
深く考えず生成AIにコードを生成させよく分からないまま実装していた場面がしばしばあった(趣味のコーディングに限った話だが)
生成AIを使わずにプログラミングすることで、時間はかかるようになったがその分自分の頭で考えるようになり、コーディングを通じた学習効果は高くなったように思う。急がば回れといった感じか
- また、得られる達成感も大きくなったように思う。生成AIを使っている時は、どこか他人のコードを組み合わせてレゴ遊びをしているような感覚があり、「自分で書いた自分のコードだ」という感覚が希薄だった

今後の生成AIとの向き合い方

とはいえ、生成AIが道具として優れていないという考えに至ったかといえば、全然そんなことはない

[コード生成について]

ありきたりな結論だが、結局のところ使い手次第といった印象を受けた。プログラミングや設計に関する知識が豊富な人ほど的確で具体的な指示が出せるため、コード生成の質・量ともに上がるという推測
そのため、生成AIが盛んな今こそ、逆にプログラミングや設計に関する基礎をしっかり勉強する必要があると感じた

[調べもの・学習用のツールとして]

調べもののツールとしては、生成AIは非常に優れていると感じた。咄嗟にうろ覚えな内容を「思いだす」時や、調べもののとっかかりとして概要を大まかに把握するような用途が特に向いていると思う
一方で、新しい内容を一からしっかり学ぶ時は本や教科書をじっくり読む方が良いと感じた。体系的な知識を身につける際は、ある程度まとまった情報源から学ぶ方が良いと思う
- 現状の生成AIが生み出せるのは「知識の断片」止まりだと感じている
また、新しいことを学ぶ際の「本選び」を生成AIにしてもらうのは結構便利だと感じた

[アンチパターン]

逆に、生成AIの良くない使い方についても考えてみた

基本的に、「自力でできないこと」を生成AIにやらせると良くないと感じている。出力結果の良し悪しを自分で判断できないからだ
- 例えば、自分が詳しくない分野やよく分かっていないことを調べたり、動作原理のよく分からないコードを生成してもらう、といった具合
- そういう使い方をするなら、生成AIに情報源を出してもらうとか、別途自分で調べるなどして裏取りした方が良いと感じた
- 調査のとっかかりや入り口として使う分には良いと感じた
デバッグの際に、深く考えずとりあえずエラー内容と症状だけ伝えて生成AIに解決策を求めるやり方
- 特に、初学者はこれを避けた方が良いと感じた
- 簡単なエラーとかなら良いかもしれないが、少し込み入った不具合だと生成AIの出した解決策を実施してみても解決しないこともあり、かえって泥沼化するケースがある
- 加えて、初学者がこれをやると「考えずにただ生成AIの言いなりになる」ことが多く、学習効果も低くなってしまうと感じている
- このケースの場合は「生成AI」を使うことが悪いのではなく「深く考えていない」ことが悪いので、生成AIやWebで調べものをする前に 自分で仮説を立てる ことが大事なのだと思う。急がば回れ(自戒)

※上記の記述は、記事執筆時点(2025/03)時点のもの。生成AIを取り巻く環境は日進月歩なので、いつ時代遅れになってもおかしくない
※また、上記はあくまでプログラミング初心者～中級者レベルの一個人の感想である。違うステージや違う環境にいる人からは、また違った感想が出てくるとは思う。

今後の展望など

前回より設計はマシになっているとはいえ、まだまだ見直す点は多い。結局 Main.cpp に色々な処理が集中している
プレイ前、プレイ中、クリア、ゲームオーバー　といったゲームモードの切り替えの実装も、フラグ立ててifで分岐してといった原始的な実装になっているので、これももっと洗練された実装にしたい
- interfaceを使うと良いのかなと思いつつも、具体的にどう実装すればよいかイメージがつかない
C++の文法周りは最低限の知識はついたので、どちらかというとイディオムや設計まわりの知識不足がボトルネックになっている気がする
- C++の文法については、「独習C++」を一読し、練習問題や章末問題も全て解いた
- 設計については、まずはデザインパターンの勉強をしたいと思っている
  - 入門的に、まず「オブジェクト指向でなぜつくるのか」を読んだ。この本でデザインパターンという概念を知った
  - 次に、「オブジェクト指向のこころ」を読んでいる(進捗率20%ほど)。平易な表現でありながら、本質的なことが書かれているように感じる。とても面白い