Для начала залезем в конфиги 1865 билда. В настройках ботов мы видим такие параметры …

Min_Satiety = 0.000055 (минимальная норма сытости, ниже которой бот считается голодным)

Max_Satiety = 1.0 (максимальная норма сытости)

satiety_v = 0.001 (скорость уменьшения сытости со временем [0...1])

Что это означает? Теоретически это можно описать так. У каждого бота в игре есть текущее значение сытости, которое привязано к игровому времени, и убывает со временем. Его в конфигурации по понятным причинам нет, потому что он уникален для каждого персонажа, а значит есть только в динамической памяти. Есть максимальное значение сытости, выше которого сыт не будешь. И есть минимальное значение, ниже которой бот считается голодным. Если значение убывает, значит должен быть и механизм, который увеличивает значение. Его по понятным причинам в конфигурации тоже нет, это какая-то процедура в самом движке.

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

satiety_critical = 0.25 (критическое значение сытости (в процентах от 0..1) когда здоровье начинает уменьшаться)

Описание говорит само за себя, это порог сытости. Точно такой же параметр есть и у других ботов. И для последних получается, что параметры satiety_critical и Min_Satiety/Max_Satiety дублируют друг друга. А значит какие-то параметры уже не работают, просто их забыли зачистить из конфигурации. И если отталкиваться, что satiety_critical есть у всех ботов, а без порогового значения параметры скорости убывания сытости просто не имеют смысла, то «лишними» здесь являются Min_Satiety/Max_Satiety. Забавно, но эти «лишние» и давно не рабочие параметры есть даже в конфигах Аномалии.

И остался еще один параметр …

satiety_health_v = 0.03 (увеличение здоровья при уменьшении сытости)

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

В целом, получается такая картина. Боты каждый имеют уникальный параметр сытости, который убывает со временем на неуказанную в конфигах величину (предположу, что на единицу, или около того). И есть некое пороговое значение сытости, после пересечения которой (в процентах от общего объема «желудка») убывать начинает уже здоровье на величину satiety_health_v. Раз сытость убывает со временем, то логично предположить и механизм, который увеличивает значение сытности. Иначе все боты на локации рано или поздно попросту вымрут от голода.

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

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

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

-

Это делается приблизительно так. В движке объявляются переменные..

Текущее_значение_сытости, максимальное_значение_сытости, минимальное_значение_сытости, и так далее (условно и для примера) = Integer (мы хотим целочисленные).

Отдельно задается проверка …

Если текущее_значение_сытости < минимальное_значение_сытости, то …

Дальше для бота начинается обратный отсчет, потому что значение сытности преодолело порог. Значит теперь у него уменьшается здоровье …

Текущее_значение_здоровья = текущее_значение_здоровья + satiety_health_v

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

Текущее_значение_сытости = текущее_значение_сытости - 1

И только после этого идет конфигурация. Где в каком-нибудь .ltx заявляются минимальные и максимальные значения, каким величинам они равны.

Если из примера закомментировать объявление, то движок даже не скомпилируется, потому что в нем есть операторы, которые нигде не объявлены, он не знает их типа. Но если в движке снести все остальное, то даже игра не скрошится. Если снести проверку, то движок никогда не будет проверять, проголодался ли бот (уменьшилось ли его значение сытости ниже порога), даже если он честно уменьшает величину сытности, хоть до отрицательных значений. А значит и не будет уменьшать здоровье боту, если тот «проголодался». Можно и по-другому, снести только уменьшение здоровья. Движок проверил, что сытость бота упала ниже критического значения, и ничего дальше. 

-

Теперь вернемся к 1865 билду. В нем есть параметры satiety_v (скорость уменьшения сытости со временем) и satiety_health_v (величина, на которую будет увеличиваться здоровье при наличии «голода»).

В 1865 билде оба параметра работают. Если выставить значение satiety_v = 1000 (чтобы бот побыстрее оголодал) и satiety_health_v = -1000 (минус, потому что у разработчика руки такие были, а тысяча — чтобы бот гарантировано умер, стандартная величина их здоровья 100 .. 200), то боты будут умирать от голода ваншотом, как только загрузятся онлайн (в офлайне живут). Любые, хоть сталкеры, хоть собаки, хоть плоти, хоть кто.

У меня нет оригинальной игры, поэтому я взял ОЛР, который пользуется версией движка Теней. Выставление такого же значения здесь не приводит ни к чему, боты это просто игнорируют. Следовательно, проверка в Тенях закомментирована, либо удалена вовсе. Можно было бы предположить, что это произошло где-то с августа 2004 по март 2007. Но можно поступить иначе, взяв билд 1935, датированный октябрем 2004 года. То есть, прошло всего два месяца. Именно эту сборку, кстати, считают наиболее полной того самого.

В имеющемся у меня билде 1935 параметры satiety_v и satiety_health_v в конфигурации у ботов отсутствуют. Изначально сборка была достаточно нестабильной, и благодаря усилиям фанатов сейчас сложно понять, были там эти параметры вообще. Но даже если их туда вписать со значениями выше, то боты уже не будут умирать от голода, как в билде двумя месяцами ранее. И далее от голода они уже не будут умирать нигде и никогда, ни в Тенях, ни в Небе, ни в Зове, нигде. Но именно версия от октября 2004 считается наиболее полной.

-

Пора подводить итог. Что же пошло не так?

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

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

Что не так? Бот сидит возле костра (или где-то в другом гулаге) и ждет игрока, который в Тенях единственный. Бот здесь для мебели, но мебель может проголодаться и сдохнуть. Она не может победить в первой игре, жрать хочется постоянно, но она может не проиграть и не выгрузиться из памяти, ну хотя бы какое-то время. Для чего ей надо отойти пожрать. Но во второй игре ей запрещено покидать свое место. Дальше развилка, либо сдохнуть от голода в смарте, либо отключить (удалить из кода) проверку. Что вроде бы похоронило первую игру всего за два месяца. Мы прибегаем по квесту к персонажу, а он прямо во время диалога умер, потому что у него упало значение сытости ниже критического уровня, а следом и здоровье до нуля, начинайте игру заново. И, хотя свободное перемещение осталось в 1935 билде, это средство без цели. Смысла для ботов в этом уже нет.