Всем привет, меня зовут Григорий Дядиченко, и я технический продюсер. Недавно я столкнулся с одной интересной задачкой в ходе реализации проекта, и подумал что стоит наверное рассказать про физику в Unity, про нюансы работы с ней и про то, какие существуют альтернативные варианты в решении разных задач. Как связывать это всё дело с EventSystem и расширять Unity классы. Если вам это интересно - добро пожаловать под кат.
Мы привыкли, что разработка, особенно геймдев, — это долго и дорого. Нужно много людей: бэкенд, тестировщики, дизайнеры, маркетологи… И миллионы на продвижение. Но множество проектов инди разрабатываются даже сольными программистами, а некоторые в своё время просто взорвали рынок.
Давайте разберёмся, стоит ли вообще идти в инди. Сразу покажем прекрасный пример — игру RimWorld, пока у нас стартует курс по разработке на Unity.
Всём привет, меня зовут Григорий Дядиченко и я технический продюсер. Сегодня хочется обсудить подготовку 2д арта. Существует, скажем так, хороший тон в плане подготовки графических ассетов. Исходя из контекста технических ограничений и удобства дальнейшей работы. Больше речь про Unity3d конечно, но многие вещи работают везде одинаково и по сути меняются в нюансах. Если вам интересная данная тема, то добро пожаловать под кат!
По мере роста популярности нашего онлайн-шутера читеры все активнее его атаковали. Мы решили строить комплексную оборону по всем фронтам, где одним из шагов стала защита игрового процесса. Тогда взлому подвергались параметры здоровья, урона и скорострельности, кулдауны, количество патронов и многое другое — то, от чего в первую очередь страдали честные игроки.
Мы используем Photon Cloud для сетевого взаимодействия игроков, поэтому сразу стали искать удобное решение на его основе. И нашли Photon Plugin, который закрыл все потребности. Изначально его вводили только для защиты, но потом стали использовать и при разработке новых фичей, где требуется серверная логика. Как мы его внедряли — рассказал под катом.
Друзья, это продолжение серии статей по созданию шутера с использованием фреймворка LeoECS. В этой части мы реализуем несколько новых игровых механик и рассмотрим механизм взаимодействия ECS "мира" с MonoBehaviour-ами. Перед прочтением этой части не забудьте ознакомиться с предыдущей.
Какие движки наиболее популярны в 2021 году — да и вообще в последнее десятилетие? Очевидно, по всем параметрам лидирует Unity. Unreal, в свою очередь, — пожалуй, наиболее очевидный выбор для AAA. О таких выводах догадаться несложно, даже не имея на руках никаких численных данных. Но что, если все-таки попытаться их собрать?
Сайт gamedatacrunch.com максимально приблизился к реализации этой задачи, и его основатель Ларс Дусе на днях выкатил анализ движков paid-игр в Steam, выпущенных с 2010 года. В этой статье по нему мы тоже пройдемся, но и вспомним о том, какие еще движки сейчас в обиходе (и не только в Steam).
Аим-ассист — вечная тема для споров среди игроков. Для одних это узаконенный чит, для других — инструмент комфортной игры. Этическую сторону вопроса сейчас обсуждать не будем, просто примем как факт, что большинству пользователей неудобно целиться на геймпадах и тачскринах. И это проблема.
Пару лет назад в нашем онлайн-шутере вообще не было аим-ассиста и автострельбы. Даже в сторе было написано, что Pixel Gun 3D — «hardcore shooter». Нас это устраивало, пока не стало сложнее привлекать новую аудиторию. Даже несмотря на обучение и матчмейкинг, новичкам было сложно освоиться.
На рынке тогда уже были шутеры с автодоводкой, но она была слишком навязчивая, чересчур влияла на игровой опыт и скилл игрока. Нам предстояло разработать систему получше — чтобы не разозлить бывалых хардкорщиков и не отпугнуть новичков. Рассказываю под катом, что из этого вышло.
Прежде всего, хочу сразу отметить, что я не являюсь профессиональным разработчиком. Я обычный бакалаврик технического ВУЗа, так что незнание мною некоторых терминов прошу простить, не дорос ещё. Просто однажды летним вечером делать было нечего, как говорится, и я решил попробовать свои силы в создании игОр на всем известном движке Unity.
Начал я свою "разработку" с непосредственной установки Unity и тамошних туториалов aka курсов от самой Unity. Почерпнув оттуда основы основ в виде понимания, что такое объекты и компоненты в Unity, как-куда и на что вешать скрипты и тому подобное, я приступил к созданию своей первой игры. Попытки создания, по крайней мере.
Unity — это один из самых популярных движков на данный момент, составить ему конкуренцию может разве что Unreal Engine 4, но что у первого, что и у второго есть свои плюсы и свои минусы. Unity поддерживает почти 30 платформ, в их числе мобильные, виртуальная реальность, настольные компьютеры, консоли и так далее. Unity — это не просто хороший вариант для старта, это идеальный вариант для старта! Тут заложено использование гибкой модульной системы при создании сцен и персонажей в игре. Даже новичок способен создать крутой проект, используя готовые спрайты и конструктор движка.
Если же считаете, что готовы погрузится с головой в «кирпичную систему» для продвинутых, то тут есть возможность настройки практически любого компонента. К примеру разработка своего собственного шейдера или же переписать сетевой стек для потребностей своей игры.
Появилась возможность рассказать о том как мы создавали жидкость для TReload. Нам всего лишь нужно было залить уровни кислотой. Кислоты должно быть много, площади затопления огромные :) Один из финальных результатов:
Друзья, это первая статья по фреймворку LeoECS из предстоящей серии, которая позволит вам быстрее понять, как работать с LeoECS в Unity и решить некоторые виды проблем, возникающих на практике. Все советы, изложенные в них, не представляют собою какой-то свод правил, способы построения подходов, а скорее набор рекомендаций и best practices, которые помогут вам освоиться в работе с фреймворком. Перед чтением убедитесь, что вы понимаете принцип работы архитектурного паттерна Entity Component System (ECS), и ознакомьтесь с документацией LeoECS, так как в процессе изучения фреймворка мы создадим простую игру жанра Top-Down shooter, рассмотрим часто возникающие проблемы и способы решения, и отвлекаться на различные вопросы, связанные с концепцией ECS, не будем.
Одним из неотъемлемых элементов игровых приложений, обеспечивающих красочный пользовательский опыт, является анимация. Основным компонентом Unity для анимации является "Mecanim", имеющий более привычное название "Аниматор". Это очень мощный инструмент, позволяющий управлять сложнейшими системами объектов, совместимый со скелетными анимациями, экспортируемыми из 3D-пакетов, с инструментами для работы с IK, смешивания анимаций или частичного их проигрывания. И как только ты уверишься в том, что пробовал в аниматоре все, будь уверен - на следующий день ты найдешь новую функцию, с которой не сталкивался ранее. И это будет та самая функция, которой тебе так не хватало. Но не всегда...
Современные AAA-тайтлы уже давно стали весить больше 100 ГБ, а их апдейт еще на 20 ГБ считается обычным делом. Тот же тренд разрастания билда постепенно просачивается в мидкорные и хардкорные мобильные игры. Впрочем, к тому, что уже не удивляет ПК- и консольных юзеров, мобильные геймеры все еще довольно чувствительны.
Размер игры на релизе может оказаться гораздо больше необходимого, такое бывает. И даже тогда, когда кажется, что в билде осталось все только нужное, всегда найдется то, что можно оптимизировать и сократить.
В этой статье я бы хотел поговорить об архитектурном решении для Unity - GUA и объяснить логику работы. Если мы перейдём по ссылке нас встречает великолепное readme, где описаны правила работы с данным решением, но я бы хотел разобрать их подробнее с примерами. Пусть это будет бесплатной рекламой для автора.
Всём привет! Меня зовут Дядиченко Григорий, и я CTO Foxsys. В разработке я порядка 8 лет, а занимаюсь игровой или AR/VR разработкой последние лет 6. Сразу скажу, что в данной статье нет простого ответа “этот игровой движок лучше”, и она не претендует на объективность. Я лишь расскажу мнение с точки зрения технического директора и человека за плечами которого порядка 40 коммерческих проектов. Если вам интересно — добро пожаловать под кат.
ри разработке игры не всегда есть время на создание отдельных элементов, например, моделей или звуков. Как раз для таких случаев существуют библиотеки ассетов, из которых можно взять нужный контент. Обычно там есть как бесплатные, так и платные ассеты.
Но важно учитывать, что у ассетов есть разные условия использования: например, у одних может вообще не быть ограничений, а у других нужно указывать автора. Поэтому всегда читайте условия, если хотите добавить в свою игру чужие наработки.
Ранее на DTF уже выходили подборки ассетов. К примеру, Арсений Мирный опубликовал список полезных ресурсов для поиска ассетов. Есть подборка от Дмитрия Чикалова, который упомянул не только библиотеки, но и полезные медиа-ресурсы. Иван Михайлов в своём внушительном списке программ для разработчиков также рассказал про библиотеки ассетов.
Наша подборка перекликается с другими списками, но мы выбрали самые удобные ресурсы, в которых легко найти нужные ассеты в условиях ограниченного времени.
Этот материал написан в поддержку нашего инди-джема, в котором ещё можно успеть поучаствовать.
Всем привет, последние года три мое основное хобби – создание игр. Не могу сказать, что я добилась чего-то сверхъестественного, но в Steam есть две мои игры (горжусь самим фактом доведенных до конца проектов, но сейчас многое в них уже поменяла бы). И обе эти игры сделаны на движке Unity.
Почему на нем?
Когда не знаешь ничего о создании игр и только начинаешь погружаться в тему, именно он всплывает первым как очевидный вариант для ознакомления. О нем много информации, куча курсов, уроков, в том числе и на русском, даже книги выпускают и переводят. Он бесплатный, в конце концов, а в сети можно найти множество примеров успешных проектов, сделанных на Unity. В общем выбор казался очевидным. И в целом меня все устраивало, хоть и были недостатки. Однако свою третью игру я начала делать на движке Godot. Здесь я расскажу причины, а также поделюсь своими первыми наблюдениями о плюсах и минусах этого перехода.
Разработка игр с многотысячной пользовательской базой и постоянно накатывающимися обновлениями — комплексный процесс. Он включает в себя не только работу над новым контентом и фичами, но и оптимизацию процессов, чтобы все происходило гладко, и разработчики, аналитики, QA-инженеры постоянно получали новые билды.
DevOps — это и есть набор методов, благодаря которым можно сократить время разработки и ускорить выпуск обновлений. А CI/CD, или непрерывная интеграция и доставка — это не сколько технология, сколько целая культура, позволяющая чаще и надежнее производить небольшие изменения в игре с частыми коммитами, доставлять модули проекта в разные отделы и автоматизировать их тестирование. Все это представляет собой целый пласт работ — эдакий невидимый игрокам фронт.
Изначально, до старта работ над War Robots Remastered, у нас уже был выстроенный пайплайн CI/CD для всех проектов, и оригинальная War Robots не была исключением. Сам проект тогда в среднем собирался 40-100 минут. Но чем дальше продвигалась работа над ремастером, чем больше накапливалось проблем со скоростью сборок. Спустя полгода проект стал собираться от 3-х часов и больше с периодическими зависаниями, которые могли доходить до 7-10 часов. Это становилось совсем неприемлемым: QA в динамике не могли проверять билды, разработчикам тоже приходилось тратить время на ожидание, чтобы посмотреть результат или начать профилировать. Пришлось серьезно подумать над тем, как все это чинить и возвращать время сборок к исходному значению.
