В жизни не раз случаются внезапные события, о которых ты даже не подозревал за очень небольшой срок до их наступления. Тем жизнь и хороша, что она не расписана для каждого от начала до конца. Вот и конференция в Минске 22 апреля 2026 года свалилась мне на голову достаточно внезапно и поломала все мои планы. Но обо всём по порядку.
Как мы автоматизировали сборку Unity-проектов под несколько платформ: прошли через Jenkins, GitHub Actions с game-ci и сорокаминутные билды — и в итоге написали собственный инструмент.
В статье:
Почему Jenkins и GitHub Actions не подошли
Что такое Unity Builder и какую боль закрывает
Визуальный пайплайн, параллельные задачи, FTP-интеграция
За десятилетия существования ECS сложились два фундаментальных способа хранить компоненты: архетипы (Unity DOTS, Flecs, Bevy) и sparse sets (EnTT, LeoECS). Каждый из них несёт структурные ограничения, которые не устраняются оптимизацией реализации — они вытекают из самой модели данных.
StaticEcs — третья модель. Она основана на инвертированном иерархическом битовом индексе: не сущности хранят маски своих компонентов, а компоненты хранят битовые карты сущностей. Фильтрация запроса — это побитовое AND, обрабатывающее 64 сущности за одну инструкцию CPU. Добавление или удаление компонента меняет один бит и не перемещает никаких данных.
В статье разбираю, как устроена эта архитектура, чем она отличается от архетипов и sparse sets, и что даёт на практике.
Как одна модификация формулы превращает генератор карт в дизайнера уровней
Всем привет! Меня зовут Григорий Дядиченко, и я технический продюсер. Играли в Hades? Там дизайнер уровней не бросает кубики. Он точно знает, где игрок поймает дыхание после погони, где встретит соблазн свернуть с пути, где сундук стоит под прицелом элитника, а где — просто в углу за колонной. В простой случайной генерации таких решений нет: карты рождаются «равномерными» и драматургически мёртвыми. Сегодня хочется поговорить о том, как одной модификацией в формуле Wave Function Collapse вернуть в генератор жизнь. Разберём Entropy Bias, Entropy Cascade, Tile Probability Bias и семантические слои. Если вам интересна тема процедурной генерации и немножко математики — добро пожаловать под кат.
В жизни каждого программиста рано или поздно наступает момент, когда хочется вернуть из функции «либо то, либо это». Правильным языком это называется Discriminated Union (далее DU). Его суть проста: тип должен представлять одно значение из нескольких возможных (поэтому реализации называют «OneOf», т.е «один из»).
Казалось бы, что это довольно станадртная ситуация и нечего тут бухтеть, но именно c# кажется особенным в этом плане по сравнению с другими языками. Давайте разберёмся как устроены DU в других языках программирования.
Одним из самых простых примеров без «но» является Си. Действительно, язык просто содержит ключевое слово union, которое позволяет на один участок памяти наложить типы. эта возможность просто комбинируется с enum или int тегом, чтобы различать, что мы записали. Проблема заключается в том, что по большей части никто ничего не гарантирует: программист сам обязан проверять каждый из вариантов и следить, чтобы случайно не создать невалидное состояние.
В этом посте я хочу поделиться своим мнением: может ли человек в 2026 году без специализированного образования и без какого-либо опыта в геймдеве стать инди-разработчиком.
Меня зовут Rok и в настоящее время я занимаюсь разработкой коллекционной карточной игры про танки в сеттинге Второй мировой войны — Tank General.
На данный момент мне 44 года. Я не являюсь профессиональным разработчиком и никогда раньше не имел отношения к геймдеву. По профессии я юрист и всю свою жизнь работал именно юристом. Разработчиком я решил стать полтора года назад.
Разрабатываемая мной игра уже имеет вполне рабочий билд. В нём реализованы около 200 карт техники и приказов, три играбельные нации, около 30 штабов со способностями, несколько PvE-режимов, а также сетевой режим, который является основным в моей игре.
Также, в этом посте я хочу рассказать о многочисленных ошибках, которые я допустил на своём пути, а также поделюсь некоторыми советами, которые могут оказаться полезными таким же новичкам, каким был я.
Если вы недавно обновились до Unity 6 (или URP 17+) и попытались перенести свои старые пост-эффекты, то наверняка столкнулись с красной консолью и предупреждениями об устаревших методах.
Старые туториалы по созданию эффекта обводки (Outline) через ScriptableRendererFeature больше не работают "из коробки". Unity полностью изменила архитектуру рендера, внедрив Render Graph. Старый добрый метод Execute канул в Лету, а fullscreenMesh заменили на Blitter.
В этой статье мы не просто перепишем классический эффект Outline под новые реалии Unity 6. Мы решим две главные проблемы подобных шейдеров, о которых часто умалчивают в гайдах.
Ritualist — это isometric roguelike в стилистике low poly. В ранний доступ мы вышли 5 марта, а до этого участвовали в Steam Next Fest с демкой (об этом хочется выложить отдельную статью, там отдельный пласт проблем и неоправданных ожиданий). Команда за время разработки сильно менялась: сначала нас было много, потом люди уходили, и сейчас в проекте осталось пять человек. Сама игра была в разработке больше 2 лет, но плотно ей заниматься начали всего полгода назад: как раз когда команда сократилась до этого ядра.Почему так вышло? Потому что до этого мы толком не знали, как управлять продуктом, не умели договариваться и делали ставку не на те вещи. Рассказываем по порядку: что было до раннего доступа, что случилось после и с чем мы боремся сейчас.
Привет, уважаемые пользователи Хабра! Решил поделиться с вами историей своего пути в геймдев. Забегая вперед, скажу, что история еще не окончена и чем окончится никому не известно. Тем не менее, возможно она вдохновит тех, кто хочет изменить свою жизнь, но не решается это сделать, потому что считает, что в «40+ уже поздно» или опасается быть непонятым окружающими.
Это моя дебютная статья. Не ждите глубоких технических разборов или чудодейственных методик, гарантированно ведущих к успеху. Никакой преисполненности собственной крутости или токсичной позитивности — только правда. При написании статьи ни одна нейросеть «не пострадала», да бы материал максимально отражал реальный уровень моих знаний и навыков. И так, не буду затягивать вступление и перехожу непосредственно к истории...
Всем привет! Меня зовут Григорий Дядиченко, и я разрабатываю разные проекты на заказ. Сталкивались ли вы с ситуацией, когда персонаж в вашей игре начинает немного дёргаться, если поиграть достаточно долго? Или пуля иногда пролетает сквозь тонкую стену, хотя коллайдер на месте? Если да — добро пожаловать в мир проблем float precision.
Сегодня хочется поговорить о том, почему тип float — при всей его повсеместности — может создавать тонкие и неочевидные баги в играх. Разберём, как он устроен, где именно он начинает врать, и что с этим делать.
Если вам интересна эта тема — добро пожаловать под кат!
Я разработал свою первую 3D-игру на Unity: подводный лабиринт в духе PacMan, где игрок управляет субмариной и взаимодействует с разными типами рыб. В какой-то момент, я столкнулся с вопросом: как сделать поведение агентов не просто рабочим, а живым и правдоподобным?
В статье разберем:
• что такое Steering Behaviors и в чем суть этого подхода
• основные типы поведения: seek, pursue, evade, wander, avoidance
• как из простых правил собрать более сложную модель поведения агента
• как этот подход был применен в моей игре
С 2022 года отечественная игровая индустрия получила, по разным оценкам, около 7–10 млрд рублей государственной поддержки. Цифры могут показаться огромными, но, сравнив их с мировыми, становится не так страшно. Например, разработка GTA V или Cyberpunk 2077 стоила порядка $300 млн — это около 20–25 млрд рублей. То есть весь объём государственной поддержки за несколько лет — это половина бюджета одной крупной игры.
И всё же для российского геймдева это беспрецедентные инвестиции. А ещё создано множество проектов, направленных на поддержку игровой индустрии. Но почему же из всех этих стараний мы видим лишь набор аккуратно собранных, но мёртвых проектов?
Недавняя волна обсуждений, в том числе статья на DTF, показала неприятную тенденцию: ПК-геймеры всё чаще используют геймпады. И причина не в переходе на консоли, а в ощущениях от игры.
Геймпад обеспечивает удобный контроль, эргономику и тактильную отдачу. Клавиатура же создана для набора текста, а не для игр, и состоит из множества бинарных кнопок.
Но как быть, если мы разрабатываем ПК-эксклюзив, а у игрока нет джойстика? Сегодня мы подумаем, как эмулировать геймпад с помощью клавиатуры и мыши, следуя индустриальным стандартам.
Я всегда хотел играть в игры, где NPC ощущаются по-настоящему живыми — как в исекаях или фэнтези-историях.
Не просто говорят: «Добро пожаловать, странник», — а помнят, что ты уже был здесь, спрашивал про кузнеца, и понимают, что сейчас вечер. Им можно сказать: «Привет, где здесь таверна?» — и они ответят голосом, учитывая прошлые разговоры и контекст мира.
В этой статье мы шаг за шагом соберём такую систему в Unity: от первого запроса к локальной LLM до персонажа, который слышит голос игрока, знает мир игры, помнит разговоры, делает выводы и отвечает голосом. В основе — архитектура Generative Agents от Stanford.
Дорогие любители написать, что текст ИИ-шный, эта статья также, как и все другие отредактирована ИИ.
Под моими статьями на Хабре в какой-то момент начал повторяться один и тот же сценарий. Не обсуждение тезисов, не спор по аргументам, не разбор примеров — а мгновенный заход в комментарии с диагнозом: «нейротекст», «нейрослоп», «научитесь формулировать мысли сами». Иногда человек даже не дочитывает материал до середины, но уже уверен, что проблема именно в инструменте, а не в содержании.
Меня это сначала раздражало, потом удивляло, а потом стало просто интересно. Потому что я не скрываю, что использую ИИ как редактор и помощника: чтобы быстрее шлифовать структуру, перепроверять формулировки, вытягивать из головы черновую мысль в более читаемый вид. Но я при этом не понимаю, где здесь логическая связка: если текст редактировался с помощью ИИ, почему это автоматически означает, что у автора нет своих мыслей?
В какой-то момент стало ясно, что спорить на уровне «ну это же просто инструмент» бесполезно. Если тема так многих цепляет, значит, за этим стоит что-то глубже: недоверие, культурная реакция, ощущение подмены, страх обесценивания труда — что угодно. Поэтому я решил не гадать и посмотреть, что на этот счёт вообще говорят исследования.
В геймдизайне продолжает жить удобная формула: «чтобы игроку было интересно, он должен войти в роль персонажа». Эта статья отстаивает альтернативную позицию: идентификация — важный, но не обязательный механизм вовлечения; удовольствие в играх часто строится на управляемой недосказанности — неполной ясности и смысловых пробелах, которые игрок заполняет интерпретацией. Недосказанность запускает любопытство, производство смысла, эмоциональную связь и ощущение «живого мира» — без необходимости полного совпадения игрока с персонажем. Текст синтезирует подходы game studies (герменевтика, пределы «текстового анализа»), психологию любопытства и исследования неопределённости, а также геймдизайнерские теории о роли неопределённости как топлива игрового опыта.
Небольшая ремарка про процесс: статья получилась длинной — пришлось заново прокрутить в голове несколько прохождений (и пару раз открыть заметки по game studies), чтобы не скатиться в «мнение из воздуха». Формулировки местами специально оставлены живыми: так проще говорить об опыте, который сам по себе не любит стерильности.
Я сейчас собираю маркетинговую кампанию для своей первой игры. Денег на рекламу — ноль. И это, на самом деле, не редкость: большинство инди на старте живут в режиме «или делаем игру, или делаем маркетинг».
И вот что я понял: маркетинг без бюджета работает. Это дисциплина. Это таблицы. Это упаковка. Это тайминг. И это нормальное количество отказов, которое нужно пережить.
Ниже — система, которую я выстраиваю сам. Это не «универсальная истина», но это точно рабочая логика для тех, у кого нет бюджета, зато есть голова и руки.
— Нам нужен дизайн-док. — Какой именно? — Ну...ГДД.
Пожалуй, это одна из самых частых ситуаций, с которыми я столкнулся, начав искать работу в студиях.
Я уже более трёх лет в геймдеве — пусть и как инди-разработчик. У меня своя команда, собранная с нуля. Я учусь в магистратуре по профилю «геймдизайн», прошёл ряд курсов от западных университетов, написал десятки тысяч диалогов, GDD, питч-доков, фич-доков и множество других документов.
Я понимал, что поиск работы — процесс непростой. Но я не ожидал, что одной из главных сложностей станет размытость формулировок и отсутствие ясности в том, какой именно документ требуется.
Под «дизайн-доком» может скрываться что угодно: от one-pager на одну страницу до многостраничного системного описания с метриками, балансом и техническими ограничениями.
В этой статье я не буду обсуждать, почему в индустрии зачастую выше ценится сухая аналитика и таблицы, чем авторское видение (при том что одно другому не мешает). Вместо этого я попробую систематизировать наиболее распространённые виды дизайн-документов, немного их типизировать и, возможно, помочь тем, кто только входит в профессию и теряется в этом терминологическом хаосе.
Итак, попробуем разобраться.
Всем привет! Прошел насыщенный год, и пришло время поделиться тем, что успело произойти с моей мобильной игрой "Лампочка". Изначально я хотел поручить написание этого текста ИИ, но, прочитав его творчество, решил отказаться от этой идеи. В этом материале я расскажу, как мы делали масштабное обновление.
Вы когда-нибудь задумывались, почему в вашей любимой игре одни двери открываются, а другие - просто декорация? Почему за одной дверью - босс, а за другой - пустая комната? И я сейчас не про техническую реализацию, а про то, как дверь влияет на восприятие мира, на доверие игрока к системам игры и на саму логику игрового пространства. Это так называемая «Проблема дверей», и сегодня мы разберем, почему эта, казалось бы, простая вещь ломает мозг каждому геймдизайнеру.
Представьте: вы делаете свою первую игру. Вы добавляете дверь. Казалось бы, что может быть проще? Но тут же возникает куча вопросов.
Можно ли открыть эту дверь? Если да - как? Ключом, кнопкой, после выполнения квеста? А если нет - почему она вообще здесь? Является ли она просто частью декорации? Но тогда как игрок поймет, что одни двери - интерактивны, а другие - нет? Ведь если половина дверей в мире нерабочая, а другая - функциональная, но визуально они неотличимы, вы создаете фрустрацию, а не загадку.
А что, если дверь открывается только с одной стороны? Игрок проходит через неё, оборачивается - и видит, что обратно пройти нельзя. Это намеренное ограничение? Или баг? Как вы донесете до игрока, что это часть замысла, а не недоделка?
Или вот ещё: дверь закрывается за спиной. Это должно вызывать напряжение - как в Resident Evil. Но если игрок не был готов к этому, он может подумать, что застрял. Где тут грань между атмосферой и плохим UX?
Еще сложнее - когда дверь становится частью нарратива. Например, вы не можете открыть дверь в дом, потому что «герой ещё не готов эмоционально». Но механически это выглядит как обычная запертая дверь. Игрок не видит внутреннего конфликта персонажа - он видит стену. И начинает биться головой в попытках найти ключ, которого не существует. Так вы рискуете разрушить погружение, а не усилить его.
