Какие методы/библиотеки/технологии использовать в web-проекте?

Question

[hidden_pingvin]

На сервере дана небольшая карточная игра, написанная на php, без какого-либо интерфейса, использующая вместо пользователей встроенных ботов. Игра идет на выбывание, первый выбывший - победитель, последний оставшийся - проигравший. Ходят игроки по очереди, когда очередь кончается - начинается новый цикл, очередь идет заново. Каждый игрок раз в цикл делает один ход.
Боты сейчас играют между собой и клиент пока лишь может наблюдать результаты. Необходимо:
1) Заменить ботов на людей
2) И соответственно написать интерфейс
Внимание вопрос:
Используя какие методы/библиотеки/технологии можно не прерывая работы php-скрипта общаться с клиентом, собирать у него данные и использовать их для работы скрипта?
Просто сейчас скрипт выполняется непрерывно, и страница не перезагружается (т.к. если ее перезагрузить это будет уже новая игра), а с добавлением клиентов, от которых уходит запрос через AJAX такое уже не прокатит.
Пробую копать в сторону сохранения позиций игроков на поле путем сохранения объектов игры (serialize) в БД через каждый цикл и соответственно в начале следующего его разворачивая, но это уж как-то изощренно получается.

Comments

[Павел Волынцев]

Реально, без интерфейса играют. А как результаты смотришь?
Может быть ты имел в виду, что игра написана на Javascript?
А ссылку дашь посмотреть. Хотя бы приватно, по имейл вышли.

[Станислав Макаров]

Павел Волынцев ну так игра заканчивается, скрипт отвечает, вот и результаты) Бот №3 выиграл.

[Павел Волынцев]

Я бы хотел видеть хотя бы карандашный прототип интерфейса. Без этого вообще как из пушки по воробям стрелять.
Минимум, можно на HTML форму с полями ввода сделать. Как "виселица".
Максимум, использовать 3D движки и специальные контролеры типа Kinect

Answer 1

[Станислав Макаров]

> в БД через каждый цикл и соответственно в начале следующего его разворачивая, но это уж как-то изощренно получается.
Ничего изощренного в этом нет, по крайней мере если хотите это все реализовать на PHP.
Паттерн применения этого языка такой, что лучше таки давать скриптам быстро отрабатывать ценой необходимости сохранения состояния. Дополнительными плюсами автоматически идут:
масштабирование (один сервер может сохранить состояние, а уже другой - извлечь) и надежность - упавший скрипт не убьет игру.
В качестве БД советую взять Redis или Mongo, можно даже в паре, РСУБД для сохранения состояния игры будет малополезным решением, хотя будет гораздо полезнее для сохранения и обработки статистики, если таковая планируется.

Comments

[hidden_pingvin]

Большое спасибо за ответ. А почему считаете применение РСУБД менее эффективным в данном случае?

[Станислав Макаров]

hidden_pingvin а потому что врядли вы будете искать что-то внутри состояния игры. Вам состояние нужно целиком, как черный ящик, и искать вы его будете по какому-то простому ключу (id игры или id игроков + время начала игры). Для таких задача РСУБД - оверхед. Само состояние наверняка будет сложным и структурированным, и все равно вы прийдете к хранению его в какой-нибудь JSON-колонке. А тогда смысл брать РСУБД?

Вот статистика - совсем другое дело. Там будут поиски/свертки/отчеты и т.д., там пригодится.

Answer 2

[Павел Волынцев]

Общий ответ: вебсокеты и асинхронные сообщения через pub/sub
В гугле искать по фразам "socket.io rabitmq" "php rabbitmq" "php websocket" "php pub/sub"

Вариант реализации с использованием PHP
На клиентском приложении: socket.io + javascript
На сервере: socket.io + RabbitMQ + PHP

Чтобы следить за игровым процессом:
Скрипт PHP будет посылать сообщения в очередь на RabbitMQ
socket.io будет читать очередь RabbitMQ и пересылать в веб-сокеты

Клиентское приложение в браузере будет создавать постоянное соединение к сервером по протоколу веб-сокетов и читать из него всё, что пришлёт сервер socket.io. Всё, что присылается, нужно будет показывать в веб-интерфейсе.

Чтобы управлять игровым процессом
Из клиентской части веб-приложения нужно будет отправлять команды управления через AJAX или через то же соединение веб-сокет.
В случае "через AJAX" нужно будет создать серверное микро-приложение, которое будет принимать команды через AJAX и затем передавать в основной игровой процесс через RabbitMQ или иным способом.
В случае "через веб-сокет" серверная сторона socket.io должна будет отрабатывать полученные команды и передавать в основной игровой процесс через RabbitMQ или иным способом.

На сервере нужно будет периодически делать дамп состояния основного серверного игрового процесса и сохранять в какую-нибудь базу. Я бы предложил дамп хранить в формате JSON в базе NoSQL, например, Mongo, CouchDB, Redis.
При перезапуске основного серверного игрового процесса нужно будет восстанавливать состояние из этого дампа.

Игрокам нужно будет выполнять авторизацию. У нескольких игроков может быть один игровой мир или отдельный микро-мир на несколько пользователей или на отдельный сеанс игры (например, одна шахматная доска на двух игроков и несколько зрителей). Поэтому надо будет хранить данные о пользователях и мирах. Вот тут подойдёт SQL база, например, MySQL или PostgreSQL. Хотя и NoSQL тоже можно использовать.

Ну как то так.
Выглядит замысловато, а на деле реализуется очень просто.

Comments

[hidden_pingvin]

Спасибо за столь развернутый ответ. Почитал сегодня про socket.io и RabbitMQ, пока не особо понятно как это использовать, буду разбираться. Вопрос про socket.io: это ведь модуль к Node.js? Нужно поднимать еще сервер Node.js чтобы использовать эту библиотеку?

[Павел Волынцев]

hidden_pingvin: да, надо будет поставить ноду

Answer 3

[Иван]

Так один фиг AJAX, просто при запросе он должен передавать ID игры (считай комнаты) в которую хочет войти.