Комментарии 16
Не могли бы прокомментировать по поводу выбора функции оценки: «Сумма score-ов на каждом тике с затуханием на 2% в тик.»? Почему именно сумма, а не, например, оценка финального положения? Почему именно такое затухание? Пробовали ли какие-то другие варианты, и как оно было в сравнении с текущим?
Спасибо.
Примеров можно привести множество. Ну скажем, в функцию оценки включена позиция мяча по Y. но если мяч не летит на протяжении всей траектории, а скачет по полу, то больший score получила бы та траектория, где конкретно в момент финального тика мяч был выше всего. хотя возможно рядом есть траектория, где мяч вообще не касался земли, но конкретно в момент финального тика он был ниже, чем в первой.
Затухание же нужно для того, чтобы выбирались траектории, которые приводят к результату скорее всего. То есть, скажем, если есть несколько траекторий, которые заканчиваются голом, то благодаря затуханию, те, где гол случается позже, получат меньший score. Что логично, т.к. чем больше тиков до гола, тем больше у противника шансов его отбить.
Другие подходы к вычислению скора не пробовал, т.к. для меня было очевидно, что этот для моего бота сработает лучше всего. Пробовал только в качестве оптимизации считать score не каждый тик. Это значительно ухудшило результат, так что я от этого отказался.
А множитель 0.98 (т.е. затухание в 2%) подобран экспериментальным путём. Причём, изначально было 0.99, и в какой-то момент изменение на 0.98 дало приличный буст к результату.
благодаря затуханию, те, где гол случается позже, получат меньший score
Вот тут не совсем понятно. Допустим, есть две траектории, обе приводят к голу. Первая длиной 10 тиков, вторая длиной 20 тиков. Несмотря на то, что бонус за гол во второй траектории будет взят с меньшим коэффициентом, общая оценка второй траектории будет из 20 слагаемых, тогда как оценка первой траектории только из 10 слагаемых. Не получится ли так, что оценка второй траектории будет выше просто из-за большего числа слагаемых?
Вообще, интуитивно кажется, что сравнивать оценки, состоящие из разного количества слагаемых, как-то неправильно.
Какая-то языковая дискриминация, Вы не находите? Учить С++ ради победы в чемпионате — ну такое себе удовольствие. А со своим любимым языком, например, Python или JavaScript, победить практически нереально. Жаль, что организаторы не учитывают этот момент! Может стоит сделать номинации по языкам, типа как весовые категории в боксе?
Ограничение по времени нужно. Но не могут же они делать его разным для разных языков.
А для номинаций по языкам нужен гораздо больший призовой фонд, да и больше активных участников.
А как организован ввод-вывод, что бот получает и что выдаёт? И как описана вселенная игры? У вас есть точная математическая модель? Геометрия игрового поля и ворот, например, описана процедурно, или как?
Насчёт геометрии и т.д. — в этом году впервые нам в этом сильно упростили жизнь. А именно, в документации приводились конкретные функции для симуляции мира, коллизий и т.д.
Т.е. точная математическая модель была у всех, кто не поленился просто переписать этот псевдокод на свой язык.
Ну т.е. относительно точная, ибо игровой мир был недетерминирован. Т.е. в некоторые действия был включён рандом в указанном диапазоне.
Бонус за гол несравнимо выше, чем любой другой бонус. Скажем, это видно на 2:30 в видео из визуализатора. На его фоне бонусы за всё остальное не имеют особого значения.
Я это проверял и экспериментально — пробовал не прерывать траекторию в случае гола и также пробовал досчитывать траекторию до конца по тикам, но «фиксировать» мяч в точке гола.
Оба варианта ничего не дали, так что я вернулся к первоначальному.
Russian AI Cup 2018, история 9 места