Комментарии 6
Картинка к посту по-моему и есть иллюстрация выстрела в ногу
Иначе при большом количестве персонажей мы можем поймать ошибку, что в момент перебора массива извне из него будут добавляться или удаляться элементы.
public class Repository<T>
{
public IEnumerable<T> Items => _items.Values;
private readonly Dictionary<Guid, T> _items = new();
public void Register(Guid id, T item) =>
_items.Add(id, item);
public void Unregister(Guid id) =>
_items.Remove(id);
public void ForEach(Action<T> action)
{
foreach (T item in _items.Values.ToArray())
action(item);
}
}Это костыль. Он жрет ресурсы, причем в часто вызываемом методе. Хотя у вас там Guid, он еще и памяти сожрет ибо ValueType. Как бы тоже решение, просто неоптимальное.
Если объектов будет, например - лям, то там 16*10^6 байт памяти под одни ток гуидники будет выделятся на каждом апдейте, вроде как. 15,25.. Мбайт памяти вроде как. Эт будет, допустим 60fps - по гигу памяти в секунду? Сборщик мусора повесится) у меня походу профдеформация после bigdata)
Лучше делать отдельный механизм для удаления элементов, и не давать трогать _items. Обычно я делаю список на удаление и удаляю по списку сразу после цикла. У вас наружу еще и Items торчит, так что может возникнуть трабл с перечислением снаружи. В зависимости от требований к многопоточности - разные решения.
Гугльнул, пишут мол делать проверку на энумерации if(x){remove} но эт лишняя комманда в цикле, не оч хорошо. Хотя мб для многопоточности - норм, но мне чот семафоров хочется и блокировок)
По большому счёту все юниты должны быть набором систем из которых конструируются эти юниты, а не как у автора - класс с набором пропертей и все проверки по идее должны происходить для всех юнитов, а не для каждого по отдельности. Тогда оно и в памяти лежать будет лучше и процессору в кэшлинию попадать предсказуемо станут. То бишь пилить всё это надо было или на Unity Jobs или на DOTS, чтобы действительно считать это нормальной интеграцией с Unity.
Да у автора вообще много жести, прост мне за код ревью и наставничество в интернетах не платят)
Например Resources.Load<Character>("Character") эт жоский хардкод, прям вообще мрак.
Монобихавор для чарактера - это вообще божественный объект, без разделения ответственности.
А по самой статье - код вообще не в тему, автор прочитал про r-b ai и решил натянуть сову на глобус. В итоге вместо аи - тут что-то типа клона компонентного подхода из юнити натянутый на типа r-b ai, хотя это даже не близко.
Хотябы это: public bool CanExecute => !_context.HasEnemy;
Оно тут воткнуто просто потому что типа должен быть предикат CanExecute, чонить да воткнем. Какой в этом вообще смысл - никакого, просто натянуть чонить на паттерн.
В итоге статья - никакущая, код вообще никак не про r-b ai, даже не близко. Тут самописный компонентный подход аля юнити просто потому что в юнити так и мы тож этот паттерн будем втыкать на верхнем уровне архитектуры просто потому что. И обзовем это аи, воткнем интерфейс не в тему. И вуаля, читайте - набирайтесь мудрости, дорогие мои.
Меня эт не особо удивляет уже, каждую неделю натыкаюсь на "делаем * на юнити!" и какая-то жесть внутри) так то не вижу ничего особо плохого в этом - ресурс же социальный. Просто иронично, что несведущий пишет обучающие статьи) Но этакая форма рефлексии, почему бы и нет. Я иногда таким занимаюсь, по пути написания - углубляюсь в тему, конспектирую, провожу анализ. Но это скорее как научно исследовательская работа.
С точки зрения обучения - чел молодец, намутил ргз. Только вот я бы поставил неуд. наверное, если бы он не смог защитить. Беда в том, что на хабре все вперемешку, уровень и направление статей оч сильно разница. Но такую живую статью мне лично в 1000 раз интереснее читать чем очередной выблев копирастов и маркетологов, коего здесь 95% вперемешку с новостями и техническими статьями. А от этого пережевывания, особенно про генеративные сети - тошнит уже.
Имхо это встраивание некой универсальной конструкции - выстрел себе в ногу. Применение паттернов ради паттернов. Это в рил прожектах потом ад. Возьмут какогонить аутсорсера, и он понапишет весь код через какой нибудь цепочка обязанностей и потом с ума сходишь. Тру стори.
Причем, почему то Die : IRule Хотя это не к аи относится, а к внутриигровой логике. В итоге все смешалось в кучу - люди, кони. Началась грызня.
Кстати:
Владелец видео запретил его просмотр на других сайтах.
Причём тут Rule-based? Это просто самописная компонентая модель, к тому же медленная и неоптимальная, с единственной разницей, что обновляется один компонент (Rule) за тик. Можно переименовать это в Action/Decision/Behaviour/Component-based AI и смысл вообще никак не изменится. По запросу Rule-based выдаёт множество статей про machine learning, по играм инфы мало, а если и есть, то там совсем про другое. Тут либо что-то недопоняли и переврали, либо придумали что-то своё, но дали этому название вводящие в заблуждение, так ещё и с реализацией накосячили.
Rule-based AI + Unity