Миша пишет движок

Кастомные шейдеры

Sun, 15 Feb 2026 00:00:00 GMT

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

В Pixi для решения этой задачи можно использовать фильтры. Это такой механизм для добавления пост обработки. Фильтры влияют не только на сам объект, но и на всех его потомков. Именно поэтому я вносил доработки в рендерер и добавлял дерево, чтобы при использовании фильтров использовать это преимущество.

На практике, когда я собрал первый черновик и пошел тестировать – ничего не заработало. Как я выяснил позднее, фильтры плохо дружат со слоями, которые я использовал чтобы контролировать порядок отрисовки. Я завел issue на гитхабе Pixi, чтобы убедиться, что я понимаю все правильно и спустя месяц получил ответ мол, да это такое ограничение у RenderLayers.

Раздосадованный я продолжил искать другие варианты и остановился на мэшах. Это более низкоуровневый вариант отображения графики чем спрайт, фигура или текст, которые я уже добавил в движок. Тут нужно самостоятельно описывать вершинный и фрагментный шейдеры, задавать текстуру через uniform переменную и все что еще потребуется для отрисовки.

По итогу я реализовал новый компонент Mesh, который очень похож на уже существующий Sprite, за тем исключением, что через поле material ему можно указать скрипт с шейдерами для отрисовки. От фильтров я тоже полностью отказываться не стал и оставил возможность повесить фильтры на все сцену целиком для случаев если захочется добавить эффекты вроде CRT. И то, и другое можно создавать из шаблонов через редактор.

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

Полагаю, что с отрисовкой я пока что закончил, поскольку делать одно и то же несколько месяцев – сильно утомляет. Вернусь к улучшению редактора, к тому же хочется посмотреть как с моими задачами справится Codex.

Смотреть видео

Итоги 2025 года

Tue, 30 Dec 2025 00:00:00 GMT

Раньше я не подводил итоги года, но после того как я перестал вести доску задач (из Trello меня погнали, потом и из Notion) я решил, что заметок в Телеграме мне достаточно (надежное же место, да?) и лучше я буду детальнее описывать над чем работаю в свой канал. В целом, за год получилось сделать довольно много крупного и полезного.

По задачам

– Мультивыбор элементов в редакторе: выделение рамкой, выбор с шифтом в проводнике. Копирование, удаление и вставка выборки по ctrl+C, ctrl+V, ctrl+X. Очень долго этого не хватало, любое серьезное редактирование сцены превращалось в кошмар, из-за необходимости работать с каждым объектом по отдельности.

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

– Переработал жизненный цикл сцен и систем. Ранее под каждую сцену нужно было собирать свой список систем, дублировать все, включая рендерер, физику и обработку ввода. Теперь список систем общий на всю игру, есть системы которые живут и пересоздаются в рамках каждой сцены, а есть глобальные, которые живут пока запущена игра. Стало проще шарить состояние игры между сценами/уровнями и не надо копипастить длинные списки систем под каждую сцену.

– Одна из самых крутых задач на мой взгляд – это декораторы для регистрации игровых систем и компонентов. Ранее нужно было писать много кода, чтобы сообщить редактору как отображать кастомные компоненты и системы. А при изменениях нужно было каждый раз перезагружать редактор. Теперь через декораторы редактор самостоятельно собирает по игре все с чем умеет работать. Все изменения в коде редактор подхватывывает автоматически и отображает без необходимости перезапуска.

– Cнова переписал рендерер. На этот раз на Pixi.js. Надеюсь что в ближайшие годы я больше не буду его переписывать, а только расширять. Помимо спрайтов научился рисовать различные геометрические фигуры и bitmap текст. На подходе удобный способ добавлять шейдеры. Сам рендеринг за счет более подходящей библиотеки для 2D стал быстрее да и бандл немного уменьшился.

– Ну и доработки по Transform-у о которых я рассказывал в последний раз.

По джемам

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

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

Что было еще

Сходил на подкаст к @xufostation. Поговорили про разработку моего движка и джемы. Опыт интересный хоть и было немного не по себе, будучи ноунеймом идти на подкаст. В очередной раз спасибо Сергею, он и с докладом на Holy мне очень помог в свое время, и новых людей сюда привел.

Планы

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

Вдобавок ко всему в движке не хватает сущности, которой можно было бы описать объекты, которые не являются акторами, но которые можно к этим акторам привязать. Это различные предметы, квесты, способности и тому подобное. Все это хочется описывать в редакторе, а не хардкодить портянки объектов в коде.

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

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

Строим дерево сцены для отрисовки

Mon, 29 Dec 2025 00:00:00 GMT

После переписывания рендеринга на Pixi.js, в планах было добавить возможность удобно писать кастомные шейдеры или быстро применять встроенные в Pixi фильтры вроде размытия на один или группу акторов. Повесить фильтр/шейдер на один объект несложно, а вот с группами возникла проблема.

Хоть сцена и акторы в движке представляют собой дерево, при отрисовке через Pixi я собирал все объекты для отображения в один плоский список. Вложенность при отрисовке мне была не нужна и так было проще сортировать спрайты по слоям и координатам чтобы те, что отображаются ниже на экране, перекрывали спрайты выше.

Переделать список на дерево для Pixi оказалось несложно, так как Pixi сцена тоже дерево, а для работы со слоями и сортировкой в последнем мажоре рендерера есть Layer API. Более серьезная проблема меня ожидала в текущей реализации компонента Transform.

Transform компонент отвечает за все трансформации актора в пространстве – смещение по координатам, поворот и масштабирование. Чтобы дочерние акторы учитывали смещение родителя, я в компоненте оставлял ссылку на такой же компонент родительского актора и считал общее смещение складывая родительские значения с дочерними. Это работало для очень простых сценариев, но если к примеру повернуть родителя, то дочерний объект повернется не относительно родителя как должно быть, а относительно своей оси.

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

В результате я полностью переписал Transform компонент и начал использовать матрицы 3 на 3. Матрицы позволяют описать все преобразования по смещению, повороту и масштабированию объекта так, что при перемножении матриц дочернего объекта и родителя мы можем получить итоговые значения по всем преобразованиям.

Вся работа с матрицами спрятана под капот компонента, поэтому снаружи достаточно обращаться к привычным полям вида x, y, rotation и тд.

const transform = actor.getComponent(Transform);

// абсолютные координаты актора в мировом пространстве
console.log(transform.world.position.x, transform.world.position.y);

// относительно координаты актора в пространстве родителя
console.log(transform.local.position.x, transform.local.position.y);

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

Смотреть видео

Перемещение камеры и зум с помощью трекпада

Sat, 15 Nov 2025 00:00:00 GMT

Спустя месяц отдыха пора приниматься за работу.

Начал с простой фичи, которой давно не хватало – возможности двигать камеру и менять зум используя трекпад или колесико мыши, а не только по выбору отдельного инструмента в тулбаре. Сделал очень просто с помощью события wheel. Событие похоже на скролл, но в отличие от него срабатывает на областях, которые нельзя прокручивать, что мне и было нужно для моего канваса. При жестах зума на трекпаде, в объекте события автоматически выставляется флаг ctrlKey, поэтому одним обработчиком получается реализовать зум и для трекпада и для колесика мыши с зажатой клавишей Ctrl.

Теперь редактировать сцену стало удобнее. При демонстрации доработки жене я получил ожидаемый вопрос: "А куда смотреть? Что изменилось?". Очередная функция, которая ожидается в редакторе по умолчанию и заметить можно разве что ее отсутствие.

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

Смотреть видео

Финал Ludum Dare 58

Tue, 07 Oct 2025 00:00:00 GMT

Третий день и окончание людума. В этот раз на реализацию механик ушло больше времени чем раньше, но как будто первоначальную задумку особо и не порезали.

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

Над балансом еще нужно поработать, потому что в какой-то момент можно пройти игру в афк режиме.

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

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

Ссылка на игру: https://ludum-dare-58.netlify.app/ (можно с телефона, но лучше в вертикальном положении, в горизонтальном верстка едет)

Смотреть видео

Второй день Ludum Dare 58

Mon, 06 Oct 2025 00:00:00 GMT

Второй день людума. До рисования дойти не успели, но на экране появилось определенно больше кругов и прямоугольников.

За сегодня добавили разные виды оружия: дробовик, самонаводящуюся ракету, рикошет и тд. Добавили усиление врагов со временем и увеличение частоты спавна.

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

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

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

Смотреть видео

Первый день Ludum Dare 58. Тема Collector

Sun, 05 Oct 2025 00:00:00 GMT

Первый день людума. Тема Collector.

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

Сегодня сделали спавн противников, их перемещение до сокровищ, механику воровства и боевую систему. Персонаж стреляет автоматически по случайному врагу. Если вора поймать и убить, то из него выпадают монеты, которые можно вернуть в казну. За каждого поверженного противника дается опыт, а при получении нового уровня появляется меню выбора улучшений (пока выбирать не из чего и единственный вариант улучшения – только качать основную атаку). В общем, нашел повод сделать клон Vampire Survivors.

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

Смотреть видео

Новый рендерер: фигуры и текст

Sat, 27 Sep 2025 00:00:00 GMT

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

В дополнение к этому избавился от костылей в редакторе. Старый рендерер умел рисовать только спрайты, поэтому для рамок выделения или сетки приходилось наворачивать дополнительные слои: грид рисовал через css градиент, а прямоугольники для выделения объектов – через канвас. Теперь для всего используется pixi рендерер.

На следующей неделе очередной людум, поэтому придется взять паузу. Из того что еще нужно сделать: добавить фильтры с пользовательскими шейдерами, а также решить, что делать с освещением. На three js я использовал решение из коробки, а на pixi такого нет. Нужно что-то сообразить либо найти готовый плагин.

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

Смотреть видео

Переход с Three.js на Pixi.js

Sun, 17 Aug 2025 00:00:00 GMT

После череды полезных задач захотелось заняться тем чего душа давно просит, а именно – снова переписать рендерер. На этот раз с ThreeJS на PixiJS.

Я уже давно для себя решил, что движок делается исключительно под 2D иначе мне и на пенсии времени не хватит чтобы привести его в более менее солидное состояние. ThreeJS удобный, есть документация, да и исходники достаточно понятные, но работать с 2D через абстракции разработанные для отрисовки трехмерной графики оказалось избыточным. Кто бы мог подумать.

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

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

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

Смотреть видео

Генерация скриптов через редактор

Fri, 11 Jul 2025 00:00:00 GMT

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

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

Файлы создаются по шаблону. Есть дефолтные, но при желании можно указать свои через конфигурационный файл в проекте. Шаблон – это просто функция, которая принимает имя класса, а возвращает строку, поэтому накрутить там можно все что угодно.

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

Смотреть видео

Автоподключение скриптов в редакторе

Fri, 27 Jun 2025 00:00:00 GMT

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

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

К счастью, подобный механизм можно реализовать на уровне исходного кода игры, а не движка. К примеру, если игра собирается через Webpack, то можно воспользоваться функцией require.context, которая позволяет по регулярке импортировать все нужные модули и затем передать все что удалось найти в конструктор класса Engine. В Vite для тех же целей есть import.meta.glob.

function importAll(context) {
  const modules = context.keys().map(context);

  // ожидаем что система/компонент доступны через дефолтный экспорт в скрипте
  return modules.map((module) => module.default);
}

const components = importAll(require.context('./', true, /.component.ts$/));
const systems = importAll(require.context('./', true, /.system.ts$/));

const engine = new Engine({
  components,
  systems
});

engine.play();

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

// в упрощенном виде выглядит примерно так:
const virtualModules = new VirtualModulesPlugin({
  './virtual-entry.ts': () => `
  function importAll(r) {
    r.keys().forEach(r);
  }

  importAll(
    require.context('./', true, /\.system\.ts$/),
  );
  importAll(
    require.context('./', true, /\.component\.ts$/),
  );
  `
});

webpack({
  entry: {
    extension: './virtual-entry.ts'
  },

  output: {
    libraryTarget: 'umd',
    library: '[name]'
  },

  plugins: [virtualModules]
});

Код проекта все еще собирается отдельным скриптом и подключается в редактор как UMD модуль (после загрузки и исполнения скрипта его экспорт можно достать из window). Так сделано, потому что при запуске редактора, Webpack собирает только код игры, а клиентский код редактора бандлится заранее.

Webpack Dev Server при любых изменениях в коде проекта производит пересборку виртуального модуля и через апи электрона посылает событие в редактор. В ответ на событие, я загружаю скрипт сборки по новой и делаю ререндер панели инспектора. Благодаря этому, все обновления кода систем и компонентов сразу же отображаются в редакторе без обновления страницы и потери состояния интерфейса.

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

Убираю бойлерплейт в движке

Sun, 08 Jun 2025 00:00:00 GMT

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

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

class Health {
  points: number;

  constructor(config) {
    this.points = config.point;
  }
}

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

const health = {
  title: 'Health,
  fields: [
    {
      name: 'points',
      title: 'Points',
      type: 'number',
    },
  ],
  getInitialState: () => ({
    points: 100,
  }),
};

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

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

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

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

Такого поведения вполне можно добиться, но нужно решить несколько задач:

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

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

@DefineComponent({
  name: 'Health',
})
class Health {
  @DefineField({ initialValue: 100 })
  points: number;

  constructor(config) {
    this.points = config.points;
  }
}

Переходим к автоматическому подключению. Для сборки информации о проекте под капотом редактора я использую webpack dev сервер, но теперь вместо статической точки входа, я сканирую определенные каталоги проекта по glob паттерну и выгребаю все что есть. Webpack позволяет указать несколько точек входа и собрать их в один бандл, который затем я подключаю в редакторе.

const widgetEntries = fastGlob.globSync(
  [
    `${config.systemsDir}/**/*.ts`,
    `${config.componentsDir}/**/*.ts`,
    `${config.behaviorsDir}/**/*.ts`
  ],
  { absolute: true }
);

// далее передаем widgetEntries в entry поле webpack конфига

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

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

Рефакторинг жизненного цикла сцен

Tue, 13 May 2025 00:00:00 GMT

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

Какие были проблемы

Системы были привязаны к сценам и уничтожались при их смене. Это не позволяло пошарить состояние между разными экранами игры и за неимением других возможностей я складывал данные в window или local storage. К примеру, в новогоднем мини-квесте я так хранил инвентарь с предметами.

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

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

Что сделал

Чтобы решить все проблемы разом я:

Вытащил системы на общий уровень
Списки акторов вернул обратно в сцены
Уровни удалил

Системы разделил на два типа: WorldSystem и SceneSystem. Первые являются синглтонами, которые сохраняют состояние при переходах между сценами, а вторые инстанцируются под каждую сцену отдельно.

Как следить за изменениями

Для отслеживания переходов между сценами я добавил методы:

  onSceneLoad(scene: Scene): Promise<void> // загрузка ресурсов: текстуры, звуки и тд.
  onSceneEnter(scene: Scene): void // активация сцены
  onSceneExit(scene: Scene): void // выход со сцены, без уничтожения
  onSceneDestroy(scene: Scene): void // сцена полностью уничтожается

Для World систем есть еще пара методов:

  onWorldLoad(world: World): Promise<void> // загрузка глобальных ресурсов. К примеру, бандл с интерфейсом игры.
  onWorldReady(world: World): void // глобальные ресурсы загружены
  onWorldDestroy(world: World): void // полное завершение игры

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

Как управлять переходами

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

type LoadSceneEvent = WorldEvent<{
  id: string;
  autoEnter?: boolean;
  autoDestroy?: boolean;
}>;
type EnterSceneEvent = WorldEvent<{
  id: string;
  autoDestroy?: boolean;
}>;
type ExitSceneEvent = WorldEvent<{
  autoDestroy?: boolean;
}>;
type DestroySceneEvent = WorldEvent<{ id: string }>;

Флаги autoEnter и autoDestroy для автоматического перехода или уничтожения сцен. По умолчанию, оба в true. Если выключить autoEnter, то сцена загрузится, но перехода не произойдет. Полезно если потребуется сцены предзагружать заранее.

Зачем я это делал

Проектирование API библиотеки для меня – это одна из самых сложных задач. При написании бизнес логики, главное чтобы работало так как хочет заказчик, а на удобство использования кода можно хоть и не всегда, но закрыть глаза. Ну не будет никто эту функцию использовать кроме тебя, зато работает. При разработке библиотеки, ее API – это и есть продукт, а заказчики – это те, кто будут им пользоваться. Или не будут если оно будет сложным и неудобным.

Результаты Ludum Dare 57

Wed, 30 Apr 2025 00:00:00 GMT

Опубликовали результаты прошедшего людума, 268 место в общем зачете из 1181 игры. В прошлом году были 700 и 400 места, поэтому прогресс есть. В категории Fun получилось попасть в топ-100, что для меня является самой важной категорией. Закономерностью это пока не назовешь, но будем и дальше работать над улучшением результата, пусть и не в этих циферках, а хотя бы в своих собственных глазах.

Для того чтобы в твою игру поиграли после публикации, нужно оценивать чужие игры. Всего я поиграл в 42 игры и на каждую старался писать фидбек.

При оценке чужих игр понимаешь насколько важно чтобы управление было интуитивным, а игра раскрывалась в первые минуты. Иначе ты сильно рискуешь потерять потенциального игрока, который задушится уже на главном меню и с отзывом "Very nice art! Great jam entry!" закроет вкладку и пойдет дальше.

Среди игр, которые мне довелось посмотреть, было немало классных проектов. Отдельно я бы отметил The Void и Scavenger Deep за супер крутой пиксель арт и общую атмосферность.

Еще одна игра под названием Podvodsk привлекла мое внимание знакомым графическим стилем. Как оказалось, эти же ребята 5 лет назад сделали на людуме LooPatHero, которая в последствие была доработана и переименована в LoopHero. Ее достаточно высоко оценили многие игровые журналы и она была номинирована на звание лучшей инди игры на VGA в 2021 году.

<img src="https://s3.ru1.storage.beget.cloud/4d7b85999aed-legendary-azamat/blog/images/2025-04-30/1.avif" alt="Результаты голосования"

Сходил на подкаст Xufostation

Mon, 28 Apr 2025 00:00:00 GMT

Сходил на подкаст к @xufostation. Поговорили про то, чем я занимаюсь, с чего все начиналось, про геймджеймы и про геймдев в целом.

Послушать можно здесь: https://t.me/xufostation/992.

Подводим итоги Ludum Dare 57

Sun, 13 Apr 2025 00:00:00 GMT

Ну что ж, немного передохнул — пора подводить итоги прошедшего гейм-джема.

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

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

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

Ну и, как и в прошлый раз, движок всё ещё требует много boilerplate кода на каждую систему или компонент — это тормозит.

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

Совсем не жалею, что начал регулярно участвовать в Людумах. Чтобы развивать инструменты в правильном направлении — ими нужно пользоваться. Да и просто приятно иметь в коллекции ещё одну завершённую игру, пусть и небольшую.

PS: На скриншоте — как игра выглядит в редакторе. Красные прямоугольники — это те самые края-убийцы, а фиолетовая полоса слева убивает всех недобитых противников для очистки ресурсов.

<img src="https://s3.ru1.storage.beget.cloud/4d7b85999aed-legendary-azamat/blog/images/2025-04-13/1.avif" alt="Скриншот игры в редакторе"

Финал Ludum Dare 57

Tue, 08 Apr 2025 00:00:00 GMT

Закончился третий день. Игру доделал и загрузил на сайт людума. До дедлайна оставалось два часа, уложился прям как раз.

Нарисовал графику, настроил звуки, которые скачал с freesound.org и собрал два уровня. Сделал не все что планировал, как обычно хотелок было очень много. Каждый день приходило очередное осознание, что успею сделать, а что нет, поэтому резал как мог.

В целом результатом доволен.

Поиграть можно тут: https://ludum-dare-57.netlify.app/ Исходники тут: https://github.com/michailRemmele/ludum-dare-57

Подробнее о впечатлениях и результатах напишу позже.

PS: На телефоне игра работает, но текущий вариант управления не очень удобный и я не смог побороть выделение текста по долгому нажатию на айфонах. Свойство "user-select: none" не помогло, возможно как обычно приколы Safari.

Смотреть видео

Второй день Ludum Dare 57

Mon, 07 Apr 2025 00:00:00 GMT

Второй день.

Добавил стреляющих противников. Есть стационарные, которые спавнятся при приближении и стреляют очередями. Есть плавающие, которые после того как попадут в поле зрения, двигаются со скоростью скролла камеры, поэтому просто так от них избавиться не получится. Дополнительные пираньи теперь выдаются не просто так, а в награду за получение уровня. Уровень можно набить поедая других рыб. Также, добавил подсчет очков с сохранением прогресса. Информация складывается в local storage и при ее наличии, в меню вместо кнопки старта будет кнопка выбора уровня.

Порисовать успел всего часок. Добавил спрайт пираньи с анимациями атаки, получения урона и смерти. Гневное рыло рыбы перед атакой срисовал со своей собаки. У меня корги если что.

Вечерние часы проходят не очень продуктивно, к концу дня голова начинает плыть и я могу долго залипать в одно и то же место. С утра до ночи код писать тяжко.

Завтра последний день. Буду преимущественно рисовать арт и собирать уровни. Ну и дополнительные механики попробую добавить если успею.

Смотреть видео

Первый день Ludum Dare 57

Sat, 05 Apr 2025 00:00:00 GMT

Закончился первый день людума. Тема на этот раз – Depths.

Я хотел сделать сайд-скроллер, поэтому, недолго думая, решил, что игра будет про рыб – чтобы под тему подходило. Сейчас на рыб и море это не особо похоже, только если сильно напрячь воображение. Но фон вот синий, например.

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

За сегодняшний день сделал логику скролла экрана с ограничениями по краям. Если выйти за пределы экрана, то сначала нанесется предупреждающий урон, а затем все заплутавшие рыбы будут уничтожены. Пираньи при контакте с другими рыбами начинают кусаться с некоторым кулдауном. Также добавил спавнеры рыб, в которых можно указать, кого, сколько и с какой частотой нужно создать, и по какой траектории направить. Есть рыбы, которые просто плывут и терпят, а есть рыба-меч, которая наносит урон если подъехать к ней не с той стороны.

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

Смотреть видео

Подготовка к Ludum Dare 57

Fri, 04 Apr 2025 00:00:00 GMT

Завтра пройдет очередной Ludum Dare. Это всемирный челлендж, когда за несколько дней нужно написать игру на определеную тему. Тема объявляется в начале эвента.

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

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

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

В дополнение к этому я добавил инструмент для работы с гугл аналитикой. Хочу разметить игру кастомными событиями чтобы понимать как вообще в игру играют: пройдут ли тот или иной уровень, смогут ли использовать какой-то предмет и так далее

Поглядим что получится в этот раз, буду делиться успехами по ходу работы.

Смотреть видео

Система звука

Fri, 21 Mar 2025 00:00:00 GMT

Ну чтож, передохнул – пора возвращаться к работе над звуковой системой. Для работы со звуком в браузерах существует Web Audio API. Апи, как оказалось, уже из коробки умеет многое: есть пространственный звук, фильтры и опция выноса звука в отдельный воркер. Похоже, даже изобретать ничего не придется – достаточно написать удобный фасад, чтобы интегрировать звук в движок и редактор.

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

Работа с Web Audio API сводится к составлению графа, где узлы – это источники звука, эффекты (например, фильтрация или изменения громкости) и выходной узел куда подается итоговый микс. Все довольно удобно и логично. Документация на MDN подробная, есть примеры на GitHub. Огорчает разве что отсутствие отладочных инструментов на уровне браузеров. В Chrome они доступны только в виде расширений, а в Firefox вкладка в дев тулзах для отладки когда-то была, но, похоже ее уже убрали. Из-за этого я испытываю некоторую тревогу: справляется ли сборщик мусора с отработанными звуками или нет.

Собрал небольшую демку на базе последней игры, которой я занимался. Поскольку в работе с аудио я полный профан, было довольно тяжело подобрать подходящие звуки, особенно музыку. В итоге трек сгенерировал через Suno AI, а остальные звуки взял с freesound.org. Поэтому впервые на канале видос к посту со звуком. Предыдущие видео, где я случайно забыл отключить запись микрофона и дышал в него пока делал запись экрана – не в счет.

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

Смотреть видео

Про переводы книг по геймдеву

Wed, 05 Feb 2025 00:00:00 GMT

Пока пробираюсь через главу о работе со звуком в книге Game Engine Architecture, хочу поделиться своим недовольством по поводу качества перевода литературы из области геймдева и IT в целом.

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

Недавно я зашел в книжный поглазеть на обложки и удивился, как много книг появилось по игровой тематике. В большинстве случаев издателем является Бомбора – та самая, что занималась переизданием Кровь, пот и пиксели Шрайера после шквала критики первоначального перевода. Второй вариант я читал и мне он понравился, так что, решив, что издательство заботится о качестве, я купил у них Пиксели! Курс по пиксельной графике и анимации для новичков.

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

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

Чтобы не быть голословным, вот типичный абзац, который оставил меня в полном недоумении:

Оригинал: "Add some simple shading details in the clouds and grass. You can add more details if you prefer but backgrounds are often looped seamlessly so adding more detail can often catch the viewers eye and take away from the entire experience by feeling repetetive."

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

О какой обводке идет речь – мне так и не стало понятно.

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

Копировать, вырезать и вставить

Sun, 02 Feb 2025 00:00:00 GMT

Январь позади, а я уже закончил первую большую задачу – добавил операции: копировать, вырезать и вставить. Теперь можно скопировать или перенести выбранные элементы в произвольное место. Ранее операции совершались только над одним элементом за раз, а возможности переноса не было совсем, только создание дубликата на том же месте.

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

И это далеко не все проблемы с которыми я столкнулся. При вставке в место, где уже есть элемент с таким именем, нужно генерировать новое имя для копии. Для этого пришлось перебирать все элементы в точке назначения, чтобы исключить возможность совпадения. А при множественном переносе нужно учесть, что по нажатию на ctrl+Z все должно вернуться на свои места.

Очередное улучшение сделало редактор значительно удобнее. Всего на год я запланировал как минимум 4 задачи для движка и редактора, которые я посчитал самыми важными. Следующая на очереди – звук.

Смотреть видео

Мультивыбор элементов в проводнике

Fri, 10 Jan 2025 00:00:00 GMT

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

Начал с задачи попроще – в редакторе. Сейчас при создании уровня нельзя выбрать более одного актора. Если нужно передвинуть группу объектов на сцене или удалить лишние, то делать это придется долго, редактируя один элемент за другим. Нужно добавить возможность выбирать несколько сразу.

Компонент дерева из библиотеки Ant Design поддерживает мультивыделение, но пришлось отрефакторить код вокруг него, поскольку раньше редактор был заточен под работу только с одним выбранным элементом. А вот для окна просмотра уровня из коробки ничего нет, пришлось писать самостоятельно. Добавил выделение рамкой и по клику мыши с зажатой клавишей Shift. Как оказалось в нативных событиях мыши есть такие поля как shiftKey, altKey и тд. Удобно.

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

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

Смотреть видео

Как я делал игру на новогодний конкурс

Tue, 31 Dec 2024 00:00:00 GMT

Идея

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

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

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

Fallout 1

Планируем фронт работ

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

На очередной прогулке с собакой я составил следующий список задач:

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

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

Первые шаги

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

Взаимодействие с объектами сцены я реализовал через коллизии. Отслеживая столкновения курсора и интерактивных объектов, я проверяю наличие компонента Interactable и смотрю на поле с действием, которое этот объект предполагает. Зная контекст, по клику мыши я отправляю соответствующее событие: переход в другую комнату, поднятие предмета и так далее.

Персонажа временно взял из другой своей игры, остальное - заглушки в виде цветных прямоугольников и кружков

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

Курсор

Добавляем инвентарь

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

Братья Пилоты

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

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

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

Переходы между комнатами и сохранение прогресса

Комнаты я сделал отдельными уровнями, поэтому за раз на экране отображается только один, а переходы происходят по клику на дверь. Чтобы переходы не были такими резкими, добавил плавное затемнение экрана. Никаких красивых переходов между сценами у меня в движке нет, поэтому затемнение это обычный div с разными классами состояниями.

При переходе с уровня на уровень, движок не сохраняет своего состояния и все системы полностью сбрасываются. Это проблема, которую нужно будет решать отдельно, но а сейчас за неимением других опций я сложил все в один объект в window, c последующим отложенным сохранением в Local Storage. Туда попали последние координаты персонажа, список всех предметов и их текущих состояний, чтобы при перезапуске игры можно было восстановить последнее состояние. Сохранение происходит в определенным контрольных точках когда происходит хоть сколько-нибудь значимое событие: успешное взаимодействие с предметами или переход в другую комнату.

Смотреть видео

Переход между комнатами

Квесты

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

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

Смотреть видео

Сбор предметов

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

Смотреть видео

Нарисованный контур отображается на отдельном холсте канваса, решение буквально в несколько строчек

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

Смотреть видео

Квест с аркадным автоматом

Рисуем

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

Финальная версия игры

Результат

Игру я задеплоил через Netlify и ссылку отправил 25 числа в день дедлайна в той же гугло форме через которую собирались новогодние рисунки. Ну и чтобы избежать недопонимания сразу же написал в предложку в телеге с пояснениями. И стал ждать.

29 декабря Денис начал подводить итоги конкурсов и в самом конце показал мою игру в качестве бонуса. Неожиданно после открытия ссылки с игрой у стримера крашнулась трансляция на несколько минут и чат сразу же заподозрил наличие майнера, но трансляция ожила и дальше все прошло хорошо. Единственная проблема - почему-то текст в игре, который должен был быть темным, посветлел и на сцене с аркадным автоматом Денис долго не мог найти кнопку "Играть". Мою игру тестировало человек 5 включая меня и ни у кого такой проблемы не было. Подозреваю, что проблема заключалась в расширении хрома, которое могло инвертировать цвет текста. Насколько я знаю, такие расширения могут ставить если очень хочется иметь темную тему на сайтах, где ее нет.

Денис запустил игру

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

Спасибо что уделили внимание моей статье и с наступающим вас новым годом!

Коллизии повернутых прямоугольников

Wed, 20 Nov 2024 00:00:00 GMT

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

Когда-то давно я работал над графических редактором для построения электросхем в браузере. У меня была задача реализовать авторасстановку элементов так, чтобы они не перекрывали друг друга. Каждая деталь на схеме могла сопровождаться набором картинок, изображающих изделие с разных ракурсов и чтобы пользователю редактора не нужно было все расставлять в ручную, заказчик попросил добавить автоматизацию. Также, нужно было предусмотреть функцию авторасстановки для уже существующих электросхем, для элементов, которые были расставлены неаккуратно.

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

Один из популярных алгоритмов построен на теореме о разделяющей оси (плоскости для 3D). Суть в том, что фигуры не пересекаются если существует хотя бы одна ось, при проекции на которую, полученные отрезки не пересекаются. В качестве осей часто предлагается использовать нормали к граням тестируемых многоугольников. Подробнее про реализацию можно почитать здесь если интересно.

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

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

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

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

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

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

Смотреть видео

Оптимизируем систему обнаружения коллизий

Sun, 10 Nov 2024 00:00:00 GMT

Во время рефакторинга системы обнаружения коллизий, я сделал несколько замеров производительности, чтобы выявить наиболее медленные места. Ранее я ни разу этим не занимался, как написал систему, так она и работала все это время. Честно говоря, тогда я даже слабо понимал за счет чего выбранные алгоритмы работают эффективно, поэтому легко мог что-то проглядеть и накосячить.

Оказалось, что самая медленная часть системы была не в тестировании пар и не в широкой фазе, а на этапе подготовки данных. При изменении координат объекта, нужно внести изменения во все структуры данных, которые используются под капотом системы коллизий для представления объекта. В частности, нужно обновить границы объекта в отсортированных списках, которые используются на широкой фазе. Тут я видимо устал, когда писал эту логику несколькими годами ранее и не придумал ничего лучше, чем проходиться по всему списку и искать запись, соответствующую объекту и вносить изменения. Отсюда вылез N^2 на такой простой задаче. Для устранения проблемы я завел мапу, в которой, по идентификатору актора, дублируется запись из сортировочного списка. Ссылка на запись в мапе и в списке одна и та же, поэтому перебирать список больше не надо, достаточно обновить нужное поле с координатами.

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

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

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

Смотреть видео

Широкая фаза обнаружения столкновений

Sat, 26 Oct 2024 00:00:00 GMT

Как я уже писал выше, обнаружение коллизий между объектами – задача ресурсоемкая. Если попарно проверять все объекты сцены друг с другом на пересечение, то это займёт квадратичное время.

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

Популярной техникой для широкой фазы, является алгоритм Sweep and Prune. Идея заключается в том, чтобы построить проекции объектов на одну из координатных осей, отсортировать полученные границы объектов и затем перебрать отсортированный список, фиксируя все пересечения проекций. Таким образом, нам не придется проверять объекты каждый с каждым, поскольку встретив закрывающую границу проекции объекта, далее его можно не рассматривать. Что касается сортировки, то алгоритм опирается на то, что между итерациями игрового цикла, объекты не сильно меняют свои позиции, а значит массив проекций будет всегда почти отсортирован. Сортировка, которая лучше работает на частично отсортированном массиве будет выдавать сложность близкую к O(n). Например, сортировка вставками.

На самом деле я реализовал этот алгоритм уже довольно давно, но рассказывал про него только на своем выступлении на HolyJS , поэтому думаю стоит упомянуть об этом здесь отдельно перед тем как двигаться дальше. А двигаться есть куда, поскольку недавно я заметил, что из-за косяков в реализации алгоритма я избавился от N^2 не до конца. О своих ошибках я расскажу дальше.

<img src="https://s3.ru1.storage.beget.cloud/4d7b85999aed-legendary-azamat/blog/images/2024-10-26/1.avif" alt="Схема Sweep and Prune алгоритма"

Возвращаюсь к физике движка

Sun, 13 Oct 2024 00:00:00 GMT

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

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

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

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

Я уже начал работать над улучшениями еще до Людума и далее планирую продолжать. Как минимум задачи следующие:

возможность поворачивать коллайдеры
поддержка угловой скорости, чтобы при столкновении объекты могли разворачиваться относительно точки приложенной силы
ray casting. Это функция, позволяющая выпустить луч из заданной точки и получить список объектов-попаданий. Полезно для AI или стрельбы в шутерах
упругие столкновения объектов и возможность передачи кинетической энергии
пространственное разделение (spatial partitioning) чтобы оптимизировать количество попарных проверок. Может быть такие оптимизации в небольших играх и не понадобятся, но интересно разобраться, что это за зверь такой + хорошая возможность применить на практике сложные структуры данных

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

Итоги Ludum Dare 56

Thu, 10 Oct 2024 00:00:00 GMT

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

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

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

Шаблонный репозиторий для быстрого старта все еще полезная штука, но оказалось, что стартовая репа для новичка и для людума – это разные вещи. Часть первого дня я потратил на подключение систем и перенос кода, которые я уже писал для прошлых игр. Боевую систему взял для стрельбы башен, систему перемещения для мышей, да и спавн врагов волнами тоже был реализован несколько месяцев назад. Возможно для игровых джемов полезнее создавать максимально толстый репозиторий со всем, что может пригодиться. Хотя даже с тем, что было, получилось сделать игру, которая работает сразу на всех платформах при минимальных затратах на адаптацию верстки.

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

<img src="https://s3.ru1.storage.beget.cloud/4d7b85999aed-legendary-azamat/blog/images/2024-10-10/1.avif" alt="Скриншот игры в редакторе"

Финал Ludum Dare 56

Tue, 08 Oct 2024 00:00:00 GMT

Закончился последний день Ludum Dare. Доделывали игру как могли. Нарисовали башни, подтюнили уровни и добавили оформление: главное меню, лого и различные иконки для интерфейса.

Хотелось добавить в уровни больше декоративных элементов: построек вроде теплицы, грядок и тому подобного, но времени не хватило, поэтому получилось довольно минималистично.

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

Заполнили страничку на сайте: https://ldjam.com/events/ludum-dare/56/long-live-dacha. Теперь надо играть и оценивать другие игры если хотим получить фидбек на свою.

В игру можно поиграть по этой ссылке: https://michailremmele.github.io/ludum-dare-56/

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

Смотреть видео

Второй день Ludum Dare 56

Sun, 06 Oct 2024 00:00:00 GMT

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

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

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

Времени остается все меньше, поэтому костыли становятся все страшнее.

Смотреть видео

Первый день Ludum Dare 56

Sat, 05 Oct 2024 00:00:00 GMT

Прошел первый день Ludum Dare, где пишут игры за несколько дней. Тема 56 людума – "Tiny creatures".

Мы решили делать Tower Defence про дачу, которую надо оборонять от мелких вредителей (грызуны, мб птицы). Идея банальная, но давно хотелось такое написать, плюс все были не против.

За сегодня накидали несколько видов башен: одна стреляет одиночными снарядами, другая по области, а третья как и вторая, но еще и замедляет.

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

Завтра будем делать возможность строительства и апгрейда башен и усиленно работать над графикой.

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

Смотреть видео

Подготовка к Ludum Dare 56

Sat, 21 Sep 2024 00:00:00 GMT

Осталось меньше двух недель до следующего Ludum Dare и я потихоньку готовлюсь. Поскольку джемы проходят в большей степени на энтузиазме и уровень участников очень разный, то ограничений на подготовку практически нет. Разрешается использовать любые инструменты да и в целом врываться с любой кодовой базой.

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

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

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

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

Смотреть видео

Улучшаем работу с шаблонами

Sun, 08 Sep 2024 00:00:00 GMT

Расскажу немного про работу с шаблонами в редакторе.

При создании актора (напоминаю, что актором в моем движке называется любой объект на сцене) из шаблона, копируется вся его иерархия, включая вложенные шаблоны. Зачем это нужно? После создания актора из шаблона его можно кастомизировать, что-то переопределить или добавить дополнительные объекты. Чтобы различать кастомные акторы от наследуемых, каждый актор помечается признаком, указывающим от какого вложенного шаблона он наследуется.

Проблема возникает когда в шаблон нужно добавить новые объекты. Если на сцену ранее уже добавлялись акторы, созданные из этого шаблона, то при изменении структуры шаблона, нужно отыскать все наследуемые акторы и обновить их.

В свое время я не стал этого делать, решив что работа с шаблонами очень уж сложная и лучше не развивать эту историю, а позднее все переписать.

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

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

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

Смотреть видео

Незаметные функции редактора

Mon, 19 Aug 2024 00:00:00 GMT

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

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

Добавил скролл, авто раскрытие родительских нод и переключение вкладки на ту, что соответствует выбранному элементу. Мелочь, но времени на ручные переключения будет тратиться чуть меньше.

Смотреть видео

Восстанавливаем состояние редактора при перезапуске

Fri, 09 Aug 2024 00:00:00 GMT

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

Ludum Dare проходит два раза в год и следующий раз уже не за горами – 4 октября. Самое время вспомнить какие проблемы возникали во время разработки игры на апрельском эвенте.

Одна из таких проблем – при перезапуске редактора сбрасываются все настройки вроде размера сетки, выбранного уровня или открытых табов. Перезапускать его при этом приходится часто. Чтобы созданные для игры компоненты и системы подгружались в редакторе, нужно обновить страницу, поскольку под капотом редактора webpack пересобирает код, который берет из проекта с игрой. Возможно тут можно прикрутить hot module replacement чтобы перезагрузка не требовалась, но даже если редактор был закрыт, хотелось бы продолжить с того места на котором остановился.

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

Другой вариант – хранить состояние в файле. Способ простой и надежный. На нем я и остановился. Написал класс прослойку PersistentStorage, который отдает get, set методы, под капотом хранит все в обычном объекте и периодически пишет изменения в файл через node апишку проброшенную через electron. Далее во всех местах редактора, где было желание прихранить состояние, я добавил обращение к PersistentStorage.

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

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

Смотреть видео

Как не бросить пет-проект

Thu, 06 Jun 2024 00:00:00 GMT

Казалось бы, у пет-проекта должна быть конечная цель. В какой-то момент можно было бы сказать, что я сделал все что хотел, научился тому что хотел, поэтому можно пойти дальше ~~и переписать движок на Rust.~~

Вместо этого я только добавляю себе работы. Например:

В движке нужно доделывать физику
Все еще нету звука
От рендерера на Three.js хочется отказаться и попробовать снова написать свой рендеринг, но уже на WebGPU

А еще есть редактор и там свои проблемы:

В редакторе не хватает инструментов
Нет валидации в формах инспектора
Состояние не сохраняется и при перезапуске нужно натыкивать все по новой

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

Я как будто насоздавал рабочих мест, но сидеть на них буду в одиночку.

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

Было неприятно, когда в конце прошлого года Atlassian заблочил мою учетку с Trello и похерил весь лог работы. Как оказалось они уведомляли меня по почте что аккаунт скоро заблокируют и я потеряю все данные, но я это письмо успешно пропустил, поскольку после сотен писем с заголовком "Taco from Trello" перестал обращать на них внимание. К счастью, по просьбе в поддержку мне дали один день, чтобы все выгрузить и я экспортировал свои доски в Notion. В целом норм.

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

<img src="https://s3.ru1.storage.beget.cloud/4d7b85999aed-legendary-azamat/blog/images/2024-06-06/1.avif" alt="Скриншот доски Notion с задачами"

Добавил параллакс

Mon, 03 Jun 2024 00:00:00 GMT

Недавно добавил параллакс.

Что это вообще такое и как его можно реализовать?

Парралакс в играх – это когда фоновые объекты двигаются с разной скоростью относительно наблюдателя в зависимости от их удаленности. Это дает ощущение объема и картинка выглядит живее.

Реализация может быть очень простой и моя система уместилась в 60 строк кода, а основная часть и вовсе состоит из пары строк вычислений (код немного порезан чтобы было проще прочитать):

function update() {
  const { x: cameraX, y: cameraY } = camera.Transform;

  actorCollection.forEach((actor) => {
    const t = actor.Transform;
    const p = actor.Parallax;

    t.x = p.startX + (cameraX - p.startX) * p.distance;
    t.y = p.startY + (cameraY - p.startY) * p.distance;
  });
}

Для каждого объекта фона, к которому мы хотим применить параллакс эффект, добавляется компонент Parallax со свойством distance. Текущее положение объекта с параллаксом вычисляется относительно его начальных координат, координат камеры и коэффициента distance, который принимает значения от -1 до 1. Если к примеру distance положительный, то объект будет перемещаться вслед за персонажем, поэтому будет казаться, что объект находится далеко от точки наблюдения и чтобы объект пропал из поля зрения нужно потратить больше времени чем когда параллакса нет.

Смотреть видео

О фиксированной частоте обновления физики

Mon, 20 May 2024 00:00:00 GMT

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

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

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

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

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

Смотреть видео

Доработал ИИ призраков

Tue, 14 May 2024 00:00:00 GMT

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

Сейчас времени у меня достаточно, поэтому я решил снова подумать, что с этим можно сделать.

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

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

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

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

Для эффектности я нарисовал анимированные клубы дыма, которые появляются в точках откуда и куда призрак переместился.

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

Смотреть видео

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

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

Смотреть видео

Результаты голосования на людуме

Mon, 06 May 2024 00:00:00 GMT

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

Всего в категории Jam (команда в несколько человек, три дня на разработку и отсутствие серьезных ограничений) было отправлено 1679 игр.

Мы заняли 435-е в общем зачете и 208-е за графику. Довольно далеко от верхушки, но вместо трех дней мы работали над игрой только два (понедельник рабочий) да и опыта у нас особого нет.

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

Так что, пойдет. Будем продолжать и посмотрим как пойдет прогресс.

<img src="https://s3.ru1.storage.beget.cloud/4d7b85999aed-legendary-azamat/blog/images/2024-05-06/1.avif" alt="Результаты голосования на людуме"

Все еще доделываю игру

Wed, 24 Apr 2024 00:00:00 GMT

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

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

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

Теперь если объект с компонентом RigidBody обладает свойством isPlatform и возникает коллизия с другим объектом, вектор движения которого направлен вверх, то такая коллизия пропускается и будет игнорироваться до тех пор, пока объекты не разойдутся в стороны и возникнет событие CollisionLeave.

Напомню, что все обновления можно посмотреть на страничке игре.

Смотреть видео

Оцениваем чужие игры и доделываем свою

Sat, 20 Apr 2024 00:00:00 GMT

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

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

Для того, чтобы игра попадалась на первых страницах сайта ldjam.com тебе нужно играть и оценивать чужие игры. Так ты будешь получать карму и твоя игра будет получать более высокий приоритет. До тех пор, пока кто-нибудь не напишет "Nice game!" и твоя игра снова не улетит в помойку.

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

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

А еще мы накатали большую статью о том как мы делали игру и с какими сложностями в процессе столкнулись. Опубликовали на сайте людума чтобы собрать классов и привлечь еще немного внимания к нашей игре. Прочитать можно тут (на английском): ссылка

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

У странички есть манифест, поэтому игру можно сохранить как пва на домашний экран и играть на телефоне в фуллскрине.

Смотреть видео

Закончили писать игру

Sun, 14 Apr 2024 00:00:00 GMT

Закончили. За два дня мы провели за ноутами по меньшей мере часов 20 с перерывами на покушать и погулять пса.

Я писал код и собирал уровень в редакторе, а Таня нарисовала практически весь арт, кроме персонажей. Их рисовал я.

Старался писать быстро как мог, где можно было наговнокодить – говнокодил, где скопипастить – копипастил.

Не успел прикрутить управление с мобильных телефонов, добавлю чуть позже. Поэтому пока только десктоп.

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

Кажется игра получилась сложноватой. Мне пришлось немного потренироваться прежде чем я научился справляться с лучниками.

Поиграть можно тут: https://michailremmele.github.io/ludum-dare-55/

Смотреть видео

Пишем с женой игру на людум

Sat, 13 Apr 2024 00:00:00 GMT

Собрались с женой писать игру на людум. Тема в этот раз: Summoning.

Брейнштормили идеи пока гуляли с собакой, надумали игру про молодого некроманта. Сам он драться не умеет, зато за него это делают восставшие мертвецы.

Планируем сделать платформер с непрямой боевой системой когда за тебя дерутся поднятые NPC.

При убиении очередного противника опционально можно отпустить текущего подопечного и призвать нового (пехотинца заменить на лучника к примеру).

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

Подготовка к людуму

Sat, 06 Apr 2024 00:00:00 GMT

Немного подготовился к предстоящему людуму: создал репозиторий, настроил окружение и собрал hello world игры, где один квадрат падает на другой. Сразу воткнул React чтобы сделать экран меню и нарисовать интерфейс.

А еще поставил новый пиксель арт редактор на планшет — Pixquare. Aseprite все никак не появится на iPad зато начали появляться подражатели. Это уже второй, из тех, что я нашел.

Потестил Pixquare. На пару с женой нарисовали нашего пса. Вроде даже получилось похоже на собаку если сильно взгляд не отдалять.

Кнопка перезагрузки редактора

Sun, 31 Mar 2024 00:00:00 GMT

После большой задачи с событиями хочется немного откиснуть и сделать что-то несложное. Тем более через две недели Ludum Dare на котором я буду писать игру.

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

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

Смотреть видео

Очередь событий

Mon, 11 Mar 2024 00:00:00 GMT

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

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

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

Полностью перейти на использование очереди у меня не получилось. Как я говорил выше, в некоторых случаях когда дело касается добавления или удаления объектов из сцены, отложенная реакция приводила к ошибкам и попыткам обратиться к уже уничтоженным данным. Поэтому наряду с методом dispatchEvent() для отправки события в очередь, я оставил dispatchEventImmediately() для немедленного оповещения. Второй используется только для уведомления об изменениях на сцене и вообще служит только для исключительных кейсов, когда срочность очень важно и без нее никак.

Всплытие событий

Sun, 25 Feb 2024 00:00:00 GMT

Для чего вообще может понадобиться всплытие событий в движке?

Представим, что есть система, которая обрабатывает различные эффекты вроде "Нанести персонажу X урона", "Вылечить игрока на Y хп" или "Отравить врага на Z секунд". Событие эффекта может иметь единый тип, но разный набор параметров и тогда системе достаточно следить только за этим событием и подбирать правильную стратегию реагирования. Но как узнать о том, что к какому-то объекту применили эффект? Без всплытия придется перебрать вообще все объекты сцены и на каждый подписаться. При этом нужно не забывать, что объекты могут исчезать и появляться, поэтому нужно следить и за этим тоже. На выходе имеем больше boilerplate кода и кучу одинаковых обработчиков на каждом объекте. В то же время, если бы события умели всплывать наверх, то одной подписки на корневой объект (например сцену) было бы достаточно чтобы следить за всеми сразу.

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

const event = {
  type,
  target: this,
  currentTarget: this
};

let target = this;

while (target !== null) {
  event.currentTarget = target;

  const listeners = target.getListeners(event.type);
  listeners?.forEach((listener) => listener(event));

  target = target.parent;
}

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

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

Чтобы у сцены и объекта был единый интерфейс по работе с родителями и детьми я добавил немножечко наследования. В основе лежит EventTarget класс c возможностями подписки и генерации событий, затем идет Entity – базовый класс, поддерживающий методы вроде appendChild(), removeChild(), getEntityById() и так далее. Наконец, от него уже наследуются Scene и Actor (переименовал GameObject в Actor потому что надоело писать много букв да и приставка Game ни туда ни сюда).

Код движка стал немного аккуратнее и у меня даже получилось щегольнуть знаниями, полученными после нарешивая задач на литкоде. Для поиска объекта в дереве по идентификатору я использовал BFS метод с очередью на односвязном списке.