Files

T

snark13 a3aaa30e53 SprPoP: тесты смерти от меча (базовое поведение до правок 12/13)

КОД ИГРЫ НЕ МЕНЯЛСЯ.  Новый набор 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

2026-08-31 20:23:35 +03:00

7.5 KiB

Raw Blame History

Два поведения: 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;
и наоборот: отдельные исправления (например, падение сквозь стену) вполне могут быть сделаны прямо в нынешнем «ванильном» билде, если сочтём, что играбельность важнее буквальности.

Что предстоит решить

Что считать ванилью на практике. Составить список уже сделанных отступлений от оригинала и распределить их между режимами.
Цена рантайм-проверки. Условия попадают в физику и play_seq, то есть в горячий путь. Если переключать в рантайме, проверка должна быть дешевле самого фикса: флаг в резиденте, а не вызов через банк.
Что считать умолчанием. Оригинальное поведение честнее для порта, но часть фиксов SDLPoP включает по умолчанию.
Как тестировать оба режима. Host-тесты гоняются одним прогоном; для двух режимов нужен либо параметр сборки тестов, либо ожидания, зависящие от флага.

Список кандидатов на BUGFIXED

Пополняется по мере аудита. Пока:

три опциональных фикса SDLPoP выше;
находка 24 (перезагрузка кадра в in_wall);
находка 21 из аудита — общая рамка «мы намеренно повторяем ваниль».

Не относятся сюда находки, где мы расходимся с оригиналом НЕ в его пользу (ранги А и Б аудита): их надо чинить в обоих режимах, потому что это не баги оригинала, а наши.

7.5 KiB Raw Blame History