Що є найбільш серйозним обмеженням Єдності? [зачинено]

Прочитавши це гаряче запитання про Unity vs. UDK vs. ID, мені цікаво дізнатись: що таке багаторазове враження, найбільш покалічувальне обмеження (-ла) Єдності?

Для того, щоб це питання не було суб'єктивним, я знову кажу про головних злочинців, які повторюються в Єдності. Це те, що вам, як користувачеві Unity, дуже хочеться, щоб хтось розповів вам про нього, перш ніж почати користуватися ним.

Я чув від когось, що Unity не дуже добре справляється з контролем версій, оскільки він генерує безліч бінарних файлів (які не можна змінити). Це, на мене, насправді не калічить, коли я працюю на самоті.

Думки?

Дозвольте мені заздалегідь сказати це, що хлопці з Єдності досить добре почули основні якості, з якими стикається їхня громада, і, врешті-решт, обіцяють обіцяти покращити справи. Існує також багато питань, які виникають лише на певних платформах або є питаннями особистої переваги чи конкретних питань гри, над якою ви працюєте.

Це сумно:

1) Погана інтеграція управління джерелами та великі інструменти для команди. Як ви вже згадували, багато бінарних файлів, що не змінюються. Редактор ігнорує прапор лише для читання для файлів сцени. Фактичні файли, які ви повинні зареєструвати, не очевидні. Дещо з цього виправляється в 3.5 за допомогою інтеграції SVN та P4. Також є обіцянки текстових форматів сцен. ОНОВЛЕННЯ: Текстовий формат сцени тепер доступний у Pro версії Unity. Дивіться тут .

2) Повільний, програміст, орієнтований на інструменти інтерфейсу користувача. Кожен віджет - це власний розіграш, який має багато накладних витрат на мобільних платформах. Не існує поняття таких речей, як панелі з анімацією та все те, що інші модні речі, що дозволяє користувальницькому інтерфейсу почувати себе добре, не перекочуючи його самостійно. У дорожній карті є обіцянка щодо нової системи інтерфейсу користувача (3.6?). Є деякі сторонні інструменти, але вони не чудові.

3) Дійсно рудиментарне редагування частинок. Хоча вони обіцяють нову систему на основі кривої в 3.5. ОНОВЛЕННЯ: Ця система на основі кривих, яка називається Shuriken, тепер доступна. Дивіться тут .

4) Ви не можете вкладати збірні елементи. Невелика проблема, але коли ви звикли працювати з системою збірних пристроїв і всією потужністю, яку вона вам надає, це може розчаруватись. Це обіцяно, але конкретної дати немає. ОНОВЛЕННЯ: Тепер ви можете вкладати збірні елементи.

5) Далі неможливо отримати гру для iOS під лімітом повітря. Бінарний потік - це як 8 мег у найкращому випадку. Це не те, що легко виправити.

6) Нульові довідникові винятки збиваються платформи, які не дозволяють компілювати JIT-код. У окремій або веб-версіях НРЕ потрапляють. Це все ще невипадкове виключення, але принаймні програма намагатиметься продовжувати працювати. На iOS він вибиває з ладу пристрій. Ви можете перевести його в режим налагодження і вловлювати деякі типи винятків, але продуктивність страждає.

7) Працюючи в грі з багатоплатформою, кожен раз, коли ви перемикаєте побудову цілей, вам доведеться знову імпортувати все, і це займе тривалий час. Я працював над цим, фактично маючи на диску кілька копій проекту. Мабуть, є імпортний сервер активів, який надходить у 3.5.

Коли я з другом оцінили Unity для більшого проекту, ми виявили, що однією з найбільших проблем була ефективність роботи з їх програмним забезпеченням. Якщо я точно пам’ятаю, у нас було щось на кшталт 10 анімованих об’єктів з приблизно 1000 вертами кожен, і я отримав 20 кадрів в секунду під час використання середнього комп'ютера ... Не дуже добре ...

Моя проблема номер один полягала в контролі версій. Рішення? Просто використовуйте DropBox для проектів Unity. Якщо ви правильно налаштували його (тобто заплатили за їх послугу "PackRat"), він підтримує історію перегляду. Також набагато простіше співпрацювати з дизайнерами, таким чином, які не хочуть знати про традиційний контроль версій, DropBox надає їм прозоре рішення. Мінус розгалуження / злиття насправді не підтримується таким, яким вони є, наприклад. git, SVN.

Для тих, хто сумнівається ...

Хоча Dropbox функціонує як служба зберігання даних, його увага приділяється синхронізації та спільному доступу. Він підтримує історію версій, тому файли, видалені з папки Dropbox, можуть бути відновлені з будь-якого з синхронізованих комп'ютерів. [33] [34] Контроль версій Dropbox також допомагає користувачам знати історію файлу, над яким вони зараз працюють, дозволяючи більш ніж одній особі редагувати та повторно публікувати файли без ускладнень, втрачаючи попередню форму. [35] Історія версій обмежена 30 днями. Доступний платний варіант для необмеженої історії версій під назвою "Pack-Rat".

Див тут для солідного посилання з форумів Unity.

Окрім цього, єдине, що мені стало прикро для Unity, - це те, що у нього немає точки входу програми так, як це робить C (main ()) або AS3 (клас документа). Але ви просто покладете свою програму init на порожній GameObject, не велика справа. Потік коду дещо відрізняється і навколо цієї притаманної структури, але, знову ж таки, нічого надто важкого, щоб зрозуміти.

Що стосується ліцензії, то більшість людей не розуміє (і я особливо маю на увазі невеликі операції з інді та хобістів, які, можливо, не мають грошей, щоб заплатити за ліцензію професіонала та аддона менеджера активів), що ви можете робити майже все, що могли ніколи не хочу з базовим / безкоштовним виданням. Дійсно, це не якийсь величезний бар'єр, команда Unity була дуже щедрою.

Я подумав про ще одне головне обмеження, яке мене дратує щодня, тому я публікую це окремо.

Unity3D хоче, щоб ви редагували свої сценарії в MonoDevelop, зокрема стару версію MonoDevelop, яку вони поширюють. Функція "Знайти файли" цієї версії порушена, оскільки використання її зазвичай призводить до зависання IDE, що робить його марним.

Це було б великим роздратуванням для будь-якого двигуна, але це масове роздратування Unity, оскільки воно заохочує дуже децентралізовану систему окремих компонентів, що діють на різні ігрові об'єкти. Але як можна дізнатися, які компоненти отримують доступ до яких властивостей, якщо ви навіть не можете шукати різні компоненти?

EDIT: Ця відповідь була розміщена в 2011 році: помилка Find In Files була виправлена ​​певний час тому, на щастя. І як кажуть коментатори, ви можете редагувати свій код в інших редакторах (хоча ваш вибір обмежений, якщо ви хочете мати можливість працювати в налагоджувачі).

Для мене найсерйозніше обмеження є у EULA:

"Обмеження азартних ігор" Ви не можете поширювати чи публікувати будь-який вміст ліцензіата у зв'язку з будь-якими видами азартних ігор без окремої ліцензії від Unity. "

Це означає, що, починаючи з v4.0, ви не можете використовувати Unity для ігор, пов’язаних з готівкою / випадковістю, якщо ви або ваші клієнти не готові платити додатковий ліцензійний збір, про який домовляєтесь у кожному конкретному випадку. Тобто вони бачать, скільки ти коштуєш, і оподатковують тебе відповідно, з цитуванням 6 цифр.

Більш тривожним є те, хто знає, що вони додадуть до vLA EULA. Можливо, всі соціальні ігри? Можливо, всі ігри для багатьох гравців?

Будь-який розробник, що використовує Unity, ризикує отримати викуп у майбутньому випуску.

Гарне питання. Для мене найбільша проблема - це графічний інтерфейс. Я не проти того, щоб він був орієнтованим на програміста, але я маю на увазі жахливий спосіб, коли об’єкти GUI є функціями, а не об’єктом, і що обробка графічного інтерфейсу вбудована в один виклик функції, який використовується для візуалізації та для обробки подій, і що немає інтеграції з системою введення (тобто кліки на елементах GUI можна інтерпретувати як кліки у світі) тощо.

Вторинною проблемою є відсутність адекватної підтримки управління версіями (здебільшого тому, що система використовує макет каталогів як макет проекту, який плутає VCS під час переміщення чи перейменування речей), але це можна вирішити, і це не є проблемою для всі.