Как создать внутриигровое меню в Unity

Разработчик детского мобильного паззла Fold the Adventure Алексей Галкин написал для ЦП колонку о том, на что следует обратить внимание при разработке мобильной игры на платформе Unity: как выбрать правильные ассеты из Asset Store, в каком сервисе хранить данные о прогрессе пользователей и где взять звуки для игры.

В закладки

Начало

Чтобы сделать хорошую игру, нужна хорошая идея. Но даже имея идею, создать на её основе достойную игру совсем непросто. Помимо банальной удачи, существует огромное множество вещей, с которыми приходится иметь дело. Бесконечное число решений необходимо принять в весьма скромное время. Ведь время - это деньги, а бюджет проекта имеет тенденцию исчезать до того, как сделано хоть что-то достойное демонстрации (не говоря уже о выпуске).

Эта история о том, как наша небольшая инди-команда создавала игру Fold the Adventure («Сложи приключение») на основе оригинальной идеи. Поскольку игра выпущена, мы можем перевести дух и окинуть взглядом три месяца, потраченные на разработку. Несмотря на наличие многолетнего опыта в игровой индустрии, создание Fold the Adventure заставило нас изрядно попотеть ввиду непредсказуемых поворотов событий и весьма ограниченных ресурсов. Добро пожаловать в наше приключение!

Выбор движка: Unity

Сказать по правде, движок нам выбирать не пришлось. Мы сразу взяли Unity и не пожалели об этом. Нашей первостепенной задачей было создание сравнительно небольшой игры и запуск её на максимальном количестве платформ. При этом хотелось избежать возни с программированием на Objective C и Java. С Unity нам это удалось. И хотя всё было не так просто и гладко, как предполагалось, движком мы остались довольны.

По нашему мнению, Unity - это лучший игровой движок для инди-разработки в настоящий момент. Его программная архитектура хорошо продумана, редактор сделан добротно и становится лучше с каждой версией. Начать пользоваться Unity легко, но опытным разработчикам он может показаться поначалу контринтуитивным. Тем не менее, и новички, и профессионалы, скорее всего, столкнутся с одними и теми же подводными камнями.

• Необходимо с самого начала потратить время на изучение базовой архитектуры Unity, включая игровые объекты, скриптуемые объекты, сцены, префабы, ассеты, методы-события и порядок их вызова, сопрограммы, измерение времени, обработку ввода, сериализацию. Unity может показаться лёгким в использовании движком, но без понимания его основ можно провести бесконечные часы за отладкой и рефакторингом.
• С самого начала сформулируйте правила структуризации, а также именования ассетов и игровых объектов. Даже небольшая игра имеет тенденцию превращаться в хаос без должной организации. Существует много статей, посвящённых данному вопросу. Можно также ориентироваться на проекты, публикуемые разработчиками в Unity Assets Store.
• Программируйте как можно меньше. Вместо этого активно используйте WYSIWYG (What You See Is What You Get - свойство прикладных программ, в которых содержание отображается в процессе редактирования и выглядит максимально близко похожим на конечную продукцию - ред.) возможности редактора Unity. Благодаря лёгкой расширяемости, редактор Unity позволяет превратить разрабатываемую игру в удобный конструктор, которым смогут пользоваться даже те, кто не умеет программировать. А это существенно упрощает и ускоряет создание игрового контента.
• Избегайте использования привычных практик, которые плохо сочетаются с идеологией Unity. Какой бы заманчивой не была возможность размещения всех объектов игры в рамках одной сцены или сохранение параметров игровой механики в XML-файлах, подобный подход существенно осложнит жизнь на более поздних этапах разработки.
• Будьте аккуратны и внимательны при использовании систем управления версиями. Unity имеет тенденцию непредсказуемо менять файлы. Например, внесение изменений в префаб влечёт за собой модификацию всех файлов сцен, в которых он используется, но только после их последующего сохранения. Всегда используйте force text в качестве режима сериализации ассетов и внимательно следите за файлами, которые заливаете на сервер, чтобы не уничтожить результат работы коллег.
• Тестируйте игру на максимально возможном количестве платформ. При этом не забывайте, что настройки можно определить для каждой из платформ в отдельности. Без подобного тестирования, вы, как и мы, можете столкнуться с тем, что ваша игра ведёт себя по-разному в web player-е под Windows и OS X.

Ассеты: создавать или покупать

Если у вас небольшая команда при сильно ограниченных времени и бюджете, то создать большое количество качественных игровых ассетов с нуля практически невозможно. Приходится усмирять грандиозные амбиции и минимизировать количество необходимого. Но даже при условии минимизации, нужно оставить что-то, на что игроку было бы приятно посмотреть.

Если ассеты для игры могут быть сделаны силами команды - одной проблемой меньше (cкорее всего). Но есть ещё фаза прототипирования, а для неё также нужны ассеты, которые с большой долей вероятности будут выброшены. Поэтому практически каждой команде требуются ассеты, которые она не может или не хочет делать. Вопрос в том, где их взять.

Первым и самым очевидным ответом для нас, как для Unity разработчиков, был Unity Assets Store . Какой бы заманчивой ни казалась эта возможность, она влечёт за собой и ряд сложностей:

• Ассеты в Unity Assets Store доступны всем без исключения. Однако никто не хочет, чтобы их игра была похожа на другие. По крайней мере, мы этого очень не хотели.
• Практически невозможно купить один пак ассетов, который бы удовлетворил все нужды проекта, и возникает проблема стилистической совместимости. Для Fold the Adventure мы купили несколько паков, из которых использовали меньше половины.
• Несмотря на то, что общее количество ассетов в Unity Assets Store довольно велико, найти среди них что-то подходящее для конкретных нужд бывает весьма непросто. При этом качество зачастую оставляет желать лучшего. Мы потратили часы на поиски, при этом не всегда имея возможность оценить качество пака без его покупки.

Вторым вариантом был аутсорсинг ассетов. Безусловно, этот путь отнимает больше времени и денег, чем просто покупка чего-то из Unity Assets Store. Однако, при удачном раскладе, получаемые ассеты уникальны и более качественны.

Существовала также возможность покупки ассетов из источников помимо Unity Assets Store. Однако здесь возникала проблема совместимости с Unity, и мы решили воздержаться от таких экспериментов.

Когда мы принимали решение о том, какие ассеты делать самостоятельно, а какие нет, мы начали с их категоризации. Как оказалось, ассетов, которые были уникальны для нашей игры и выделяли её среди прочих, было сравнительно немного. Их мы решили сделать своими силами, прибегая к помощи аутсорса там, где это было возможно. Остальное было куплено в Unity Assets Store.

Вот несколько простых правил, к которым мы пришли в ходе поиска и покупки ассетов в Unity Assets Store

• Чтобы избежать стилистических расхождений, желательно покупать ассеты одного типа у одного автора. Это не мешает купить модели у одной студии, а партиклы у другой, но при этом нужно следить за совместимостью стилей.
• Избегайте использования ассетов в том виде, в котором они были куплены. Достаточно внести небольшие изменения (например, немного перерисовать текстуры, реструкурировать партиклы) или использовать ассеты нестандартным образом.
• Если вы планируете выпуск игры на мобильных платформах, убедитесь, что покупаемые ассеты оптимизированы под них.

Музыка и звуки заслуживают отдельного внимания. Они редко создаются инди-командой самостоятельно (если у вас есть композитор, то вам либо очень повезло, либо вы уже не инди). К счастью, существует большое количество сервисов, поставляющих royalty-free музыку и звуки, включая Unity Assets Store. И это совсем недорого.

Недостаточно просто купить музыку и звуки. Необходимо сделать так, чтобы они правильно звучали в игре и не раздражали слух. Если вы уверены в своих силах, то можно попробовать сделать это самостоятельно. Мы же обратились за помощью к студии, которая специализируется на озвучке. Полученный результат был существенно лучше того, что мы могли сделать сами, и стоил своих денег.

Где хранить данные: Parse

Даже если вы, как и мы, создаёте однопользовательскую игру, вам всё равно потребуется место для хранения данных о текущем прогрессе игрока, статистике его действий, сделанных покупках и прочей информации. Самым простым решением будет использовать для этого класс Unity PlayerPrefs . Однако он сохраняет данные локально и, совершенно очевидно, не подходит для таких деликатных вещей, как внутриигровые покупки.

В поисках лучшего решения мы обнаружили Parse . Parse - это кросс-платформенный сервис BaaS (Backend as a Service - платформа типа «бэкенд как сервис», предоставляет облачную серверную инфраструктуру для всех типов приложений - ред.), который позволяет приложению сохранять данные в облаке, поддерживает авторизацию пользователей, серверные функции, push-оповещения и аналитику. Это не исчерпывающий список функциональности, но он даёт общее представление о том, что есть Parse.

Одной из причин, по которым мы выбрали Parsе, была его интеграция с Facebook (первая версия Fold the Adventure создавалась именно для Facebook). И, несмотря на то, что позднее фокус разработки был смещён на мобильные платформы, мы продолжили использовать Parse.

Ещё одной приятной особенностью Parse является его ценовая политика. Поначалу она кажется немного странной, но, после размышлений и расчётов, оказывается более чем удачной. По существу, вы ограничены количеством запросов в секунду. Хорошая новость в том, что 30 запросов в секунду даются бесплатно. Может показаться, что это совсем немного, но на деле этого достаточно для поддержки тысяч пользователей. При условии, что вы используете эти запросы разумно.

В Parse вы делаете всё через запросы. Для получения и изменения полей данных, создания отношения между таблицами, формирования выборки - для всего нужен запрос. На первый взгляд, количество запросов должно быть довольно большим, но, на деле, большую часть элементарных операций можно объединить в один запрос с помощью метода ParseObject.SaveAllAsync. Кроме того, Parse выбросит исключение, если предел запросов в секунду превышен. Но ничего не мешает вам подождать некоторое время и выполнить запрос повторно. И хотя игра в таком случае может показаться пользователю «подвисшей», эта проблема легко обходится с помощью внесения небольших изменений в пользовательский интерфейс и логику сохранения и чтения данных.

Единственное, для чего Parse не следует использовать, так это для создания игрового сервера. Даже если вы разрабатываете пошаговую игру, предназначение Parse в корне отлично. Существуют другие решения, которые существенно лучше подходят для этих целей.

Использование Parse в рамках Unity не сопряжено с особыми трудностями и хорошо документировано. По сути, вам необходимо скачать Parse SDK, настроить вашу игру на сервере Parse и в проекте Unity, а также немного попрограммировать. Один очевидный нюанс: вы не сможете использовать Parse, если устройство, на которое установлена ваша игра, не имеет доступа к интернету.

Если есть необходимость поддерживать офлайн-режим и обновлять данные в Parse при наличии сетевого соединения, то вам придётся написать для этого небольшую отдельную систему. Мы использовали для этого класс PlayerPrefs. Система сохраняет данные локально и заливает их в Parse, как только обнаруживает наличие подключения к интернету.

Стационарные платформы против мобильных: компромиссы

Несмотря на постепенное сближение в течение последних лет, стационарные и мобильные платформы по-прежнему сильно отличаются друг от друга. Это становится очевидным при попытке заставить «красивые» шейдеры работать приемлемо (не говоря уже о том, чтобы заставить их работать быстро) на всех устройствах, на которых предполагается запуск игры. Unity существенно облегчает этот процесс, но, к сожалению, не решает всех проблем.

Существует огромное количество статей, посвящённых оптимизации Unity-игр под мобильные платформы, так что здесь на эту тему будет сказано немного.

• Если вы планируете запуск на мобильных платформах и используете тени, то ограничьтесь режимом forward lighting. Несмотря на запекание освещения и сокращения числа объектов, отбрасывающих тени, мы не смогли добиться приемлемой производительности в режиме deferred lighting. Возможно, мы недостаточно старались, но форумы Unity, по большей части, солидарны с нами в этом вопросе.
• Минимизируйте количество draw call-ов. Большое количество полигонов в моделях не скажется так сильно на производительности, как дополнительные draw call-ы. Мы планировали большую оптимизацию, направленную на сокращение количества draw call-ов, чтобы лучше поддерживать старые модели мобильных устройств, но, к сожалению, не смогли сделать её в отведённые жёсткие сроки.
• Не злоупотребляйте текстурными выборками в шейдерах. Это может привести к существенному падению производительности. В нашей игре мы были вынуждены использовать несколько специальных шейдеров вместо одного универсального - именно по этой причине.

Помимо различий в производительности и аппаратных ограничений, существует ещё одно важное отличие между стационарными и мобильными платформами. И это отличие - режим ввода. Игра, созданная для управления с помощью клавиатуры и мыши, плохо переносится на мультитач и акселерометр. Мы убедились в этом на своём горьком опыте. Прежде всего, в Unity разделена обработка мыши и мультитача. А потому было необходимо создать систему, унифицирующую этот аспект. Для этих целей мы использовали систему ввода из состава NGUI , которая, после небольших доработок, показала себя весьма хорошо. Она также позволила нам решить проблему распределения ввода между пользовательским интерфейсом и игровым управлением, которая доставляла нам некоторые неприятности на тот момент.

Пользовательский интерфейс в целом потребовал ряда модификаций для корректной поддержки мобильных устройств. Например, вместо прокручивания колёсика мыши и удерживания кнопок пришлось ввести мультитач-жесты. Некоторые из модификаций можно было потенциально упросить с помощью готовых решений из Unity Assets Store. Но в нашем случае это был простой pinch, а потому мы решили написать его за час с нуля, вместо того, чтобы тратить дни на подключение и отладку системы, которая «делает всё и даже больше».

Наибольшее количество проблем вызвало внутриигровое управление. Мы начали с традиционного набора ASWD + мышь для управления персонажем и камерой, планируя использовать экранный джойстик на мобильных устройствах. Но всё получилось не совсем так, как мы ожидали: игра стала практически неуправляемой. Нам пришлось срочно менять внутриигровое управление, при этом внося изменения даже в игровую механику. Методом проб и ошибок мы остановились на point-n-click управлении, которое на мобильных устройствах воспринимается интуитивно.

Локализация: чем проще, тем лучше

Если вы хотите добиться успеха игры в мировом масштабе, то, вне всяких сомнений, её необходимо локализовать. А локализация - это ещё одна часть разработки, которую инди-команда практически никогда не может сделать самостоятельно. Это означает только одно: за локализацию придётся заплатить.

Локализовывать необходимо всё, что имеет отношение к человеческому языку. То есть тексты, речь, надписи на текстурах - всё это должно быть локализовано. Такой процесс очень быстро может стать весьма трудоёмким и дорогим. Поэтому крайне важно свести количество локализуемого контента к минимуму.

Надписей на текстурах лучше избегать, и использовать, например, текстовые поля NGUI. Если в игре необходима речь, то, скорее всего, потребуются и субтитры, поскольку локализация речи не только дорогое удовольствие, но ещё и требовательное с точки зрения места, занимаемого игрой.

Но минимизация локализуемого контента - это только начало. Следующий этап - подготовка самой игры к локализации. Плохая новость состоит в том, что Unity (на момент написания данной статьи) не имеет встроенных механизмов для этих целей. И хотя существует целый ряд специализированных решений в Unity Assets Store (например, l2 Localization), мы решили использовать систему локализации, идущую в составе NGUI.

Система локализации NGUI проста и понятна в использовании. Она построена на основе одного CSV-файла, содержащего колонку для каждого языка. Наличие такого файла очень удобно для отправки строк на перевод (для этого существует большое количество специализированных сервисов) и последующей вставки переведённой версии.

Написать

Слово предупреждения перед началом — данный текст не является самым исчерпывающим и всеохватывающим руководством по написанию скриптов в Unity. Данное руководство предназначено для человека, который хочет использовать Unity и который не имеет никаких знаний о каком-либо виде программирования. Используйте информацию отсюда, чтобы получить начальный опыт и отбросить некоторые опасения при добавлении скриптов к своим игровым объектам.

Написание скриптов, или программирование вообще, изучается на самых первых этапах, особенно полными новичками. Скорее всего, вам необходимо преодолеть некоторые неоправданные страхи относительно того, насколько удивительно трудным кажется написание скриптов. Основы использования скриптов Unity на самом деле не так и сложны. Мы делаем некоторые каждодневные вещи, которые похожи на последовательные процедуры в скриптах.

Существует множество книг, руководств и уроков по программированию, которые могут показать вам, как на самом деле разобраться в деталях. Также имеется множество видео-уроков для изучения Unity, и они почти все обучают основам написания скриптов. После прохождения всех этапов в данном руководстве, вы почувствуете себя более комфортнее, изучая подобные уроки. По крайней мере, у вас появится основное понимание того, что говорят другие авторы.

Я сам новичок в Unity. Я также знаю о том, что значит, когда нравится изучать и другие языки программирования. Я должен был пройти через беспорядок, как и вы. Я надеюсь, что данное руководство прояснит основы написания скриптов, которые я изучил, и я надеюсь, что обучение через «призму новичка» просветит вас тоже.

Уроки с первого по седьмой для полных новичков, для тех, кто не имеет абсолютно никакого представления о программировании вообще. Я на самом деле рассказываю о низком уровне и основах. Я просто стараюсь объяснить основные понятия на примере каждодневных жизненных ситуаций. Я не хочу, чтобы вы всегда имели расплывчатое пятно в своем сознании, которое бы заставило вас сдаться.

Уроки восьмой и выше фактически начинают рассматривать применение концепции написания скриптов в Unity.

Кажется, что большая часть начинающих может довольно легко узнать о том, как пользоваться Unity, это в первую очередь касается работы скриптов, которых они так боятся. Данное руководство для новичков предполагает, что вы на собственном опыте изучили из других источников, как в общих формах обращаться с редактором Unity, даже просто работая с файлами ресурсов. Это руководство только об изучении основ по работе со скриптами.

Редактор Unity

Это иллюстрация проекта Bootcamp Demo в редакторе Unity. Вы должны быть знакомы с расположением окон в редакторе Unity из просмотра других доступных уроков. Те уроки, которые размещены здесь, не о расположении окон или навигации в редакторе. Данные уроки только о программировании в Unity с помощью скриптов (версия JavaScript для Unity).

Редактор скриптов

Это Unitron, редактор скриптов Unity для Mac, который я использую. Он будет выглядеть по-другому в Windows, но они оба служат одной и той же цели.

Если вы абсолютный новичок в скриптах Unity и не имеете никакого представления даже о том, что означает слово «скрипт», то данные уроки — для вас. Если один только взгляд на изображение редактора пугает вас, то данные уроки — для вас. Если вы художник, желающий использовать Unity для разработки игр, и едва знаете как мыслить логически, тогда данные уроки — для вас.

Что вы изучите

Вы узнаете, что уже знакомы со скриптами, даже если вы и не догадывались об этом. Поэтому я собираюсь описать самые основы в нескольких первых уроках, так что вы сможете увидеть то, что программирование в Unity — это всего лишь еще один способ проделывания тех вещей, которые вы делали ранее, даже не подозревая об этом.

Ваша игра наполнена глупыми объектами

Вы установили все свои игровые ресурсы. У вас есть сцена, отображающая то, что содержат игровые объекты. Вы хотите, чтобы эти игровые объекты двигались вокруг, слушали, разговаривали, поднимали другие объекты, пристреливали «плохих парней» или делали все то, что вы можете пожелать, чтобы они делали. Тем не менее, все эти игровые объекты по своей природе глупы, они не знают, как выполнить любые из этих взаимодействий, которые вы хотите, чтобы они выполнили.

Это то самое место, где в дело вступают скрипты. «Но, но, но я не знаю как программировать» — скажете вы. Хорошо, на самом деле вы правы. Вы делаете это каждый день, просто вы не называете это программированием или написанием скриптов. Вы ведь живете каждый день бесцельно натыкаясь на вещи без каких-либо указаний? Вы, наверное, взаимодействуете вообще с другими людьми, или даже с домашними животными? Разговариваете? Пользуетесь туалетом или ванной-комнатой?

Шаг первый

Давайте притворимся:

Вообразите, что сидите на диване, разговаривая с другом.

Шаг второй

Потом звонит телефон. Вы говорите: «Извините, позвольте мне ответить на звонок».

Шаг третий

Вы заканчиваете телефонный разговор и затем продолжаете разговор со своим другом.

Теперь подумайте

Происходило ли это с вами когда-нибудь в реальной жизни, или что-то наподобие этого? Это было сложно проделать? Держу пари, что вы даже не задумывались обо всем процессе принятия телефонного звонка в середине разговора. Вы просто сделали это. Ну, и что вы думаете? Все это — то же самое, что делают скрипты в игровых объектах.

Давайте разберем немного по пунктам:

Шаг первый

Так случилось, что вы — объект, персонаж, игровой объект в игре, именуемой «жизнь». Вы запускали скрипт «разговор» в то время, когда телефон прервал ваш скрипт «разговор» .

Шаг второй

Вами была запущена на выполнение другая функция — разговор по телефону. Следовательно сейчас вы выполняете скрипт «разговор по телефону» .

Шаг третий

Когда вы закончили с телефоном, вы возвратились к скрипту «разговор» со своим другом.

Примечание:

Обратите внимание на слова, выделенные синим шрифтом. Они наиболее близки к точным словам, которые вы будете использовать для написания скриптов. Такие слова вы уже знаете, понимаете и используете сами.

Скриптофобия

Теперь я спрашиваю вас, настолько ли трудным был процесс? Беспокоил ли он вас, потому что вы не верили в то, что сможете сделать все это? Заходили ли вы на форум, чтобы спросить о том, как вести разговор, а после разговаривали по телефону в середине всего этого?

Скриптофобия: страх не позволяющий писать инструкции (то, что я делал).

У вас есть такие страхи, которые не дают вам написать несколько инструкций в последовательном ключе?

Дело в том, что вы занимаетесь написанием скриптов всю свою жизнь, просто вы никогда не должны были записывать то, что вы делаете на листке бумаги, перед тем как, что-то сделать. Вы бы смогли, если бы действительно этого хотели, но это занимает слишком много времени и не является необходимым. Но вы, на самом деле, знаете, как это сделать. Ну, хорошо, и что вы об этом думаете? Вы должны начать записывать действия, не для себя, а для мира, который создаете.

«Комплекс Бога»

Создатель миров.

У вас есть Unity, потому что вы хотели создать игру или что-нибудь интерактивное. Хорошо, вы чувствуете, что игра наполнена глупыми игровыми объектами и теперь вы должны «поиграть в Бога». Вы создали их, теперь вы должны обучить их всему, что им нужно знать для жизни в этом воображаемом мире. Та часть, где вы должны написать инструкции так, чтобы ваши игровые объекты могли быть умными, как и вы.

Станьте учителем

То, что вы сейчас должны делать — это играть роль учителя. Вы должны обучить каждый игровой объект или префаб индивидуально, потому что каждый из них имеет различные вещи, которые им нужно узнать. К счастью, каждая вещь, которую они должны знать, находится в справочнике по скриптам , который поставляется вместе с Unity. Все, что вам нужно будет сделать — это записать последовательные инструкции для своих игровых объектов, которые будут их выполнять.

Надлежащее поведение

Какой же это умелый способ описать то, что вы собираетесь сделать вашим игровым объектам. Вы зададите им поведения. Так же, как родитель учит своего ребенка, как себя вести. Мало того, что Unity достаточно хорош в плане предоставления большого приятного списка всех действий, которые могут проделывать игровые объекты, но также и в том, что есть разъяснение в справочнике по скриптам , каким образом использовать эти действия.

Это означает, что вы можете выбрать мышью из списка поведений любое действие, которое хотите и которое игровой объект должен будет сделать. Unity проделал сложную работу по программированию всех этих поведений, так что все, что вам нужно сделать — это решить, что вы хотите использовать, после чего подключить поведения в инструкции, которые описываете.

Как создать игру в Unity

Казуальные игры в жанре match 3 (три в ряд) - одни из самых популярных на рынке. Многие играют в Candy Crush, Bejeweled и прочие. У этих игр простая цель: перемещать мозаичные элементы до тех пор, пока три одинаковых элемента не окажутся рядом. Когда это происходит, совпавшие элементы исчезают, а на их месте появляются другие. Игрок при этом набирает баллы.

В этом руководстве будут освещаться следующее:

• Создание доски, заполненной мозаичными элементами
• Выбор и отмена выбора мозаичных элементов
• Идентификация соседних элементов с помощью raycasts
• Замена элементов
• Поиск совпадающих трех и более элементов с помощью raycasts
• Заполнение пустых элементов
• Ведение счета и подсчет движений

Примечание . Предполагается, что вы уже знаете, как пользоваться редактором Unity, как редактировать код, и что у вас есть базовые знания по части C#.

В дальнейшем вы сможете добавлять временные режимы, различные уровни с досками разных размеров, бонусные очки за комбинации, или же анимационные эффекты.

Share this article:

Related Articles

Наткнулся на англоязычную статью 2012-го года, от немецкого автора, фрилансера-геймдевелопера, разработчика инструментов для Юнити — Herman Tulleken. В статье, сведены 50 советов по работе в Юнити. Советы основаны на опыте работы автора в проектах, с командами от 3 до 20 человек. Автор предупреждает, что не все из них, могут быть применены в каждом проекте; многие советы — дело вкуса. От себя добавлю, что Юнити эти 3 года не стоял на месте, и возможно некоторые советы, могут быть уже не актуальны. Перевода я не нашел. Подумал, а почему бы мне ее не перевести ее, для своего сайта.

Сразу скажу, что с английским я не дружу совершенно, и перевод местами будет корявым. Да и вообще, это мой первый опыт такого большого перевода. Итак, поехали.

Процесс

1. Избегайте разветвленных ассетов. Всегда, должна быть только одна версия, любого ассета. Если вам абсолютно необходимо ответвить новую версию префаба, сцены или сетки, следуйте процессу, это сделает ясным, какая версия является правильной. «Неправильная» версия должна иметь броское имя, например, использовать двойное подчеркивание префикс: __MainScene_Backup . Ветвление префабов требует определенного процесса, чтобы сделать его безопасным (см в разделе Префабы).

2. Каждый член команды, должен иметь второй экземпляр проекта для тестирования, если вы используете систему контроля версий. Все изменения должны делаться, и тестироваться в нём, и затем вносится в «чистовую» версию. Никто не должен делать какие-либо изменения в их «чистовых» экземплярах. Это особенно полезно, чтобы отловить недостающие ассеты.

3. Рассмотрите возможность использования внешних инструментов для редактирования уровня. Юнити не лучший инструмент для этого. Например, мы использовали TuDee для создания уровней на основе 3D-тайлов, где есть такие полезные функции, как: привязка к сетке, 2D вид, быстрый выбор тайлов. Простое инстанцирование префабов из XML-файлов.

4. Рассмотрите сохранение уровней в XML, а не в сценах. Это прекрасный метод:

• это избавляет от необходимости настраивать каждую сцену;
• это делает загрузку намного быстрее (если большинство объектов являются общими для всех сцен).
• это делает легче объединение сцен.
• это делает более легким отслеживание данных уровня.

Вы по-прежнему сможете использовать Unity в качестве редактора уровня (хотя и не должны). Вам нужно будет написать код для сериализации и десериализации данных, для загрузки уровня в редакторе и во время выполнения, а также для сохранения уровня в редакторе. Вам также может понадобиться, имитировать ID систему Unity, для поддержания ссылок между объектами.

5. Рассмотрите написание пользовательского инспектора. Написать пользовательский инспектор довольно просто, но система Unity имеет много недостатков:

• Он не позволяет воспользоваться преимуществами наследования.
• Он не позволяет определить компоненты инспектора на уровне поля, только на уровне класса. Например, если каждый игровой объект, имеет поле типа SomeCoolType , который вы хотите отобразить в инспекторе иначе, вы должны написать инспектор для каждого класса.

Вы можете решить эти вопросы, повторной реализацией системы инспекторов. Используя несколько приемов рефлексии, это не так сложно, как кажется. Детали, представлены в конце статьи.

Организация сцены

6. Используйте именованные пустые объекты, как папки. Тщательно организовывайте свои сцены, чтоб облегчить поиск объектов в них.

7. Помещайте при редактировании свои префабы и папки (пустышки) в нулевые координаты (0, 0, 0). Если префаб/пустышка редактируется не для позиционирования, он должен быть в нуле. Таким образом, уменьшается вероятность возникновения проблем с локальными и мировыми системами координат, и код как правило проще.

8. Минимизируйте использование смещений для компонентов GUI. Смещения должны использоваться для компоновки компонентов, только относительно их родительского контейнера; они не должны полагаться на позиционирование своих прародителей. Смещения не должны отменять друг друга, чтобы правильно отображаться. Это в основном для предотвращения такого рода вещей:

Родительский контейнер произвольно размещен в (100, -50). Ребенок, предназначенный для позиционирования в точке (10, 10), помещен в (90, 60) [относительно родительского].

Эта ошибка распространена, когда контейнер невидим, или не имеет визуального представления вообще.

9. Размещайте вашу землю на y=0. Это облегчает задачу размещение объектов на земле.

10. Делайте игру, готовую к запуску в каждой сцене. Это значительно сокращает этап тестирования. Для этого нужно сделать 2 вещи:

Во-первых, предоставить в сцене все данные, требующиеся от предшествующих сцен, если они не доступны.

Во-вторых, создайте объекты, которые должны сохраняться между загрузками сцены, следующим образом:

myObject = FindMyObjectInScene();

if (myObjet == null)
{
myObject = SpawnMyObject();
}

Арт

11. Размещайте пивот поинты (точки вращения) в основании объектов и персонажей, а не в центре. Это упрощает установку объектов, точно на поверхность. Так же это позволяет работать с 3d, как с 2d в игровой логике, AI, и даже в физике, когда это необходимо.

12. Ориентируйте все ваши объекты, включая персонажей, «лицом» вдоль одной и той же оси (положительное или отрицательное направление оси Z). Многие алгоритмы упрощаются, когда все объекты лицом направлены в одном направлении. Тут имеются ввиду, локальные оси самого объекта, а не мировые.

13. Позаботьтесь о правильном масштабе своих ассетов, до импорта в движок. При масштабе (1, 1, 1) они должны иметь задуманные размеры. Для сравнения, можно использовать ссылку на объект куба в юнити, находящийся в стандартных ассетах. Выберите подходящее соотношения к мировым единицам, и придерживайтесь его.

14. Чтобы, было легче размещать и ориентировать GUI и партиклы, используйте two-poly plane (плоскость из двух треугольников). Сориентируйте плоскость лицом по оси Z (см. пункт 12) и вкладывайте в нее GUI или партиклы.

15. Создайте и применяйте тестовые арты:

• Меченые квадраты для скайбоксов.
• Текстуру с сеткой.
• Различные «плоские» цвета для шейдерного тестирования: белый; черный; 50% серого; красный; зеленый; синий; пурпурный; желтый; голубой.
• Градиенты для шейдерного тестирования: от черного к белом; от красного к зеленому; от красного к синему; от зеленого к синему.
• Текстуру «чекер» (черно-белые квадраты, по типу шахматной доски).
• Сглаженные и жесткие карты нормалей.
• Готовое и настроенное освещение, для быстрого создания тестовых сцен.

Префабы

16. Используйте префабы абсолютно для всего. Единственные объекты, которые не должны быть префабом, это папки. Даже уникальные объекты, которые будут использованы только раз, должны быть префабом. Это облегчает внесение изменений в сцены, не трогая сами сцены. (Дополнительным преимуществом является то, что это делает построение атласа спрайтов надежнее, при использовании EZGUI).

17. Используйте отдельные префабы для специализации, не специализируйте экземпляры. Например, если у вас 2 типа врагов, отличающихся друг от друга только свойствами, сделайте отдельный префаб для этих свойств и свяжите их. Это позволит:

• вносить изменения для каждого типа в одном месте;
• вносить изменения без изменения сцены.

Если у вас слишком много типов врагов, экземпляры все равно не нужно делать в редакторе. Как вариант, можно сделать это процедурно, или используя файл/префаб для всех врагов. А конкретный тип определять через выпадающее меню, или алгоритм на основе вражеской позиции, или прогресса игрока.

18. Связывайте префабы с префабами; не связывайте экземпляры с экземплярами. Ссылки на префаб поддерживаются, при помещении префаба в сцене; ссылки на экземпляры нет. Ссылки на префабы, когда это возможно, упрощают настройку сцены, и уменьшают необходимость ее изменения.

19. Насколько это, возможно, устанавливайте связи между экземплярами автоматически. Если вам необходимо установить связь между экземплярами, делайте это программно (в коде). Например, префаб игрока может зарегистрировать себя в GameManager , когда он стартует. Или GameManager может сам найти экземпляр префаба игрока, когда он стартует.

Не ставьте меши, в корень префаба, если собираетесь добавлять другие скрипты. Когда вы делаете префаб из меша, поместите его в пустой объект, сделав, таким образом, корнем пустышку, и уже на нее вешайте скрипты. Так намного проще заменить меш другим мешем, не потеряв каких-то значений, которые вы установили в инспекторе.

Используйте связанные префабы, как альтернативу вложенных префабам. Юнити не поддерживает вложенные префабы, а существующие сторонние решения, могут быть опасны при работе в команде, потому что отношения между вложенными префабами, не являются очевидными.

20. Используйте безопасный процесс ветвления префабов. Объясним на примере префаба Player .

Делать опасные изменения в префабе, нужно следующим образом:

• Скопировать префаб Player .
• Переименовать дубликат на __Player_Backup .
• Сделайте изменения в префабе Player .
• Если все работает, удалить __Player_Backup .

Не называйте дубликат Player_New , и не вносите в него изменения!

Некоторые ситуации более сложные. Например, некоторое изменение может включать двух человек, и следуя вышеописанному процессу, можно нарушить рабочую сцену у всех, пока второй разработчик не закончит. Если это не займет много времени, можно действовать, как описано выше. В противном случае, можно сделать следующим образом:

Разработчик 1:

• Скопировать префаб Player .
• Переименовать его в __Player_WithNewFeature или __Player_ForDev .
• Сделать изменения в дубликате, закоммитить / передать 2-му разработчику.

Разработчик 2:

• Внести изменения в новый префаб.
• Скопировать префаб Player , и назвать его __Player_Backup .
• Перетащить экземпляр __Player_WithNewFeature на сцену.
• Перетащите экземпляр на оригинальный префаб Player .
• Если все работает, удалить __Player_Backup и __Player_WithNewFeature .

Расширения и MonoBehaviourBase

21. Расширьте MonoBehaviour своим поведением, и получайте все ваши компоненты от него. Это позволяет реализовать некоторую общую функциональность, такие как типобезопасного вызова (Invoke), и более сложные вызовы (например, случайный, и т.д.).

22. Определите безопасные методы для методов Invoke, StartCoroutine и Instantiate. Определите делегат Task, и используйте его, для определения методов, которые не зависят от имени. Например:

public void Invoke(Task task, float time)
{
Invoke(task.Method.Name, time);
}

23. Используйте расширения для работы с компонентами, которые наследуют интерфейс. Иногда это удобно, для получения компонентов, реализующих определенный интерфейс, или для поиска объектов с такими компонентами.

Реализации ниже используют TypeOf , вместо обобщенных версий этих функций. Обобщенные версии не работают с интерфейсами. Методы ниже, обертывают TypeOf-версии в обобщенные методы.

//Defined in the common base class for all mono behaviours
public I GetInterfaceComponent() where I: class
{
return GetComponent(typeof(I)) as I;
}

Public static List FindObjectsOfInterface() where I: class
{
MonoBehaviour monoBehaviours = FindObjectsOfType();
List list = new List();

Foreach(MonoBehaviour behaviour in monoBehaviours)
{
I component = behaviour.GetComponent(typeof(I)) as I;

If(component != null)
{
list.Add(component);
}
}

Return list;
}

24. Используйте расширения, чтобы сделать синтаксис более удобным. Например:

public static class CSTransform
{
public static void SetX(this Transform transform, float x)
{
Vector3 newPosition =
new Vector3(x, transform.position.y, transform.position.z);

Transform.position = newPosition;
}
...
}

25. Используйте безопасную альтернативу GetComponent. Иногда внедрение зависимостей компонентов (через RequiredComponent ), может быть болезненным. Например, это затрудняет изменение компонентов в инспекторе (даже, если они имеют тот же базовый тип). В качестве альтернативы, может быть использовано, следующее расширение GameObject , для вывода ошибки, если компонент не найден.

public static T GetSafeComponent(this GameObject obj) where T: MonoBehaviour
{
T component = obj.GetComponent();

If(component == null)
{
Debug.LogError("Expected to find component of type "
+ typeof(T) + " but found none", obj);
}

Return component;
}

Идиомы

26. Избегайте использования разных идиом, для того, чтобы сделать одну и ту же вещь. Зачастую есть больше одного идиоматического способа, чтобы сделать одну и ту же вещь. В таких случаях, следует выбрать один, и использовать его во всем проекте. И вот почему:

• Некоторые идиомы не сочетаются.
• Использование одной и той же идиомы, помогает всей команде понять, что происходит. Это делает структуру и код легче для понимания. Уменьшает вероятность совершить ошибку.

Примеры групп идиом:

• Сопрограммы vs конечного автомата.
• Вложенные префабы vs связанные префабы vs «Бог»-префабы.
• Стратегии разделения данных.
• Способы использования спрайтов для состояний в 2D-игр.
• Структура префаба.
• Стратегии спауна (spawning).
• Способы поиска объектов: по типу vs по имени vs по тегу vs по слою vs ссылке.
• Способы группировки объектов: по типу vs по имени vs по тегу vs по слою vs массиву или ссылкам.
• Поиск групп объектов vs self-registration.
• Контроль порядка выполнения (использовать установленный порядок исполнения Unity vs логику yield vs Awake/Start и Update/Late Update vs ручные методы vs в любом порядке).
• Выделение объектов / позиции / целей с помощью мыши в игре: менеджер выделения vs локальный self-management.
• Хранение данных между изменениями сцены: через PlayerPrefs, или объекты, которые не уничтожаются при загрузке новой сцены.
• Способы комбинирования (смешивания, добавления и наслаивание) анимации.

(*vs — против)

Время

27. Держите свой собственный класс времени, чтобы сделать паузу легче. Оберните Time.DeltaTime и Time.TimeSinceLevelLoad для учета пауз и временной шкалы. Использование его требует дисциплины, но облегчит работу с разными таймерами (например, анимация интерфейса и игровая анимация).

Спаун объектов

28. Не позволяйте порождаемым объектам загромождать иерархию, когда игра запущена. Установите для них родителя — объект сцены, для облегчения поиска объектов, при запущенной игре. Вы можете воспользоваться пустым объектом игры, или даже единичным объектом без поведения, чтобы легко получить доступ из кода. Вызовите этот объект DynamicObjects .

Дизайн классов

29. Используйте Синглтоны для удобства. Класс ниже, сделает синглтоном автоматически, любой класс производный от него:

public class Singleton : MonoBehaviour where T: MonoBehaviour
{
protected static T instance;

/**
Returns the instance of this singleton.
*/
public static T Instance
{
get
{
if(instance == null)
{
instance = (T) FindObjectOfType(typeof(T));

If (instance == null)
{
Debug.LogError("An instance of " + typeof(T) +
" is needed in the scene, but there is none.");
}
}

Return instance;
}
}
}

Синглтоны полезны, для различных менеджеров, таких как ParticleManager , или AudioManager , или GUIManager .

• Избегайте использования синглтонов для уникальных экземпляров префабов, которые не менеджеры (например, экземпляр Игрока). Не соблюдение этого принципа, усложняет иерархию наследований, и делает некоторые изменения сложнее. Вместо этого, держите ссылки на такие экземпляры в вашем GameManager (или другом подходящем «Бог»-классе;-)).
• Определите статические свойства и методы для публичных переменных и методов, которые часто используются за пределами класса. Это позволит вам писать GameManager.Player вместо GameManager.Instance.player .

30. Для компонентов, никогда не делайте переменные общедоступными, если они не должны изменяться через инспектор. Иначе, ее может «покрутить» дизайнер, не зная, что переменная делает. В редких случаях, это неизбежно. В таком случае, используйте два, или даже четыре подчеркивания в качестве префикса, в имени переменной, чтобы отпугнуть «крутильщиков»:

public float __aVariable;

31. Отделяйте интерфейс от логики игры. Это, по сути паттерн MVC.

Каждый контроллер ввода, должен лишь давать команды соответствующим компонентам, чтобы дать им знать, что контроллер был вызван. Например, в логике контроллера, можно решать, какие команды давать, основываясь на состоянии игрока. Но это плохо (например, это приведет к дублированию логики, если добавлено несколько контроллеров). Вместо этого, объект Игрока должен быть уведомлен о намерениях двигаться вперед, а затем на основе текущего состояния (замедлен или оглушен, например) установить скорость и обновить направление игрока. Контроллеры должны делать только то, что относится к их собственному состоянию (контроллер не меняет состояние, когда игрок изменяет состояние, поэтому контроллер вообще не должен знать о состоянии игрока). Другим примером является смена оружия игроком. Правильный способ сделать это в Player , с помощью метода SwitchWeapon(Weapon newWeapon) , который можно вызвать из GUI. GUI не должен манипулировать трансформациями, родителями и т.д..

Любой компонент интерфейса, должен только поддерживать данные, и выполнять обработку, связанную с его собственным состоянием. Например, отображение карты, на основе расчетов движения игрока. Тем не менее, это данные состояния игры, и не принадлежат к GUI. GUI должен лишь отображать данные состояния игры, хранить их нужно в другом месте. Картографические данные должны быть сохранены в другом месте (в GameManager , например).

Объекты геймплея не должны знать практически ничего о GUI. Единственным исключением является режим паузы, которая может контролироваться глобально посредством Time.timeScale (что не является хорошей идеей). Геймплейные объекты должны знать, если игра приостановлена. И это всё. Поэтому, не должно быть ссылок, на GUI-компоненты из объектов геймплея.

В общем, по идее, если вы удалите все классы GUI, игра должна компилироваться.

Вы также, должны быть в состоянии, повторно реализовать графический интерфейс и ввод без необходимости написания новой логики игры.

32. Разделяйте состояние игры и промежуточные данные. Промежуточные данные используются для скорости или удобства, и могут быть извлечены из состояния. Делая такое разделение, вы упрощаете:

• сохранение состояния игры
• отладку состояния игры

Один из способов сделать это, определение класса SaveData для каждого класса игровой логики:

PlayerSaveData
{
public float health; //public for serialisation, not exposed in inspector
}

Player
{
//... bookkeeping variables (переменные промежуточных данных)

//Don’t expose state in inspector. State is not tweakable.
private PlayerSaveData playerSaveData;
}

33. Отделяйте конфигурацию специализаций.

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

• Определите шаблонный класс для каждого класса игровой логики. Для экземпляра врага, мы определим класс EnemyTemplate . Где будут храниться, все отличительные характеристики.
• В классе игровой логики, определите переменную типа нашего шаблона.
• Сделайте префаб врага, и два шаблонных префаба WeakEnemyTemplate и StrongEnemyTemplate .
• При загрузке и порождении объектов, задайте переменной шаблона нужный шаблон.

Этот метод может стать довольно сложным (а иногда, излишне сложным, так что будьте осторожны!).

Например, лучше будет использование полиморфизма обобщения, мы можем определить класс, так:

public class BaseTemplate
{
...
}

Public class ActorTemplate: BaseTemplate
{
...
}

Public class Entity where EntityTemplateType: BaseTemplate
{
EntityTemplateType template;
...
}

Public class Actor: Entity
{
...
}

34. Не используйте строки ни для чего, кроме отображаемого текста. В частности, не используйте строки для идентификации объектов, префабов и т.д.. Досадным исключением является анимация, доступ к которым осуществляется по строковым именам.

35. Избегайте публичных индексов массивов. Не определяйте массив оружий, массив пуль, массив частиц, следующим образом:

public void SelectWeapon(int index)
{
currentWeaponIndex = index;
Player.SwitchWeapon(weapons);
}

Public void Shoot()
{
Fire(bullets);
FireParticles(particles);
}

Проблема тут не столько в коде, сколько в безошибочных настройках в инспекторе.
Вместо этого определите класс, который инкапсулирует три переменные, и создайте упомянутый массив, вот так:

public class Weapon
{
public GameObject prefab;
public ParticleSystem particles;
public Bullet bullet;
}

Код выглядит аккуратнее, а главное, так труднее совершить ошибку в настройке данных в инспекторе.

36. Избегайте использования в массивах структур. Например, игрок может иметь три типа атак. Каждая использует текущее оружие, но генерирует разные пули и другое поведение. Вы можете захотеть поместить пули в массиве, и воспользоваться таким видом логики:

public void FireAttack()
{
/// behaviour
Fire(bullets);
}

Public void IceAttack()
{
/// behaviour
Fire(bullets);
}

Public void WindAttack()
{
/// behaviour
Fire(bullets);
}

Перечисления могут сделать ваш код лучше …

public void WindAttack()
{
/// behaviour
Fire(bullets);
}

… Но для инспектора это плохо.
Лучше использовать отдельные переменные, так чтобы имена помогали увидеть, какое у них содержание. Используйте класс, чтобы сделать это изящно.

public class Bullets
{
public Bullet FireBullet;
public Bullet IceBullet;
public Bullet WindBullet;
}

Здесь предполагается, что нет других данных для огня, льда и воздуха.

37. Группируйте данные в сериализуемых классах, чтобы сделать параметры в инспекторе упорядоченнее. Некоторые объекты могут иметь десятки параметров. Это может стать кошмаром, при попытке найти правильную переменную в инспекторе. Чтобы упростить это дело, выполните следующие действия:

• Определите отдельные классы для групп переменных. Сделайте их публичными и сериализуемыми.
• В основном классе, определите публичные переменные каждого типа, как указанно ранее.
• Не инициализируйте эти переменные в Awake или Start ; так как они сериализуемые, Unity позаботится об этом.
• Вы можете указать значения по умолчанию, до присвоения значений в определении.

Это сгруппирует переменные в инспекторе в блоки, и облегчит управление ими.

public class MovementProperties //Not a MonoBehaviour!
{
public float movementSpeed;
public float turnSpeed = 1; //default provided
}

Public class HealthProperties //Not a MonoBehaviour!
{
public float maxHealth;
public float regenerationRate;
}

Public class Player: MonoBehaviour
{
public MovementProperties movementProeprties;
public HealthPorperties healthProeprties;
}

Текст

38. Если у вас много сюжетного текста, поместите его в файл. Не помещайте его в полях для редактирования в инспекторе. Сделайте, чтоб его легко было изменить, без редактора Unity, и особенно, без необходимости сохранения сцены.

39. Если вы планируете локализовать отдельно все строки в одном месте. Есть много способов сделать это. Один из способов заключается в определении класса Text , с публичным полем для каждой строки, и заданным значением по умолчанию на английском, например. Другой языковой подкласс, повторно инициализирует поля языковым эквивалентом.

Более сложные методы (подходящие, в случаях когда тело текста большое и/или много языков) заключаются в чтении из электронной таблицы, и обеспечении логики для выбора правильной строки, на основе выбранного языка.

Тестирование и отладка

42. Реализуйте свой собственный FPS-счетчика. Да. Никто не знает, что на самом деле измеряет FPS-счетчик Unity, но это не скорость кадров. Реализуйте собственный, так чтобы FPS соответствовал интуиции и визуальному контролю.

43. Реализуйте сочетаний клавиш, для снятия снимков экрана. Многие ошибки являются визуальными, и гораздо проще, сообщить о них, когда можно сделать скриншот. Идеальная система должна содержать счетчик в PlayerPrefs, чтобы последовательные скриншоты не перезаписывались. Скриншоты должны быть сохранены за пределами папки проекта, чтобы избежать случайного коммита в репозиторий.

44. Реализуйте сочетания клавиш, для печати позиции игрока в игровом мире. Это облегчает репорт о позиции ошибок, которые происходят в определенных местах в игровом мире, что в свою очередь облегчает отладку.

45. Реализуйте опции отладки для упрощения тестирования. Некоторые примеры:

• Разблокировать все предметы (айтемы).
• Отключить врагов.
• Отключить GUI.
• Сделать игрока непобедимым.
• Отключить весь геймплей.

46. Для команд, которые достаточно малы, сделайте префаб с опциями отладки, для каждого члена команды. Положите идентификатор пользователя в файл, который не коммитится, и читается, когда игра запускается. И вот, почему:

• Члены команды не закоммитят свои опции отладки по случайности, и никого не затронут.
• Изменение опций отладки не изменит сцену.

47. Держите сцену со всеми элементами геймплея. Например, сцена со всеми врагами, все объекты, с которыми можно взаимодействовать, и т.д. Это делает легкой проверку функциональности, без необходимости играть слишком долго.

48. Определите константы для отладки сочетания клавиш, и держите их в одном месте. Клавиши отладки не нормально (не удобно) обрабатываются в едином месте, как и остальные части игрового ввода. Чтобы избежать конфликтов между сочетаниями клавиш, определите константы в одном месте. Альтернативой является, обрабатывать все клавиши в одном месте, независимо от того, является функция отладочной, или нет. (Недостатком является то, что этому классу могут понадобиться дополнительные ссылки на объекты).

Документация

49. Документируйте ваши настойки. Большинство документации должно быть в коде, но некоторые вещи должны быть задокументированы вне кода. Документация, повышает эффективность (если она актуальная).

Документируйте следующее:

• Использование слоя (для коллизий, Culling, и Raycasting — по сути то, что должно быть на слое).
• Использование тэгов.
• Глубина GUI для слоев (что должно отображаться, поверх чего).
• Настройка сцены.
• Идиома предпочтений.
• Структуры префабов
• Слои анимации.

Стандарт именования и структура папок

50. Следуйте документированному соглашению об именовании и структурах папок. Следование ему облегчает поиск вещей, и понимание, что это за вещь.

Вы, скорее всего, захотите, сделать свое собственное соглашение об именовании и структурах папок. Вот одно в качестве примера.

Общие принципы именования.

• Называйте вещи своими именами. Птица должна называться Bird .
• Выбирайте имена, легко произносимые и запоминающиеся. Если вы делаете игру о Майя, не называйте свой уровень QuetzalcoatisReturn .
• Будьте последовательными. Выбрав имя, придерживайтесь его.
• Используйте стиль PascalCase, например: ComplicatedVerySpecificObject . Не используйте пробелы, подчеркивания или дефисы, с одним исключением (см. «Именования различных аспектов одного и того же»).
• Не используйте номера версий, или слова для обозначения стадии прогресса (WIP, финал).
• Не используйте аббревиатуры: DVamp@W должно быть DarkVampire@Walk .
• Используйте терминологию из дизайн документации: если в документе анимация смерти называется Die, то надо использовать имя DarkVampire@Die , а не DarkVampire@Death .
• Держите наиболее специфический дескриптор слева: DarkVampire , вместо VampireDark ; PauseButton , вместо ButtonPaused . Легче, например, найти кнопку паузы в инспекторе, когда не все кнопки, начинаются со слова «Button». [Многие люди предпочитают делать наоборот, потому что, это делает группировки, визуально более очевидными. Имена существуют не для группировок, для этого есть папки. Имена для различения объектов, одного и того же типа, и они должны помогать делать это быстро.]
• Некоторые имена образуют последовательность. Используйте номера в этих названиях, например, PathNode0 , PathNode1 . Всегда начинайте с 0, а не 1.
• Не используйте цифры для вещей, которые не образуют последовательность. Например, Bird0 , Bird1 , Bird2 , должно быть Flamingo , Eagle , Swallow .
• Ставьте префикс временным объектам в виде двойного подчеркивания __Player_Backup .

Именования различных аспектов одного и того же

Используйте подчеркивание между основным именем, и тем, что описывает «Аспект». Например:

• Состояние GUI-кнопок: EnterButton_Active, EnterButton_Inactive.
• Текстуры: DarkVampire_Diffuse, DarkVampire_Normalmap.
• Скайбоксы: JungleSky_Top, JungleSky_North.
• LOD-группы: DarkVampire_LOD0, DarkVampire_LOD1.

Не используйте, это соглашение просто, для различия типов предметов, например, Rock_Small , Rock_Large , должно быть SmallRock , LargeRock .

Структура

Организация ваших сцен, папки проекта и папки скриптов, должны следовать аналогичной схеме.

Структура папок:

Materials
GUI
Effects
Meshes
Actors
DarkVampire
LightVampire
...
Structures
Buildings
...
Props
Plants
...
...
Plugins
Prefabs
Actors
Items
...
Resources
Actors
Items
...
Scenes
GUI
Levels
TestScenes
Scripts
Textures
GUI
Effects
...

Структура сцены:

Cameras
Dynamic Objects
Gameplay
Actors
Items
...
GUI
HUD
PauseMenu
...
Management
Lights
World
Ground
Props
Structure
...

Структура папки скриптов:

ThirdParty
...
MyGenericScripts
Debug
Extensions
Framework
Graphics
IO
Math
...
MyGameScripts
Debug
Gameplay
Actors
Items
...
Framework
Graphics
GUI
...

Как переопределить отрисовку инспектора.

1. Определите базовый класс для всех ваших редакторов:

BaseEditor : Editor
where T: MonoBehaviour
{
override public void OnInspectorGUI()
{
T data = (T) target;

GUIContent label = new GUIContent();
label.text = "Properties"; //

DrawDefaultInspectors(label, data);

If(GUI.changed)
{
EditorUtility.SetDirty(target);
}
}
}

2. Используйте рефлексию и рекурсию, чтобы составить компоненты:

public static void DrawDefaultInspectors(GUIContent label, T target)
where T: new()
{
EditorGUILayout.Separator();
Type type = typeof(T);
FieldInfo fields = type.GetFields();
EditorGUI.indentLevel++;

Foreach(FieldInfo field in fields)
{
if(field.IsPublic)
{
if(field.FieldType == typeof(int))
{
field.SetValue(target, EditorGUILayout.IntField(
MakeLabel(field), (int) field.GetValue(target)));
}
else if(field.FieldType == typeof(float))
{
field.SetValue(target, EditorGUILayout.FloatField(
MakeLabel(field), (float) field.GetValue(target)));
}

///etc. for other primitive types

Else if(field.FieldType.IsClass)
{
Type parmTypes = new Type{ field.FieldType};

String methodName = "DrawDefaultInspectors";

MethodInfo drawMethod =
typeof(CSEditorGUILayout).GetMethod(methodName);

If(drawMethod == null)
{
Debug.LogError("No method found: " + methodName);
}

Bool foldOut = true;

DrawMethod.MakeGenericMethod(parmTypes).Invoke(null,
new object
{
MakeLabel(field),
field.GetValue(target)
});
}
else
{
Debug.LogError(
"DrawDefaultInspectors does not support fields of type " +
field.FieldType);
}
}
}

EditorGUI.indentLevel--;
}

Описанный выше метод использует вспомогательный метод:

private static GUIContent MakeLabel(FieldInfo field)
{
GUIContent guiContent = new GUIContent();
guiContent.text = field.Name.SplitCamelCase();
object descriptions =
field.GetCustomAttributes(typeof(DescriptionAttribute), true);

If(descriptions.Length > 0)
{
//just use the first one.
guiContent.tooltip =
(descriptions as DescriptionAttribute).Description;
}

Return guiContent;
}

Обратите внимание, что он использует аннотации в коде вашего класса, для генерации всплывающих подсказок в инспекторе.

3. Определите новые пользовательские редакторы.

К сожалению, вы все равно должны определить класс, для каждого MonoBehaviour. К счастью, эти определения могут быть пустыми, вся фактическая работа делается в базовом классе.

public class MyClassEditor: BaseEditor
{}

Теоретически, этот шаг может быть автоматизирован, но я не пробовал этого делать.

Перевод Максим Саликов .

Пролог.
Всем привет. Узнав о Unity3D, я очень обрадовался. Это была вторая вещь в геймдевлопе, которая меня зацепила простотой и интуитивностью (первая Game Maker). Так как я не люблю видеоуроки (сам не знаю почему), в поисках уроков очень сильно напрягался, из-за малого количества текстовых уроков. Поэтому решил написать данный цикл статей, для таких же любителей текстовых уроков как я. Так как этот цикл ориентирован на новичков, попутно будут изучаться возможности Unity3D.
Урок 0 или небольшой план.

«Будущее должно быть заложено в настоящем. Это называется планом.
Без него ничто в мире не может быть хорошим»
Георг Кристоф Лихтенберг

1. Создаем меню с летающей камерой аля Far Cry.
2. Персонаж. Движение и управление. Камера. Меняем позицию и вид камеры.
3. Статы. Часть первая. Опыт, деньги.
4. Квесты.
5. Ai. Искусственный интеллект. Часть первая. Покупка персонажа.
6. Статы. Часть вторая. Жизни, манна. Рисуем HP и MP бары.
7. Ai. Искусственный интеллект. Часть вторая. Мобы.
8. Инвентарь. Магазин.
План может дополняться и изменятся.
Урок 1. Меню с летающей камерой аля Far Cry.
В этом уроке мы узнаем основы создания сцен в Unity3D. Узнаем некоторые стандартные возможности и некоторые дополнительные.
Использовано:
1. Terrain Toolkit http://yadi.sk/d/NECQRcVaCEKuT
2. Nature Pack http://yadi.sk/d/m8Qu8ts2CEKyB
3. Real Nature Pack 2 Autumn v2 http://yadi.sk/d/A4IN7tuMCELA3
4. Tropical Nature Pack http://yadi.sk/d/lTMMWzC4CELCf

План:
1. Создание проекта. Импорт необходимых библиотек.
2. Генерация ландшафта. Редактирование.
3. Освещение. Камера.
4. Анимация камеры(полет).
5. Создание меню.
Создание проекта. Импорт необходимых библиотек.
Запускаем Unity. В «Project wizard» переходим во вкладку «Create New Project». В «Import the following packages» выбираем следующие паки: Skyboxes, Terrain Assets, Water(в зависимости от версии unity3d, я выбрал pro)

Заходи в «Assets>>Import package>>Custom package» и переходим в папку где у вас лежат скачанные паки. Выбираем и нажимаем открыть.

Внимание!!! Паки тяжелые по этому Unity может не слабо задуматься не пугайтесь!!
Генерация ландшафта.
Нажимаем «Terrain>>Create Terrain»

Появился объект «Terrain»
Нажимаем «Terrain>>Set Resolution» И устанавливаем размеры нашего ландшафта как на скриншоте. Для сцены меню на большой ландшафт не нужен и дабы не грузить процессор достаточно этих размеров.

Тыкаем «Set Resolution»
Нажимаем «Component>>Terrain>>Terain Toolkit»


В появившемся компоненте «Terrain Toolkit» я выставил все так


Советую поиграть с настройками очень часто вылазят такие интересные варианты ландшафта.
Итак наш ландшафт готов.
Зададим ему текстуру.
В инспекторе нажимаем на кисточку а затем Edit Textures.

И нажимаем Add Texture. В появившемся окне нажимаем «Select» на Texture

В появившемся окне выбираем текстуру (двойной клик мышью), я выбрал «Grass(Hill)»


Нажимаем Add и наш ландшафт перекрашивается.


Нажимаем «Raise/Lower terrain»


Выбираем кисть, размер(Brush Size) интенсивность(Opacity). И нажимая LBM(Левая кнопка мыши) поднимаем вершину, либо нажимая Shift+LBM опускаем.
Нажимая «Smooth Height» (3 кнопка) убираем острые углы.
Дальше я нарисовал что типа песчаного пляжа добавив текстуру «Good Dirt».
Вот что у меня получилось.

Выбираем «Place trees» и нажимаем «Edit trees». В появившемся окне нажимаем кружочек.
И аналогично выбору текстуры выбираем дерево.
И варируя настройками кисти насаживаем разных деревьев.
Аналогично на предпоследней кнопке насаживаем цветов, травы, камней итд.
С одним НО для того что бы не грузить процессор мы для травы мы выбираем «Add Grass Texture» а вот для остального «Add Details Mesh».
И в последней вкладке можно побаловаться с настройками деревьев, рендера, настройками ветра. Я оставил все стандартно.
Создадим воду. В окне «Project» идем в паку «OnQ Nature Pack 2 v2>>Resources Demo>>Standard Assets>>Water(pro only)» и выбираем «Daylight water».

Перетягиваем на сцену и при помощи кнопок трансформации ставим и растягиваем как нам надо.

Вот что у меня получилось.


На этом с ландшафтом покончено.
Добавим теперь «Skybox». Для Этого идем в «Edit>>Render Settings».

И в инспекторе выбираем материал «Skybox» тыкнув на кружок.


Я выбрал «Sunny2 skybox».
Освещение и камера.
В «GameObject>>Create Other» выберем «Point light».

В инспекторе выставляем навстройки. «Position» x=100 y=100 z=100 это выставит наш источник света по центру над «Terrain» на высоте равной 100. «Range» = 150, это радиус освещения вокруг источника. И «Itensity» = 3.3.


В итоге получился довольно мягкий свет достающий везде.


У нас уже есть стандартно созданная камера «Main Camera». Кликнем на ней в окне Hierarchy. И расположим ей в позиции X=10, Z=10. A Y устанавливаем относительно высоты вашего ландшафта, у меня получилось 45. Что бы уменьшить площадь захватываемой камерой Изменяем настройку «Field of View»(У меня 43). Ориентируясь на окно «Camera Preview» поворачиваем камеру так как нам надо. У меня получилось Rotation X=5, Y=45, Z=0.
Анимация камеры (полет)
Заходим в «Window>>Animation» или нажимаем Ctrl+6. Нажимаем на стрелочки в пустом поле и выбираем «Create New Clip»

Назовем его на пример «CameraFly». Нажмем на палочку на против «Position.x» и нажмем «Add Curves». Установим позицию кадра на 300 и выставляем необходимые координаты следующего положения камеры.
У меня получились следующие значения:

200?"200px":""+(this.scrollHeight+5)+"px");">
Переменная/номер кадра 300 | 600 | 900 | 1200 | 1500| 1800
Position.x 90 | 10 | 190 | 120 | 190 | 10
Position.y 45 | 45 | 45 | 45 | 45 | 45
Position.z 90 | 190 | 190 | 100 | 10 | 10
Rotation.x 5 | 45 | 15 | 15 | 15 | 15
Rotation.y 45 | 94 | 240 | 140 | 270 | 405
Rotation.z 0 | 0 | 0 | 0 | 0 | 0

Нажмем на кнопочку Play и посмотрим что получилось. И вот наша камера уже летает. Однако пролетев круг она останавливается. Давайте исправим это.
Создадим новый C# скрипт (RMB по окну «Project» далее «Create>>C# Script») и назовем его FlyCamera. В нем пишем в методе Update всего одну строчку:

200?"200px":""+(this.scrollHeight+5)+"px");">
transform.animation.CrossFade ("FlyCamera");

Этим заставляем циклично выполнять анимацию под названием «FlyCamera». Скрипт помещаем на Main Camera.
Проверяем и все работает).
Создаем меню.
Создадим скрипт под названием «Menu».
Зададим переменные:

200?"200px":""+(this.scrollHeight+5)+"px");">
public bool showMenu = true; //Отображать ли меню

В метод «Start» пишем:

200?"200px":""+(this.scrollHeight+5)+"px");">
showMenu = true;
window = 1;

В метод «Update» пишем:

200?"200px":""+(this.scrollHeight+5)+"px");">
{
}
if(curTime >
{
window = 0;
}
{
window = 1;
}

Создаем метод «OnGUI» и пишем в него:

200?"200px":""+(this.scrollHeight+5)+"px");">
{

{
}
{
}
{
}
{
}
}

//Далее все аналогично
if(window == 2)
{

{
}
{
}
{
}
{
}
{
window = 1;
}
}

If(window == 3)
{

{
window = 1;
}
}

If(window == 4)
{

{
}
{
window = 1;
}
}

{
useGUILayout=false;
}
}

Скрипт перемещаем на Main Camera.

Сохраним сцену под названием menu.unity

Полный код скрипта menu

200?"200px":""+(this.scrollHeight+5)+"px");">using UnityEngine;
using System.Collections;

Public class Menu: MonoBehaviour {
public bool showMenu; //Отображать ли меню
public int window; //Отображаемое окно
public float lifeTime = 5.0f; //Максимальное время отображения меню
private float curTime; //Текущие время отображения меню

Void Start () {
showMenu = true;
window = 1;
}

Void Update () {
if(showMenu == true) //Проверяем включно ли меню
{
curTime += Time.deltaTime; //Если включено, Увеличиваем переменную curTime согласно пройденому времени
}
if(curTime > lifeTime) //Если время дошло до максимальной точки
{
showMenu = false; //Отключаем меню
window = 0;
curTime = 0; //Сбрасываем таймер
}
if(showMenu == false&Input.anyKeyDown) //Если меню выключено и нажата любая клавиша
{
showMenu = true; //Включаем меню
window = 1;
}
}

Void OnGUI () {
if(window == 1) //Если окно 1
{
GUI.Box (new Rect (Screen.width/2-100,Screen.height/2-80,200,220), "Меню"); //Создаем окно с меню

If(GUI.Button (new Rect (Screen.width/2-90,Screen.height/2-40,180,30), "Новая игра"))
{
Application.LoadLevel(1); //Загружаем уровень 1
}
if(GUI.Button (new Rect (Screen.width/2-90,Screen.height/2-0,180,30), "Настройки"))
{
window = 2; //открываем окно настроек
}
if(GUI.Button (new Rect (Screen.width/2-90,Screen.height/2+40,180,30), "Об игре"))
{
window = 3; //Выводим информацию об Автарах игры
}
if(GUI.Button (new Rect (Screen.width/2-90,Screen.height/2+80,180,30), "Выход"))
{
window = 4; //Вызываем окно выхода
}
}

//Далее все аналогично
if(window == 2)
{
GUI.Box (new Rect (Screen.width/2-100,Screen.height/2-80,200,250), "Настройки");
if(GUI.Button (new Rect (Screen.width/2-90,Screen.height/2-40,180,30), "Игра"))
{
}
if(GUI.Button (new Rect (Screen.width/2-90,Screen.height/2-0,180,30), "Аудио"))
{
}
if(GUI.Button (new Rect (Screen.width/2-90,Screen.height/2+40,180,30), "Видео"))
{
}
if(GUI.Button (new Rect (Screen.width/2-90,Screen.height/2+80,180,30), "Управление"))
{
}
if(GUI.Button (new Rect (Screen.width/2-90,Screen.height/2+120,180,30), "Назад"))
{
window = 1;
}
}

If(window == 3)
{
GUI.Box (new Rect (Screen.width/2-100,Screen.height/2-80,200,220), "Об игре");
GUI.Label(new Rect(Screen.width/2-90,Screen.height/2-0, 180, 40), "Инфа о разрабе");
if(GUI.Button (new Rect (Screen.width/2-90,Screen.height/2+100,180,30), "назад"))
{
window = 1;
}
}

If(window == 4)
{
GUI.Box (new Rect (Screen.width/2-100,Screen.height/2-60,200,120), "Выход?");
if(GUI.Button (new Rect (Screen.width/2-90,Screen.height/2-20,180,30), "Да"))
{
Application.Quit(); //Выход из игры
}
if(GUI.Button (new Rect (Screen.width/2-90,Screen.height/2+20,180,30), "Нет"))
{
window = 1;
}
}

If(window == 0) //Если это окно то выключаем меню
{
useGUILayout=false;
}
}
}

Компилированная сцена http://yadi.sk/d/f5pFI0_pCG7YC

P.S. Прошу строго не судить, это моя первая статья.
P.P.S. Для тролей: да я быдлокодер, идите лесом!