Три месяца назад я уже создавал на этом форуме тему с "игрой для программистов". К сожалению, проект оказался мертворожденным, потому что огромное количество багов не позволило даже немногим желающим написать хоть какой-то AI.
Что ж, мною была проведена работа над ошибками, я учел те немногие замечания, что все-таки были, и вот на свет появилась UFOs.
Жанр: стрелялка/игра для программистов Количество игроков: 2 Платформа: клиент на C#, поддерживает плагины на C#, Delphi и LUA Версия: бета
Итак, суть крайне проста: есть квадратная комната, есть два диска, которыми могут управлять игроки. Все управление сводится к двум вещам:
1. Задать вектор ускорения
2. Выстрелить в определенном направлении
Игрокам доступны данные о координатах и скорости собственного диска, координатах диска противника, а также положение и скорость всех "пуль" в игре. Все предельно просто. Тем не менее, как показал мой собственный опыт, чтобы написать что-то мало-мальски приличное, приходится подключать знания аналитической геометрии и курса физики в разделе механика, что в целом уже неплохо).
В игре четыре режима:
1. движение к мишени - задача точно наехать на мишень и задержаться там на определенное время
2. стрельба по неподвижным мишеням
3. стрельба по подвижным мишеням
4. собственно бой двух дисков
В нем уже реализован вшитый AI, который демонстрирует все режимы игры.
Для C# и Delphi я создал что-то вроде шаблонов - проектов, которые максимально упрощают разработку AI. Их затем как плагины можно подключать к клиенту и смотреть, как все работает. Шаблон для C# Шаблон для Delphi
Также в исходном проекте в папке plugins лежит шаблон для LUA. В качестве бонуса в той же папке лежит простенький пример AI, написанный на этом воистину чудо-языке. Называется my_test.lua.
В общем, неплохой способ немного познакомиться с просто отличным языком!
Вот, собственно, и все. Если вдруг кого заинтересует или возникнут вопросы - welcome!
Своего бота еще не написал, ибо это же надо вспомнить физику, геометрию :D
Неплохо было бы ограничить время выполнения функций в дллках и скриптах, чтобы приложение не висло, если в дллке напишу while true do sleep(1); А я ведь напишу, если жизни начнут кончаться :D
. Наверное их лучше выполнять в отдельном потоке, с прибитием его по времени и перехватом исключений.
Далее, в дллке я использую глобальные переменные, для сохранения каких то нужных данных. Если запустить мою дллку против себя же, то эти глобальные переменные будут общими -> начнутся глюки в логике бота. Лучше если каждую дллку перед загрузкой переименовывать, тогда переменные будут у каждого свои.
Лучше ограничить бои по времени, засчитывая техническую победу или ничью в зависимости от жизней ботов.
Мне кажется, в игре выигрывает тот, который лучше математику знает. Сделать нормальный выстрел с упреждением нетривиальная задача, но она решается не так сложно, впрочем без навыков высшей математики сложность возрастает. А лучше такого выстрела ничего не придумаешь в плане нападения. В плане защиты, уклонения от пуль, тоже задача решается и способов решения немного по моему. Другое дело, если раундов несколько(штук 10) и в каждом раунде параметры арены меняются; кулдаун пуль, эластичность стенок, акселерация и прочие. Написать бот который будет при разных условиях работать это интересно, но впрочем тоже представляет собой конечную математическую задачу у которой немного решений). Хотя, может я забегаю далеко вперед и для большинства хотя бы простейшего бота написать составляет некоторую трудность)
Развитие этой игры мне видится в увеличении арены, увеличением количества дисков в каждой команде, в течении времени каждый диск накапливает очки эволюции которые тратит на увеличение своих параметров. Например, в одной команде один диск будет наращивать свои жизни и ловить все пули, другие же будут прятатся за его спиной, отстреливаться и лечить его. Т.е. диски смогут исполнять различные роли. Можно предусмотреть размножение дисков) Увеличение количества команд. Далее контроль над областью, захват флага, etc... замечтался :D
Молодец, эта идея мне кажется удачнее чем противостояние 2х войск в прошлой, мне нравится и своего бота-нагибатора я в скором времени напишу).
CoderInTank
Спасибо за участие и отзыв!
Сейчас постараюсь ответить:
1. Ограничить время выполнения надо. Если ИИ думает слишком долго, то проигрывает. У меня это было в планах, но что-то я забыл это реализовать. Доделаю в следующей версии.
2. Глобальные переменные одной dll никак не будут видны другой dll. Каждая dll, насколько я понимаю, работает в своем выделенном адресном пространстве. В случае с LUA там используется довольно хитрый механизм извлечения данных из глобальной таблицы по guid игрока.
3. Насчет математики и физики - да, все именно так. Но ведь это еще надо закодить. И заоптимизировать, чтобы выполнялось быстрее.
4. Предложения по развитию все довольно интересные, но тут главный вопрос в том, насколько будет интересна людям исходная задача. Потому что усложнение исходной задачи ведет в целом к увеличению порога вхождения.
Перед тем, как писать собственного бота, советую посмотреть файл my_test.lua. Он сейчас в части боя полностью реализует мой вшитый ИИ.
Я бы предложил иметь возможность тратить энергию. Или на выстрел или на щит. Тогда можно было бы тактику разнообразить значительно. А энергию восстанавливать во времени.
2. Глобальные переменные одной dll никак не будут видны другой dll. Каждая dll, насколько я понимаю, работает в своем выделенном адресном пространстве. В случае с LUA там используется довольно хитрый механизм извлечения данных из глобальной таблицы по guid игрока.
В случае разных dll так и есть, но если dll одна и та же(бот против себя же), то при повторной её загрузке, просто увеличится счетчик ссылок на нее, адресное пространство останется тем же.