Unity3D — один из самых популярных игровых движков. В последние годы всё больше отличных игр выходят благодаря тому, что Unity прост в использовании и предлагает разработчикам много готовых решений. Алексей Науменко, .NET Developer в Plarium Kharkiv, рассказал с чего разработчику начать изучение Unity.
Я учился в ХАИ по специальности «Телекоммуникации». У нас был преподаватель, который конструировал беспилотники. Благодаря ему уже на 4-м курсе я начал писать простой код на С для микроконтроллеров, которые управляют передачей данных с земли на БПЛА. Тогда я решил, что нужно выучить какой-то актуальный язык программирования, чтобы писать на нём постоянно, а не только для решения узких задач.
Выбирал я между С# и Java: читал книги по этим языкам, но потом просто открыл Visual Studio и Java IDE и сделал выбор в пользу первого по «обертке». Не самый правильный способ анализа преимуществ и недостатков, но о выборе я не жалею.
В 5–7 классах мы с другом пытались сделать игру. И хотя получилась ерунда, романтика процесса осталась со мной. К тому же я люблю играть, особенно в древние RPG. После университета я работал в нескольких продуктовых компаниях: год занимался веб-программированием, потом 4 года разрабатывал ПО для call-центров. Но меня всё время преследовала идея попробовать себя в разработке игр. Так что в свободное от работы время я стал думать, какой движок использовать для будущей игры.
Многие разработчики используют Unity и Unreal Engine, но я хотел изучить все варианты. Поэтому я стал разбираться, на чем написаны популярные проекты. Оказалось, что это либо самописные движки, как, например, у Naughty Dog, либо движки, о которых очень мало информации в интернете — чтобы работать с ними, нужно, скорее всего, некоторое время работать в индустрии и знать хотя бы общие принципы построения игровых движков.
Я вернулся к выбору между Unity и Unreal Engine. И так как на тот момент я уже 4 года программировал на .NET, выбор был прост: в Unity есть C#, а в Unreal Engine — нет. Еще один плюс Unity: я погуглил некоторые интересные мне вопросы и почти на все из них нашел попытки ответить. Пусть не всегда профессиональные, но информация была, и было с кем ее обсудить.
У Unity есть аналог StackOverflow — Unity Answers. Там очень просто найти ответы на конкретные вопросы на начальном этапе, поэтому порог входа очень низкий, особенно если человек понимает хотя бы общие принципы программирования.
Я изучал уже решенные задачи, похожие на те, что интересовали меня. Однажды я искал конкретное решение, но не нашел его в Asset Store. Поэтому начал мониторить форумы и наткнулся на парня, который делал именно то, что мне было нужно, но в Store его решение не пропустили по каким-то требованиям. Я написал ему сообщение и предложил купить его наработку. Он очень обрадовался возможности подзаработать — это был румынский десятиклассник. Чуть ли не лучшее мое вложение в изучение движка: 10$ плюс столько же за Swift-платеж.
Новичку полезно посмотреть, как работают над задачами другие люди, даже если это что-то примитивное. Ведь решений может быть множество. Когда начинаешь, как будто шаришь пальцами в темноте. Ты не знаешь, насколько удачно выбранное решение: возможно, с его реализацией возникнут проблемы в будущем или есть более простой вариант.
Всегда лучше ориентироваться на какой-то пример. Я распотрошил покупку: там было много наворочено, но я переделал это решение под свои нужды. Пока разбирал этот пример, многие вопросы начального уровня отпали. Так начал понимать основные принципы работы с Unity и продолжил разбираться с возможностями движка.
За месяц-полтора изучил базу, но не поверхностно, а достаточно предметно — то, что было нужно на тот момент. Сначала возникло очень много вопросов, как и с любой новой технологией. Я смотрел нативный код и читал мануалы, чтобы разобраться, почему что-то работает в Unity именно так, а не иначе. Но, конечно, будет тяжелее и дольше, если нет конкретных задач и ты не понимаешь, зачем это делаешь.
Нет смысла изучать Unity просто так — стоит начинать с решения конкретных проектных задач. Лучше сразу определиться: «Я хочу сделать Pac-Man». Начинаешь думать, что для этого понадобится: например, нужно реализовать управление персонажем. Желтое существо ест белые точки. Существо должно понимать, что наткнулось на съедобный объект — значит, нужно начать с определения соприкосновения съедобной точки с Пакменом. Тогда появляется конкретная проблема и необходимость искать пути ее решения — а это, по-моему, и есть лучший способ изучения технологии.
Когда мы собеседуем кандидатов, прямо говорим, что не проверяем знания Unity, а фокусируемся на .NET. На практике мы убедились: человека, который знает .NET, гораздо легче обучить работе с движком, чем того, кто начал изучать язык параллельно с Unity. Поэтому приглашаем на собеседования людей, которые знают .NET и просто хотят работать на Unity. Дальше всему обучим.
Иногда мы собеседуем Senior или Middle+ .NET программистов, которые не знакомы с Unity вообще. При этом человек не переходит на позицию Junior, потому что в Plarium, да и в работе с движком, нет понятия Unity Junior. Если с .NET всё хорошо, освоить движок будет очень просто.
Кроме Unity Answers есть еще UnifyWiki. Можно декомпилировать код и посмотреть результат (он не обфусцирован).
На старте очень пригодились форумы (answers.unity3d.com и forum.unity3d.com). Также я читал книгу Game Engine Architecture Джейсона Грегори. Автор в ней не говорит конкретно о Unity, но подробно рассматривает составные части и особенности игровых движков в целом. Он в деталях описывает, из чего состоит движок, какая математика нужна, как устроен рендеринг. Эта книга расширяет представление о Unity: я начал понимать, что в этом движке есть или должно быть, что с него спрашивать. Единственная трудность — для прочтения этой книги нужно быть очень мотивированным: она не нудная, но достаточно объемная.
Большие компании любят Unity за кроссплатформенность. Если ты что-то написал, оно билдится и под iOS, и под Android — пусть и с надстройками, но зато сразу работает без особых плясок. Конечно, если это не касается платежки :)
В нашем случае преимущество также в том, что Plarium — официальный партнер Unity с поддержкой уровня Enterprise Support. Нам не только быстро отвечают на запросы, но и предоставляют больше открытого кода, и мы можем сами что-то вскрыть и допилить.
Надеюсь, информация будет полезна тем, кто планирует работать с Unity. Успехов!
Как я начал программировать
Я учился в ХАИ по специальности «Телекоммуникации». У нас был преподаватель, который конструировал беспилотники. Благодаря ему уже на 4-м курсе я начал писать простой код на С для микроконтроллеров, которые управляют передачей данных с земли на БПЛА. Тогда я решил, что нужно выучить какой-то актуальный язык программирования, чтобы писать на нём постоянно, а не только для решения узких задач.
Выбирал я между С# и Java: читал книги по этим языкам, но потом просто открыл Visual Studio и Java IDE и сделал выбор в пользу первого по «обертке». Не самый правильный способ анализа преимуществ и недостатков, но о выборе я не жалею.
Почему пошел в геймдев и выбрал Unity
В 5–7 классах мы с другом пытались сделать игру. И хотя получилась ерунда, романтика процесса осталась со мной. К тому же я люблю играть, особенно в древние RPG. После университета я работал в нескольких продуктовых компаниях: год занимался веб-программированием, потом 4 года разрабатывал ПО для call-центров. Но меня всё время преследовала идея попробовать себя в разработке игр. Так что в свободное от работы время я стал думать, какой движок использовать для будущей игры.
Многие разработчики используют Unity и Unreal Engine, но я хотел изучить все варианты. Поэтому я стал разбираться, на чем написаны популярные проекты. Оказалось, что это либо самописные движки, как, например, у Naughty Dog, либо движки, о которых очень мало информации в интернете — чтобы работать с ними, нужно, скорее всего, некоторое время работать в индустрии и знать хотя бы общие принципы построения игровых движков.
Я вернулся к выбору между Unity и Unreal Engine. И так как на тот момент я уже 4 года программировал на .NET, выбор был прост: в Unity есть C#, а в Unreal Engine — нет. Еще один плюс Unity: я погуглил некоторые интересные мне вопросы и почти на все из них нашел попытки ответить. Пусть не всегда профессиональные, но информация была, и было с кем ее обсудить.
У Unity есть аналог StackOverflow — Unity Answers. Там очень просто найти ответы на конкретные вопросы на начальном этапе, поэтому порог входа очень низкий, особенно если человек понимает хотя бы общие принципы программирования.
С чего начать обучение
Я изучал уже решенные задачи, похожие на те, что интересовали меня. Однажды я искал конкретное решение, но не нашел его в Asset Store. Поэтому начал мониторить форумы и наткнулся на парня, который делал именно то, что мне было нужно, но в Store его решение не пропустили по каким-то требованиям. Я написал ему сообщение и предложил купить его наработку. Он очень обрадовался возможности подзаработать — это был румынский десятиклассник. Чуть ли не лучшее мое вложение в изучение движка: 10$ плюс столько же за Swift-платеж.
Новичку полезно посмотреть, как работают над задачами другие люди, даже если это что-то примитивное. Ведь решений может быть множество. Когда начинаешь, как будто шаришь пальцами в темноте. Ты не знаешь, насколько удачно выбранное решение: возможно, с его реализацией возникнут проблемы в будущем или есть более простой вариант.
Всегда лучше ориентироваться на какой-то пример. Я распотрошил покупку: там было много наворочено, но я переделал это решение под свои нужды. Пока разбирал этот пример, многие вопросы начального уровня отпали. Так начал понимать основные принципы работы с Unity и продолжил разбираться с возможностями движка.
За месяц-полтора изучил базу, но не поверхностно, а достаточно предметно — то, что было нужно на тот момент. Сначала возникло очень много вопросов, как и с любой новой технологией. Я смотрел нативный код и читал мануалы, чтобы разобраться, почему что-то работает в Unity именно так, а не иначе. Но, конечно, будет тяжелее и дольше, если нет конкретных задач и ты не понимаешь, зачем это делаешь.
Нет смысла изучать Unity просто так — стоит начинать с решения конкретных проектных задач. Лучше сразу определиться: «Я хочу сделать Pac-Man». Начинаешь думать, что для этого понадобится: например, нужно реализовать управление персонажем. Желтое существо ест белые точки. Существо должно понимать, что наткнулось на съедобный объект — значит, нужно начать с определения соприкосновения съедобной точки с Пакменом. Тогда появляется конкретная проблема и необходимость искать пути ее решения — а это, по-моему, и есть лучший способ изучения технологии.
Переход с .NET на Unity на практике
Когда мы собеседуем кандидатов, прямо говорим, что не проверяем знания Unity, а фокусируемся на .NET. На практике мы убедились: человека, который знает .NET, гораздо легче обучить работе с движком, чем того, кто начал изучать язык параллельно с Unity. Поэтому приглашаем на собеседования людей, которые знают .NET и просто хотят работать на Unity. Дальше всему обучим.
Иногда мы собеседуем Senior или Middle+ .NET программистов, которые не знакомы с Unity вообще. При этом человек не переходит на позицию Junior, потому что в Plarium, да и в работе с движком, нет понятия Unity Junior. Если с .NET всё хорошо, освоить движок будет очень просто.
Что почитать
Кроме Unity Answers есть еще UnifyWiki. Можно декомпилировать код и посмотреть результат (он не обфусцирован).
На старте очень пригодились форумы (answers.unity3d.com и forum.unity3d.com). Также я читал книгу Game Engine Architecture Джейсона Грегори. Автор в ней не говорит конкретно о Unity, но подробно рассматривает составные части и особенности игровых движков в целом. Он в деталях описывает, из чего состоит движок, какая математика нужна, как устроен рендеринг. Эта книга расширяет представление о Unity: я начал понимать, что в этом движке есть или должно быть, что с него спрашивать. Единственная трудность — для прочтения этой книги нужно быть очень мотивированным: она не нудная, но достаточно объемная.
Преимущества работы с Unity
Большие компании любят Unity за кроссплатформенность. Если ты что-то написал, оно билдится и под iOS, и под Android — пусть и с надстройками, но зато сразу работает без особых плясок. Конечно, если это не касается платежки :)
В нашем случае преимущество также в том, что Plarium — официальный партнер Unity с поддержкой уровня Enterprise Support. Нам не только быстро отвечают на запросы, но и предоставляют больше открытого кода, и мы можем сами что-то вскрыть и допилить.
Надеюсь, информация будет полезна тем, кто планирует работать с Unity. Успехов!
Комментарии (22)
Zhuck
11.08.2017 10:05-3А как перейти с Pascal на Delphi? Разве Бетти не целиком и полностью лежит на шарпе?
floralDenis
11.08.2017 10:05Подскажите, пожалуйста, а по какой книге(книгам) лучше всего изучать С#?
Klotos
11.08.2017 12:55+1Если для новичка, который не знаком с C#, то, ИМХО, «Э.Троелсен. Язык программирования C# 20xx и платформа .NET y.y» (книга обновляется, выходят и переводятся на русский новые версии, потому и добавил «хх/у.у»).
floralDenis
11.08.2017 17:55А если я немного знаком(изучал параллельно с Unity)
HexGrimm
11.08.2017 23:44Лучше забыть про юнити-опыт и изучать по Э.Троелсену, тренируясь в консольных приложениях и так далее по NET. стеку. Одна из плохих особенностей юнити, это то, что вы привыкаете работать в рамках фреймворка и не прививаете себе мышление использования инверсии зависимостей.
lexxpavlov
12.08.2017 23:40Я очень люблю книгу Троелсена, но новичкам не рекомендую — она написана для программистов-профессионалов, которые умеют программировать, но не знают c#. Например, в книге подробно описывается, как в c# использовать ООП, но не написано, зачем он нужен вообще. То есть, это шикарная книга для изучения c#, но не для изучения программированию.
BogdanF
14.08.2017 11:56Книгу лучше использовать как справочник. Намного экономней в плане времени пройти один из курсов, которых сейчас в нете навалом.Например от . 20 баксов в месяц… Есть на Rutracker. По книгам лучше не учиться. Вообще, не рекомендую unity изучать вместе с языком, C# Unity — не совсем C#. Лучше для этого взять Monogame.
aquamakc
Небольшая поправка. Если код пишется на Mono, который устанавливается вместе с Unity. Есть возможность настроить систему так, что код будет писаться в Visual Studio, но тогда о кроссплатформенности можно забыть. По крайней мере так было год назад.
HexGrimm
Это не верно. Средство редактирования кода никак не влияет на его выполнение. У вас что в моноДевелоп, что в студии, что в райдере будет при сборке вызываться один и тот же компилятор.
aquamakc
Джозеф Хокинг в «Unity в действии. Мультиплатформенная разработка на C#» пишет, что влияет.
KumoKairo
Можете привести конкретную цитату? Скорее всего либо автор имел в виду что-то другое, либо есть вероятность неверного перевода.
aquamakc
Прямо сейчас не могу. Книга в бумаге лежит дома. Но, если думать логически. Mono имеет свой компилятор, отличный от ортодоксального MS. Мы все знаем, что Mono — кроссплатформенный. Классический же .Net Framework — Windows Only JIT или Roslyn.
Исходя из этого приходим к логичному умозаключению, что код написанный на Mono — кроссплатформенный, в MS VS — нет.
Про Net.Core и его связку с Unity ничего не могу сказать.
Razaz
Вы путаете рантайм и редактор кода. Код можно написать в VS а выполнить на разных рантаймах. PS и компильнуть разными компиляторами ;)
KumoKairo
Если рассматривать контекст Unity, то Visual Studio работает с ней как простой редактор кода, ничем не отличный от обычного блокнота или Notepad++. После сохранения скрипта в Visual Studio нужно переключиться на окно с Unity чтобы она собрала (с помощью внутреннего компилятора) основную текущую сборку (Assembly-CSharp). Рантайм у Unity и в редакторе и на таргет девайсах тоже свой. Причём на iOS там вообще не Mono, а IL2CPP. То есть «кроспилированный» код из IL в С++. Если игровой код Unity компилировать прям в Visual Studio — результат сам по себе просто провалится в бездну, он нигде не используется. Есть конечно возможность использовать готовые .dll файлы, собранные специально под текущий .NET Profile в Unity (стабильный в юньке до сих пор .NET 3.5), но при компиляции на тагрет девайсы с IL2CPP рантаймом, они всё равно перегоняются в С++.
Если резюмировать — неважно в чём вы пишете код для Unity, т.к. движок сам занимается конечной сборкой кода и настройкой рантайма на конечном устройстве.
aquamakc
Хорошо, если так. Попаду домой, уточню этот момент в книге.
avvor
Я вот сегодня столкнулся с тем, что в VisualStudio for Mac при работе с Unity в Debug на брекпоинте не показывается состояние объекта, потом эту ветку комментариев увидел, думаю дай-ка попробую MonoDevelop, переключился обратно на MonoDevelop и там Debug работает как надо.
KumoKairo
Дебаггер это отдельная история. На данный момент для Visual Studio на Windows устанавливается специальный плагин, который подцепляется к юньковскому рантайму. Visual Studio for Mac это по сути Xamarin Studio, то есть с Win версией VS общего ничего не имеет. Для всех редакторов (VS Code например) необходима такая надстройка, которая подружит текстовый редактор с Unity. Для «встроенного» в Unity MonoDevelop она интегрирована по умолчанию, а для Visuai Studio (Windows) и VS Code (Windows + Mac) она устанавливается отдельно. Не часто дебажу в Unity с Мака, но по-моему дебаггер пока можно подключать только во встроенном Mono Develop, либо в VS Code.
aquamakc
Вам я по этому вопросу в диалог ответил, но также должен публично заявить следующее:
Добрался до книги.
Раздел 1.3.2 стр. 34-35.
Автор предупреждает, что могут возникнуть трудности при кроссплатформенной разработке, т.к. MonoDevelop запускается на любой платформе, а VS — только на Windows. Из-за этого могут быть проблемы в команде разработчиков, работающих под разными платформами.
В общем смысле и MonoDevelop, и VS выступают только в качестве продвинутого текстового редактора для набора кода.
На выполнение кода в среде Unity выбранная IDE не влияет.
Leopotam
Разные компиляторы генерят разный MSIL для одного и того же кода. Например, абсолютно по-разному генерируется код coroutines штатным моно и внешним / системным. Проверить можно через ilspy / reflector — в случае внешнего компилятора получается ровный читабельный код, в случае штатного — адская каша. Есть ли различие? Есть (по крайней мере было во времена AOT, когда еще il2cpp не было на горизонте) — код просто переставал работать на реальных ios-девайсах после трансляции через AOT в некоторых случаях, например, с использованием Func и хитрых конструкций linq. Есть такая библиотечка websocket-sharp — вот она как раз умирала на коннекте / дисконнекте на ровном месте, если ее собирать внешним более свежим компилятором. В случае подкладывания в виде исходников в проект юнити — все собиралось как нужно.