Connect paid food purchasing, kitchen production, and porter deliveries
This commit is contained in:
Takeshi
@@ -238,3 +238,12 @@
|
||||
- 保存互換: StaffService Snapshotをversion 4とし、継続計画を保存する。旧version 3の保存は計画なしで読み込み、既存の人物・単日Shift・給与履歴を保持する。旧保存の最終勤務先を推測して全員へ繰返し予定を付与しない。読み込み後に通常UIで配属を指定した人物から、新しい継続計画を使う。
|
||||
- 影響: 翌日出勤、再配属、夜勤の日付跨ぎ、未配属、作業中拒否、途中Save復元を受入へ含める。施設別給与は保存した実勤務区間を根拠とし、現在の計画だけから過去分を再分類しない。
|
||||
- 今回の範囲外: 施設価格、受付の直接収入、宿泊料金の決済・売上記帳タイミングは改定しない。開業ガイドと帳簿は現在のサービス・台帳・06:00決算を読み取って表示する。これらと仕様正本の照合・変更はPLAY-04／PLAY-05で別に判断する。
|
||||
|
||||
## D-033 P1の厨房供給は既存レシピを維持して通常操作へ接続する
|
||||
|
||||
- 状態: 採用（2026-09-09。供給・製造のP1調整値。3営業日を含む通常プレイの受入は別途検証する）
|
||||
- 判断: 既存の `ingredient/raw_food` 4個から `ingredient/basic_meal` 4個を15稼働分で作るレシピを維持する。厨房の継続生産計画は客や客財布を要求せず、入力予約、製造進捗、完成時消費と出力を独立して扱う。無人、停電、到達不能、休業時は進捗と予約を保持し、材料の期限切れはバッチ失敗として予約を解放する。出力容量が足りなければ材料を消費せず待つ。
|
||||
- 調整値: 食材は1個3G・重量1・期限1,440分、基本料理は重量1・完成後期限720分。保管容量は倉庫100、厨房40、食堂24の重量とし、施設の接客定員とは分ける。厨房への食材補給目標は8個、完成料理の目標は既定8個・上限16個（4個単位）とする。これらは `SupplyCatalog` に明記した暫定値であり、価格バランスの合格を意味しない。
|
||||
- 人員データ: 倉庫の必要役割を既存雇用候補の `porter` に合わせる。食堂は既存の `cook`／`server` を維持して `attendant` を追加し、接客係Iris／Junoも配属できるようにする。候補に存在しない役割だけを要求して厨房と食堂の同時営業を阻む状態を解消する。
|
||||
- 保存と撤去: 生産計画、進行中バッチ、予約ID、進捗と時刻を保存し、復元済みInventoryの所有者・品目・数量・依頼者・用途・期限と照合する。有効な生産計画または進行中バッチがある厨房は解体対象にできない。停止済みかつバッチがない計画は解体成功後に削除する。
|
||||
- 仕様差: 正本の「料理ポイント＋食器在庫」、食器・清掃用消耗品の購入と消費、廃棄物回収の通常操作は後続の仕様調整へ残す。今回の基本料理を料理ポイントへ暗黙に読み替えない。食堂の現行15分／35Gと正本45分／25G、受付の直接収入、宿泊決済時刻、倉庫のRank解禁条件も、この供給接続では改定しない。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# 制作課題台帳
|
||||
|
||||
更新日: 2026-09-09。承認済み [全体制作計画](DEVELOPMENT_PLAN.md) の実行台帳。基準はドット断面版コミット `423fd6dd2e75da926e38b35ac8c435e462b168d9`、制作ブランチは `codex/first-operating-loop`。P1の通常開業ガイド・継続配属API／パネル・日次帳簿を接続し、通常初期予算での最小宿を単日受入・専用保存復元で確認した。全自動テストの構成ターゲットは成功終了。補給・厨房・物流を含む3営業日は未合格。部品の接続、単日成立、段階全体の完成を区別する。
|
||||
更新日: 2026-09-09。承認済み [全体制作計画](DEVELOPMENT_PLAN.md) の実行台帳。基準はドット断面版コミット `423fd6dd2e75da926e38b35ac8c435e462b168d9`、制作ブランチは `codex/first-operating-loop`。P1の通常開業ガイド・継続配属API／パネル・日次帳簿を接続し、通常初期予算での最小宿を単日受入・専用保存復元で確認した。全自動テストの構成ターゲットは成功終了。その後、有料仕入れ・厨房の自律生産・実配送を通常の商品UIへ接続した。3営業日の最終受入は進行中。部品の接続、単日成立、段階全体の完成を区別する。
|
||||
|
||||
## 状態の読み方
|
||||
|
||||
@@ -33,10 +33,10 @@ P0の保存物はGit管理対象の制作ファイル。`.godot/`、`build/`、`
|
||||
|---|---|---|
|
||||
| PLAY-01 | **最小ループ実装済み・単日確認**。初期Gold 5,000／資材50、通常UIの建築経路で受付1・一般客室2・通路7、アカネ雇用・配属、自然来客の宿泊320G、翌06:00決算まで確認。`test_first_operating_day.gd` | 受入は見学Fixture・無料在庫・客挿入なし。**3営業日未検証／バランス調整残**。受付売上6,020G等の数値を正本と照合し、補給・厨房・配送込みの序盤へ広げる |
|
||||
| PLAY-02 | **通常UI接続済み・個別API103項目／単日確認**。雇用済み一覧、配属・再配属・未配属、DAY／NIGHT継続計画、変更不可・経路・定員等の理由、予約Commandと保存復元。StaffService v4、D-032 | 実通勤と到着後の稼働はMOVE-07へ分離。現在は経路存在を検証して論理配属し、人物位置は変えない。長期の複数施設・人員不足対応は3営業日受入で検証 |
|
||||
| PLAY-03 | `inventory_service.gd` のStack・予約・期限、`logistics_dispatcher.gd`、Runtimeの配送Command、`test_inventory_logistics.gd` | **画面へ未接続／未検証**。発注費を支払う仕入れから倉庫→厨房→接客施設までを通常操作へ接続。欠品、容量超過、期限切れ、配送失敗を同じ経営ループで再現する |
|
||||
| PLAY-04 | 厨房・食堂DefinitionとFacility Service／Inventory Callbackが存在。見学は食堂へ `ingredient/basic_meal` を32個支給する | **仕様との相違／画面へ未接続**。食材消費と仕様の料理ポイント／食器を照合する。客の注文に依存しない厨房生産の入口と材料→料理の扱いを決定し、実配送を含む通常運営へ接続する。見学支給は完成の根拠にしない |
|
||||
| PLAY-03 | **通常UI接続済み**。完成倉庫への有料購入、容量・期限・予約、実porter TaskとPathによる倉庫→厨房→食堂。物流81項目、管理処理84項目、商品UI37項目の回帰 | 仕入れは倉庫への即納。外部業者の納期、継続自動購入、複数品目、正本の食器・消耗品は後続。経路断・満杯・腐敗・担当不能での保持／再試行／返送を検証 |
|
||||
| PLAY-04 | **自律生産接続済み・140項目確認**。明示設定した厨房で原料4→料理4、15稼働分、目標在庫、入力予約・出力容量・期限・中断復帰を扱う。見学用の無料在庫に依存しない | **仕様差をD-033で明記**。今回の原料／基本料理を維持し、料理ポイント＋食器、食堂価格・所要時間との統一は残す |
|
||||
| PLAY-05 | **日次帳簿UI接続済み・単日確認**。06:00営業日、入出金と建築、確定売上・運営費・給与・利益・前日差・未払・施設別損益を表示。翌朝給与120G、未払0、照合一致 | **操作未接続／仕様差・調整残**。価格・営業／休業Policy UI、受付の直接収入、宿泊の決済・記帳時点、維持費分類を正本と照合。受付売上6,020G・全利益6,040Gは製品バランス合格ではない |
|
||||
| PLAY-06 | **基礎実装済み・単日Save復元確認**。手動1枠と世代保存に加え、単日受入の専用 `user://tests/first_operating_day_<process_id>/restore-check` から配属・決算・開業達成を復元 | **未検証**。通常3日運営の建設中・配送中・行列中を保存し、再起動後の一致を確認。手動10枠UIは別途制作 |
|
||||
| PLAY-06 | **Runtime v7と配送途中Save復元を確認**。厨房計画・バッチ、Request・Task・carrier・貨物・予約を照合。旧v6移行20項目、商品UIの待機購入も再読込後に一度だけ確定 | 建設中・行列中・配送中を組み合わせた再起動の人手試遊、手動10枠UIと製品の保存導線は残る |
|
||||
|
||||
確認済みの単日経路: 通常初期予算→建設→アカネの日勤配属→自然来客宿泊→翌06:00給与・決算→専用保存復元。`make test-opening` で再現し、`make capture-opening` は `artifacts/first-operating-day/{opening,staffed,first-close}.png` を出力する。建築は現金出金、営業成績は確定損益として分離した。最終UIはPixel238・Dashboard121・Staff44・開業35項目が合格し、既存全自動テストの構成ターゲットも成功終了した。詳細は [P1単日検証記録](qa/P1_FIRST_OPERATING_DAY.md) を参照する。
|
||||
|
||||
@@ -62,7 +62,7 @@ P0の保存物はGit管理対象の制作ファイル。`.godot/`、`build/`、`
|
||||
| LIFE-02 | **試作実装済み／専用素材未制作**。Kenney静止画の足スライス・上下動・左右反転。衣服の継ぎ目修正済み | 専用歩行・作業フレームを共通人物で確認し、縮小、拡大、混雑、職種識別を満たしてから展開 |
|
||||
| LIFE-03 | **一部実装済み**。`pixel_tower_art.gd` の施設別家具、昼夜背景、世界樹の枝葉。現在の対象はMVP16施設 | 種類、営業、混雑、故障を家具と状態で識別できること。計画の施設数はMVP16種へ統一済み |
|
||||
| LIFE-04 | **素材一部導入／音未接続**。Kenney Tiny Town／Tiny Dungeonの公式素材とCC0原文保存 | UI音・環境音をKenney優先で選定し、音量設定と頻発音の重複抑制を確認 |
|
||||
| UX-01 | **一部実装済み・通常UI接続**。配置・掘削Preview、停止理由、待機・人員、配属・勤務変更、日次帳簿 | 在庫・欠品・接続、価格や営業方針などの対処を通常画面から完結させる |
|
||||
| UX-01 | **一部実装済み・通常UI接続**。配置・掘削Preview、停止理由、待機・人員、継続配属、日次帳簿、有料仕入れ・厨房設定・配送理由 | 価格・営業方針の設定と、初見プレイヤーが各理由から対処できる導線を仕上げる |
|
||||
| UX-02 | **最小ガイド実装済み・単日確認**。実状態に応じる6段階、通常操作へのボタン、折り畳み、達成履歴・Save復元 | Day 1〜5解禁との整合、スキップ、複数失敗からの回復、初見30分で改善まで到達する試遊は残る |
|
||||
| UX-03 | **一部実装済み／未接続**。ホイール、中ボタン、Home、キーボード開閉、Pixel・カメラ回帰 | 中ボタンなし・トラックパッド代替操作、日本語可読性、拡大時のドット、色以外の状態判別を実入力で確認 |
|
||||
|
||||
@@ -100,5 +100,5 @@ P0の保存物はGit管理対象の制作ファイル。`.godot/`、`build/`、`
|
||||
|
||||
1. 通常UIの最小宿・翌朝決算・専用保存復元は単日確認済み。新しい配属、ガイド、帳簿を含む全体回帰の結果を確認して次の検証済みコミットを記録する。
|
||||
2. MOVE-01〜03の階間経路と基本昇降機、MOVE-07の実通勤・到着後稼働を統合する。現在の論理配属で人物移動を完成扱いにしない。
|
||||
3. PLAY-03〜05の発注・厨房生産・実配送・会計仕様差を解消し、通常3営業日を継続する。建設中・配送中・行列中の保存再開を含める。
|
||||
4. 通常開始と保存なし見学の両方で表示・操作を確認し、最小宿の成功をP1全体完成やWindows製品合格としない。
|
||||
3. PLAY-03／04の有料発注・厨房生産・実配送は接続済み。PLAY-05の価格・営業Policy・会計仕様を揃え、欠品・人員・経路の改善比較と初見試遊へ進む。
|
||||
4. 通常開始と保存なし見学の両方で表示・操作を確認し、最小宿の成功をP1全体完成やWindows製品合格としない。供給機能の最新検証は [供給検証記録](qa/P1_SUPPLY_CHAIN.md) を参照。
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
作成日: 2026-09-09
|
||||
基準: The Tower SPを参考にしたドット絵の断面経営ゲーム。ローカル制作版を正本とする。
|
||||
状態: 2026-09-09 ユーザー承認済み。P0の基準点整備を完了し、P1の通常営業の最小ループを実装・単日確認済み。補給・厨房・物流を含む3営業日は未合格。
|
||||
状態: 2026-09-09 ユーザー承認済み。P0の基準点整備を完了し、P1の通常営業の最小ループを実装・単日確認済み。有料仕入れ・厨房・実配送を通常UIへ接続し、部品・UI・配送途中保存の検証は合格。3営業日の最終受入を進行中。
|
||||
|
||||
## 1. 目指す体験と計画の前提
|
||||
|
||||
@@ -30,6 +30,8 @@
|
||||
|
||||
[IMPLEMENTATION_STATUS.md](IMPLEMENTATION_STATUS.md)、[PLAYTEST_GUIDE.md](PLAYTEST_GUIDE.md)、[UI_OPERATION_SPECIFICATION.md](UI_OPERATION_SPECIFICATION.md) はP0で現在のドット断面と開閉式UIへ同期した。現在の外観・操作は [PIXEL_TOWER_VISUALS.md](PIXEL_TOWER_VISUALS.md)、復旧方法は [RECOVERY_GUIDE.md](RECOVERY_GUIDE.md)、実装・未接続・仕様差・検証残は [DEVELOPMENT_BACKLOG.md](DEVELOPMENT_BACKLOG.md) に記録する。P1の最小営業は単日受入・専用保存復元を確認した。初期Gold 5,000／資材50から受付1・客室2・通路7・アカネ1人で、自然来客の宿泊売上320G、翌06:00の給与120G、未払0、帳簿照合一致。受付売上6,020G・全体利益6,040Gは価格・会計仕様の調整対象であり、バランス合格や補給・厨房・配送込みの3営業日完成ではない。最終の既存全自動テスト構成ターゲットも成功終了。詳細は [P1単日検証記録](qa/P1_FIRST_OPERATING_DAY.md) を参照。
|
||||
|
||||
追加進捗: 商品の3タブ、有料原料購入、厨房の自主生産、porterの実歩行による搬入・搬出、期限／容量／障害時の貨物保全を接続した。Runtime v7で厨房計画と配送途中の保存を扱い、旧v6も移行する。仕様差と検証範囲は [供給検証記録](qa/P1_SUPPLY_CHAIN.md) を参照。
|
||||
|
||||
## 3. 段階別の制作計画
|
||||
|
||||
| 段階 | 目的・主な成果 | 依存 | 完成条件 |
|
||||
|
||||
@@ -145,7 +145,7 @@
|
||||
- 掘削モードでは費用、入口接続、支保、Rank／運営gate、進捗を表示し、FRONT／BACK同時解放Commandへ接続する。
|
||||
- 雇用候補20人の氏名、役割、勤務帯、契約金、日給、4技能を表示。原子的な雇用、未払／破綻gate、二重クリック防止、予約実行結果、保存したCommand履歴との整合を扱う。その後のP1追加で、雇用済み人物の配属・再配属、DAY／NIGHTの継続勤務計画、未配属、反映予定と変更不可理由を通常UIへ接続した。配属先までの経路を検証するが、実通勤して到着してから稼働する経路は未統合。
|
||||
- 本番運営の明示起動、個人AP、未払給与、前日損益、要確認／破綻、失敗境界の再試行表示、foreground Eventの日本語Choice、下部の手動Save／Loadを接続する。P1追加で6段階の「開業の手引き」と、営業日選択、現金入出金、建築出金、確定損益、給与・未払、施設別損益、照合を示す帳簿を接続した。建築出金と営業利益を分け、内部のcost_of_goodsは雇用契約金等を含むため「運営費」と表示する。
|
||||
- 商品・探索・投資等の管理カテゴリは入口または準備中の案内に留まる。すべてのカテゴリを製品機能の完成として数えない。
|
||||
- 商品は有料仕入れ・厨房設定・実配送の3タブへ接続済み。探索・投資等の管理カテゴリは入口または準備中の案内に留まる。すべてのカテゴリを製品機能の完成として数えない。
|
||||
- 従来の大きな生成背景、施設アイコンによるマップ表現、人物Bust Marker、装飾Skinは現マップ表示に使用しない。小型の建築・管理・資源・操作アイコンは `VisualThemeProfile` の既存参照を残す。
|
||||
- 基準解像度1440×810、HiDPI、`canvas_items`／`expand`／fractional stretchは維持。Pixelの元画像にはMipmapを生成しない。旧UIの解像度別Layout試験と現在のPixel・カメラ試験は、実描画Frame性能とは別に評価する。
|
||||
|
||||
@@ -163,7 +163,16 @@
|
||||
- 受付売上6,020G、全体営業利益6,040Gという現結果はバランス合格ではない。受付の会計上の役割、価格、宿泊料金の決済・売上記帳タイミングは仕様との差を調整する必要がある。
|
||||
- 配属は繰返し計画をStaffService v4へ保存し、過去の勤務区間を保持してShiftを分割する。旧v3は計画なしで互換復元する。設計判断はD-032を参照。
|
||||
- `make test-opening` で単日受入、`make capture-opening` で `artifacts/first-operating-day/{opening,staffed,first-close}.png` を生成する。自動受入は通常UI処理を呼び出すもので、初見プレイヤーの試遊合格とは区別する。
|
||||
- P1全体は未合格。補給、厨房の自律生産、倉庫からの実配送、価格・営業方針、欠品からの回復を含む3営業日運営は残る。配属は経路存在の事前検証と論理確定であり、人物位置を変えず、職場到着後の稼働はMOVEへ追加する。
|
||||
- P1全体は未合格。供給経路は下記へ追加した。価格・営業方針、正本との会計統一、初見プレイヤーの3営業日試遊は残る。配属は経路存在の事前検証と論理確定であり、人物位置を変えず、職場到着後の稼働はMOVEへ追加する。
|
||||
|
||||
### P1追加：仕入れから食堂まで
|
||||
|
||||
- 商品パネルから完成倉庫へ調理用食材を1個3Gで有料購入し、現物と台帳費用を一括確定する。支払い失敗時は両方を戻す。
|
||||
- KitchenProductionService は客の注文なしで原料4→料理4を15稼働分で生産。自動ON/OFF、目標4/8/12/16、予約・期限・容量・職員・魔力・接続の待機を扱う。
|
||||
- SupplyLogisticsBridge は勤務中のporterへ実Taskを割り当て、荷元への歩行→積込→納品先への歩行→納品を実行する。満杯・経路断・担当不能では貨物を保持し、部分腐敗時は残った品を実際に荷元へ返す。
|
||||
- 配送中の保存、無効参照の拒否、厨房counterの再使用防止を含むRuntime v7を追加。旧v6以下は生産計画なしとして復元し、既存の物流Commandは維持する。供給配送の到着確認は手動advanceで迂回できない。
|
||||
- 倉庫の担当職種を実catalogのporterへ補正し、食堂はattendantも配属可能にした。設定値・正本の料理ポイント／食器等との差はD-033へ記録。
|
||||
- 部品・UI・通常運営の検証範囲は [供給検証記録](qa/P1_SUPPLY_CHAIN.md)。`make test-supply`、`make capture-supply` で再現する。
|
||||
|
||||
## 統合済みの運営縦断
|
||||
|
||||
|
||||
@@ -13,6 +13,9 @@
|
||||
| 建設済みの宿を見学 | `make preview-pixel` | 受付、食堂、厨房、客室、通路、実際の客・従業員を用意。保存なし |
|
||||
| 時間差の画像を出力 | `make capture-pixel` | `artifacts/pixel-tower/` にPNG 2枚と運営状態JSONを生成 |
|
||||
| 通常開業の単日受入 | `make test-opening` | 見学Fixtureなしで通常UIのCommand経路を使い、初売上・翌06:00・保存復元を検証 |
|
||||
| 仕入れ・厨房・配送をすぐ試遊 | `make preview-supply` | 初期予算から通常建設・実購入した宿を12:20まで進め、停止して開く。Spaceで再開。保存なし |
|
||||
| 有料仕入れ・厨房・配送の検証 | `make test-supply` | 通常予算から供給を接続し、配送途中保存と3営業日の運営を検証 |
|
||||
| 稼働中の商品パネルを撮影 | `make capture-supply` | 通常建設・実購入で用意した初日の仕入れ／厨房／配送をPNG出力 |
|
||||
| 通常開業の画面を出力 | `make capture-opening` | 同じ単日受入を描画し、開始・配属後・決算のPNGを生成 |
|
||||
|
||||
見学は実施設7件と通路、従業員4人をRuntimeコマンドで組み立て、食堂へ食材32個を用意した再現場面です。保存・読込・自動保存は無効で、通常の初期状態には反映しません。準備中は少し待ってから操作します。PNGの生成には描画可能なデスクトップ環境が必要です。
|
||||
@@ -31,6 +34,7 @@
|
||||
| 地下掘削モード | 下部の「掘削」、または `E` |
|
||||
| 雇用候補を開閉 | 左の「従業員」から「候補を見る」、または `H` |
|
||||
| 雇用済み人物の配属・勤務変更 | 左の「従業員」→「雇用済み」→人物・配属先・日勤／夜勤を選び「配属・勤務帯を変更」 |
|
||||
| 食材の仕入れ・厨房の自動生産・配送状況 | 左の「商品」→「仕入れ」「厨房」「配送」 |
|
||||
| 日次決算を見る | 左の「帳簿」。確定した営業日を選択可能 |
|
||||
| 開業ガイドを折り畳む | マップ左上の「開業の手引き」の見出しをクリック |
|
||||
| FRONT／BACK切替 | 下部の「客用・表層」「裏方・裏層」、または `Tab` |
|
||||
@@ -120,3 +124,16 @@ Windows書き出しコマンドの存在はWindows実機合格を意味しませ
|
||||
今回の到達点は、通常UIでの最小宿の単日成立です。仕入れ→倉庫→厨房生産→実配送→消費、価格・営業方針の操作、欠品や人員不足からの回復を含む3営業日はまだ完了していません。昇降機の運行・乗降と、配属先への実通勤も未統合です。
|
||||
|
||||
全Actorの14日実Tick、初見試遊、Windows実機での100客＋30従業員描画、保存枠・設定・専用アニメーション・音・本文も別途必要です。現在の単日受入や画像出力から製品完成を判定せず、[課題台帳](DEVELOPMENT_BACKLOG.md) の完成条件で進めます。
|
||||
|
||||
## 食材を仕入れて料理を提供する
|
||||
|
||||
初期の資材50で倉庫・厨房・食堂も建てる場合、客室はまず1室にします。受付1・客室1・食堂1・倉庫1・厨房1・職員ドア1で資材46を使用します。2室の開業例にそのまま追加すると資材が1不足します。
|
||||
|
||||
1. FRONTに受付・食堂、BACKに倉庫・厨房を建て、地表の職員ドアでFRONT/BACKをつなぎます。具体的な配置と職員5人の組合せは [供給検証記録](qa/P1_SUPPLY_CHAIN.md) にあります。
|
||||
2. 完工後、調理人を厨房、接客係2人を食堂、運搬係を倉庫へ配属します。倉庫の仕入れ自体は職員なしでも可能ですが、運ぶには勤務中の運搬係と通行可能な経路が必要です。
|
||||
3. 左の「商品」→「仕入れ」で倉庫と食材数量を選びます。まず40個なら120Gです。代金と残金を確認し「購入」を押します。
|
||||
4. 「厨房」で厨房を選び、自動生産を有効にし、目標を8個にして保存します。4個の食材を使う15分の調理が始まり、食堂の在庫が少なくなると運搬係が納品します。
|
||||
5. 「配送」で担当者・荷元・納品先・待機理由を確認します。材料不足なら仕入れ、人員不足なら勤務・配属、経路不足なら職員ドアと通路を確認します。積み込んだ荷物は、経路が修復されるまで担当者が保持します。
|
||||
6. 食材は24時間、料理は12時間で期限切れになるため、翌営業日にも必要量を仕入れます。仕入れ費用・給与・食堂売上は「帳簿」に反映されます。
|
||||
|
||||
厨房の自動生産を停止すると追加の原料補給と調理が止まります。予約済みの配送と、すでに作った料理の食堂への出庫は続きます。在庫・運搬中の荷物・有効な生産計画が残る施設は解体できません。
|
||||
|
||||
@@ -110,3 +110,13 @@ Runtimeでは00:00の暦日更新と、06:00の前営業日締め・朝運用を
|
||||
旧V3モック `assets/mockups/the-tree-main-gameplay-visual-mock-v3-tower-style.png` と旧画像制作仕様書は過去の資料として保存する。現在の画面を旧モックの装飾や常設パネルへ戻す基準にはしない。画像内の数値・施設寸法ではなく、正式DefinitionとWorldServiceの占有を正とする。
|
||||
|
||||
確認手順は [PLAYTEST_GUIDE.md](PLAYTEST_GUIDE.md)、実装と未接続の区分は [DEVELOPMENT_BACKLOG.md](DEVELOPMENT_BACKLOG.md) を参照する。
|
||||
|
||||
## 10. 商品・厨房・配送
|
||||
|
||||
左の「商品」は右パネルを開き、仕入れ／厨房／配送の3タブを切り替える。完成した倉庫・厨房を選び、仕入れは合計代金と購入後残金、厨房は現物在庫・生産状態・目標4/8/12/16を表示する。入力途中の数量と厨房別の設定は表示更新やタブ変更で失わない。
|
||||
|
||||
仕入れ・設定は正式Commandを1件だけ送り、待機中の同じ操作を無効にする。処理結果は固定位置の日本語ラベルに表示し、失敗時は入力を保持する。Save復元時もCommand Queueを参照し、二重購入を防ぐ。
|
||||
|
||||
配送は施設名、品目数量、担当者、状態、待機理由を表示する。現在の配送を優先し、完了履歴は直近10件まで表示する。食堂未建築でも厨房への配送は表示する。帳簿・従業員等と同時に常設せず、Escで閉じて断面へ戻る。
|
||||
|
||||
実装: `scripts/ui/supply_management_panel.gd`。検証: `tests/ui/test_supply_management.gd`。詳細と画面は [供給検証記録](qa/P1_SUPPLY_CHAIN.md) を参照。
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
# P1 有料仕入れ・厨房・実配送
|
||||
|
||||
更新日: 2026-09-09。承認済み計画 PLAY-03／04／06 の供給経路を統合した記録。
|
||||
|
||||
## 接続した挙動
|
||||
|
||||
- 左の「商品」から「仕入れ」「厨房」「配送」を操作する。既存のKenney素材・クリーム色の管理パネルと断面表示を維持する。
|
||||
- 完成倉庫に調理用食材を1個3Gで購入する。確定前に代金・購入後残金・保管上限を確認し、実在庫追加と台帳への費用記帳を同時に確定する。
|
||||
- 厨房の自動生産を有効にすると、倉庫から原料を補給し、勤務中の調理人が4個の原料から15分で4個の基本料理を作る。来客の注文を生産開始の条件にしない。
|
||||
- 運搬係の勤務・Task・Pathを使って、荷元へ歩く→積み込む→納品先へ歩く→納品する。運搬中の人物は既存の荷物表示と連動する。
|
||||
- 食堂の実サービスが納品された料理を消費し、売上を計上する。厨房停止後も、すでに作った料理の出庫は続けられる。
|
||||
- 食材は24時間、料理は12時間で期限切れになる。予約中の期限切れ、容量不足、経路断、人員不在は実在庫を保持した待機・再試行・廃棄へ接続する。積載中の経路断では荷物を持つ担当者を解除しない。
|
||||
- Runtime保存形式はv7。厨房計画・進行中バッチを保存し、物流・人物・予約・貨物の参照を照合する。v6以前は厨房計画なしとして移行する。
|
||||
|
||||
供給値の採用理由と正本との差は [D-033](../DESIGN_DECISIONS.md) を参照する。
|
||||
|
||||
## 再現方法
|
||||
|
||||
```sh
|
||||
make test-supply
|
||||
make test-ui
|
||||
make capture-supply
|
||||
make preview-supply
|
||||
```
|
||||
|
||||
`test_normal_supply_chain.gd` は通常Mainを起動し、初期5,000G・資材50から建設、採用、配属、購入の正式Commandを使う。人工の客・完成施設・在庫・無料資源を挿入しない。画面の購入・設定・Save復元は別の `test_supply_management.gd` で実Button／入力を操作する。
|
||||
|
||||
供給テストの配置はFRONTに受付 `(-8,0)`、食堂 `(2,0)`、客室 `(-8,2)`。BACKに倉庫 `(-8,0)`、厨房 `(2,0)`、職員ドア `(0,0)`。客室への通路はFRONT `(-4,1)` → `(-4,2)` → `(-5,2)`・`(-6,2)`。完成に必要な実時間を進めてから配属する。
|
||||
|
||||
アカネを受付、ジーナを倉庫、チカを厨房、イリスとユノを食堂へ日勤配属する。原料40個を購入し、厨房の目標在庫を8個に設定する。次の2営業日の06:00にも40個ずつ購入する。採用時の契約金と日々の給与も通常会計へ含める。
|
||||
|
||||
保存先はテスト専用 `user://tests/normal_supply_<process_id>/cargo`、その他の各テストもプロセス別の専用保存を使う。通常の手動保存や自動保存へ書き込まない。
|
||||
|
||||
`preview-supply` は初日の12:20で停止した試遊を開く。Spaceで再開し、商品・勤務・建設を試せる。手動保存・読込と自動保存は無効。
|
||||
|
||||
画像は `artifacts/supply-chain/{purchase,kitchen,delivery}.png`、3日運営の数値は `artifacts/supply-chain/normal-play-report.json`。`capture-supply` は初日の稼働場面を撮影して終了するため、3日間の受入そのものは `test-supply` の結果を見る。
|
||||
|
||||
## 検証結果
|
||||
|
||||
| 対象 | 確認結果 |
|
||||
|---|---|
|
||||
| 厨房の原料・生産・中断・期限・容量・復元 | 140項目 PASS |
|
||||
| Runtime v7／旧v6の移行・偽装旧保存拒否 | 20項目 PASS |
|
||||
| 実物流・途中保存・障害復旧・外部Command境界 | 81項目 PASS |
|
||||
| 有料購入・決済失敗・停止後出庫・返送容量・複数倉庫 | 84項目 PASS |
|
||||
| 商品UI・下書き・重複防止・待機購入Save復元 | 37項目 PASS、1280×720も実描画確認 |
|
||||
| 通常初期予算→実供給→食堂売上→配送途中保存 | 初日の35項目 PASS、1440×810の3タブを目視確認 |
|
||||
| 通常3営業日の締め・再仕入れ・最終保存 | 最終受入を実行中 |
|
||||
|
||||
既存回帰は構成ターゲットを分割して実行した。`test-s0/s1/s2/s3/s6/mvp` の38本・3,389項目が成功終了し、`check`・`test-s4`・`test-s5`（旧保存fixture補正後のDefense再確認を含む）・`test-acceptance`・`test-ui`・`test-perf` も完了した。性能のsmokeは部品を直接合成する検証で、通常シーン全体の描画性能を示さない。
|
||||
|
||||
## 残る課題
|
||||
|
||||
- 正本の料理ポイント・食器・施設解禁との統一、仕入れ設定の継続自動発注、価格・サービス会計の調整は残る。
|
||||
- 建設済みの倉庫へ仕入れ品を直接受け取る方式で、外部業者の車両・納期はまだ扱わない。
|
||||
- 職員ドアを使う実物流は接続したが、一般職員の出勤・職場到着後稼働、昇降機の実乗降はP2の別項目である。
|
||||
- この検証だけで初見30分の遊びやすさ、経済バランス、Windows実機性能、P1全体の完成を判定しない。
|
||||
Reference in New Issue
Block a user