Тот самый сталкер можно увидеть в сборке 1865, может быть даже позднее, но не позднее сборки 1935 (включительно). Что он из себя представлял – это отдельный разговор, он так и не был закончен, но в целом у разработчиков получилось.
12 мая 2003 года появилась сборка 1472. Симуляции (того самого сталкера, который и есть та самая симуляция) пока еще нет. Соответственно, и рассматривать события до смысла тоже нет. 28 октября 2003 года появилась сборка 1580 для показа кому-то. По этой сборке был создан отсчет и все такое, игра готовилась к релизу. Следовательно, тот самый сталкер был создан где-то в промежутке между 12 мая 2003 года и 28 октября 2003 года. И в целом он был готов, была геометрия, симуляция, никаких квестов, скриптов и прочего, что не совместимо с симуляцией, это и есть тот самый сталкер.
Дата рождения и жизни приблизительно понятна, что с датой смерти? Смерть произошла в промежутке между 9 августа 2004 (сборка 1865) и 14 октября 2004 года (сборка 1935). В последней сборке никакого того самого сталкера нет, это релизная игра, только пока еще на старых локациях. К слову, квесты начнутся тоже с 1935 сборки. Если судить по фактам, то в промежутке 09.08.04 – 14.10.04 что-то произошло, какая-то радикальная смена концепции, вместо одной игры стали делать другую. Сначала переписали код (как раз за эти три месяца), начали менять одну из локаций. Потом поменяют и все остальные (а также все остальное).
Как-то странно, если 28 октября 2003 года игра была готова, а менять концепцию и делать другую игру начали 14 октября 2004 года, аж через год. Чем занимались этот год?
19 декабря 2003 года появилась сборка 1632 для отладки скриптов. А 3 февраля 2004 года появилась сборка 1828, где присутствует схема патрулирования. Вообще интересно, а как схема патрулирования совместима с тем самым сталкером, но со сталкероманами уже давно все понятно, поэтому считается, что симуляция была расширена, хотя правильнее сказать, что она была убита 3 февраля 2004 года. Но код перепишут не в промежутке между 19 декабря 2003 года и 3 февраля 2004 года, а почти через год. Если судить по фактам, то между 28 октября 2003 года и 19 декабря 2003 года что-то произошло, какая-то смена концепции, но не радикальная. Она отменила релиз, и, если судить по дальнейшему, и саму игру, потому что дальше разработка стала развиваться в другом направлении, итог чего можно будет увидеть в 2007 году.
Получается такая последовательность. Тот самый сталкер в чистом виде существовал в период 12.05.2003 – 28.10.2003. Далее концепция поменялась в сторону дополнения (скрипты, смарты и прочая постановка, но пока еще без линейного сюжета и квестов), т.е. тот самый сталкер сосуществовал с релизной игрой. А т.к. это несовместимо с симуляцией (а симуляция несовместима со скриптами, смартами и прочей режиссурой), и надо выбрать что-то одно, то в промежутке 09.08.04 – 14.10.04 концепция снова изменилась, симуляция была полностью удалена (и навсегда), а промежуточная концепция (скрипты, смарты и прочая постановка, но пока еще без линейного сюжета и квестов) была дополнена линейным сюжетом и квестами.
Странно, почему код переписали не сразу, а только через год? Зачем вообще поменяли концепцию в первый раз? Смена концепции во второй раз понятна и логична, симуляция непредсказуема с точки зрения геймдизайна, если мы хотим то, что получилось в итоге. Ну как это будет выглядеть, если в скриптовой сцене у бота вдруг закончатся патроны, или он вдруг умрет от голода? Это убивает саму суть скрипта как элемента режиссуры (геймдизайна). На первый вопрос тоже можно предположить, что хотели усидеть на двух стульях, какая-то часть игры под симуляцией, какая-то под режиссурой. Хотя это тоже странно, потому что последствия можно предугадать сразу, даже без сборок, а не в течении года. Симуляция будет постоянно вмешиваться в режиссуру и ломать. Целый год пытались обуздать симуляцию, а потом плюнули и просто удалили? Но зачем вообще нужно было менять концепцию еще в конце 2003 года?
Между сборками 1865 и 1935 два месяца (09.08.04 — 14.10.04 соответственно). И не только два месяца, но и еще пачка сборок. Однако остановимся на этих двух, как если бы между ними никаких других сборок не было. Сборка 1935 лежит в папке «stalker-dream-16oct04», намекая на законченность. Крайне сомнительно, чтобы билд в папку с таким названием вложил кто-то из реальных разработчиков. Чего не скажешь о фанатах, среди которых эта сборка считается наиболее полной версией «того самого». Их не смущает даже то, что это первая сборка, в которой одна из локаций отъехала на тотальный редизайн (до релиза не доберутся практически все из имеющихся). Смущает лишь нестабильность из-за недоработок AI (основная причина). Сборка 1865, по официальной версии, предназначена для тестирования A-life. От билда 1935 отличается, по той же официальной версии, «альтернативными» локациями, отсутствием проработанной звуковой составляющей и спауна. Больше вроде как не отличается ничем.
Чем две сборки отличаются между собой в реальности? Пропустим, что между ними были и другие сборки.
Сборка 1865 — это последняя сборка, в которой у бота могут закончиться патроны. Начиная с 1935 патроны у бота не заканчиваются никогда, хотя по инерции в 1935 бот еще берет что-то из инвентаря (у покойника в инвентаре количество патрон может быть разным).
Сборка 1865 — это последняя сборка, где на ботов действует радиация, они могут проголодаться, и так далее. То есть, взаимодействовать с игровой средой так же, как и игрок (за вычетом шутерной части). Начиная с 1935 таких параметров у них уже не будет никогда.
Сборка 1865 — это последняя сборка, где боты живут своей жизнью, собирают артефакты, оружие, патроны, ПДА, и так далее. Начиная с 1935 сборки они будут жить так, как им предписал режиссер, своей жизнью они уже не будут жить никогда.
Сложно понять, о каких недоработках AI может идти речь, скорее нужно говорить о тотальном упрощении. В результате это две разные игры на одних и тех же картах (с одинаковыми моделями, анимациями и текстурами).
В каком-то интервью А.Прохоров заявил следующее. В 2004 году Сталкер сделан, геометрия есть, наполнение есть, оно симуляционное. Но попытки тестировать, проходить игру, дали понять, что это не играбельно, это невозможно пройти. Игроку нужно встретиться с человеком, а этого человека нет, потому что его съела собака на уровне три. И если он туда придет, то действительно увидит труп этого человека, и можно даже будет найти какую-то информацию. Но игрок никогда не догадается, что на самом деле он умер вон там. И тогда было принято решение, что все. Симуляцию в узду, симуляцию нафиг, скрипты, скрипты, скрипты, и понятное каждому скриптование.
А теперь вопрос на миллион. А о каком именно билде говорит А.Прохоров, поиграв в который разработчики поняли, что это не играбельно, это невозможно пройти? После чего приняли решение, что все, симуляцию в узду, симуляцию нафиг, скрипты, скрипты, скрипты, и понятное каждому скриптование …
Для тестов 1865 билда я использую локацию свалка. Прямо на входе, чуть слева, в моей версии пасутся три собаки. Дальше справа за поворотом пасется плоть, а слева сталкер Жора (tradeseller_gora_0_011). И для них имеет смысл сделать некоторые приготовления. Во-первых, параметру satiety_v присвоить значение 1000 для всех ботов кроме сталкеров. Можно и им, но они прекрасно бродят по локации и без этого. А вот все остальные имеют одну особенность. Если бот не голоден, то он никуда не ходит. Но если голоден, то начинается движение. Собаки, сидевшие слева, идут вглубь локации. Плоть справа тоже начинает бродить. Впереди их ждет радиация.
Во-вторых, satiety_health_v = 0.000. Иначе боты будут умирать от голода и пропустят самое интересное. И да, в текущей версии Теней можно выставить это значение каким угодно, ботам будет на него наплевать. Делается это просто, в геймдате есть креатуры, в них сталкер.лтх, а там пачка нужных параметров. Можно там и со значениями satiety_v побаловаться, толку все равно никакого. «Проработан» этот вопрос не на рубеже 2004 года, а в период с августа по октябрь 2004 года. И «проработан» окончательно.
К слову, у Жоры по карманам лежит несколько пачек дроби и пара аптек. И дробь, и аптеки, всегда в единственном экземпляре, и даже будучи надкусанными в какой-то общий стек они не собираются. Потому что у каждой пачки или аптеки есть свой уникальный ID. Еще это значит, что патроны у бота могут кончиться. А еще это может привести к забавному багу, если количество патронов в пачке равно нулю, а вот функции снести эту пачку из памяти нет. Тогда появятся пачки патронов с нулевым количеством этих патронов. А еще боты могут подбирать игровые предметы, те могут лежать у них в рюкзаке, и если обыскать труп, то там будет честно лежать игровой предмет. Запомним эти факты.
В конфигурации у всех без исключения ботов есть такой интересный параметр
radiation_v = 0.001
Заявлен он как скорость уменьшения радиации. В конфигах нет величины, на которую уменьшается радиация, но можно предположить, что на единицу. А этот параметр определяет, с какой скоростью будет уменьшаться доза.
Нет в конфигах и самой дозы. Потому что здесь все индивидуально. Чем ближе бот к эпицентру радиации, тем большую дозу он схватит. Накопление радиации совершается порциями в единицу времени. Но нигде нет скорости накопления радиации. От чего можно предположить, что скорость уменьшения радиации и скорость накопления радиации — это одно и тоже. А порция привязана к геометрии. Соответственно, боты в любой точке локации получают порцию радиации. Но в некоторых местах порция равна нулю, а в некоторых (радиоактивные зоны) порция выставляется еще при компиляции, и убывает от максимальной величины в эпицентре до нуля в безопасных зонах.
radiation_health_v = 1000
Этот параметр — на какую величину уменьшится здоровье при облучении. Но и здесь все лукаво. Бот для радиации представляет собой своеобразный стакан, который может быть пуст, может быть наполнен до краев, а может там только на дне что-то плещется. Соответственно, есть (но не в конфигурации) текущее количество радиации, и максимальное, сколько в себя может впитать бот. Если текущее значение равно максимально возможному, то у бота отнимется столько, сколько заявлено в этом параметре. Если текущее значение меньше, то и здоровья отнимется меньше. Впрочем, это в Тенях и для персонажа. А вот в билде и для бота все может быть и иначе. И может быть, что у бота отнимается полное значение radiation_health_v, не зависимо от уровня накопившейся дозы. Правды мы уже никогда не узнаем. Поэтому я поставил сразу тысячу, чтобы уж наверняка (у ботов здоровья не более 100 единиц, так что им и десятой части от максимума хватит).
radiation_immunity = 1.0
Так как мы играем в РПГ, то какое же РПГ без резиста? Этот параметр — сопротивление радиации у бота. Единица означает полное отсутствие сопротивления, бот получает полную дозу без резиста. Ноль — это полный резист к радиации, в любой точке карты бот получает одинаковую дозу, равную нулю.
Пришло время залезть в сборку 1865, занять место на вышке, и ждать, когда Жора зайдет на кучу мусора (потому что там граф), или туда зайдет плоть, или собака прибежит по дороге до ямы. Везде в указанных местах зоны радиоактивности. Финал будет предсказуем — ваншот для ботов. Если хоть кому-то поставить стопроцентный резист (radiation_immunity = 0.0), то все будут ходить как ни в чем не бывало. Поэтому для впечатлений лучше оставить величину этого параметра как есть. Жору, кстати, в этом случае даже костюм не спасет, здоровья не хватит.
В билд 1935 мы уже не полезем, с ним и так все понятно. Не полезем мы и в оригинальные Тени, потому что они у меня на диске, надо устанавливать и вводить ключ. Мы полезем в ОЛР, которое сделано на версии Теней. Ну не можем же мы предположить, что те, кто восстанавливают тот самый сталкер, снесут из кода тот самый сталкер? Следовательно, уж в ОЛР все должно быть как надо. Поэтому ищем креатуры (геймдата — конфиг — креатура — любой.лтх), и всем шлепаем radiation_health_v = 1000, а radiation_immunity = 1.0. Затем заходим в игру на свалку, заманиваем все подряд в радиацию, и выясняем, что в радиации подохнет только наш персонаж. И можно хоть как менять параметры, хоть radiation_immunity = 0.0, хоть radiation_health_v = -1000, хоть вообще снести эти параметры, движок этого даже не заметит. Как он, собственно, не замечал их и до этого.
Вывод? В период с августа по октябрь 2004 года боты перестали умирать как мухи от радиации. Так же, как и перестали умирать от голодовок. В чем можно убедиться, убрав нулевые коэффициенты. Делается это там же (геймдата — конфиг — креатура — любой.лтх), satiety_health_v = -1000, satiety_v = 1000. Дальше запускам Тени. Но одно дело обнулить параметры (satiety_health_v = 0), после чего бот даже голодным ласты не склеит. Совсем другое, если удалить из движка объявленный оператор satiety_health_v = integer. И третье, если удалить некоторые функции и методы, где он был задействован. Это разные вещи.
-
Почему нельзя было поставить ботам стопроцентный резист? Эффект был бы тот же самый. Это очень интересный вопрос. Но сначала вернемся в сборку, где и плоть, и Жора постоянно идут на радиоактивную кучу мусора. Они довольно часто тупят, напоровшись на какое-то препятствие, и все равно идут вперед, вместо того, чтобы его обойти. Потому что в спокойном состоянии они ходят от одного графа к другому (А-life), и только в возбужденном начинают ходить по клеточкам (AI). Мы можем поставить граф прямо в эпицентр радиоактивного участка, и тогда рано или поздно туда кто-то зайдет. В развлекательных целях мы поставили radiation_health_v = 1000, что гарантированный ваншот. Но значение может быть и поменьше, тогда у Жоры/плоти просто отнимется немного здоровья. А еще у Жоры в кармане есть пара аптек, одну из которых он может зажевать для здоровья. Если добавить Жоре умение найти торгаша и купить у него антирад, то жизнь и вовсе наладится. Правда Жоре нужно добавить умение искать артефакты, потому что торгаши занимаются коммерцией, а не благотворительностью. Но с этим у Жоры в 1865 все в порядке.
И тогда становится понятно, почему патроны обязательно в пачках (а не из рюкзака и общего стека), аптеки, антирады и даже жратва не собираются в стеки, и так далее. Потому что каждый игровой предмет (даже пачка патрон) — это отдельный игровой предмет со своим ID. Последний нужен, чтобы отследить движение вещи от одного бота к другому. Но не только. Еще это нужно, чтобы скатать функцию, возвращающую всего два значения (истинно или ложно) — а есть у меня в рюкзаке предмет такого класса? И если она вернет истинно, тогда надо активировать функцию «использовать», внутри которой будет обращение к уникальному ID (использовать именно этот предмет), а так же функция «выгрузить из памяти» по этому уникальному ID и именно с этим уникальным ID как использованный. Все, пачки патронов есть самые разные, но вот той самой надкусанной больше нет, мы ее в автомат зарядили.
Граф можно поставить и не в эпицентр, а куда-нибудь рядом. Можно очаг радиации поставить между графами, все равно же бот будет идти от одного к другому, а значит пройдет через очаг без возможности свернуть. Или с возможностью, когда движение на один граф сменится движением на другой, потому что здесь что-то со здоровьем не так. Варианты могут быть разные.
Но где-то в конце 2003 / начале 2004 года (зима-весна) у нас вылезла проблема. Мы запилили патрулирование территории, сделали скриптовые сцены, анимацию, хорошо поработали. Но движок начал крошиться. Потому что непонятно, кто управляет ботом, скрипт или симуляция (a-life). Скрипт предписывает боту патрулировать территорию и играть соответствующую анимацию, а симуляция предписывает идти за аптекой с соответствующей анимацией, потому что бот во время патрулирования в очаг радиации наступил. А еще бот может умирать от голода, а мы его на патруль поставили. В общем, мы соберем 1865, ужаснемся, и примем решение — симуляцию лесом.
-
Еще раз, можно поставить стопроцентный резист к радиации. Можно и по жратве придумать, что голодные, но не умирают. Дело не в этом. При каждой ситуации симуляция будет предписывать какие-то действия, которые будут противоречить действиям, предписываемым скриптом. А значит игра будет крошиться постоянно. Да, можно попытаться отделаться малой кровью, пусть у нас будут боты, которые под симуляцией, а другие боты под скриптом. Но потом те, кто под симуляцией, придут к тем, кто под скриптом. И тех, кто под симуляцией, все равно придется сажать на скрипт. Это будет потом, а в августе/октябре 2004 пока просто снесли сердцевину симуляции — голод (радиация за компанию улетела).
И тот самый сталкер начал облазить. Зачем нужны радиоактивные зоны, если в них бот не облучается? А мы не можем позволить ему облучиться, потому что иначе он попрется за аптекой, кто патрулировать будет? А если не попрется, то умрет от радиации, а ему еще патрулировать (ну или в смарте сидеть возле костра). Нафиг …
Если бот не облучается, за аптекой не ходит, зачем тогда нужны внутриигровые предметы со своими уникальными ID? Их кроме игрока все равно никто не использует. Пусть тогда все аптеки в стеке лежат, раз у них больше уникального ID нет. Перепишем движок, не первый раз. А зачем нужны пачки патрон? Пусть тоже в стеке лежат, бот их все равно больше не покупает. И вообще, мы ему сделаем бесконечный запас патрон, потому что к торговцу он больше не ходит, да и покупать разучился. А пояс зачем, если пачек патрон больше нет? Что туда вешать, если все патроны в рюкзаке в одном стеке? Пусть из рюкзака перезарядка будет. И прямо из общего стека (для бота бесконечного), не надо больше пачек. А если что, то в 2008 xStream еще раз научит их аптечки использовать, но уже скриптом, и мы назовем это новым словом.
В чем был замысел? Боты ходят по картам, что-то собирают, у этого чего-то есть свои уникальные ID. Не обязательно покупать у торговцев или других сталкеров, можно найти, снять с трупа, но любые действия с предметом осуществлялись по однотипному сценарию как смена владельца вещи, имеющей уникальный ID. И если бот где-то нашел пачку патрон с 23 патронами в пачке, и вы его встретили на другом уровне, завалили и обыскали, то в его рюкзаке вы найдете именно эту пачку, в которой именно 23 патрона. Или отнес и продал ее торговцу, а вы позже пришли и купили именно ее (надкусанная дешевле). Такой подход требует отдельно подумать, как предметы будут выгружаться из памяти, потому что в норме они не должны выгружаться никогда, но аптеку можно использовать, патроны в пачке могут закончиться, ну и так далее. В норме в рюкзаке сталкера будет только то, с чем он заспаунился (и что еще не успел использовать, в 1865 боты могут отстрелять патроны, и в рюкзаке не будет ничего), и что он успел насобирать/намародерить/накупить.
Это не значит, что в Тенях от того самого сталкера не останется вообще ничего. Что-то останется, и если вы сбросите ствол, а бот его подберет, и вы бота за это завалите, то в рюкзаке будет ваш ствол. Но еще бот заспаунится с каким-то количеством предметов, которые уже не имеют ID. Эти предметы еще будут в окне торговли, благо они ботом не используются. Но если завалить бота, то в его рюкзаке окажутся совсем другие рандомные вещи из death_items_by_communities, а не рюкзака как такового. Потому что зачем боту вещи с уникальным ID, если он их не собирает, не покупает и не использует? Как он будет собирать, покупать и использовать, если он в смарте на скрипте сидит? И зачем ему собирать, покупать и использовать, если он не облучается, не голодает и не теряет здоровье со временем? Так что можете смело стрелять боту в голову, и если death_items_by_communities выплюнет антирад для вас, то забирайте. Боту он уже не нужен …
Для начала залезем в конфиги 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 (мы хотим целочисленные).
Отдельно задается проверка …
Если текущее_значение_сытости < минимальное_значение_сытости, то …
Дальше для бота начинается обратный отсчет, потому что значение сытности преодолело порог. Значит теперь у него уменьшается здоровье …
И только после этого идет конфигурация. Где в каком-нибудь .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 билде, это средство без цели. Смысла для ботов в этом уже нет.
На дорогах лежит апрельский гололед, Григорович постит запись в Фейсбуке.
«Друзья! Мы знаем, с каким нетерпением вы ждали релиза S.T.A.L.K.E.R 2. Но, когда случился анонс второй части, мы были молоды, и у нас было много свободного времени. Однако жизнь расставляет свои акценты, прошли годы, сейчас у нас появилась работа, семьи, дети. И у нас уже нет столько времени, чтобы продолжать разработку так, как это делали раньше. А потому решили выложить билды, наработки и исходники в свободный доступ. Быть может доделает кто-то из разработчиков, или хотя бы возьмет что-то в свои игры. Всем спасибо, что все это время были с нами, верили в нас, ссылка в описании.»
