Я надеюсь вам понравилась прошлая неделя, теперь мы можем вернутся в наш график стандартных постов до 10к подписчиков)

Замечали ли вы что последнюю неделю наш любимый Подпольный Транскриптор мог долго обрабатывать войсы, или игнорировать их и потом резко отрабатывать все, как вы думаете, в чём было дело?

А правильный ответ - РосКомНадзор! Наши няшки поняшки сломали сетевое взаимодействие между микросервисом ответственным за предварительную обработку медиа и микросервисами которые непосредственно транскрибируют их. (кто бы думал). Так что да, мне пришлось немного поменять конфиги и теперь у нас есть несколько бенефитов.

1) Бот работает, уже хорошо, да?
2) Поверх SSL/TLS шифрации, трафик между микросервисами теперь дополнительно оборачивается в ещё один слой шифрации моей внутренней частной сети в которой взаимодействуют мои сервера.
3) Наконец туннели между всеми серверами использует не только Prometheus (личное достижение)

Вот как-то так, сидишь, держишь бота в рунете, а приходит дядя РКН и ломает сетевую связанность.

Кстати об играх, я вас понял, Игра Бога так Игра Бога, это уже точно. А пока я готовлю для вас контентик, начнём с интересного факта.

Сейчас при разработке сюжета мы стараемся выдерживать длительность серии в 25-30 сюжетных минут.

А знаете что было в первой серии Игры Бога? - "продолжительность сюжета на серию - 2 минуты"

Вот так и подросли мы, в 14 раз)

Многие из вас слышали от Зейта, кодеров и тестеров ST о "скриптах", но что это такое вообще?

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

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

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

Что может быть лучше технического поста? Технический пост, за которым стоит бэкграунд трёх дней мучений!

Появилась у меня необычная потребность — ускорить выполнение одного метода. Изучив его работу, я понял: можно добиться ускорения через внедрение кэша. Простая задачка! (Эх, наивный…)

Дано:
У нас от 1 до 20 тысяч записей. Каждая запись выполняет от 1 до 20 тысяч вычислений — которые, к счастью, часто повторяются. А значит, могут быть закэшированы.
Сложность: O(n²). Ну что ж, впихнём кэш.

Первая реализация была на MapDB, ведь он уже использовался в другом методе этого проекта.
Результат? Запрос 324 млн ключей через MapDB — идея плохая.
Время выполнения: 8 часов.

Окей, нужен вариант, готовый к хайлоаду.
Выбор пал на RocksDB. Переписал всё под него.
Результат: 2 часа выполнения (~21 000 операций/сек). Уже лучше, но всё ещё не то.

Думаю — может, твикнем параметры Rocks? Что может пойти не так?
Итог: нагрузка на диск — 1200 МБ/с, 0 операций в секунду. Красота…

Начинаю твикать осознанно, читая доку. Что я сделал:
- Отключил внутренний кэш RocksDB
- Уменьшил размер блоков до 8 МБ
- Отключил кэширование индексов
- Включил кэширование страниц на уровне ОС
- Увеличил размер страниц до 128 КБ
- Снял лимит на число дескрипторов

И ещё один важный шаг — переписал get-запросы на batched multiGet. Почему?
- Меньше JNI-переключений между Java и C++
- Оптимизация I/O при чтении смежных ключей
- Внутренний параллелизм RocksDB при multiGet
И… да! Ускорение до 1.5 часа.

Что дальше? Подключил GPT, начали вместе думать.
Появилась идея: батч в 18 000 ключей — перебор.
Сократил до 1000 — и получил прирост!

Результат: ~41 210 операций в секунду. Много? Да. Достаточно? Пока — нет.

Продолжение следует…

Дальше начался метод научного тыка. Сократил объём операций до 56 250 000 и начал тестировать разные гипотезы. Вот что получилось:

Результаты:
База (2 ГБ, batch = 1000): 8m 11s
Расширенный Block Cache (10 ГБ): 7m 59s
Уменьшенный batch (500): 8m 09s
Увеличенный batch (2000): 8m 06s
Лексикографически отсортированный batch: 7m 57s
Лексикографически отсортированный весь get: 7m 57s
Сокращение потоков вдвое: 7m 18s
Увеличение потоков вдвое: 9m 32s
Увеличение параллелизма и фоновых задач RocksDB: 8m 05s


Что стало ясно:
1. Block Cache:
Увеличение с 2 до 10 ГБ дало прирост всего ~2%.
➝ Значит, либо данные не влезают в кэш, либо узкое место — не RAM.

2. Batch size:
Изменения в пределах 500–2000 почти не влияют.
➝ Значит, размер уже оптимален под текущий паттерн доступа.

3. Сортировка:
Минимальный выигрыш от сортировки ключей (~14 секунд).
➝ Либо ключи уже достаточно локализованы, либо RocksDB сам всё делает неплохо.

4. Потоки:
Вот где интересно: меньше потоков → быстрее (7:18), больше потоков → медленнее (9:32).
➝ Классический bottleneck по диску или lock'ам:
➝ меньше потоков → меньше переключений и блокировок,
➝ больше потоков → хаос и случайные I/O.

5. Параллелизм RocksDB:
Изменение этих параметров почти не повлияло.
➝ Узкое место в другом.


Когда идеи начали заканчиваться, пришла мысль — а что если всё загрузить в память и забыть про диск?
Ну... не хватило 30 ГБ ОЗУ 😃 Больно, больно.

И тут чёрт меня дёрнул проверить версию JNI-обёртки.
Оказалось — она отстаёт на 2 мажорных версии. Обновил с RocksDB JNI 8 → 10 и...

БАХ — 833 171 операций в секунду с диска.
Время выполнения метода: 390 секунд.
ПОБЕДА.


🧠 Итого:
Три дня, куча боли, и в итоге:
- Ускорение метода в десятки раз
- Глубокое погружение в RocksDB
- Новые знания о высоконагруженных системах

А теперь слово моему копилоту:

Итоги оптимизации:
Обновление rocksdbjni дало основной прирост
Точное количество потоков имеет критичное значение
Сортировка ключей даёт минимальный, но стабильный прирост
Batch и cache — важны, но эффект умеренный
Использование NVMe SSD — must-have

Что дальше?
Архитектурные изменения: шардирование, горизонтальное масштабирование
Или full in-memory при небольших объёмах

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

В прошлом посте про геймдев я упомянул шину событий игры, и вы задали вопрос, что это за шина вообще?
Я люблю ваши вопросы, так что давайте ответим на него! 🥰

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

Шина - список методов которые принимают то или иное событие, порой с дополнительными плюшками в виде приоритетов или отмены события.
Давайте представим что Рома нажал ПКМ по двери чтобы открыть её и войти в комнату Брендона. Тут в дело вступает PlayerInteractEvent.RightClickBlock. Когда сервер получает пакет от клиента игрока о том что тот делает клик, в шину событий улетает этот ивент:

public static PlayerInteractEvent.RightClickBlock onRightClickBlock(Player player, InteractionHand hand, BlockPos pos, BlockHitResult hitVec) {
    PlayerInteractEvent.RightClickBlock evt = new PlayerInteractEvent.RightClickBlock(player, hand, pos, hitVec);
    NeoForge.EVENT_BUS.post(evt);
    return evt;
}

Ивент в шине, тут он будет проходить по всем местам где есть на него подписка (пример):

@SubscribeEvent
public void onRightClick(PlayerInteractEvent.RightClickBlock event) {
    event.getEntity().sendSystemMessage(Component.literal("КАК ТЫ СМЕЛ ТЫКНУТЬ ПО БЛОКУ?"));
}

Но как мы определяем какая подписка должна выполнится первее, для этого у нас есть приоритеты:

public enum EventPriority
{
    HIGHEST, //First to execute
    HIGH,
    NORMAL,
    LOW,
    LOWEST; //Last to execute
}

Возвращаясь к Брендону. Сначала наше событие приходит в HIGH подписку где мы проверяем, если Рома сильно ранен или у него нет рук, то событие отменяется, и идёт дальше, выглядит это примерно так:

@SubscribeEvent
public void onRightClick(PlayerInteractEvent.RightClickBlock event) {
    if(event.getEntity().isWithoutHands()) {
        event.setCanceled(true);
    }
}

Если Рома не прыгал со скалы, то ивент пройдёт дальше, и словится другим слушателем, который уже даст команду Брендону начать быковать на Рому, вот как-то так :3

Пока я тут собираю информацию для постов по Игре Бога, согласую её публикацию (NDA дело такое), собираю это в посты - проходит много времени, а ведь у меня ещё и работа есть, так что да, вы видите посты не так часто как этого хочу я. И параллельно изучению сценариев, изучению истории коммитов и кода я пересматриваю серии.

Ютуб что логично, заметил что у меня появился интерес к Игре Бога, а ещё он знает что я люблю смотреть документалки и рассказы про кино, к примеру MacGuffin Channel, И ОН РЕШИЛ ВЫДАТЬ МНЕ ЛЕГЕНДАРНОЕ КОМБО.

https://www.youtube.com/watch?v=z0v3_T2ynto

Короче да, ребята, я нашёл новую звёздочку лофд, за такой труд мы можем автору закинуть лайков)

Какая самая неотъемлемая часть сюжета?
Конечно же чат. Ведь в отсутствие возможности передавать мысли персонажей голосом, мы делаем это через текст — тот самый, который читаете вы и Рома. Именно поэтому мы уделяем ему отдельное внимание.

Например, если вы посмотрите первую и третью серии Игры Бога, то заметите, как мы начали работать над айдентикой чата.
Наши персонажи всегда пишут в квадратных скобках — [Картер] — это сразу позволяет понять: перед вами сюжетный герой, а не просто системное сообщение или реплика от энтити из какого-нибудь мода.

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

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

Вот такие вот мелочи, которые на самом деле — совсем не мелочи :3

Есть интересная и очень крутая вещь в нашем флоу работы, в процессе написания серии кодером и её тестирования тестером, она может немного изменится в сторону лучшего визуала и геймплея. Что я имею в виду? Ну смотрите, первая серия Игры Бога.

Помните все страшилки которые насылал на Рому Люциус? На самом деле их изначально было на одну больше, когда бы он рубил первое дерево, его бы ударила молния, но в процессе разработки и тестирования было решено что этот момент излишен и он был успешно вырезан.

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

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

Кукловод. О чём вы подумали, прочитав это слово? Фильм? Страшилка? Кукла из «Пилы»?
А ведь именно так можно назвать Storytelling.

Почему? В ранние времена в сюжете часто использовались сущности из других модов и ванильной игры: зомби, Картер, да даже Селести.
С нашими сущностями всё понятно — мы ими управляем напрямую. Но что насчёт чужих?

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

Наш «кукловод» может:
- поворачивать и направлять
- менять маршрут
- подменять текстуры
- глушить систему целей (goals)
и многое другое…

В итоге любая сущность подчиняется нашей воле.
Вот так вот :3

Строим настоящего робота WALL-E😍⚙️🎮🌱
https://t.me/WalleBuilding

Вы когда-нибудь задумывались, каково это — оживить персонажа из любимого мультфильма? WALL-E — это не просто робот из фантастической истории, это символ заботы о нашей планете, воплощение дружбы и надежды на лучшее будущее. Мы, команда энтузиастов из России, решили не просто мечтать, а действовать. Наш проект — это первый в России функционирующий WALL-E, который мы строим с любовью и вниманием к деталям. Хотите увидеть, как персонаж из мультфильма оживает на ваших глазах? Подписывайтесь на наш канал и следите за процессом создания. Это не просто проект — это история о том, как идеи становятся реальностью. Следите за нашим прогрессом здесь и вдохновляйтесь на собственные свершения 🌍