Unity *

Игры во многом построены на условиях. Если скорость больше нуля, надо сменить айдл анимацию на что‑то другое. Если хп меньше нуля, персонаж считается мертвым. Если у персонажа 10 клыков, он может сдать квест. Если в руках лазер, надо зажать ЛКМ для непрерывной стрельбы. С ружьем обычно так не получается, здесь одно нажатие — один выстрел. Если в руках молоток, то всё превращается в гвозди.

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

В какой‑то момент таких условий в мета геймлее становится много, и хочется их как‑то структурировать. И эта статья как раз может в этом помочь

Игровой движок Юнити можно освоить на онлайн‑курсах в школе программирования. Хотим отметить, что уроки будут полезными: удастся разобраться не только в разработке игр, но и в написании кода на одном из относительно сложных языков — C#.

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

Все еще собираешь билды вручную? Тогда статья идет к вам!

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

В этой статье мы разбираемся, что такое CI/CD, какие сервисы доступны Unity-разработчикам и как сделать процесс релизов быстрее и удобнее.
Также рассмотрим как внедрение автоматизации упростило процесс релиза в нашей компании

Pure.DI — это генератор исходного кода C# для создания композиций объектов в парадигме чистого DI. С версии 2.1.53 в нем появились новые возможности, которые будут полезны разработчикам игр на Unity. Предлагается познакомиться с ними на этом примере.

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

Казалось бы, техническая сторона графики у игр, созданных на одном игровом движке, должна быть более-менее схожей. Вот я и приступил к реверс-инжинирингу рендеринга Genshin Impact, не питая особого энтузиазма, ожидая увидеть там что нибудь вроде Universal Render Pipeline, стандартного решения для мобильных игр на Unity, с шейдером Cell shading для отрисовки персонажей. Но реальность преподнесла немало сюрпризов...

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

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

Наверное, все игровые разработчики знают, как происходит рендеринг. Ну там вертексы, треугольники, растеризация, буфер экрана... Но детали процесса для многих внезапно являются сюрпризом. Например, сколько раз рендерится объект в Unity (да и в других движках) в обычном случае? Один?... Если разработчик отключит все что можно, то да. Но как правило - минимум 2. А может быть и 8 раз. Как так? Добро пожаловать в удивительный мир рендеринга...

Ловили ли вы себя когда-нибудь на мысли, что, будучи C# .NET разработчиком, вы можете попробовать начать разрабатывать игры на Unity3d? Ведь язык используется тот же. А точно ли тот же? Точно ли код, написанный для .NET, может без проблем быть скопирован для выполнения в Unity3d приложении? Давайте в этом разберемся и поймем, какие дополнительные знания необходимы C# .NET разработчику, чтобы с комфортом разрабатывать игры.

В этом практическом руководстве мы расскажем вам о том, как разместить WebGL‑билд Unity в системе управления обучением (LMS) с отслеживанием по xAPI. На сегодняшний день LMS‑платформы, такие как SCORM Cloud, являются самым популярным решением для доставки и отслеживания учебного материала в онлайне. Интегрировав xAPI в свой проект Unity, вы сможете отслеживать детальные взаимодействия с учащимися и отправлять эти данные в выбранную вами LMS.

В этом руководстве мы используем в качестве примера SCORM Cloud, но эти шаги применимы к любой другой LMS‑платформе, совместимой с xAPI.

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

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

Привет, читатель! Вот уже три года я провожу собеседования на позиции Unity-разработчиков. За это время я просмотрел более 500 кандидатов на позиции мидла и сеньора, провёл свыше 100 интервью и нанял более 20 Unity-разработчиков. Этот опыт помог мне выявить множество "зелёных" и "красных" флагов, которые помогают определить подходящих кандидатов.

Эта статья будет полезна всем Unity-разработчикам — от Junior до Senior, а также лидам, которые проводят собеседования.

С детства я обожал игры и мечтал когда-нибудь сделать свою. И вот спустя 20 лет мне это удалось (ну, почти).

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

🟥 >> Я начал разрабатывать игры в 12 лет
-> В 15 начал зарабатывать первые деньги с игр (~5000₽/месяц)
--> В 16 лет создал свою студию игр GAMEDEV ADULT
---> Через полгода выложил игру на которой в сумме более 1.000.000 игроков
----> В 17 лет стабильно зарабатываю больше ~150.000₽ в месяц
🟥 << Продолжаю развиваться в сфере Геймдева
*Пруфы и цифры будут дальше

Продолжаю описание внутреннего устройства шаблона 3D-игры с ходьбой по ленте Мёбиуса.

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

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

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

- Почему сделать хорошую игровую камеру сложно
- Что такое Cinemachine и как его установить
- Как настроить базовую виртуальную камеру Cinemachine
- Как комбинировать ракурсы с помощью Timeline

Полистал курсы от коробок навыков, мозгов гика и даже Великого Романа Сакутина и не нашел ответа на дефолтный вопрос с джуновых собеседований: "Что же такое .NET, Mono, компилятор, рантайм и прочие ругательства"...

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

Многие крупные проекты в Google Play при первом запуске требуют прочитать и принять пользовательские соглашения: обычно это Privacy Policy и Terms of Use.

Однако в Web-проектах, например на Яндекс.Игры или VK Игры, такого не встретишь. И не понятно, нужно ли это там. Я провёл небольшое «расследование» на площадках, и, кажется, понял, как это устроено.

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

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

В 2014 году в движке Unity набралось столько критических изменений и новинок, что «пятерка» фактически была другим движком. И хотя многие за одинаковым фасадом не особо этого и заметили, но изменения коснулись всех компонентов движка, начиная от файловой системы и заканчивая рендером. Питерский офис EA имел свою ветку основного репозитария, отставая от мастера максимум на месяц. Я уже писал про различные реализации и типы строк в игровых движках, но в Unity была своя реализация, имевшая как положительные так и отрицательные стороны, которая использовалась практически во всех подсистемах. К ней привыкли, знали слабые стороны и плохие «use cases» и хорошие «best practices». Поэтому когда эту систему стали выпиливать из движка много чего поломалось, и если у обычных пользователей был сразу переход на новую версию и наблюдались только отголоски шторма, то допущенные до «тела» наловили много прикольных багов.