Assembly Definition properties
Click on an Assembly Definition Asset to set the properties for an assembly in the Inspector A Unity window that displays information about the currently selected GameObject, asset or project settings, allowing you to inspect and edit the values. More info
See in Glossary window.
Assembly Definition properties are divided into the following sections:
Name and General
| Property: | Description: |
|---|---|
| Name | The name for the assembly (without a file extension). Assembly names must be unique across the Project. Consider using a reverse-DNS naming style to reduce the chance of name conflicts, especially if you want to use the assembly in more than one Project. Note: Unity uses the name you assign to the Assembly Definition asset as the default value of the Name field, but you can change the name as needed. However, if you reference an Assembly Definition by its name rather than its GUID, changing the name will break the reference. |
| Allow ‘unsafe’ Code | Enable the Allow ‘unsafe’ Code option if you have used the C# unsafe keyword in a script within the assembly. When you enable this setting, Unity passes the /unsafe option to the C# compiler when it compiles the assembly. |
| Auto Referenced | Specify whether the predefined assemblies should reference this Project assembly. When you disable the Auto Reference option, Unity does not automatically reference the assembly during compilation. This has no effect on whether Unity includes it in the build. |
| No Engine References | When you enable this property, Unity does not add references to UnityEditor or UnityEngine when it compiles the assembly. |
| Override References | Enable the Override References setting to manually specify which precompiled assemblies this assembly depends upon. When you enable Override References, the Inspector shows the Assembly References section, which you can use to specify the references. A precompiled assembly is a library compiled outside your Unity Project. By default, assemblies you define in your Project reference all the precompiled assemblies you add to the Project, which matches how the predefined assemblies reference all precompiled assemblies. When you enable Override References, this assembly only references the precompiled assemblies you add under Assembly References. Note: To prevent Project assemblies from automatically referencing a precompiled assembly, you can disable its Auto Referenced option. See Plugin Inspector for more information. |
| Root Namespace | The default namespace for scripts A piece of code that allows you to create your own Components, trigger game events, modify Component properties over time and respond to user input in any way you like. More info See in Glossary in this assembly definition. If you use either Rider or Visual Studio as your code editor, they automatically add this namespace to any new scripts you create in this assembly definition. |
Define Constraints
Define constraints specify the compiler #define directives that must be defined for Unity to compile or reference an assembly.
Unity only compiles and references a Project assembly if all of the Define Constraints are satisfied. Constraints work like the #if preprocessor directive in C#, but on the assembly level instead of the script level. Define all the symbols in the Define Constraints setting for the constraints to be satisfied.
The constraints are satisfied when the symbol ENABLE_IL2CPP is not defined and the symbol UNITY_2018_3_OR_NEWER is defined. The result is that Unity only compiles and references this assembly on non-IL2CPP scripting runtimes for Unity 2018.3 or newer.
You can use the || (OR) operator to specify that at least one of the constraints must be present in order for the constraints to be satisfied. For example:
The constraints are satisfied when either UNITY_IOS or UNITY_EDITOR_OSX and UNITY_2019_3_OR_NEWER are defined and UNITY_ANDROID is not defined. Individual lines are analogous to performing a logical AND operation between the constraints in them. The above example is equivalent to:
(UNITY_IOS OR UNITY_EDITOR_OSX) AND (UNITY_2019_3_OR_NEWER) AND (NOT UNITY_ANDROID)
You can use any of Unity’s built-in #define directives, symbols defined in a global compiler response (.rsp) file, and any symbols defined in the Project’s Scripting Define Symbols Player setting. See Platform dependent compilation for more information, including a list of the built-in symbols.
Note: The Scripting Define Symbols settings are platform-specific. If you use this setting to define whether Unity should use an assembly, make sure that you define the necessary symbols on all the relevant platforms.
Invalid or incompatible constraints
Unity marks each constraint with an indicator based on the currently defined settings (for example, the following set of three constraints indicates that the first symbol is currently defined while the other two are not). Since each individual constraint must be true for the overall constraint to be satisfied, the Editor marks the entire Define Constraints section as currently incompatible or invalid.
Invalid or incompatible constraints are flagged.
Assembly Definition References
| Property: | Description: |
|---|---|
| Assembly Definition References | Specify references to other assemblies that you have created using Assembly Definition assets. Unity uses these references to compile the assembly and also define the dependencies See in Glossary between assemblies. |
| Use GUIDs | This setting controls how Unity serializes references to other Assembly Definition assets. When you enable this property, Unity saves the reference as the asset’s GUID, instead of the Assembly Definition name. It’s good practice to use the GUID instead of the name, because it means you can make changes to the name of an Assembly Definition asset without having to update other Assembly Definition files that reference it. |
Assembly References
The Assembly References section only appears when you enable the Override References property (in the General section). Use this area to specify any references to precompiled assemblies on which this assembly depends.
Platforms
Set the platform compatibility of the assembly. Unity only compiles or references this assembly on the included (or not excluded) platforms.
Version Defines
Specify which symbols to define according to the versions of the packages and modules in a project.
20 вредных советов по разработке игр на Unity
В этой статье я попытался собрать советы которые помогут вам и вашей команде договориться наконец о том, как надо писать код, и, надеюсь, хорошо посмеяться. И так, поехали!
1. Пиши на UnityScript
Один язык в проекте — это скучно. Разнообразь жизнь своих коллег, пусть учаться быть полиглотами. C# — это майкрософт, и вообще строгая типизация это не твое.
2. Не используй var
Сами Unity запрещают * это делать, да и вообще непонятно, какого типа переменная. Когда тебе скажут про подсказки IntelliSense — закатывай глаза, майкрософт головного мозга! Твой Notepad++ этого не умеет.
3. Смешивай стили
4. Не пиши XML Doc комментарии
Они засоряют файл, а твой код должен быть понятен без дополнительных комментариев. И вообще, твой Notepad++ не поддреживает это всё. Если меняешь сигнатуру чужого метода, не обновляй XML Doc — так чтение автодокументации будет веселее.
5. Не используй namespace
Писать using — слишком муторно, и вообще зачем это делать, если можно обойтись без этого. Все скрипты должны лежать в папке Script — так их проще находить по алфавиту.
6. Связывай компоненты
Чем больше связей — тем лучше! Каждый компонент должен ссылаться на каждый другой компонент — зато так проще! У твоего персонажа должна быть ссылка на противника, дверь, гейм менеджер, ХП бар на канвасе, на любые другие объекты на сцене. А иначе как с этим работать?
7. Создавая референсы, прячь их через [SerializeField] private GameObject myGameObject;
Так твой референс можно будет отредактировать только через редактор, а в коде они мешаться не будут. Когда окажется, что что-то надо все-таки поменять через код, просто переделай private на public.
8. Не используй паттерны проектирования, кроме singleton
Когда тебе говорят про Dependency Injection или другие паттерны, закатывай глаза. Какие нафиг паттерны, тут тебе не энтерпрайз!
9. GameObject.SendMessage — потрясающе удобный инструмент, используй его как можно чаще
По возможности собирай название метода из нескольких строк — так твоим коллегам будет веселее искать, откуда вызвался метод!
10. Используй UnityEvent везде, где это возможно
Стандартные event’ы — это для лохов, тем более они не отображаются в инспекторе. Unity не зря придумали свои ивенты.
Выставляй все через инспектор. Раздели свой код на части и выстави 5 разных методов при нажатии на кнопку — так будет веселее искать, по нажатию какой кнопки этот метод вызывается!
11. Подписываясь на событие через AddListener, забывай прописать RemoveListener
Нет ничего веселее, чем дебажить и искать, почему код срабатывает несколько раз одновременно. Особенно когда это происходит не постоянно.
12. Кэшируй все компоненты на GameObject’ах
Даже если вы их не используете или используете один раз при нажатии на кнопку. Оптимизировать надо начинать как можно раньше! Не забывайте закэшировать transform; те, кто говорят, что transform уже закэширован — лжецы.
13. Не используй свойства
Свойства — это медленно, как вызов метода, а доступ к полю гораздо быстрее. Все преимущества свойств — выдуманы. Когда тебе кто-то начнет говорить про private set, обратную совместимость и необходимость рекомпиляции assembly в случае изменения поля на свойство, смотри на них как на дураков — какая еще компиляция, у нас геймдев а не энтерпрайз, мы тут dll не используем! И вообще, когда ты последний раз менял поле на свойство?
14. Не используй foreach
Ну, про это уже не раз говорили. Сами Unity запрещают использование foreach. Найдя foreach в коде коллеги, замени его на for и прочитай 10 минутную лекцию о том, что foreach создает мусор, для убедительности покажи свой бенчмарк, где ты обходишь список каждый кадр.
15. Не используй Linq
Linq — это медленно, сложно, и вообще это майкрософт. For на 10 строк — это гораздо красивее (foreach мы же не используем — забыл?). Если кто-то посмеет написать Query Expressions, то смотри на него как на идиота — майэскюЭль с Юнити перепутал!
16. Не используй строки
Строка — это выделение памяти, которую потом будет собирать GC. Используй char[] — не зря же ты в универе сишку проходил. Никакой юникод тебе не нужен — нечего лишние байты гонять, все равно у тебя bitmap шрифты.
17. Не используй Generics
Дженерики — это медленно и сложно, а Generic Constraints — еще сложнее. Какая нафиг ковариантность и контравариантность? У нас Юнити, тут этого нет! Когда нужны классы с разным типом, храните имя класса в переменной и находите его с помощью Type.GetType().
18. Не используй Coroutines без надобности
Они не работают на неактивных объектах, и вообще, создают дополнительную нагрузку. Храни состояние в булевых переменных, и проверяй их в Update — так гораздо удобнее, ведь все собрано в одном месте.
19. Как только выходит новая версия движка, ставь ее и закоммить папку ProjectSettings
Пусть твои коллеги учаться держать обновленный инструментарий. Ну и что, что проект сдавать через 2 дня, а новая версия с багами? Не твоя это проблема, что Unity не могут зарелизить нормально! Зато там есть новая система частиц, с которой тебе хочется поиграться.
20. Не используй текстовую сериализацию ассетов
1. В своем Bitbucket репозитории Unity действительно указывают на то, что в pull-request’ах нельзя использовать var или foreach. Интересно, что там же они пишут не использовать префиксы m_ k_ итд, хотя сами делают это в огромном количестве мест, в нарушение стандарта C# Style Guide.
Статья была частично навеяна вот этой статьей по оптимизации и периодическими перлами, которые выдают знакомые программисты.
Что бы не устраивать холивар, я предлагаю условиться, что foreach действительно создает мусор, который потом приходится собирать GC. Но во-первых, это правило работает не всегда (иногда foreach разворачивается компилятором в обычный for), а во-вторых, если не обходить большие списки в каждом кадре, в 99% случаев проблемой это не является.
Managed Plugins
Обычно скрипт в проекте содержится как файл исходного текста и компилируется Юнити при изменении. Однако также возможно компилировать скрипт в динамически связываемую библиотеку (dll) используя внешний компилятор. Результирующая dll может быть затем добавлена к проекту, а содержащиеся в ней классы прикреплены к объекту как обычные скрипты.
Создание dll
Путь к dll Юнити обычно такой
На Виндовс dll могут быт myfqltys в папках, принадлежащих приложению Юнити. Путь обычно такой
Использование dll
После компиляции dll файл может быт просто перетащен в Юнити проект как и любой другой ассет. Dll ассет имеет треугольник раскрывающий содержимое файла для выбора отдельного класса внутри библиотеки. Классы, которые были унаследованы от MonoBehaviour могут быть перетащены на ГеймОбъект как обычные скрипты. Не MonoBehaviour классы могут быт использованы прямо из других скриптов обычным путем.
Развернутая dll с классами в ней
Пошаговое руководство для MonoDevelop и Visual Studio
В этой секции вы узнаете как собрать и интегрировать простую dll с использованием MonoDevelop и Visual Studio, и как подготовить отладочную сессию для этой DLL.
Настройка проекта
Затем нужно заполнить информацию о новой библиотеке:
На данном этапе, у вас будет возможность выбрать нужный DLL файл. В Mac OSX, файл можно найти в
Для этого примера, переименуем класс в “MyUtilities” в Solution browser, и заменим его код на следующее:
Закончив с кодом, соберите проект, и сгенерируйте DLL файл с отладочными символами.
Использование DLL в Unity
/bin/Debug/DLLTest.dll в папку Assets. Затем, создайте C# скрипт под именем “Test” в Assets, и замените его содержимое на следующий код:
Когда вы присоедините этот скрипт к объекту в сцене, и нажмете Play, вы увидите вывод кода из DLL в окне консоли.
Настройка отладочного сеанса для DLL
Во-первых, вы должны исправить отладочные символы для DLL. В MonoDevelop, скопируйте файл сборки
/bin/Debug/DLLTest.dll.mdb в папку Assets/Plugins. В Visual Studio, выполните
Как мы переосмыслили работу со сценами в Unity
Unity, как движок, имеет ряд недостатков, но которые благодаря возможностям для кастомизации и инструментам для кодогенерации, можно решить.
Сейчас я вам расскажу о том, как мы написали плагин для Unity на основе пост-процессинга проектов и кодогенератора CodeDom.
Проблема
В Unity загрузка сцен происходит через строковой идентификатор. Он не стабильный, а это означает, что он легко изменяем без явных последствий. Например, при переименовании сцены всё полетит, а выяснится это только в самом конце на этапе выполнения.
Проблема обнаруживается быстро на часто используемых сценах, но может быть трудно обнаруживаемая, если речь идёт о небольших additive сценах или сценах, которые используются редко.
Решение
При добавлении сцены в проект, генерируется одноимённый класс с методом Load.
Если мы добавим сцену Menu, то в проекте сгенерируется класс Menu и в дальнейшем мы можем запустить сцену следующим образом:
По-хорошему, класс должен быть статическим, так как не предполагается создание экземпляра из него. Это ошибка, которую мы исправим. Как видно уже из этого фрагмента, кода мы цепляемся не к имени, а к GUID сцены, что является более надежным. Сам базовый класс выглядит вот так:
Теперь сцена может задекларировать список параметров, а вызывающий код должен передать для них аргументы.
Например, сцена Game хочет получить перечисление, содержащее всех игроков и при инициализации добавить для них аватаров.
В таком случае мы можем сами создать такой компонент.
После размещения его на сцене и последующим её сохранением, генератор добавит в класс сцены метода запуска сцены с обязательной передачей перечисления игроков.
В данный момент реализована возможность перегрузки обработчиков. Т.е. если на сцене будет N обработчиков с разными параметрами, под них создастся N методов запуска. Также не запрещается наличие нескольких компонентов-обработчиков с одинаковыми параметрами.
Это не фишка, а скорее недоработка, так как такой функционал быстрее создаст путаницу, нежели будет полезен.
А почему не сделать через N?
Первую версию плагина я осветил на своём YouTube канале в этом видео.
Там задали ряд вопросов и предложили альтернативные решения. Есть интересные подходы, которые имеют право на жизнь, а есть откровенно идиотские, которые я хочу разобрать.
Чем плох статический класс с полями, через которые передаются данные для сцены?
Нередко встречаю и такое. Речь идёт о классе по типу этого:
А уже внутри сцены, вероятно, будет группа компонентов, которая достаёт данные из свойств.
Основная проблема в том, что нет формализации: при загрузки сцены не совсем ясно, что нам нужно предоставить для корректной работы. Получателей в целом определить будет проще, так как мы можем воспользоваться поиском по ссылке.
Ну и опять же сцену придётся запускать по ID или имени.
Чем плох PlayerPerfs
Предлагали и такой экзотический вариант. Можно было бы начать с того, что PlayerPrefs вообще не предназначен для передачи значений внутри одного инстанса. Этим можно было бы и закончить, но продолжим критику тем, что вам также придётся работать с неформальными строковыми идентификаторами параметров.
Параллель с ASPNet
Мне хотелось получить что-то схожее с строго типизированными View из ASPNet Core. Мы считаем плохим тоном использовать ViewData и стараемся определять ViewModel. В Unity хочется что-то такого же толка с теми же преимуществами.
Но такой подход не очень распространён, к сожалению, и на это, я думаю, есть свои причины.
Где скачать
Плагин мы сделали в паре с Владиславом Койдо в рамках Proof-of-concept. Он ещё не стабилен и не обкатан как следует, но с ним уже можно поиграться.
Если вам интересно, я попрошу Владислава в следующей статье рассказать, как он работал с Code Dom в Unity и как работать с пост-процессингом на примере того, что мы сегодня обсуждали.
C# Unity the namespace ‘ ‘ already contains a definition for
I am studying access modifiers and I came across the following error in my code. Can someone explain to me and help me solve it? Assets\Testes\Scripts\modificadoracesso.cs(40,7): error CS0101: The namespace ‘ ‘ already contains a definition for ‘Felino’
I’ve looked for some answers but so far nothing works
2 Answers 2
Unless a class is in a namespace, the class it in the ‘global namespace’. Add a namespace around your classes. I’m not saying this is the complete answer, but not using namespaces is a bad idea. Namespaces usually start with the name of your solution and will be placed there automatically when you create a new class.
It’s only because you have another script in your project with this name! Maybe you accidentally duplicate it or something.
Not the answer you’re looking for? Browse other questions tagged c# unity3d or ask your own question.
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
site design / logo © 2021 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2021.11.26.40833
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.