Противопоказания для нити 3д

Недавно я прочитал очередную статью про Unity3d на Хабре, в очередной раз были интересные комментарии — и грамотные, и грамотные не совсем.
Я вдохновился и решил немного прокомментировать происходящее.
Надеюсь, кто-нибудь почерпнет для себя здесь что-то новое и интересное.

Несколько комментариев

Данный подраздел статьи является комментарием к комментариям — текст в кавычках не мой.

«Поддержка кеширования ассетов на клиенте продается за отдельные очень большие деньги (это которая не в браузере, а отдельно на диске)».

В 3.2 есть кеширование для всех (с ограничениями, конечно).

«Автор аккуратно опустил две очень серьёзные проблемы:
— Игры на Unity требуют большого трафика,
— Нельзя использовать сложные динамичные сцены».
«Игры на Unity имеют элементарную игровую механику — сложный бой с несколькими игроками будет весьма тормозить».
«Под сложным боем Я имел в виду совместную игру нескольких игроков. Для Unity это является узким местом. Опускать этот момент нельзя, т.к. основное требование к современным играм — это высокая степень социализации. Игроки хотят играть в игры со своими друзьями. Отметьте, что в социальных сетях игр на Unity практически нет».

Отметьте, что большинство игр в социальных сетях имеет асинхронный принцип работы. Т.е. когда Петя в универе, я пришел и сломал ему грядку – Петя пришел домой, зашел на свою страничку в контакте, разозлился и отправил отряд мстителей ко мне на грядку. А я, естественно, в момент нападения никак не взаимодействую с Петей напрямую. Фраза о том, что «совместная игра нескольких игроков является узким местом Unity» звучит, мягко говоря, неприлично – особенно если говорить о действительно небольшом количестве игроков в одной комнате, либо о стороннем сетевом решении.

«И как результат:
— Игры на Unity у людей с низким трафиком превращаются в кошмар,
— Игры на Unity имеют элементарную игровую механику — сложный бой с несколькими игроками будет весьма тормозить».

Вообще, минимальное приложение в вебплеере будет весить чуть больше 500кб, а дополнительные ресурсы можно подкачивать в Asset Bundles (которые пакуются 7z). Если мы говорим именно о трафике, возникающем при обмене игровыми сообщениями – здесь снова играет роль выбранное решение для сети.

«Unity хорош, но прежде чем бросаться писать осмыслите 2 минуса
1: ЗД не панацея и применять его надо осторожно. Посмотрите на топ аппстора — там в основном 2д игры. Посмотрите на соц игры в которые играют сотни миллионов — там нет 3д. Только небольшое количество игровых механик по настоящему требует 3Д.
2: Сделать сочную притягательную графику на 3Д гораздо сложнее чем на 2Д и удается это только профессионалам. Любители и новички делают с 3Д картинку вызывающую страх и ужас…».

Здесь явно присутствует непонимание того факта, что на Unity можно замечательно делать 2д игры. Чем и занимается целая толпа разработчиков в аппсторе (и некоторый процент игр былесть в top100, между прочим) и казуальщики.

«В Юнити есть deferred освещение, встроенный редактор шейдеров».

Небольшая ошибочка. По-умолчанию никакого подобного инструмента не поставляется, но есть один качественный бесплатный — Strumpy Shader Editor и один платный редактор шейдеров — ShaderFusion. Шейдинг в 3.х шагнул на встречу разработчику (появились surface shader’ы), поэтому написание собственных шейдеров (без визуального редактора) не представляется чем-то невероятным. Портирование шейдеров проходит, в целом, отлично (к примеру, без проблем можно взять и быстренько переделать под юнити что-то отсюда).

«Он [Unity3d] закрыт. Т.е. исходных кодов вам не дадут даже по лицензии».

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

А на лицензии (1500$, если мы говорим про Unity PRO), кстати, несколько раз в год бывают скидки, обычно ~20%. Ограничения базовых версий (Unity за 0$, Unity iPhone за 400$) не так велики – значительное количество проектов можно разработать и на них.

«Кто-нибудь пробовал Unity для Android / iOS? Как впечатления?»

Впечатления отличные.
Недавно, например, проходил конкурс от компании Qualcomm на создание augmented reality приложения (можно было использовать квалкомовский Unity SDK) и призы составляли неплохие 125, 50 и 25 тысяч долларов за первое, второе и третье места соответственно.
Обе платформы разработчики активно допиливают и оптимизируют.
На мощных мобилках поддерживается Open GL ES 2.0 (попиксельное освещение, шейдеры) – это, по-моему, отлично. Можно пытаться делать что-то похожее по качеству на Epic Citadel.

Ещё немного мыслей

Пока я выписывал мысли на бумагу, появилась новая статья на тему Unity от этого же автора (автор молодец!).

«Серьезные сцены удобнее отдать делать artist’ам в 3DS Max’е том же. Единственное что плохо — что из FBX (промежуточный формат между максом и юнити) Unity не импортирует источники света. Пришлось писать плагин к Unity на С++. А это доступно только в платной версии. Вобщем намучались с этим движком.»

Скажите, а зачем было писать плагин на С++, если источники света нормально переносятся в юнити в виде геймобъектов-пустышек (dummy)? Можно договориться с художниками о том, как правильно обзывать источники света и написать небольшой скрипт в юнити, который бы при импорте модельки эти источники бы создавал. И сборка уровня в юнити, и сборка уровня в 3д пакете имеют свои плюсы и минусы – и выбор больше, на мой взгляд, зависит от предпочтений разработчиков.

«Возможно, все-таки стоит взяться за реализацию своего майнкрафта с блекджеком — все возможности вроде есть».

Если это поможет, то существует Unity Minecraft Starter Package.

Сеть

Говорят, что с сетью в Unity3d дела плохи, и двиг не годится для большого числа коннектов. На самом деле все проще – и тот кто знает, что говорит, имеет в виду именно встроенный networking. Потому что вместо встроенного решения можно использовать практически всё что угодно:

Сетевые решения с API, специально подготовленным для работы с Unity3d:

1. Smartfox.
2. Photon.
3. Badumna.
4. Electroserver.

Сетевые решения, которые можно прикручивать самостоятельно:

1. Оригинальный Raknet (c++, не подойдет для вебплеера).
2. Lidgren.
3. RedDwarf.
4. NetDog (c++, не подойдет для вебплеера и еще у него какой-то совсем чумовой ценник).

Часть решений бесплатная, часть стоит совсем не дорого и к тому же предоставляют бесплатную версию с ограниченным числом коннектов (у Photon’а, например, 100 — у других, если честно, не интересовался).

Естественно, можно написать что-то свое на произвольной технологии (c++, Java, Erlang, c#, whatever) и прикрутить какой-то еще существующий networking solution. Что-то основанное на TCPUDP подходит отлично. Если работать по HTTP протоколу, то наиболее частый выбор это php – хотя, как вы понимаете, тот же Erlang или нечто другое тоже подойдет.

Я собственноручно делал простенький чат (не позиционирую это как достижение, но результат в п.3 меня порадовал), который работал через протокол HTTP:

1. Erlang и вебсервер Misultin для серверной части.
2. Unity3d и его класс WWW для клиентской части.
3. Несколько разнотипных девайсов: iPad и iPhone (Unity iPhone Basic), HTC Desire (Unity Android Trial), PC и Mac (в вебплеере, бесплатная версия Unity) – всё это замечательно работало вместе и обменивалось сообщениями.

Оптимизация

Если говорить об оптимизации во время разработки на Unity, то основные моменты вот:

1. Чем меньше draw calls – тем лучше (хотя это не панацея). Раньше с этим боролись специальными скриптами для объединения геометрии в один меш (CombineChildren), собирали хитрые конструкции с костями (например, 1 skinned mesh, 8 костей – 8 независимых друг от друга спрайтов с анимацией, такой подход, например, использовался в топовой iOS игре ZombieVille на юнити). Теперь разработчику помогает static batching, dynamic batching и Umbra (система отсечения невидимых поверхностей occlusion culling).
2. Без необходимости лучше не использовать FindGetComponent и похожие методы — по мере возможности лучше сохранить ссылку на компонент один раз при запуске скрипта.
3. Лучше не выполнять лишних расчетов внутри OnGUI() и не использовать больше одного OnGUI() одновременно.
4. Необходимо следить за таким параметром как Fillrate. Несколько плоскостей размером на весь экран с полупрозрачным материалом способны серьезно убить производительность на PC, не говоря уже о чем-то вроде iPad.

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

Грабли

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

1. В юнити не существует «game loop»’a или единой точки входа, как к этому многие привыкли в других движках. Т.е. никто вам не мешает такую штуку организовать, но по-умолчанию работает принцип: каждый game object – это некий набор компонентов (в том числе скриптов), при этом в каждом скрипте может вызываться свой набор событий (Start(), Update(), OnMouseDown(), и т.д.).
2. Первым делом, прежде чем ломиться на форумы, стоит хотя бы попробовать ознакомиться с проектом-примером про обезьянку Лерпца.
3. Чтобы найти game object по имени, используем метод GameObject.Find(“Some Object”);, чтобы получить компонент (в том числе скрипт) на этом объекте (который также часто называют «ГО») – используем код вида ссылка_на_объект.GetComponent<Тип>();.
4. Более-менее продвинутые разработчики тоже в опасности, но грабли у них более изощренные. К примеру, не все знают, что так широко используемый способ работы с материалами (render.material.color = Color.White;, color.material.SetColor(“_Color”) и т.д.) содержит в себе подлянку: При таком доступе создается копия материала в памяти (instance), и объекты не будут работать с batching’ом (который бывает статический и динамический — а skinned batching, вопреки расхожему мнению, в 3.х не поддерживается). Поэтому тут можно либо работать с renderer.sharedMaterial (но тогда свойства материала изменятся у всех объектов с этим материалом), либо менять цвет вершин используя класс Mesh и шейдер который реагирует на такое изменение цвета.
5. NPOT текстуры это плохо (текстуры со сторонами, не кратными степени двойки). Хорошие размеры это 64, 128, 256 и т.д. На iOS ввиду использования PVRTC компрессии нужно использовать еще и квадратные текстуры. Неквадратные текстуры мылятся в 3д (не относится к GUI), а ещё из таких текстур зачастую замечательно вытекает память. Тут еще можно отметить, что хранить текстуры в юнити проекте в формате jpg абсолютно бесполезно, т.к. среда пережимает графические ассеты в свой формат. Я для локальной разработки больше всего люблю psd, а если работа идет удаленно и нужно гонять туда-сюда через ассет серверmercurialsvn много ресурсов – тогда мне начинает больше нравиться png.

Интересные дополнения к Unity3d

Давайте рассмотрим несколько любопытных дополнений к юнити.

• Мега текстурирование, прямо как у Кармака в Rage:
• Отличнаяпримочка для взрывов в игре (безусловно необходимая вещь), которая теперь входит в стандартную поставку Unity3d вот
• Я где-то слышал мнение о том, что в приложение на Unity3d (для iOS или Android) невозможно интегрировать поддержку iAd, OpenFeint и т.д. Оказывается, врут.
• Проект-пример для работы с kinect’ом.

Из последних интересных материалов на тему Unity3d можно отметить выложенную на официальном сайте подборку презентаций с Unite’2010.

Минусы

Можно поговорить про минусы. Например:

1. Давно юнитек обещает прикрутить нормальный GUI, и всё никак. Но я верю в светлое будущее. С другой стороны всё не так смертельно – если UnityGUI реально вас достал, можно воспользоваться какой-то разработанной в сообществе примочкой, которая рисует всё в 1 draw call и не кушает много процессорного времени (тут, конечно, большой простор для допиливания). Очень хотелось бы увидеть грамотный WYSIWYG для графических интерфейсов в юнити. Если есть времяжелание – такой можно, конечно же, оформить самостоятельно, т.к. возможности по модификации Editor IDE в юнити поистине огромны.
2. Можно без особых проблем взламывать композиции, сделанные на Unity. Можно рефлектить код (правда, нетипизированный JS и Boo зачастую могут спасти автора). Можно распаковывать бандли и вебплеерные композиции. Можно загружать сцены и ресурсы в практически исходном виде обратно в редактор. Код, конечно, можно защищать с помощью обфускации, а вот с ресурсами всё сложнее (особенно в вебплеере). С другой стороны, это можно не считать проблемой – весьма субъективный пункт.
3. На данный момент нету поддержки отображения html внутри вебплеера (что, возможно, изменится, т.к. в редакторе тройки был замечен WebKit, который используется в работе Asset Store). Если нужно рендерить html и можно использовать standalone приложение на юнити, то можно посмотреть тут

Заключение

Минусы можно найти везде, если покопаться. На тему проблем и заморочек в Unity можно дискутировать очень долго, способ решенить проблему есть почти всегда. Я думаю, что юнити замечательный инструмент, и если в 2011м Unity Technologies не подкачает – всё коммунити будет водить хороводы и радоваться «как хорошо что любимый инструмент развивается!».

На носу Unity 3.2 – присоединяйтесь к юнитологам!