3 главных ошибки тех, кто пишет библиотеки для Unity
⁃ Забить на Package Manager.
⁃ Забить на Тесты.
⁃ Забить на Теги для контроля версий.
Обозначить ошибки неинтересно, а вот как их избежать? Обычно я рекомендую:
1. Использовать
Package Manager. Профессионалы всегда предпочтут просто жмакнуть на плюсик в Package Manager и вбить ссылку для установки.
Вряд ли кому-то захочется качать вашу репу, открывать это с помощью Unity и вычленять оттуда нужный код. GitHub с вашей библиотекой сразу же закроют, когда увидят папку Assets или, не дай бог, ProjectSettings.
2. Написать
юнит-тесты. Вам самим же будет трудно вносить изменения и дальше развивать свою библиотеку, когда не понятно, отвалится ли что-то после изменения кода. Папка Tests - это главный детектор качества. Без них профессионал сильно задумается, прежде чем брать вашу библиотеку себе в проект.
3. Использовать
теги. Допустим, на проект пришёл Вова и качает репозиторий. Вова говорит, что у него ничего не работает, а у остальной команды всё норм. Что произошло? Правильно - вы выкатили обновление с ломающими изменениями. У Вовы скачалась обновлённая версия, а у остальной команды старая. Вам строчат гневные письма в Issues, чтобы вы наконец начали использовать теги.
Собрал несколько примеров хороших библиотек:
https://github.com/forcepusher/com.bananaparty.websocketclient
https://github.com/forcepusher/com.agava.yandexgames
https://github.com/forcepusher/com.agava.webutility
https://github.com/forcepusher/com.agava.yandexmetrica
Но там в основном процедурка, а не ООП, потому что это
WebGL плагины - они заставляют работать со статикой.
Если хочется поковыряться в чистом ООП-коде, вам в эту незавершённую библиотеку:
https://github.com/forcepusher/com.bananaparty.behaviortree
P.S. Чтобы удобно ревьюшить код в гитхабе, можно вставить vscode.dev/ после https:// например, вот так:
https://vscode.dev/github.com/forcepusher/com.bananaparty.behaviortree
