길드 시스템 기획서 2편: 통신 방식(Socket)과 길드 직급, 권한 테이블 설계
안녕하세요. 호랭이 물어갈 기획놈들입니다. 지난 프롤로그에서 길드 시스템을 도대체 왜 만들어야 하는지, 그 거대한 의도에 대해 다루어 보았습니다. 오늘은 기획서의 본편으로 들어가, 길드 시스템을 게임 속에 실제로 구현하기 위한 가장 뼈대가 되는 기술적, 구조적 설계에 대해 이야기해 보겠습니다. 지난 시간에 길드를 '왜' 만드는지, 그 역할에 대해 진지하게 고민해 보았습니다. 결론적으로 길드는 게임 내의 '작은 사회'입니다. 이 사회가 삐그덕거리지 않고 원활하게 돌아가려면 명확한 시스템(규칙)이 필요합니다. 우선 이 작은 사회를 어떠한 방식으로 설계하고 만들지(서버 타입을 웹 방식으로 할지 소켓으로 할지) 생각하고 그 다음으로 '작은 사회'라고 했는데 이때 구성원은 어떻게 나눠야 할지 마지막으로 그렇게 나눈 구성원의 권한은 어떻게 되는지 알아보겠습니다. 1. 퀄리티를 가르는 보이지 않는 손: 웹(Web) vs 소켓(Socket) 길드 시스템 기획에 들어가기 앞서, 기획자가 개발팀과 가장 먼저 합의해야 할 중대한 사안이 바로 '서버 동기화 방식'입니다. 이 선택이 우리가 아는 '진짜 살아 숨 쉬는 길드'를 만들지, 아니면 '껍데기만 길드인 웹 게시판'을 만들지를 결정합니다. 그럼 간략하게 웹 방식과 소켓 방식에 대해 이야기 드리겠습니다. <그림 1. 추방을 당했지만 추방 당한 줄 모르는 유저> 웹(Web) 방식 (비동기화) 흔히 네이버 카페나 게시판을 생각하시면 됩니다. 클라이언트가 서버에 패킷(요청)을 쏠 때만 데이터를 받아옵니다. 만약 이 방식으로 길드를 만들면 치명적인 UX 붕괴가 발생합니다. 길드장 또는 부길드장이 나를 길드에서 강퇴시켰더라도, 내가 화면을 새로고침하거나 재접속하기 전까지는 내 화면에 여전히 길드원으로 나오는 '유령 상태'가 유지됩니다. 강퇴당한 줄도 모르고 길드 채팅을 치는 대참사가 벌어지는 것이죠. 더 슬픈 ...