Рад что понравилась)
Ситуация очень редкая, и программировать на неё бота — ну, это мало на что повлияет. Лучше уделить внимание тем вещам, которые бывают в каждой игре.
Не получится, т.к. лучникам можно просто выставить прироритет атаки по лучникам. Т.е. если в радиусе атаки есть и лучники и мечники, то атакуем и размениваемся с лучниками, и мечники оказываются как бы не у дел.
Все правильно, лечение обычно до 6 хп. И учитывая, что лучники дорогие, когда их много — то это того стоит.
Насчет медиков, ну вот как у меня было с Recar-ом. Допустим 2 в 2, но рядом с одним из его лучников стоит медик. Мои вообще это никак не учитывают и стреляют в того, кто рядом с медиком. В итоге его лучник выживает с 1 хп, а мой один погибает. Т.е. если бот недостаточно умный, чтобы учитывать такие вещи, то может быть очень больно.
В целом согласен насчет того, чтобы иметь не более 1 — 2 в гуще боевых действий.
Но бывают разные ситуации, например, когда бот защищается, и рабочие уже рядом, то они могут естественным образом выступать в роли медиков, тогда не сильно накладно.
1. Это для DFS, я так понимаю? У меня он в целом отнимал не так много времени. Львиная доля была за BFS.
2. Commandos вроде делал нечто подобное…
3. Это будет автолуз, т.к. слишком большое проседание по ресусрам вначале.
4. У меня было предсказание только для текущего хода. Типа если есть N рабов восле ресурсов, то скорее всего за этот тик насобираем N единиц ресурсов, следовательно для строительства можно использовать эту информацию, как будто сейчас не X а X + N, ресурсов. На более дальние дистанции уже не прогнозировал, но вообще да, есть смысл.
5. Тоже думал как-то считать окупаемость, но это очень сложно и много нюансов, а факторов может быть очень много. Так что остановился на описанной схеме. Но вообще интересно, как другие игроки это делали.
6. Мои диверсанты всегда бежали не просто к ближайшему рабочему, а к ближайшему скоплению, поэтому против моего бота это бы не сработало. А вообще, при отступлении у меня в приоритете были те клетки, которые ближе к моим войскам и турелям.
Такую стратегию не пробовал, но думал об этом. Еще можно было бы ставить мещающие стены (не достраивая их).
Тратил ооочень много времени, думаю часов по 5 в день это минимум. Ну там много времени еще уходит на прогон тестов. Бывает, хочешь попробовать несколько фич, но пока одну не протестируешь, к другой не хочется приступать.
Пробовали. У меня раненный лучник отбегает к ближайшему рабу для лечения. Лечит 1 хп за тик. А у Recar-а более продвинутое лечение, у него вроде даже медики есть на поле боя, специально бегают в паре с лучниками…
Похоже вставили не ту картинку в примере. Думаю не получилось бы, т.к. нужно всего 2 выстрела чтобы убить лучника. Если они будут ходить вместо того чтобы стрелять — то это смерти подобно.
Спасибо за статью! Но на мой взгляд в ней не хватает самого важного — результатов применения этой сети. На сколько возросла сила игры? Также неплохо было написать о том каковы были результаты на обучающей и тестовой выборке.
Я б тоже на @Validated отдавал бы только простейшие влидации, который там сейчас поддерживаются javax.validation аннотациями. А более сложные, с участием базы данных, пусть делает сервис и кидает исключение в случае чего.
1) Можно ставить значение намного меньше, но затухать обратно пропорционально расстоянию, типа value / dist, или, если нужно более медленное затухание — value / log(dist), если более резкое, то value / dist^2, тут можно играться с различными формулами и смотреть что получается.
2) Да, под каждый тип юнитов может быть свое множество потенциальных полей которые суммируются.
Например, время с лагом менее 5 минут считается одинаковым.
Ну не знаю, вроде это правило в одну строчку записывается. Наворачивать вокруг целый класс — как-то слишком, метода было бы достаточно. Если бы там реально сложная логика, на десятки / сотни строк, тогда может быть стратегии действительно были бы оправданы.
Этот тест только проверяет, что не забыли подумать про новое свойство, как раз та изначальная проблема которую вы описали, и не заставляет вводить новые сущности — а значит больше соответствует принципу KISS.
По поводу проблемы с IsEquivalent — я бы предложил решение попроще, без необходимости создавать классы стратегий. Достаточно юнит теста на рефлекшене такого вида:
в тесте имеем список имен полей не участвующих в проверках внутри IsEquivalent (ignoredByEquivalent)
пробегаемся рефлекшеном по списку полей. Для каждого поля:
если нет в списке ignoredByEquivalent, то создаем 2 одинаковых объекта для проверки, меняем в одном из них текущее поле и сравниваем при помощи IsEquivalent, если вернуло true — ошибка, т.к. данное поле должно участвовать в проверке и должно было вернуть fasle,
ведь поле именилось
Таким образом, добавляя новое поле, но забыв явно добавить его в ignoredByEquivalent теста, получим ошибку при тестировании.
Спасибо! Жаль ты в этом году не поучавствовал. Мне вот тоже интересно, можно ли было бы сделать что-то похожее на бота TouchAI с применением машинного обучения. Чтобы без групп, без ПП, а чисто управляемый хаос юнитов :)
Могу посоветовать «Искусственный интеллект, Современный подход» Стюарт Рассел и Питер Норвиг. Книга фундаментальная — большая и сложная. Сам читал выборочно.
Ситуация очень редкая, и программировать на неё бота — ну, это мало на что повлияет. Лучше уделить внимание тем вещам, которые бывают в каждой игре.
Насчет медиков, ну вот как у меня было с Recar-ом. Допустим 2 в 2, но рядом с одним из его лучников стоит медик. Мои вообще это никак не учитывают и стреляют в того, кто рядом с медиком. В итоге его лучник выживает с 1 хп, а мой один погибает. Т.е. если бот недостаточно умный, чтобы учитывать такие вещи, то может быть очень больно.
В целом согласен насчет того, чтобы иметь не более 1 — 2 в гуще боевых действий.
Но бывают разные ситуации, например, когда бот защищается, и рабочие уже рядом, то они могут естественным образом выступать в роли медиков, тогда не сильно накладно.
2. Commandos вроде делал нечто подобное…
3. Это будет автолуз, т.к. слишком большое проседание по ресусрам вначале.
4. У меня было предсказание только для текущего хода. Типа если есть N рабов восле ресурсов, то скорее всего за этот тик насобираем N единиц ресурсов, следовательно для строительства можно использовать эту информацию, как будто сейчас не X а X + N, ресурсов. На более дальние дистанции уже не прогнозировал, но вообще да, есть смысл.
5. Тоже думал как-то считать окупаемость, но это очень сложно и много нюансов, а факторов может быть очень много. Так что остановился на описанной схеме. Но вообще интересно, как другие игроки это делали.
6. Мои диверсанты всегда бежали не просто к ближайшему рабочему, а к ближайшему скоплению, поэтому против моего бота это бы не сработало. А вообще, при отступлении у меня в приоритете были те клетки, которые ближе к моим войскам и турелям.
Тратил ооочень много времени, думаю часов по 5 в день это минимум. Ну там много времени еще уходит на прогон тестов. Бывает, хочешь попробовать несколько фич, но пока одну не протестируешь, к другой не хочется приступать.
2) Да, под каждый тип юнитов может быть свое множество потенциальных полей которые суммируются.
Ну не знаю, вроде это правило в одну строчку записывается. Наворачивать вокруг целый класс — как-то слишком, метода было бы достаточно. Если бы там реально сложная логика, на десятки / сотни строк, тогда может быть стратегии действительно были бы оправданы.
Этот тест только проверяет, что не забыли подумать про новое свойство, как раз та изначальная проблема которую вы описали, и не заставляет вводить новые сущности — а значит больше соответствует принципу KISS.
ведь поле именилось
Таким образом, добавляя новое поле, но забыв явно добавить его в ignoredByEquivalent теста, получим ошибку при тестировании.
Именно так — грубо говоря «использует машины конечных состояний». Боты для компьютерных игр в основном так и пишутся.