Sovka Ivanov

Баланс билдов.

2025-02-23T08:10:24.560Z

Техническая часть.

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

Ярко зелёным опорные распределения, мутно зелёным опорные билды при этих распределениях.

Сначала мы чего-то мыкались да пыкались, пробовали да тестили, и всё получалось неустойчиво со всякими сраными побочками. Характеристики уходили в отрицательные значения, небольшое изменение входа приводило к большому изменению выхода и т.д. Из неудачных попыток я помню только линейную регрессию, остальные нерабочие варианты благополучно забыл. В некоторый момент мы с пацанами додумались сделать визуальную модельку такой системы. Увидев это визуально, я воскликнул: «Ебать меня ржавым якорем! Да это же барицентрическая залупа!» И в тот же день задачка была успешно закрыта, реализация заняла несколько часов. Матчасть и вовсе несколько минут, львиная возня произошла с API гугл-табличек.

Чёрным опорные билды, красным искомый билд.

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

Найти ближайшие опоры.
Проинтерполироваться между ними.

Корокто про возню с API гугл-табличек:

Гуманитарная часть.

Это был первый раз, когда я делал математичное не CG. В будущем оказалось, что не последний, ещё пару раз нужно было выдумывать какие-то кастомные геймдизные инструменты, и в основном это было интересно. На следующих геймдизных задачках я заметил одну фундаментальную разницу между прогерством и дизайнерством: инстант результат и отложенный результат. В разработке результат работы можно оценить сразу же после нажатия кнопочки плэй; в дизайне же результат видно через три дня, тридцать дней, девяносто дней, в общем через много нажатий кнопочки плэй. И как следствие, дебаг разработки суть одно прямолинейное рассуждение, дебаг дизайна — какой-то ебучий бэк пропагейшен.

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

Расчлен на Unity.

2025-02-21T13:26:13.463Z

Техническая часть.

Код не покажу, потому что это НДА и просто душно. Алгоритм расскажу, потому что это можно и круто. Всё это происходило давно, и все полезные на тот момент ссылки да ресурсы сейчас утеряны и/или неактуальны. Да и хуй с ними.

Для заголовка.

Однажды мы делали пострелушки киборгов. Одной из угарных фич была расчленёнка и сочленёнка обратно. То есть какому-то терпиле (в т.ч. из своей команды) можно отстрелить нахуй голову, затем видимо войдя в кураж оторвать голову себе тоже, и водрузить на своего фрешдекапитейтед персонажа свежий трофей. БЛЯТЬ, ДА Я БЫЛ РОЖДЁН ДЛЯ ЭТОЙ ЗАДАЧИ. Беглый гугл показал, что расчлен на юнити делается легко. Там нужно-то всего лишь заготовки моделек без конечностей, и заготовки конечностей. И во время расчлена, просто нормальную модель заменять на безрукую например, а рядом спавнить оторванную руку. Но вот для обратного сочлена с такой системой требуются заготовки всех перестановок всех конечностей между всеми персонажами, что слегка неприемлемо. И никаких других способов расчленять гуманоидов я в интернетах не нашёл, как и никаких вообще способов сочленять. Я попробовал просто детачить кость от скелета, но юнити мне сказал «runtime error» или что-то в этом духе, оказывается так делать нельзя. После этого ~~в маршрутке начался~~ пришлось закопаться в доку на пару дней и разбираться, как это всё говно там работает. И вот как:

Есть иерархия костей, типа скелет. Хотя не типа ни хера, это и есть скелет. Это конкретные геймОбжекты в сцене с позишеном и ротейшеном. У них там есть параметр, какой меш на них забинден, этот параметр кайф, он мне пригодился.
Есть аватар. Это уже абстракция, а не конкретный объект. Можно его рассматривать как конфиг, в котором записаны имена и должности костей. Его роль — обоссанная прокладка между скелетом и аниматором. Аватар может быть произвольного или гуманоидного типа, в случае с гуманоидом у него должности костей расписаны заранее: левая рука, средняя нога и т.д. Это мне однажды вставило небольшую палочку в колёсико.
Есть аниматор. Это компонент на руте скелета, он собирает разную инфу со всей игры: какие кнопочки сейчас нажаты, кто персонаж по жизни и т.п., инфу отправляет в контроллер, анимации отправляет в аватар.
Есть контроллер анимаций, это обычный стейт машин, во всех движках одинаковый. Аниматор выдаёт ему разные параметры и спрашивает, что в такой ситуации делать -> контроллер ему отвечает, что в такой ситуации нужно делать приседания -> аниматор отправляет присед в аватара -> аватар сажает кости.

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

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

Гуманитарная часть.

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

Это жожо референс?

Запечёный GI на webGL.

2025-02-21T07:34:05.892Z

Техническая часть.

Ноль источников света.

ДжиАй онли.

Делали какую-то пострелушку на браузерном движке Playcanvas. По какой-то причине нам захотелось добавить туда global illumination, который предварительно красиво запечь где-нибудь там в гудини например. Чтоб персонаж бегал по левелу, и угарно освещался этим левелом. Но лайтпроб-то в плейканвасе нету. Значит придётся их своими руками сделать. На мне повисла работа по движку, на другом серьёзном пацане работа по гудини. Идея запекания проста: разбить пространство на грид точек, в каждой точке посчитать освещённость (цвет, интенсивность опционально), все эти значения упаковать в жсон и отдать мне. Идея лайтпроб тоже проста: засунуть этот жсон в шейдер, и шейдером разобраться с какого раена конкретная точка на геометрии, которую сейчас надо осветить, кто её ближайшие соседи из запечённого грида, и проинтерполироваться между этими соседями. Реализация оказалась тоже проста — всё как задумали, так и сделали. По части запекания в гудиче я хз какие проблемы возникали, это были не мои проблемы. У меня же возникла беда с суванием жсона в шейдер, ибо webGL того времени не поддерживал никаких буферов, и никаким удобным образом массив кастомных данных в GPU не передать. Но есть неудобный способ, который я уже применял в декалях — закодировать всю эту парашу в текстуру, и отправлять в видеокарту текстуру. Благо наши так называемые кастомные данные — это RGB, так что и кодировать даже ничего не пришлось, взял цвет точки, положил в цвет текселя, хуль тут сложного. Ну и вот, теперь у меня есть текстура, в каждом пикселе которой находится значение освещённости в какой-нибудь точке сцены. Эту текстуру я могу сувать в шейдер. Шейдер написал без приключений — там просто определение соседей да интерполяция между ними, ничего интересного. А потом снова нюанс: этот фейк-джиай должен быть встроен во все материалы сцены. Чтобы художники там понастраивали материальчики, игру включили, а мой GI опа и работает сам собой. И такую возможность встраивания своего кода в код материала плэйканвас предоставляет. Молодец какой. Там это называется shader chunks. Суть в том, что шейдеры компилятся при запуске игры, а не в едиторе. В едиторе же они хранятся текстом, просто открытым голым кодом валяются, а значит промеж этого заводского кода можно сувать свой кастомный код. И при запуске компилиться будет уже заводской шейдер со встроенными кусками моего. Я свой шейдер и положил во все материалы в чанк люминанса. А потом чтобы художники могли новые материалы добавлять, и меня не дёргать мол включи ну включи джиай, я бахнул скрипт, который при запуске ещё до компиляции шейдеров все материалы собирает, и суёт в них мой шейдер.

Гуманитарная часть.

Давным-давно я щупал движок юниджайн, кажется это был ещё 2014. Там я увидел лайтпробы и охуел как вкопанный. Это казалось обоссаным чудом, что глобал иллюминейшен возможен в риалтайме хоть в каком-то виде. Я тогда думал, что это какие-то надмозги придумали и даже не пытался там что-то изучить или поприкидывать, как это могли сделать; просто подумал «не для моих мозгов», пустил дегенеративную слюнку и забил хуйца. И вот спустя шесть лет мне поставили задачку бахнуть этот иллюминейшен в браузере. И мне не понадобилось даже ничего гуглить, идея как это сделать пришла сразу же, я сразу эту идею реализовал, и всё прошло гладко, легко и быстро. На протяжении всего дня разработки я не воспользовался гуглом ни разу. Задачка казалась пугающей издалека, но вблизи на практике выяснилось, что а разговоров-то было.

Декали на webGL.

2025-02-20T08:30:55.751Z

Техническая часть.

Что такое декали, если по какой-то причине твоя карьера прошла мимо них:

Мне нужно было их бахнуть на браузерном игровом движке Playcanvas. Требований было немного, вот они все трое:

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

И первым применением по плану должны были стать брызги крови на стенах, на полу, на любой геометрии, РАЗМАЗАТЬ ЭТО ДЕРЬМО ПО ВСЕЙ СЦЕНЕ. И думая о кровище, я от себя добавил ещё немного требований:

Расстояние от источника брызг до поверхности должно влиять на дисперсию.
Форма брызгульки должна зависеть от угла между направлением брызг и поверхностью.
Каждая брызга уникальна по форме, никаких подготовленных текстур, чисто генератив.

Позже оказалось, что первые два требования — это одно и то же требование в двух разных интерпретациях, это круто.

Все перестрелки между игорьками происходят на стороне CPU, то есть высчитывать направление и позишен декали придётся именно там. А рендерить придётся на GPU. Другой поганый момент — на GPU мне не сделать какую-то угарную структуру данных, в которую можно было бы на расслабоне складывать и хранить прилетающие из CPU декальки, которые при рендере доставать и юзать не снимая свитер. Значит удобно складывать и хранить эти декали придётся тоже на стороне CPU. Учитывая требования выше, мне нужна структура данных, у которой максимально быстрая вставка нового элемента, адекватно быстрый поиск элемента и максимально сильное похуй всё остальное. Спецфичи, которые могут помочь — у декалей три координаты, значит моя структурка может быть трёхмерной. Сразу же в голову пришло ЕБЕЩЕЕ ОКТОДЕРЕВО, оно ведь будто бы рождено для этой задачи, мэтчинг по требованиям сто из ста. И я его сделал. Вот как это говно у меня работало (ячейки октодерева во всём этом длинночтене я буду называть вокселями).

1. ИНИШИАЛ СОСТОЯНИЕ.
Существует структурка декали, в ней лежит матрица и какая-то кастомная инфа, например таймстамп или цвет или что угодно.
Существует тупа массив декалей. При ините естеесн пустой.
Существует структурка вокселя, в ней лежат восемь интеджеров (ссылки на декали в предыдущем массиве либо на другие воксели в этом же массиве); чекбокс subdivided; какая-то техническая инфа, которая я уже и не помню для нахуя.
Существует тупа массив вокселей. Оба массива нужны отдельно для отправки всех этих данных на GPU, потому что октодерево туда не отправить.
И собсна само октодерево: в инишиал состояни это просто один большой воксель размером с весь левел.

2. СПАВН.
Спавнится первая декаль, вторая и вплоть до восьмой — массив декалей пополняется, в большом вокселе восемь сцылок заполняются. И тут спавнится предательская девятая декаль. В массив она конечно на изи попадает, но в вокселе для неё места нету, все ссылки заняты. И этот кедр просто делится на восемь вокселей поменьше. Они попадают в массив вокселей. Те восемь декалей, которые в большом папе, распихиваются по его дочкам, папа-воксель ставит себе чекбокс subdivided, и ссылки на декали заменяет ссылками на дочек.

Ни хуя не понятно, но очень интересно. Слева до деления вокселя, справа после.

3. ПОИСК.
Позишен свежей декальки поступает в первый большой папа-воксель. Если этот воксель уже разбит, то он оценивает, с какого раена свежая декаль, и кому из дочек её отправить, и отправляет. Доча-воксель, принявшая эту декаль, поступает с ней точно так же. И так до тех пор, пока декаль не дойдёт до вокселя, который ещё не разбит на дочек, и в котором есть для неё место.

4. ПРОФИТ.
Казалось бы ни хера себе тут работы, компуктер перегреется. Хотя если ты шаришь за O(n), то тебе не казалось бы. Тем не менее. На тестах декали вставляются не то что с лагом, а с ускорением нахуй. Фпс вверх подскакивает, когда декаль спавнится. Шучу конечно, фпс просто не дёргается, никакого лага нету, всё работает максимально с кайфом. Октодерево аппрувед.

Маленькай момент с максимальной глубиной дерева, доколе оно может делиться. Тут изи посчитать, на карте максимально может бегать x челиков, в каждого можо сделать максимум y попаданий до разлома кабины. Пусть карта отмывается от крови раз в z каток. Итого максимально может заспавниться x*y*z декалей. Первые два множителя это данность, константа, факт, принимаем это. Третий множитель на тестах регулируем так, чтобы и крови копилось нормально, и переполнений дерева не возникало. Но вообще для деления дерева до глубины всего лишь пять уже требуется восемь в пятой степени успешных ранений игорьков — это 32 тысячи выстрелов, тридцать две тысячи нажатий ЛКМ при условии что все ниибаца меткие. Поэтому эта тяга с дроблением дерева в бесконечность меня не кошмарила. Алсо в воксели можно записывать их поколение, и просто его ограничить, но я кажется забил хер либо забыл.

Теперь нужно передать массив декалек на GPU и начатьь уже рендорить. Не так быстро, молодой человек. В webGL на тот момент не было никаких буферов, webGPU не существовал даже в открытой бете, прямого пути переправить сраный массив данных из проца в видяху на вебе просто нету. Но есть косой путь — текстуры. Значит надо просто задекодить объекты декалек в наборы пикселей, а на стороне шейдера раздекодить обратно, хуль тут сложного. Тут я особо ничего не делал, собрал пару кодов со стакОверфлоу, они по какой-то причине не работали, починил, бахнул пивасика, посмотрел серик, в то время «дом дракона» только начинался. В общем трансфер данных налажен, остался рендер. И раз уж все брызги крови будут одним и тем же материалом — почему бы их все не рендерить за один дроколл. Просто взять шейдер крови, накинуть сразу на всю геометрию в сцене, а декали использовать как маску для этого шейдера. И как раз количество декалей не будет влиять не перфоманс вообще, и все требования получаются выполнены. Так и сделал, весь левел со старта облит кровью, просто с альфой. Когда кто-то cum blood — декаль затирает маску, и в этом месте материал крови становится непрозрачный.

Теперь про шейдер. В шейдере по умолчанию всегда можно добыть глобальный позишен обрабатываемого пикселя, так уж оно устроено. Так же там есть массив вокселей, который прилетел с проца, и нулевой в этои массиве — папа всех вокселей. Зная всё это, шейдер спрашивает у папы, есть ли у того доченьки. Если есть, шейдер по позишену сам определяет к кому из дочек обратиться, и обращается. И так до тех пор, пока не найдёт ту, что не разделена. И шейдер пройдётся по всем декалям в ней, и каждой из них подотрёт свою альфу. Здесь выяснился вот такой момент:

Чёрным воксели, красным декаль, зелёным рендер декали.

Центр декали в левом вокселе, там шейдер её находит и рендерит. В правом вокселе шейдер её не находит и не рендерит. Значит вставка декалей в воксели должна происходить по другому принципу. Не в тот воксель, внутри которого находится её центр, а во все воксели, с которыми она интерсектится. Внёс эту правку, на перфоманс не повлияло, всё хорошо. Теперь шейдер всегда понимает в каком пикселе сколько декалей находится.

Ещё нужен мапинг декали на поверхность. Тут инфы в интернете полно, отдельно разжёвывать не буду, взял да замапил. Но в этот дефолтный мапинг я добавил небольшой нюанс — перспективу брызгульки. То есть баундБокс декали расширяется по оси Z, и похож на фрустум камеры. Это как раз для дисперсии с расстоянием. И неожиданно это же делает брызги красивыми, когда они проходят вдоль стены например. То есть два моих выдуманных требования я убил одним зайцем.

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

декали в браузере 60 фпс жесть смотреть.

Гуманитарная часть.

На момент, когда мне эту задачку поставили, я не знал о внутренности декалей ровно ничего. Знал только, что такая технология существует, юзал декальки когда-то давно в анриле. Полез гуглить как там в плейканвасе с декалями вопрос обстоит. Не нашёл ничего вообще, про это были вопросы на форуме, вопросы без ответов, вопросы с ответвами от разрабов, дескать функционала такого у нас нету и не предвидится, сасайте палка. После я полез гуглить как сделать декали на openGL, нашёл полезную инфу про мапинг декалей, какой-то видос с не очень полезной, но крутой инфой от графоноинженера какой-то трипл-инди хуйни. Но не нашёл ничего, что могло бы мне помочь. Зато начерпавшись вот этой всей рандомной хуерги со всего интернета по запросу «decals openGL», решение по-тихонечку начало формироваться как будто бы само собой. Я просто сижу, в носу ковыряю, ничего не делаю, а идея приходит. Ну не кайф ли. Кайф. Потом правда приходится эту идею реализовавыть, что в общем-то тоже кайф. А иногда в процессе реализации осознаётся, что идея не рабочая, и нужно ещё поковырять в носу, что снова кайф. Хоспаде, да какой этап разработки не возьми — всё кайф.
Игра, для которой это всё делалось в итоге переехала на юнити, и эти декали канули в хер. Никаких эмоций у меня по этому поводу не возникало, я свой балдёж высосал из разработки до дна.