⚙️Log #17

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

Почему так? Всё просто: есть основная работа. Мобилки и веб, казуальщина, головоломки и детский кринж. За это платят стабильно и по меркам моего региона — даже очень хорошо. Но по меркам геймдева в целом — это середнячок, а удовольствия от процесса минимум.

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

Есть ещё и мой внутренний программист, который грызёт изнутри. За 7 лет я нафигачил кучу опыта: Unity, Cocos Creator, C#, JS/TS. Набежало больше 20.000 часов. Если верить правилу 10.000 часов, я «дважды мастер». Но по факту так себя не ощущаю.

Проблема в том, что я слишком верхнеуровневый. Опыт размазан: работаешь → выгораешь → снова работаешь. Да, могу собрать игру определённого уровня. Но есть потолок. Смотришь на AAA — и вообще не понимаешь, как там такие технологии реализованы. Для этого нужен другой фундамент, а у меня его тупо нет.

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

Хочу ещё копать не только в технику, но и в историю. Истории вроде Ады Лавлейс, первых компьютеров и всего этого старого безумия. Это вдохновляет, заряжает и помогает не забывать, ради чего всё начиналось.

Хочу подтянуть теорию. Потому что, когда у тебя только практика, это реально мешает в общении и в работе. Теоретическая база даёт уверенность, системность и другой уровень понимания.

🟢 Теперь к движку. За эти месяцы у меня родились новые идеи, и я начал перестраивать архитектуру.

План такой:
- будет два ядра — одно на C#, другое на JS/TS, чтобы собирать проекты и под веб, и под ПК;
- будет свой скриптовый язык ManuScript, пишу его на Си;
- на C# сделаю собственную библиотеку рендера, а на ней — фреймворк для UI, чтобы можно было собирать как игры, так и десктопные приложения;
- на этом же фреймворке будет написан редактор под Windows.

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

⚙️Log #18

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

🟢 Нативное ядро: C# и .NET 8.0 LTS. Это основная сила движка для десктопа. .NET 8 предоставляет отличную производительность и современные возможности. Логика будет разбита на модули в виде отдельных DLL-библиотек. Сам движок соберётся в одну динамическую библиотеку.

🟢 В нативной части рендеринг будет на OpenGL. Это проверенная технология с хорошим балансом сложности и возможностей. В далёкой перспективе — переход на Vulkan для более тонкого контроля и производительности. Для веб-версии, естественно, будет задействован WebGL|GPU.

🟢 Фокус сейчас на Windows. Как только нативное ядро станет стабильным, займусь вебом через WebAssembly (WASM) и того же WebGL.

🟢 От идеи с собственным скриптовым языком ManuScript я отказался. Не вижу смысла тратить силы на создание и поддержку того, что уже прекрасно реализовано другими. Это дикая дистилляция велосипеда.
- Основной язык логики — C#.
- Для гибкости будем подключать скриптовые языки, вроде Lua или JavaScript. Идеально для контента, модов или быстрого прототипирования.
- DSL остаются для конкретных задач, например, для описания UI, сделаю что-то похожее на XML для структуры и подобие CSS для стилей.
- Будет еще визуальный язык, что-то похожее на блюпринты в UE. (это не в приоритете и скорее всего будет являться инструментом для систем, где важна четкая визуальная связь)

Итого план стал более зрелым и сфокусированным. Вместо распыления на два ядра и свой язык — концентрация на сильном нативном ядре на C# с продуманной модульной архитектурой.

⚙️Log #19

В данный момент занимаюсь модулем рендеринга. Пробую описать какой-то пайплайн...

🟢 Пока что пришел к такой системе: Render Pipeline -> Render Phase -> Render Phase Layer -> IRenderable

Для теста завел объект спрайта и попытался его отрендерить в этойм пайплайне.

🟢 Моя первичная задача:
Реализовать модуль рендеринга до какого-то рабочего состояния.
- Чтобы можно было например отрендерить N спрайтов с уникальными трансформами
- Чтобы все это было за N батчей (система батчинга)
- Чтобы N спрайтов использовали N текстур
- Чтобы были динамические спрайты, которые могут менять свои параметры в процессе. (для анимаций)

🟡 После этого рендеринг можно будет оставить на какое-то время и заняться системой UI. Начну писать каркас на основе XML + CSS.

⚙️Log #20

Я давно знал о существовании RenderDoc - наблюдал за его использованием на стримах других разработчиков, но тогда он казался мне чем-то сложным и непонятным. До недавнего времени я откладывал глубокое погружение, но сейчас решился - и был приятно удивлен!

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

Я разрабатываю движок и систему рендеринга на .NET 8. При обычном запуске или дебаге все работало идеально, но при попытке захватить процесс через RenderDoc приложение молча падало на старте. Ни ошибок, ни логов - просто краш.

Перелопатил пол-интернета в поисках решения. Находил похожие проблемы, но их фиксы не подходили под мой случай. Начал даже думать, что .NET принципиально несовместим с RenderDoc.

Тут началось детективное расследование.

В отчаянии я решил проверить другие .NET движки - Stride и Prowl. К моему удивлению, их рантайм прекрасно работал с RenderDoc! Это окончательно сбило меня с толку - почему у них работает, а у меня нет?

Погрузившись в документацию OpenTK (обертка над OpenGL), я нашел ключ - нужно было включить дебаг-режим для OpenGL. И вот тут проявилась настоящая причина проблемы!

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

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

🟡 Теперь планирую глубже изучить RenderDoc - буду читать документацию и экспериментировать с различными фичами инструмента.

⚙️Log #21

Изучаю потихоньку OpenGL, вникаю в системы рендеринга.

Вот основной список документаций, которые штудирую:
1. OpenTK Learn
2. OpenGL Core
3. OpenGL GLSLang Spec
4. OpenGL Registry

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

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

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

🟢 Потом познакомился с оптимизацией для работы с вершинами. Условно, мы можем для отрисовки спрайта использовать 6 вершин, что не очень эффективно, потому что в двух местах будет дубликат вершин из-за наложения двух треугольников. Либо же мы можем использовать только 4 вершины, что будет правильнее, и переиспользовать для создания треугольника уже известную вершину. Для этого нам поможет EBO — это буфер элементов, в который мы передаём индексы вершин, загруженные в VBO и определённые при помощи VAO. Здесь, кстати, тоже есть важный момент: EBO нужно привязывать к привязанной VAO, потому что он работает с ней, так как ему нужно понимать индексы вершин.

🟢 Ну и по мелочи: ещё поигрался с настройками OpenGL, например, с включением смешивания.

🟡 Дальше планирую по-прежнему работать над рендерингом. Нужно разобраться более подробно с фундаментом.

⚙️Log #22

Начал писать парсер под wavefront формат (.obj) и мне райдер предложил поставить расширение.

Неожиданно и приятно был удивлен, что меш можно осматривать прям в IDE, еще и подсвечивает данные + можно поиграться с разными настройками.

⚙️Log #23

Давно не ощущал такой свободы в разработке...

За последние два года устал заниматься Unity-like мобильной дрочильней. Единственной отдушиной был веб-стек, который пришлось осваивать из-за очередного бума HTML5-игр. Но и там всё переросло в рутину, потому что задачи в той или иной степени повторяются.

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

Вот оно, запах инди! Многое здесь создается только потому, что «Хочу!»

⚙️Log #24

Сезон страданий открылся...

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

Всё шло прекрасно до одного нюанса. Приложение начало крашиться, когда я делал два раза подряд привязку одного и того же буфера или вершинного массива. Раньше можно было привязывать сколько угодно раз, а теперь — нет. В рендере начиналась дичь в момент привязки указателей на данные атрибутов. Я хотел сделать лаяут, который автоматически сдвигал бы offset и определял stride для вершинных атрибутов.

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

Оказалось, что я создавал буферы в автоматическом свойстве через лямбду:

public int Id => GL.GenBuffer();

Из-за того, что GL.GenBuffer() — unsafe-метод, при каждом обращении к свойству генерировался новый буфер, а старый терялся, создавая утечку памяти. Решение было простым — вынести создание в конструктор:

public int Id { get; private set; }

public ArrayBuffer()
{
    Id = GL.GenBuffer();
}

Теперь буфер создаётся только один раз и больше не вызывает падений при повторных привязках.

P.S. Дипсик и GPT-чат вообще не справляются с низкоуровневой разработкой. Да, они знают многое, и полезно с ними сверяться по каким-то нюансам, но они очень жестко теряются и постоянно выдают невалидную информацию. Она иногда даже не сходится с официальной документацией. А такие нюансы, как порядок привязки буферов — вообще жопа для них. Да, они в курсе, что должен быть какой-то порядок, но какой именно — им пофиг. В каждом ответе всегда рандомный порядок и бессмысленные биндинги и т.д.

⚙️Log #25

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

При выборе проекта в лаунчере он будет открываться в изолированной рабочей директории. Эта папка будет содержать только файлы, относящиеся к данному проекту, а также служебные метафайлы для работы редактора и движка.

🟢 Решил реализовать эту систему на раннем этапе, чтобы заложить основу для её дальнейшего развития.

На текущий момент наметил принцип работы:
- Для каждого проекта автоматически генерируется решение (.sln) под .NET 8.0, а также его первый проект (.csproj).
- Параметры сборки для всех проектов определяются на уровне решения. В нём прописаны ссылки на собранные DLL-библиотеки движка.
- Пока что путь к этим DLL читается из переменных окружения компьютера. В будущем этот механизм может быть изменён — возможно, путь будет генерироваться динамически при запуске редактора. Решение через переменные окружения было выбрано как наиболее стандартное на первом этапе.

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

🟢 Каждый проект будет содержать главный файл .project с информацией о нём: название, описание и т.д.

Также в этом файле указывается тип проекта:
- Игра — конечный продукт, разрабатываемый на движке. Собирается в исполняемый .exe-файл вместе с контентом. Может иметь зависимости в виде библиотек и пакетов.
- Библиотека — проект, состоящий в основном из кода, без контента. Представляет собой обычные .dll-файлы, которые могут использоваться в играх или других пакетах. Библиотеки могут быть одиночными или представлять собой группу взаимозависимых проектов.
- Пакет — reusable-компонент, который можно легко переиспользовать в разных проектах. Это аналог Packages в Unity, но адаптированный под нужды данного движка. Пакет может содержать как код, так и контент. Он может зависеть от других проектов, но только от библиотек или других пакетов.

🟡 В качестве теста я начал делать в этой системе игру Flappy Bird. Пока что всё работает отлично: процесс удобен и не требует дополнительных манипуляций с файлами проекта.

⚙️Log #26

Давно не было новостей по разработке, но потихоньку, помаленьку, по строчке — работал!

🟢 Продумал больше архитектурных штук, определился с техническим стеком, нащупал направления, которые моему внутреннему феншую в радость. Например, закончил с экспериментами структуры пользовательского проекта, который будет создаваться по шаблону через CLI движка. В планах сделать виртуальную среду для V8 в связке с TypeScript. Скажете зачем? А я захотел интегрировать JavaScript движок для скриптинга. Потому что интерпретируемость даст условия для быстрых итераций без пересборки, а еще Hot Reload в такой среде куда лучше. Не могу сказать, что у шарпа он плохой, но интерпретатор может творить магию, особенно в таком нетипизированном языке (благо правится тайпскриптом). Скриптинг теперь только в JS? Нет, будет основной нативный слой на C# и дополнительный JS. Можно работать в связке: часть, требующая быстрых правок — на JS, а производительности — на C#. Это пока определилось на этапе экспериментов, может это все бредни сумасшедшего, а может прекрасное решение.

🟢 Мне очень не нравится концепция движка, где основа — редактор. Нашел компромисс: будет встроенный редактор в рантайм игры. Движок будет делиться на слои выполнения, где в дебаг режиме основной слой идет со встроенными инструментами. Вкратце: движок — это библиотека, игра — плагин. Ни у движка, ни у игры не будет исполняемой стороны, это просто либы, однако, когда CLI соберет исполняемый файл, он просто подгрузит их по слоям. Управление будет через CLI, а редакторские инструменты станут частью рантайма.

🟢 Еще не захотелось юзать OpenTK, некомфортно делегировать нативные вещи. Хочу писать сам, понимать как это работает под капотом и иметь контроль. Потому в проекте появились нативные модули на C/C++, которые экспортируют API для C# через LibraryImport. Сейчас делаю Window, чтобы иметь полный контроль над процедурой окна. Как закончу, буду писать обработку инпута. Ну хочется мне нативного кода, хочется плюсов, хочется возни с unsafe шарпом.

🟢 Перекатил проект на .NET 10, будем двигать в ногу с платформой. Новые фичи — это имба, особенно когда работал 7 лет на Unity с убогим шарпом. А еще наконец-то выкатили полную поддержку .slnx и теперь перешел на него, красиво оформлено.

🟢 Настроил сборку в одну папку, теперь чище выглядят артефакты. Потом изучу вопрос паблишинга, может есть инструменты для пайплайна, если нет — напишу скрипты на JS или питоне (баш или батники не хочется юзать). Для CLI сделал парсер аргументов и абстрагировал это командами, получилось удобнее, чем у всратых решений из гитхаба. Сделал тестовую сборку проекта в двух конфигурациях — это следующий большой этап разработки. Пока руки ленятся туда лезть, потому и начал писать нативные модули, чтобы заниматься чем-то веселым.

В общем как-то так. Заряжен как никогда, куча идей, осталось настроиться на завершение этапа окружения. Считаю, что важно сейчас не рендеринг, а именно то, как будет строиться рабочий процесс и масштабируемость.

⚙️Log #27

Столько разных идей и вдохновений на архитектуру движка!

Расскажу о них чуть позже, нужно все мысли привести в порядок, что-то попробовать реализовать в черновом состоянии, а что-то допилить до MVP.

Держите пока что первую версию внешнего вида сайта с документацией к движку. Решил отвлечься и заняться монкей работой, поэкспериментировал с .md файликами для описания доков. Может потом сделаю еще и отдельную страницу для блога и дев отчетов и переедем туда, так как телега жестко ограничивает в этом деле.

В этом году если все пойдет по плану, то дам в общее пользование, пощупать двигло, поклепать флепи бердов и дудл джампов :D

⚙️Log #28

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

Пока этим занимался, решил сделать основой сайта «борду» в стиле блюпринтов - мне это кажется современным визуальным подходом.

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

Вся документация также будет в виде раскиданных папок и файлов на борде: их можно раскрывать, вытаскивать, и они будут оставаться в открытом виде перед глазами. А так как движок будет поддерживать WASM, примеры кода можно будет встраивать прямо в эту борду и на ней же смотреть, как они отрабатывают.

Надеюсь, в течение марта смогу определиться и зафиксировать идеи по ядру. Тогда закину статейку (на НАШЕМ блоге по движку) со всеми мыслями, чтобы те, кто интересуется разработкой, понимали, как оно будет работать.

⚙️ Log #29

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

За это время начал собирать собственную UI-систему и первый прототип встроенного редактора.

🟢 В движке появился retained-mode UI-системы, ориентированной одновременно на игровые интерфейсы и внутренние инструменты.

Мне всё ещё не хочется использовать System.Drawing, WinForms, WPF или другие готовые решения. Интерфейс должен полностью отрисовываться собственным OpenGL-рендерером.

Разметка описывается через UXML, стили - через CSS-подобный синтаксис, а расчётом flex-layout занимается Yoga. В итоге получается что-то близкое к вебу по подходу.


🟢 Параллельно появилось понятие GameScreen.

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

Это позволило наконец собрать первый прототип runtime-редактора, который включается по F12.

Мне по-прежнему нравится идея, что редактор не должен быть основой движка или отдельным огромным приложением. Поэтому сейчас он реализован как обычный EditorLayer : AppLayer, который подключается поверх работающей игры.

⚙️ Log #30

Попутно изучению и применению на практики, я веду для себя шпаргалку по работе с OpenGL. В моем случае стек C# + Silk.NET.

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

Возможно потом разверну на своем сайте эту страницу, может будет кому-то полезно)

⚙️ Log #31

Знакомьтесь, это Сюзанна)

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

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

Ну и захватил этап создания и инициализации движка. Вроде получилось лаконично и крассиво)

⚙️ Log #32

Сегодня решил поиграться с системами освещения. Реализовал Point и Spot. Все параметры изначальные берутся с Blender.

Идея собственно какая? Я сечас собираю локацию в Blender, выставляю там камеры, точки освещения, их виды и параметры, расставляю какие-то объекты, добавляю на них кастомные компоненты (сделал адон для Blender), после экспорт сцены и движок уже рендерит это так, как было в Blender.

+ Затестил физический движок Jitter2. Мне понравилась его простота, оставлюсь на нем, до первых ограничений или проблем при работе с ним.

+ Сделал тестовое управление персонажем от первого лица