К основному контенту

Unity or not unity


В начале разработки игры иногда встаёт вопрос выбора технологии, иногда находятся люди, которые настойчиво агитируют за использование unity 3d. Оно и понятно - красивый сайт с рекламными лозунгами, примеры выпущенных продуктов. Но на практике я встречаю не очень лестные отзывы о разработке на юнити. Рассмотрим преимущества и недостатки юнити относительно нативной разработки.

Преимущества:
  • Кроссплатформенность - юнити поддерживает широкий спектр платформ из коробки
  • Полный набор инструментария в одной среде
  • Быстрая разработка, быстрое изучение

Все преимущества хорошо расписаны на официальном сайте юнити. Теперь рассмотрим недостатки на примере моего личного опыта использования и по отзывам других пользователей.

Недостатки:
  • Закрытый исходный код и проприетарная модель - это означает что вы зависите от разработчиков юнити и можете пользоваться только тем, что они успели реализовать. Ну скажем использовать свою физику, свой звук, синтез речи, работу с железом будет не так просто и связано со сложностями.
  • Каждую новую игру вы начинаете писать по сути с нуля, переиспользовать наработки проблематично. При апдейте графики в вашей игре, вы будете вставлять каждую текстурку ручками ( если посмотреть вакансии по юнити, половина из них - написание системы интеграции контента или ресурсной системы).

Теперь немного отзывов из сети:
  • Unity tends to be somewhat of a memory hog. It takes more memory than you think it should; probably due to caching things like textures. This can cause problems debugging and even OOM errors on mobile devices
  • Performance problems can be hard to locate, address, and fix since you are dealing with a black box (no source code)
  • Unity's own Asset Server costs a pretty penny. And it sucks, really, really hard. It doesn't even have branching. While Unity3D theoretically supports 3rd-party SCM systems, using them is wrought with peril too. I've seen import settings "magically" change after SVN commit, or all objects' parameters disappear after using Perforce. All these can be worked around, but anyway, Unity3D + Source control = pain.
Ещё из личного опыта:
  • Пришлось отказаться от юнити на одном проекте, когда начались проблемы с памятью. Сейчас это не так актуально, т.к. слабые девайсы вытесняются с рынка.
  • Ребята (студенты) писали сравнительно маленькую игру на юнити, в целом они успешно её сделали. Но их впечатления свелись к тому, что они больше не хотят использовать юнити. 
Юнити - это быстрый старт, но не всегда эффективная дальнейшая разработка. В целом если нет своего решения, то надо использовать юнити. Если писать с нуля (движок) за юнити уже не угнаться. Для крупных и средних проектов (скажем так, разрабатываемых больше года, больше чем 4-мя программистами) юнити не самый лучший вариант. Я считаю, что лучшая сфера применимости юнити мелкие проекты (до полугода в разработке, 1-2 программиста). Также юнити хорошо подходит для прототипирования (с учетом того, что прототип пойдет в помойку). Но если нужен стопроцентный контроль над проектом во всех аспектах, юнити не подходит. Путь юнити это использовать то, что вам дали, и как из кирпичиков собирать проект. Если что-то не получается, проблема решается выбором другого компонента или другого решения, а не решением собственно проблемы. Если всё это устраивает – юнити ваш выбор.

Комментарии

Популярные сообщения из этого блога

Мобильное устройство будущего

Введение Однажды я задумался и представил себе портативное устройство будущего. Каким оно будет через 1000 лет. А может быть и раньше, развитие технологий идёт очень быстро, не уследишь :) Разумеется если человечество не уничтожит себя и технологии продолжат своё развитие. Человечество может устроить ядерную войну, или ещё какую-нибудь войну, которая отбросит нас назад. В этом случае портативное устройство будущего будет называться "палка-копалка" или "камень" и мы будем бегать с голой жопой по выжженой планете:) Не будем рассматривать такой вариант развития событий ( хотя честно говоря мне он кажется наиболее правдоподобным, т.к. каждый человек в отдельности не такой уж и глупый и обладает высоким интеллектом, особенно некоторые индивидуумы, но человечество в целом ведет себя как бактерии не обладающие разумом, бесконтрольно размножаются и потребляют свою планету). Мы рассмотрим фантастический вариант развития событий - когда человечество руководствуется разумом ...

Моё развитие как разработчика игр

Ярило студио - это хороший проект, но он пока что не вышел за рамки "занятий по вечерам и в свободное время". Поэтому всё основное время ( последние годы ) - я работаю в небольшой  компании по разработке игр. О ней и хочу немного рассказать, не буду её называть, т.к. в целом говорю не приятные для неё вещи. В основном компания делает игры как аутсорс, т.е. внешние деньги, внешний заказчик. Я работаю на позиции рядового программиста и смотрю на всё со стороны и офигиваю. За последние полтора года я поучаствовал в шести проектах, очень многое узнал и многому научился. От чего же я офигиваю? От чувства несправедливости и от того как бездарно и неэффективно сливает бабло хозяин компании. В компании совершенно нет градации по уровню мастерства у разработчиков, нет управленческой иерархии. Полная анархия привела в итоге к тому что никто ни за что не отвечает. Компания держится на плаву только за счёт художников, потому что их работа линейно прогнозируется и легко поддаё...

Редакторы для казуальных и независимых игр. Адаптация открытого непрофильного софта под нужды разработчика игр

Введение Часто инди-разработчики или разработчики казуальных игр сталкиваются с проблемой нехватки специализированных редакторов, инструментов, утилит и т.д. ( так называемого middleware ) для создания контента для своих игр. Пример такого контента - это уровни, сложные анимации, 2d монстры и техника, а также параметры настройки и конфигурации всего этого. Прописывать всё это вручную в текстовых, редакторах (или скажем xml-редакторах) это не всегда удобно. В самом деле не будешь же ручками прописывать координаты полигонов в двухмерном уровне. Или задавать цвет глаз в шестнадцатеричном коде в xml-файле описания эльфа. Обычно бывает сложно найти удовлетворяющий всем нуждам редактор или тулзу. Самые частые проблемы это: закрытый код недостаточные возможности для конкретно вашей игры (ограничения по редактированию) навязываемый api и библиотеки от создателей middleware Часто принимается решение писать свой собственный редактор и набор утилит, но такое решение не всегда раци...