Unity development on linux

PC, Mac & Linux Standalone build settings

The PC, Mac & Linux Standalone build settings contain options you can use to set up and begin the build process for your application on these platforms. It contains settings to create development builds A development build includes debug symbols and enables the Profiler. More info
See in Glossary as well as publishing your final build. To access the Build Settings window, go to File > Build Settings. Once you specify the build settings, select Build The process of compiling your project into a format that is ready to run on a specific platform or platforms. More info
See in Glossary to create your build, or select Build And Run to create and run your build on the platform you specify.

Standalone Build Settings

The following table outlines the settings available for your build. These vary depending on the target operating system you choose.

Setting		Description
Target Platform
Windows	Build for Windows
macOS X (Not available on Linux)	Build for macOS
Linux (not available on Mac)	Build for Linux
Architecture	Not available on macOS
x86	32-bit CPU
x86_64	64-bit CPU
x86 + x86_64 (Universal)	All CPU devices for Linux
Server Build		Enable this setting to build the Player for server use and with no visual elements (headless) without the need for any command line options. When you enable this setting, Unity builds managed 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 with the UNITY_SERVER define, which means you can write server-specific code for your application. You can also build to the Windows version as a console application to access stdin and stdout . Unity logs go to stdout by default.
Copy PDB files(Windows only)		Enable this setting to include Microsoft program database (.pdb) files in the built Standalone Player. .pdb files contain application debugging information that is you can use to debug your application. Copying .pdb files might increase the size of your Player, so you should disable this setting for builds that are intended for publishing. This setting is disabled by default.
Create Visual Studio Solution(Windows only)		Enable this setting to generate Visual Studio Solution files for your Project, so you can build your final executable in Visual Studio.
Create Xcode Project (Mac Only)		Enable this setting to generate an Xcode project so you can build your final application bundle in Xcode. Xcode has built-in support for code signing and uploading the application to the Mac App Store.
Development Build		Enable this setting to include scripting debug symbols and include the Profiler A window that helps you to optimize your game. It shows how much time is spent in the various areas of your game. For example, it can report the percentage of time spent rendering, animating or in your game logic. More info See in Glossary in your build. When you enable this setting, the DEVELOPMENT_BUILD scripting define is set. You should use this option when you want to test your application.
Autoconnect profiler		Requires Development Build option to be enabled. When you enable this setting, the Unity Profiler automatically connects to your build.
Deep Profiling Support		Requires Development Build option to be enabled. Deep Profiling Support enables the Unity Profiler to record more detailed data by instrumenting every function call. Enabling Deep Profiling might slow down script execution.
Script debugging		Requires Development Build option to be enabled. When you enable this setting, Unity adds debugging symbols to your script code.
Scripts Only Build		Requires Development Build option to be enabled. When you enable this setting, you can rebuild only the scripts for your application while leaving data files intact from a build you have previously executed. Script only builds significantly improves iteration times if you are only changing the code in your application. You need to build the whole Project once before you can use this setting.

For information on minimum requirements for build targets see documentation on Player System Requirements.

Источник

Перенос редактора Unity на Linux: вещи, которые стоило бы сделать заранее

На прошедшей в этом году конференции Unite Europe мы опубликовали наш план развития. И хотя там много классных вещей, лично мне больше всего нравится редактор для Linux. История портирования редактора под Linux похожа на историю добавления поддержки Linux для среды выполнения в Unity 4.0. По большому счету это делается для души, часть сотрудников Unity периодически работала над этим в течение некоторого времени, во многом этот проект является одним из итогов внутренних хакерских недель (hackweek) среди разработчиков Unity — и я бы сказал, что дело продвигается весьма неплохо. Достаточно скоро мы планируем выпустить экспериментальную сборку, которую вы все сможете попробовать.

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

* Большого количества кода на C++, большая часть которого (но не все) общая с нашей средой выполнения, который, само собой, компилируется под нужную платформу

* Большого количества кода на C#, работающего поверх Mono

* Различных библиотек и связующих программ (middleware) от сторонних производителей, которые должны быть перекомпилированы под Linux

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

1. Позаботиться о чувствительности к регистру

Unity неправильно работает на чувствительных к регистру файловых системах (с чем уже могли столкнуться те пользователи, которые пытались установить и запустить редактор на чувствительной к регистру файловой системе HFS+). В основном это связано с тем, как именно база данных ресурсов Unity хранит пути к ним и связывает их со значениями GUID. Само собой мы пытались учесть все в начале разработки, но если вы не проверяете на практике, как система работает на чувствительных к регистру файловых системах, то она никогда не упадет после того как один из программистов не применит где-нибудь с самыми лучшими намерениями toLower() и не испортит всю идею.

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

2. Не использовать #if WINDOWS #else OSX

Совершенно неожиданный объем работы на раннем этапе переноса редактора под Windows был связан с вещами вроде

или, как вариант

Вывод: если вы хотите писать переносимый код, всегда делайте что-то разумное (читай: с расчетом на будущее) в случае #else.

3. Просто не делайте предположений

Две предыдущие проблемы были очень крупными, следующие помельче

* Предположения о компиляторах. Для примера возьмем нашу систему отслеживания ошибок (bug reporter), которая писалась во многом отдельно от основного редактора и использует некоторые возможности C++11. Во многих местах этот стандарт… э-э… несколько неопределенный и разные компиляторы реализуют его по разному. Это делает перенос кода C++11 на третий компилятор весьма болезненным. Было очень много ошибок компиляции в духе этот-шаблон-С++-с-кучей-угловых-скобок не совпадает с этим-шаблоном-С++-с-кучей-уголовых-скобок-в-котором-есть-константа-где-то-в-середине.

* Предположения по поводу родных приложений, включая тем пункты, которые автоматически включаются в меню приложений. Для примера, на Windows вещи вроде «копировать», «вставить» и тому подобное включаются бесплатно, а вот в GTK нет и нам пришлось добавлять их вручную. Не буду врать, в OS X они доже не добавляются автоматически, но реализация для OS X попала в описанную выше ловушку #if WINDOWS #else OSX.

* Предположения о работе файловых диалогов. На других платформах есть системы обратных вызовов (callback), позволяющие родительскому приложению объяснить диалогу, что некоторые вещи выбирать нельзя. Стандартные виджеты GTK так не работают.

* Предположения в целом

Вывод: предположения — это источник всех бед. 🙂

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

Интереса ради опишу решение, от которого нам пришлось отказаться в процессе переноса. Первый вариант использовал чистый X11 для обработки окон и событий, потому что мы не хотели привязываться ни к GTK ни к QT. Из-за этого ранняя система меню была написана на Unity GUI. Мне все еще кажется, что было бы очень круто вернуться к этому когда-нибудь. В Unity 5.1 в качестве встроенного браузера используется CEF, который зависит от GTK, так что мы переключились на GTK для обработки окон и событий для всех систем меню. Но это был единственный случай, когда нам пришлось переделывать что-то заново.

Так как продвигается работа над редактором? Вот что я знаю:

* будет поддерживаться только 64-битный Linux

* Аналогично нашей среде выполнения, чтобы не сойти с ума, мы будем официально поддерживать только Ubuntu. Но скорее всего редактор будет работать и в других дистрибутивах.

* Скорее всего мы будем поддерживать версии Ubuntu начиная с 12.04 (именно на ней мы делаем наши текущие сборки)

* Зависящие от сторонних библиотек возможности (вроде глобального освещения) будут работать

* Установщик скорее всего (мы его пока еще не сделали) будет пакетом .deb

* Некоторые из импортеров моделей, зависящие от стороннего софта (вроде 3ds Max и SketchUp) не будут работать. В качестве обходного пути можно использовать экспорт в FBX

На данный момент все. Небольшой тизер:

Наше сетевое демо двухмерного шутера, экспортируемое на Linux из редактора на Linux.

Linux-редактор в Unity Labs. Шрифты такие маленькие, потому что он запущен на MacBook Pro с Retina.

Источник

Unity на Linux? Да без проблем

Думаю долго мучает эта идея многих из нас: А не перейти ка мне полностью на Linux? Так было и со мной. Много дней раздумий, много за и против.

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

Думал как ставить Unity так, чтобы не через Wine. И о чудо. Unity уже давно ведут ветку Linux пакетов, готовых к установке. Есть у них как и .sh скрипт, так и готовый .deb пакет(ссылки внизу).
Каждая выпускаемая версия Unity собирается и для нашей OC. Есть косяки иногда, но они малозаметны и, в принципе, для комфортной разработки есть всё что нужно и всё хорошо работает.
И так. Unity ставится просто и легко

1. С помощью готового .deb пакета через менеджер
2. Или через терминал

Дальше начинается неразбериха. Думаю вы знаете, что Unity использует свой компилятор. Ему нежен .Net версии 3.5.

Я пробовал для работы Rider от JB(на окнах всё хорошо, в Ubuntu,Mint ругается на отсутствие .Net 3.5), VSCode(тоже самое и ещё чуть чуть) и новый MonoDevelop, который поставляется через flatpack. Но с ним оказалась куча проблем, главной из которых является неполное, а с моей стороны даже некорректное чтение файловой системы. Лезет не в те разделы, не видя при этом то, что надо. В итоге нарушается линковка и вы вряд ли захотите каждый раз мучаться с настройкой библиотек. Поэтому я пришёл к простому решению — поставить Mono из стандартных репозиториев через apt. Приступим.

Советую сделать перед началом всего

Обновились.
Дальше ставится Mono версии 5.9.6\

И так. Нам нужна сама программа. Мы её получили. Указываем на неё в Unity.
В Unity идём Edit->Preferences->External Tools->External Script Editor выбираем пункт monodevelop

Запускаем. Всё хорошо. Но линковщик ругается: чувак, а где .Net 3.5? И многие тут стопорятся. У mono есть так называемые mono-reference-assemblies. Нам то оно и нужно

В итоге: Unity замечательно дружит с Linux, не создавая проблем при разработке. Так же всё ПО, которое было у меня на Windows, я смог заменить аналогами на Linux Mint.

Источник

Integrated development environment (IDE) support

An integrated development environment (IDE) is a piece of computer software that provides tools and facilities to make it easier to develop other pieces of software. Unity supports the following IDEs:

Visual Studio (default IDE on Windows and macOS)

Visual Studio is installed by default when you install Unity on Windows and macOS. On Windows, you can choose to exclude it when you select which components to download and install. Visual Studio is set as the External Script Editor in Preferences (menu: Unity > Preferences > External Tools > External Script Editor). With this option enabled, Unity launches Visual Studio and uses it as the default editor for all script files.

On macOS, Unity includes Visual Studio for Mac as the C# IDE. Visual Studio Tools for Unity (VSTU) provides Unity integration for Visual Studio for Mac (VS4M). For information on setting up and using Visual Studio for Mac, see the following Microsoft documentation pages:

On Windows, Unity also includes Visual Studio 2017 Community.

Visual Studio Code (Windows, macOS, Linux)

Unity supports opening scripts in Visual Studio Code (VS Code). To open scripts in VS Code, select it as the External Script Editor in the Editor Preferences (menu: Unity > Preferences > External Tools > External Script Editor). For information on using VS Code with Unity, see Visual Studio’s documentation on Unity Development with VS Code.

Prerequisites

To use Visual Studio Code for C# code editing and Unity C# debugging support, you need to install:

JetBrains Rider (Windows, macOS, Linux)

Unity supports opening scripts in JetBrains Rider. To open scripts in Rider, select it as the External Script Editor in the Editor Preferences (menu: Unity > Preferences > External Tools > External Script Editor).

Rider is built on top of ReSharper and includes most of its features. It supports all of C# 7.2’s features as well as C# debugging on the .NET 4.6 scripting runtime in Unity. For more information, see JetBrains documentation on Rider for Unity.

Источник