После многих лет работы с Flash и игровыми движками использующими его как оболочку, где все необходимо создавать вручную, а возможности ограничены парой-тройкой пунктов, новость о работе с Unity вызывала у меня эйфорию.

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



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

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

Сайты и паблики, новостные публикации, крупные пиар-акции, гайды по игре, брендовая одежда и мобильные приложения. Многое из этого было создано для того, чтобы заработать и пропиариться на волне хайпа вокруг Pokemon Go. Некоторым это удалось. Остальным — не очень.

История о разработке приложения, интеллектуальной собственности и «злых дядьках» из Google под катом.

Наш отважный герой, случайно забредший в запретную область ядовитых венерианских джунглей, окружён роем из десяти тысяч голодных полуразумных комаров. Вопрос съедобности человека для инопланетных организмов, с научной точки зрения, вообще-то, достаточно спорен — но венерианские комары, как известно, искренне разделяют позицию Маркса, что критерием истинности суждения является эксперимент. Казалось бы, положение безнадёжно — но герой, не растерявшись, извлекает из широких штанин инвентаря походный термоядерный фумигатор, красивым движением включает его, и…

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

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

Unity3D — один из самых перспективных и быстроразвивающихся игровых движков на текущий момент. Время от времени, в официальном репозитории появляются новые библиотеки и компоненты, многие из которых до недавнего времени были недоступны в виде исходников. К сожалению, команда разработчиков Unity3D предоставила на растерзание общественности не весь исходный код проекта, а только некоторые его компоненты, библиотеки и демки. В этой статье мы попробуем найти всевозможные ошибки и опечатки в них, используя для этого статический анализатор PVS-Studio.

Аналогов подобных теней для точечного источника света (Pointlight с эффектом размытия на расстоянии, имитирующий arealight) в компьютерных играх я почему-то до сих пор не встречал. Везде — либо полностью запечённые тени, либо «лампочки» вообще без теней, максимум — обыкновенная PCF-фильтрация. Хотя для направленного солнечного света уже давно применяются PCSS-тени (GTA5, например). В Unreal есть интересный алгоритм сродни рейтрейсингу, который рисует красивые arealight-тени, но только для статической геометрии (требуется генерация дополнительных объёмов). В Unity же всё совсем плохо — мягко фильтруется только солнечный свет, а «прожекторы» и «лампочки» в пролёте.

Осторожно, спойлеры и артхаус! Если вы в тупике и отчаянии, то эта статья должна помочь вам пройти игру. Плюс, технические подробности.

Предисловие

Это была самая странная, долгая и познавательная охота за ачивкой. Был изучен код игры, воссоздан API и реализован звездный навигатор для этой бесконечной космической одиссеи. Весь путь я проклинал разработчиков. Ведь, по сути, игра длится всего 10 минут. А дальше, дальше только пустота и надежда. Но как я рад теперь! Благодаря разработчикам и моему стремлению я многое узнал. Далее само прохождение.

    Добрый день, Хабр. В эфире снова я, Илья Кудинов, QA-инженер компании Badoo. В свободное от основной работы время я занимаюсь разработкой игрушек на Unity 3D и решил в качестве эксперимента написать статью об одной из проблем, с которой столкнулась наша команда. Я являюсь основным разработчиком, и наш гейм-дизайнер в «гробу видал» копание в моем коде с какой бы то ни было целью (разделение труда — одно из величайших достижений цивилизации), значит, моя обязанность — предоставить ему все необходимые рычаги управления и настройки геймплея в виде удобных визуальных интерфейсов. Благо Unity сам по себе имеет достаточно удобные (кхе-кхе) готовые интерфейсы и ряд методов их расширения. И сегодня я расскажу вам о некоторых приемах, которые делают жизнь нашего гейм-дизайнера проще и удобнее, а мне позволяют не биться головой о клавиатуру после каждого его запроса. Надеюсь, они смогут помочь каким-нибудь начинающим командам или тем, кто просто упустил эти моменты при изучении Unity.

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

Когда-то я пошел на ПОВТ (можете вставить свою специальность в IT) для того чтобы узнать как писать игры. Хотя обучение и было несколько отдалено от интересующей тематики, оно принесло фундаментальные знания, без которых было бы очень тяжело. Дальнейшая после выпуска работа в нескольких компаниях только затягивала в энтерпрайз, отдаляя от геймдева. Но, время от времени, покупая новую игру, или наблюдая за разработкой очередного тайтла, возникает очень навязчивая идея — «Хочу этим заниматься!».

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

За последний проект я взялся очень крепко и довел до стадии релиза.

В данной статье хотелось пройти по базовым этапам создания новой игры, с изрядной долей субъективного мнения. Я не буду углубляться в детали реализации и код — больше хотелось поделиться своим опытом и помочь тем, кто вынашивает свои идеи, но не предпринимает дальнейших шагов. Если вы готовы, то

Недавно мы побывали в Амстердаме на конференции Unite Europe 2016, где получили массу эмоций и интересного опыта. На этой конференции было очень много увлекательных докладов по разным направлениям и различного уровня сложности. Темой одного из выступлений была “Overthrowing the MonoBehaviour tyranny in a glorious ScriptableObject revolution”, на котором Ричард Файн (https://twitter.com/superpig / https://github.com/richard-fine), специалист из Unity Technologies, подробно рассказал о ScriptableObject и на примерах показал, как он может быть применен в проекте.

Scene View в Unity3D является одним из самых необходимых элементов интерфейса. Каждый, кто хоть раз запускал Unity3D пользовался Scene View для визуальной расстановки объектов на сцене, а также для их настройки. Расширение функционала Scene View может понадобиться для создания собственного редактора уровней, редактирования mesh’а, создания собственных gizmos и много другого. Стоит заметить, что при использовании Terrain в вашем проекте, его редактирование (рисование текстур, изменение высот, а также посадка деревьев и растительности) осуществляется при помощи Scene View.

Для того, чтобы иметь возможность писать скрипты работающие в Scene view в первую очередь класс с которым вы работаете должен быть унаследован от Editor или EditorWindow, что подразумевает подключение namespace UnityEditor. Это дает доступ к нескольким «магическим» методам Unity3D, таким как OnGUI() и OnSceneGUI(). Метод OnSceneGUI дает возможность Editor'у управлять событиями Scene View.

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

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

---

Что требуется для создания миникарты в игре на Unity? Наверно вы будете удивлены, но это проще, чем вы думаете и даже не требует навыков программирования! Далее я постараюсь шаг за шагом объяснить, как это сделать.

Привет, Хабр! В этой статье я расскажу о результатах публикации одной визуальной новеллы и поведаю о второй, при разработке которой я попытался учесть полученный опыт…
Перед интенсивной разработкой небольшой игры (aka хакатоном) важно решить чего вы хотите: программировать, повеселиться или создать готовый продукт? У меня есть друг, который очень хочет сделать игру, но раз за разом он начинает с создания графического движка, на базе libgdx. Возможно, такой путь приводит к шедеврам вроде {$TitleCoolIndieGame}. На мой же взгляд, ему просто хочется попрограммировать. Так, что Читатель, если же Вы действительно хотите сделать игру, лучше не начинать с абсолютного нуля или читать эту статью, а приступить к конкретной работе! Тем более, что под катом не success story, а согласование макетов полуголой девушки, вакуумные маффины в коне, безумная работа над переводом сомнительного юмора и ещё более сомнительных отсылок, описание ненормальной соло разработки, да немного программирования, чтобы соответствовать тематике.
Под катом десяток мегабайт графики и более десяти страниц текста.

Поводом для написания данной статьи послужила эта публикация про "хрущёвки", в которой была поднята интересная для меня тема программной генерации мешей в Unity.

Моя статья не предназначена для тех, кто уже давно работает на Unity, маловероятно, что здесь будет что-то новое для людей, знакомых с тонкостями Unity. Также для совсем новичков здесь возможны неочевидные "трудности" и зачем нужно что-то придумывать, когда итак в редакторе всё есть. Наиболее подходящей нашей аудиторией являются разработчики, которые уже кое-что умеют делать в Unity, но они ещё не решали задачи динамического изменения мешей в редакторе. Также, возможно, некоторым будет полезен наш опыт работы с инспектором.

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

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



Создание качественных скелетных 3D анимаций сегодня, пожалуй, самая труднодоступная для инди разработчиков задача. Вероятно поэтому так мало инди игр в 3D, и так много проектов в стилях пиксель арта или примитивизма, а также бродилок без персонажей в кадре. Но теперь это соотношение может измениться…

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

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

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

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

• 1 Необходимо обеспечить отрисовку большого числа анимированных объектов на сцене. Ведь мы хотим, чтобы игрок отстреливался от полчищ монстров.
• 2 Прогресс анимации должен быть различен для каждого из объектов. Ведь мы не хотим, чтобы мобы ходили строем.

Решение «из коробки»

Безусловно, первое решение было простым: все сделать с помощью уже встроенного в UnityEngine компонента Animator. Посмотрим, что из этого получается.

Введение

В прошлой моей статье были приведены способы обеспечения “мягкой” связи между компонентами игровой логики, основанные на уведомлениях и подписки на них. В общем смысле подобные уведомления можно посылать на любое, какое нам захочется, действие или событие, возникающее в работе компонента: от изменения переменной, до более сложных вещей. Однако зачастую определенные события требуют от нас выполнить ряд действий, которые нецелесообразно делегировать. Самым простым примером является звуковое оформление — в компоненте возникло событие, которое требует звукового сопровождения. В простейшем варианте мы вызовем функцию AudioSource.Play(), в чуть более сложном, функцию обертки над звуковой системой. В принципе ничего страшного в этом нет, если проект небольшой и в команде мало людей, которые совмещают в себе множество ролей, но если это проект крупный, где есть несколько программистов и саунд-дизайнер, то, в частности, настройка звуков превратится для программиста в кошмар. Не секрет же, что мы стараемся абстрагироваться от контента и поменьше с ним работать в плане настройки, ибо правильнее, если этим будут заниматься ответственные специалисты, а не мы.