Використання бібліотек у проектах на Unity3D

Не знаю, як у кого прийнято, писати все в одному проекті або хто-небудь може знає що можна класти сторонні збірки в папку Assembly (як підключаються багато плагіни), а хтось може вміє навіть і сам збирати свої бібліотеки в папку Assembly, але інформації про те хто як робить, і вже якихось рекомендацій про те, як налаштувати свій проект так, щоб можна було програмувати під Юніті так, як ніби ви пишете серйозне додаток, я не бачив.

Суть в тому, що зазвичай програма розбивається на модулі, а кожен модуль кладеться в свою окрему Збірку. Модуль або бібліотека в даному випадку не важливо, важливо що якщо вам хочеться розбити свій додаток на окремі збірки — то це в принципі досить просто зробити, хоча є і свої підводні камені. Одна з основних проблем — це те, що мій підхід не буде працювати в безкоштовній версії Юніті (вона не підтримує завантаження Збірок в рантайме), але і для такого випадку є рішення на посиланнях файлової системи, про який розповім в кінці.

Навіщо?

Навіщо розбивати свою програму на окремі модулі/бібліотеки? Можливо багатьом не треба пояснювати чим хороша угруповання коду бібліотеки, але в Юніті можна жити і без них. Навіщо роблю це я? Мені зручно використовувати одні і ті ж бібліотеки в різних своїх проектах, навіть самописні. В першу чергу навіть самописні. Кожну бібліотеку я зберігаю в своєму репозиторії і якщо в якомусь з проектів знаходжу і виправляю помилку в бібліотеці, то простим комітом, пушем і пулом з інших проектів мої фікси потрапляють у всі проекти.

Організація проекту

Бібліотеки я зазвичай використовую як подмодули (
submodule
) в репозиторії гіт. Коли починаю новий проект, то просто додаю в порожній репозиторій всі подмодули бібліотек, які я буду використовувати. Щось на зразок

git init
git submodule add my_rep/systemex.git Libraries/SystemEx


Всі бібліотеки я завжди кладу в теку
Libraries
— мені так зручно. Ви можете робити як вам зручно. Кожна бібліотека містить файл проекту з налаштуваннями за замовчуванням. Нічого там змінювати особливо не треба, крім деяких випадком. Хіба що встановити версію .net framework 3.5. А ні, ще один нюанс — у всіх референсов бібліотеки потрібно встановити проперті
Copy Local - False
. Це позбавить від майже всіх проблем і дивацтв після білду.

Далі я створюю в Юніті файли проектів для студії (я використовую visual studio, але підхід працює і для monodevelop). Юніті створює щось на зразок
имя_проекта.sln
,
имя_проекта-csharp.sln
та
Assembly-CSharp.csproj
,
Assembly-CSharp-vs.csproj
файли. Ці файли вона завжди пересотворює і їх чіпати не треба. Що треба зробити — скопіювати
имя_проекта.sln
на
имя_проекта-bundle.sln
і далі працювати вже з ним.

Після чого я створюю в порожню бібліотеку класів, яку за традицією називаю
Code
і додаю її в солюшен. Ось їй вже треба додати всі бібліотеки в референси і виставити їм
Copy Local - True
, хоча він повинен стояти за замовчуванням. Друге, що треба зробити з цією бібліотекою — задати їй
Output Path: ..\Assets\Assemblies\
— зазвичай я створюю цю бібліотек в корені проекту, тому
..\Assets\
— буде якраз тією самою папкою
Assets
з якою працює Юніті. І все, збираємо бібліотеку Code, вона викладає файли у Assets\Assemblies\, Юніті бачить ці файли і додає референси
Assembly-CSharp.csproj
. Все має працювати як годинник. Єдині мінуси — треба два рази жати білд, і навігація по коду з проекту
Assembly-CSharp.csproj
працювати не буде.

Після всього цього мій солюшен виглядає приблизно так:
image

У проекті
Code
, я пишу ігрову логіку, яку можна нишпорити між проектами. Але він не бачить безейвиоры з гри, тому може спілкуватися з ними тільки через
SendMessage


Нюанси

* У своїх бібліотеках можна використовувати UnityEngine.dll — треба лише просто додати її в референси, але їй обов'язково вимкнути
Copy Local
інакше вона піде в Assemblies і Юніті стане погано.
* У всіх бібліотек потрібно вимкнути
Copy Local
і залишити його тільки у
Code
, інакше є шанс що притягнеться щось зайве. особливо якщо ви будете розширювати редактор. В свій час я якийсь час мучився з цим, поки знайшов причину і рішення.
* Розширювати редактор можна так само, але треба викладати
Code.Editor
на
Output Path: ..\Assets\Editor\Assemblies\

* Юніті не любить і не розуміє якщо одна і та ж збірка лежить в кількох папках.
* Механізм працює тільки для платних версій. Точніше у безкоштовній з ним начебто можна працювати, але публікувати такі проекти не вийде.

Якщо хочеться безкоштовно

В такому випадку можна так само використовувати гіт і структуру репозиторію, тільки з місць доведеться руками робити лінки файлової системи папок з кодом бібліотек в папку Assemblies проекту Юніті. І не треба буде шаманити з файлами проекту, Юніті буде займатися усім сама. Щось типу
mklink /J .\Assets\Plugins\MathEx .\Libraries\MathEx\Assets\Plugins\MathEx

В даному випадку
.\Libraries\MathEx\Assets\Plugins\MathEx
папка де лежать .cs файли.

Спасибі, сподіваюся комусь мої поради стануть в нагоді. Keep your code clean.

upd: Як написав у коментах ZimM, у безкоштовної версії теж все відмінно працює. Так що магія з лінками файлової системи в загальному не потрібна. Спасибі йому за це.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.