разбить данные и методы и собрать их так, чтоб можно было легко использовать с декларативным подходом Vue
Я так понимаю, что Вы говорите о том, чтобы вынести методы is_availible и do_action в methods, сделав их унифицированными, верно?
Дело в том, что объекты, в действительности, немного сложнее. Каждый объект - это единица оборудования в системе планово предупредительного ремонта. И условие отображения каждого объекта немного сложнее, чем я указал ранее. Например метод is_availible одного объекта вернет true если подошел срок обслуживания (сравнит значение поля с датой последнего обслуживания), тогда как другой объект содержит информацию о наработке мотор часов и необходимых расходниках, и не отображается если чего-то нет в наличии (метод is_availible этого объекта сравнивает уже другие поля объекта). Как аналогию могу привести, что каждый метод is_availible каждого объекта реализует доступность какого-либо действия для персонажа игры (например действие do_action объекта с name:"лечиться" доступно если в инвентаре есть бутылочка, а действие do_action объекта "скрафтить что-нибудь" доступно если есть нужный предмет и навык крафта прокачан до указанного уровня).
Отсюда вопрос: какую информацию должен содержать объект вместо методов? Как быть если один объект сравнивает (условие1)
другой ((условие1)&&(условие2))
а трутий ((условие1)||((условие2)&&(условие3)))
Каждый объект содержит свой метод is_availible только потому, что я не нашел решения как его унифицировать. То же и с методом do_action.
В принципе состояние системы и есть набор состояний клеток доски, которые, в свою очередь, и есть массив из восьми нулей и единиц (восемь направлений), отражающих возможность хода. Дополнительно подал состояние текущей клетки, в которой находится агент (подумал что это поможет ему понять где он сейчас находится). Не помогло.
Добавил на вход агенту координаты x и y, нормализованные в диапазоне от 0 до 1. Тоже не помогло, агент гуляет по всему полю, даже не пытаясь брать курс на цель, периодически случайно попадая в ворота.
Так же неуспешной оказалась попытка подавать на вход состояние не всей доски, а только ближайшего окружения в радиусе 3х клеток (я подумал, что лишняя информация сбивает агента с курса).
Я так понимаю, что Вы говорите о том, чтобы вынести методы is_availible и do_action в methods, сделав их унифицированными, верно?
Дело в том, что объекты, в действительности, немного сложнее. Каждый объект - это единица оборудования в системе планово предупредительного ремонта. И условие отображения каждого объекта немного сложнее, чем я указал ранее. Например метод is_availible одного объекта вернет true если подошел срок обслуживания (сравнит значение поля с датой последнего обслуживания), тогда как другой объект содержит информацию о наработке мотор часов и необходимых расходниках, и не отображается если чего-то нет в наличии (метод is_availible этого объекта сравнивает уже другие поля объекта). Как аналогию могу привести, что каждый метод is_availible каждого объекта реализует доступность какого-либо действия для персонажа игры (например действие do_action объекта с name:"лечиться" доступно если в инвентаре есть бутылочка, а действие do_action объекта "скрафтить что-нибудь" доступно если есть нужный предмет и навык крафта прокачан до указанного уровня).
Отсюда вопрос: какую информацию должен содержать объект вместо методов? Как быть если один объект сравнивает
(условие1)другой
((условие1)&&(условие2))а трутий
((условие1)||((условие2)&&(условие3)))Каждый объект содержит свой метод is_availible только потому, что я не нашел решения как его унифицировать. То же и с методом do_action.