오늘은 하루종일 회의로 인해 새로운 지식을 습득하는데 제한이 있었다.
Today I Learned 이 아니라 Today I Did 느낌으로 간다...
서버 회의
✍ 주요안건
- 상태동기화 모델 논의
- 에러 패킷 구조 논의
- 기술 스택 논의
- 데이터 테이블 관련 논의
- 패킷별 역할 담당
📑 회의 내용
상태동기화 모델 논의
- 세가지 모델 후보 제시
- 서버 권위형 모델: 서버가 보내주는 위치값대로 클라이언트가 위치를 동기화
- 주기적인 S2C 이동패킷
- 장점:
- 확실한 위치 보장 + 완벽한 동기화
- 강력한 클라이언트 변조 대처능력
- 단점:
- 서버비용 증가 (구체적인 위치계산 모델) + 네트워크 비용 증가 (이동패킷 전송량)
- 유니티 물리엔진 내 유닛의 행동을 완벽하게 예측할 수 없음 (실제 유닛의 이동패턴과의 괴리 강요)
- 상태동기화 중심 검증형 모델: 클라이언트가 이동을 주도하되 주기적으로 서버가 위치를 검증
- 주기적인 C2S 위치알림패킷 + 오차범위를 벗어날 시 S2C 위치보정알림패킷
- 장점:
- 서버 권위형 모델보다 서버비용이 낮음
- 오차범위를 타협함으로서 대부분의 클라이언트 위조에 대처 가능
- 단점:
- 네트워크 비용 증가 (서버 권위형 모델과 동일한 수준)
- 허용 오차범위 증가 (보수적인 클라이언트 변조를 막기 힘듬)
- 이벤트 중심 검증형 모델: 클라이언트가 이동을 주도하되 유닛 이벤트가 발생할때마다 위치를 검증
- 위치관련 패킷 없음 / 이벤트 패킷에서 검증+보정을 실시
- C2S 이벤트패킷 : 유닛 좌표와 timestamp를 전송
- timestamp를 기준으로 거리를 계산한 뒤 검증 및 보정
- 장점:
- 서버비용 및 네트워크비용 최소화 (이동패킷 교환 필요 없음)
- 단점:
- 이벤트 사이에 간격이 클수록 오차범위가 커짐
- 클라이언트 변조에 대처하기가 매우 어렵다
에러 패킷 구조 논의
- 별도의 에러 패킷을 만들 것인가?
- 장점: 정상패킷 대비 에러패킷의 비율이 낮기 때문에 패킷헤더의 크기를 최소화할 수 있음
- 단점: 몰?루 왜 튜터님들은 이렇게 안한거지?
기술 스택 논의
- 이미 채택중인 기술 스택
- 추가로 채택 가능한 기술 스택 후보
- 분산 서버 ( 유저정보관리 / 게임로직 )
- logger
- BullQueue
- Docker
- Redis (아맞다 데이터테이블)
데이터 테이블 관련 논의
패킷별 역할 담당
📢 회의결과
상태동기화 모델 논의 결과
- 상태동기화 중심 검증형 모델 채택
- 게임 특성상 유닛의 이동이 상당부분 예측 가능하기에 서버주도형 모델의 비용을 감수할 필요성이 적음
- 이벤트 중심 검증형 모델을 채택하기에는 이벤트 사이의 간극이 너무 길 때의 예외상황에 대처할 방법이 없음
에러패킷 구조 논의 결과
기술스택 논의 결과
데이터 테이블 관련 논의
패킷별 역할 담당
서버-클라이언트 팀 전체 회의
✍ 주요안건
- 패킷 명세 결정
- 에셋 후보 논의
- 컨벤션 관련 논의
- 개발 환경 세팅
- 데이터테이블 관련 논의
📑 회의 내용
패킷 명세 결정
- 서버팀에서 작성한 명세서를 클라이언트 팀에게 설명 후 피드백
에셋 후보 논의
- 아트 컨셉
- 캐릭터 / 애니메이션 / UI 등 예산을 고려해 구매할 에셋 논의
컨벤션 관련 논의
개발 환경 세팅
데이터테이블 관련 논의
- 게임 데이터테이블을 어떤식으로 클라이언트에게 전달할지 논의
📢 회의결과
패킷 명세 결정
- 1차 패킷 명세서 채택 (추후 수정 및 보완 가능)
에셋 후보 논의
- 아트 컨셉 → 중세 판타지풍으로 합의
- 애니메이션: 무료애셋 Mixamo를 사용하기로 결정
- 그 외 에셋은 계속해서 논의
컨벤션 관련 논의
- 서버팀 코드/깃허브 컨벤션 확립
- 클라이언트팀도 이에 맞춰서 갈건지 따로 정할 것인지 추후 논의
개발 환경 세팅
- git 조직을 만들고 서버팀/클라이언트팀 repo를 생성
데이터테이블 관련 논의