Development log

これは実装完了の記事ではなく、長期成長をどう作るかを壁打ちして保存した企画候補です。セーブ機能へ進む前に、転生すると何が消えて何が残るのかを先に整理しました。

成長を三つの時間軸に分ける

成長は、ランブルの中だけで有効なもの、ひとつの人生のあいだ続くレベルやパラメータ割り振り、転生後も残る長期成長の三層に分けます。現時点の企画値ではレベル上限を50前後、レベル 20以降を転生可能な範囲とし、レベルアップごとにパラメータへ割り振るポイントを1つ得る案を置いています。これらの数値はまだ調整前です。

持ち越すか、ポイントへ変えるか

転生時に持ち越さない装備や家具は、ただ消すのではなく転生ポイントへ変換する案にしました。装備や家具は購入済みの持ち越し枠の範囲で選び、転生用の重要アイテムなどは枠を使わず残せる扱いも用意します。今世だけの成長アイテムなどはリセット対象です。

転生後の選択肢も、あとから調整できる形にする

転生ポイントの交換候補には、初期パラメータの割り振りポイント、装備や家具の持ち越し枠、獲得経験値補正、選択肢の成功率補正などを置いています。将来ジョブを導入する場合は、その解放も候補です。交換回数に上限があるものと、何度でも交換できる代わりに必要ポイントが増えていくものを両方扱えるようにします。

転生条件、ポイント計算、交換価格はいずれも企画段階です。ゲームルールを確定してから保存対象を決め、最後にセーブや再開の仕組みへ接続する順番で進めます。

ゲームを保存できるようにする前に、「何を保存するのか」を先に決めました。保存先の仕組みから作り始めると、ランブル中だけの状態までうっかり持ち越したり、逆に残すべき成長を落としたりしやすいためです。

残す状態、残さない状態

持ち越す対象は、帰還済みのアイテム、装備しているもの、配置した家具、メイドさんの恒久的な基礎パラメータです。反対に、現在のランブルの進行、途中で拾っただけのアイテム、ランブル中だけの成長、乱数の進行状態、選んだ難易度などは次回へ持ち越しません。

この境界をデータ化し、保存用の形へ変換してから元へ戻しても同じ状態になること、失敗時に一時的な状態が混ざらないこと、存在しない装備参照を正常な保存データとして扱わないことまでテストしました。

保存先は、ルールが固まってから

今回はクラウド保存や認証にはまだ接続していません。先にゲーム側の持ち越しルールを固定したことで、次に保存先を選ぶ時も、ゲームのルールと外部の仕組みを切り分けたまま進められます。

装備や成長で能力を上げる意味ができたので、次は「どこへ挑むか」にも意味を持たせました。難易度をゲーム内容側の設定として持たせ、同じメイドさん、同じ選択肢でも挑戦する難易度によって成功率が変わるようにしています。

まずは三段階の基準線から

現在の基準値はEASYが成功率に+10%、NORMALが±0%、HARDが-10%です。同じ条件で比較してもこの差が反映されることを、自動検証とブラウザ上の両方で確認しました。成功率の下限・上限もこれまでどおり守られます。

この数値は最終バランスではありません。難易度の設定をゲーム内容側で調整できる形にしたので、今後イベントごとの危険度などを増やす場合も、ランブルの基本処理を作り直さずに調整できます。まずは攻略の強弱を作るための基準線を置いた段階です。

能力値が選択肢の成功率へ届くようになった次は、ランブルで得たものが本当に次の挑戦へ返ってくるかを一周通して確認しました。個別の仕組みはそろっていても、「拾う → 帰る → 組み直す → また挑む」がつながらなければ、ゲームの循環にはなりません。

帰るか、続けるか

チェックポイントでは、そのまま先へ進むか、そこで帰還するかを選べます。帰還できた場合は、そのランブルで拾ったアイテムを手元へ移します。一方、失敗した場合はその回で拾ったアイテムを失い、以前から持っていたアイテムや組み直した状態までは失わないようにしました。

持ち帰ったものが、次の挑戦を変える

帰還後に拾った装備や家具を使うと、メイドさんの基礎パラメータと派生能力が変わり、その差が次のランブルの成功率へ反映されます。途中帰還、最後まで完走、失敗のどの終わり方からでも次のランブルへ戻れることも確認しました。

自動テストだけでなく実際のブラウザ上でも、帰還して拾ったものを装備し、次のランブルで能力値と成功率が変わるところまで確認できました。これで「挑戦して、持ち帰って、組み直して、また挑む」という基本の一周が形になりました。

これまでも装備や家具、ランブル中の成長で基礎パラメータは変化していましたが、その数値が選択肢の成功率へ直接つながってはいませんでした。今回はSTRやINTなどから算出する「解析・接客・整備・出力・耐久」を、選択肢ごとの成功率へ接続しました。

選べる条件と、成功しやすさを分ける

最初の実装では、特定の能力値を満たした時だけ選べる選択肢にだけ成功率補正がかかっていました。ブラウザで確認すると、普通の選択肢は能力が伸びても基準成功率のままです。そこで「選択できる条件」と「成功率が参照する能力」を別の情報として持たせ、すべての選択肢がいずれかの派生能力を参照する形へ直しました。

修正後は、装備で基礎パラメータが上がった場合も、ランブル中の成長で上がった場合も、派生能力を経由して成功率が変わることを確認できました。これでメイドさんを組み直した結果とランブル中の成長が、実際の攻略結果につながり始めました。

動いたら、今度は強すぎた

仕組み自体は狙い通りでしたが、能力が高くなると成功率が上限付近まで届きやすく、かなり簡単になります。今回は接続そのものの検証を完了とし、成功率の係数は今後のStage Difficultyと合わせて調整することにしました。

Main値をメイドさんの能力へつないだだけでは、アイテム全体の品質ルールはまだ途中でした。Rarityが上がると何が変わるのか、Subはどこへ付くのか、UNIQUEを普通の抽選から出してよいのかを整理する必要がありました。

それぞれの役割を分ける

RarityごとにMainとSubの範囲を持たせ、装備や家具だけがランダムな能力補正を受けるようにしました。その他のアイテムには同じ仕組みを無理に付けません。UNIQUEは通常のRarity抽選から偶然出るものではなく、ゲーム内容側で定義する特別なアイテムとして分けています。

さらに大量のアイテムをSeed付きで生成し、Rarityの出方やMain / Subの平均をまとめて確認できるようにしました。これで『数字が付いている』状態から、拾った時に違いを見比べる意味があるアイテム体系へ一段進みました。

Engineとゲーム内容を分けても、コードが別ファイルになっただけでは意味がありません。本当に分離できたかは、実際にゲーム内容を増やす時にEngineへ手を入れずに済むかで確かめることにしました。

実際にゲーム内容だけを増やしてみる

ランブル、アイテム、メイドさんの組み替えを支えるEngineは変更せず、新しいイベント「記録庫の信号異常」と、回収できる装備「信号解析レンズ」を追加しました。イベントの選択肢からレンズを拾い、そのレンズを持っている時だけ使える別の選択肢まで、ゲーム内容側の追加だけでつなぎました。

Human Previewでは実際にイベントが出て、選択肢から信号解析レンズを回収できるところまで確認できました。分離は「構造上分かれている」だけではなく、「ゲーム内容を増やす時にEngineを触らなくていい」ところまで成立しました。

能力値を成功率へつなげれば、装備や家具で整えた能力やランブル中の成長が攻略に効くようになります。ただ、確率を先に入れると、テストで想定外の結果が出た時に、仕様の問題なのか単に乱数を引いただけなのか切り分けにくくなります。

先に検証できる状態を作る

そこで成功と失敗を意図的に再現できる入口、任意の能力値で選択肢の条件を試せる仕組み、複数のランブルをまとめて見るためのbatch実行を先に用意しました。通常プレイのSeed再現性はそのまま残しています。

この土台があれば、次に選択肢ごとの参照能力と確率式を入れた時も、能力値を変えた結果がランブルの成否へどう効いたのか追いやすくなります。ゲームらしい不確実さを足す前に、まず原因を追える状態を作る順番にしました。

ここまで作ってきた仕組みはMAID’S RAMBLE専用のコードとしても動きます。ただ、Seed付きの進行、アイテム生成、装備や家具の集計まで全部ゲーム固有の名前と結びついていると、次のゲームではまた作り直すことになります。

EngineはSTRもメイドさんも知らない

そこで、ランブルの進行、アイテムの抽選、装備や家具から補正を集める部分をEngine側へ分けました。EngineはSTRや解析といった具体的な能力名を知りません。どんな能力があり、何という装備やイベントを使うかはゲーム内容側から渡します。

分離したあとも同じSeedで同じ挙動を再現できることを確認し、アイテムをまとめて生成して分布を見るアイテム検証用のテストも追加しました。この時点では『分けられた』ところまでで、本当にEngineを触らず新しい内容を増やせるかは次の実地検証で確かめることにしました。

数字が違うだけでは意味がない

拾ったアイテムにはMain値が付いていましたが、この時点では表示されるだけで、同じBaseItemならメイドさんへの補正は同じでした。数字に差があっても装備や家具の選び方が変わらないなら、拾った個体を見比べる理由としては弱いです。

Mainをメイドさんの能力へつなぐ

そこでBaseItemごとの補正の方向性はそのままに、Main値を補正強度へ効かせる形にしました。Main 10を基準に、値が低ければ弱く、高ければ強くなります。同じ装備でもMainが違えば、ランブル前の基礎能力と派生能力のPreviewに差が出ます。

これでMainは見た目の数値ではなく、どの個体を使うか考える材料になりました。RarityやSubはまだ別なので、アイテムの個体差全体の設計は次の工程で詰めていきます。

最初の成長は、特定の条件を満たしたかどうかをタグで持つ簡単な仕組みでした。でも装備や家具でメイドさんを組み直し、ランブル中にも成長するゲームにするなら、能力の差を数字として扱える方が調整しやすくなります。

7つの基礎能力と5つの派生能力

基礎能力はSTR / DEF / INT / MND / DEX / SPD / CHRの7つにしました。そこから解析、接客、整備、出力、耐久の5つを計算します。初期値はすべて10で、複数の基礎能力を組み合わせて派生能力を出す形です。

装備や家具による補正はランブル前の能力へ入り、ランブル中に得た成長はその上へ積み重なります。次のランブルでは途中の成長だけをリセットして、今の装備や家具の効果をもう一度反映します。これで『組み直して出発する』ことと『ランブル中に育つ』ことを同じ能力モデルで扱えるようになりました。

装備や家具は、置けるだけではゲームの選択になりません。そこで11の装備枠と6×6の部屋を作り、何を装備したか、どの家具を置いたかがランブル中の選択肢へ実際に効くようにつなぎました。

組み替えると、できることが変わる

たとえば特定の頭装備があれば使える選択肢や、工具台を置いている時だけ使える選択肢を用意しました。ランブル開始後は装備や家具を変更できないので、出発前にどうメイドさんを組むかがそのまま攻略へつながります。

Previewで見つかった穴も直す

実際に遊ぶと、同じSeedで拾った同じアイテムがInventory上で同一人物のように衝突する問題や、家具を配置できるのにランブル中では家具を拾えない問題も見つかりました。どちらもその場で修正し、同じアイテムを別個体として扱えること、拾った家具を持ち帰って配置できることまで確認しました。

画面はルールを持たない

Headless Coreが動いたので、次はブラウザから触れるようにしました。ただし、成功率や選択肢の可否を画面側で計算し直すことはしません。画面は選んだ内容をCoreへ渡し、返ってきた状態を表示するだけにしました。

Seed入力、イベント表示、3つの選択肢、結果表示、Checkpointでの帰還か続行、失敗・持ち帰り・完走までを最小UIへつなぎました。大きなFrameworkを先回りで入れず、まず一周遊べることを優先しています。

最初の10イベント完走

CloudflareのPreviewで実際にランブルを開始し、Event 10 / 10まで進んでCOMPLETEDになるところまで確認できました。ここで初めて、画面なしで検証していたCoreが、そのまま人が遊べるゲームへつながりました。

企画が固まったあと、最初に画面を作るのではなく、ゲームのルールだけを先に動かすことにしました。画面側の都合でゲームのルールが決まってしまうのを避けたかったからです。

同じ条件なら、同じランブルになる

Seed付きの乱数、イベント抽選、3つの選択肢、稼働度、5イベント目のCheckpoint、10イベント完走、途中で拾ったアイテムと恒久Inventoryの境界までをHeadless Coreへまとめました。同じSeedと同じ入力なら、同じイベントと結果を再現できます。

失敗した時はそのランブルで拾ったアイテムだけを失い、持ち帰りに成功したものは残ります。画面がなくても一周の流れを最後まで検証できるようになったことで、その後のUIはこのCoreを表示して操作する役に集中できるようになりました。

合意していても、違うものは違う

最初の企画はAI同士のレビューを重ねて一度まとまりました。ただ、最終レビューで見ると、ランブル中に装備を替えながら進む方向が強く、作りたかった遊びとは少し違っていました。そこで、合意済みという理由でそのまま進めず、企画をいったん戻すことにしました。

出発前にメイドさんを組み直す

新しい軸は、ランブルへ出る前に装備や家具でメイドさんを組み直し、途中で拾ったアイテムを持ち帰ることです。失敗すれば、そのランブル中に拾ったものは失います。10イベントの途中には固定のCheckpointを置き、そこで帰るか先へ進むかを選べる形にしました。

このやり直しで、アイテムを拾うこと、持ち帰るか賭けること、帰ったあとにメイドさんを組み直すことが一本の循環になりました。AIの合意より、実際に作りたい遊びを優先したところからMAID’S RAMBLEの土台が始まっています。