Коннект 2 игроков для онлайн игры

[Paul Ololo]

Всем привет!

Столкнулся с проблемой коннекта 2 игроков для онлайн игры.

На PHP написан обработчик, с помощью которого я (по нажатию кнопки "играть") GET-ом записываю в БД id пользователя и его уровень. Дальше, тем же GET-ом, с помощью того же обработчика, я пытаюсь получить id пользователя, который мне по уровню подходит. Если такой игрок получен, то я отправляю запрос на удаление из таблицы и первого, и второго игрока.

Проблема: бывает ситуация, когда несколько пользователей получают одного и того же противника (то есть: я нашел игрока - отправил запрос на удаление, но в этот момент его нашел кто-то еще...).

Если есть идеи как модифицировать мой алгоритм коннекта или как правильно сделать новый, подскажите плз.

Заранее благодарен.

[-De-]

Транзакции

[Paul Ololo]

Можно подробнее?

[-De-]

Гуглить (думаю можно и в яндексе) слово "транзакции". Получить общее представление, что это такое. Потом гуглить транзакции для вашей БД, примеры.

[DaFive]

А зачем тут транзакции? Кажись проблема не в этом. Скорее php-обработчик косячит, выбирая то, что не должен.

[Genzo]

Дальше, тем же GET-ом, с помощью того же обработчика, я пытаюсь получить id пользователя, который мне по уровню подходит. Если такой игрок получен, то я отправляю запрос на удаление из таблицы и первого, и второго игрока.

Т.е. вы 2 запроса посылаете, что в корне не верно, удаляйте их в момент нахождения или ставьте им статус найдены и т.п., вообще не особо правильная структура сервера...

[Tr1te]

Решил след образом: сначала кидаешь в комнату гранату, потом смотришь кто был в комнате.

Например мне нужно найти пару в тонне пользователей. Есть БД с именем ждущего пользователя и пустое поле для напарника. Второй отправляет гет, а пхп в этот момент не глядя добавляет второго пользователя в то пустое поле ждущего. Прямо сразу Апдейт (SQL) где второе поле = null. И только потом смотришь добавил ли ты вообще, если добавил, то клиенту возвращаешь того кто был в первой графе той строки куда добавил. Если не добавил, когда все строки были заняты, или их вообще не было создано, то после отрицательного ответа от базы, добавляешь себя как ждущего, себя пишешь в первую графу, а вторая остается пустая, и ждешь пока кто нить себя не впишет во вторую графу.

Если в одно мгновение два пользователя попытаются изменить строку, то например SQL не сможет нарушить записи и добавить в пустое поле сначала одного потом второго, конечно же это зависит от типа таблицы.

Ну главное общий принцип описал, реальная система конечно же сложней, но ты разберешься. И это работает быстрей чем транзакции, ибо они уже есть в SQL, так что можно пользоваться именно ими.

PS: А что за игра, жанр, геймплей?

[Paul Ololo]

Т.е. вы 2 запроса посылаете, что в корне не верно, удаляйте их в момент нахождения или ставьте им статус найдены и т.п., вообще не особо правильная структура сервера...

Если не сложно, напиши плз правильную структуру, на твой взгляд.

[Genzo]

Есть таблица Games в ней поля (id ,player1_id , player2_id , start_time , finish_time и т.п.), игрок 1 вызывает метод startGame , добавляется запись с проверкой того, что у этого игрока нету уже записи где он играет. Получается (id , player1_id , null , null , null), это и есть игра которая еще не началась, первый игрок периодически посылает запрос checkGameStatus(id) и получает start = false, потом второй игрок посылает запрос joinGame(id) , ставится запись (id , player1_id , player2_ID , now() , null) - finish_time = null - означает, что игра еще не закончилась, ну и первый игрок на checkGameStatus(id) ,получает start = true;

Это что-то вроде эмуляции socket сервера получается, только с периодическими запросами статусов

[Paul Ololo]

удаляйте их в момент нахождения

Сделал так. Роботает гораздо лучше, но баги такой же природы проскакивают.
Нагуглил MySQL write lock. Кто знает как им пользоваться?