BLOG ARTICLE
Q：なぜUnityではなくReactで戦略シミュレーションゲームを作っているのか
筆者について: Webフロントエンドエンジニア(実務約10年)。個人開発で戦国風の戦略シミュレーションゲームを制作中。連載第2回です。
正直に言うと、Unityで作るつもりでした
ゲームを作ると決めたとき、頭にあったのは当然Unityでした。ゲームを作るならゲームエンジン。それが常識だと思っていたからです。
でも実際に選んだのは TypeScript + React。TypeScriptとReactに絞れば経験は1年ほどですが、その下にあるHTMLとCSS、JavaScript、そして画面の設計は10年分の蓄積があります。
きっかけは単純で、「こういうゲームを作りたい」とAIに相談しながら進めていたら、いつのまにか手元のWeb技術でプロトタイプが動いていました。正直に言えば、深い決断というより成り行きです。
ただ、3ヶ月作り続けた今になって振り返ると、この成り行きにはそれなりに利点もありました。戦略シミュレーションというジャンルは、Reactの宣言的UIや状態管理と噛み合うところがあります。この記事では、後から検証してわかった「Reactでもやれた理由」と、実際にぶつかった壁を書きます。
A：と、いろいろ理由を並べましたが、本音は未知のジャンルで作る自信がなかったからです。本音を白状したところで、次に行きましょう。
やってみると、意外と「戦える土俵」だった
Unityと比べて自分にとって何が違ったのかを整理すると、こうなります。
基準 | Unity等のエンジン | Web技術(React) |
|---|---|---|
配布 | ビルド・ストア経由 | URLを開けば動く。体験版の敷居が最低 |
10年の資産 | ほぼゼロから学習 | UI実装・状態管理・CSSの経験が全部効く |
1人での保守 | エンジン更新への追従が必要 | ブラウザ標準の上なので、作り直しを迫られにくい |
1つ目は、実際にそうなりました。インストールもアカウント登録もなしで、ブラウザで開けばそのまま遊べる体験版を公開しています
https://worldline-simulator.tanukicode.dev/
一番効いているのは2つ目です。ゲーム開発については完全に素人ですが、画面を作ることに関しては10年やってきました。Unityを選んでいたら素人として始めていたはずのところを、気づけば経験者として始められていた。成り行きにしては、ずいぶん得をしたと思います。
もう1つあります。戦略シミュレーションの画面をよく見ると、その正体は「地図と、大量のパネル・一覧・フォーム」です。60fpsで弾が飛び交うアクションゲームとは違って、画面のほとんどがUIでできています。ここはWebフロントエンドがふだん相手にしているものと、そう変わりません。
選んだ構成
項目 | 選定 |
|---|---|
言語 | TypeScript |
UI | React + Vite |
描画 | DOM + SVG(地図)。※後にCanvas併用へ。これは別記事で |
ゲームデータ | すべてJSON(武将・勢力・イベント・ルール) |
乱数 | シード固定(同じ条件なら同じ結果を再現できる仕組み) |
データをすべてJSONにしたのは、第1回で書いた「いろんな人が物語を作れるツールにしたい」という目標のためです。コードを書かなくても、データを差し替えれば別のゲームになる。その構造を最初から敷いておきました。
個人開発でも「設計の仕切り」を機械に守らせる
構成よりも大事にしたのは設計のほうです。コードをゲームロジック層(ドメイン)とUI層に分け、UI層からしかドメインを参照できない一方通行にしました。画面の都合がゲームルールに漏れてこないようにする仕切りです。
ポイントは、この仕切りを人間の注意力ではなくビルドに守らせているところです。違反するimportを書くと build が失敗するスクリプトを仕込んであります。
一人で作っているとレビュアーがいません。だから「気をつける」ではなく「破れない」ようにしておく。第1回で書いた規律の自動化の、設計版だと思ってもらえれば近いです。この分離のおかげでUIを一切起動せずにゲームロジックだけを数百ターン自動実行できるようになり、それが後のAI協業(第3回)の土台になりました。
通用した点、しなかった点
通用した点:
- 宣言的UI。「状態が変われば画面が変わる」というReactの考え方は、ターン制ゲームとよく噛み合いました
- コンポーネント設計・CSS。パネルだらけのゲーム画面で10年の蓄積がそのまま効きます(デザインの善し悪しはさておき、組み立てる側の技術です)
- TypeScriptの型。武将・勢力・イベントのデータ構造を型で守れます
しなかった点(=壁):
- 描画性能。47都道府県と数百の表示物をSVGで動かしたら、パンとズームが目に見えてもたつきました。実測してCanvas併用へ移した話は、それだけで1本の記事になります
- 解像度対応。Webサイトのレスポンシブと、ゲーム画面の全解像度対応はまったく別物でした。これも後の記事で書きます
ここまでの実感としては、Webの技術は8割方そのまま通用します。残りの2割は確かに壁ですが、そこはWebエンジニアが仕事で使っている武器、つまり計測と段階的な改善で越えられる範囲でした。
次回: AIに書かせたコードをどう信用するか
このゲームは最初からずっとAIメインで開発しています。実装の多くはAI(Claude / Codex)に任せています。ただ、出てきたコードをそのまま信用しているわけではありません。次回は、テスト2,313ケースとシード固定のシミュレーション、それに多層の検証でAIの成果物を確かめ続けている仕組みの話をします。