Каждый, кто имел дело с Unreal Engine после 2014, наверняка слышал про скриптовый язык Blueprint. Но что реально происходит под капотом, когда вы таскаете ноды? Как создать свою ноду (и надо ли это вам вообще?) В данной статье я бы хотел разобрать K2Node
Я сейчас собираю маркетинговую кампанию для своей первой игры. Денег на рекламу — ноль. И это, на самом деле, не редкость: большинство инди на старте живут в режиме «или делаем игру, или делаем маркетинг».
И вот что я понял: маркетинг без бюджета работает. Это дисциплина. Это таблицы. Это упаковка. Это тайминг. И это нормальное количество отказов, которое нужно пережить.
Ниже — система, которую я выстраиваю сам. Это не «универсальная истина», но это точно рабочая логика для тех, у кого нет бюджета, зато есть голова и руки.
— Нам нужен дизайн-док. — Какой именно? — Ну...ГДД.
Пожалуй, это одна из самых частых ситуаций, с которыми я столкнулся, начав искать работу в студиях.
Я уже более трёх лет в геймдеве — пусть и как инди-разработчик. У меня своя команда, собранная с нуля. Я учусь в магистратуре по профилю «геймдизайн», прошёл ряд курсов от западных университетов, написал десятки тысяч диалогов, GDD, питч-доков, фич-доков и множество других документов.
Я понимал, что поиск работы — процесс непростой. Но я не ожидал, что одной из главных сложностей станет размытость формулировок и отсутствие ясности в том, какой именно документ требуется.
Под «дизайн-доком» может скрываться что угодно: от one-pager на одну страницу до многостраничного системного описания с метриками, балансом и техническими ограничениями.
В этой статье я не буду обсуждать, почему в индустрии зачастую выше ценится сухая аналитика и таблицы, чем авторское видение (при том что одно другому не мешает). Вместо этого я попробую систематизировать наиболее распространённые виды дизайн-документов, немного их типизировать и, возможно, помочь тем, кто только входит в профессию и теряется в этом терминологическом хаосе.
Итак, попробуем разобраться.
Всем привет!
Сегодня говорим про систему world state — она позволяет делать вариативность, запоминать решения игрока и делать реплики/ответы на основе флагов.
Вы когда-нибудь задумывались, почему в вашей любимой игре одни двери открываются, а другие - просто декорация? Почему за одной дверью - босс, а за другой - пустая комната? И я сейчас не про техническую реализацию, а про то, как дверь влияет на восприятие мира, на доверие игрока к системам игры и на саму логику игрового пространства. Это так называемая «Проблема дверей», и сегодня мы разберем, почему эта, казалось бы, простая вещь ломает мозг каждому геймдизайнеру.
Представьте: вы делаете свою первую игру. Вы добавляете дверь. Казалось бы, что может быть проще? Но тут же возникает куча вопросов.
Можно ли открыть эту дверь? Если да - как? Ключом, кнопкой, после выполнения квеста? А если нет - почему она вообще здесь? Является ли она просто частью декорации? Но тогда как игрок поймет, что одни двери - интерактивны, а другие - нет? Ведь если половина дверей в мире нерабочая, а другая - функциональная, но визуально они неотличимы, вы создаете фрустрацию, а не загадку.
А что, если дверь открывается только с одной стороны? Игрок проходит через неё, оборачивается - и видит, что обратно пройти нельзя. Это намеренное ограничение? Или баг? Как вы донесете до игрока, что это часть замысла, а не недоделка?
Или вот ещё: дверь закрывается за спиной. Это должно вызывать напряжение - как в Resident Evil. Но если игрок не был готов к этому, он может подумать, что застрял. Где тут грань между атмосферой и плохим UX?
Еще сложнее - когда дверь становится частью нарратива. Например, вы не можете открыть дверь в дом, потому что «герой ещё не готов эмоционально». Но механически это выглядит как обычная запертая дверь. Игрок не видит внутреннего конфликта персонажа - он видит стену. И начинает биться головой в попытках найти ключ, которого не существует. Так вы рискуете разрушить погружение, а не усилить его.
Всем привет! Сегодня снова говорим про ключевую фичу проекта — сноски Дэвида Фостера Уоллеса. В этот раз без технической части.
Захотелось мне как-то написать что-нибудь на UMG в Unreal Engine 5 и исключительно на С++ (без использования блупринтов). Заодно было любопытно краем глаза взглянуть на QT. “Пахнет небольшим проектом”, - подумал я и избрал для вдохновения игру “Сапёр” из сего репозитория -> https://github.com/Bollos00/LibreMines. Моё почтение автору той репы!
Началось всё с бездумного и медитативного переписывания… простите, портирования структуры и логики на анриловский UMG и параллельного просмотра любимых шоу на ютьюбе. Чудесное было время! Далее чуть подрефачил код, упростил его, убрал ненужное, и получилось то, что получилось.
Представьте: вы геймплейный программист, к вам приходит левелдизайнер и говорит что ему нужно чтобы наши мобы умели патрулировать, да к тому же не просто ходить по прямой между точками, а уметь двигаться по кривой, например, вокруг какого-то важного объекта на карте. Вспоминая как работает мувмент вы спрашиваете:
— А по точкам вот прям вообще не подойдет?
— Не, ну, конечно, на крайняк подойдет, но хочу чтобы было по кривой. Да и на прошлой игре где я работал такое было, почему у нас нет?
И вот вы одновременно рады за его предыдущую команду, но в то же время и сами понимаете, что по кривой будет и красивее и гибче, но с какой стороны подойти к задаче — вопрос не праздный. Если вы оказались в такой или подобной ситуации, то эта статья для вас.
Всем привет!
Этот пост будет предновогодним и потому мы обсудим самую мякотку.
Сегодня обсудим ключевую фичу проекта - сноски Дэвида Фостера Уоллеса! Это автор с уникальным подходом к написанию - как понятно из названия, там что-то любопытное придумал Уоллес со сносками. Его открытие: Сноски могут быть самостоятельным сюжетным битом, ироничным и харизматичным замечанием, они могут быть большие и огромные - некоторые его сноски достигают размера целой главы и создают ощущение бесконечного текста*(это сноска, листайте в конец чтобы оценить задумку).
Всем привет!
Сегодня поговорим о том как выглядит бросок кубика и как он работает.
Кубики бывают разные (СКРИН_1).
Они нужны чтобы ролевая система могла обрабатывать геймплей - бросок кубика направляет историю, делает ее непредсказуемой (или умеренно предсказуемой) и в целом является тем что оживляет характеристики персонажа, позволяет играть в игру.
Приветствую всех в новом сообществе, где я буду делиться ходом разработки!
Сегодня говорим о том где вообще записываются диалоги игры.
Если вы достаточно информированный фанат, то знаете что Дискач делали с помощью ARTICY, что у них были такие большие деревья диалогов, что программа буквально крашилась.
Что мне удалось сделать за это время, детальный разбор механик, советы по разработке - делюсь всем этим с вами тут!
Всем привет, я разработчик игр на Unreal Engine 5, долгое время я занимался изучением игрового движка, созданием плагинов на FAB и теперь готов показать вам свой проект!
Для начала я расскажу немного о игре, а затем о технологиях которые я использовал, чтобы получить прирост производительности и более интересный геймплей.
При разработке игры в условиях 72-часового джема звук часто становится последней линией защиты, на которую заканчиваются силы. Главная задача прототипа — создать ощущение, что игра «живая и отзывчивая», а звук главный инструмент для этого. В этой статье мы разберем иерархию звуков на реальном примере нашей игры «Выход из строя», созданной на Siberian Game Jam — Ноябрь 2025
Что такое полезное действие и почему оно важно для звука?
1.Что такое пространство?
2.О самых распространенных пространствах
3.Причем тут трансформ и умножение матриц?
4.Как их можно использовать, на примерах шейдеров
На прошлой неделе вышла вторая версия архитектурного фреймворка Atomic, который применяет атомарный подход в разработке игр на Unity и C#.
Ключевая идея фреймворка заключается в том, чтобы создавать игровые системы из атомарных элементов, которые представляют собой модульные объекты в виде констант, переменных, событий, действий и функций. Такой подход избавляет от лишней сложности объектно-ориентированной архитектуры и фокусируется на реализации игровых механик.
В этой статье мы подробно разберём концепцию атомарного подхода и посмотрим, как можно проектировать архитектуру из «болтиков» и «винтиков». Также рассмотрим способ разработки игр на чистом C#, используя Unity в качестве визуализации.
Привет!
В этой статье я объясню как сделать ИИ летающего боевого дрона на движке Unreal Engine с использованием алгоритма A*.
Привет, Хабр! На связи команда разработчиков R2 из ПИК Digital. Сегодня мы расскажем о нашей платформе на базе движка UE, на которой мы занимаемся разработкой модулей, автоматизирующих различные процессы девелопмента.
Это первая статья из серии, в которой будет сделан обзор платформы и ее архитектуры. Последующие статьи будут рассматривать отдельные модули более глубоко и подробно.
Когда мы начинали автоматизировать проектные процессы, столкнулись с типичной проблемой: каждая стадия проекта, от концепции до эксплуатации — требовала своего набора инструментов, зачастую мало интегрированных друг с другом. Градостроительный анализ делали в одной среде, рабочую документацию готовили в другой, контроль качества строительства — в третьей. Данные между системами передавались вручную, что вызывало потери и ошибки.
Платформа R2 — это попытка системно решить эту проблему, охватив часть процессов девелоперского цикла модульными инструментами, которые работают с моделью данных и интегрируются с привычными САПР-системами.
Ранее мы уже рассказывали о том, как с помощью сервиса R2 можно использовать метод инсоляционного массинга — то есть, проверять размещение многоэтажной жилой настройки на участке с учётом требований инсоляции.
Почему Unreal Engine?
В основе платформы R2 лежит движок Unreal Engine — решение, которое может показаться неожиданным для сферы проектирования недвижимости. Однако именно производительность этого движка и его способность работать с большими объемами данных стали ключевыми факторами выбора.
В сообществе Epic в последнее время активно обсуждают статтеты, вызванные компиляцией шейдеров, и их влияние на геймдев-проекты.
В этой статье разберёмся, почему возникает это явление, объясним, как предкэширование PSO помогает его устранить, а также поделимся практиками разработки, которые позволят минимизировать статтеры. Также расскажем о планах по развитию системы предкэширования PSO.
Привет, хабр!
Это моя первая статья, поэтому для начала представлюсь. Меня зовут Виктор, мне 40 лет, из которых почти 20 я на разных ролях участвую в разработке различного программного обеспечения для крупных корпораций (в основном финтех). Путь был долгий и тернистый, но сейчас я занимаю роль Системного архитектора и по совместительству Руководителя направления интеграции.
Я всегда любил игры, у меня даже был собственный канал с летсплеями и обзорами разных игр, который, к сожалению, не сыскал успеха. Несмотря на это, около двух лет назад я решил с ноги ворваться в мир геймдева. Ничто не предвещало беды, просто одним февральским вечером будто щелкнуло что-то в мозгу - ХОЧУ… ДЕЛАТЬ… ИГРЫ…
Я человек самодостаточный, так что если хочу, значит, делаю. И на самом деле это очень интересное ощущение - в 40 лет почувствовать себя беспробудным джуном в той области, в которой совершенно ничего не понимаешь, но тебе так интересно.
