monobleedingedge unity что это
Введение в IL2CPP
Unity продолжают совершенствовать технологию IL2CPP, а мы публикуем перевод статьи о том, как она работает.
Около года назад мы писали о будущем скриптинга в Unity. Новая технология скриптинга IL2CPP должна была обеспечить движок высокопроизводительной портативной виртуальной машиной. В январе мы выпустили нашу первую платформу на 64-битной iOS, использующую IL2CPP. С выходом Unity 5 появилась еще одна платформа – WebGL. При поддержке огромного сообщества пользователей мы выпустили множество патчей и обновлений для IL2CPP, постепенно оптимизируя компилятор и повышая быстродействие среды.
А пока мы продолжаем совершенствовать технологию IL2CPP, было бы неплохо рассказать о том, как она работает. Мы планируем написать серию статей, посвященных таким темам:
1. Основы – набор инструментов и аргументы командной строки (эта статья).
2. Экскурсия по генерируемому коду.
3. Советы по отладке генерируемого кода.
4. Вызовы методов: обычные методы, виртуальные методы и другие.
5. Реализация общего обмена.
6. Обёртки P/Invoke для типов и методов.
7. Интеграция сборщика мусора.
8. Тестирование и применение фреймворков.
В этих статьях мы обсудим некоторые особенности реализации IL2CPP. Надеюсь, эта информация вам пригодится.
Технология IL2CPP состоит из двух частей:
• компилятор Ahead-of-time (AOT);
• исполняемая библиотека для поддержки виртуальной машины.
Эта утилита принимает управляемые сборки, скомпилированные Mono-компилятором, поставляемым с Unity, и генерирует код C++, который мы передаем в компилятор C++ для конкретной платформы.
Инструментарий IL2CPP можно схематически представить так:
Вторая часть технологии IL2CPP – это исполняемая библиотека для поддержки виртуальной машины. Мы написали эту библиотеку почти полностью на C++ (в ней есть немного платформенного кода, но пусть это останется между нами) и назвали ее libil2cpp. Она поставляется в виде статической библиотеки, связанной с исполняемым файлом плеера, а ее простота и портативность являются одними из ключевых преимуществ технологии IL2CPP.
Вы можете получить более четкое представление об организации кода libil2cpp, глядя на файлы заголовков, поставляемых с Unity (их можно найти в директории Editor\Data\PlaybackEngines\webglsupport\BuildTools\Libraries\libil2cpp\include в Windows, или в директории Contents/Frameworks/il2cpp/libil2cpp – в OS X). Например, интерфейс между кодом C++, генерируемым il2cpp.exe, и средой libil2cpp находится в файле заголовка codegen/il2cpp-codegen.h.
Один из ключевых элементов среды – сборщик мусора. В комплект Unity 5 входит libgc, сборщик мусора Boehm-Demers-Weiser. Однако libil2cpp поддерживает и другие сборщики. Например, мы рассматриваем возможность интеграции с Microsoft GC – сборщиком с открытым исходным кодом в комплекте CoreCLR. В одной из следующих статей мы расскажем о нём подробнее.
Как выполняется il2cpp.exe?
Давайте рассмотрим на примере. Для этого я создам новый пустой проект в Unity 5.0.1 на Windows. Чтобы у нас был хотя бы один пользовательский скрипт, я добавлю к главной камере простой компонент MonoBehaviour:
При сборке для платформы WebGL я могу использовать Process Explorer, чтобы увидеть команду для запуска il2cpp.exe:
Это достаточно длинная строка, поэтому давайте разберем ее по частям. Сперва Unity запускает этот исполняемый файл:
Следующий аргумент – сама утилита il2cpp.exe.
Остальные аргументы передаются il2cpp.exe, а не mono.exe. Давайте разберем и их. Во-первых, Unity передает 5 флагов il2cpp.exe:
Стоит отметить, что этот набор аргументов командной строки для il2cpp.exe всё еще нестабилен и, скорее всего, изменится в последующих версиях.
Итак, в командной строке указаны 2 файла и 1 директория:
• «C:\Users\Josh Peterson\Documents\IL2CPP Blog Example\Temp\StagingArea\Data\Managed\Assembly-CSharp.dll»
• «C:\Users\Josh Peterson\Documents\IL2CPP Blog Example\Temp\StagingArea\Data\Managed\UnityEngine.UI.dll»
• «C:\Users\Josh Peterson\Documents\IL2CPP Blog Example\Temp\StagingArea\Data\il2cppOutput»
Утилита il2cpp.exe принимает список всех сборок IL, подлежащих конвертации. В нашем случае сюда входит мой простой скрипт MonoBehaviour, Assembly-CSharp.dll и UnityEngine.UI.dll. Обратите внимание, что здесь явно отсутствует несколько сборок. Очевидно, что мой скрипт ссылается на UnityEngine.dll, а значит нужен хотя бы mscorlib.dll, и, возможно, другие сборки. Но где они? Дело в том, что разрешение сборок происходит внутри il2cpp.exe. Их можно упомянуть в командной строке, но это необязательно. Получается, Unity нужно всего лишь указать корневые сборки (на которые не ссылаются другие сборки).
Чего не делает IL2CPP?
Хотелось бы обратить внимание на одну сложность, которую мы решили обойти стороной и таким образом избежали многих проблем. Мы не пытались переписать стандартную библиотеку C# под IL2CPP. При создании проекта Unity с использованием IL2CPP весь код стандартных библиотек C# (mscorlib.dll, System.dll и т. д.) является точной копией кода Mono-скриптов.
Мы используем код стандартных библиотек C#, потому что он уже успел хорошо зарекомендовать себя во многих проектах. Таким образом, если где-то возникает ошибка, мы можем быть уверены, что проблема в AOT-компиляторе или исполняемой библиотеке.
Разработка, тестирование и выпуск IL2CPP
С момента первого официального релиза IL2CPP версии 4.6.1p5 в январе мы выпустили 6 полноценных обновлений и 7 патчей (для Unity 4.6 и 5.0), в которых исправили более ста ошибок.
Чтобы обеспечить непрерывную оптимизацию, мы разрабатываем обновления на базе одной версии кода. Перед каждым релизом мы передаем все изменения в конкретную релизную ветку, проводим тестирование и проверяем, все ли ошибки были успешно исправлены. Наши команды QA и Sustained Engineering прикладывают максимум усилий, чтобы разработка велась в таком темпе, и ошибки исправлялись каждую неделю.
Наше сообщество оказало нам бесценную помощь, предоставив множество полезных сообщений об ошибках. Мы очень благодарны пользователям за все отзывы, которые помогают непрерывно улучшать IL2CPP.
Для разработчиков IL2CPP тестирование стоит на первом месте. Мы часто берем за основу технику разработки через тестирование и крайне редко отправляем запросы на включение, если код не был полностью протестирован. Эта стратегия хорошо работает для таких технологий, как IL2CPP, где есть четкие входы и выходы. Это означает, что подавляющее большинство ошибок, с которыми мы сталкиваемся, являются скорее частными случаями, чем неожиданным поведением системы (например, при использовании 64-битного IntPtr в качестве 32-битного индекса массива может произойти вылет с ошибкой компилятора С++). Таким образом, мы можем быстро определять и исправлять любые баги.
При поддержке нашего сообщества мы всё время делаем IL2CPP стабильнее и производительнее.
Обязательные условия
Откройте «Параметры проигрывателя» в инспекторе Unity, выбрав параметры Правка > Параметры проигрывателя > Проигрыватель.
Дополнительные сведения об этих вариантах см. в этой записи блога Unity.
Создайте новый текстовый файл с именем Csc. rsp в каталоге корневых ресурсов проекта Unity.
Перезапустите редактор Unity.
Добавление пакетов из NuGet в проект Unity
Нажмите кнопку Загрузить:
Найдите загруженный файл и измените его расширение с .nupkg на .zip.
В ZIP-файле зайдите в каталог lib/netstandard2.0 и скопируйте файл Newtonsoft.Json.dll.
В папке Assets в корневом каталоге проекта Unity создайте папку с именем Plugins (Подключаемые модули). В Unity «Plugins» — это имя специальной папки. Дополнительные сведения см. в документации по Unity.
Скопируйте файл Newtonsoft.Json.dll в каталог Plugins проекта Unity.
Создайте файл с именем link.xml в каталоге Assets проекта Unity и добавьте приведенный ниже код XML. Это нужно для того, чтобы процесс удаления байт-кода в Unity не удалял необходимые данные при экспорте в платформу IL2CPP. Несмотря на то что это действие относится только к данной библиотеке, проблемы могут возникнуть и с другими библиотеками, которые используют отражение подобным образом. Дополнительные сведения на эту тему см. в документации по Unity.
Теперь пакет Json.NET готов к работе.
Это простой пример использования библиотеки без зависимостей. Если одни пакеты NuGet зависят от других, необходимо вручную загрузить эти зависимости и добавить их в проект таким же образом.
Новые возможности синтаксиса и языка
Обновленная среда выполнения сценариев предоставляет разработчикам Unity доступ к C# 6 и целому ряду новых возможностей синтаксиса и языка.
Инициализаторы автосвойств
Интерполяция строк
Элементы, воплощающие выражение
Члены, заданные выражениями, теперь можно использовать также в свойствах, доступных только для чтения:
Асинхронный шаблон, основанный на задачах (TAP)
Асинхронное программирование позволяет выполнять длинные операции без зависания приложений. Кроме того, с помощью этой функции можно сделать так, чтобы код, в котором используются результаты ресурсоемких операций, выполнялся только после того, как будут выполнены эти операции, например после загрузки определенного файла или завершения сетевой операции.
TAP — это сложная тема с определенными характерными для Unity нюансами, которые разработчикам необходимо учитывать, поэтому его нельзя назвать универсальной заменой соподпрограммам в Unity. Тем не менее это полезный инструмент. Сфера применения этого компонента выходит за рамки данной статьи, но некоторые общие рекомендации и советы вы найдете ниже.
Начало работы с TAP в Unity
Эти советы помогут вам приступить к работе с TAP в Unity.
Различия между соподпрограммами и TAP
Между соподпрограммами и TAP (async-await) есть несколько важных различий.
В Unity 2018.2 отладка асинхронных методов с использованием точек останова не поддерживается в полном объеме; эта возможность будет реализована в Unity 2018.3.
Оператор nameof
Оператор nameof получает строковое имя, тип или член переменной. В некоторых случаях nameof удобно использовать для регистрации ошибок и получения строкового имени перечисления.
Информационные атрибуты вызывающего объекта
Информационные атрибуты вызывающего объекта содержат информацию о вызывающем объекте метода. Для каждого параметра, который вы хотите использовать c информационным атрибутом вызывающего объекта, необходимо указать значение по умолчанию.
Директива using static
Директива using static позволяет использовать статические функции, не указывая имя класса. Директива using static помогает сэкономить место и время при использовании нескольких статических функций одного класса.
Рекомендации по IL2CPP
Кроме того, как уже говорилось в приведенном выше примере Json.NET, во время экспорта IL2CPP Unity попытается удалить неиспользуемый код. Обычно это не страшно, но в случае с библиотеками, где используется отражение, это может привести к случайному удалению свойств или методов, которые будут вызываться в среде выполнения и не могут быть заданы во время экспорта. Для решения этой проблемы добавьте в свой проект файл link.xml, содержащий список сборок и пространств имен, к которым не нужно применять процесс удаления. Дополнительные сведения см. в документации Unity по удалению байт-кода.
Давайте поговорим о Unity
Бесплатная версия поддерживает только десктопы и вэб, и сильно урезана (нет постэффектов, рендера в текстуру и т.д).
Полный функционал (pro) стоит 1500$. Причём для десктопов, iPhone и Android ценник отдельный; а на консоли нужно вообще специально догавариваться.
Тем не менее на Unity вышло много коммерческих игр, таких как BattleStar Galactica Online, Feist, King’s Bounty Online.
Всё больше порталов и социальных сетей поддерживают API Unity наряду с Flash.
А EA и вовсе заключили многолетнее соглашение, благодаря которому все инструменты Unity доступны любому сотруднику EA в полном объеме.
Казалось бы, вот он, простой, но мощный и при этом весьма демократичный движок! Но почему-то на форуме активность unity крайне мала.
Все либо пишут свои движки, либо используют какой-нибудь Game- или RPGMaker. Есть даже мнение, что его время прошло. собственно, почему так?
Хочется разобраться; услышать отзывы тех, кто с ним работал более плотно.
Первое впечатление оно производит очень хорошее, но какие подводные камни?
Итак, кто что думает?
Я думаю что это бешено крутая штука, которую у меня пощупать никак руки не доходят. Смотрел ролики примеров, нравица.
меня пугает юнити поэтому боюсь с ним связываться. пугает не своей сложностью(вероятно он вовсе не сложен), а скорее своей не оптимизированностью
AcManZ
Я уже пощупал (правда мало), но ощущения двойственные. С одной стороны, ты можешь гораздо больше, чем без движка.
Во всяком случае есть чёткое понимание, что многие вещи, которые тут есть, мне не сделать и за годы работы.
Но с другой стороны такое чувство, что тебя связали по рукам и ногам (нет возможности поменять что-то на низком уровне, да и уже много раз упирался в ограничения free-версии).
Почему я не пользуюсь юнити? Я просто не могу понять зачем мне это нужно.
Непонятно, как на нем деньги зарабатывать.
Ну вот как-то так.
Попробовать тоже хочу 🙂
Апдейт.
Я имею ввиду, что хочу попробовать использовать в проекте новом.
Пока дальше ковыряний по туториалам дело не пошло.
IPPavlov
> а скорее своей не оптимизированностью
Гм, а что именно вы понимаете под опитимизированностью? Это вопрос криворукости программиста, работающего с движком, не более.
Alprog
> Но с другой стороны такое чувство, что тебя связали по рукам и ногам (нет
> возможности поменять что-то на низком уровне, да и уже много раз упирался в
> ограничения free-версии).
Зависит от проекта, конечно, но мне кажется юнити дает гораздо больше свободы, чем другие коммерческие движки. По крайней мере, игры на юнити не выглядят как моды к какому-нибудь унреалу или крузису.
fzr125
Если хочется писать движки, зачем вообще тогда трогать готовые решения? =) Если только не с целью «посмотреть как у других».
PagaN
> Непонятно, как на нем деньги зарабатывать.
Берешь лопату и начинаешь грести деньги, в чем проблема? Зарабатывать так же, как и в любом другом случае. Цифровая дистрибуция/Продажа крупному порталу веб версии/Мобильные приложения/Консоли/Free-to-play монетизация/Соц. сети. Дальше продолжать?
Alprog
> Казалось бы, вот он, простой, но мощный и при этом весьма демократичный движок!
> Но почему-то на форуме активность unity крайне мала.
> Все либо пишут свои движки, либо используют какой-нибудь Game- или RPGMaker.
> Есть даже мнение, что его время прошло. собственно, почему так?
А смысл что-то флудить на форуме? Это движкопейсателям по каждому вопросу требуется онлайн-консультация. По каким-то тонким вопросам есть официальный форум юнити и русское коммьюнити, этого достаточно.
Dan Diamond
вы правы, а мы не правы.
Unity 2018.2.17 с ошибкой SQLite: MonoBleedingEdge?
До сих пор я без проблем использовал SQLite в своей игре Unity: сегодня мне было предложено обновить Unity (до 2018.2.17), и после обновления я больше не могу создавать свои игры.
Теперь существует конфликт между System.Data.DLL моего проекта и другим, найденным в подпапке MonoBleedingEdge.
На моем проекте было скопировано из: единство/содержание/Mono/Либ/mono/единство/System.Data.DLL
А папка MonoBleedingEdge-это: Unity/Contents/MonoBleedingEdge/lib/mono/4.7.1-api/System.Data.DLL
Размеры файлов совершенно разные (mono-это
700-800kb, а MonoBleedingEdge-это
Есть какие-нибудь идеи о том, как это исправить или почему это произошло? Или почему это случилось только сейчас?
1 ответ
Я столкнулся с этой основной проблемой при интеграции AppWarp Unity SDK (версия не указана, загружена 10 марта) с Unity 4.3.4 Android player. Образец AppWarpVikingMobile завершается с той же ошибкой. telnet appwarp.shephertz.com 12346 действительно подключается к серверу. Wireshark не показывает.
у меня была такая же проблема в нескольких автономных проектах unity windows с 2018.2.17 и 2018.2.18
я удалил System.Data.dll в папке Assets/Plugins/SQLite/ в своем проекте. это решило проблему для меня.
Похожие вопросы:
Мне нужно создать базу данных sqlite в Unity (C#) для проекта android, но я не могу найти необходимую информацию или учебные пособия. Я иду по этой ссылке http:/ / answers.unity3d.com / вопросы /.
Я столкнулся с этой основной проблемой при интеграции AppWarp Unity SDK (версия не указана, загружена 10 марта) с Unity 4.3.4 Android player. Образец AppWarpVikingMobile завершается с той же.
Здравствуйте, я работаю над игровым проектом android в unity3d 5 (язык c#)that должен сохранить некоторые данные в базу данных sqlite. в игре не так много данных для хранения, у нее есть только 1.
Я использую Unity, вот небольшой фрагмент моего кода. Все, что я хочу сделать, это поместить data.token и data.expire в SQLite. По какой-то причине он продолжает бросать мне ошибку, то есть.
В моей игре Unity я получаю системную дату и отправляю ее в базу данных Sqlite. Но в базе данных sqlite дата сохраняется как 4-значное число. это код, который я использовал, чтобы получить дату.
Это в основном последующий вопрос после того, как я опубликовал этот вопрос вчера. Короче говоря, у меня были проблемы со ссылкой на System.ServiceModel в моем приложении Unity, и я исправил это.
Я новичок в unity. Мне нужно подключить базу данных Sqlite в устройстве Android. В редакторе unity он работает нормально, но в устройстве Android я получаю ошибку Недопустимый формат строки.
Ошибки новичка Unity, испытанные на собственной шкуре
Привет, Хабр. Это снова я, Илья Кудинов, QA-инженер из компании Badoo. Но сегодня я расскажу не о тестировании (этим я уже занимался в понедельник), а о геймдеве. Нет, этим мы в Badoo не занимаемся, разрабатывать компьютерные игры — моё хобби.
Профессионалы индустрии, не судите строго. Все советы в этой статье адресованы начинающим разработчикам, решившим попробовать свои силы в Unity. Многие советы можно отнести к разработке в целом, но я постараюсь добавить в них Unity-специфику. Если вы можете посоветовать что-то лучше, чем предлагаю я — пишите в комментариях, буду обновлять статью.
Я мечтал разрабатывать игрушки с детства. Наверное, уже в далёком 1994 году, когда мне подарили мою первую Dendy, я думал: “Как была бы здолава, если бы вот в этай иглушке было бы ещё всякое классное. ” В средней школе я начал учиться программировать и вместе с товарищем делал свои первые играбельные поделки (ох, как мы их любили!). В институте мы с друзьями строили наполеоновские планы о кардинальном изменении индустрии с помощью нашей совершенно новой темы…
А в 2014 году я начал изучать Unity и наконец-то НА САМОМ ДЕЛЕ начал делать игры. Однако вот беда: я никогда не работал программистом. У меня не было опыта настоящей корпоративной разработки (до этого я всё делал “на коленке”, и, кроме меня, в моём коде никто бы не разобрался). Я умел программировать, но я не умел делать это хорошо. Все мои знания Unity и C# ограничивались скудными ещё на тот момент официальными туториалами. А мой любимый способ познавать мир — делать ошибки и учиться на них. И я наделал их предостаточно.
Сегодня я расскажу о некоторых из них и покажу, как их избежать (ах, если бы я знал всё это три года назад!)
Для того чтобы понять все используемые в материале термины, достаточно предварительно пройти один-два официальных туториала Unity. Ну, и иметь хоть какое-то представление о программировании.
Не засовывайте всю логику объекта в один MonoBehaviour
Что, суть моего совета в том, чтобы не писать гигантские классы, спасибо, Кэп? Нет. Мой совет: дробите вашу логику на атомарные классы ещё до того, как они станут большими. Пусть сначала ваши объекты будут иметь три-четыре осмысленных компонента по десятку строк в коде каждого, но ориентироваться в них будет не сложнее, чем в одном из 50 строк, зато при дальнейшем развитии логики вы не окажетесь в такой ситуации, как я. Заодно появляется больше возможностей для переиспользования кода — например, компонент, отвечающий за здоровье и получение урона, можно прилепить и игроку, и противникам, и даже препятствиям.
Не забывайте про ООП
Каким бы простым ни казалось на первый взгляд проектирование объектов в Unity (“Программирование мышкой, фуууу”), не нужно недооценивать эту составляющую разработки. Да-да, я вот недооценивал. Прямо по пунктам:
При этом C# — такая душка, что позволяет не плодить эти параметры, и вот эти два вызова будут работать идентично:
Изучите Editor GUI
Я этим занялся значительно позже, чем стоило. Я уже писал статью о том, как это может помочь при разработке как программисту, так и геймдизайнеру. Помимо кастомных инспекторов для отдельных атрибутов и целых компонентов, Editor GUI можно использовать для огромного количества вещей. Создавать отдельные вкладки редактора для просмотра и изменения SAVE-файлов игры, для редактирования сценариев, для создания уровней… Возможности — безграничны! Да и потенциальная экономия времени просто восхитительна.
Думайте о локализации с самого начала
Даже если вы не уверены, что будете переводить игру на другие языки. Впиливать локализацию в уже сформировавшийся проект — невыносимая боль. Можно придумать самые разные способы локализации и хранения переводов. Жаль, что Unity не умеет самостоятельно выносить все строки в отдельный файл, который поддаётся локализации “из коробки” и без доступа к остальному коду приложения (как, например, в Android Studio). Вам придётся писать такую систему самому. Лично я использую для этого два решения, пусть и не очень изящные.
Оба они базируются на моём собственном классе TranslatableString :
В нём ещё есть кучка строк с защитой от ошибок и проверки на заполненность полей, сейчас я их убрал для читабельности. Можно хранить переводы как массив, но по ряду причин я всё же выбрал отдельные поля.
Вся “магия” — в методе неявного преобразования в строку. Благодаря ему вы в любом месте кода можете вызвать что-то типа такого:
— и сразу же получить в строке text нужный перевод в зависимости от текущего языка в настройках игрока. То есть в большинстве мест при добавлении локализации даже не придётся изменять код — он просто будет продолжать работать со строками, как и раньше!
Первый вариант локализации очень простой и подходит для игр, где совсем мало строк, и все они расположены в UI. Мы просто добавляем каждому объекту с переводимым компонентом UnityEngine.UI.Text вот такой компонент:
Заполняем все строки переводов в инспекторе — и вуаля, готово!
Кстати, полезная вещь — язык системы игрока (по сути, его локализационные предпочтения) можно получить с помощью, например, вот такого кода:
Пишите подробные логи!
Это может показаться излишним, но теперь некоторые мои игры пишут в лог практически каждый чих. С одной стороны, это дико захламляет консоль Unity (которая, к сожалению, не умеет заниматься никакой удобной фильтрацией), с другой — вы можете открыть в любом удобном вам софте для просмотра логов исходные лог-файлы и составлять по ним любые удобные вам отчёты, которые помогут заниматься как оптимизацией приложения, так и поиском аномалий и их причин.
Создавайте самодостаточные сущности
Я делал глупости. Предположим, мы хотим как-то хранить настройки различных уровней какой-то игры:
Мой первоначальный подход был такой: Mission хранит в себе только параметры, а MissionController занимается всеми прочими запросами. Например, чтобы получить лучший счёт игрока на определённом уровне я использовал методы вида
Казалось бы, всё работает исправно. Но затем таких методов становилось всё больше, сущности разрастались, появлялись прокси-методы в других классах… В общем, наступил спагетти-ад. Поэтому в конечном счёте я решил вынести все методы для работы с миссиями в саму структуру Mission и стал получать рекорды миссии, например, таким образом:
что сделало код гораздо более читабельным и удобноподдерживаемым.
Не бойтесь использовать PlayerPrefs
Во многих источниках говорится, что PlayerPrefs нужно использовать очень осторожно и при каждом возможном случае вместо этого самостоятельно сериализовывать данные и писать их в собственные файлы. Раньше я старательно готовил свой формат бинарного файла для каждой сохраняемой сущности. Теперь я так не делаю.
Класс PlayerPrefs занимается тем, что хранит пары «ключ => значение» в файловой системе, причём работает одинаково на всех платформах, просто хранит свои файлы в разных местах.
Постоянно писать данные в поля PlayerPrefs (и читать их) — плохо: регулярные запросы к диску никому добра не делают. Однако можно написать простую, но разумную систему, которая поможет этого избежать.
Например, можно создать единый SAVE-объект, который хранит в себе все настройки и данные игрока:
Следите за объектами в сцене
Вот вы запустили свою игру. Она работает, вы радуетесь. Поиграли в неё минут 15, поставили на паузу, чтобы проверить этот любопытный ворнинг в консоли… ОБОЖЕМОЙ, ПОЧЕМУ У МЕНЯ В СЦЕНЕ 745 ОБЪЕКТОВ В КОРНЕ. КАК МНЕ ЧТО-НИБУДЬ НАЙТИ.
Избегайте GameObject.Find()
Очень дорогая с точки зрения ресурсов функция для поиска объектов. Да ещё и завязана она на имени объекта, которое нужно каждый раз изменять как минимум в двух местах (в сцене и в коде). То же можно сказать и про GameObject.FindWithTag() (я бы вообще предложил отказаться от использования тегов — всегда можно найти более удобные способы определения типа объекта).
Если уж очень приспичит, обязательно кешируйте в переменную каждый вызов, чтобы не делать его больше одного раза. Или вообще сделайте связи объектов через инспектор.
Важно: в отличие от большинства других функций для поиска объектов, transform.Find() возвращает даже отключенные (gameObject.active == false) в данный момент объекты.
Договоритесь с художником о формате изображений
Особенно если художник — это вы сами. Особенно если художник никогда раньше не работал над играми и IT-проектами в целом.
Дать много советов по текстурам для 3D-игр я не смогу — сам ещё глубоко в это не закапывался. Важно научить художника сохранять все картинки с POT-габаритами (Power Of Two, чтобы каждая сторона картинки была степенью двойки, например, 512х512 или 1024х2048), чтобы они эффективнее сжимались движком и не занимали драгоценные мегабайты (что особенно важно для мобильных игр).
А вот рассказать грустных историй про спрайты для 2D-игр я могу много.
Устанавливайте майлстоуны
Что это такое? По хорошему, майлстоун (milestones — камни, которые в былые времена устанавливали вдоль дороги каждую милю для отмечания расстояний) — это определённое состояние проекта, когда он достиг поставленных на данный момент целей и может переходить к дальнейшему развитию. А может и не переходить.
Наверное, это была наша главная ошибка при работе над дебютным проектом. Мы поставили перед собой очень много целей и шли ко всем сразу. Всегда что-то оставалось недоделанным, и мы никак не могли сказать: “А вот теперь проект действительно готов!”, потому что к имеющемуся функционалу постоянно хотелось добавить что-то ещё.
Не надо так делать. Лучший способ развития игры — точно знать конечный набор фич и не отходить от него. Но это уж больно редко бывает, если речь идёт не о крупной индустриальной разработке. Игры часто развиваются и модернизируются прямо в процессе разработки. Так как же вовремя остановиться?
Составьте план версий (майлстоунов). Так, чтобы каждая версия была завершённой игрой: чтобы не было никаких временных заглушек, костылей и недореализованного функционала. Так, чтобы на любом майлстоуне было не стыдно сказать: “На этом мы и закончим!” и выпустить в свет (или навсегда закрыть в шкафу) качественный продукт.
Заключение
Глупый я был три года назад, да? Надеюсь, вы не будете повторять мои ошибки и сэкономите много времени и нервов. А если вы боялись даже попробовать начать заниматься разработкой игр, может быть, я смог вас хоть немного на это мотивировать.
P. S. Я подумываю о написании туториала вида “Делаем игрушку для хакатона за сутки с нуля”, по которому человек без знания Unity и навыков программирования смог бы написать свою первую игру. На русском языке качественных туториалов такого формата не очень много. Как думаете, стоит попробовать?