aary

KeyCloak

aary — Sun, 4 Oct 2026 18:27:51 +0000

Установил KeyCloak. Говорят, что к нему можно подключить Gitlab. Надо подумать, что ещё можно подключить.

Баба Валя упороласть...

aary — Sun, 27 Sep 2026 18:08:25 +0000

Сценарии, планы и их реализации

Приложение 1. Термины действительности (игры)
Приложение 2. Термины программы моделирования/симуляции
Приложение 3. Сравнение и финалы
Приложение 4. Как человек организует выбор варианта стратегии
Приложение 5. Работа АВТ
Приложение 6. Формализация АВТ в псевдокоде
Приложение 7. Состояние модели

Введение

Задача — выработать истину: набор правильных гипотез и соответствующих истине стратегии и тактики. Стратегия одна. Человек прорабатывает варианты стратегии заранее и записывает в виде сценариев. Человек создаёт несколько сценариев, потому что человек хочет сравнить разные гипотетические варианты стратегии между собой.

Исходное описание действительности заранее прописывается человеком как состояние модели.

Два уровня выработки истины

Существуют два уровня выработки истины: стратегический и тактический.

Стратегический уровень — уровень разума человека и помогающего человеку вырабатывать стратегию алгоритма.

РЧ вырабатывает стратегию, для чего РЧ формирует стратегические гипотезы и создаёт сценарии для проверки стратегических гипотез. Стратегическая гипотеза, которая ведёт к выигрышной стратегии — правильная. Стратегическая гипотеза, которая ведёт к проигрышной стратегии — неправильная. Сценарий — продукт РЧ. Сценарий состоит из этапов.

ПЧВСА помогает человеку обрабатывать сценарии, для чего ПЧВСА создаёт результаты этапов. ПЧВСА обрабатывает сценарии по этапам. ПЧВСА заказывает план у АВТ. ПЧВСА инициирует работу АВТ.

Тактический уровень — уровень алгоритма выработки тактики для реализации этапа стратегии.

АВТ создаёт планы — важно, как именно (это надо запрограммировать), потому что АВТ нужно сравнить планы между собой и выбрать лучший. План — последовательность моделируемых действий. АВТ вырабатывает тактику для этапа (ПЧВСА решает, для какого — для любого, для каждого, для указанного). АВТ создаёт всё: миры, граф, планы.

Человек проверяет стратегические гипотезы. АВТ проверяет тактические гипотезы.

Сценарий — это не стратегия. План — это не тактика.

Гипотезы и сценарии

Пример стратегических гипотез.

Стратегическая гипотеза 0: квест лучше выполнять, чем не выполнять.
Антигипотеза 0: квест лучше не выполнять.

Стратегическая гипотеза 1: выполнять квест раньше — выгоднее, чем позже.
Антигипотеза 1: выполнять квест позже — выгоднее, чем раньше.

Стратегическая гипотеза 2: два завода.
Антигипотеза 2: один завод.

Стратегическая гипотеза 1 связана с гипотезой о минимизации момента получения бонуса. Стратегическая гипотеза 2 тоже связана с гипотезой о минимизации момента получения бонуса. Обе гипотезы связаны с гипотезой получения бонуса. Два завода быстрее вырабатывают топливо и уменьшают время до получения бонуса. Один завод медленнее вырабатывает топливо и увеличивает время до получения бонуса.

Сценарии образуются из гипотез так: по каждой гипотезе берётся либо гипотеза, либо антигипотеза. Не все комбинации дают разные сценарии. Комбинации, которые дают одинаковые сценарии, сворачиваются в один. Например, если квест не выполняется, то не важно, один или два завода, и не важно, раньше или позже. Все такие комбинации дают один сценарий.

Антигипотеза 0 сворачивает и отсекает три сценария как невозможные. Если квест не выполняем, не важно — один или два завода, и не важно — раньше или позже. Поэтому всего сценариев пять, а не восемь:

Квест не выполняем.
- Этап 1: домики.
Два завода, потом домики.
- Этап 1: первый завод, второй завод, домики.
- Этап 2: второй завод, домики.
- Этап 3: домики.
Один завод, потом домики.
- Этап 1: один завод, домики.
- Этап 2: домики.
Домики, потом два завода.
- Этап 1: домики, первый завод, второй завод.
- Этап 2: первый завод, второй завод, домики.
- Этап 3: второй завод, домики.
Домики, потом один завод.
- Этап 1: домики, один завод.
- Этап 2: один завод, домики.

Промежуточные варианты (не раньше и не позже) не рассматриваются — это упрощение.

Два завода сразу не построить — не хватит ресурсов. Заводы строятся поштучно. Между первым и вторым заводом проходит время. В это время можно строить домики. Возникает вариант: первый завод, домики, второй завод. Этот вариант не рассматривается, потому что он не оптимален ни по одному критерию: он хуже, чем «два завода, потом домики» (бонус позже), и хуже, чем «домики, потом два завода» (домики позже).

Этап

Этап — это цели и приоритеты. Этап может иметь несколько целей. Цели приоритезированы: первая цель более важная, затем следующая цель и так далее. Только первую цель этапа обязательно нужно достичь — это условие завершения этапа.

Пример этапа: «строительство завода» — построить завод, строить домики. Строительство завода и накопление ресурсов для строительства завода — приоритетнее, потому что строительство завода и накопление ресурсов указаны первой целью.

Человек не пишет в сценарии мелкие моделируемые действия вроде «подождать». Это уровень АВТ.

Действия

Моделируемые действия мгновенные: они не занимают игрового времени и не продвигают его. Мгновение не путать с тактом, имеющим переменную длительность. Исключение — моделируемое действие «подождать»: оно не мгновенное, а продвигает игровое время на К тактов. «Подождать» входит в число моделируемых действий.

Моделируемое действие — элементарная операция плана: обменять труд на сталь, построить домик, забрать бонус, подождать.

Как это связано

РЧ создаёт сценарии. ПЧВСА по сценарию порождает результаты этапов. Реализация сценария — совокупность результатов этапов. Один сценарий — одна реализация сценария.

АВТ вырабатывает тактику для этапа. АВТ создаёт план для этапа. АВТ создаёт миры, граф и планы. План — путь в графе миров. Миры входят в планы.

ПЧВСА создаёт результаты этапов. Реализация сценария хранит результаты этапов. Результаты этапов знают тактики своего этапа.

Реализация сценария → результаты этапов → моделируемые действия (граф) + миры.

Реализация сценария знает результат последнего этапа, для знания имеет указатель (кеш).

Результат этапа знает наилучший план, для знания имеет указатель (кеш). План — маршрут в направленном ациклическом графе (НАГ).

Параллельные действия

Моделируемые действия могут выполняться параллельно. Например, во время выполнения квеста можно строить домики. Это возможно, если позволяют ресурсы и труд. Если труд уходит на энергию и топливо, домики не строятся. Если труда много — часть труда идёт на квест, часть труда на домики, — если так написано в сценарии. Может быть написано, что лишний труд надо тратить на науку или на добычу стали.

Если параллельно делать нельзя, делаем то, что ведёт к достижению цели, потому что в случае невозможности параллельности приоритеты не нужны.

Зачем это нужно

Разделение на уровни позволяет отделить то, что задаёт человек, от того, что вычисляют алгоритмы. РЧ задаёт сценарий. АВТ ищет лучший план. ПЧВСА помогает человеку обрабатывать сценарии.

Разделение на реализации сценариев и миры позволяет организовать сравнение. ПЧВСА сравнивает миры внутри реализации сценария, чтобы найти лучший мир. ПЧВСА принимает уже готовый лучший мир от каждой реализации сценария и сравнивает их между собой. ПЧВСА принимает состояние модели из лучшего мира.

Приложение 1. Термины действительности (игры)

Термины упорядочены так, чтобы каждый термин ссылался только на определённые ранее.

Действительность

Действительность — исходное описание. Действительность отражена в программе (человеком) в виде исходного состояния модели. Исходное состояние модели — одно, глобальное, неизменяемое.

Состояние действительности

Состояние действительности — набор строений, накопления на складе, запасы в строениях. Всё целые числа.

РЧ

РЧ — разум человека.

Игровой период

Игровой период — 6 часов игрового времени. Далее используется формулировка «игровой период (6 часов)». Игровой период — фиксированная величина. Игровой период не зависит от населения. Игровое время считается в игровых периодах, не в тактах. За 1 игровой период всё население даёт весь труд этого периода. 1 такт = 1 игровой период / (население / 1 млн). Население — целое число (млн жителей). Длительность такта — вещественная. Округлять её не нужно. Такт пересчитывается при изменении населения. В действительности население меняется при постройке домика и при бомбардировке. В модели население меняется только при постройке домика. Это происходит в момент моделируемого действия, не во время «подождать». Значит, на протяжении одного «подождать» длительность такта постоянна. После постройки домика длительность такта уменьшается, потому что население выросло. За 1 такт труд прирастает на 1. Неизвестно, какой именно миллион жителей даёт этот 1 труд — это условность. «Подождать» продвигает время на К тактов.

Реальное действие

Реальное действие — действие, совершаемое в действительности. Занимает реальное время. Гипотетически есть, но мы о них не говорим. Термин нужен для понимания человеком. См. раздел «О терминах, абстрагирующих другие термины».

Бомбардировка

Бомбардировка — событие в действительности. Бомбардировка разрушает строения: домики, заводы, электростанции, шахты, заводы ракетного топлива. Бомбардировка уменьшает население. В текущей модели не учитывается.

Приложение 2. Термины программы моделирования/симуляции

Термины упорядочены так, чтобы каждый термин ссылался только на определённые ранее.

О терминах, абстрагирующих другие термины

В этом приложении есть три термина, которые не описывают отдельные сущности, а абстрагируют по два других термина. Это «Действие», «Финал» и «Гипотеза».

Моделирующая система сложна: она описывает и действительность, и модель, и разные уровни планирования. Одни и те же понятия на разных уровнях имеют разный смысл. Например, действие в действительности и действие в модели — не одно и то же. Финал сценария и финал плана — не одно и то же. Гипотеза о стратегии и гипотеза о тактике — не одно и то же.

Чтобы не смешивать эти разные смыслы, вводятся абстрагирующие термины. Они нужны для понимания человеком. Если удалить абстрагирующий термин, возникнет вопрос, почему конкретный термин называется именно так, а не иначе, и чем он отличается от другого конкретного термина.

Абстрагирующие термины не заменяются конкретными в тексте определений. Если заменить абстрактный термин на конкретный там, где он абстрагирует два других, получится либо круг, либо бессмыслица. Например: «Моделируемое действие — конкретизация абстракции „Моделируемое действие“» — бессмыслица. «Стратегический финал — термин, абстрагирующий два других: стратегический финал и тактический финал» — круг.

Поэтому абстрагирующие термины остаются в тексте и используются там, где нужно говорить о двух конкретных терминах вместе или где нужно показать их общую природу.

Если абстрагирующий термин сейчас нигде не используется, его всё равно нужно оставить на будущее. Возможность его использования есть. В любой момент может появиться место, где потребуется сказать о двух конкретных терминах вместе. Без абстрагирующего термина придётся либо вводить его заново, либо переписывать определения. И то, и другое хуже, чем оставить термин в тексте заранее.

Состояние модели

Состояние модели — представление состояния действительности в программе. Набор строений, накопления на складе, запасы в строениях. Всё целые числа. К запасам в строениях прилагается буфер дробной части: он хранит дробную часть прироста, которая ещё не стала целой единицей. Буфер вещественный. Если такое состояние модели уже существует — АВТ не создаёт его, а переиспользует. Флагов в состоянии модели нет: флаги — артефакты алгоритма, они хранятся в мире.

Гипотеза

Гипотеза — термин, абстрагирующий два других: стратегическую гипотезу и тактическую гипотезу.

Термин нужен для понимания человеком. См. раздел «О терминах, абстрагирующих другие термины».

Сам термин «гипотеза» используется в двух местах:

В термине «Истина»: истина — набор правильных гипотез, стратегии и тактики. Здесь имеются в виду и стратегические, и тактические гипотезы вместе.
В термине «Кеширование гипотез»: механизм общий для человека и АВТ. Кешируются и стратегические, и тактические гипотезы. Абстрактный термин позволяет говорить о них вместе.

Стратегическая гипотеза

Стратегическая гипотеза — утверждение о выгодности варианта стратегии. Антигипотеза — противоположное утверждение. Стратегическая гипотеза формулируется РЧ. Стратегическая гипотеза, которая ведёт к выигрышной стратегии — правильная. Стратегическая гипотеза, которая ведёт к проигрышной стратегии — неправильная.

Тактическая гипотеза

Тактическая гипотеза — утверждение о выгодности варианта способа превращения цели в моделируемые действия. Антигипотеза — противоположное утверждение. Тактическая гипотеза формулируется АВТ. Тактическая гипотеза, которая ведёт к выигрышной тактике — правильная. Тактическая гипотеза, которая ведёт к проигрышной тактике — неправильная.

Истина

Истина — набор правильных гипотез, стратегии и тактики. Правильная гипотеза — та, которая ведёт к лучшему результату по критерию сравнения. Стратегия — победитель сравнения сценариев. Тактика — победитель сравнения планов.

Стратегия

Стратегия — вариант действий, который ведёт к лучшему результату по критерию сравнения. Стратегия одна для действительности.

Тактика

Тактика — лучший вариант реализации этапа стратегии. Из планов выбираем лучший по результатам сравнения. Тактика одна для этапа.

Цель

Цель — то, что должно быть достигнуто на этапе. Цель формулируется человеком в сценарии.

Приоритет

Приоритет — указание, какая цель важнее, если целей несколько. Приоритет формулируется человеком в сценарии.

Этап

Этап — цели и приоритеты. Этап может иметь несколько целей. Цели приоритезированы. Только первая цель этапа обязательно должна быть достигнута — это условие завершения этапа. Этап состоит из целей и приоритетов и владеет ими.

Исключение — последний этап. У последнего этапа есть цель (строить домики), но условие завершения этапа внешнее: не «построить определённое число домиков», а условие остановки симуляции. Последний этап завершается, когда все миры достигли стратегического финала. АВТ планирует для последнего этапа так же, как для остальных: строит планы, сравнивает, выбирает лучший. Разница только в том, что тактический финал последнего этапа совпадает со стратегическим финалом — то есть с условием остановки симуляции.

Последняя цель — та, что в списке целей этапа идёт последней (не пустая). Приоритет определяет порядок достижения. После достижения последней цели этапа сценарий продолжает выполнять последнюю цель до конца симуляции. Если последняя цель — «построить завод», а завод уже построен, сценарий строит домики, если есть ресурсы; иначе ждёт.

Сценарий

Сценарий — продукт РЧ. Сценарий — цепочка этапов. Человек создаёт сценарий, потому что человек хочет сравнить разные гипотетические варианты стратегии между собой. Стратегия одна, и человек прорабатывает стратегию заранее. Сценарий состоит из этапов и владеет ими.

Сценарий недействителен, если не может достичь стратегического финала. Недействительный сценарий не участвует в сравнении. Если все сценарии недействительны, человек должен пересмотреть сценарии или гипотезы.

Финал

Финал — термин, абстрагирующий два других: стратегический финал и тактический финал.

Термин нужен для понимания человеком. См. раздел «О терминах, абстрагирующих другие термины».

Стратегический финал

Стратегический финал — условие завершения сценария. Стратегический финал — два условия одновременно: флаг из_руды, домик построен. Домик построен — на последнем этапе построен хотя бы один домик. Снос домиков в модели не рассматривается. Поэтому условие равносильно: счётчик домиков, построенных на текущем этапе, больше нуля. Последний этап определяется проверкой: текущий этап == Последний_этап(Сценарий). Отдельный флаг последний_шаг не нужен. Флаг из_руды и текущий этап — артефакты алгоритма, хранятся в мире, не в состоянии модели.

Флаг из_руды — признак того, что склад опустел по стали, товарам, энергии и труду. Топливо, КР и наука не входят в проверку: топливо — цель квеста, не тратится на домики; КР и наука в текущей модели не используются для покупки ресурсов и исследований. Эти ресурсы не влияют на строительство домиков.

Склад может опустеть по труду: труд тратится на обмены, и после действия труд может быть равен нулю. Отдельного «строительства из руды» нет: строительство всегда идёт со склада, ресурсы сначала попадают на склад, потом тратятся. Флаг из_руды отмечает момент, когда запасы стали, товаров, энергии и труда на складе исчерпались на последнем этапе сценария. Флаг сбрасывается при получении бонуса: бонус пополняет склад, и запасы снова становятся непустыми. Флаг устанавливается снова, когда склад опять опустеет. К моменту финала флаг установлен — значит, склад опустел и больше не пополняется бонусом.

Как условие стратегического финала флаг из_руды означает: к моменту финала сценарий исчерпал запасы стали, товаров, энергии и труда, накопленные изначально или полученные бонусом. После этого момента дальнейшее продолжение не добавляет различий между сценариями: поведение одинаково. Сравниваются различия в населении и количестве моделируемых действий, накопленные к этому моменту. Именно поэтому флаг из_руды — условие финала: он отмечает точку, после которой сценарии перестают различаться дальнейшим поведением, и сравнение возможно только по накопленному.

Тактический финал

Тактический финал — условие завершения плана. Тактический финал — цель этапа достигнута. План считается завершённым, когда цель этапа достигнута. Для последнего этапа тактический финал совпадает со стратегическим финалом.

Действие

Действие — абстракция. То, что изменяет состояние или продвигает время. Большинство моделируемых действий мгновенные: изменяют состояние, но не продвигают время. «Подождать» — не мгновенное: продвигает время. Только Приложение 2.

Термин нужен для понимания человеком. См. раздел «О терминах, абстрагирующих другие термины».

Моделируемое действие

Моделируемое действие — конкретизация абстракции «Действие». Создаётся программой. Моделируемые действия делятся на два вида:

Мгновенные. Большинство действий. Не продвигают время и не занимают такты.
«Подождать». Не мгновенное. Продвигает время на К тактов, где К — параметр моделируемого действия.

Параметр «подождать» задаётся в тактах, потому что труд дискретизирован в тактах: за 1 такт начисляется 1 труд. Запасы в строениях при этом накапливаются за игровые периоды: K тактов = K × длительность_такта игровых периодов. Моделируемым действием при сравнении считается только то, что изменило состояние. Если ресурсы закончились — ждать. Если ресурсы не могут появиться — сценарий недействителен. Ресурсы не могут появиться, если население равно нулю: тогда труд не производится, обмены невозможны, ресурсы не восстанавливаются. В текущей модели население не умирает, поэтому эта проверка не срабатывает.

Такт

Такт — часть игрового периода, зависящая от населения. 1 такт = 1 игровой период / (население / 1 млн).

Население — целое число (млн жителей). Население_млн — целое (550, 551 и так далее). Длительность такта — вещественная (1/550, 1/551 и так далее). Округлять длительность такта не нужно: она используется только для перевода тактов в игровое время при обновлении запасов.

Такт нужен только для дискретизации труда: за 1 такт прибавляется 1 труд целым числом. За К тактов прибавляется К труда. Всё остальное (запасы в строениях, игровое время, длительность этапа) считается в игровых периодах, не в тактах. Непрерывное начисление труда привело бы к дробным значениям, что усложнило бы учёт и округление.

Такт пересчитывается при изменении населения. В модели население меняется только при постройке домика. Это происходит в момент моделируемого действия, не во время «подождать». Значит, на протяжении одного «подождать» длительность такта постоянна. После постройки домика длительность такта уменьшается, потому что население выросло. За 1 такт труд прирастает на 1. «Подождать» продвигает время на К тактов. Население разное в разных мирах. Как следствие — длительность такта разная в разных реализациях сценария (в реализации сценария есть оптимальный мир).

Мир

Мир — отличается от другого мира одним моделируемым действием, и этим же действием миры присоединяются к графу. Начальному состоянию модели соответствует нулевой мир. В нулевом мире задаётся начальное реальное время. Мир отличается от нулевого мира планом (путём из моделируемых действий). Мир ссылается на состояние модели.

Мир всегда новый. Состояние модели может переиспользоваться.

В мире хранятся артефакты алгоритма: флаг из_руды, количество домиков, построенных на текущем этапе, текущий этап, длительность такта. Флаги — артефакты алгоритма, они не входят в состояние модели, потому что в действительности их нет.

План

План — последовательность моделируемых действий. План — маршрут в направленном ациклическом графе (НАГ). План — путь в графе миров. План содержит моделируемые действия и ссылается на миры. План соотносится со сценарием так же, как тактика со стратегией.

Реализация плана

Реализация плана — миры одного маршрута (одного плана) и моделируемые действия между ними. Реализация плана не хранится, а выводится, используя имеющуюся информацию, если это потребуется. Выводится она для любого плана, если возникнет потребность. Хранится только тактика — лучший план. Реализация лучшего плана выводится из графа и маршрута лучшего плана.

Граф моделируемых действий

Граф моделируемых действий — структура, связывающая моделируемые действия. Как следствие — связывающая миры. АВТ создаёт новые состояния модели и новые миры. Из одного состояния можно совершить разные моделируемые действия. Каждое моделируемое действие ведёт в новое состояние. Граф направленный ациклический (НАГ). Циклов нет: снос домика не возвращает ресурсы (ресурсы теряются), значит вернуться в прошлое состояние нельзя. Граф владеет моделируемыми действиями (рёбрами), использует миры (узлы).

АВТ

АВТ — алгоритм выработки тактики для реализации этапа стратегии. АВТ создаёт всё: миры, граф, планы, состояния модели. Если такое состояние модели уже существует — АВТ не создаёт его, а переиспользует. АВТ создаёт планы — важно, как именно (это надо запрограммировать), потому что АВТ нужно сравнить планы между собой и выбрать лучший. АВТ вырабатывает тактику для этапа (ПЧВСА решает, для какого — для любого, для каждого, для указанного).

АВТ порождает все перестановки моделируемых действий внутри цели. АВТ отсекает ветки, которые не ведут к цели. Эвристики для отсечения: эвристика 1 (независимые моделируемые действия) и эвристика 3 (блокирующее раньше).

ПЧВСА

ПЧВСА — помогающий человеку вырабатывать стратегию алгоритм. ПЧВСА помогает человеку обрабатывать сценарии, для чего ПЧВСА создаёт результаты этапов. Результат этапа — следствие обработки сценария при помощи ПЧВСА и часть реализации сценария. ПЧВСА обрабатывает сценарии по этапам. Чтобы подобрать тактику на сценарии, ПЧВСА должен подобрать тактики на каждом этапе. ПЧВСА заказывает план у АВТ. ПЧВСА инициирует работу АВТ.

Результат этапа

Результат этапа знает тактику своего этапа (как кеш). Тактика — лучший план для этого этапа. Результат этапа знает результаты применения тактики (тоже как кеш). Результат этапа — на момент окончания этапа. Результат этапа владеет графом моделируемых действий и мирами. План — маршрут в направленном ациклическом графе (НАГ). Реализация плана для лучшего плана выводится из графа и маршрута лучшего плана по запросу.

Реализация сценария

Реализация сценария — совокупность результатов этапов. Реализация сценария содержит результаты всех этапов сценария, не только последнего. Реализация сценария указывает на сценарий — исходный сценарий, из которого построена эта реализация. Реализация сценария знает результат последнего этапа, для знания имеет указатель (кеш).

Реализацию сценария можно построить по сценарию. Реализацию сценария строит ПЧВСА.

Сравнение

Сравнение — сопоставление миров или реализаций сценариев по критериям.

АВТ сравнивает миры внутри одного этапа одного сценария. ПЧВСА сравнивает реализации сценариев между собой.

Сравнивать нужно в одном времени. Время равно, если время отличается меньше, чем на величину максимального такта среди сравниваемых миров.

Максимальный такт — максимальная длительность такта среди тех миров, которые сравниваются. Если АВТ сравнивает миры одного этапа одного сценария, максимальный такт берётся среди этих миров. Если ПЧВСА сравнивает реализации сценариев, максимальный такт берётся среди всех миров, которые входят в сравниваемые реализации.

Главный критерий — население. Население — главный критерий, потому что от него зависит скорость выработки труда. Чем больше население, тем быстрее копится труд, тем быстрее строятся домики. Второстепенный критерий — количество моделируемых действий. Количество действий важно только при равном населении. Меньше действий — лучше, потому что это эффективнее. Все сравниваемые величины — целые числа. Критерий лексикографический: сначала население, потом моделируемые действия.

Кеширование гипотез

Кеширование гипотез — механизм, общий для человека и АВТ. Гипотезу можно проверить один раз и затем пользоваться результатом проверки, если сохраняются условия, при которых гипотеза проверялась.

Условие — характеристика ситуации, при которой гипотеза проверялась. Условие — набор проверок над состоянием модели. Проверка — это логическое выражение, которое либо истинно, либо ложно.

Примеры проверок:

Качественная: «склад пуст», «склад не пуст», «достаточно стали на домик», «достаточно товаров на домик», «достаточно энергии на домик».
Числовая: «население > 550 млн», «сталь на складе > 100».

Условие считается совпадающим, если все проверки дают тот же результат, что и в сохранённом условии. Точные числа не сравниваются. Сравниваются результаты проверок.

Результат проверки гипотезы — вывод о том, какой вариант выгоднее при данных условиях.

Результат сохраняется в кеше вместе с набором проверок и их результатами.

Требование к именам

Все имена переменных, функций, типов и структур в псевдокоде и в коде — на русском языке и кириллицей. Латинские буквы в именах не используются. Единственное исключение — синтаксические ключевые слова языка программирования (например, fn, let, if, while), если язык их требует.

Приложение 3. Сравнение и финалы

Общий момент сравнения

Миры разной длины: один заканчивается раньше, другой позже. Мир не останавливается, когда достиг последней цели. Мир продолжает работать до общего момента сравнения.

Общий момент сравнения — когда последний мир достиг стратегического финала. На уровне АВТ — когда последний план достиг тактического финала. На уровне ПЧВСА — когда последняя реализация сценария достигла стратегического финала. Этот же момент — условие остановки симуляции. Симуляция останавливается, когда все миры достигли стратегического финала. Мир, который достиг стратегического финала раньше, продолжает строить домики до общего момента.

В этот момент у каждого мира своё население и своё количество моделируемых действий.

Проверка финала — это условие остановки, а не отсечение. Отсечение планов происходит по другим причинам: невозможность выполнить моделируемое действие, нарушение порядка блокировки, эквивалентность другому плану.

Связь финалов с целями этапов

Разные этапы могут иметь разные цели. Тактический финал зависит от цели этапа.

Для этапа с целью «построить завод» тактический финал — завод построен.
Для этапа с целью «строить домики» тактический финал совпадает со стратегическим финалом — условием остановки симуляции.
Для этапа с целью «копить топливо» тактический финал — накоплено 160 топлива.
Для этапа с целью «забрать бонус» тактический финал — бонус забран.

Приложение 4. Как человек организует выбор варианта стратегии

Постановка задачи

Человек хочет выработать стратегию. Стратегия одна. Человек прорабатывает варианты стратегии заранее и записывает в виде сценариев. Человек создаёт несколько сценариев, потому что хочет сравнить разные гипотетические варианты стратегии между собой.

Шаги

Шаг 1. Формулировка стратегических гипотез.

Человек формулирует стратегические гипотезы о выгодности вариантов стратегии.

Пример гипотез:

Стратегическая гипотеза 0: квест лучше выполнять, чем не выполнять.
Стратегическая гипотеза 1: выполнять квест раньше — выгоднее, чем позже.
Стратегическая гипотеза 2: два завода выгоднее одного.

Шаг 2. Создание сценариев.

Человек создаёт сценарии для проверки стратегических гипотез.

Сценарий — цепочка этапов. Этап — цели и приоритеты.

Из гипотез образуются сценарии: по каждой гипотезе берётся либо гипотеза, либо антигипотеза. Не все комбинации дают разные сценарии. Комбинации, которые дают одинаковые сценарии, сворачиваются в один. Например, если квест не выполняется, то не важно, один или два завода, и не важно, раньше или позже. Все такие комбинации дают один сценарий.

Пример: пять сценариев из трёх гипотез.

Шаг 3. Сравнение сценариев.

Сценарии разной длины: один заканчивается раньше, другой позже. Сценарий не останавливается, когда достиг последней цели. Сценарий продолжает работать до общего момента сравнения.

Общий момент сравнения — когда последний сценарий достиг стратегического финала. Стратегический финал — флаг из_руды, домик построен. Сценарий, который достиг стратегического финала раньше, продолжает строить домики до общего момента.

В этот момент у каждого сценария своё население и своё количество моделируемых действий.

Сравниваем население и моделируемые действия в этот момент.

Главный критерий — население. Второстепенный критерий — количество моделируемых действий. Все сравниваемые величины — целые числа. Критерий лексикографический: сначала население, потом моделируемые действия. Меньше моделируемых действий — лучше.

Шаг 4. Выбор лучшего сценария.

Лучший сценарий — это истинная стратегия.

Шаг 5. Проверка гипотез.

Стратегическая гипотеза, которая ведёт к выигрышной стратегии — правильная.
Стратегическая гипотеза, которая ведёт к проигрышной стратегии — неправильная.

Истина — набор правильных гипотез и соответствующих истине стратегии и тактики.

Приложение 5. Работа АВТ

Как работает АВТ

Сценарий задаёт цели с приоритетами. АВТ превращает цели в моделируемые действия. Это можно делать разными способами.

Как АВТ ищет истинную тактику

АВТ ищет истинную тактику так же, как человек ищет истинную стратегию.

Человек ищет стратегию среди сценариев.
АВТ ищет тактику среди планов.

Человек формулирует стратегические гипотезы о порядке этапов и создаёт сценарии.
АВТ формулирует тактические гипотезы о порядке моделируемых действий и создаёт планы.

Человек сравнивает сценарии по результатам.
АВТ сравнивает планы по результатам.

Человек выбирает лучший сценарий — это истинная стратегия.
АВТ выбирает лучший план — это истинная тактика.

Как АВТ порождает тактические гипотезы

АВТ порождает тактические гипотезы о способах превращения цели в моделируемые действия.

Тактическая гипотеза — утверждение о выгодности варианта способа.
Антигипотеза — противоположное утверждение.

АВТ порождает все перестановки моделируемых действий внутри цели. Отсечение — см. раздел «Ограничение перебора».

Как АВТ строит пары планов

АВТ строит пару планов: один с гипотезой, один с антигипотезой.

План с гипотезой — маршрут в графе моделируемых действий, где порядок моделируемых действий соответствует гипотезе.
План с антигипотезой — маршрут, где порядок моделируемых действий соответствует антигипотезе.

Пока цель этапа не достигнута, выполняются действия из перестановки. После достижения цели этапа мир переходит к действию по умолчанию. Действие по умолчанию — это то, что делает мир до наступления общего момента сравнения.

Как АВТ сравнивает планы

Планы разной длины: один заканчивается раньше, другой позже.

Сравнение в одном времени: все планы доходят до момента, когда последний из них закончился.

В этот момент у каждого плана своё население и своё количество моделируемых действий.

Сравниваем население и моделируемые действия в этот момент.

Два мира сравнимы по времени, если время отличается меньше, чем на величину максимального такта.

План с лучшим результатом становится тактикой.

Ограничение перебора

АВТ не перебирает все моделируемые действия. АВТ работает в рамках целей этапа. Цели этапа заданы сценарием с приоритетами. Цели заданы снаружи по отношению к АВТ. АВТ не придумывает цели верхнего уровня, а только разбивает и уточняет их.

АВТ порождает гипотезы только о порядке моделируемых действий внутри цели. Количество способов ограничено числом перестановок моделируемых действий внутри цели.

АВТ отсекает ветки, которые не ведут к цели.

Эвристика 1: моделируемые действия независимы, если не меняют одни и те же ресурсы и не конкурируют за труд. Конкуренция за труд — только если труда не хватает на оба моделируемых действия сразу. В текущей модели конкуренция за труд не проверяется. Предполагается, что труда хватает на все обмены. Если в будущем труда будет не хватать, эвристика 1 должна учитывать конкуренцию.

Эвристика 3: блокирующее раньше. Если моделируемое действие A блокирует моделируемое действие B, A надо делать раньше.

В текущей модели эвристика 3 не применяется: все цели этапов содержат либо одно действие, либо несколько независимых обменов. Число перестановок для цели «построить завод» — 6, потому что обмены независимы и не блокируют друг друга. Эвристика 3 понадобится, когда появятся цели с зависимыми действиями.

Проверка после действия

Проверка после моделируемого действия: проверять, если после моделируемого действия ресурс ниже целевого уровня или ресурс увеличился. Не проверять, если после моделируемого действия ресурс выше или равен целевому и ресурс уменьшился.

Действие по умолчанию

Действие по умолчанию — то, что делает мир после достижения цели этапа, пока не наступит общий момент сравнения. В текущей модели действие по умолчанию — строить домики, если есть ресурсы, иначе ждать. Это одинаково для всех целей и всех этапов: после достижения любой цели мир продолжает строить домики. Если в будущем появятся другие цели, действие по умолчанию может зависеть от сценария.

Кеширование гипотез

АВТ кеширует тактические гипотезы так же, как человек кеширует стратегические гипотезы. См. Приложение 2, термин «Кеширование гипотез».

Как это работает на целях

Цель «построить завод»

Завод требует 100 стали, 500 товаров, 1000 энергии. Строительство завода всегда последнее. Перестановки — только для обменов. Три обмена дают 6 перестановок.

Зависит от запасов на складе и в производстве.

Цель «копить топливо»

Топливо производится из энергии. Энергия производится из труда. Топливо копится на складе.

Способы: покупать энергию частями или сразу; покупать топливо частями или сразу.

Цель «строить домики»

Моделируемое действие — построить несколько домиков. Количество ограничено запасом на складе. Запас может быть дан изначально или получен бонусом.

Способы:

Копить ресурсы, потом строить пачкой.
Строить по одному по мере накопления.

Приложение 6. Формализация АВТ в псевдокоде

Вход АВТ

Вход:
    Этап — цели и приоритеты
    Начальное_состояние — состояние модели, время
    Сценарий — сценарий, к которому относится этап

Выход:
    Граф — граф моделируемых действий
    Лучший_план — маршрут в графе миров

Структуры данных

Состояние_модели:
    строения: {шахт, электростанций, заводов, топливных}
    склад: {сталь, товары, энергия, топливо, труд, КР, наука}
    запасы: {сталь_в_шахте, энергия_в_станциях, товары_в_заводах, топливо_в_топливных}
    буферы: {сталь, энергия, товары, топливо}
    население: целое (млн жителей)

Мир:
    состояние_модели: Состояние_модели
    время: вещественное (игровые периоды)
    длительность_такта: вещественное (игровые периоды)
    артефакты: {флаг_из_руды, домиков_на_этапе, текущий_этап}

Моделируемое_действие:
    тип: {обменять_сталь, обменять_товары, обменять_энергию, обменять_топливо,
          построить_домик, построить_завод, забрать_бонус, подождать}
    параметры: {единиц, тактов}

Граф_моделируемых_действий:
    узлы: список Миров
    рёбра: список (Мир_откуда, Моделируемое_действие, Мир_куда)

План:
    маршрут: список Миров (путь в графе)
    время_финала: вещественное (игровые периоды)

Построение графа

АЛГОРИТМ Построить_граф(Этап, Начальное_состояние, Сценарий):

    Текущая_цель = Первая_цель_этапа(Этап)
    Действия = Действия_ведущие_к_цели(Текущая_цель, Начальное_состояние)
    Перестановки = Все_перестановки(Действия)

    Граф = Создать_пустой_граф()
    Граф.узлы.добавить(Создать_мир(Начальное_состояние, время=0))

    Планы = []
    ДЛЯ КАЖДОЙ перестановки В Перестановки:
        План = Построить_план(перестановка, Граф, Сценарий)
        ЕСЛИ План ≠ пусто:
            Планы.добавить(План)

    Общий_момент = МАКСИМУМ(план.время_финала ДЛЯ КАЖДОГО плана В Планы)

    ДЛЯ КАЖДОГО плана В Планы:
        Продолжить_план(план, Общий_момент, Граф, Сценарий)

    Планы = Отсечь_ветки(Планы)
    Лучший_план = Выбрать_лучший(Планы, Общий_момент)

    ВЕРНУТЬ {граф: Граф, лучший_план: Лучший_план}

Действия, ведущие к цели

АЛГОРИТМ Действия_ведущие_к_цели(Цель, Состояние):
    # Для цели «построить завод» — три обмена: сталь, товары, энергия.
    # Само строительство завода не входит в перестановки: оно всегда последнее.
    # Для цели «копить топливо» — обмен энергии и обмен топлива.
    # Для цели «строить домики» — одно действие: построить домик.
    ВЕРНУТЬ Список_действий(Цель)

Построение плана

АЛГОРИТМ Построить_план(перестановка, Граф, Сценарий):

    Текущий_мир = Граф.узлы[0]
    Маршрут = [Текущий_мир]

    ДЛЯ КАЖДОГО действия В перестановке:
        ПОКА НЕ Можно_выполнить(действие, Текущий_мир):
            Ждать = подождать(тактов=1)
            Новый_мир = Применить(Ждать, Текущий_мир, Сценарий)
            Граф.узлы.добавить(Новый_мир)
            Граф.рёбра.добавить((Текущий_мир, Ждать, Новый_мир))
            Маршрут.добавить(Новый_мир)
            Текущий_мир = Новый_мир
        Новый_мир = Применить(действие, Текущий_мир, Сценарий)
        Граф.узлы.добавить(Новый_мир)
        Граф.рёбра.добавить((Текущий_мир, действие, Новый_мир))
        Маршрут.добавить(Новый_мир)
        Текущий_мир = Новый_мир

    ПОКА НЕ Достигнут_финал(Текущий_мир, Сценарий):
        ЕСЛИ Цель_этапа_достигнута(Текущий_мир, Сценарий):
            Следующий_этап(Текущий_мир, Сценарий)
        Действие = Выбрать_действие_по_умолчанию(Текущий_мир)
        Новый_мир = Применить(Действие, Текущий_мир, Сценарий)
        Граф.узлы.добавить(Новый_мир)
        Граф.рёбра.добавить((Текущий_мир, Действие, Новый_мир))
        Маршрут.добавить(Новый_мир)
        Текущий_мир = Новый_мир

    ВЕРНУТЬ {маршрут: Маршрут, время_финала: Текущий_мир.время}

Продолжение плана до общего момента

АЛГОРИТМ Продолжить_план(план, Общий_момент, Граф, Сценарий):

    Текущий_мир = план.маршрут[конец]

    ПОКА Текущий_мир.время

Создание мира

АЛГОРИТМ Создать_мир(Начальное_состояние, время):
    Мир = {}
    Мир.состояние_модели = Копировать(Начальное_состояние)
    Мир.время = время
    Мир.длительность_такта = 1 / Мир.состояние_модели.население
    Мир.артефакты = {флаг_из_руды: ложь, домиков_на_этапе: 0, текущий_этап: 1}
    ВЕРНУТЬ Мир

Проверка возможности действия

АЛГОРИТМ Можно_выполнить(действие, мир):
    ЕСЛИ действие.тип == обменять_сталь:
        ВЕРНУТЬ мир.склад.труд >= действие.параметры.единиц * 7 И
                мир.запасы.сталь_в_шахте >= действие.параметры.единиц
    ЕСЛИ действие.тип == обменять_товары:
        ВЕРНУТЬ мир.склад.труд >= действие.параметры.единиц И
                мир.запасы.товары_в_заводах >= действие.параметры.единиц
    ЕСЛИ действие.тип == обменять_энергию:
        ВЕРНУТЬ мир.склад.труд >= действие.параметры.единиц И
                мир.запасы.энергия_в_станциях >= действие.параметры.единиц
    ЕСЛИ действие.тип == обменять_топливо:
        ВЕРНУТЬ мир.склад.энергия >= действие.параметры.единиц И
                мир.запасы.топливо_в_топливных >= действие.параметры.единиц
    ЕСЛИ действие.тип == построить_домик:
        ВЕРНУТЬ мир.склад.сталь >= 4 И
                мир.склад.товары >= 12 И
                мир.склад.энергия >= 19
    ЕСЛИ действие.тип == построить_завод:
        ВЕРНУТЬ мир.склад.сталь >= 100 И
                мир.склад.товары >= 500 И
                мир.склад.энергия >= 1000
    ЕСЛИ действие.тип == забрать_бонус:
        ВЕРНУТЬ Квест_выполнен(мир)
    ЕСЛИ действие.тип == подождать:
        ВЕРНУТЬ истина

Применение действия

АЛГОРИТМ Применить(действие, мир, Сценарий):

    Новый_мир = Копировать(мир)

    ЕСЛИ действие.тип == обменять_сталь:
        Новый_мир.запасы.сталь_в_шахте -= действие.параметры.единиц
        Новый_мир.склад.сталь += действие.параметры.единиц
        Новый_мир.склад.труд -= действие.параметры.единиц * 7
    ЕСЛИ действие.тип == обменять_товары:
        Новый_мир.запасы.товары_в_заводах -= действие.параметры.единиц
        Новый_мир.склад.товары += ОКРУГЛИТЬ_ВНИЗ(действие.параметры.единиц * 1.5)
        Новый_мир.склад.труд -= действие.параметры.единиц
    ЕСЛИ действие.тип == обменять_энергию:
        Новый_мир.запасы.энергия_в_станциях -= действие.параметры.единиц
        Новый_мир.склад.энергия += действие.параметры.единиц * 3
        Новый_мир.склад.труд -= действие.параметры.единиц
    ЕСЛИ действие.тип == обменять_топливо:
        Новый_мир.запасы.топливо_в_топливных -= действие.параметры.единиц
        Новый_мир.склад.топливо += ОКРУГЛИТЬ_ВНИЗ(действие.параметры.единиц * 0.2)
        Новый_мир.склад.энергия -= действие.параметры.единиц
    ЕСЛИ действие.тип == построить_домик:
        Новый_мир.склад.сталь -= 4
        Новый_мир.склад.товары -= 12
        Новый_мир.склад.энергия -= 19
        # Население хранится в миллионах жителей.
        Новый_мир.состояние_модели.население += 2
        Новый_мир.артефакты.домиков_на_этапе += 1
        Новый_мир.длительность_такта = 1 / Новый_мир.состояние_модели.население
    ЕСЛИ действие.тип == построить_завод:
        Новый_мир.склад.сталь -= 100
        Новый_мир.склад.товары -= 500
        Новый_мир.склад.энергия -= 1000
        Новый_мир.состояние_модели.строения.топливных += 1
    ЕСЛИ действие.тип == забрать_бонус:
        Новый_мир.склад.КР += 45
        Новый_мир.склад.труд += 300
        Новый_мир.склад.наука += 500
        Новый_мир.склад.сталь += 550
        Новый_мир.склад.товары += 1400
        Новый_мир.склад.энергия += 1200
    ЕСЛИ действие.тип == подождать:
        игровое_время = действие.параметры.тактов * Новый_мир.длительность_такта
        Новый_мир.время += игровое_время
        Новый_мир = Обновить_запасы(Новый_мир, действие.параметры.тактов, игровое_время)

    Обновить_флаги(действие, Новый_мир, Сценарий)

    ВЕРНУТЬ Новый_мир

Обновление запасов

АЛГОРИТМ Обновить_запасы(мир, тактов, игровое_время):

    # За 1 такт население даёт 1 труд
    мир.склад.труд += тактов

    # Прибавить к буферам прирост за прошедшее игровое время
    мир.буферы.сталь += игровое_время * мир.строения.шахт * 100
    мир.буферы.энергия += игровое_время * мир.строения.электростанций * 100
    мир.буферы.товары += игровое_время * мир.строения.заводов * 100
    мир.буферы.топливо += игровое_время * мир.строения.топливных * 100

    # Перенести целую часть буфера в запас
    целая = ЦЕЛАЯ_ЧАСТЬ(мир.буферы.сталь)
    мир.буферы.сталь -= целая
    мир.запасы.сталь_в_шахте += целая

    целая = ЦЕЛАЯ_ЧАСТЬ(мир.буферы.энергия)
    мир.буферы.энергия -= целая
    мир.запасы.энергия_в_станциях += целая

    целая = ЦЕЛАЯ_ЧАСТЬ(мир.буферы.товары)
    мир.буферы.товары -= целая
    мир.запасы.товары_в_заводах += целая

    целая = ЦЕЛАЯ_ЧАСТЬ(мир.буферы.топливо)
    мир.буферы.топливо -= целая
    мир.запасы.топливо_в_топливных += целая

    # Ограничить запасы
    мир.запасы.сталь_в_шахте = МИН(мир.строения.шахт * 100, мир.запасы.сталь_в_шахте)
    мир.запасы.энергия_в_станциях = МИН(мир.строения.электростанций * 100, мир.запасы.энергия_в_станциях)
    мир.запасы.товары_в_заводах = МИН(мир.строения.заводов * 100, мир.запасы.товары_в_заводах)
    мир.запасы.топливо_в_топливных = МИН(мир.строения.топливных * 100, мир.запасы.топливо_в_топливных)

    ВЕРНУТЬ мир

Проверка финала

АЛГОРИТМ Достигнут_финал(мир, Сценарий):
    ЕСЛИ мир.артефакты.флаг_из_руды И
       Домик_построен(мир, Сценарий):
        ВЕРНУТЬ истина
    ИНАЧЕ:
        ВЕРНУТЬ ложь

АЛГОРИТМ Домик_построен(мир, Сценарий):
    ЕСЛИ мир.артефакты.домиков_на_этапе > 0 И
       мир.артефакты.текущий_этап == Последний_этап(Сценарий):
        ВЕРНУТЬ истина
    ИНАЧЕ:
        ВЕРНУТЬ ложь

Обновление флагов

АЛГОРИТМ Обновить_флаги(действие, мир, Сценарий):
    ЕСЛИ Склад_пуст(мир) И мир.артефакты.текущий_этап == Последний_этап(Сценарий) И
       НЕ мир.артефакты.флаг_из_руды:
        мир.артефакты.флаг_из_руды = истина

    ЕСЛИ действие.тип == забрать_бонус:
        мир.артефакты.флаг_из_руды = ложь

АЛГОРИТМ Склад_пуст(мир):
    # Топливо, КР и наука не входят в проверку.
    # Топливо — цель квеста, не тратится на домики.
    # КР в текущей модели не используются для покупки ресурсов.
    # Наука в текущей модели не используется для исследований.
    # Эти ресурсы не влияют на строительство домиков.
    ЕСЛИ мир.склад.сталь == 0 И
       мир.склад.товары == 0 И
       мир.склад.энергия == 0 И
       мир.склад.труд == 0:
        ВЕРНУТЬ истина
    ИНАЧЕ:
        ВЕРНУТЬ ложь

Действие по умолчанию

АЛГОРИТМ Выбрать_действие_по_умолчанию(мир):
    ЕСЛИ Есть_ресурсы_на_домик(мир):
        ВЕРНУТЬ построить_домик
    ИНАЧЕ:
        ВЕРНУТЬ подождать(тактов=1)

АЛГОРИТМ Есть_ресурсы_на_домик(мир):
    ЕСЛИ мир.склад.сталь >= 4 И
       мир.склад.товары >= 12 И
       мир.склад.энергия >= 19:
        ВЕРНУТЬ истина
    ИНАЧЕ:
        ВЕРНУТЬ ложь

Вход на этап

АЛГОРИТМ Вход_на_этап(мир, Сценарий):
    мир.артефакты.домиков_на_этапе = 0

АЛГОРИТМ Следующий_этап(мир, Сценарий):
    мир.артефакты.текущий_этап += 1
    Вход_на_этап(мир, Сценарий)

Отсечение веток

АЛГОРИТМ Отсечь_ветки(Планы):

    Отсечённые = []

    ДЛЯ КАЖДОГО плана В Планы:
        ЕСЛИ Есть_эквивалентный_план(плана, Отсечённые):
            ПРОДОЛЖИТЬ
        # В текущей модели эвристика 3 не применяется: все цели содержат независимые действия.
        # Проверка Нарушает_порядок_блокировки не используется.
        # Она понадобится, когда появятся цели с зависимыми действиями.
        ЕСЛИ НЕ Прошёл_проверку_после_действия(плана):
            ПРОДОЛЖИТЬ
        Отсечённые.добавить(плана)

    ВЕРНУТЬ Отсечённые

Эквивалентность планов

АЛГОРИТМ Есть_эквивалентный_план(план, Список_планов):
    # План считается эквивалентным, если у него такое же конечное состояние модели
    # и такое же время финала, как у одного из уже отобранных планов.
    ДЛЯ КАЖДОГО отобранного В Список_планов:
        ЕСЛИ Состояния_равны(план.маршрут[конец].состояние_модели,
                              отобранного.маршрут[конец].состояние_модели) И
           план.время_финала == отобранного.время_финала:
            ВЕРНУТЬ истина
    ВЕРНУТЬ ложь

Проверка после действия

АЛГОРИТМ Прошёл_проверку_после_действия(план):

    ДЛЯ КАЖДОГО перехода В план.маршрут:
        Мир_до = переход.откуда
        Мир_после = переход.куда
        Ресурсы_из_условия = Ресурсы_цели(план.этап)

        ДЛЯ КАЖДОГО ресурса В Ресурсы_из_условия:
            Значение_до = Мир_до.склад[ресурс]
            Значение_после = Мир_после.склад[ресурс]
            Целевой_уровень = Целевой_уровень(ресурс, план.этап)

            # Проверка: если ресурс упал ниже целевого и не восстановится — план отсекается.
            ЕСЛИ Значение_после

Сравнение планов

АЛГОРИТМ Выбрать_лучший(Планы, Общий_момент):

    # Проверка: все планы должны иметь время финала, отличающееся от общего момента
    # не больше, чем на максимальный такт среди планов.
    Максимальный_такт = МАКСИМУМ(1 / план.маршрут[конец].состояние_модели.население
                                  ДЛЯ КАЖДОГО плана В Планы)

    Лучший_план = пусто

    ДЛЯ КАЖДОГО плана В Планы:
        ЕСЛИ АБС(план.время_финала - Общий_момент) > Максимальный_такт:
            ПРОДОЛЖИТЬ
        ЕСЛИ Лучший_план == пусто:
            Лучший_план = план
            ПРОДОЛЖИТЬ
        Результат = Результат_на_момент(план, Общий_момент)
        Лучший_результат = Результат_на_момент(Лучший_план, Общий_момент)
        ЕСЛИ Результат.население > Лучший_результат.население:
            Лучший_план = план
        ИНАЧЕ ЕСЛИ Результат.население == Лучший_результат.население:
            ЕСЛИ Результат.количество_действий

Кеширование гипотез

АЛГОРИТМ Кешировать_гипотезу(гипотеза, условие):
    ЕСЛИ Условие_совпадает(условие, кеш.условие):
        ВЕРНУТЬ кеш.результат
    ИНАЧЕ:
        Результат = Проверить_гипотезу(гипотеза, условие)
        кеш.сохранить(условие, Результат)
        ВЕРНУТЬ Результат

Приложение 7. Состояние модели

Состояние модели — набор строений, накопления на складе, запасы в строениях. Всё целые числа.

Запасы в строениях накапливаются пропорционально 100 единиц за игровой период (6 часов). Скорость накопления не зависит от населения и от длительности такта. Она зависит только от игрового времени, которое прошло.

Строения

Шахта — накапливает возможности добыть сталь. 100 единиц за игровой период (6 часов). Запас 100.
Электростанция — накапливает возможности произвести энергию. 100 единиц за игровой период (6 часов). Запас 100. В начале 4 штуки.
Завод — накапливает возможности произвести товары. 100 единиц за игровой период (6 часов). Запас 100. В начале 5 штук.
Завод ракетного топлива — накапливает возможности конвертировать условные единицы в топливо. 100 единиц за игровой период (6 часов). Запас 100. В начале 0 штук.

Склад

Склад хранит сталь, товары, энергию, топливо, труд, КР, науку. Весь склад ограничен, но ограничение высокое, и в расчётах считается, что его нет.

КР — кредиты. Кредиты хранятся на складе. Кредиты используются для покупки ресурсов (описание покупки — за рамками текущей модели).

Наука — ресурс, который хранится на складе. Наука используется для исследований (описание исследований — за рамками текущей модели).

Обмены

Шахта: ты вводишь число единиц заказа. Списывается 7 труда за 1 единицу заказа. Зачисляется 1 сталь за 1 единицу заказа.
Завод: ты вводишь число единиц заказа. Списывается 1 труд за 1 единицу заказа. Зачисляется 1.5 товара за 1 единицу заказа. Округление результата вниз.
Электростанция: ты вводишь число единиц заказа. Списывается 1 труд за 1 единицу заказа. Зачисляется 3 энергии за 1 единицу заказа.
Завод ракетного топлива: ты вводишь число единиц заказа. Списывается 1 энергия за 1 единицу заказа. Зачисляется 0.2 топлива за 1 единицу заказа. Округление результата вниз.

Домик

Домик на 2 миллиона жителей требует 4 стали, 12 товаров, 19 энергии.

Завод ракетного топлива

Завод ракетного топлива требует 100 стали, 500 товаров, 1000 энергии.

Квест

Квест — накопить 160 топлива на складе. За выполнение квеста правительство выдаёт бонус: 45 КР, 300 труда, 500 науки, 550 стали, 1400 товаров, 1200 энергии. Бонус забирается отдельным моделируемым действием.

Население

Население хранится в миллионах жителей. Население даёт труд: 1 миллион жителей даёт 1 труд за 1 игровой период (6 часов игрового времени). За 1 такт население даёт 1 труд. Такт нужен только для дискретизации труда: 1 труд целым числом за 1 такт. Всё остальное считается в игровых периодах. Длительность такта пересчитывается при изменении населения: 1 такт = 1 игровой период / население (в млн).

Пример

В начале: 550 миллионов жителей, 322 стали на складе, 0 товаров, 25 энергии, 96 топлива, 0 труда. Одна шахта, четыре электростанции, пять заводов, ноль заводов ракетного топлива.

Установил Eclipse и Web Development Tools (WDT)

aary — Sat, 19 Sep 2026 08:25:44 +0000

Теоретически, это должно позволять отлаживать web-приложения. Практически я только научился запускать и останавливать второй веб-сервер изнутри IDE, и только. Ну, конечно, ещё наверное хорошо, что там проект отображается и визарды есть... Но я их пока не освоил.

ibis.wiki - собрал, установил, настроил, ... заполнил?

aary — Fri, 12 Jun 2026 16:07:36 +0000

2026-09-29

Собрал версию Ibis.wiki 0.3.3 из исходных текстов, пропатчил:

~/rust/ibis/Nutomic$ git diff
diff --git a/crates/federate/src/validate.rs b/crates/federate/src/validate.rs
index a6709f1..35d2edd 100644
--- a/crates/federate/src/validate.rs
+++ b/crates/federate/src/validate.rs
@@ -6,7 +6,7 @@ use std::sync::LazyLock;
 pub fn validate_article_title(title: &str) -> BackendResult<()> {
     #[expect(clippy::expect_used)]
     static TITLE_REGEX: LazyLock<Regex> =
-        LazyLock::new(|| Regex::new(r"^[a-zA-Z0-9-. ()]{3,100}$").expect("compile regex"));
+        LazyLock::new(|| Regex::new(r"^[\p{L}\p{N}\-. ()_]{3,100}$").expect("compile regex"));
     if !TITLE_REGEX.is_match(title) {
         return Err(anyhow!("Invalid title").into());
     }

Задеплоил

2026-06-12

Установил версию 0.3.0 из контейнера с докерхаба

Однако счастья это пока не принесло.

В частности, в ibis.wiki нельзя называть страницы русскими буквами. Это печально.

Собрал Heritrix 3 через GitLab CI

aary — Fri, 15 May 2026 04:08:16 +0000

Немало времени на это потратил. И на перенастройку самого Heritrix3. Оказалось, что нельзя пытаться заблокировать скачивание robots.txt, потому что это обязательный ритуал у Heritrix3, он их с каждого сайта качает первыми.

В этот раз HEAD/master (3.14.1+), а не 3.10 как в прошлый. Впрочем, разница незаметна. Теперь контейнеры делаются через Dockerfile + docker-compose.yml

Предыдущая запись была 9 апреля, эта 15 мая. Получается, что больше месяца времени на это потратил.

Попробовал создавать БД при помощи Liquibase 5.0.2

aary — Thu, 9 Apr 2026 20:45:32 +0000

Технический отчёт за сегодня

1. Настройка развёртывания приложения

Устранена ошибка сборки, связанная с несуществующей версией родительского POM Spring Boot.
Настроен Tomcat Manager API для удалённого деплоя WAR-файла через HTTP-запросы.
Решена проблема доступа к Manager API (403), вызванная ограничениями по IP в конфигурации контекста Tomcat.
Создан скрипт предварительной инициализации контейнера для копирования стандартной конфигурации Tomcat и веб-приложения Manager.

2. Подключение к базе данных

Настроена сетевая связанность между Docker-контейнером Tomcat и сервером PostgreSQL на хосте.
Исправлены синтаксические ошибки в конфигурации pg_hba.conf, приводившие к отказу в подключении.
Зафиксирована подсеть Docker в compose.yaml для обеспечения стабильного IP-адреса контейнера и корректной аутентификации в БД.

3. Управление схемой базы данных

Подключена и настроена миграционная система Liquibase.
Созданы файлы миграций для автоматического развёртывания таблиц пользователей и ролей.
Реализована проверка актуальности схемы БД при запуске приложения с перенаправлением на инструкции по обновлению в случае несоответствия.
Добавлено логирование статуса выполнения миграций.

4. Система аутентификации и авторизации

Настроена Spring Security с хранением учётных записей в базе данных PostgreSQL.
Реализована публичная страница регистрации новых пользователей.
Создана административная панель с возможностью просмотра списка пользователей и блокировки/разблокировки учётных записей.
Реализовано автоматическое создание учётной записи администратора при первом запуске либо через веб-форму мастера установки, либо через переменные окружения.

5. Мастер первоначальной настройки

Разработан контроллер, выполняющий проверку готовности окружения (наличие БД, версия СУБД, состояние схемы, наличие администратора).
Создан набор информационных страниц с пошаговыми инструкциями для устранения типовых проблем (отсутствие подключения к БД, необходимость обновления СУБД, запуск миграций и др.).
Обеспечено блокирование доступа к страницам мастера после завершения настройки.

6. Доработка интерфейса и навигации

Скорректированы ссылки в шаблонах для корректной работы с контекстом приложения.
Устранены ошибки в Thymeleaf-выражениях, вызывавшие исключения при отсутствии активного профиля Spring.
Актуализировано содержимое главной страницы в соответствии с предметной областью.

7. Оптимизация и диагностика

Выявлена и решена проблема длительного запуска Tomcat, связанная со сканированием TLD в JAR-файлах.
Добавлены инструкции по точечному отключению сканирования TLD через контекстный XML-файл.
Рассмотрены рекомендации по улучшению аутентификации в PostgreSQL с использованием SSL-сертификатов и по управлению ограничениями доступа для пользователей.

Результаты

Приложение успешно развёртывается и работает в целевой среде.
Обеспечена возможность самостоятельной настройки окружения администратором без ручного вмешательства в конфигурационные файлы.
Реализован базовый функционал управления пользователями и ролями.

Настроил Heritrix 3.10.0 и OpenWayback

aary — Tue, 7 Apr 2026 20:33:21 +0000

Отчёт о настройке системы веб-архивации

1. Цель работы

Настроить полный цикл сбора и последующего воспроизведения веб-контента:

Запустить и сконфигурировать краулер для выборочного скачивания сайтов.
Обеспечить передачу собранных данных в систему воспроизведения архивных копий.
Настроить фильтрацию: скачивать только нужные сайты, но при этом подхватывать все внешние ресурсы (стили, скрипты, изображения, файлы книг), необходимые для корректного отображения страниц.
Исключить нежелательный переход на посторонние сайты по обычным гиперссылкам.
Проверить работоспособность всей цепочки и выявить оптимальные настройки.

2. Используемые компоненты

Краулер – программа для сбора веб-страниц и файлов.
Система воспроизведения архивов – для просмотра сохранённых копий.
Контейнеризация – для изолированного запуска компонентов на выделенном сервере.
Рабочая станция – для подготовки конфигураций и анализа логов.

3. Выполненные этапы

3.1. Развёртывание и начальная настройка

Краулер и система воспроизведения запущены в отдельных контейнерах на серверной машине.
Настроен общий том (директория) для обмена собранными архивными файлами между краулером и системой воспроизведения.
Организована сетевая доступность между компонентами.

3.2. Настройка краулера (базовый режим)

Подготовлен минимальный рабочий конфигурационный файл, позволяющий краулеру запускаться и обрабатывать указанный начальный адрес.
В процессе отладки были устранены ошибки, связанные с аутентификацией веб-интерфейса краулера и правами на запись в рабочие каталоги.

3.3. Организация рекурсивного обхода сайта

Изначально краулер скачивал только главную страницу и не переходил по внутренним ссылкам.
Путём корректировки правил обхода («scope») удалось настроить бесконечную глубину перехода по ссылкам внутри целевого сайта.
Достигнуто стабильное скачивание сотен внутренних страниц (количество обработанных URL выросло с единиц до тысяч).

3.4. Ограничение области сканирования

В конфигурацию добавлены правила, запрещающие переход на посторонние домены по обычным гиперссылкам.
Это предотвратило «уход» краулера во внешний интернет и позволило сфокусироваться на целевом сайте.

3.5. Разрешение внешних ресурсов (стили, скрипты, картинки)

Обнаружено, что при ограничении доменов перестали скачиваться необходимые элементы оформления (CSS, JavaScript, изображения), которые физически расположены на других сайтах.
Разработана комбинация правил:
- Список разрешённых доменов для таких ресурсов задан в отдельном файле.
- Включена проверка «родительской страницы» – внешний ресурс скачивается только если на него есть ссылка с уже принятой страницы целевого сайта.
В результате стили и скрипты стали корректно сохраняться в архив, что обеспечивает правильное отображение страниц при воспроизведении.

3.6. Настройка скачивания файлов (книг, документов)

В конфигурацию добавлено правило, принимающее любые ссылки на файлы с типичными расширениями (PDF, EPUB, FB2, DJVU, DOC и др.) независимо от их домена.
Это позволило автоматически собирать все книжные и архивные файлы, на которые есть ссылки со страниц целевого сайта.

3.7. Отладка синтаксиса правил

В ходе работы выяснились особенности синтаксиса, используемого правилами фильтрации.
После нескольких итераций был найден рабочий вариант записи префиксов, обеспечивающий корректное распознавание доменов.
Лишние, неиспользуемые правила удалены для упрощения конфигурации.

3.8. Проверка целостности данных

Выполнен анализ логов краулера, подтверждающий, что скачиваются как страницы целевого сайта, так и внешние стили, скрипты, а также файлы книг.
Через интерфейс системы воспроизведения подтверждена возможность просмотра сохранённых страниц (со стилями) и доступа к скачанным файлам.

4. Достигнутые результаты

Стабильная работа краулера: система запускается, обрабатывает тысячи URL, не «падает» и не уходит на посторонние сайты.
Полное воспроизведение страниц: архивные копии отображаются с оригинальными стилями и оформлением.
Автоматический сбор внешних файлов: все ссылки на книги, документы и архивы, встречающиеся на целевых страницах, сохраняются в архив.
Гибкая настройка: правила фильтрации легко дополнять новыми типами файлов или разрешёнными доменами.
Прозрачность работы: все действия логируются, что позволяет отслеживать поведение краулера и выявлять возможные проблемы.

5. Замечания и рекомендации

Для обеспечения полноты архива периодически следует проверять, не появились ли на сайте ссылки на новые типы ресурсов (например, аудио, видео), и при необходимости расширять список разрешённых расширений.
При значительном росте объёма архива рекомендуется рассмотреть использование внешнего индексатора (например, CDX-сервера) для ускорения поиска и масштабирования.
В случае изменения структуры внешних ресурсов (смена домена CDN) потребуется обновить список разрешённых доменов.
Все конфигурационные файлы и сценарии запуска целесообразно хранить в системе контроля версий для воспроизводимости.

6. Вывод

В результате проделанной работы создана полностью функционирующая система веб-архивации, которая:

собирает контент с заданного сайта, включая все необходимые внешние ресурсы и файлы;
ограничивает обход только нужными доменами, не допуская бесконечного блуждания по интернету;
сохраняет собранные данные в формате, пригодном для последующего просмотра через интерфейс архивной системы.

Настройки могут быть повторно использованы для любых других сайтов с минимальными правками (замена целевого домена и, при необходимости, списка внешних ресурсов).

Установил/настроил Apache Archiva 2.2.10

aary — Fri, 3 Apr 2026 07:04:08 +0000

✅ Сборка из исходников

Успешно выполнена полная сборка Apache Archiva 2.2.10 из официального Git-репозитория по релизному тегу
Сгенерирован целевой артефакт: archiva-webapp-2.2.10.war
Все 68 модулей проекта прошли компиляцию и тестирование зависимостей без критических сбоев
Настроено стабильное разрешение артефактов через внутренний Maven-репозиторий

✅ Исправление JavaUtils (совместимость с современными JRE)

Выявлена причина падений персистентного слоя: устаревший парсер версий в org.jpox.util.JavaUtils
Переписана логика сравнения версий: устранено затенение переменных, добавлена корректная обработка формата major.minor.patch
Патч применён к библиотеке JPOX 1.1.9, пересобран и опубликован в локальном репозитории
Обеспечена стабильная работа JDO-слоя на актуальных версиях Java (17+)

✅ Настройка mail.jar

Устранены конфликты класслоадеров: почтовая библиотека вынесена в общий classpath сервера приложений
Настроен JNDI-ресурс javax.mail.Session для корректной работы почтовых уведомлений Archiva
Обеспечена совместимость с современными API активации и предотвращён дублирующий класс-лоадинг из WEB-INF

✅ Конфигурация Tomcat 9 и деплой через Manager API

Развёрнут и оптимизирован Tomcat 9 с настройкой пулов соединений и политик безопасности
Сконфигурированы JNDI-ресурсы для подключения к PostgreSQL и инициализации контекста приложения
Освоен удалённый деплой через Tomcat Manager API:
- Настроен безопасный доступ к управляющему REST-интерфейсу
- Реализована автоматическая выгрузка, обновление и откат WAR-артефактов без ручного вмешательства
- Интегрирована проверка статуса развёртывания и логирование операций деплоя
- Процесс полностью автоматизирован и готов к интеграции с CI/CD-конвейерами

✅ Настройка сборочного и клиентского окружения

Подготовлена стандартизированная среда разработки: JDK, Maven, Git, системные зависимости
Настроен защищённый канал передачи артефактов между сборочным узлом и сервером приложений
Документирован полный цикл поставки: от клонирования кода до рабочего экземпляра в production-подобной среде
Обеспечена полная воспроизводимость процесса на любых совместимых хостах

📋 Итоговые артефакты и готовность

Сборка:
  - Исходный код: официальный релизный тег 2.2.10
  - Патч JPOX: применён, собран и зафиксирован в артефакторее
  - WAR-файл: archiva-webapp-2.2.10.war (готов к публикации)

Инфраструктура:
  - Сервер приложений: Tomcat 9 с настроенными JNDI-ресурсами
  - СУБД: PostgreSQL с выделенной схемой и пользователем для Archiva
  - Деплой: автоматизирован через Tomcat Manager REST API

🎯 Готовность к следующему этапу

Работает автоматический деплой актуальной сборки через Manager API
Настроен веб-интерфейс, аутентификации и управления репозиториями
Протестирована интеграция с внешними хранилищами и системами сборки
Настройкы политики хранения, резервного копирования и мониторинга

Поставил TightBlog

aary — Sat, 28 Mar 2026 04:40:31 +0000

1. Технические достижения

Запуск TightBlog 4.2.0 на Java 25, PostgreSQL с SSL, исправлены проблемы:
- Десериализация пароля: @JsonProperty перенесены на сеттеры в UserCredentials.java.
- Схема БД: password_hash в weblogger_user снят NOT NULL (двухэтапное сохранение: INSERT с NULL → UPDATE с хешем). Также исправлены date_updated и publish_time в weblog_entry.
- Фиды (Atom): исправлен шаблон entries-atom.html:37 (замена updateTime на dateUpdated).
- Добавлен заголовок Content-Disposition: inline для отображения в браузере.
Роутинг работает: /aary/feed перенаправляется на /tb-ui/rendering/feed/aary через RequestMappingFilter.
Feedbro (расширение Firefox) успешно читает локальный фид, решая проблему внешней валидации.

2. Понимание архитектуры TightBlog

Таблица user_weblog_role была переименована из roller_permission в 2015 году, семантика изменена с «права» на «роль». Это наследие Roller, но TightBlog упростил модель.
Миграции БД перешли от Velocity-генерации к прямым SQL-файлам (Flyway). Это снизило универсальность (только PostgreSQL), но повысило прозрачность и управляемость.
В TightBlog несколько блогов на пользователя поддерживаются, хотя в UI Roller эта функция могла отсутствовать.

3. Ключевые концепции, выработанные в диалоге

Плоские категории vs теги: категории — рубрикация, теги — кросс-тематический поиск. В TightBlog категории не иерархичны.
Фиды: Atom 1.0 + JSON Feed + ActivityPub (последние — для гибкости). Обнаружение фидов через <link rel="alternate">.
Мультиязычность в фидах возможна через отдельные фиды по языкам или через атрибут xml:lang.
Поиск: без ИИ — использовать обратный индекс, ранжирование по доверенному кругу (организации, подписки), группировку по источникам, уточняющие вопросы.
Приватность и обнаружение: нужен баланс между «кругами доверия» и шлюзами наружу. Организация как единица доверия может сертифицировать ключи, управлять доступом, модерацией.
Теги как сообщества: теги становятся точками входа, имеют свои фиды, модерацию, могут быть scoped по организациям.

4. Уроки из истории

«Мой Круг» показал, что неявные круги друзей сложны в UX и не обеспечивают рост. Ваша модель «Планет» с явным членством и уставом может быть понятнее.
Провалы XMPP, Matrix, RetroShare связаны с тем, что они решали технические задачи, забывая о массовом пользователе: сложный старт, отсутствие обнаружения, привязка к серверу, метаданные открыты.
Успешные системы (Email, DNS) работают потому, что владельцы идентичностей заинтересованы поддерживать свои записи.

5. Предложения для будущего движка

Прогрессивная децентрализация: начать с централизованного приложения, затем добавить свой домен, федерацию, P2P.
Организация как КА (центр сертификации): выдаёт сертификаты участникам, публикует каталог, управляет модерацией.
Теги как службы: каждый тег может иметь правила модерации, фид, уровень доступа (публичный/только для участников).
Идентичность: did:web:org:user — портативная, с возможностью миграции.
Поиск: контекстный, с приоритетом доверенного круга, группировкой по источникам, опциональными шлюзами наружу.

Место для публикации текстов

aary — Thu, 19 Mar 2026 16:20:49 +0000

Здесь я буду писать свои мысли. Пока, наверное, на тему создания "схемы технологических работ". Можно подписаться (если есть чем читать подписки).

aary

KeyCloak

Баба Валя упороласть...

Сценарии, планы и их реализации

Оглавление

Основной текст

Приложения

Введение

Два уровня выработки истины

Гипотезы и сценарии

Этап

Действия

Как это связано

Параллельные действия

Зачем это нужно

Приложение 1. Термины действительности (игры)

Действительность

Состояние действительности

РЧ

Игровой период

Реальное действие

Бомбардировка

Приложение 2. Термины программы моделирования/симуляции

О терминах, абстрагирующих другие термины

Состояние модели

Гипотеза

Стратегическая гипотеза

Тактическая гипотеза

Истина

Стратегия

Тактика

Цель

Приоритет

Этап

Сценарий

Финал

Стратегический финал

Тактический финал

Действие

Моделируемое действие

Такт

Мир

План

Реализация плана

Граф моделируемых действий

АВТ

ПЧВСА

Результат этапа

Реализация сценария

Сравнение

Кеширование гипотез

Требование к именам

Приложение 3. Сравнение и финалы

Общий момент сравнения

Связь финалов с целями этапов

Приложение 4. Как человек организует выбор варианта стратегии

Постановка задачи

Шаги

Приложение 5. Работа АВТ

Как работает АВТ

Как АВТ ищет истинную тактику

Как АВТ порождает тактические гипотезы

Как АВТ строит пары планов

Как АВТ сравнивает планы

Ограничение перебора

Проверка после действия

Действие по умолчанию

Кеширование гипотез

Как это работает на целях

Приложение 6. Формализация АВТ в псевдокоде

Вход АВТ

Структуры данных

Построение графа

Действия, ведущие к цели

Построение плана

Продолжение плана до общего момента

Создание мира

Проверка возможности действия

Применение действия

Обновление запасов