Спасибо за статью, но на мой взгляд она скомканная и в плане подачи знаний сильно уступает замечательной документации от юнитеков не привнося ничего нового
Для тех кто действительно заинтересуется темой немного полезной информации:
— в первую очередь изучить офф документацию — github.com/Unity-Technologies/ml-agents/tree/master/docs
— обязательно попробовать immitation learning — blogs.unity3d.com/ru/2018/05/24/imitation-learning-in-unity-the-workflow — c его помощью мне удалось за полчаса обучить танчик поведению которого не удавалось достичь при помощи reinforcement learning за ночь обучения
— не обязательно покупать мощный комп для обучения, лучше иметь несколько слабеньких и на них обучать различные конфигурации сети
— если в ml-agents не хватает какого-то функционала, вы можете его попросить (или сделать пуллреквест) здесь — github.com/Unity-Technologies/ml-agents/pulls — проектом руководят очень отзывчивые чуваки
— есть еще курс — www.udemy.com/machine-learning-with-unity/learn/v4/overview — брал за 10 баксов. К сожалению толком изучить не успел, но на первый взгляд выглядит очень неплохо, и хорошо дополняет офф. документацию
— когда пилите агентов, не нагружайте их всякой «мусорной инфой» которая не помогает достичь им цели. Сигналов должно быть как можно меньше
— Играйтесь с зависимостями сигналов. К примеру у моего танчика был изначально сигнал «насколько пушка повернута к врагу» от -180 градусов до 180, который нормализовывался от -1 до 1. Однако танки в итоге постоянно немного мазал :) намного лучше стало когда интервал от -1… 1 стал покрывать более узкий диапазон (-10.. 10 градусов, если выходило за пределы, то к сигналу применялся clamp), получился этакий аналог оптического прицела)
— Не стоит юзать нейронки на вообще все поведения агента, что то проще и эффективнее выразить детерминированно. Делал бы я сейчас танк с нуля, я бы к пример прицеливание сделал детерминированно, а нейронке бы просто поручил задачу «на какого врага навести прицел». Мое имхо что всякая низкоуровневая лабуда должна решать классическими алгоритмами, а принятие решений лучше доверять нейронке.
По сути у вас получился Service Locator. Когда то пользовался подобным, но несколько извращенным подходом: вместо длинного dataBase писал A — application, данные сетал в статические поля и рефлексией чистил все при выходе из сцены. Получалось A.Player
И все таки есть более предпочтительные решения:
1) использование DI. Наиболее популярные github.com/modesttree/Zenject или github.com/intentor/adic. Но я бы например не стал ничего инжектить внутрь объектов которых несколько десятков на сцене, не проверив как это отразиться на перфомансе.
2) Строгая архитектура по типу «сверху-вниз». Пример — существуют GameController'ы (или Manager'ы, называйте как хочется) которые знают о игровых персонажах, и реагируют на события порождаемые ими. Каждый контроллер на старте регистрируется в службе контроллеров — это позволяет контроллерам получать доступ друг к другу через что нибудь типа Controller < TController .>
3) Сильно уменьшить связность могут помочь глобальные события. Одно из самых простейших решений которое я видел — unity3d.ru/distribution/viewtopic.php?f=13&t=24933 Я лично использую свой велосипед с блекджеком и визуализацией
Подходы можно комбинировать, у каждого есть свои плюсы и минусы. Целесообразность использования варьируется от проекта, его размера (пожалуй в первую очередь), числа программистов, факта использования плейтестов и просто личных предпочтений
Для тех кто действительно заинтересуется темой немного полезной информации:
— в первую очередь изучить офф документацию — github.com/Unity-Technologies/ml-agents/tree/master/docs
— обязательно попробовать immitation learning — blogs.unity3d.com/ru/2018/05/24/imitation-learning-in-unity-the-workflow — c его помощью мне удалось за полчаса обучить танчик поведению которого не удавалось достичь при помощи reinforcement learning за ночь обучения
— не обязательно покупать мощный комп для обучения, лучше иметь несколько слабеньких и на них обучать различные конфигурации сети
— если в ml-agents не хватает какого-то функционала, вы можете его попросить (или сделать пуллреквест) здесь — github.com/Unity-Technologies/ml-agents/pulls — проектом руководят очень отзывчивые чуваки
— есть еще курс — www.udemy.com/machine-learning-with-unity/learn/v4/overview — брал за 10 баксов. К сожалению толком изучить не успел, но на первый взгляд выглядит очень неплохо, и хорошо дополняет офф. документацию
— когда пилите агентов, не нагружайте их всякой «мусорной инфой» которая не помогает достичь им цели. Сигналов должно быть как можно меньше
— Играйтесь с зависимостями сигналов. К примеру у моего танчика был изначально сигнал «насколько пушка повернута к врагу» от -180 градусов до 180, который нормализовывался от -1 до 1. Однако танки в итоге постоянно немного мазал :) намного лучше стало когда интервал от -1… 1 стал покрывать более узкий диапазон (-10.. 10 градусов, если выходило за пределы, то к сигналу применялся clamp), получился этакий аналог оптического прицела)
— Не стоит юзать нейронки на вообще все поведения агента, что то проще и эффективнее выразить детерминированно. Делал бы я сейчас танк с нуля, я бы к пример прицеливание сделал детерминированно, а нейронке бы просто поручил задачу «на какого врага навести прицел». Мое имхо что всякая низкоуровневая лабуда должна решать классическими алгоритмами, а принятие решений лучше доверять нейронке.
И все таки есть более предпочтительные решения:
1) использование DI. Наиболее популярные github.com/modesttree/Zenject или github.com/intentor/adic. Но я бы например не стал ничего инжектить внутрь объектов которых несколько десятков на сцене, не проверив как это отразиться на перфомансе.
2) Строгая архитектура по типу «сверху-вниз». Пример — существуют GameController'ы (или Manager'ы, называйте как хочется) которые знают о игровых персонажах, и реагируют на события порождаемые ими. Каждый контроллер на старте регистрируется в службе контроллеров — это позволяет контроллерам получать доступ друг к другу через что нибудь типа Controller < TController .>
3) Сильно уменьшить связность могут помочь глобальные события. Одно из самых простейших решений которое я видел — unity3d.ru/distribution/viewtopic.php?f=13&t=24933 Я лично использую свой велосипед с блекджеком и визуализацией
Подходы можно комбинировать, у каждого есть свои плюсы и минусы. Целесообразность использования варьируется от проекта, его размера (пожалуй в первую очередь), числа программистов, факта использования плейтестов и просто личных предпочтений