Log of Alprog

У меня сейчас в голове борятся две концепции для Crunch House. Общее это то, что у нас есть RimWorld-подобный геймплей, где ты управляешь студией из нескольких человек с разными скиллами. У нас есть мир офиса, где дэвчики обедают и ходят на планёрки, но как только они садятся за комп, они попадают в мир репозитория. Там кодеры физически обрабатывают шестерёночные поля кода, ловят баги; артисты физически в мастерских делают ассеты. А также есть мир игры, куда левел-дизайнеры носят ассеты, строят локации, а тестеры по ним ходят. Не буду сейчас вдаваться в остальные нюансы. Сосредоточимся на различиях. В изначальной концепции мир репозитория представляет собой визуализацию работы системы. Между зданиями проложены дороги, по котором ездят машинки (job system) и перевозят ресурсы. Такой Anno-стайл менеджмент производственных цепочек. Плюс ещё есть река по которой проплывают кадры-корабли. Каждый кадр мы должны загрузить треугольниками, после чего он отправляется вниз по GPU Stream. Нагруженный кадр плывёт дольше. Опционально он ещё по пути должен перевернуть все треугольники в турбулентных потоках от вертексной мельницы и покрасить их вблизи пиксельной красильни. Так или иначе у нас корабли символизируют общий FPS системы, мы видим что тормозит: CPU или GPU, если корабли где-то накапливаются. Но в этой концепции загрузка кораблей становится центральным элементом геймплея. Причём FPS и нагрузка становятся общими для всех тестеров. Либо надо как-то чередовать корабли кадров, или делать какие-то оверлеи (и тогда всё становится запутанным и визуально перегруженным). Во второй концепции я подумал, а что если локации — это здания-павильоны в том же пространстве? Тестеры и кодеры ходят рядом, больше экшена происходит в одном месте. Оверлей тоже можно сделать, но который наоборот скрывает, а не добавляет: репозиторий заменяется на море, а всё что мы видим — это игра в виде островов (чисто на случай если хотим полюбоваться самой игрой). В этой метафоре как будто возникает больше пространственных конфликтов размещения (сама игра vs технические помещения и коммуникация вокруг). И больше упор на людей, которые кранчат, а не на машинки и симуляцию программы. Что думаете? Главная дизайн-проблема у меня сейчас это то, как придать каждой игре уникальность. Чтобы игра была нечто большее, чем просто сумма локаций и ассетов. Есть идея как-то превратить это в пространственный пазл, но не до конца оформленно в голове.

Только что осознал, что прошлый раз, когда я серьёзно озадачивался вопросом создания тайловых текстур, был БОЛЕЕ 20 ЛЕТ назад. Вот эти файлики с тех времён. Когда я сам руками заделывал швы в каком-то примитивном редакторе. И вот мы снова здесь. Всю ночь изучал, чего новенького с тех пор появилось в этой области: читал пейперы, пробовал либы всякие. Нейронки — это, конечно, хорошо; гигантские тулзы для художников — тоже. Но всё-таки хочется удобную тулзу с минималистичным GUI, заточенным под плитку wang'а и API для массовой обработки. Похоже, придётся самому писать.

Я влюбился в геометрическую алгебру 2026 год начался во многом с подтягивания математики. То ли на фоне наступления ИИ-шки меня потянуло на фундаментальные знания, то ли в преддверии моего скорого перехода на движок*, но так или иначе уже пару месяцев как очередное обострение. Они у меня случаются периодически, но в основном я долблюсь в какую-нибудь из балдёжных физик (кванты, космология, СТО/ОТО), ни одной из которых у меня не было в универе, но разобраться очень хочется. В случае с квантами долблюсь обычно не очень успешно, потому что местами не хватает математической подготовки. Один из очевидных пробелов — абстрактная алгебра, который я стал закрывать книгой Чарльза Пинтера. Я, конечно, пока не добрался до алгебр Ли, но дико кайфанул от первой половины книги: теории групп и немножко колец. Интересно, что я учусь вместе с чатомЖПТ, задавая ему вопросы по непоняткам. На типовые вопросы он отвечает прям хорошо: таблицы Кэли рисует, находит подгруппы, факторизует. На более экзотических структурах (лупы, моноиды) люто галлюцинирует, но по основному материалу с таким помощником учиться одно удовольствие. Хз, как будет выглядеть высшее образование через 10 лет, потому что уже даже для тупых вопросов препод-человек не особо нужен. *** Но хватит уже про абстрактную алгебру. Она классная, но не главная в этом посте. Этот пост — признание в любви геометрической алгебре. Моё первое знакомство с ней началось с интерактивной статьи про роторы: Let's remove Quaternions from every 3D Engine. И я не перестаю пиарить её при каждом удобном случае. Серьёзно, почитайте, если ещё не видели — это прям eye-opening. Во многом эта статья вдохновила меня на написание моей статьи про матрицы. Я её, кажется, так и не показывал здесь? Несмотря на то, что я потратил кучу времени на интерактивные иллюстрации и даже выступил с этим докладам на внутренней конфе парадокса, я так и не доделал текстовую версию. Но презентация доступна. Посмотрите что ли. Зря что ли делал? Но в этом году я решил более серьёзно разобраться с геометрической алгеброй по книжке МакДональда. И сказать, что я очарован, это ничего не сказать: она не только сводит dot и cross к одной операции, не только объясняет повороты без привлечения 4D, но и обобщает в целом комплексные числа и кватернионы. Совершенно казалось бы разные вещи из разных разделов математики внезапно сводятся к одному и тому же и выводятся буквально из одной операции. Просто катарсис. Геометрическая алгебра — ты моя Валентинка ❤️ Многие спросят, если она такая крутая, то чё её никто не использует? Почему ни в одном движке её нет? А дело в том, что классическую линейную алгебру тупо знает больше народа. Она появилась гораздо раньше и входит в стандартный университетский курс. Линейная алгебра давно и прочно занимает одно из самых центральных мест в математике (наряду с матанализом), на её языке работает половина науки от квантовой физики до экономики. Геометрическая алгебра, напротив, появилась сравнительно недавно, и это по сути другой язык. И на нём не так уж много материалов для начинающих. Обычно статьи с применением геометрической алгебры уже предполагают, что вы знаете предмет в терминах линейки. Но как же всё становится проще и осмысленнее в геоме. Одним словом, КРАСОТИЩА. И да, я знаю, что это всего лишь алгребра Клифорда, и очарование потом у многих проходит. Но, чёрт возьми, дайте насладиться влюблённостью, я в своей геометрической фазе. *** Разумеется, я ещё по мелочи затыкал более мелкие дыры всякими ютуб-плейлистами на разные темы. Из наиболее существенного: я наконец-то разобрался с дуальным пространством (для этого пришлось немного залезть в тензоры). А ещё было приятно найти видос у 3Brown1Blue, объясняющую формулу эйлера ровно тем же способом, как я её себе объяснял в древнем посте. * — ну и да, если в апреле сдадим крупный майлстоун, то я на годик по обмену схожу в команду движка. А там дальше видно будет.

Ребята из "Пилим, Трём" сняли мини-фильм памяти Кранка. Туда же в качестве бонуса вошло и моё интервью с Андреем 2013 года, которое я упоминал в прошлом подкасте. Кранк был важным человеком в моей жизни. Я пришёл к нему в студию уже опытным разработчиком, но всё равно воспринимал его как своего "геймдев-папу". Посмотрите. Душевное. https://www.youtube.com/watch?v=7Ea9NfH73Ss

Подписывайтесь на ребят, они классные t.me/pilimtrem

Сходил на подкаст ПИЛИМ, ТРЁМ. Обсудили моё движкописательство, пет-проекты и литературные конкурсы. Внутри также стандартный набор моих баек, немного старческого нытья и заметные страдания от подбора слов на русском. Но вроде как пообщались душевно. Уточнение: на момент записи я был в процессе получения апрува на пет-проджект. Уже всё есть официально. Кранч Хаусу быть! https://www.youtube.com/watch?v=uy7LLyoOtKA

Тяжёлые выборы #2 С днём, когда моё MS-бойство серьёзно пошатнулось. Несмотря на то, что я сейчас пишу исключительно под винду и только на DirectX12, я в итоге перешёл во многом на OpenGL конвенции: Right-handed координаты и Bottom-left текстуры. Да-да, это ещё один пост про чёртовы оси, и я их снова изменил. Во всех бедах я по-прежнему продолжаю винить Сильвестра Лакруа и прочих составителей учебников по математике 18 века, повадившихся рисовать ось «Y» вверх. Именно они обрекли многие поколения школьников на страдания, всякий раз когда им требуется теперь отступить место для графика в школьной тетрадке. А ведь у них была историческая возможность развернуть «Y» вниз, и тогда бы это удобно встраивалось в европейское письмо слева-направо и сверху-вниз (а положительные углы шли бы по часовой стрелке). А ведь направление письма сверху-вниз определило ещё и направление скроллинга страницы, и направление обновления монитора, а это, в свою очередь, повлияло и на систему координат большинства графических редакторов и файловых форматов. Но увы. Они решили направить ось ординат наверх, и это во многом предопределило разброд и шатание по вертикале между DX и GL, между GUI и World Space. Моя приверженность левосторонней системе координат и TopLeft-текстурам произрастала из приоритета консистентности над математичностью. Мне важно, чтобы мировые координаты росли туда же, куда и текстурные. И чтобы «X» вёл себя точно так же, как и «Y»: нет ничего более раздражающего, чем флип только одного компонента. А поскольку координаты графических редакторов (Paint, Photoshop) это своего рода данность, то я подсознательно выстраивал всё остальное под них. И до поры до времени я был готов мириться с тем, что это нематематично: ну, подумаешь, повороты в игре будут идти в другую сторону. Задокументировать и забыть. Но я сдался на утилитах для 2D геометрии. Функции типа «площадь под кривой» или «IsClockwise» для многоугольника обычно предполагают, что мы смотрим на оси как принято в математике. Но если в моём движке большую часть времени мы смотрим на оси с обратной стороны (X — вправо, Y — вниз), то либо надо функции переименовывать, либо всегда держать в голове, что их значения перевёрнуты для геймплея. И всегда нужно помнить, где именно инвертировано внутри, а где — предполагается инвертировать на выходе. Это просто невозможный оверхед, который непременно приведёт к путанице, и к тому, что ты сам в какой-то момент перестанешь доверять названиям собственных функций. Масла в огонь добавило то, что большинство DCC экспортят увишку по умолчанию как Bottom-Left и то же самое предполагает MikkTSpace — по сути стандарт тангент-спейса. И тут я снова задумался: а такая уж ли данность координаты графических редакторов? Я большую часть жизни использую Paint.Net. Как оказалось, проект давно закрыл исходники, но у него есть open-source клон Pinta. Который, по моему мнению, начиная с версии 2.0 тоже пошёл куда-то не туда, уродуя интерфейс. Но в общем я форкнул себе старую версию Pinta и перевернул там отображаемые координаты. И жить сразу стало веселее. DirectX я тоже перенастроил так, чтобы он как будто нативно был Bottom-Left. Для этого я переворачиваю текстуры при загрузке и ставлю отрицательную высоту у вьюпорта при рендере-в-текстуру. И получается, что он семплит и рендерит как будто по правилам OpenGL, не нужно ничего флипать в шейдерах. Всё растёт в одном направлении, всё консистентно. Уж не знаю, делает ли так кто-нибудь ещё: обычно все переворачивают текстуры в OpenGL, чтобы они были как в DirectX, а я вот сделал наоборот всё. В RenderDoc, конечно, всё отображается вверх-ногами, но там, слава богу, есть кнопочка отзеркалить изображение. А ещё у меня всё ещё Z-up. Надеюсь это менять не буду. Господи, когда же я уже буду игру делать, а не оси вертеть туда-сюда?

Последнее время активно работаю над движком для Crunch House. Пока занимаюсь всякими техническими штуками: Deferred Shading, MSAA, Тени. В планах как минимум ещё TAA, Motion Blur, Bloom, SSAO, SSR. Возможно, для виртуального мира игры эти настройки нужно будет разблокировать по мере улучшения движка, который надо будет создавать в самой игре. Дошёл вот до создания персонажей. Референс это в первую очередь RimWorld и Prison Architect, но скрещенный с Portal Bridge Construction. То есть я хочу такие же простые 2D-силуэты, но реально торчащие в 3D, с некоторой толщиной и отбрасывающие корректные тени. Думаю, какой подход подойдёт лучше: либо генерить настоящую геометрию, либо квад с Alpha-To-Coverage. Настоящая геометрия хорошо подходит для создания туловища, круглой головы и рук. Но вот для всяких пропсов и причёсок генерировать геометрию из изображения не так удобно. Квад с прозрачностью, конечно, сильно проще, но тогда сложнее сделать нормальную толщину. Что думаете?

Проблема праворукой системы координат в том, что даже если определиться, какая ось смотрит вверх, там существует ещё куча вариантов с лево/право и вперёд/назад. Тим Суини на днях твитнул, что Unreal Engine будет переезжать с координат FRU на LUF. Типа, Right-handed Y-up это стандарт в индустрии. Ну не знаю, насколько это прям стандарт. Тем более именно LUF. По мне так лучше уж RUB выбирать. Он вроде чаще используется в приложениях, если ноги из OpenGL растут. Иронично, но я в своём движке буду занимать квадрат Анрила теперь в одиночку, хе-хе

Иронично, но изначально я считал схему Unreal одной из самых упоротых, но по итогу сам к ней пришел. Но зато я остался верен более нативной для DX левосторонней системе координат. Как видите, microsoft-бой однажды — навсегда microsoft-бой. Ну и, кстати, забыл упомянуть одну из самых главных киллер-фич левосторонней системы: я правша. А это значит, что когда у меня в руке мышь, левой рукой гнуть пальцы банально удобнее. Впрочем, надо бы обзавестись распечатанной на 3D-принтере гизмой осей.