4Hえんぴつ｜React＋TypeScriptでWeb RPGを作る
第1章「小さなWeb RPGを作り始める」
第2回：最初から全部作らないために決めたこと
1. 今回のテーマ
前回は、なぜ最初の開発対象をUnity＋C#ではなく、React＋TypeScriptによるWebアプリにしたのかを整理しました。
Webから始めると決めたあと、次に考えたのは、
「では、最初にどこまで作るのか」
でした。
RPGを考え始めると、作りたいものはすぐに増えていきます。
例えば、
- 複数の町
- 広い世界
- 多くの依頼
- 戦闘
- 装備
- アイテム
- キャラクター育成
- セーブ
- 物語の分岐
- さまざまなイベント
などです。
どれもRPGらしい要素です。
しかし、これを最初から全部作ろうとすると、
「ゲームとして面白いかを確認する前に、作るものだけが増えていく」
状態になりかねません。
そこで最初のWebプロトタイプでは、
何を作るかだけでなく、何を作らないか
を先に決めました。
2. 最初に確認したかったことは一つだった
今回作っている異世界ファンタジーRPG「冒険に行こう！」では、町から街道へ出て、途中で起きる出来事を解決しながら旅を進めます。
最初に確認したかったのは、次の流れでした。
町にいる
↓
依頼を受ける
↓
街道へ出る
↓
出来事が起きる
↓
行動を選ぶ
↓
結果が出る
↓
目的地へ着く
この記事では、ゲーム内の仕事を「依頼」と呼んでいます。
一般的なRPGでいうクエストに近いものです。
また「街道」は、町と目的地を結ぶ移動ルートです。
つまり最初の目的は、
大きなRPGを作ることではなく、この一連の流れがゲームとして動くことを確認すること
でした。
3. 最初のプロトタイプは4つまで小さくした
そこで、最初のWebプロトタイプを次の範囲まで絞りました。
町 1つ
街道 1本
依頼 1つ
イベント 1つ
「イベント」は、街道を移動している途中などで発生するゲーム内の出来事です。
例えば、
街道の途中で壊れた荷車を見つけた。
という出来事が発生します。
そこからプレイヤーが行動を選びます。
今回のプロトタイプでは、解決方法として、
戦闘
交渉
調査
を用意しました。
つまり、
一つの町から、一つの依頼を受け、一つの街道へ出て、一つの出来事を解決する。
まずは、これだけです。
4. 「少ない」と「足りない」は違う
最初の構成を見ると、
町が一つではRPGとして少なすぎるのでは？
と思うかもしれません。
実際、完成版として考えれば足りません。
ただし、プロトタイプの目的は完成させることではありません。
ここでいう「プロトタイプ」とは、
基本となる遊び方や仕組みが成立するかを確認するための試作品
です。
確認したいことが、
依頼を受ける
↓
移動する
↓
出来事に遭う
↓
選ぶ
↓
結果が変わる
なのであれば、最初の確認には町が10個ある必要はありません。
むしろ町が増えると、
- 町のデータ
- 接続する街道
- 依頼
- 解放条件
- セーブ状態
など、確認しなければならないものまで増えます。
そこで、
確認したいことに必要な最小数だけ置く
という考え方にしました。
5. 最初に作らないと決めたもの
範囲を小さくするには、
「作るもの」
よりも、
「今は作らないもの」
を決める方が難しいことがあります。
最初の段階では、例えば次のようなものを優先しませんでした。
- 大量の町
- 大量の依頼
- 大量のイベント
- 複雑な戦闘
- 大規模な世界マップ
- 本格的なキャラクター育成
- 大量のアイテム
- 完成した物語全体
- 高度なセーブシステム
- 将来プラットフォームへの対応
これらが不要なのではありません。
今確認したいことには、まだ必要ない
と判断しただけです。
この区別は、個人開発ではかなり重要だと感じています。
6. 「いつか必要」と「今必要」を分ける
開発中に、
あとで必要になるから、今のうちに作っておこう
と考えたくなる場面があります。
もちろん、後から変更するのが大変な部分は先に考えておく必要があります。
ただ、すべてを先回りすると、プロトタイプが完成する前に設計対象が増え続けます。
そこで今回の開発では、
今の検証に必要
↓
作る
将来は必要だが、今の検証には不要
↓
いったん作らない
と分けました。
例えばセーブ機能も、最初から大規模な保存方式を作るのではなく、Web版では小さな保存から始めています。
その後、実際にゲームが大きくなってから、
- 複数セーブスロット
- 街道途中からの再開
- セーブ形式のバージョン管理
などが必要になりました。
必要になった時点で、設計を広げています。
7. 一番小さくしても「一周」は残す
ただし、小さくすることだけを優先すると、
何を確認したかったのか分からない試作品
になってしまいます。
例えば、
町画面だけ作る
でも画面は動きます。
しかし、それだけでは、
「依頼を受けて冒険へ行くゲーム」
が成立するかは確認できません。
そこで今回のプロトタイプでは、規模は小さくしても、
ゲームの開始から結果まで一周できること
は残しました。
イメージとしては、
町
│
├─ 依頼を受ける
│
▼
街道
│
▼
イベント
│
├─ 戦闘
├─ 交渉
└─ 調査
│
▼
結果
│
▼
目的地
です。
横に広げるのではなく、
最初は細くても、縦に最後まで通す
という考え方です。
8. 小さく完成させると、次の問題が見える
実際に一周できるプロトタイプを作ると、
設計中には見えなかった問題が見えてきました。
例えば、
- 一度選んだ選択肢をどう扱うか
- イベントを複数にするとどうなるか
- 途中で保存したらどこへ戻すか
- 失敗した依頼をどう管理するか
- プレイヤーのHPを次の画面へどう引き継ぐか
などです。
もし最初から大量の町やイベントを作っていたら、
「データが多いからおかしいのか」
「基本設計がおかしいのか」
の切り分けも難しくなっていたと思います。
小さく始めたことで、
一つずつ問題を見つけやすくなった
という効果がありました。
9. その後、実際にMVPへ広げた
プロトタイプで基本の一周を確認したあと、Web版をMVPへ広げました。
「MVP（Minimum Viable Product）」は、実際に使って試せる必要最小限の機能を持った製品を指します。
プロトタイプでは、
町 1つ
街道 1本
依頼 1つ
イベント 1つ
だったものを、その後、
- 複数の町
- 複数の依頼
- 複数の街道
- 複数のイベント
へ広げています。
ここで重要だったのは、
最初から複数に対応できていたわけではない
ことです。
一つだったものを複数へ増やすと、
- データの持ち方
- 状態の持ち方
- イベントの順番
- 保存する情報
などに問題が出ました。
この「1から複数へ増やしたときに何が起きたか」は、この連載の後半で何度も登場します。
10. 個人開発で使っている判断基準
今回の経験から、最初の範囲を決めるときには、次の3つを意識しています。
その機能がないと、今回確認したいことを試せないか
試せないなら、作る候補です。
なくても確認できるなら、後回しにできます。
最後まで一周できるか
機能数ではなく、
開始から結果まで到達できるか
を確認します。
増やす前に、一つで問題を見つけられないか
町を10個作る前に、町1個でデータの持ち方を確認します。
イベントを20個作る前に、まず1個を最後まで動かします。
この考え方は、ゲーム以外のWebアプリでも使えると思います。
11. 今回のポイント
今回のポイントは3つです。
- 最初のプロトタイプでは「作るもの」だけでなく「今は作らないもの」を決めた
- 規模は小さくしても、ゲームの開始から結果まで「一周」は残した
- 一つで動かして問題を見つけてから、複数へ広げた
最初の目的は、
たくさん作ることではなく、早く学べる状態を作ること
でした。
結果として、小さなプロトタイプから始めたことで、MVPへ広げたときに起きる問題も一つずつ確認できるようになりました。
この記事を最後まで読んでいただき、ありがとうございます。
「いいね」を押していただけるとうれしいです。これからの記事づくりの励みになります。
もし気に入っていただけましたら、フォローもよろしくお願いします。
12. 次回
次回は、
町1つ、街道1本、依頼1つ――RPGの最小プロトタイプを作る【第3回】
です。
今回は「なぜ小さくしたのか」という考え方を中心にしました。
次回は、実際にその最小構成を、
Town
Quest
Road
Event
というゲームデータとしてどうつなげたのかを見ていきます。
この連載の現在位置
第0章 この連載について
第1章 小さなWeb RPGを作り始める
- 第1回 なぜWebから始めたのか
- 第2回 「最初から全部作らない」ために決めたこと ← 今回
- 第3回 町1つ、街道1本、依頼1つの最小プロトタイプ
- 第4回 画面とゲーム状態をどう分けるか
前の記事
第1回 React＋TypeScriptでWeb RPGを作っています――なぜWebから始めたのか
次の記事
第3回 町1つ、街道1本、依頼1つ――RPGの最小プロトタイプを作る
公開後、この場所にリンクを追加します。
連載トップ
連載全体のロードマップ
- 第0章 この連載について
- 第1章 小さなWeb RPGを作り始める ← 現在
- 第2章 RPGをデータとして設計する
- 第3章 街道とイベントを設計する
- 第4章 戦闘・交渉・調査と状態管理
- 第5章 セーブと再開
- 第6章 実際に起きた不具合と改善
- 第7章 テストと品質管理
- 第8章 Web公開・互換性・永続化