Я заинтересован в участии в конкурсе по программированию, в котором люди пишут ботов на любом языке, который они предпочитают конкурировать в обычных играх против компьютера (и, в конце концов, друг против друга, но это на потом). Идея состоит в том, что боты будут делать вызов RESTful API с их ходом и получать ответ с ходом компьютера и состоянием доски, пока игра не закончится.
Вот подвох: я не Я не хочу размещать свой собственный сервер для обработки этих запросов, потому что это головная боль, связанная с балансировкой нагрузки, и потому, что в случае, если это стало популярным, у меня нет средств для размещения сервера высокой доступности на многих узлах.
Если предположить, что стратегия компьютера может вписаться в минимизированный файл JavaScript разумного размера, что вполне вероятно для такой игры, как, скажем, Манкала , это было бы невероятно проще. и значительно быстрее, если программа пользователя может взаимодействовать с веб-страницей, которая может получать и отвечать на простые вызовы локального API при открытии на своей машине. Это может быть логически невозможно, но я чувствую, что должно быть возможным.
Чтобы уточнить, давайте возьмем пример с Манкалой. Существует согласованный синтаксис для вызовов RESTful, который в данном случае представляет собой просто число от 1 до 6. Игра отслеживает состояние доски, делает ход и отвечает новой доской - 14- целочисленный массив - и, для целей пользователя, какой бин он выбрал, когда сделал свой ход. До бесконечности.
Допустим, пользователь написал бота в Python 3 - SuzysMancalaBot.py - для выбора своих ходов в зависимости от состояния доски. С моей стороны, довольно простой бот средней сложности может поместиться в mancala.min.js, загружаемом браузером, когда вы посещаете страницу игры. Здесь нет денег на карту, поэтому доставка бот-компьютера в миниатюрном JS не проблема. Игра достаточно сложна, так что предварительные вычисления каждого состояния и создание API-интерфейса c нереалистичны c.
Очевидное решение состоит в том, чтобы разместить сервер Express в EC2 или где-то, что после пользователь создает идентификатор, будет отвечать на любое количество вызовов от Python (или Ruby, или Node, или что-у-вас) следующим ходом. Поскольку в идеале Сьюзи хотела бы протестировать своего бота во многих испытаниях, даже один пользователь генерировал бы тысячи вызовов и был бы ограничен задержкой ответа.
Если бы бот Python мог каким-то образом сделать вызов Локальный экземпляр страницы, который содержит всю логику c и необходимую память для симуляции игры, будет намного НАМНОГО быстрее и создаст НАМНОГО меньше накладных расходов и затрат для меня. Это разочаровывает: все необходимые вычисления находятся прямо на клиенте, но как Python может общаться с Chrome? (Я не против ограничиться Chrome.)
Я вижу, что есть плагин Chrome для раскрутки локальных хостов . Хотя было бы замечательно иметь решение, не требующее его, я бы смог написать плагин. Хотя я думаю, что это потребует от пользователя загрузки всей серверной среды для игры и раскрутки сервера, а это больше работы, чем я бы предпочел.
Кажется, что цель здесь возможно выполнимо: пользователь заходит на мой сайт, запускает новую игру с уникальным локальным идентификатором, а затем его бот взаимодействует со страницей для игры. Браузер действует как сервер, отслеживая состояние игры и реагируя на каждое движение следующим. Все, что мне нужно, это выяснить, как заставить браузер слушать и разговаривать.
Единственное альтернативное решение, о котором я могу подумать, - это то, что пользователь загружает свой код клиенту, а не мне. - и сама страница выполняет игру. (Это не межсайтовый скриптинг, если он никогда не пересекает сайты, и у него мало стимулов для взлома!) Я полагаю, что для этого потребуется перенести каждый язык на JS, если только у веб-страницы нет способа запустить Python (и Ruby и Rust et al. c et c). Я никогда не пытался загрузить страницу локально JS - это может стать кошмаром безопасности. Я не знаю.
Последнее решение, которое я могу придумать, состоит в том, что пользователь должен развернуть localhost и ввести конечную точку на страницу, которая затем обращается к локальному хосту для воспроизведения. Опять же, это больше работы, чем я бы предпочел для пользователя, и это может быть кошмаром CORS - у меня никогда не было возможности проверить, как работает AJAX вызовы при взаимодействии с локальным хостом, что, вероятно, потребуется обслуживаться через SSL, так как сайт.
Надеюсь, я хотя бы достаточно подробно описал дилемму. Это интересный вопрос распределенной обработки, если ничего больше.