Game A Week 振り返り (2024.11.24〆 囲碁de探索)

毎週ゲームを作る、Game A Weekの振り返り記事です！

作ったやつ

https://unityroom.com/games/igotan

アイデア

ボードゲームで広いフィールドを探索するゲームが楽しそうだなーと思いました。ルールが簡単にわかり、知っている事柄の発展を見ると感動するため。

↑以前の反省を踏まえて、広く知られている地形（日本、関東、アメリカ、グンマあたり）を地形の題材に。
ややマイナーな懸念がありつつも、慣れ親しんでいる囲碁をメインに据えることにしました。

うまくいったところ

ゲーム全体

前提として、ちゃんと完成させられなかったので、総じてうまくいってはいないですが…

日本を題材にすることで、感動ポイントは作れたと思います。
最初はここどこだろう…から始まり、九州か！ 本州入った！ …日本踏破した！ という感じで、興味を継続させながら、日本統一までできるといい体験になる。（日本統一まで作ってないけど）

アタリになったら逃げるというAIを入れるだけで、ちゃんと囲碁っぽい動きになったのもよかった。

視界という概念を入れるだけで、敵に変化をつけられた。
一つの石でも、こちらを向いてるのか、あっちを向いてるのかで、戦い方を変えられる

プログラミング面

VContainerのbuilderを動的に作って、EnemyGroupごとに別々のインスタンスを注入できたのはとてもよかった。

他ゲーム紹介メニューを最後に出せたのもよかった。

そこそこ適切にDisposeできた気がする。

Decoratorパターンも使えた。

課題

企画面

なるべく少ない石で敵を倒しきるというゲームが、まず成立してなかったように思います。
　・石数をシビアにしすぎると、覚えゲーのパズルになる
　・囲碁的に言えば殺している石に、とどめを刺さないといけなくて、石の無駄遣い感があった
　・本当は石の攻防のところも重要なメカニクスの一つにしたかったが、AIの都合でできなかった。
　　できたとしても、囲碁力に左右されすぎて微妙だったと思う
自分の囲碁力だと楽しめるゲームは作れそうだけど、世の人の囲碁力は千差万別すぎるのできつい。
将棋ローグライクなんかは、将棋力がなくてもそれなりに楽しめる気がする。

プログラミング面

囲碁のルールを実装し、AIも作らねばならないという時点で、ハードルはかなり高かった。

その上でも、石置き判定のクラス設計はちゃんとすべきだった。
　グリッドの情報を持っているIGridProviderを結構どこからでも呼んでしまったのだが、もっと呼べる人を抑えるべきだったのだと思う。
　Tilemapを使うと、どこに石があるというデータをTilemap側でいじりたくなるから、ModelがTilemapを見に行ってしまった。ここは分けた方がよかったかもしれない。

ボードゲームのAIも行き当たりばったりだったので、教科書的なものを見た方がよかった。

全体的に、不必要に丁寧にしている箇所と、事前の設計や計画が足りない箇所がある気がする。
　たとえば、この規模ならほとんどすべてのクラスにinterfaceをつけるのはやりすぎな気もするが、単一責務の原則に反している箇所も多々ある。
　脳死でクラスにinterfaceをつけるのではなくて、まず必要なinterfaceを考えて、それに応じて複数のinterfaceを持つクラスを作るというやり方がよいのか？

得られたこと

・初期化のタイミングの方針。とりあえずPostInitializeで組んでおき、InitializeとStartに分けるのがいいのではないか
・VContainerのLifetimeScopeの分割
・ゲームを成仏させられなかった痛み

次回に向けて

・バグの出た回数と原因をメモっておきたい。

いつかやりたい課題

・IDisposable完全に理解する
・gaw241110でPostProcessが動かなかった理由を解明
・タッチ機能スマホ対応