Unity *

Если вы недавно обновились до 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 млрд рублей. То есть весь объём государственной поддержки за несколько лет — это половина бюджета одной крупной игры.

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

Я всегда хотел играть в игры, где NPC ощущаются по-настоящему живыми — как в исекаях или фэнтези-историях.

Не просто говорят: «Добро пожаловать, странник», — а помнят, что ты уже был здесь, спрашивал про кузнеца, и понимают, что сейчас вечер. Им можно сказать: «Привет, где здесь таверна?» — и они ответят голосом, учитывая прошлые разговоры и контекст мира.

В этой статье мы шаг за шагом соберём такую систему в Unity: от первого запроса к локальной LLM до персонажа, который слышит голос игрока, знает мир игры, помнит разговоры, делает выводы и отвечает голосом. В основе — архитектура Generative Agents от Stanford.

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

Под моими статьями на Хабре в какой-то момент начал повторяться один и тот же сценарий. Не обсуждение тезисов, не спор по аргументам, не разбор примеров — а мгновенный заход в комментарии с диагнозом: «нейротекст», «нейрослоп», «научитесь формулировать мысли сами». Иногда человек даже не дочитывает материал до середины, но уже уверен, что проблема именно в инструменте, а не в содержании.

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

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

В геймдизайне продолжает жить удобная формула: «чтобы игроку было интересно, он должен войти в роль персонажа». Эта статья отстаивает альтернативную позицию: идентификация — важный, но не обязательный механизм вовлечения; удовольствие в играх часто строится на управляемой недосказанности — неполной ясности и смысловых пробелах, которые игрок заполняет интерпретацией. Недосказанность запускает любопытство, производство смысла, эмоциональную связь и ощущение «живого мира» — без необходимости полного совпадения игрока с персонажем. Текст синтезирует подходы game studies (герменевтика, пределы «текстового анализа»), психологию любопытства и исследования неопределённости, а также геймдизайнерские теории о роли неопределённости как топлива игрового опыта.

Небольшая ремарка про процесс: статья получилась длинной — пришлось заново прокрутить в голове несколько прохождений (и пару раз открыть заметки по game studies), чтобы не скатиться в «мнение из воздуха». Формулировки местами специально оставлены живыми: так проще говорить об опыте, который сам по себе не любит стерильности.

Я сейчас собираю маркетинговую кампанию для своей первой игры. Денег на рекламу — ноль. И это, на самом деле, не редкость: большинство инди на старте живут в режиме «или делаем игру, или делаем маркетинг».

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

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

— Нам нужен дизайн-док. — Какой именно? — Ну...ГДД.

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

Я уже более трёх лет в геймдеве — пусть и как инди-разработчик. У меня своя команда, собранная с нуля. Я учусь в магистратуре по профилю «геймдизайн», прошёл ряд курсов от западных университетов, написал десятки тысяч диалогов, GDD, питч-доков, фич-доков и множество других документов.

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

Под «дизайн-доком» может скрываться что угодно: от one-pager на одну страницу до многостраничного системного описания с метриками, балансом и техническими ограничениями.

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

Итак, попробуем разобраться.

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

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

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

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

А что, если дверь открывается только с одной стороны? Игрок проходит через неё, оборачивается - и видит, что обратно пройти нельзя. Это намеренное ограничение? Или баг? Как вы донесете до игрока, что это часть замысла, а не недоделка?

Или вот ещё: дверь закрывается за спиной. Это должно вызывать напряжение - как в Resident Evil. Но если игрок не был готов к этому, он может подумать, что застрял. Где тут грань между атмосферой и плохим UX?

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

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

На помощь приходит статический анализ кода.

Привет! Меня зовут Игорь, я занимаюсь разработкой на Unity c 2018 года.
В этой статье расскажу, как с помощью Roslyn можно автоматизировать задачи.

Продолжаю разрабатывать Minecraft на движке Unity. В этой статье я покажу мою реализацию разрушения блоков - перестройки чанков. Это будет моя вторая реализация.

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

Моя первая логика основывалась на полной перестройке чанка после удаления блока. Это работало без багов и не сильно влияло на производительность. Но я решил поэкспериментировать со своей игрой, поставил высокую скорость разрушения и блоки разрушались 1 блок за кадр или около 100 - 300 блоков в секунду. При таком раскладе игра начинала тормозить, не сильно, но заметно. Конечно я не планировал оставлять такую скорость разрушения, но, если я могу увеличить производительность, то нужно реализовывать.

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

Далее расскажу о всех деталях:

Первым делом я вынес Mesh и его параметры (Vertices, Triangles и т.д.)

Когда я решил сделать свою первую игру для Steam, я был максимально наивен. Мне приходили «крутые идеи», я загорался, начинал их продумывать… и довольно быстро упирался в тупик.

Со временем я понял, что в момент выбора идеи очень легко:

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

Берете язык из String.Format и жените его с Unity Inspector.

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

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

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

С момента прошлой статьи прошло достаточно много времени и я заметил одну интересную вещь: немало людей добавили статью в закладки, несмотря на небольшое число отметок “нравится”. Это убедило меня в полезности материала и потому я решил написать вторую часть.

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

Далее предоставлю полный скрипт для построения чанка.