Comments 41
Я надеюсь, юнити никогда не станет таким упрощенным трешем, который захотелось автору статьи. Хочется ущербной простоты без знаний — это на Defold / Godot. Хочется «по-настоящему» — обмазываемся нейтивными библиотеками и пытаемся заставить это все работать на всем зоопарке доступных устройств.
Уважаемый Leopotam, цель любого фрэймворка — упростить разработку. Разве нет?
Нет, цель фреймворка — предоставить ограниченный функционал, целью которого и было создание фреймворка. И нет, юнити не фреймворк. Я могу расписать по каждому пункту, почему написанное ужасает, стоит?
Если честно, то мне было бы очень интересно ваше мнение, возможно я почерпну для себя что-то новое.
Проблема: я потратил два дня на то, чтобы найти нужные SDK, JDK, NDK и сделать так, чтобы Unity с ними заработал. На моей машине до Unity уже присутствовали sdk из андроид студии, но с ними не завелось, пришлось искать что-то другое, устанавливать, пробовать, опять искать… два дня…
Все работает, нужно только в самом SDK доустановить нужный минимальную платформу-таргет — сведения прямо открытым текстом можно взять из ошибок при сборке.
Вообще про SDK — это не проблема юнити, т.к нельзя докачивать последние версии просто так, какие-то проекты нужно собирать на старых версиях юнити. Юнити может только подсказать где и что взять для сборки под нужную платформу (а там не только android, подо все платформы делать автоматическую закачку самого нового софта?).
Про NDK немного другая тема. С лета 2019 гугль перестанет принимать билды без поддержки ARM64 (v8), а это значит, что mono в качестве рантайма уже по сути доживает последние месяцы. Актуальным рантаймом является IL2CPP, т.е весь MSIL транслируется в нейтив и именно для этого и нужны нейтивное NDK под android.
Проблема: Unity из коробки не понимает SVG. Даже всякие маленькие JS фрэймворки типа Paper.js просто шикарно работают с вектором, а такой слон как Unity — нет.
Решение: установил какой-то бета-пакет, который, вроде как читает SVG, но в итоге — конвертит его в растр. Приемлемо, но стыдно, Unity!
Открою большую тайну — gpu вообще не умеет работать ни с чем, кроме растра и 3д геометрии. Любые 2д движки внутри себя все делают в 3д пространстве, хотят они этого или нет. Ну если правда они хотят продемонстрировать достойную скорость работы, софтовый рендер руками никто не отменял. То, что веб-движки умеют в svg и прочее — так они не сами рендерят, а пользуются услугами браузера, который внутри точно так же выполняет растеризацию при изменении векторных данных. Юнити делает это все самостоятельно и изначально дает доступ почти ко всему рендеру, который можно поменять практически под себя в любом месте. Если прямо не хочется растра, а хочется вектора — это можно сделать через геометрию, разумеется без плавных кривых (апроксимировать прямыми до нужной точности) — это уменьшит размер и часто может ускорить работу, но нужно проверять на каждом кейсе.
Проблема: как видно на скриншоте, есть земля, и на ней есть снежок. И это еще и Mesh и Polygon Collider. То есть это поверхность, которая взаимодействует с объектами и которую можно изменять в редакторе. Так вот в текущей версии Unity нет стандартных средств, которыми можно такое моделировать.
Все потому, что 2д пришито сбоку, чтобы увеличить аудиторию. IMHO, это сильно увеличивает количество пассажиров, но сильно уменьшает их качество. Умея в 3д, можно реализовать любое 2д, но все хотят большую красную кнопку с надписью «сделать п#$ато».
Проблема: очень сложная система 3d позиционирования и поворотов, ненужная в 2D играх.
Я бы сказал — 2д игры не нужны в юнити, а система позиционирования впоне вменяема даже для ориентации в пространстве экрана. Берем единственный конструктор Quaternion.Euler(0, 0, angle) и практически все проблемы решены.
Полноценные бряки — удел тех, кто платит. Вот тут поправьте меня, если ошибаюсь, но я никак не смог настроить Visual Studio для дебага, хотя находил видео, в которых видно, что настраивать ничего и не надо, оно всё само должно работать. Сделал вывод, что дебаг доступен в платных версиях.
Отладка полностью бесплатна и зависит от настроек IDE. Для VisualStudio вроде как есть встроенный пакет Unity Tools (они его купили и сделали бесплатным, либо его нужно докачивать) — не могу точно сказать, винду видел 6 лет назад. В Rider есть поддержка дебага, в VSCode аналогично — через бесплатные плагины.
Юнити вообще по сути вся бесплатна, начиная с 5.x. Платными остались только облачные сервисы по коллаборации, билду в облаке и т.п штукам, которые можно повторить локально (буди только совместного редактирования не будет, но то очень сомнительная вещь). Да, еще можно будет убрать штатный сплеш юнити. На этом платность заканчивается.
Проблема: несмотря на удобство встроенной системы пользовательского ввода, не хватает простоты обработки обычных одиночных тапов, кликов и свайпов. Хотелось бы использовать один метод, который вернет координаты одиночного клика/тапа для разных типов устройств: тач и десктопа с мышкой, например.
Решение: пришлось написать свой класс прослоечку и обернуть нужные эвенты.
Юнити — это multipurpose движок и если делать вещи узкой направленности — он разрастется просто дико. Под каждый девайс придется делать что-то свое и как этим всем придется управлять — хз. Те же джойстики, мыши, стилусы, мультитачи — очень много устройств ввода. Поэтому юнити дает унифицированное апи для получения информации и дальше пользователь сам может решить как он будет обрабатывать все это добро.
Проблема: нельзя объекту присвоить координаты клика и увидеть его в нужном месте, и это немного неочевидно.
Решение: Нужно сперва почитать документацию, разобраться и использовать различные методы для маппинга координат
Можно попробовать использовать OnGUI метод для отладки и в нем уже рисовать все, что угодно через GUI.xxx и GUILayout.xxx. Повторяюсь — только для отладки, для игрового функционала крайне не рекомендую использовать.
Проблема: из коробки поставляются лишь самые базовые элементы, да и то с некоторыми приходится повозиться.
Тут как посмотреть. По сути все контролы — это картинка + поведение. Картинку делают артовики под каждый конкретный проект, чтобы получился единый UIKit, поэтому смысла в богатом наборе штатных виджетов как бы и нет. Любой сложный виджет можно сконструировать на базе штатных или даже написать код. Внезапно, все виджеты написаны на шарпе и доступны на битбакете, можно посмотреть как сделано то или иное и подкрутить у себя. Есть даже реп с кастомными виджетами.
Проблема: при билде пустого проекта, его размер равен 21.9 MB (23,061,612 bytes)
Потому что нужно уметь его готовить. Пустой билд под IL2CPP с ".netfw46" и профилем ".net std 2.0" весит меньше 9мб — как когда-то пустой билд с mono рантаймом. Страйпинг неиспользуемого кода делается только при таком конфиге, если выбрать другой профиль, то фокус не получится.
Если не затруднит, можете сделать скиршот настроек, пожалуйста?
Собирать FAT-билды смысла нет: x86-девайсы по статистике на 3 квартал 2018 занимают меньше 1%, а ARM64-железо умеет исполнять ARMv7 код, поэтому одной архитектуры будет достаточно на данный момент.
Можно написать небольшой скрипт, который делает 3 билда для разных архитектур. А в новых версиях Unity этот функционал делается выставлением одной галочки.
А можно написать скрипт, который делает 20 билдов с разными рандомными настройками, но зачем? Тут посыл был именно в целесообразности — не смысла делать, а самое главное, поддерживать столько вариаций билдов под android, по крайней мере еще полгода.
Как связана версия ОС (а безопасность привязана исключительно к ней) на конечном устройстве пользователя и архитектура cpu, под который собирается билд? От того, что мы соберем билд под x86 вендор устройства сразу опомнится и выкатит на него android8? В x86 устройствах разочаровались все, за исключением китайцев, клепающих совсем непотребный треш за копейки. ARMv8 станет обязателен только с июля-августа 2019, но подобное железо уже сейчас прекрасно исполняет приложения под ARMv7.
Проблема: собрав проект под платформу JS/HTML5 (для тестов), выяснилось, что текстов, написанных по-русски, просто нет.
Вот тут я совсем не понял юмора. Есть штатный Arial, в котором есть русские глифы и если используем штатные uGui компоненты, то все работает без проблем. Если мы говорим про TextMeshPro, то это вообще отдельная песня — он не умеет в динамический truetype-шрифт и хочет, чтобы все глифы были запечены в sdf-атлас в редакторе. В будущем они планируют приделать поддержку генерации глифов на лету, то нет никаких сроков.
Проблема: Игра жутко начинает тормозить при наличии сложных коллайдеров, при использовании Continuous режима для Collision Detection, когда в одной сцене используется несколько Particle System, короче при использовании всего, что придает эффектность и красоту играм.
А еще можно узнать, что 2д движок физики — это box2d. Теоретически можно попробовать все сделать через physx колайдеры с ненулевой толщиной и попробовать замерить скорость — раньше это 2д-поделие было гораздо медленнее, чем вылизанный 3д-physx.
Вообще, любая физика — это очень тяжело и нужно очень четко настраивать в плане баланса между производительностью и удовлетворительным качеством симуляции.
Системы частиц — сюда же, никакой физики на них быть не должно, такое неприятно даже десктопному железу, не говоря уже про мобилки. С партиклами есть еще одна проблема — это альфаблендинг и overdraw с ним, что очень сильно бьет по скорости рендера. Это чисто специфика мобильного-gpu железа.
Ну и вообще нужно понимать, что геймдев — оно такое. Тяп-ляп может слепить каждый, а чтобы оно реально было быстрым, занимало мало места и не вызывало отторжения — это труд.
Еще какие-то вопросы имеются? :)
Еще какие-то вопросы имеются? :)
Спасибо, очень интересно было почитать мнение человека, хорошо знающего о чем говорит :)
И да, есть один вопрос, какой движок для 2D порекомендуете именно вы?
Не обязательно простой, можно и с высоким порогом входа.
И да, есть один вопрос, какой движок для 2D порекомендуете именно вы?
Не обязательно простой, можно и с высоким порогом входа.
Если хочется высокой производительности, маленького размера и полного контроля, то только самопал на базе cocos2d, libdgx и т.п в качестве рендера, физику придется брать либо VelcroPhysics (бывший FarseerPhysics), либо Box2D. И так для каждого функционала, который потребуется. Часть новичков сбежала в Godot (но там даже нет gles2 поддержки, т.е хз как оно вообще на мобилках работает), активно пушат сейчас Defold (туда перебежал евангелист юнитехов Олег Придюк, больше о нем не слышал) из-за низкого порога входа. Но я ненастоящий сварщик, 2д мне крайне чуждо, я смотрю только в сторону 3д.
З.Ы. Вот интервью, может будет полезным: app2top.ru/conferences/oleg-pridyuk-defold-imeet-smy-sl-poprobovat-esli-vas-ne-ustraivaet-unity-89171.html
З.Ы. Вот интервью, может будет полезным: app2top.ru/conferences/oleg-pridyuk-defold-imeet-smy-sl-poprobovat-esli-vas-ne-ustraivaet-unity-89171.html
Отладка брейкпойнтами у меня работает в бесплатной версии, причем и в VS и VS Code, но… только один раз до следующей перезагрузки.
У меня в студии просто нет кнопки «Attach to Unity», есть только «Start», как в обычных проектах.
Возможно это как-то настраивается?
Возможно это как-то настраивается?
К слову, только что был анонс 2018.3: blogs.unity3d.com/ru/2018/12/13/introducing-unity-2018-3
We’ve updated the debugger extension for Visual Studio Code, an open-source, code-optimized editor available on macOS, Windows, and Linux. The Debugger for Unity extension provides debugging support for C# scripts in a lightweight environment, and the latest 2.x version adds various improvements, including support for the Mono 4.x scripting runtime. To get started, follow the setup instructions on the Visual Studio Code site.
If you’re looking for a more integrated and feature-rich C# editing and debugging environment, there’s also Visual Studio and Visual Studio for Mac.
OpenJDK installed with Unity
By default, Unity now installs a Java Development Kit based on OpenJDK, ensuring you always get the correct JDK version.
А сколько ребенку лет? Игра в GP 16+ :)
Проблема: я потратил два дня на то, чтобы найти нужные SDK, JDK, NDK и сделать так, чтобы Unity с ними заработал.
Странно. Буквально месяца полтора назад установил юнити побаловаться, чисто ради теста собрал все под андроид — установка заняла минут 15, из которых минут 10 эти библиотеки скачивались. Причем там и делать ничего не нужно было, я просто тыкнул собрать под андроид, и там юнити уже сама писала чего не хватает и предлагала перейти на сайты, где оставалось всего лишь нажать кнопку «скачать».
Проблема: при билде пустого проекта, его размер равен 21.9 MB (23,061,612 bytes)
Замеры компиляции пустого проекта (android):
6.4МБ armv7+il2cpp+stripEngineCode
11.3МБ armv7+il2cpp (без stripEngineCode)
10.4МБ armv7+mono+(strip assemblies)
12.2МБ armv7+mono (без strip assemblies)
Unity 2018.2.8f1 (64-bit)
Статья якобы дает советы, а по сути советы дают автору.
Я не против туториалов и советов, но не стоит писать статью с советами после первой пробы.
Знающие люди не получили новой информации, а новички вряд ли поймут как решать эти проблемы, потому что Вы так и не написали как решить их, а просто пожаловались и предложили вариант как бы Вы хотели чтобы было удобно.
Все проблемы в статье решаемы, если почитать документацию и немного знать математику.
Не нужно ругаться на юнити, при изучении других технологий Вы наверняка тоже тратили время. Это нормально.
Я не против туториалов и советов, но не стоит писать статью с советами после первой пробы.
Знающие люди не получили новой информации, а новички вряд ли поймут как решать эти проблемы, потому что Вы так и не написали как решить их, а просто пожаловались и предложили вариант как бы Вы хотели чтобы было удобно.
Все проблемы в статье решаемы, если почитать документацию и немного знать математику.
Не нужно ругаться на юнити, при изучении других технологий Вы наверняка тоже тратили время. Это нормально.
Sign up to leave a comment.
Unity — подводные камни разработки 2D игры