snark13
a3aaa30e53
КОД ИГРЫ НЕ МЕНЯЛСЯ. Новый набор t_death — 9 проверок, всего наборов 16. Заведён ПЕРЕД правкой находок 12/13, чтобы поймать деградацию: правка 13 в изоляции уже ломала смерть (мёртвый оставался с ненулевой скоростью падения, проваливался за нижнюю границу, игра уходила на рестарт, не показав тела). Поэтому проверяется ровно то, на что эти правки влияют: * удар не в боевой стойке смертелен независимо от запаса HP; * удар с мечом снимает одно HP, на последнем — убивает; * ПЕРЕЖИВШИЙ удар ставится на пол своего ряда с нулевой скоростью падения (в оригинале это единственная ветка, где координата трогается); * тело после смерти остаётся в своём ряду — и на ровном полу, и у самого обрыва (целевая сцена находки 12; после правки ожидание изменится осознанно). По дороге тест дважды показал не баг движка, а мои ошибки в самой сцене: обвязка выставляет признак «жив» только стражу, а урон применяется не сразу — удар выставляет дельту, и HP меняет отдельный шаг кадра, как в оригинале. Оба раза чинился тест. VANILLA/BUGFIXED: записано, что переключатель уже существует в настройках и зафиксирован в положении VANILLA, второй заводить не нужно. Отмечено главное следствие — наш «ванильный» билд УЖЕ не чистая ваниль (часть ванильных багов пофикшена), поэтому при разделении режимов придётся пройтись по сделанным отступлениям и распределить их; отдельные фиксы (падение сквозь стену) могут быть сделаны и в нынешнем билде. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011MsUsEFAQfsjjQpJ7RtKVY
112 lines
7.5 KiB
Markdown
112 lines
7.5 KiB
Markdown
# Два поведения: VANILLA и BUGFIXED
|
|
|
|
> Заведено 2026-08-31. Задача поставлена, работа НЕ начата.
|
|
|
|
## Зачем
|
|
|
|
У оригинального PoP есть баги, которые игроки знают наизусть и на
|
|
которых построены известные трюки. SDLPoP чинит их не молча, а
|
|
ОПЦИОНАЛЬНО: каждое исправление отдельным переключателем, по умолчанию
|
|
часть включена, часть нет. Мы до сих пор повторяли ваниль — сознательно,
|
|
чтобы порт вёл себя как оригинал.
|
|
|
|
Задача: дать ДВА поведения на выбор, не размазывая условия по всему коду:
|
|
|
|
* **VANILLA** — как в оригинале 1989 года, со всеми его багами;
|
|
* **BUGFIXED** — с портированными исправлениями SDLPoP.
|
|
|
|
## Что уже известно (из аудита)
|
|
|
|
Разбор расхождений — `docs/sdlpop_audit.md`. Оттуда прямо в эту задачу
|
|
переезжает следующее.
|
|
|
|
### Опциональные фиксы SDLPoP, которых у нас НЕТ
|
|
|
|
Все три относятся к прохождению сквозь препятствия и живут в `do_fall`
|
|
(seg005) и рядом:
|
|
|
|
| фикс SDLPoP | что чинит |
|
|
|---|---|
|
|
| «скольжение сквозь стену» | Кид падает сквозь стены после разворота в беге, особенно под зельем медленного падения |
|
|
| «прыжок сквозь стену над воротами» | пролёт в тайл над воротами |
|
|
| «проваливание сквозь гобелен» | падение сквозь тайл гобелена |
|
|
|
|
Ни один не портирован — это и есть наше нынешнее VANILLA.
|
|
|
|
### Находка 24 — отложена сюда
|
|
|
|
`in_wall` у нас пересчитывает только колонку, а оригинал перезагружает
|
|
ещё и данные кадра (`load_fram_det_col`, seg006). Правка сделана и
|
|
ОТКАЧЕНА 2026-08-31 по такой причине:
|
|
|
|
* по букве оригинала находка верна;
|
|
* но практического эффекта показать НЕ УДАЛОСЬ — все 15 наборов
|
|
host-тестов дают одинаковый результат до и после, включая специально
|
|
написанный тест на заход в кладку;
|
|
* при этом правка не бесплатна: добавляет маппинг окна и перезагрузку
|
|
кадра на каждое выталкивание из стены.
|
|
|
|
Платить за недоказанное не стали. Вернуться к ней имеет смысл именно
|
|
здесь: при работе над BUGFIXED появится сценарий, где кадр меняется перед
|
|
выталкиванием, и тогда эффект станет наблюдаемым.
|
|
|
|
### Готовый детектор поведения
|
|
|
|
`tests/host/t_wall.c` расширен с одной проверки до трёх. Ключевая —
|
|
`wall_stops_jump_from_left_side`: она НЕ требует нуля заходов в кладку, а
|
|
сторожит их ЧИСЛО (сейчас ровно два случая из четырнадцати стартовых
|
|
позиций).
|
|
|
|
Это и есть переключатель ожиданий между режимами:
|
|
|
|
* больше двух — правка сделала нас хуже ванили, регресс;
|
|
* ровно два — ведём себя как оригинал (режим VANILLA);
|
|
* меньше двух — кто-то портировал фикс; в режиме BUGFIXED тест должен
|
|
ждать нуля.
|
|
|
|
То есть когда появится BUGFIXED, этому тесту понадобится ожидание,
|
|
зависящее от режима, — и он готов стать первым таким.
|
|
|
|
## Переключатель уже есть — второго не нужно
|
|
|
|
Уточнено 2026-08-31: в настройках игры ПЕРЕКЛЮЧАТЕЛЬ VANILLA/ENHANCED
|
|
СУЩЕСТВУЕТ (`docs/menu_settings_plan.md`), просто сейчас он жёстко
|
|
зафиксирован в положении VANILLA. Отдельную сущность заводить не надо —
|
|
эта задача про то, чтобы наполнить смыслом уже имеющееся положение
|
|
ENHANCED.
|
|
|
|
**Наш «ванильный» билд уже не чистая ваниль.** Часть ванильных багов у
|
|
нас пофикшена по ходу портирования. Значит:
|
|
|
|
* нельзя считать текущее поведение эталоном ванили — оно смешанное;
|
|
* при разделении режимов придётся пройтись по уже сделанным фиксам и
|
|
решить по каждому, остаётся он в VANILLA или уезжает в ENHANCED;
|
|
* и наоборот: отдельные исправления (например, падение сквозь стену)
|
|
вполне могут быть сделаны прямо в нынешнем «ванильном» билде, если
|
|
сочтём, что играбельность важнее буквальности.
|
|
|
|
## Что предстоит решить
|
|
|
|
1. **Что считать ванилью на практике.** Составить список уже сделанных
|
|
отступлений от оригинала и распределить их между режимами.
|
|
2. **Цена рантайм-проверки.** Условия попадают в физику и `play_seq`, то
|
|
есть в горячий путь. Если переключать в рантайме, проверка должна
|
|
быть дешевле самого фикса: флаг в резиденте, а не вызов через банк.
|
|
3. **Что считать умолчанием.** Оригинальное поведение честнее для порта,
|
|
но часть фиксов SDLPoP включает по умолчанию.
|
|
4. **Как тестировать оба режима.** Host-тесты гоняются одним прогоном;
|
|
для двух режимов нужен либо параметр сборки тестов, либо ожидания,
|
|
зависящие от флага.
|
|
|
|
## Список кандидатов на BUGFIXED
|
|
|
|
Пополняется по мере аудита. Пока:
|
|
|
|
* три опциональных фикса SDLPoP выше;
|
|
* находка 24 (перезагрузка кадра в `in_wall`);
|
|
* находка 21 из аудита — общая рамка «мы намеренно повторяем ваниль».
|
|
|
|
Не относятся сюда находки, где мы расходимся с оригиналом НЕ в его
|
|
пользу (ранги А и Б аудита): их надо чинить в обоих режимах, потому что
|
|
это не баги оригинала, а наши.
|