Участник:6opoDuJIo/Unity3D

Материал из Lurkmore

Эта статья находится на доработке. Эта статья всё ещё не взлетела и не соответствует нынешним реалиям /lm/. Но добрый 6opoDuJIo приютил её в своём личном пространстве, и теперь она может тихо гнить неспешно дописываться здесь вечно. Модераторам: выпустить Дата последней правки страницы: 26.03.2015

Логотип

Unity3D — басурманский, проприетарный игровой движок, сочетающий в себе такие качества, как гибкость и удобство скриптинга (официально поддерживается три языка, но при особом желании можно прикрутить ещё[1]), возможность работы с туевой хучей форматов (а в случае, если формат не поддерживается, то движок может попробовать импортировать файл при наличии программы, что работает с ним, я гарантирую это!) и кроссплатформенность, которую ввиду обилия платформ для публикации стОит выделить отдельно (об этом ниже). Благодаря этим качествам, выгодно выделяется на рынке, а так-же привлекает внимание безудержных полчищ малолетних долбоёбов, ввиду чего обилие говноподелок на форумах в духе гд.сру превышает все допустимые и недопустимые пределы.

Возникновение

Движку (как и Unity Technologies) положили начало трое развесёлых ребят David Helgason, Nicholas Francis и Joachim Ante после былинного провала их игрульки под мак под названием GooBall. ИЧСХ, Unity3D стал первым дижком, что полностью поддерживается в IOS. Стартовали только как движок под тот-самый б-гмерзкий мак, теперь поддерживает множество платформ, но при этом, лицензия на каждую платформу покупается отдельно (для Windows, Linux, и MAC OS лицензия бесплатная с тем лишь допущением, что компиляция под MAC OS возможна только из-под самой MAC OS, редактор под макось также в наличи. Возможность построения под Windows Store и WP8 покупается отдельно.

Плюшки

◄ ►

Сдобренное лулзами демо рендеринга в реальном времени на четвёртой версии движка

Старенькое техническое демо — 30 миллионов полигонов в реальном времени

Большинство других игровых движков представляют собой либо конструктор, в котором хуй что сделаешь из-за ограничений, либо наоборот, просто набор библиотек (или даже исходники), которые можно крутить как угодно и на чём угодно, имея при этом едва ли не запредельную сложность работы и малую наглядность результатов. В свою очередь, Unity3d является и тем и тем сразу — встроенный редактор можно использовать для компоновки уровней, а также облегчает ознакомление + можно игру запустить прямо в редакторе, чтобы просмотреть изменения (при этом, такой ход позволяет отследить состояние всех объектов в сцене, что очень помогает в разработке). С момента выпуска версии 2.6.1 имеет халявную версию, в которой выпилены некоторые плюшки (тем не менее, движок на Free лицензии чуть более чем юзабелен). Pro-версия стоит 1500 вечнонефтяных. На момент написания статьи имелась уже версия 4.1, содержащая в себе следующие приблуды:

• Библиотеку для работы с анимацией aka Mecamin. Детище сумрачных гениев из бунжундии, познавших дао в анимации. Отлично помогает в деле анимировании персонажей. Имеет в себе аж два вида рига — generic и humanoid. Разница заключается в том, что анимация с humanoid ригом может быть использована на других моделях с гуманоидным ригом. EPIC WIN! Теперь не нужно анимировать каждого персонажа отдельно. Называется это Retargeting'ом. generic риг тоже годен к смешиванию анимаций, но не к ретаргетингу. Правда, если модели немного отличаются анатомически (длинна рук-ног-прочее) то получится УГ. Такой же безблагодатный результат можно получить, если начальные позы моделей, что взаимодействуют в ретаргетинге, отличаются, или если поза в первом и последнем кадре анимации сильно отличаются (тогда просто портится анимация при установке флага LoopPose, который показывает, должна ли анимация быть цикличной). Алсо, имеется встроенная система инверсной кинематики. Что это значит? Это значит то, что руки анимируемого персонажа не будут проваливаться в стену, если он в неё упрётся руками (в анимации, что совершает такое действие). Так-же, всё это доступно из скриптов. Встроенный Animation Controller позволяет смешивать, переключать, накладывать друг на друга (в том числе по маскам, в которых задаются кости/части тела (для гуманоидных ригов), которые будут анимированы в том слое, к которому эта маска будет применена) анимации как душе угодно. При этом, старая система aka «legacy» не выпилена. Доступно как нахаляву, так и в PRO-версии.
• Встроенный рейтрейсер aka Beast lightmapper. Позволяет запекать статическое освещение уровня. Выглядит лучше, чем встроенные тени, но хуже, чем освещение во многих других движках. Но в целом, сносно. Настраиваемо. Доступно только на Pro-версии.
• Редактор регдоллов (aka тряпичные куклы aka трупы). Позволяет сотворить тряпичную куклу без особого геморроя. По сути, является автоматическим конфигуратором character joint-ов (сочленение, имеющее свои ограничения, как суставы). С момента выпуска версии 2.6.1 дизайн традиционно не изменяется. Создание рэгдолла осуществляется перетаскиванием костей в соответствующие поля в редакторе. Персонаж должен быть в позе гражданина и смотреть вдоль оси Z.
• Объёмные источники света. Название говорит само за себя. Только для лайтмаппинга, во время выполнения не котируются и теней не отбрасывают.
• Audio Reverb Zone — эдакий убершушпанцер для создания эффектов эха в туннелях, помещениях и прочих. Доступно во Free и PRO.
• Редактор ландшафтов. Кривоватый инструмент для создания больших площадей. Невозможно использование пещер без напильника. Сами ландшафты являются штукой довольно жручей, но эпичность получаемых открытых пространств доставляет неимоверно.
• Speedtree. Используется в ландшафтах. Суть в том, что в качестве настоящей модели ставятся только ближайшие к активной камере деревья. Остальные же преобразуются по алгоритму true imposters. Так-же, деревья имеют свойство гнуться, благодаря Wind Zone.
• Магазин ассетов aka Asset Store. Тут можно купить чужие модели/недоделки по скриптингу (если сам умом не дорос). Годнота есть, но её мало. Часть бесплатно. Требует регистрации. Так-же, стоит отдельно отметить имеющийся там плагин для магазина Mixamo, установив который, открывается доступ ко второму магазину, который специализируется на анимациях (кстати, можно за 750 баксов получить к этому магазину неограниченный доступ — всё будет бесплатно!). Asset Store доступен прямо в редакторе, но невероятно тормозит даже на хороших машинах, поэтому чаще используют обычный браузер. Не очень подходит ценами для славянских земель, ибо не проблема найти ассет, который по стоимости превосходит месячную зарплату какого-нибудь эникейщика или продавца обуви.
• Возможность использования подгружаемого контента aka Asset Bundles. Используется преимущественно для браузерок. Суть в том, что какие-то ассеты (модели, текстуры, материалы, что душе угодно) запихиваются в отдельный файл, после чего загружаются с сервера уже в процессе игры. Скрипты при этом остаются скриптами, после этого их нужно компилировать самостоятельно (но в C# такая возьможность все-таки имеется, нужно только сделать бочку). Либо компилировать такие скрипты в отдельную библиотеку, запихать в папку с ассетами и запихнуть в бандль, после чего исполнить стандартные трюки по впиливанию кровавого патчинга (спойлер: этот способ ничем пока не проверялся, но теоретически должно сработать.).
• Удобный и noob-friendly скриптинг. Нет, правда удобный! Для написания Hello World не нужно создавать проект в IDE, ставить кучу зависимостей и обьявлять какой-нибудь метод, вычлененный откуда-нибудь из документации. Нет! Всё куда проще — проект для Visual Studio (или MonoDevelop) создаётся самим редактором. Заготовка скрипта — тоже кнопкой из редактора. Приводится же в действие скрипт навешиванием его на гейм-объект в сцене. (спойлер: Стоит только отметить что для запуска при старте скрипт должен содержать некоторый код в методе Start.)
• Собственный язык для программирования шейдеров aka Shaderlab. Во многом, неплох. Полностью документированы впиленные разработчиками приблуды. Остальное совпадает со справкой от NVidia.
• Встроенная физика PhysX.
• Поддержка симуляции физики тканей.
• Поддержка тесселяции и вычислительных шейдеров в DX11.
• MovieTexture — позволяет использовать твой любимый прон с лолями в качестве текстуры. Звук при этом становится отдельным ассетом, который нужно самостоятельно прикручивать в сцену, а MovieTexture'у ставить на воспроизведение уже из скрипта.

◄ ►

Встроенный гуец — уже на лурке

соус

Как это могло выглядеть. Пичальбида

• Встроенный гуец. Отличается умом и сообразительностью излишней тормознутостью, фимозностью и нихуя не компонентной системой (это вам не формошлёпство в Visual Studio!). Для отображения элемента необходимо вызвать какой-нибудь метод из класса GUI или GUILayout. Разница между ними в том, что во втором случае координаты рассчитываются автоматически, а в первом случае их нужно указывать самому. При этом, координаты ставятся не точкой левого верхнего угла, а задаются четырьмя значениями — x, y координаты левого верхнего угла и ширина с высотой. Сам гуй тратит минимум по одному DrawCall на элемент, что провоцирует тормоза на сложных гуйцах, за что нелюбим в сообществе. Разработчики давно уже обещают новый гуй, но вместо этого, пытаются ускорить старый. Выпуск нового же гуйца отложили на неопределённый срок, но вопросы в духе «а когда выйдет новый гуй?» все ещё время времени всплывают в сообществе.
• Встроенный профайлер. Считай что внутренний диспетчер задач. Как вариант — посмотреть сколько времени уходит на выполнение того или иного вызова в каждом кадре. Или посмотреть на расход памяти. Информация записывается, поэтому можно запустить профайлер на запись, после чего выключить сцену и изучить данные в спокойной обстановке. Чрезвычайно полезная штука, можно подключать и к уже построенной игре. Доступна только в PRO.
• Если вы кибер-маньяк (или ёбнутый на всю голову байтоёб), и при этом обладаете бездонным кошельком, то можно за сотни нефти приобрести исходники движка.
• Встроенное сетевое решение (UDP). Тоже вин, несмотря на то, что порицается многими. Вполне юзабелен. Впрочем, никто не запрещает изобрести свой велосипед на сокетах или купить стороннее решение в AssetStore.
• Для встроенной сети — совершенно халявный мастерсервер. Для любой лицензии. С крякнутой версией движка тоже работает.
• Возможность использовать настраиваемые текстуры aka Algoritmic Substance. Полноценного редактора таких субстанций в Unity нету, можно только настраивать значения, которыми эта субстанция обладает. ЧСХ, их использование чревато падением плагина Web Player'а.
• Нативные плагины — для байтоёбов без шекелей. Возможность использования оных предоставляется PRO лицензией. Впрочем, никто не запрещает использовать p/invoke если захотелось вдруг потеребонькать тёплый, ламповый C++. Среди плагинов все-таки выделяются плагины рендера, которые позволяют вклиниться в конвейер рендерера, из чего, при наличии рук, можно извлечь профит.
• Unity2D — как 3D, только 2D. Для тех, кто не осилил перевод камеры в ортографику, запилили движок в движке. Автор правок не имеет представления о том, что это за адовая поебень и нахуя она нужна. По отзывам, штука глючная.
• И множество других мелких плюшек, в духе настраиваемой гравитации, изменяемой скорости течения времени (для SLLLLLLLOOOOOOOOOOOOW MOTION, например).
• And even MOAR…

Редактор

Сферический вид в вакууме

Редактор представляет из себя компоновку из нескольких окон. Это окно компоновщика сцены (Scene view), окно игрового рендера (Game View), окно ассетов (тут находятся все игровые ресурсы) и окно инспектора (Inspector) в котором отображаются свойства выделенного элемента. Это базовый набор окон. Среди прочих стандартных имеются ещё окно запекания NavMesh'ек, окно запекания карт освещения (LIghtmaps) и окно запекания Occlusion Culling. Полный список возможных окон предоставить невозможно, ибо редактор скриптуется и каждый быдлокодер может нагавнякать своё окошко, с кривозубыми англичанками и мечеными картами. Окно Inspector'а содержит информацию о всех компонентах, что являются прикреплёнными к выделенному объекту. При этом, каждый компонент имеет свой собственный инспектор, который тоже можно задать самостоятельно. В общем, даже в редакторе гибкости over9000. В остальном, редактор даже в плане компоновки сцены имеет кучу плюсов, такие как shooter-like контроль за камерой компоновщика сцены (то есть просто mouse + WASD (а ещё E+C, в общем, гуглите)), и, немного минималистичный, ничем не перегруженный интерфейс.

Скриптинг

О скриптинге

Объёмен ровно настолько же, насколько и оказуален. Основная модель скриптинга Unity — компонентная. То есть каждый скрипт обычно является компонентом (класс, который наследует от класса MonoBehaviour) и добавляется к геймобъекту. При этом, бо́льшая часть наиболее вероятных к использованию компонентов уже завёрнута в свойства, для всего остального существует метод GetComponent. Основные методы таких классов это Start, Awake, Update, FixedUpdate, LateUpdate, и коллбеки коллизий — OnCollisionEnter, OnCollisionStay, OnCollisionExit. По большей части, всё-таки это всё тот же C#, только лишь с тем отличием, что находится в окружении расово неверного Mono. Остальные встроенные языки являются какими-то ебанутыми унтершпрехерами, которые все-равно потом компилятся в CIL, и типы которых таки доступны через отражения. Ниже приведены методы, необходимые чуть ли не каждому уважающему себя классу-наследнику MonoBehaviour:

Start

Вызывается при установке объекта(при этом, этот метод вызывается только в случае, если объект активен, ГО можно включать-выключать, не удаляя из сцены). Конструкторы при этом использовать не рекомендуется: если объект находится в сцене, он будет установлен в отличном, от главного, потоке при загрузке сцены. Также конструктор может вызваться в процессе работы редактора даже если целевой объект лежит тупо в ассетах.

Awake

Вызывается при установке объекта, но вне зависимости от того, активен он или нет. Вызывается перед Start.

Update

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

LateUpdate

Вызывается в каждом кадре, но уже в последнюю очередь, уже после Update. Возможный вариант применения — коррекция позиций костей на анимируемой модели, как это было в винрарном компоненте Locomotion ещё на старенькой 2.6.1.

FixedUpdate

Метод, который вызывается через равные промежутки времени (алсо, расчёты физики, коллизий и прочей хуеты происходят именно в очереди вызовов FixedUpdate, если не задать иначе, что, кстати, возможно указать для каждого объекта по отдельности).

Коллбеки физики и коллизий

Методы, которые вызываются встроенным в Unity физическим движком при некоторых условиях, таких как столкновение или вход в триггер. Для методов на случай столкновения приходит параметр с типом Collision, а для событий триггеров приходит параметр с типом Collider. При этом, метод может не иметь параметров вообще, это допустимо, движок всё поймёт и простит. Для физики есть несколько допущений, настроек и нюансов, с которыми можно ознакомиться на соответствующей странице. Главное в той ссылке — это Contact Action Matrix. Суть в том, что коллбеки коллизий вызываются только в определённых случаях, ибо Rigidbody (без которого эти методы могут быть вызваны только пользовательским кодом) может быть Kinematic, а коллайдер может быть триггером/статичным. В общем, курите мануалы. Внизу представлены только вызовы для коллизий, ибо методы для триггеров аналогичны, с тем лишь допущением, что используется другой тип для единственного параметра.

OnCollisionEnter

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

OnCollisionStay

Вызывается в каждом FixedUpdate между OnCollisionEnter и OnCollisionExit. Что можно тут сделать? Можно отслеживать нахождение какого-либо объекта на другом объекте. Фантазию проявите, блеать.

OnCollisionExit

Вызывается в момент прекращения коллизии.

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

В общем и целом, скриптинг, ввиду частичной совместимости с .NET (а частичная она потому, что в Unity находится не самая свежая версия Mono), может результировать в получение как неиилюзорного бугурта, так и не менее неиллюзорного WIN'а, ибо перед программистом лежит практически вся мощь .Net (и немного native, для случая с построением в Stanalone). Отдельный бонус — для компиляции unsafe не требуются никакие танцы с бубном, просто нужен выделенный блок, а так-же можно использовать сборки, что требуют разные версии фреймворков (тем не менее, типы из тех-самых, к примеру, четвёртых дотнетов загружены НЕ БУДУТ, ибо их нету. Но если используется только то, что есть в Mono, то всё будет пучком). Даже в WebPlayer и прочих можно использовать собственные сборки, главное чтобы они были совместимы с таблицей совместимости (Achtung! Многа букав!) типов и были managed.

При этом, поощряется использование одного громадного костыля под названием SendMessage — это метод, который вызывает методы всех скриптов на целевых ГО (называют этот ёбаный стыд посылом сообщения). Само же название такого метода задаётся строкой. Таким образом, всё что нужно для вызова метода — это поле с типом GameObject (или, Transform), которое уже используют для вызовов методов скриптов через SendMessage. Изобилующие такими SendMessage официальные примеры и туторы только усугубляют ситуацию, что ведёт к формированию совершенно идиотского шаблона, в котором нету ни одной ссылки между классами и ни одного обращения к полям/свойствам, а одни только лишь SendMessage. Крайним случаем долбоебизма является взаимный обмен сообщениями при необходимости получить значение какого-либо поля — один скрипт шлёт сообщение другому (например, SendFragsToMe)и он в ответ шлёт сообщение с нужным значением (продолжаем — SetFrags). Через это говно прошёл едва ли не каждый из практикующих разработчиков, так что это так же естественно, как обосраться в ясельном возрасте (что ни разу не отменяет того, что от такой хуйни нужно избавляться).

Asset store

Вот так вот оно выглядит

Местная барахолка, типичная помойка, в которую сваливаются (главным образом) донные недоделки, так и не ставшие компонентами игрищ. Иногда есть годнота, Prime31 тому пример. Это могут быть модели (по ценам дороже, чем в сквиде), текстур-паки, анимации, недоделки по скриптингу, плагины к редактору и прочее, по разной цене, от нуля до over9000. С полной спискотой лучше ознакомиться на сайте ассет-стора[2]. При этом, сам магазин доступен и из редактора, но тормозит похлеще того-же Steam'а, поэтому желательно использовать браузер. ЧСХ, не является DRM и не имеет такового в принципе, так что ничего не мешает передать купленные ассеты кому-то из знакомых/любовницам/боссам/друзьям/родителям/собаке/кому угодно. Довольно много кода идёт в виде исходников, а не в виде библиотек (такова традиция, ИЧСХ, обоснованная, ибо делать правки для успешного впиливания приходится чуть реже чем всегда).

Платформы для публикации

Платформы для публикации. Их не тысячи, но количество все равно впечатляет

Платформ для публикации несколько. Платформы пусть и переключатся прямо из редактора (что не составляет проблем, буквально несколько кликов) но на каждую действуют ограничения своего sandbox'а. Например, в WebPlayer нельзя будет использовать Platrofm Invoke, нельзя получить спискоту нитей процесса. На мобильниках ограничений ещё больше (например, недоступны MovieTexture)

Standalone

• Платформа по-умолчанию. Доступна всегда и везде. Совмещает в себе возможность компиляции сразу под три оси: Linux, Windows и Mac OS. Совершенно бесплатна, но с двумя условиями — на бесплатной версии ДВИЖКА вырезана часть функционала (тащемта, тени, лайтмаппинг, инверская кинематика в меканиме, и прочее, смотрите страницу сравнения лицензий.).

Web Player

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

Google native client

• Построение в неведомую ёбаную хуйню за авторством Гугла, что находится в стадии беты и поддерживается только в Chrome, ввиду чего нужна всего трём с половиной анонимусам, которые и играют в такие игры (если они запускаются).

Android

• Позволяет производить компиляцию в приложения для ведроида. Все значения ключей и подписи можно установить прямо из редактора Unity, так что с этим проблем нет, главное не проебать ключи. Требует покупки отдельной лицензии, причём их две — basic и pro. В апреле 2012-го года basic лицензию раздавали нахаляву. Кто успел — тот и съел. Отличия лицензий basic и pro можно посмотреть на странице сравнения версий.

IOS

• Как андроид, только IOS. Вот только требует запуска на Mac OS для проведения компиляции. Лицензии такие-же, как и в Android.

Flash

• Компиляция во Flash 11. Результат убог и б-гмерзк, иногда компиляция не проходит по мало-понятным причинам, ещё больше ограничений, чем на веб-плеер. Требует покупки отдельной лицензии. Поддержка компила во Flash выпилена ввиду долбоебизма Adobe.

Blackberry

• Щито?

Wii, Xbox, PS3

• Самые ИЛИТНЫЕ (с большой буквы, причём с каждой) платформы. Лицензии на них не просто не находятся в свободной продаже, эти лицензии недоступны даже из кряков! Для покупки следует связаться с саппортом.

MS Store и WP8

• Имеется. Основной лулз таки в том, что в итоге, билд вертится под .Net-ом, а точнее той его кастрированной версией, что используется для приложений MS Store (aka Metro aka Modern-style aka -Ёбаная-таджикская-плитка-). И использует библиотеки именно из дотнетовского GAC. А под крылом редактора продукт таки использует библиотеки из стандартного GAC моно. В итоге — шапито: разрабатывается под один API, билдят под другой.

Русское сообщество

Ипавлов знает толк в сортах оптимизаций

Существует неплохое русское сообщество. Также этим комьюнити было образовано аж три тёплых ламповых чатика в скайпе. Вход по инвайтам от кого-то из администрации или кого-то оттуда. Имеются три чата, это «Цех моделлеров». «Болтушка», «Песочница». В первом тусят 3D-шники и художники, второй является местным /b/, но в основном скорее мёртв, чем жив, а третий является основным чатом, где задаются вопросы, идиотские и не очень, а также общение на смежные темы.

Unity Answers

Сабжевый форум из загнивающего запада. Некоторое время, с обязательной регистрацией даже для просмотра. Исключительно на английском языке. Содержит 95% ответов на возникающие вопросы, ссылки на туторы, иногда используется для пиара. Алсо, иногда используется для фидбека с последующей провокацией багрепортов.

Дисциплины Special Olympics

Как и везде, в среде юнитологов существуют свои особенные дисциплины Special Olympics. Тысячи их, но представлены будут лишь некоторые:

Как получить доступ к переменной другого скрипта?

Регулярно этот вопрос задаётся неофитами и является едва ли не локальным мемом. В основном, его задают люди что мало знакомы с программированием вообще. Отчасти, является отголоском присущего юнити стиля скриптинга.

Почему тени хуёвые?

С тенями в движке и в правду проблема. Со времён Unity 3.0 ситуация улучшилась и теням, создаваемым в реальном времени, можно придать мало-мальски божеский вид. Тем не менее, по сравнению с крузисом, анрылом и прочими, тени неумолимо уёбищны, sad but true. (спойлер: В версиях ДО 3.0 тени безумно пикселили и вообще было ощущение, что их делали на "отъебись")

Пишу на C#, как обратиться к скрипту на JS?

Скрипты на JS и C# взаимодействуют друг с другом со скрипом. Типичный выход — это инкапсуляция поля в метод, который вызывается потом через SendMessage. Более продвинутые используют отражения (приблуда в .Net, позволяющая получить информацию о поле, типу или методу, не зная о чём идёт речь на момент компиляции).

Делаю мультиплеер. Как узнать кем установлен объект?

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

Как сделать MMO?

• nuff said

Я НЕ ЗНАЮ ПРОГРАММИРОВАНИЕ, ПИШУ КАПСОМ И У МЕНЯ ЕСТЬ ОТЛИЧНАЯ ИДЕЯ, ПОМОГИТЕ НАПИСАТЬ ИГОРЬ!

• Типичная просьба невменяемых помочь им в написании УБИЙЦЫ КРУЗИСА со стопроцентной гарантией успеха, при том, что в 95% 100% случаев его «идея» является ничем иным, как бредом, придедшим в его межушный ганглий (при наличии оного) в пьяном угаре или во сне, и умещается максимум в пару абзацев текста, являющихся комбинацией из выражений в духе «как World Of Warcraft», «БЕСШОВНЫЙ МИР», «ОЧУМЕННАЯ ФИЗИКА», «ГРАФОН». Присоединяются к ним обычно такие-же школьники или студенты, а до состояния минимальной играбельности обычно доходит чуть более процента. Хоть это и является обычной ситуацией в любой ГД-среде, и проЭктов движков на C++ чуть более чем овердохуя, тут подобный рак начинает набирать обороты благодаря возрастающему количеству браузерных игр на сабжевом движке, отчего движок становится все более и более известным среди красноглазой фауны. В большинстве случаев, результатом являются кривые клоны игр (при наличии результата, отличного от нуля).

Проекты из пижженного контента

◄ ►

Классический пример — сделанное мудаками на коленке минут за 30 за неделю мозгоёбли говно под названием «дЭмо»

И да, копрокубики

Portal

А вот это уже вин — небезызвестная контра, портированная на мобильники

Crysis? В моём андроиде?

Бедный Йорик Марио

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

Недостатки

• Глюки теней при самозатенении объектов. Иногда «дребезжание» теней (Jittering) на определённых углах (очень напоминает z-fighting). При этом, сами тени являются просто дополнительными полигонами.
• Использование Mono даже для десктопных билдов(кроме билдов MS Store и WP8). Nuff said. Если империя зла гарантирует работу/потокобезопасность каких-либо фич, то на Mono об этом мечтать и не приходится.
• Тормозной встроенный гуй (старый гуй) и глючный Unity2D.
• Отсутствие IDE для шейдеров.
• Отладка ТОЛЬКО через Monodevelop (который имеет привычку принимать ислам даже при разворачивании treeview или при вбросе исключения в отлаживаемом коде (sic!)). Справедливости ради стоит отметить что существует решение для Visual Studio от сторонних разработчиков, но стоит оно 250 вечнонефтяных.
• Отсутствие полноценных float-текстур, что приходится реализовывать через костыли.
• Интерполяция Skinned-mesh на CPU.
• Mecanim впилен довольно криво, что регулярно выливается в сообщение Animator is not initialized в логе (и полный игнор всех параметров и слоёв в AnimationController'е) и прочую хрень. Со временем, впиливают всё больше и больше всякой всячины, чтобы сделать Mecanim всё больше и больше похожим на старый Legacy аниматор в конечном итоге.
• Туннелирование коллизий в ряде случаев и полная невозможность их избежать (кроме костылей, велосипедов, свистелок и перделок). Да, имеется CCD, но при его использовании нередка ситуация, когда он что он есть, что его нет — один йух, либо туннелирование, либо наоборот, застревание по поводу и без поводу, где ему вздумается и как ему вздумается.
• Документация по шейдерам спрятана и представляет из себя скорее серию туторов, чем полноценный док.
• Совершенно странная привычка разработчиков не обновлять некоторые компоненты и примеры. Вообще. Например, довольно популярный пак Detonator как был на версии 2.6 выпущен, так и с тех пор не обновлялся. В результате, версия, что выложена на офф. сайте в качестве бесплатного пака, попросту не робит на следующих версиях. Совместимый пак можно найти на форумах и в ассет-сторе. Такая же ситуация обстоит с примерами и некоторыми шейдерами (несовместимость из-за того, что некоторые шейдерные операции были убраны на тройке). Такая же ситуация с ассет-сервером, как с серверной, так и с клиентской частью. Странностей в поведении предостаточно, а чинить это никто даже и не собирается.
• Mono. Если верить интернетам, то получается не слишком радужная картина, ибо Mono не менее чем в пару раз слоупочнее обычных дотнетов. Не считая мелкой мишуры в духе неподдерживаемых фич как компилятора, так и clr с окружением. Ввиду природы Мигелюшки, версию того самого Mono обновлять не собираются, ибо отныне более новые версии достаются нахаляву только тем, кто пилит опенсорсное ПО. С остальных попросят бабос. Так как Unity3D и так неплохо продаётся, обновлять никто ничего не собирается, разве-что сами что-то допилят. Что потихоньку и делают.
• Расово голая сцена являет собой чуть более, чем нихуя — OpenGL/Dx с прикрученным к нему окружением Mono, не более. Если те-же CE или UE ещё добавляют сверху какой-никакой постпроцессинг, то тут всё делается ручками. С какой-то стороны даже неплохо, но для неофита выглядит уныло — «Эй, ёба, я ведь сотворил коробку из грязи. Почему такая-же коробка выглядит лучше в крайзисе? Фуууу, графона нет, движ копроморфен!». Регулярные срачи на тему «Юнити и графон — реально ли?» появляются довольно регулярно.
• Необходимость иметь придворного макоёба при необходимости строить что-либо под IOS или макось. Прична такого ограничения неизвестна, ибо технических ограничений анонимусами не наблюдается.
• Страсть разработчиков к идиотским скриптопетушиным шаблонам — не считая SendMessage, о котором было рассказано выше, но от которого ещё можно избавиться, стоит выделить необходимость обращения без прямых ссылок к параметрам AnimatorController'ов (приблуда Mecanim'а) и материалов. Нужный параметр нужно указать в качестве строки, что мало того что неудобно, так и нередко влияет на производительность. С относительно недавних пор, можно указать индекс параметра, что чуть скукоживает градус безблагодатности.
• На некоторых мобильных графческих чипах (даже относительно свежих) крайне нажористый рендер в текстуру. Не просто нажористый а КРАЙНЕ нажористый. Возможно, не по вине движка а из-за ограничений самих чипов (даже на том-же яблокофоне-4?). Сцена всего с парой белых кубиков может иметь фпс не выше 15 просто из-за рендера полноразмерного квада в текстуру.
• Бандлы. Движок не умеет читать и распаковывать их потоково, даже несжатые. Т.о. бандл грузится в память целиком и полностью, что провоцирует сотни НЕНАВИСТИ у тех, чья жизнь скатилась до разработки YOBA-игрулек для смартфонов из-за ограничений на память, которую можно отожрать приложению (однохуйственно, что на IOS, что на андроиде, квота в районе 120 мегабайт. Вылезти за лимит проще простого, достаточно несколько больших атласов в высоком разрешении).
• Невозможность использовать FBX с абсурдно большим animation sequence. Но это мелочь.
• Стандарное решение для поиска пути (и зайчаток AI) навевает тоску и уныние, ибо состоит из оных на 146%. Наибольшую боль являет собой невозможность модификации навмешек ручками во время работы — только запекание заранее, без других вариантов! Есть мнение, что творили и впиливали какие-то индусские студенты. Годится только для прототипирования и получения пути.
• Разные clr для десктопных и для мобильных платформ. СЮРПРИЗ! При использовании каких-либо фич C# (или ООП в целом), даже не самых экзотических, вроде шаблонов, можно получить разное поведение на разных платформах. В качестве бонуса, MonoBehaviour'ы в редакторе и на устройстве иногда находятся в разной очерёдности вызовов (все коллбеки MonoBehaviour'ов вызываются в одном потоке, забыл?). Ведёт к тому, что происходит былинный отказ на устройстве, при том, что в редакторе всё отлично.
• При использовании нативных плагинов для IOS, оные выковыриваются из проекта X-Code только калёным железом, ссаными тряпками и отчаянными пиздюлями — на каждом ребилде бг-мерзкий мусор, от которого тебе пришлось избавляться в экспорте, будет возвращаться в obj-c сорц, сгенерённый редактором. Выпилить можно только сменой платформы на любую другую и обратно, что, порой, занимает не один и не два часа из-за необходимости произвести реимпорт чуть ли не всего и вся.

Интересные факты

• Расово пиндостанская космолеталка «Battlestar Galactica Online» была написана на этом двигле ровно за 6 недель. А тебе слабо?
• Видеокарты некоторых Mac'ов не поддерживают линейную цветовую гамму (отлично от iPhone). Таким образом, на вендах, Mac'ах и IOS'ах результат рендера может отличаться.