전반적인 정리

• 통신: WebSocket(Stomp.js + Redis를 이용하여 실시간 통신)

• 게임 데이터: 실제 사용하는 데 필요한 정보들

  • 초기 보드판과 정답
  • 조력자가 선택한 숫자
  • 허수아비가 고른 숫자판과 기호
  • 위의 숫자판과 기호로 만든 답
  • 정답인지 아닌지

• 게임 로그: 액션만 저장

  • 사자가 숫자판 or 리셋 버튼을 눌렀을 때 저장
  • 조력자가 숫자판을 선택, 선택 해제하였을 때 저장

• 가장 중시하였던 것: 최소한으로 DB를 접근하여 관리를 해 보자

  —> 여기에서 GameManager의 역할이 커진다

사칙연산 게임에서 GameManager란

• 내가 생각한 구상도
  • 전체적으로 Back에서 실시간으로 가지고 있는 정보들
    • 각 스테이지에 맞는 컨트롤러
    • 더 들어가서 스테이지마다 현재 플레이하고 있는 게임들(예시: 크레이지 아케이드와 같은 방을 만들어서 진행하는 게임에서 같은 시간대에 여러 게임이 동시에 진행됨)
    • 진행되고 있는 게임마다 필요한 정보들(예시: 크아와 같은 경우 맵, 어떤 사용자가 어떤 캐릭터를 들고 들어갔는지 등) → 사칙연산의 경우 초기 보드판, 사용자의 역할, 라운드 정보, 게임 정보 등 DB 저장에 필요한 대부분의 모든 정보와 프론트에 뿌려 줘야 하는 정보를 매니저가 들고 있는다

• Motive: Narang(마피아 게임 & 양세찬 게임)

  • 차이점
    • Narang은 db를 사용하지 않아 저장되는 정보들이 없고 휘발성 데이터이다
    • Narang은 역할이 비공개 or 사람마다 가지고 있는 제시어가 달라 이 부분을 각 사람마다 map이나 Player라는 객체를 통해 역할을 부여해 주고 보여 주었는데, 우리는 역할이 정해져 있어 프론트에서 제어해도 됐다
  • 공통점
    • 우리는 DB가 있음에도 게임 매니저가 플레이 시작할 때 모든 정보를 만들고 시작해서 끝날 때 날리는 건 동일하다

• 사용법

  • Controller에 Service가 아닌 Manager를 선언해 두고 init으로 초기화시킨다

  private static Map<Integer, GameManager> gameManagerMap;
  

  • Manager는 Map으로 관리하며 키값은 roundId로 설정한다
    • roundId로 설정한 이유: 초기에 redis가 연결되지 않아 session ID를 받아오기 요원했으며 같은 회차를 진행하는 팀 중 중복으로 게임을 진행할 팀이 없기 때문에 round ID도 세션 아이디와 똑같이 유일할 것이라고 생각했음(나랑은 세션 아이디로 받아옴)
    • redis 전이라 roundId를 직접 프론트에서 넣어 줘야 했다 → 현재는 레디스가 들고 있는 걸 받아 올 수 있어 가능하면 리팩토링해야 함
    • 키값을 통해 접근하면 그 게임에 대한 정보를 가져올 수 있음
  • map.get(roundId).함수를 사용해서 진행했다
  • 게임 시작이 되었을 때와 필요한 정보를 저장해야 할 때마다 게임 매니저 안의 변수들을 초기화시키거나 저장시켰다 → 추후 코드 보면서 설명

• GameManager를 통해 DB를 건들지 않고 받아 올 수 있었던 것

  • 게임 진행 중 필요한 보드판
    • 사칙연산의 DB는 전부 String 형태로 저장된다 → DB를 통해 받아 왔다면 매번 String을 전처리해 맞는 보드판으로 바꾸어 보내 주어야 했음
    • 초기 보드판 int[][]의 보드, 프론트가 필요했던 보드판 char[][] 형태의 전체 영어인 보드판, String[][] 형태의 조력자가 선택한 부분만 숫자고 나머지는 영어인 보드판 → String인 이유는 char로는 10, 11, 12인 두 자리 수 전송이 어려움
  • 조력자가 선택한 칸에 대한 정보
    • 선택한 영어를 받아 오면 그에 맞는 좌표값을 전송해 줌
      • 이를 위하여 초기 보드판이 만들어질 때 Map 형태로 각 영어가 가지고 있는 좌표 r, c, 그리고 value값을 저장해 두어야 함
    • 선택했는지 안 했는지 돌려 주기
  • 허수아비가 누르는 숫자들에 대한 정보

• 매니저에서 DB에 저장되는 순간

  • 게임 데이터
    • 처음 게임이 시작되었을 때 게임에 맞는 보드판과 정답을 설정한 후 DB에 저장(보드는 스트링화)
    • 중간 조력자가 모든 숫자를 선택하였을 때 숫자판을 받아 DB에 스트링화하여 저장
    • 허수아비가 정답을 입력하였을 때 정답의 유무, 고른 숫자판의 좌표, 기호, 만들어진 정답에 맞추어 저장된다
  • 로그 데이터
    • 각 숫자판을 선택, 선택 해제하였을 때 조력자 액션 로그로 userId와 함께 저장한다
    • 허수아비는 숫자판을 선택하거나 리셋 버튼을 눌렀을 때 허수아비 액션 로그로 userId와 함께 저장한다

• 리팩토링이 필요한 부분

  • redis로 연결된 후 roundID도 받아 올 수 있다 대신 userId를 통해 받아 와야 하기 때문에 모든 request dto를 수정해 주어야 함
  • 조력자 액션 로그의 경우 같은 request, response, 함수가 두 개 수행됨
    • 마지막에 영상 & 다른 부분을 진행하느라 직접 하지 않아 리뷰가 되지 않았다
    • 예를 들어 a를 받았을 때 선택한 영어만 줬다면 이제는 r, c 값을 줘야 함
  • 프론트와 DB의 데이터 처리가 전혀 다르기 때문에(Front는 대부분 2차원 배열, DB는 대부분 r, c값으로 이루어진 스트링) 코드가 많이 더럽다 고쳐야 함!