Мы начинали, как многие — с гиперказуальных игр. Быстрое прототипирование, пробы механик, обучение на ошибках за счет издателя — казалось, идеальный старт. Но со временем стало ясно: зарабатывать на этом почти невозможно. Выплаты сжимались, требования росли, а хайп вокруг жанра угасал.
Пришло время выбора: продолжать штамповать одноразовые проекты или рискнуть и сделать что-то своё. Мы выбрали второе.
Давайте будем честны: как Unity-разработчики, мы все пишем код, который может содержать ошибки. Это касается и меня, и вас, и даже искусственного интеллекта.
Многие разработчики программного обеспечения считают модульное (или unit) тестирование важнейшим инструментом для раннего выявления и предотвращения регрессий. Но действительно ли оно эффективно в контексте разработки Unity-проектов?
В этой статье я поделюсь с вами нашим опытом внедрения тестов в Virtual Maker. Мы рассмотрим разницу между модульными, интеграционными и сквозными тестами, а также обсудим, почему вам не следует (по моему мнению) прибегать к последним в ваших проектах.
Привет. Я занимаюсь реализацией UI в нашей небольшой команде, разрабатывающей игры. Долгое время занимался 3D-моделированием, моушн-дизайном, UX/UI-дизайном, построением дизайн-систем. Позже жизнь привела меня в игровую индустрию, где я применил предыдущие навыки.
Команда разрабатывала гиперказуальные игры, и на момент моего присоединения к ней происходила перестройка — переход от гиперказуальных игр к хардкорным проектам. Тогда рассматривались два варианта новых проектов:
Пишешь игру на Unity? Нужна производительность?
UniTask – решение!
Просто о сложном в этой статье. (Примеры про роботов, лего и машинки уже тут)
JSON - это популярный текстовый формат, который используется для обмена данными. Он был разработан на основе JavaScript синтаксиса, но является полностью независимым от языка, что позволяет использовать его почти в любом программном окружении.
В контексте игродела JSON нередко используют для внутриигровых сохранений. Фактически мы преобразовываем экземпляры наших классов и структур в удобный формат, а далее помещаем это в файл с расширением .json
А точно ли самый простой жанр?
Почему визуальные новеллы — это далеко не всегда «тонны текста со статичными картинками», а полноценный, трудоемкий жанр.
Когда мы с небольшим составом в команде только начали делать визуальную новеллу, в голове звучал вопрос: «Это же вроде легкий жанр… Просто текст, картинки и немного музыки, да?»
Прошло уже больше года разработки. Сотни часов. И теперь у меня встречный вопрос: а точно ли он простой?
Когда я начал работу над Architect of Ruin в декабре 2023 года, то решил делать её в игровом движке Bevy. Мой выбор был мотивирован собственным интересом к Rust — языку, от работы с которым я получаю много удовольствия. Ещё больше меня привлекла в этом движке модель ECS, с которой мне тоже нравится работать, а также сообщество Bevy, которое мне очень симпатично.
Поэтому стало неожиданностью то, что в январе 2025 года мы выполнили миграцию нашей игры с Rust и Bevy. Я потратил примерно шесть недель, чтобы полностью переписать игру на C#, и последние три месяца мы работаем в Unity.
Смена движка — частый убийца проектов. При этом может резко снижаться продуктивность, неизбежно возникают регрессии, а каждый шаг вперёд как будто приводит к трём шагам назад. Не говоря уже о том, что опыт работы с одним языком и движком нельзя полностью перенести на новый язык и движок.
Но мы решились на это, и в посте я объясню, почему.
По сюжету мальчишки уговаривают девочек зайти с ними в аркадный центр незадолго до его закрытия. Хотя многие автоматы уже не работают или доживают последние дни (все-таки бедная американская глубинка), ребята находят, во что поиграть, и вечер неожиданно становится куда интереснее.
Привет, Хабр!
Я прочитал статью Migrating away from Rust и хочу поделиться с вами своими мыслями, заодно переведя оригинал. Я буду вести повествование от своего лица, поскольку это скорее реакция и размышления, а не традиционный перевод.
Для меня тема весьма актуальна, так как я сам нахожусь в этом странном лагере разработки игр на нишевых движках. Я использую не Rust+Bevy, а Go+Ebitengine, но многие плюсы и минусы этих комбинаций интересно рассматривать как дополняющие друг друга.
Когда-нибудь, я обязательно напишу статью о своём опыте серьёзной разработки игр на Go, но пока я слишком сильно завертелся в рабочем процессе, чтобы успеть доделать демку своей игры до Steam Next Fest. Будет ли эта статья положительная, или это будет миграция на Godot? Кто знает!
Ну а пока, погнали разбирать статью.
В этой статье мы поговорим о математических основах вращения объектов, Эйлеровых углах и проблематике их использования, а также о Кватернионах и причинах выбрать Кватернионы перед Эйлеровыми углами.
Scriptable Render Pipeline (далее SRP) в Unity - это бескомпромисная свобода и производительность по сравнению с универсальными, но слишком громозкими URP и HDRP. Результат? Noesis Render: кастомный пайплайн с декалями, продвинутым AO, поддержкой DLSS и FPS которые упираются в процессор. В первой части я обсужу общее состояние SPR и выбор лучшего пути рендера.
От первых штрихов до 2D анимации прямо в Unity
Демонстрация поэтапного создания одного кадра новеллы
Всё собирается в движке
Детали «раскладываются» в Unity как набор спрайтов. Создаются кости, настраиваются меши (сетки), назначаются веса влияния костей на точки. Особенно сложно с лицом: в этой сцене, например, брови и глаза были объединены в один меш, чтобы передать гримасу. Меши век собираются по особой логике — там кости работают как рычаги.
Всем привет!
Меня зовут Яков, не сказал бы, что я супер разработчик игр (в общей сумме у меня 20 тыс игроков со всех игр выложенных на Яндекс.Игры), но хотел бы поделиться опытом создания гибкой архитектуры игр в Unity с использованием DI-контейнера Zenject.
В статье не будет основ работы с Zenject, поэтому я надеюсь что вы уже знаете данный фреймворк.
В этой статье Вы узнаете, как создать легковесную систему комбо-атаки для 2D и 3D проектов с использованием машины состояний в Unity. Статья включает примеры кода и ссылку на репозиторий с полным проектом, что делает её полезной как для новичков, так и для опытных разработчиков, стремящихся улучшить свои навыки в создании игровых систем.
Посмотрел я наканунеэто видео и «вдохновился»… тем, что в видео показан очень сложный способ сделать очень простую вещь — миграцию пользовательских данных.
Если интересен контекст моего баттхерта, то стоит посмотреть оригинальное видео, если же нет — можно перейти сразу сюда к моей реализации...
Как любовь к играм и американским хоррорам привела меня к созданию визуальной новеллы.
Речь пойдет о предыстории разработки «Розового шума» — визуальной новеллы в формате интерактивного кино с проработанными анимациями, нелинейностью и духом старых добрых американских ужастиков.
В этой статье я расскажу, как разрабатывал виртуальную машину на C#, столкнувшись с проблемами производительности и управления памятью, а также поделюсь опытом, который приобрел в ходе работы.
https://www.youtube.com/watch?v=ZqW-WUt11vE
Создаём изометрический автомобильный PvP для мобилок — рассказываю, что готово и что нужно чтобы довести до MVP.
Когда я начинал разработку своей игры, то не смог найти каких‑то внятных гайдов с описанием архитектуры диалоговой системы. Зачастую авторы упоминали верстку да логику UI, но не отвечали на вопросы «как менять сюжетные стейджи», «как работать с разными типами диалогов», «как менять статус персонажам на сцене» и т. п. Мне не хватало найденной информации и я потратил какое‑то время на написание диалоговой системы самостоятельно. Для опыта конечно же… но и, будем честными, денег я зажал на готовые плагины. Надеюсь, что эта статья поможет таким же новичкам в Unity как и я, кто решил учиться разработке через практику и прототипирование. Небольшая оговор очка: я занимаюсь автоматизацией тестирования и мой основной язык python. Так что заранее прошу извинить за не самые лучшие конструкции C#. Также хочу упомянуть, что статья эта не про код, а про архитектуру, так что первого в принципе будет не так уж и много. А что за игру я делаю? Сюжетное 2д приключение, где я решил брать не механиками, а историей.
Часть 1. Планирование архитектуры
Без четкого ТЗ результат ХЗ. Для начала планируем и фиксируем, что хочется вообще сделать. На моем примере:
1) Система линейная, диалоги без вариантов ответа;
2) Каждая сцена — это грубо говоря отдельная игра, которая не связана с другими сценами, их все можно запускать независимо. Сохранения реализованы в момент перехода между сценами;
3) На каждой сцене есть n стейджей. На каждом стейдже m диалогов. Заканчиваются стейджи — на этой сцене заканчивается сюжет, можно переходить на новую сцену;
Всем привет! Я Ксения – пишущий редактор в блоге «IT для детей». Сегодня хочу рассказать об игровом движке «Юнити» и его возможностях, а также коснуться темы обучения ребят 10 лет и старше работе с инструментами данной среды.
В первую очередь отмечу, что Unity, как это заявлено на официальном сайте платформы, – комплексный продукт, предназначенный для художников, дизайнеров и разработчиков, принимающих участие в создании игр. Не считаю такую формулировку исчерпывающей, поэтому предлагаю погрузиться в теорию и рассмотреть возможности программы и ее потенциал.
