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д пакете имеют свои плюсы и минусы – и выбор больше, на мой взгляд, зависит от предпочтений разработчиков.
«Возможно, все-таки стоит взяться за реализацию своего майнкрафта с блекджеком — все возможности вроде есть».
Говорят, что с сетью в Unity3d дела плохи, и двиг не годится для большого числа коннектов. На самом деле все проще – и тот кто знает, что говорит, имеет в виду именно встроенный networking. Потому что вместо встроенного решения можно использовать практически всё что угодно:
-
. . . .
- Оригинальный Raknet (c++, не подойдет для вебплеера). . . (c++, не подойдет для вебплеера и еще у него какой-то совсем чумовой ценник).
Естественно, можно написать что-то свое на произвольной технологии (c++, Java, Erlang, c#, whatever) и прикрутить какой-то еще существующий networking solution. Что-то основанное на TCP\UDP подходит отлично. Если работать по HTTP протоколу, то наиболее частый выбор это php – хотя, как вы понимаете, тот же Erlang или нечто другое тоже подойдет.
-
и вебсервер Misultin для серверной части.
- Unity3d и его класс WWW для клиентской части.
- Несколько разнотипных девайсов: iPad и iPhone (Unity iPhone Basic), HTC Desire (Unity Android Trial), PC и Mac (в вебплеере, бесплатная версия Unity) – всё это замечательно работало вместе и обменивалось сообщениями.
- Чем меньше draw calls – тем лучше (хотя это не панацея). Раньше с этим боролись специальными скриптами для объединения геометрии в один меш (CombineChildren), собирали хитрые конструкции с костями (например, 1 skinned mesh, 8 костей – 8 независимых друг от друга спрайтов с анимацией, такой подход, например, использовался в топовой iOS игре ZombieVille на юнити). Теперь разработчику помогает static batching, dynamic batching и Umbra (система отсечения невидимых поверхностей \ occlusion culling).
- Без необходимости лучше не использовать Find\GetComponent и похожие методы — по мере возможности лучше сохранить ссылку на компонент один раз при запуске скрипта.
- Лучше не выполнять лишних расчетов внутри OnGUI() и не использовать больше одного OnGUI() одновременно.
- Необходимо следить за таким параметром как Fillrate. Несколько плоскостей размером на весь экран с полупрозрачным материалом способны серьезно убить производительность на PC, не говоря уже о чем-то вроде iPad.
- В юнити не существует «game loop»’a или единой точки входа, как к этому многие привыкли в других движках. Т.е. никто вам не мешает такую штуку организовать, но по-умолчанию работает принцип: каждый game object – это некий набор компонентов (в том числе скриптов), при этом в каждом скрипте может вызываться свой набор событий ( Start() , Update() , OnMouseDown() , и т.д.).
- Первым делом, прежде чем ломиться на форумы, стоит хотя бы попробовать ознакомиться с проектом-примером про обезьянку Лерпца.
- Чтобы найти game object по имени, используем метод GameObject.Find(“Some Object”); , чтобы получить компонент (в том числе скрипт) на этом объекте (который также часто называют «ГО») – используем код вида ссылка_на_объект.GetComponent<Тип>(); .
- Более-менее продвинутые разработчики тоже в опасности, но грабли у них более изощренные. К примеру, не все знают, что так широко используемый способ работы с материалами ( render.material.color = Color.White; , color.material.SetColor(“_Color”) и т.д.) содержит в себе подлянку: При таком доступе создается копия материала в памяти (instance), и объекты не будут работать с batching’ом (который бывает статический и динамический — а skinned batching, вопреки расхожему мнению, в 3.х не поддерживается). Поэтому тут можно либо работать с renderer.sharedMaterial (но тогда свойства материала изменятся у всех объектов с этим материалом), либо менять цвет вершин используя класс Mesh и шейдер который реагирует на такое изменение цвета.
- NPOT текстуры это плохо (текстуры со сторонами, не кратными степени двойки). Хорошие размеры это 64, 128, 256 и т.д. На iOS ввиду использования PVRTC компрессии нужно использовать еще и квадратные текстуры. Неквадратные текстуры мылятся в 3д (не относится к GUI), а ещё из таких текстур зачастую замечательно вытекает память. Тут еще можно отметить, что хранить текстуры в юнити проекте в формате jpg абсолютно бесполезно, т.к. среда пережимает графические ассеты в свой формат. Я для локальной разработки больше всего люблю psd, а если работа идет удаленно и нужно гонять туда-сюда через ассет сервер\mercurial\svn много ресурсов – тогда мне начинает больше нравиться png.
-
, прямо как у Кармака в Rage:
- Отличнаяпримочка для взрывов в игре (безусловно необходимая вещь), которая теперь входит в стандартную поставку Unity3d вот
- Я где-то слышал мнение о том, что в приложение на Unity3d (для iOS или Android) невозможно интегрировать поддержку iAd, OpenFeint и т.д. Оказывается, врут. для работы с kinect’ом.
- Давно юнитек обещает прикрутить нормальный GUI, и всё никак. Но я верю в светлое будущее. С другой стороны всё не так смертельно – если UnityGUI реально вас достал, можно воспользоваться какой-то разработанной в сообществе примочкой, которая рисует всё в 1 draw call и не кушает много процессорного времени (тут, конечно, большой простор для допиливания). Очень хотелось бы увидеть грамотный WYSIWYG для графических интерфейсов в юнити. Если есть время\желание – такой можно, конечно же, оформить самостоятельно, т.к. возможности по модификации Editor IDE в юнити поистине огромны.
- Можно без особых проблем взламывать композиции, сделанные на Unity. Можно рефлектить код (правда, нетипизированный JS и Boo зачастую могут спасти автора). Можно распаковывать бандли и вебплеерные композиции. Можно загружать сцены и ресурсы в практически исходном виде обратно в редактор. Код, конечно, можно защищать с помощью обфускации, а вот с ресурсами всё сложнее (особенно в вебплеере). С другой стороны, это можно не считать проблемой – весьма субъективный пункт.
- На данный момент нету поддержки отображения html внутри вебплеера (что, возможно, изменится, т.к. в редакторе тройки был замечен WebKit, который используется в работе Asset Store). Если нужно рендерить html и можно использовать standalone приложение на юнити, то можно посмотреть тут
Минусы можно найти везде, если покопаться. На тему проблем и заморочек в Unity можно дискутировать очень долго, способ решенить проблему есть почти всегда. Я думаю, что юнити замечательный инструмент, и если в 2011м Unity Technologies не подкачает – всё коммунити будет водить хороводы и радоваться «как хорошо что любимый инструмент развивается!».