Unreal или unity что выбрать
Unreal vs Unity или какое «U» выбрать
Всем доброго оборота земли вокруг своей оси в вашей широте и долготе дней. Сей опус будет полезен “Сомневающимся” и поможет пролить немного излучения звезды по имени Солнце на коварную маркетинговую кампанию самых популярных игровых движков. Я занимаюсь разработкой игр уже больше 10 лет, поэтому нескромно могу выразить свое ЛИЧНОЕ мнение о всех достоинствах и недостатках. Добро пожаловать ниже…
Unity сразу обрел огромную базу фанатов и разработчиков за счет своей простоты и удобства, а Unreal в это время мог оперировать только обученными профессионалами с большим опытом. Порог вхождения в Unreal неприлично высок, чтобы начать программировать игры на нём, вам нужно знать С++ и тонну мелких деталей работы движка, а это не один год обучения на программиста и изучения самого движка. В юнити любой человек не обделенный логикой и азами Pascal сможет написать простенькую игру за неделю. В Unreal на подобное уйдет в 10 раз больше времени и это неоспоримый Факт.
Epic Games (разработчики Unreal) знают свои слабые и сильные стороны, поэтому выпуск Blue Print не заставил себя долго ждать и действительно понизил порог вхождения в UE, но всего лишь для “прототипирования”. Серьезные проекты по прежнему “крайне рекомендуется” писать на С++ со всеми последствиями. На рынке сейчас “на глаз” разработчиков на Unreal 1 к 10 или даже к 20 по сравнению с Unity.
Работа с редактором
Просто знайте, нельзя нажать кнопку экспорт в вашем любимом 3д пакете и получить всё в том же виде в UE, вам придется каждый объект заботливо расставлять руками, про материалы и прочее естественно забудьте тоже, потому что UE кроме Diffuse+spec+Ao+metallic импортировать ничего не будет, не говоря уже про второй UV канал на назначенной текстуре или тайлинг и прочие подробности. Я страдал достаточно для того чтобы написать свой собственный экспортер из 3ds max Vray в Unreal и потратил на это несколько месяцев лишь бы не мучаться с редактором Unreal. Это позволило переводить сцены с 1000 объектов в Unreal за каких то 30 минут компьютерного времени, но даже это не помогло мне 🙂
Если вы хотите делать мобильные игры, то приготовьтесь к Аду, каждый ребут редактора отключает Mobile Preview режим и вам придется вручную каждый раз включать его заново и ждать пока перекомпилируется весь рендер движок под мобильные устройства, а это занимает несколько минут. Умножьте это на поистине Эпичную стабильность редактора, который может крашится каждые 10 минут, запускается заново несколько минут на топовом железе…
Epic очень богатая контора и она может себе позволить многое: бесплатный движок (в первую очередь для того чтобы хоть как то выращивать новых специалистов для их внутренних потребностей в разработке игр), провальные игры и щедрость с ними связанную (PARAGON) в отличии от Unity, которая перебивается продажами самого движка и подписок, если бы денег было больше, то отставание в графическом плане не было бы настолько заметным, но даже сейчас 2018 версия уже не слишком сильно уступает UE.
Unreal против Unity: на чем лучше разрабатывать мобильные игры?
Здравствуйте, уважаемые читатели!
У нас переведена и готовится к выходу книга Джона Хокинга о программировании в Unity, о которой мы уже писали.
А не так давно нам попалась на глаза интересная статья о разработке мобильных игр с применением Unity (от 12 августа 2015 года); правда, ключевое достоинство статьи заключается в том, что в ней этот инструмент сравнивается с основным конкурентом: Unreal Engine.
Именно с этим замечательным исследованием мы предлагаем вам познакомиться в пятничный вечер. В комментариях будем рады увидеть рекомендации по изданию книг о UE, а также надеемся на плодотворную дискуссию.
Статья переведена с небольшими сокращениями
Мы (компания OnlineFussballManager GmbH) в настоящее время приступаем к разработке нового проекта для мобильных устройств. Мы собираемся создать захватывающую и уникальную комбинацию пошаговой стратегии и игры типа «футбольный менеджер».
Игроки смогут планировать и создавать собственные клубные площадки и спортивные комплексы, тренировать команду и работать над ее тактикой. Игроки команды будут не просто юнитами в пронумерованных футболках, а реалистичными личностями со своими чертами и даже выражением лица. Все будет происходить в изометрическом представлении различных помещений и площадок клуба, где анимированные здания будут располагаться в специально определенной сетке.
Итак, момент истины настал, когда мы взялись за разработку визуального представления.
Учитывая поставленные перед нами требования и тот факт, что мы должны разработать эту игру и для iOS, и для Android — как реализовать этот проект технически?
Один из первых вопросов, который предстояло решить — создавать ли собственный движок или воспользоваться уже имеющимся. Разумеется, первый вариант оптимален, если вы желаете полностью контролировать все, что происходит в вашем исходном коде, тулчейне, а также вполне представлять, каковы будут ваши доходы от этой игры. Недостаток такого подхода заключается в том, что подобная разработка потребует немалых усилий — из-за чего сроки всего проекта увеличатся, и он существенно подорожает. От этой идеи мы быстро отказались, поскольку хотели удержать стоимость и сроки проекта в рамках разумного.
Далее предстояло определиться, какой движок будем использовать. Вариантов было множество: от Stencyl, GameMaker до Cocos2d и Marmalade и, наконец, Unreal и Unity.
Конечно, можно привести массу доводов о том, какой движок лучше и для каких целей. Сколько людей — столько мнений. Должны признаться, на какой-то момент и мы ощутили такой субъективизм. Команда активно поддержала Unreal Engine. Однако, сколько мы ни присматривались к UE, никто не мог охарактеризовать его объективно, без апелляции к личному мнению.
Итак, мы решили не отвлекаться от фактов и принялись исследовать другие, более известные инструменты.
GameMaker вскоре был отвергнут, поскольку он более ориентирован на новичков, только приступающих к разработке игр. Таким образом, изучить его довольно легко, но возможности GameMaker явно не дотягивали до того, что мы хотели сделать.
Далее пришел черед Cocos2D, который на первый взгляд казался многообещающим. Как понятно из названия, Cocos2D оптимизирован под разработку двухмерных игр. Поэтому возникал вопрос: хотим ли мы создать нашу изометрическую сетку зданий в истинном 2D или в фактическом 3D с фиксированной точкой обзора. После некоторых дополнительных исследований мы выбрали реализацию в 3D. В таком случае Cocos2D нас, очевидно, не устраивал.
Мы обратились к Marmalade. Ведь при помощи Marmalade были созданы такие известные игры как »Plants vs. Zombies« и »Godus«. Но, хотя мы и нашли у этого движка немало достоинств, оставались проблемы, вынудившие нас обратиться к другим вариантам. Один из наиболее существенных недостатков заключался в том, что сообщество специалистов по Marmalade довольно невелико.
Итак, из крупных альтернатив остались только Unreal и Unity. Но даже к этому моменту мы не могли уверенно выбрать один из двух без посторонней помощи.
К счастью, приближалась игровая конференция GDC в Сан-Франциско, поэтому мы воспользовались шансом слетать туда и посоветоваться с коллегами.
Встретились там с ребятами из Epic, вплотную познакомились с Unreal Engine, попробовали Paper 2D, их инструмент для просмотра превью мобильных приложений и спросили, чем бы нам воспользоваться: их движком или Unity?
Ребята нам удружили, сказав примерно следующее: «Unreal классный, но и Unity неплох. Попробуйте и то, и другое».
Тогда мы отправились к разработчикам Unity и присмотрелись к Unity 5 — как он повышает производительность в iOS. В конце концов, задали им такой же вопрос и получили аналогичный ответ.
На данном этапе мы решились на основательное техническое исследование. Спроектировали прототип, в достаточной степени напоминающий наш проект, чтобы проверить на разных мобильных устройствах, как пойдет процесс сборки и какова будет производительность. При этом мы также хотели выяснить, какие подводные камни и проблемы могут нас подстерегать при разработке на первом и на втором движке.
Поскольку все наши программисты были заняты на текущих проектах, мы поручили работу над прототипом специалистам из компании Bit Baron.
Исследование движков, выполненное в компании Bit Baron
Компания »Online Fußball Manager« (OFM) планировала создать мобильную игру. Нас попросили о помощи, чтобы увереннее определиться, какой движок лучше всего подходит для их проекта. До тех пор мы занимались исключительно разработкой браузерных игр, но решили, что справимся с задачей. Было предложено сравнить два варианта: Unity и Unreal. В настоящее время это два «локомотива» в мире программирования игр. Существует немало отчетов, подробно иллюстрирующих мельчайшие различия между ними. Но особенность нашей работы заключалась в том, что мы написали для сравнения два практически идентичных тестовых приложения и охарактеризовали их показатели в соответствии с системой контрольных точек (эталонное тестирование).
Написав два аналогичных приложения, мы смогли протестировать оба на ровном игровом поле, сообщить OFM, какая версия работает лучше и подчеркнуть дополнительные проблемы.
Мы хотели создать такой эталонный тест, который бы предоставил OFM информацию, непосредственно связанную с типом создаваемой ими игры. Заказчики указали, что в прототипе должно быть несколько анимированных зданий и деревьев. Поэтому мы создали 3D-сцену, где пользователю предлагалось самостоятельно расставлять эти объекты на карте. Размеры сетки составляли 11×16, она вмещала до 176 зданий. Каждый квадрат сетки поддерживал до 6 деревьев, таким образом, в сцене могло быть свыше 1000 деревьев. Мы добавили простой пользовательский интерфейс, где можно было добавить в сцену указанное количество деревьев и зданий. Также добавили функцию добавления зданий в конкретных местах — для этого нужно было щелкнуть по карте в желаемой точке. Что касается организации программы, мы построили сетку на плоскости, а просмотр сцены сделали через камеру, расположенную «над головой» пользователя. Мы также добавили специальный функционал камеры, чтобы пользователь мог масштабировать и панорамировать сцену. Поскольку этот прототип создавался, чтобы определиться с движком для разработки, мы сделали все возможное, чтобы в обоих вариантах сцена выглядела почти одинаково. В противном случае было бы невозможно сравнить визуальное качество первого и второго варианта. Для этого пришлось повозиться, поскольку некоторые вещи обрабатываются в Unreal и в Unity по-разному. В итоге у нас получились две очень похожие сцены.
Чтобы унифицировать тестирование производительности, мы хотели применить в обеих системах идентичные модели деревьев и зданий. Для деревьев использовалась мобильная модель SpeedTree, включавшая как раз около 1000 многоугольников и позволяла хорошо оценить, насколько мелкие инкременты в отображаемых треугольниках сказываются на кадровой частоте. Что касается анимированных зданий, нам не удалось найти для них такую модель, которая работала бы с обоими движками, поэтому мы применили две разные модели. Обе были рассчитаны чуть более чем на 16 000 многоугольников каждая, у них были практически идентичные настройки материалов. Мы полностью отключили уровни детализации (LOD), чтобы в обоих вариантах на любом расстоянии от камеры отображалось одинаковое количество треугольников. Тест проектировался не только с целью отразить различия производительности между двумя движками, но и чтобы показать разницу в качестве рендеринга. Кроме того, приходилось внимательно следить за стандартными шейдерами Unreal Engine. Заметив, что Unreal выглядит явственно лучше, мы обнаружили, что в камере действует ряд шейдеров, затратных с точки зрения производительности. После их отключения сцена визуально почти не изменилась. Освещение представляло совсем другую проблему, поэтому нам понадобилось некоторое время, чтобы довести его до ума.
Заказчики интересовались не только тестами рендеринга, но и тем, каковы будут впечатления от разработки на первом и втором движке. В конце концов, что толку от производительности, если вы не успеваете написать игру в установленные сроки. Чтобы очертить эти впечатления, мы сравнили и такие факторы, как длительность сборки, имеющуюся документацию, сложность развертывания в мобильной среде, а также сложность итераций кода. Мы полагали, что именно по этим показателям Unity будет сильнее (как флагман в области разработки мобильных игр).
Прототип в Unity. На карте нанесено 200 деревьев
Это картинка из редактора Unity. Нам очень повезло, что мы смогли дополнить его нашими собственными сценариями
Значения кадровой частоты 37 против 32. В статистической панели Unity видим оценочные данные для автономного приложения, которые не совпадают с реальными
Вот как проект выглядит в редакторе Unreal. Здесь есть много специализированных вложенных редакторов, некоторые из которых сравнимы по функционалу с целыми программами
В UE сделан такой же экранный снимок, кк и в Unity (см. выше), причем мобильные настройки оставлены по умолчанию, без освещения деревьев
Когда настройки были откорректированы, деревья получились лучше, но все равно не так хорошо, как в Unity
Чертежи превосходны при решении простых задач, их интеграция с C++ просто фантастическая. Но если задействуется более сложная логика, то они быстро приходят в беспорядок, и разобраться с ними становится непросто.
Результаты эталонного тестирования. Кадровая частота
Удивительно, но при тестировании кадровой частоты (FPS) на разных устройствах мы получили очень несхожие результаты. На некоторых устройствах Unity выигрывал при любой конфигурации. В других случаях Unreal обставлял Unity в тех тестах, где было много зданий. В принципе, Unreal выиграл, но дорогой ценой. Качество изображения и согласованность в Unity были существенно лучше. Текстуры Unreal на некоторых устройствах выглядели расплывчато, деревья получались значительно хуже. Разница в качестве была отчасти обусловлена тем, что отображается с одной стороны в редакторе Unreal и мобильном превью, а с другой – на реальном мобильном телефоне. Эта проблема была особенно очевидна, если говорить об освещении сцены. Было очень сложно подобрать настройки так, чтобы правильно настроить свет, весь сеттинг на мобильных устройствах зачастую выглядел затемненно. В этом отношении Unity оказался гораздо последовательнее, изображение на любых смартфонах было таким же, как и при предварительном просмотре в редакторе.
Результаты для обоих движков оказались гораздо лучше, чем мы рассчитывали (как вы помните, в наших тестовых моделях было примерно в 10 раз больше треугольников, чем в обычных мобильных играх).
В iOS оба движка примерно с одинаковым успехом отображали анимированные модели. Однако тесты с деревьями на этом устройстве оказались безрезультатными, поскольку Unreal не отобразил никаких текстур на моделях деревьев. Мы попытались найти причину этой модели, но не смогли ее разрешить. Кроме того, должны отметить, что при развертывании с применением этих движков у вас под рукой должен быть компьютер Apple. Это очень неудобно, но виновата в такой ситуации сама компания Apple. Заказчики также просили нас выполнить эталонное тестирование на Windows Phone. К сожалению, Unreal пока не поддерживает развертывания на Windows phone, поэтому здесь Unity победил по определению. Поскольку пока Windows Phone занимает очень небольшую долю рынка, развитие Unreal в этом направлении не считается приоритетной задачей.
В конечном итоге, эталонное тестирование лишь показало, что два движка почти равны по силе. Поэтому особенно важно обращать внимание на конкретные достоинства и недостатки каждого из них. В конце концов, если производительность настолько близка, то на первый план выходит удобство и скорость разработки для каждого из этих движков.
Другие контрольные параметры
Вот еще некоторые интересные результаты, которые удалось выяснить в ходе наших тестов:
По результатам исследования нам многое понравилось в обоих движках. Кроме того, мы обнаружили много областей, где эти инструменты можно улучшить, чтобы программисту было удобнее работать. Ни один из движков не имел существенного перевеса над другим, учитывая, как быстро изменяются их возможности и поддержка. Тестирование рендеринга показало, что оба продукта выжимают из устройства максимум и, в принципе, вполне сопоставимы. Опять же, в этой ситуации на первый план выходит удобство использования и интуитивная понятность разработки. Учитывая все, что мы узнали об этих движках, и с какими проблемами столкнулись при разработке, мы оказались перед непростым выбором, но в итоге отдали предпочтение Unity.
Несмотря на то, что изначально мы ставили на победу Unreal Engine, в настоящее время Unity все-таки более выигрышный вариант, как минимум, если говорить о разработке мобильных игр.
Вот основные доводы в пользу нашего решения:
Мы хотели бы подчеркнуть, что наши результаты следует расценивать в контексте сделанного прототипа. То, что подходит для одной компании, не подходит для другой. Кроме того, существует еще множество игровых движков, некоторые из которых могут лучше соответствовать вашей конкретной задаче. В некоторых компаниях, обладающих достаточным временем и ресурсами, будет целесообразнее даже написать собственный движок. В разработке игр универсального решения не существует. Окажите себе услугу и поэкспериментируйте как следует. Тем более, что многие из них удешевляются или вообще становятся условно бесплатными как Unreal. Мы не удивимся, если Unity также последует примеру Unreal и либерализует ценовую модель.
Интересно отметить, что и ребята из Bit Barons до создания прототипа советовали нам взять Unreal Engine для нашего проекта. Учитывая, что и мы в OFM изначально отдавали предпочтение Unreal Engine, возможно, итоговое решение оказалось неоптимальным.
Конечно, нелегко спроектировать, написать и протестировать прототип, особенно если требуется просто определиться с движком для проекта. Но вопрос такого выбора критически важен.
Наконец, мы учли еще некоторые факторы, которые могли бы изменить наше мнение. А именно: насколько легко найти опытных специалистов по каждому движку в настоящее время, и каковы имеющиеся в распоряжении бизнес-модели?
По кадровому вопросу мы посоветовались с опытными рекрутерами, чтобы узнать более-менее реальные цифры. В данный момент на каждого специалиста по Unreal приходится примерно четыре профессионала по Unity. Что касается бизнес-модели, Unreal не предусматривает первичного фиксированного взноса, а требует лицензионных отчислений. В Unity все ровным счетом наоборот. Оба упомянутых фактора были для нас важны, и в результате мы все-таки остановились на Unity.
Орёл или решка: сравнение Unity и Unreal Engine
Извечное противостояние — повод для обсуждения.
Портал 80.lv опубликовал краткое сравнение самых популярных современных игровых движков — Unity 3d и Unreal Engine 4. Его подготовил инди-разработчик и видеоблогер Jayanam.
DTF публикует перевод статьи.
Первая область сравнения — UI-редакторы для создания уровней, которые, по мнению автора, очень похожи. В них есть браузеры контента для ассетов, скриптов и других файлов проекта. Игровые объекты можно перетаскивать в область сцены и таким образом добавлять в её иерархию.
Объекты в редакторе сцены изменяются с помощью инструментов перемещения, поворота и масштабирования — они похожи в обоих движках. Свойства Unity-объектов отображаются в Inspector, а UE4 — в части Details. Jayanam также сравнивает возможности Unity Prefabs c Blueprints.
В обоих движках есть статические меши (static meshes) — их можно двигать, поворачивать, и масштабировать — и скелетные меши (skeletal meshes) — геометрические объекты, привязанные к костям скелета и используемые для анимирования персонажей. Их можно создавать в программах вроде Blender или Maya.
Анимации, включённые для скелетных мешей, также можно импортировать. В Unity они прикрепляются к импортированному объекту, как клипы анимации (animation clips), а в UE4 называются последовательностями анимации (animation sequences). В первом движения управляются с помощью контроллеров анимации (animation controllers), а во втором по тому же принципу действуют анимационные Blueprints.
В обоих движках есть стейт-машины, определяющие переходы из одного состояния ассета в другое. В UE4 система называется Persona, а в Unity — Mecanim. Также возможно применение скелетных мешей одного скелета к другим, но в Unity это в основном используется для анимирования гуманоидов.
В UE4 анимации можно редактировать, в Unity — практически нет, особенно плохо дело обстоит с движениями гуманоидов. По мнению автора, движки не подходят для профессионального анимирования персонажей — лучше использовать программы вроде Blender или Maya, а результат импортировать в виде FBX-файлов. Прикреплённый к объектам материал добавляется в проект, но его свойства вроде шейдера или текстур придётся применять вручную.
Для этого в Unity нужно задать материалу шейдер и добавить в его слоты текстуры — карты шероховатостей, нормалей или диффузии. Собственные шейдеры придётся писать самостоятельно или с помощью сторонних инструментов вроде Shader Forge или ASE. А в UE4 встроен очень мощный редактор материалов, основанный, как и система Blueprints, на нодах.
Для программирования в UE4 используется язык C++, который не все любят из-за сложности и продолжительности компилирования. Однако Jayanam считает, что у движка понятный API и приемлемый период компиляции. В UE4 очень мощная и проработанная система визуального скриптования — Blueprints, с помощью которой можно достичь практически тех же результатов, что и c C++.
Unity 5 поддерживает языки C# и UnityScript. API и его концепт очень похож на аналог из UE4. При использовании управляемого языка вроде C#, программист не обязан использовать указатели (pointers), компилирование происходит быстро. В Unity нет системы визуального скриптования, и чтобы использовать что-то подобное, разработчик вынужден покупать сторонние дополнения вроде Playmaker.
Для 2D-разработки в Unity есть великолепные инструменты — sprite creator, sprite editor и sprite packer. UE4 также поддерживает спрайты в Paper 2d, но решения из Unity мощнее, кроме того, в последнем есть отдельный физический движок для 2d-объектов.
В UE4 встроен постпроцессинг. К сцене можно применять bloom-эффект, тонирование и антиалиасинг как глобально, так и к отдельным её частям (при помощи компонента PostProcessVolume).
В Unity есть стек постпроцессинга, который можно скачать из магазина ассетов движка. Система менее гибкая, чем в UE4 — эффекты применяются только стеком или скриптами к камере.
Sequencer в UE4 можно использовать для создания синематиков. Это мощный инструмент, работающий по принципу добавления объектов на временную шкалу. К настоящему моменту в Unity 5.6 нет системы для синематиков, но timeline-редактор добавят в Unity 2017.
В заключении автор подчёркивает, что оба движка — мощные, но UE4 более гибок. В то же время, для создания 2D-игры он бы выбрал Unity 5, а вот дорогой 3D-проект с открытым миром делал бы на UE4.
Израильская компания AppReal-VR, занимающаяся решениями для виртуальной реальности, также сравнивала движки, но применительно к мобильной и VR-разработке.
У каждого из движков есть свои сильные стороны для разных задач. Unity подойдёт новичкам и любителям, в то время как Unreal — строго для профессиональных разработчиков.
Набор функций Unreal Engine лучше подходит для трёхмерных проектов, в то время как у Unity огромный послужной список на мобильных устройствах. Если вы собираетесь делать мобильную игру, или у вас VR-проект с небольшим бюджетом — выбирайте Unity. Если же вы делаете дорогую игру для консолей с опытной командой разработчиков — используйте Unreal Engine 4.
А каким был ваш опыт работы с Unity 3D и Unreal Engine 4? Поделитесь в комментариях.
Для VR у Unity более качественный антиалиасинг. В UE4 forward renderer, необходимый для MSAA, поддерживает не все фичи. Для 2D тоже Unity подходит лучше. В остальном у UE4 абсолютный приоритет. Что тут обсуждать, это AAA-движок с большой историей. Многое из того, что он может из коробки, Uniiy просто не поддерживает. Получить качественные шейдеры в нем в разы проще, чем в Unity.
Пытался начинать с юнити. И, честно говоря, мало что понял. При работе с ue4 достаточно быстро разобрался. Но, к сожалению, в решении всех задач приходится ковыряться в иностранных источниках. По юнити материалов гораздо больше.
Короче говоря, два года назад я бы рекомендовал всем юнити, но сейчас рекомендую ue4.
Я начинал делать игру в Unity3d. Купил необходимые ассеты для удобной работы, но в итоге, так и забросил. Для работы в юнити, нужно знать программирование (js, а лучше c#) на хорошем уровне. Другое дело UE4. Блупринты спасут любого, а что то серьёзное можно взять фрилансера.
Фраза «Для работы в юнити, нужно знать программирование» говорит совсем не в пользу UE.
Да, у автора была неточная формулировка, но думаю, это простительно, раз уж «many in the Unity development community (and even in the Unity corporation) refer to UnityScript and JavaScript as if they were equivalent or interchangeable».
Поправили и добавили ссылку, спасибо!
Часто говорят, что там дескать JS, да. Но мне как джаваскриптизеру с десятилетним стажем проще было писать на C#, чем на этом якобы JS. И вот почему:
* Никаких встроенных в JS объектов, функций и API там нет. У массивов, строк и объектов другие свойства и методы. Прокидываются вещи из рантайма юнити, надо искать, что и где.
* Некоторые, казалось бы, очень простые и очевидные, синтаксические конструкции тупо не работают.
* Классы не похожи ни на ES6, ни на TypeScript, ни на CoffeeScript
* Явное указание типов вроде не обязательно, но иногда компилятор в самый неожиданный момент не может вывести тип автоматически и надо идти и прописывать. Опять так декларация типов не совсем такая, как в TypeScript или ActionScript, а как описать сложные типы не всегда очевидно.
* Нет нормального редактора (MonoDevelop таким не является), который бы поддерживал этот синтаксис, подсвечивал ошибки, давал навигацию и так далее (я уж молчу про linting и рефакторинг).
В общем, нельзя просто взять и начать писать на UnityScript. Может быть, если JS (или ActionScript) у вас первый и единственный язык, это проще, чем, скажем, учить C# с нуля, но и то не факт, ибо по шарпу дофигалиард учебных материалов.
Простите за лонгрид и технические подробности, накипело:)
Да и я бы не советовал UnityScript там использовать. Юнитишники сами жалеют, что когда-то его ввели. И каждый раз проскакивают мысли о том, что они хотят выпилить его совсем. Так что, предполагаю, что в ближайшую пару лет они его совсем выпилят и оставят только C#.