Мои блоки или Наши блоки ☭?) | День 24

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

Ну а пока всё пойду доделывать практические по оценке параметров функционирования программных систем, да и вообще, говорят сессия близко 🫠

Концепт редактора интерфейсов? 🫣 | День 25

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

И один из таких - система интерфейсов ✏️
Если коротко, то посмотрев на NoesisGUI, появилась идея сделать свой редаткор интерфесов: задумка простая, у вас есть холст на котором можно располагать виджеты. И каждый виджет имеет кучу всяких параметров, например:
- Трансформация: Расположение, Размеры, Центрирование, Внешние и Внутренние отступы, а также слой (чтобы одни виджеты могли перекрывать другие).
- Внешний вид: Задний/Передний фон, рамка и в целом внешний вид каждого виджета.
- Содержимое: Уникальные параметры для каждого виджета, условно текст, путь к изображению, список вариантов и т.п.
Также можно добавить возможность создания анимаций практически любых этих параметров (вроде того, что я показывал несколько роликов назад с интерфейсом сообщения)

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

Интерфейс вышел пока довольно всратым, всё же 30 минут на прототип это пока для меня маловато 🙃
P.S. Тут должно было быть видео, но я его потерял, так что остался только скрин)

Списки, массивы и цветной текст 🌈 | День 26

Знали бы вы как мне надоели вопросы про то, как поменять цвет ника нпс))
Так что в этот раз я учту эту ошибку и добавлю возможность красить текст почти целиком :D
Ну разумеется можно будет менять и другие атрибуты (жирность, наклон, подчёркивание, и зачёркнутый текст)

Ну и ещё я пока думаю над дизайном, тени тут явно нужны будут, да и отступ в начале как по мне стоит убрать 🤔

Улучшаю архитектуру 🏡 | День 27

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

Что изменилось:
1) Триггеры событий: Глобальные и Локальные
Теперь у триггеров два режима работы:
- Глобальный: Создаёт новый экземпляр скрипта с нуля.
- Например: Игрок зашёл на сервер
- Зачем: Это изолирует данные игрока. Если во время диалога с одним игроком на сервер зайдет второй, то он не перезапишет переменную первого, а запустится в своей "среде".
- Локальный: Срабатывает внутри уже запущенного скрипта.
- Например: Игрок сломал блок во время выполнения квеста
- Зачем: Позволяет обрабатывать события в контексте текущей ситуации (например, запретить ломать блоки, пока идет диалог, или ждать действий второго игрока).

2) Сообщения и Функции
Я пересмотрел структуру пользовательских сообщений и функций, напомню что это и в чём между ними разница:
- Сообщения: 2 вида блоков, грубо говоря отправитель и приёмщик. То есть Вы можете вместо того, чтобы писать огромный спагетти блоко-код, использовать сообщения и, например, при разных вариантах выбора посылать разные сообщения и писать их параллельно, а не последовательно. По факту это async { ... } на стероидах, можно как запустить это асинхронно и забыть, можно запустить и дождаться завершения. А можно отправить сообщение и записать его контроллер в переменную, чтобы потом отменить задачу (например, если вам нужно чтобы персонаж "размышлял" перемещаясь между 2 точками одновременно с диалогом, а по его завершению перестал)
- Функции: Тоже 2 вида блоков, один запускает функцию, второй содержит её действия. В отличии от сообщений - может принимать разные параметры, но не может вызываться асинхронно, чтобы случайно не изменить эти данные в процессе выполнения и не было потом вопросов, почему у вас скрипт работает не так)
3) Переменные и состояния
- Переменные: Теперь двух уровней - локальные (в рамках 1 файла) и глобальные (в рамках всех файлов). Поддерживают все типы данных, включая игроков, мобов и т.п.
- Состояния и флаги: Те же переменные, но привязанные к конкретной сущности (игроку/нпс), что позволяет Вам легко настроить триггеры, чтобы у разных игроков всегда запускался подходящий им скрипт. Да и я думаю мне тут даже объяснять не нужно, и так много чего можно придумать, можете даже пару своих примеров в комментариях написать :)
4) (Пока просто как идея) Думаю многие помнят, что в Legacy был один неприятный косяк, что нпс мог выгрузиться из чанка, а потом дублироваться, потому что движок его не нашёл. Особенно это было заметно во всяких городах с массовкой, приходилось ставить чанклоадеры и этим ещё и ухудшать производительность. А ещё для надёжности при входе полностью всю эту массовку удалять и респавнить, короче жуть 😨
Сейчас это решено просто - если нпс не прогружен, скрипт просто ждёт, пока придёт игрок и сам всё прогрузит. Это хоть и самый стабильный и надёжный вариант, но я думаю доработать эту систему следующим образом:
- При обычной задаче дойти до точки, можно будет включить принудительную прогрузку чанков в области нпс. Например, если эта какая-нибудь важная катсцена или задача.
- Для массовки и распорядка дня сделать вообще независимую систему не требующую загруженных чанков! Согласитесь, какое вообще игроку дело до того, как очередной Виталик будет идти на работу или на Олег - на рынок. Важен сам факт, что к определённому времени нпс должен быть в определённом месте, так что я думаю лучше сделать настраиваемую систему для каждого нпс, где указать во сколько он должен прийти на место и откуда. После чего движок уже сам определит, где и когда должен быть нпс.

Короче говоря, работаю над основой, чтобы потом разом закрыть кучу задач 🙂

Вы знаете что такое нормали, скалярные произведения векторов и Биссектрисы? | День 28

А мне вот пришлось вспоминать, что это такое 🫠
Короче говоря, сегодня, существенно доработал интерфейс, а также добавил немного звуков, стало куда лучше, чем с обводкой, тем более когда 2 блока пытались друг друга перекрыть)

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

Рефакторинг 🚴‍♂️🩼 | День 29

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

Пока что добавил немного математики и тригонометрии вам в блоки 😅
- Рейкастинг: Позволяет узнать точку, куда смотрит сущность + явное ограничение дальности, что не было бесконечных значений, если сущность смотрит в небо)
- Угол между 2 сущностями, т.е. от первой до второй относительно взгляда первой.
Думаю очень поможет в создании механик вроде "нпс должен пропасть, если игрок его не видит"

А, ну и кстати, для тех кто предпочитает Telegram, а не Discord, у нас тут группа появилась, заходите если что 🤔
https://t.me/+zBNc0IJUHXozZmMy

Больше удобных фич 🤝 | День 33

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

Вышло что-то такое 🙃

Кто эти ваши шейдыры? 😨 | День 34

Довольно много времени сегодня ушло на курсовую работу, да и по блокам я думаю на первое обновление хватит, сейчас их около 130. Остальные думаю буду добавлять уже кодогенератором после релиза, к тому же ещё ведь документацию делать)
Так что сегодня вместо девлога решил поделиться знаниями на моём Boosty, где-то пол года назад я писал достаточно технический пост про устройство пост-шейдеров в HollowEngine Legacy, но в этом посте я скорее затрону их логику и в целом расскажу, как работает рендер Sodium/Iris, а также разберём подобный эффект, применяемый на мир ✨
Пост скорее обзорный, так что в технические детали вдаваться не буду, чтобы было понятно и тем, кто с шейдерами никогда не работал (Но хотя бы школьный уровень математики вам сильно упростит понимание 🙃)

Дорабатываю систему сохранения ⚙️ | День 35

Практически полностью переписал прошлый подход к сохранению, теперь оно работает через Scope (Пространства) - определённый блок или исполнитель скрипта может создать новое пространство с изолированным набором переменных.
Например, на скриншоте сейчас запущен первый блок "Ждать 5 секунд" и на этом моменте я вышел из игры и движок сохранил 4 уровень вложенности:
- Первый уровень: Цепочка от корневого блока, хранит активный блок - это Если
- Второй уровень: Уже содержимое блока Если, а если точнее его результат - condition: true,
- Третий уровень: Далее идёт опять цепочка с именем активного блока, но уже внутри Then-ветки. Сейчас там указан ID блока Ждать.
- Четвёртый уровень: Пустой блок, это уже данные самого блока Ждать, их тут пока нет, но позже тут будет храниться пройденное время, чтобы оно не сбросилось при выходе и не пришлось ждать условные 4 часа с самого начала)

В целом это довольно умная система, которая для каждого блока всегда выдаёт чистый контекст для сохранения и затрачивает минимум памяти.
Если сравнить это с Legacy, то тут преимущество может достигать более чем в сотню раз 🤯
А всё, потому что раньше моя система сохраняла каждое действие, которое вообще было в скрипте. Теперь же эта система сохраняет только те данные, которые необходимы для успешного продолжения скрипта, то есть активные ветки и данные не завершённых блоков и в худшем случае оно может сохранить 7-10 блоков (зависит от глубины вложенных блоков), но никак не 500, как это было раньше 🫣