13조의 금요일

Team

👣 개인과제

윤형석
정윤제
손창환
김동규
김나린

1. 프로젝트

프로젝트 명 : 타워 디펜스 온라인 게임
소개
- 한 줄 정리 : 이전에 만들었던 타워 디펜스 게임을 멀티플레이어 게임으로 만들어보자!
- 내용 : 한 줄 정리 내용이 곧 내용

2. 기획 관련 메모

3. WBS & Tasks

윤형석
정윤제
손창환
김동규
김나린

필수 구현 사항 진행률
선택 구현 사항 진행률

🏝️ Ground Rules

09:00~10:00 코드카타
10:30~      게임서버반 분반강의
12:00~13:00 점심시간
13:00~18:00 작업시간
18:00~19:00 저녁시간

🚩 Goals

웹소켓 방식으로 게임 서버를 구현하고, 후에 PROTOBUF방식을 이용하여 데이터를 주고 받는다.

🕑 회의

***일간 회의 : 20:00**
간단한 통지나 수정 사항은 수시로 디스코드에 글로 작성
글로 설명하기 어려운 내용은 20:00~21:00 정기 회의에서 말한다.

🚦 Project Rules

개발환경

Code Convention

Github Rules

KPT 회고

🌞 계획표

요일 별 상시 업무 [D-5]

📢 SA 서면피드백

**조호영 튜터님 피드백**

- Github에서 생긴 지 얼마 안 된 프로젝트 기능을 이슈와 함께 사용하는 것은 좋아보인다. 
누가 어떤 작업을 했는 지 확인하기 쉬워 나중에 확인하기 편할 것 같다. 한 번 잘 사용해봤으면 좋겠다.

- HandlerId와 PacketType을 둘 다 사용하는 것은 HandlerId를 알지 못해도 PacketType으로 해당 데이터 종류를 
대략적으로 알 수 있기 때문에 사용하는 것이다. 다만, 이는 필수적인 구현 사항은 아니기때문에 PacketType
만 사용해도 문제가 되지 않는다. 스타일의 차이이니 선택하여 사용하면 된다.

- 분석 패킷을 공란으로 비워두었는데, 분석 패킷을 사용할 예정이라면 C->S보단 S<->S인 경우에서 
대부분 사용한다고 알고 있으면 된다. 여러 서버를 두고 특정 서버가 다운되었을 때, 
다운된 사유를 분석하기 위해 분석 패킷을 사용하는 것이다.

**ERD 피드백
-** UserRecord테이블에 게임 기록이 상대와 본인에 대한 레코드가 하나씩 즉, 완전히 일치하는 내용의 레코드가
게임이 끝날 때마다 2개씩 추가되는데 이는 의문점이 드는 방식이다. 한 번 더 고려해보았으면 한다.
 
- UserInfo에서 승/패 그리고 최고점수에 대한 데이터는 UserRecord에서 충분히 얻어낼 수 있는 값이다. 물론,
UserRecord의 레코드 수가 늘어나면 쿼리문에 대한 연산이 부담이 되기때문에 따로 관리하려는 의도는 알고있다.
하지만 이런 경우, **같은 데이터를 저장하고 있는 이상 두 테이블은 동일한 데이터에 대한 무결성을 
주기적으로 검증해야한다.**

- User DB랑 UserInfo DB는 엮어도 되지만 UserRecord DB는 관계를 끊는게 낫다

+) 서버에서 테이블은 종종 관계를 맺지않는 경우가 있다. 그 이유는 테이블끼리 조인하는 행위자체가
큰 부담이 되는 행위이기 때문. 그래서 관계형 DB지만 관계를 맺지 않거나, MongoDB로 넘어가는 경우가 있다.

총평: 전체적으로 잘 작성해주었고 앞으로 나올 결과에 기대가 된다!