지난 번엔 유저의 게임 정보(레벨, 경험치, 돈 등)들을 연동시켰다.
이번엔 드디어.... 유저 간의 매치 메이킹을 구현한다.

구현 방법

간단하다.

'게임 찾기'를 누르면 내 정보를 'match_waiting'이라는 데이터베이스 테이블로 전송한다. 지금부터 해당 유저('나'라고 하겠다.)는 매칭 대기열에 들어간 셈이다. 다른 유저가 접속하여 같은 방법으로 '게임 찾기'를 통해 데이터베이스에 등록되기를 기다린다.

쿼리를 한 번 더 보내 데이터베이스(대기열)에 '나' 말고 다른 유저가 대기중인지 확인한다.

없을 경우 (즉, db에 나 밖에 없을 경우) 다시 쿼리를 전송한다.

있을 경우 해당 유저의 정보를 내 게임으로 불러온 후 room을 이동한다. 당연히 대기열에서 나의 정보는 삭제한다. 상대방의 정보는 상대방이 삭제할 것이다.

성과

회원 정보들이 저장되어 있다.

매치 대기열 데이터베이스에 미리 유저 정보를 넣어 놓았다. (동시에 두 개의 테스트를 실행하려면 게임메이커 월 구독료를 지불해야 하기 때문에 임시로) 즉, qwer이라는 유저가 '게임 찾기' 버튼을 통해 대기하고 있는 상황이다.

erer이라는 계정으로 로그인했다.

'게임 찾기'를 누른다. 유저 erer도 이제 매칭 대기열에 등록된다. 데이터베이스에는 두 명의 유저가 대기중이기 때문에 (아직 mmr을 도입하지 않았으므로) 그냥 두 유저를 붙여주면 될 것이다.

매칭이 완료되고 왼쪽에는 '나'(erer)의 정보를, 오른쪽에는 상대편 qwer의 정보를 띄워준다.

어려웠던 점

딱히 없었다.

그냥 계획한대로 구현했고 예상대로 잘 됐다.

한계점

이게 문제다. 어려웠던 점이 없을만큼 쉽고 간단한 구현이고 솔직히 이걸 실제 서비스에서 사용할 수 있을지 모르겠다. 문제점을 살펴보면...

가장 고질적인 문제: 쿼리를 요청만 할 수 있다. (=서버에서 먼저 요청할 수 없다.)

이게 php를 쓰면서 가장 문제일 것이라고 예상했고 벌써 나타나기 시작한다. 클라이언트 쪽에선 계속해서 쿼리를 요청할 수 밖에 없고 이는 곧 트래픽 증가로 이어질 것이다.

서버에서 무언가 신호가 올 것 같으면(예를 들어 쪽지나 공지가 와 있는지 확인하려면) 서버에 신호를 보내야만 받을 수 있는 것이다. 이것이 실시간 움직임이 되려면 계속해서 쿼리를 보내야만 통신이 가능한 것이다. 이미 여기서부터 비효율적으로 들린다.

솔직히 이제 게임을 만들어야 하는데 가능할 지 모르겠다. 상대가 턴을 종료했는지 계속해서 쿼리로 확인한다.....? 이것 참... 유저가 많아지면 점점 느려질텐데.... php 손절 각이 슬슬 보이는 부분이다. 각오는 되어 있다. 이미 나에겐 충분히 서버 입문이라는 역할을 해주어서 고맙게 생각한다.