From 70b42f6da13164382ea3bfadcbeed906fdb7e09c Mon Sep 17 00:00:00 2001 From: Jurjen Ladenius Date: Mon, 27 Jul 2026 22:21:01 +0200 Subject: [PATCH] Plan: add M10 save slots (multi-file), renumber polish to M11 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit tool/disk_save already indexes every call by entry, so multiple save files cost almost nothing on the storage side — KISSAT00.SAV, KISSAT01.SAV, and DiskSave_Check/Delete/GetFreeEntries already exist per entry. The work is the boot-time slot screen, which is why it sits late: it is easier to design once there is real save content to display. Co-Authored-By: Claude Opus 5 --- projects/kissaten_yugure/docs/DESIGN.md | 2 +- projects/kissaten_yugure/docs/PLAN.md | 51 ++++++++++++++++++++++--- 2 files changed, 46 insertions(+), 7 deletions(-) diff --git a/projects/kissaten_yugure/docs/DESIGN.md b/projects/kissaten_yugure/docs/DESIGN.md index 1bbb91c..a36717f 100644 --- a/projects/kissaten_yugure/docs/DESIGN.md +++ b/projects/kissaten_yugure/docs/DESIGN.md @@ -20,7 +20,7 @@ Platform: MSX2 · Library: MSXgl (C) · ROM: ASCII16 MegaROM > brewed, so her visits skip it — `SCRIPT.md` §8. > > Build order and per-stage requirements live in `PLAN.md`, which supersedes -> the scope ladder in §8 below with a finer ten-milestone breakdown. +> the scope ladder in §8 below with a finer eleven-milestone breakdown. ## 1. Concept diff --git a/projects/kissaten_yugure/docs/PLAN.md b/projects/kissaten_yugure/docs/PLAN.md index de3b178..151001c 100644 --- a/projects/kissaten_yugure/docs/PLAN.md +++ b/projects/kissaten_yugure/docs/PLAN.md @@ -81,10 +81,11 @@ and disk persistence all working. Verified by playing a day, cold-booting, and resuming at day 2 with the served count intact. **Pacing dial, revisited at the end.** `CUSTOMERS_PER_DAY` in `kissaten.c` is -the only number that sets day length. Worth reconsidering at M10 as a -player-facing choice — offered once at first boot ("how long should a day -be?"), or as a shelf option alongside the records. A game with no fail states -can afford to let the player set its own tempo, and it costs one saved byte. +the only number that sets day length. Worth reconsidering at **M10** as a +player-facing choice — the slot screen is already a boot-time front-end, so +"how long should a day be?" has a natural home there, asked once when a new +shop is started. A game with no fail states can afford to let the player set +its own tempo, and it costs one saved byte. Not worth building before the content exists: the right default only becomes obvious once days have stories in them. @@ -267,7 +268,44 @@ every generated track. Money finally gates something. **Exit:** Music changes with time-of-day and weather; the player can choose a record. -### M10 — Ending, polish, hardware +### M10 — Save slots (multi-file) + +Several shops on one disk. `tool/disk_save` is already built for this: every +call takes an `entry` index, so slots become `KISSAT00.SAV`, `KISSAT01.SAV` +and so on with no change to the save format. `DiskSave_Check(entry)` reports +each slot's state, `DiskSave_GetFreeEntries()` counts the free ones, and +`DiskSave_Delete(entry)` removes one. **The storage side is nearly free.** + +The actual work is front-end: a slot screen at boot showing what's in each +one, and a confirm step before overwriting or deleting. That is also why this +milestone sits late — it touches the boot flow, and it is much easier to +design once there is real save content to display. + +Worth framing in-fiction rather than as a file manager. A slot is not "Save +1", it is a shop with days behind it — *"Day 34 · 210 cups"* tells the player +which one is theirs better than a filename does. + +**Requires — from you:** +- **How many slots.** Three is conventional and the disk has room for far + more; the constraint is screen space, not storage. +- **Whether slots are named.** A proprietor's name per shop is charming, but + it means building text entry on a machine with no line editor. My + recommendation: skip it, and let day count plus cups served identify a slot. +- **What the deletion guard is.** No fail states applies to the save screen + too — an accidental delete is the one genuinely unrecoverable action in a + game that otherwise has none. I would make it a two-step confirm. + +**Requires — in place:** M2's save layer (done). Nothing else technically — +this could be built any time, and is late only because the design benefits +from real content. + +**Produces:** slot selection screen, per-slot summary, delete with confirm, +`SAVE_ENTRY` becoming a runtime value rather than the `#define` it is now. + +**Exit:** Three shops can be run in parallel from one disk, each resuming to +its own day and cast state, and no single keypress can destroy one. + +### M11 — Ending, polish, hardware One quiet ending (see §6). Real-hardware verification, 50/60Hz check, timing pass on the brew minigame. @@ -496,7 +534,8 @@ milestone that consumes them. | 13 | M7 | Number of palette sets | Fewer, art-directed well | | 14 | M8 | How overt Nakajima's reveal gets | Never stated by anyone but her | | 15 | M9 | Sound chip: PSG / FM / retarget | PSG-only via your existing lVGM pipeline | -| 16 | M10 | Hardware access + 50/60Hz target | — | +| 16 | M10 | Number of save slots, and whether they're named | 3 slots, unnamed — day count and cups served identify them without needing text entry | +| 17 | M11 | Hardware access + 50/60Hz target | — | Items 1–3 are small and I can proceed on my recommendations if you'd rather not think about them. Items 4 and 8 are the two that genuinely shape the