>>60008

>Это потом будут объяснять

https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html

Кратко:
1. Изначально GDScript создавался как язык с динамической системой типов. То есть по умолчанию любая переменная может хранить любые данные, функции могут принимать любые данные и возвращать любые данные без каких-либо ограничений. У этого есть плюсы и минусы. Плюсы:
- проще научиться программировать, ибо не нужно держать в голове концепцию "тип данных";
- дети и инвалиды быстрее пишут код, нажимая меньше клавиш (которые они ищут глазами);
- быстрее вносятся правки в прототип, ибо для изменения поведения меняешь меньше кода.
Минусы:
- компьютер вынужден выделять больше памяти и выполнять проверки типа данных каждый раз, когда работает с этими универсальными переменными;
- код сложнее читать, потому что без типа не всегда понятно, что функция ожидает или отдаёт, и т.п.;
- баги могут скрываться в коде годами, пока не сойдутся звёзды на небе и весь проект обвалится;
- компьютер не может заранее проанализировать написанный человеком код и выявить банальнейшие ошибки вроде сложения строки с числом, а также не может дать контекстные подсказки, которые зачастую значительно ускоряют набор кода;
- взрослые программисты считают пользователя такого языка... ну, ты сам понимаешь.

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

3. GDScript предоставляет следующие возможности:
- явное указание типа:
var number: int = 0
var text: String = ""
var array: Array = []
var node: Node = Node.new()
- выведение типа из данных:
var number := 0
var text := ""
var array := []
var node := Node.new()
- указание типа возврата функций:
func nothing() -> void: pass
func return_hello() -> String: return "hello"
func sum(a: int, b: int) -> int: return a + b
- типизированные массивы Pool_ТипArray.
В Godot 4.0 будет больше возможностей.

>>60054

>:= и ->void особо не нужны.

Ловите говнокодера, пока он не наложил кучу кода!

>>60286
Забыл дописать, что я пока даже не знаю, буду ли я текстурировать ландшафт несколькими разными текстурами (земля, трава, песок, камни и т.п.), или я остановлюсь на "плоскозаливочном" стиле графики, в котором вместо текстур ландшафт можно красить цветами вершин. Мне не очень нравится плоская заливка всего и вся, но вместе с тем не нравятся артефакты от перекрывающих друг друга текстур в других играх с похожим ландшафтом. Кроме того, качественные текстуры рисовать сложно, а если я сделаю текстуры для ландшафта, то мне потребуется рисовать текстуры в том же стиле вообще для всего в игре. Если же выбрать плоскозаливочный стиль, можно будет обойтись более простыми текстурами в отдельных случаях, когда без них полигонов слишком много (вроде пуговиц на одежде и т.п., где нужна высокая детализация мелких объектов).

>>60299

>разве вообще такое обсуждали где-то?

Один из популярных аргументов против Godot: "если нет встроенного компонента ландшафта с дорогами, то движок бесполезен для ААА игорей".

>>60290

>сферический конь в вакууме

Не в этом проблема. Основная проблема: в отличие от основного движка, модуль непопулярен, и в случае, если автор его окончательно забросит, мне придётся самому копаться в его коде, искать альтернативу или делать всё самостоятельно с нуля. Если бы он официально поддерживался, такой проблемы бы не было, но есть и другие проблемы, например, как у GridMap.

>>60296

>там все упаковано по каналам цвета

Рассматривал этот вариант, но меня напрягает то, что больше 4 текстур таким образом не упаковать, а если необходимо больше, то придётся их каким-то образом сортировать и разбирать потом в шейдере. Или делать две текстуры на канал, опять же максимум 8 текстур.

>карта высот рисуется пикселями

Вот это я тоже много где видел, но не понимаю. Зачем передавать карту высот в шейдер через текстуру, если тебе в любом случае необходимо на процессоре построить меш с вершинами в определённых высотах и затем по этому мешу сгенерировать коллижн шейп для физического движка? Я знаю, что в теории существует более оптимальный алгоритм коллизий с картой высот, но для его реализации нужно погружаться во внутренности физического движка. Поэтому в нашем случае единственный вариант - сделать тримеш на основе карты высот. Зачем тогда рисовать карту высот и передавать её в шейдер, если шейдер получает уже готовый меш, и ему достаточно наложить на этот меш какую-нибудь текстуру, или просто залить его одним цветом? Тут даже стандартный шейдер справится. А меш менять на процессоре после генерации всех LODов больше не нужно, соответственно экономим время ЦПУ и ГПУ, да ещё и память.

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

>>60322
Попробуй так:

public override void _Ready()
{
ProjectileTypes = new Dictionary<int, Projectile>()
{
{1, (Fireball)FireballScene},
{2, (Iceball)IceballScene}
};
CurrentProjectileId = 1;
Shoot();
}

public void Shoot()
{
Projectile projectileInstance = ProjectileTypes[CurrentProjectileId].Instantiate();
projectileInstance.DoSomething();
}

Либо так, в зависимости от твоей задачи:

public override void _Ready()
{
ProjectileTypes = new Dictionary<int, Projectile>()
{
{1, (Fireball)FireballScene.Instantiate()},
{2, (Iceball)IceballScene.Instantiate()}
};
CurrentProjectileId = 1;
Shoot();
}

public void Shoot()
{
Projectile projectileInstance = ProjectileTypes[CurrentProjectileId].Duplicate();
projectileInstance.DoSomething();
}

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

>>61547

>2д изометричной игры в духе лутер-шутера

Как ты себе представляешь шутер в изометрии? Пошаговый, как диды играли во времена Fallout?

>происходит ВН составляющая

Изометрия ещё ладно, а ВН рисовать потянешь?

>могу в 3д модельки

Ясно, значит, прям как в Fallout и ему подобных.

>динамически генерящиеся локации

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

>не хочу дрочиться с их оптимизацией для игры

Делаешь лоуполи @ запекаешь нормали. Сложно?

Лично я сомневаюсь, какая графика сегодня более тяжёлая для ПК: 2D или 3D. Во времена первых игровых консолей существовали специальные хардварные приспособления для ускорения рендера спрайтов и тайловой графики. Сегодня видеокарты оптимизированы исключительно для 3D графики, 2D ты рисуешь в виде текстур на трёхмерных треугольниках. В зависимости от детализированности твоей графики и ракурса камеры может оказаться, что лоупольки анимированные по экрану гонять дешевле, чем заранее отрендеренные гигантские спрайтшиты на прямоугольниках из двух треугольников. Вроде бы видеокарте сегодня проще переварить десятки миллионов треугольников, чем затекстурить несколько сотен квадратов с прозрачными пикселями. Отсюда, наверное, возникает неожиданная прожорливость некоторых полностью двумерных игр, в которых используется много двумерных спецэффектов.

Но в контексте Godot нужно понимать, что актуальную оптимизацию 3D (для сравнительно больших проектов) подвезли только в версии 4.0, которая уже вот-вот релизнется, но всё ещё нет.

>с чего, собственно, лучше начать?

https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
И дальше все статьи из "GETTING STARTED".
После этого - статьи из "TUTORIALS".
Наконец, тебе часто понадобится "Godot API", но его удобнее читать прямо в движке (F1, кнопка в инспекторе или ctrl+клик в коде на название класса), чем на сайте... сам поймёшь, почему. Ты же уже скачал движок?

>есть ли какие-то гайды

>с учётом того, что я хочу сделать?

По Godot вообще не так много туториалов, а на твой конкретный запрос я ничего не видел. Ну, есть пара фреймворков для визуальных новелл. Есть пара фреймворков для RPG игр. Но если ты умелый программист, сделаешь всё под себя без каких-либо фреймворков, т.к. движок очень дружелюбный и всё необходимое тебе уже есть из коробки. Для изометрии смотри официальную документацию на TileMap, там легко переключиться с прямоугольной сетки на сетку для изометрических тайлов. Ну, тыжпрограммист, так что иди RTFM, а гайды "как сделоть игру жанра X" предназначены для детей и яждизайнеров, а по факту нужны для заработка того, кто эти туториалы записал.

>>61597

>изометрия

>сверху-сбоку

Это разные проекции. Изометрия - это, например, как в Project Zomboid. Собственно, какие ещё есть шутеры с изометрической проекцией? Я чаще топ-даун шутеры встречал, они проще и понятнее. В изометрии же обычно пошаговые, тактические, РПГ и т.п. Зомбоид в данном случае - исключение.

>3д картинки как-нить вытяну

Завидую. Тяжело было учиться?

>пули летят не в том направлении, если персонаж двигается.

Есть локальная система координат и глобальная. Глобальная не вращается и не смещается. Локальная движется и вращается вместе с нодой. У нод есть специальные методы для преобразования координат из локальной системы в глобальную. Также каждая нода автоматически двигает и вращает все свои дочерние ноды, это следствие того, что дочерние ноды размещаются в локальной системе координат ноды; есть метод для отключения этого наследования. В общем, тебе нужно размещать и направлять пули в глобальной системе координат, а ты их, видимо, либо к игроку крепишь, либо в системе игрока вычисляешь вектор направления. Читай API Node2D, там всё из названий методов понятно (сравни описания global_... и local_...).

>Да и не хочу я просто ещё и в годоте с 3д возиться.

Не так уж и сложно. Ну, не важно, просто знай, что при желании ты можешь рендерить 3D поверх 2D и наоборот, генерировать текстуры в реальном времени и так далее. У Godot отдельное API для 2D, но это не мешает смешивать графику в разных вариантах. Если вдруг захочешь, например, трёхмерную карту многоуровнего подземелья, что лучше всего будет выглядеть как 3D голограмма. Так что при планировании фич учитывай, что не ограничен 2D.

>ковырять этот туториал пока:

Ну вот там топ-даун, а не изометрия...

>Пока я даже структуру того, как оно всё работает и взаимодействует слабо понимаю.

Движок каждый кадр обходит все ноды в дереве, вызывая обработчики событий (здесь они называются "сигналами"), и в этих обработчиках работает твой код. Твой код меняет свойства нод или внутренних систем движка (здесь они называются "серверы"), и движок идёт по дереву дальше. Цикл повторяется, пока программа не завершится по требованию пользователя, твоей команде из кода или из-за критической ошибки. По умолчанию движок работает в один поток, поэтому его поведение предсказуемо и можно поверхностно изучить, натыкав print().

>>62139

>>x или y?

>Да. # OP

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

>>62127

>Нужно ли ждать релиза 4 версии?

Ждать осталось немного, движок в стадии Release Candidate, что означает скорый выход в релиз. Ждать осталось максимум несколько недель.

Нужно ли? Вопрос сложный. Ты можешь уже сейчас пробовать что-то сделать на RC версии, она будет достаточно стабильна. Но большинство туториалов, примеров и т.д. пока что только для 3.x ветки, и даже официальная документация не полностью обновлена, так что о некоторых фичах можно узнать только из кода движка или обсуждения пулл реквестов на гитхабе. Однако, если ты начнёшь сейчас изучать 3.x, то в скором времени тебе придётся переходить на 4.0, запоминая отличия в API и GUI редактора. Так что если ты абсолютный новичок, никуда не торопишься и тебе есть чем заняться (рисовать спрайты или делать модели к будущим играм), я бы подождал выхода 4.0 с обновлением документации и туториалов, но если тебе очень хочется нырнуть в геймдев прямо сейчас, то можешь начать с 3.x, а потом когда-нибудь перейти на 4.x. Всё равно для первых нубских игр нововведения 4.0 тебя почти никак не касаются, там больше по 3D всё меняли.

>нужно только хай левел скил пацанам?

Версия 4.0 полностью заменяет ветку 3.x, новые фичи будут выходить только в ветке 4.x, а ветка 3.x будет получать только багфиксы. Поэтому рано или поздно все разработчики перекатятся на 4.x, как раньше перекатились с двойки на тройку. Сделано это так, потому что на ветке 3.x за эти годы выпущено много игр, которые всё ещё нужно поддерживать, но переводить на 4.0 будет слишком сложно, нерационально или недопустимо (как минимум брошена поддержка GLES2). Новые фичи этим играм не нужны, а вот багфиксы пригодятся. Поэтому новые игры будут делать только на 4.x, а игры в процессе разработки переводить с тройки на четвёрку, даже если основные нововведения четвёрки конкретной игры не касаются. Т.е. переход на новую версию растянут исключительно из необходимости поддерживать уже выпущенные игры. Godot заботится об играх, в отличие от глюкнити.

А ты что хочешь делать? 2D? 3D? Какой жанр?

>>62189

>годот, мне кажется, дружелюбной штукой на которой можно попробовать всё.

Всё так.

>>62358

>кинематик боди для пуль

Зачем? Тебе нужно, чтобы пули скользили вдоль стен? Нет? Тогда используй Area, зачем тебе кинематики?

>Заморачиваться с пулом реально стоит если

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

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

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

>>62359

>мешинстанц2д

>ничего почти в доке

Лол, а что тебе нужно-то?

>использованию серверов

Берёшь и используешь.
https://docs.godotengine.org/en/stable/tutorials/performance/using_servers.html

Если кратко, то ноды - это всего лишь удобные интерфейсы к серверам, позволяющие описать сцену декларативно в tscn файле. Ты можешь обращаться к серверам из кода без использования нод, облегчая дерево сцены. Все методы интуитивно понятны, главное хранить где-то RIDы, которые ты получаешь от сервера, ибо потеряешь RID - потеряешь доступ к объекту на сервере (что в общем и целом ведёт к утечкам памяти). Общая схема работы такова:
- запрашиваешь создание объекта;
- получаешь и сохраняешь RID;
- вносишь изменения по RID;
- радуешься/отдыхаешь.
Всё остальное сервер делает сам.

>>62367

>Прошло 6 недель и я понял

Ты мазохист или тебе просто не нужно было? Если бы мне нужно было, но не получалось, я бы намного раньше бросил и пошёл бы писать велосипед.

1. Набросал справочную систему. Грузит все страницы из одного JSON файла, они могут иметь иерархию любой вложенности. Пока что только в меню паузы и рядом с настройками из главного меню, но хочу ещё сделать контекстную справку, т.е. открывающую определённую страницу с разных кнопок в игре. На текст не обращайте внимания, писал чисто для теста. Зелёный заголовок получается, если пользователь нажал кнопку внизу страницы, эту метку можно снять. Я сначала хотел галочку слева от заголовка ставить, но дизайн Tree какой-то странный и контроля мало, я так и не смог добиться приятного расположения галочки и решил просто цветом отмечать, что даже лучше выглядит (заметнее).

2. Кнопки выбора редактора. Это одна сцена, связанная несколько раз со сценой меню с заменой надписей. Нет, это не TextureButton, т.к. он имеет неудобные ограничения, поэтому я сделал это кнопки на базе обычного Button и TextureRect. Планирую вставить туда гифки с короткой демонстрацией каждого редактора, которые будут запускаться при наведении курсора. Если кому-то интересно, могу подробнее описать, как сделать такую же кнопку, чтобы она приятно работала. Правда, теперь меня напрягает слишком сильная разница между разными меню, т.к. делать всё плиточным я не хочу, а простые кнопки для редакторов не будут достаточно наглядными.

3. Набросок редактора зданий, или, скорее, шаблонов для генерации зданий. Я подумываю над тем, чтобы сделать упрощённую версию Townscaper, только помимо внешней оболочки будет генерироваться интерьер, соответствующий выбранному типу комнаты. Базовая идея в том, чтобы указать планировку первого этажа, остальные этажи с минимальными отличиями повторяют первый. Можно расширить до редактирования каждого отдельного этажа индивидуально, но зачем?.. Суть планировки: вместо расстановки отдельных стен/кубов, пользователь отмечает предназначение клетки - спальня, кухня, прихожая, санузел, лестница и так далее - а игра самостоятельно расставляет все необходимые стены и декорации с опорой на мета-параметры здания, если они указаны. Это максимально избавляет от рутины, оставляя возможность сделать что-то оригинальное без написания тонны кода. Процедурная генерация в любом случае следует шаблонам, только в данном случае шаблон визуально настраивается, а не хардкодится в скриптах игры.

_{4. П Р О К Р А С Т И Н А Ц И Я}

>>63098

>Какой алгоритм генерации меша используется?

Алгоритм "метод проб и ошибок":
1. Делаешь меш ручками.
2. Оцениваешь: нравится?
3. Если нет, возврат к 1.
4. Конец алгоритма.
Я же вручную делаю меш, чтобы потом блендшейпами его подгонять из кода/GUI игры. Насколько я знаю, абсолютное большинство игр с кастомизацией персонажей используют блендшейпы на одной базовой модели. Обычно не дают вносить слишком сильные изменения, вроде сделать пузатого жирдяя или тощую спичку, но сделано это исключительно в целях игрового баланса, особенно в случае онлайн-игр с нон-таргет системой боя, как в шутерах, либо чтобы в анимациях не было провала рук в тело. В моём случае баланс не важен и анимации всё равно будут грубее, так что могу использовать этот способ на 200%.

Если ты предлагаешь генерировать меш прямо в игре из полигонов, то это крайне сложная задача, особенно с учётом одежды, если я хочу добиться чего-то более-менее привлекательного. Поэтому с самого начала рассматривал только классическое моделирование и затем изменение модели через блендшейпы, замену текстур и т.д. Мне кажется, люди недооценивают блендшейпы, т.к. они могут менять модель до неузнаваемости, и единственное ограничение - это чтоб анимации скелета не перекосило. Конечно, таким способом не сделать дополнительные конечности, но я же не Spore делаю (вот там реально базовый меш и скелет прямо в игре генерируется, заранее заготовленные меши - только отдельные части тела вроде глаз и ртов).

>посмотри на Lego Worlds. Как тебе стилистика?

Ты про ландшафт или про персонажей?

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

Сегодня немного поменял физику машины. Пытаюсь добиться чего-то вроде GTA IV в плане подвески на поворотах с примесью чего-то вроде GTA V в плане существенных заносов с потерей управления. Почему-то не получается сделать подвеску ещё мягче - она с какого-то значения начинает проваливаться под землю. Выяснил, что можно сделать занос, но управление какое-то не такое, совсем не похоже на GTA. Да, я по-прежнему использую стандартный VehicleBody, но движок RAGE 1/2 использует внутри Bullet Physics, так что по идее должно быть возможно смоделировать их управление. Или всё же не избежать написания своей физики с нуля?

Накидал простое преследование ИИ игрока на машине и имел большое удовольствие с ним играть. Код в скрипте наипростейший, самое сложное в нём - это использование .dot(), остальное тупо if-else. Но движения машины в результате поразительно реалистичные, как будто другой игрок в мультиплеере управляет.

Собственно, есть пара мыслей про ИИ. Из чего состоит мозг? Из нейронов. Что делает нейрон? Реагирует на раздражитель синапсов (if...) генерацией сигнала на аксоне (then...). Т.е. нейрон в самом абстрактном виде - это конструкция if-then, даже не if-then-else. Разница в том, что нейроны рождаются из хаоса, умирают и рождаются вновь, а в процессе жизни меняют своё условное выражение даже несколько раз в день за счёт гормонов, влияющих на состояние синаптических связей. Искусственные нейронные сети симулируют эти изменения модификацией весов связей, но единственный ли это способ, а главное, нужно ли делать именно так? Если нейрон не делает ничего особенного, кроме if-then, то и моделировать его можно через if-then. Разве что у биологического нейрона есть эффект краткосрочной памяти, т.е. они срабатывают с определённой частотой, а не по первому требованию.

Короче, я к чему всё это. Обычно, if-then мы пишем в коде и этот код никак не меняется. Но что такое if-then? Это условие и действие. Если вынести условие и действие за пределы статичного кода, можно подменять все if-then по желанию, увеличивать их число или уменьшать, соединять друг с другом в каскады и т.д., при этом основной код останется без изменений. И если мы можем менять if-then произвольно, то мы также можем генерировать их на ходу, оценивать их ценность и удалять наименее ценное. Т.е. по сути получаем мозг, состоящий из одних только if-then, но способный учиться опытным путём.

Самый главный секрет в том, как организовать россыпь if-then в цельную систему, которая не будет метаться от одного к другому, не будет пытаться пойти налево и направо одновременно? Ответ удивительно прост, нужно менять состояние системы установкой флагов и проверять наличие этих флагов в условных выражениях, а выбор одного действия из множества несовместимых может быть произведён как сортировка всех возможных действий по уровню срабатывания группы условий, равной сумме весов каждого условия группы. В результате получаем цепочки состояний системы и связанные с ними решения, меняющие состояние системы.

Да, разумеется, этот подход не производит планы, как делает GOAP, т.е. этот "мозг" всегда реагирует только на одно конкретное состояние и по умолчанию не думает о будущем (но, теоретически, может). И в отличие от нейросетей этот мозг не решает задачу за один проход, а непрерывно думает прямо в процессе своей жизнедеятельности, что идеально подходит к симулятору жизни, который я хочу сделать - мне не нужны идеальные решатели проблем, мне нужны живые организмы, пытающиеся выжить в заданной среде. Я всё же не игру делаю, так что "проигрыша" как такового в ней нет.

Подозреваю, что вручную настраивать эту систему сложно, но тут мы вспоминаем, что if-then в этой системе не захардкожены и могут произвольно меняться. Т.е. в теории можно накидать базовых условий и затем запустить симуляцию, в результате которой условия будут меняться, дополняться и удаляться, пока не получится наиболее эффективное поведение. Вопрос в том, сколько времени займёт такая симуляция, будет ли она эффективна? Понятия не имею, но даже если это жутко неэффективно, возможность точного контроля и расшифровки такого мозга даёт преимущество перед "обычными" нейросетями, где тысячи параметров по отдельности не означают ровным счётом ничего, тогда как у моей модели условия и действия всегда конкретны... хотя, если представить себе процедурную генерацию условий, что получится в итоге? Тысячи флагов с числовыми ID, которые приводят систему к решению какой-то задачи, но при этом дать им какие-то осмысленные имена сложно. В общем, не знаю, но попробовать сделать такое нужно, т.к. хардкодить поведение вообще никакого желания нет. Главное, что мой метод подразумевает крайне высокую модульность и полную взаимозаменяемость любых модулей, т.е. легко можно заняться процедурной алхимией поведения.