Naira AI framework: 2 шага до мечты

Сценаристы и фикописатели - приготовиться! В то время, как ChatGPT предлагает заливать данные Гуглу, а другие нейросетки требуют непомерные объёмы памяти... я потихоньку тяну своё решение для сценаристов - Найру. И да, я смог сделать перенос НПЦ как в САО, бойтесь устанавливать 2 игры на моём движке рядом: в гости ходить будут.

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

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

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

Но, как и любая нейросетка, такая жесть требует ручного заполнения. Как же я был удивлён написанием Хомякогатари для 6-го прототипа! И ведь это - просто линейный сценарий, почти что без фильтраций.

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

Она пишется на питоне, половина багов закрыта костылями едва ли не с эффективностью O^N! (да, это факториал), так что пока я не переберу код - либо будут лаги, либо ИИ будет тупить, натурально размышляя над ситуацией.

Так что на сегодня я бы не расчитывал увидеть Найру в модах на чём-то требующем хотя бы 20FPS.

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

Архитектура Найры - это прежде всего попытка воссоздать сон. Со всеми бредовыми штуками. А после, с небольшими страданиями, к этому добавилась попытка сымитировать иррациональные страхи. За последнее спасибо медитациям на рыбачьем камне в "Degrees of Lewdity" - именно там я понял, что стресс за размер груди не сильно отличается от стресса за хорошие оценки по математике.

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

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

От него наследуются 2 главных класса: Exemplar и Manager, получая все возможности и силы класса-родителя.

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

А вот Exemplar это уже другая песня. Под каждую задачу она заточены уже по-своему. Все наследующие от него возможности - с зелёным ромбиком.

Кстати, обратите внимание на root, который может использоваться как классом Scape, так и классом Chara (Subject). Ну то есть - вы можете поместить Черепаху в Космос, а игру кинуть в её сон, а можете создать всеведающего Бога, который будет в Нигде. Хотя он и отмечен жёлто-зелёным на схеме - это только для того, чтобы указать, что оно не для менеджеров.

В рамках текущего прототипа я ставил себе задачу написать процедуры для сохранения-загрузки так, чтобы можно было, при желании, выгружать ненужное, забывать ненужное, вплоть до того, что было сделано в SAO - вытащить НПЦ и утащить в другое место. Да, это возможно, вопрос только в том, буду ли я делать standalone решение.

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

А теперь к будущему: как я буду уже завтра пилить Хомякогатари, снова.

Во-первых, Равки. Это офигенная тема, чтобы не гонять кучу данных туда-сюда. Если говорить в терминах Юнити - это "префабы". Мне их ещё надо омучить, чтобы они обеспечивали большую оптимизацию потребления ОЗУ, это будет крайне важно при появлении большого количества персонажей. Потому что я это буду тестировать на нетбуке с 1Гб ОЗУ и жёстким диском, так что влажные мечты про 3090/4090 - это не про меня. А вот привить ИИ леность мышления и категоричность - это уже да.

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

В-третьих, возможность что-то выгрузить из игры. Да, можно вытащить и разобрать "по строкам", можно посмотреть о чём думает конкретный НПЦ в конкретный момент времени. Очень удобно и эффективно, если надо что-то пристально рассмотреть.

В-четвёртых, возможность что-то загрузить в игру. То есть - как в SAO - можно вытащить НПЦ из игры и притащить в другую. Выдал фентезийный король квест "покажи мне что-то, чего нет в этом мире"? Всё, пусть теперь не жалуется, убегая от Инквизиции с мельтой в руках под Оком Ужаса. Потом, конечно, можно его задобрить гаремником или ещё чем-нибудь типа "House party", но прыжки между играми не только для игроков - это прикольно.

Казалось бы, это немного... но мне запала в душу идея, что НПЦ можно вытащить из игры. Зачем? Да потому что можем!

Эта часть уже проверена и работает в 6-м прототипе, потому я могу говорить о ней с достаточной уверенностью.

Во-первых, это класс Scape. Я хочу переделать его в этом прототипе так, чтобы он содержал свойства, позволяющие взаимодействовать разным персонажам. То есть: это может быть симулятор Варпа, где даже время будет относительным, можно воспрозвести пространство дробной мерности, неевклидово пространство, ассоциативное пространство... то есть это максимально универсальный класс, где можно ориентироваться по осям X, Y, Z и "котики". Ну или "Внутренняя Империя", "Рептильный мозг", "Интуиция", "Диско"... ну да вы уже узнали, да.

Насколько это сложно написать? Немного геморройнее, чем обычно. Но вот чтобы это работало с хоть немного адекватным быстродействием... Как бы не оказалось, что с таким подходом более 300 персонажей одновременно обрабатывать не получится.

Во-вторых, это Chara/Subject - этот класс посвящён выбору действий и сопоставлению историй.

Этот класс включает в себя интерфейсы, собственный Scape (опционально), истории (которые меняют его состояние), а так же запечёные показатели.

Для взаимодействия между персонажем и миром создан класс Interface, который содержит данные для того, чтобы представить персонажа в мире, а мир - в персонаже.

Класс Story/Script - история, содержащая мемы и действия (развития сюжета). Строго говоря - это скорее отдельная сцена в истории. Она содержит свой вес по эмоциям, что позволяет не вчитываться в содержащиеся мемы, чтобы проверить её актуальность.

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

Класс Meme/Entry - это "кирпичик" истории. Он определяет какие есть возможности и выходы, содержит свой вес в эмоциях. Может не появиться, если условия для его поведения не соблюдены. Даже наличие котика может быть чем-то важным.

Класс Act - это уже нейросетка на минималках! Возможно, в Хомякогатари он не попадёт, но я очень хочу его ввести. Возможность выбрать между несколькими подходящими историями, чтобы собрать наиболее привлекательную - пусть это не то же самое, что рисовать без цензуры, но всё же - это возможность строить коварные планы... и даже нанимать игрока для своих, идущих параллельным курсом, планов. Например, подвезти игрока за денюжку, чтобы бенз отбить (при этом НПЦ не искал конкретно игрока - у него была проблема с деньгами на бензин, а игрок просто подвернулся).

Отдельно стоит упомянуть структуру статов для мира. Тем более, что это весма неплохая и комплексная тварюшка, кажную роль в формировании которой сыграли медитации, НПЦ на уроке математики и женская грудь. Меня до сих пор прикалывает это сочетание, просто "ну вот как!?".

Об отказе от KASEOSA, SAVIDL, SPECIAL и иных "комплексах" можно сказать следующее: это - истории. Отдельные, полноценные истории, наборы данных, либо даже что-то вроде персонажей, субличностей. Их можно реализовать, я так 7 и 8 прототипы угробил, но это - геморройно. Так что - я попробовал, "в лоб" у меня не получилось сделать нормально, так что "мы пойдём другим путём", но позже.

Комплексная статка TPW. Рассмотрю пока что только её, как образец. Она состоит из двух частей: собственно навык (теория/Theory, практика/Practice, мудрость/Wisdom) и иррациональная часть, регулирующая комфорт при использовании и созерцании навыка. То есть - НПЦ с такой статкой будет восхищён вашей демонстрацией навыка, если сможет понять что он видит перед собой. Причём в сценарии ничего, кроме весов, прописывать не надо - это работает автоматически.

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

Для начала, нужно завершить текущий прототип. Для этого нужно перевести Хомякогатари на новое двигло.

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

С другой стороны - нужно удобное приложение для авторов. Оно должно включать в себя:

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

- Демонстрационная среда (опционально) - локальный терминал для того, чтобы можно было погонять получившееся перед передачей в разработку. Как минимум - можно будет софтлоки отловить. С другой стороны - не вижу особого смысла, если есть консоль и возможность прописать мем/энтри для срочного каскадного сохранения.

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

- Графическая визуализация связанности. Это будет больно делать, ещё больнее сохранять, но это будет тотальным упрощением жизни. Типа как в Miro, Twine.

Ну и завершая цикл разработки, нужно с одной стороны - отловить основные баги и улучшить быстродействие. А с другой стороны... А с другой стороны кому нафиг нужен движок на питоне? Нужно портировать на C#, C++ и Forth. Либо только на Forth и придумывать как запустить фортовые проги под Unity3D и UnrealEngine, а заодно - попробовать многоядерность на 144-ядерном процессоре.

В общем, на Найру - планов громадьё! Как минимум - уже скопились материалы по "пещеркам и ящеркам", их надо бы реализовать.

Сложно говорить сейчас насколько эта зверушка будет эффективна как нейросеть. Я бы скорее её рассматривал сейчас как экономичное и комплексное решение для написания и проверки сценариев. Которое допускает некоторое своеволие НПЦ.

Но сложность будет с тем, чтобы дать НПЦ возможность обучаться: во-первых, передавать истории друг другу, во-вторых - создавать истории "на лету". Как минимум - это риск вариативного взрыва и забивания харда мыслями какой-нибудь кошки. Надо лучше.

В общем - есть что делать, есть над чем работать.

Если вы хотите помочь мне плотнее заниматься проектом - принимаю помощь на борьбу с болящими зубками. Сильно отвлекают.

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