24.04.30 나만무, 멘토 면담

나만무

플레이어 결승선 도착

플레이어가 결승선에 도달했을 때의 코드를 작성했다.

아직 멍청서버를 만들고있기 때문에 후에 더 수정 될 예정이다.

원래의 broadcast의 경우 나를 제외한 나머지 유저들에게 정보를 보내는 코드여서 broadcastAll이라는 함수를 새로 만들어서 사용했다.

---

플레이어 출발

결승선을 만들고 난 뒤, 출발도 만들었다.

일단 outgame 부분과 로딩을 확인하는 부분이 없으니 플레이어 한명이 버튼을 누르면 그 트리거를 바탕으로 프로토콜을 전달 받으며 게임을 실행하는 것으로 간단하게 만들었다.

• UML 구조

GameStart 프로토콜을 서버가 클라이언트에게서 받으면 GameStartCountDown()을 호출한다. GameStartCountDown()에서 플레이어에게 카운트 다운을 시작하라고 GameStartCountDown 프로토콜을 전송하고 CountDown() 함수를 호출한다.

CountDown 함수에서는 어떤 프로토콜인지에 따라 다른 숫자의 카운트를 시작하고, 프로토콜에 따라서 카운트가 종료되었을 때, 그에 맞는 프로토콜을 플레이어에게 전송한다.

멘토 면담

질문

1. 유저가 로딩이 완료된 것을 어떻게 판단할 수 있을까요?
   1. 로딩이 완료된 유저가 메시지를 보내는 방식으로 확인 가능할 것 같다.
2. 꽤 바닥부터 하신다고 했는데, 우리가 Node.js 라는 편한 도구로 어렵게 하고 있을까요?
   1. 이상하지는 않다. 메시지를 하나하나 만들면 관리하기 힘들기 때문에 json으로 쓰는 것을 추천한다.
3. Thread를 사용하라는 것이 main thread와 worker thread로 worker thread들을 메시지 리시버로 사용하라는 이야기이신지.
   1. yessssssssss
4. 동기화 버벅거리는 이유
   1. 여러 가설을 세울 수 있다. TCP여서, Node.js여서 등등 이런 가설들을 바탕으로 위치 동기화의 문제라면 데드레커닝이나 엑스트라폴레이션으로 우선 순위를 잘 정해서 시도해봐라. 빠르게 고치기 위해서는 가설을 잘 세우고 문제를 찾아야 한다.
   2. 서버와 클라이언트 비지니스 로직을 얼마나 어디서 진행해야 할지 생각해봐라
   3. 위치 동기화 - 데드레커닝 같은 경우는 어렵긴하지만 우리 프로젝트에서는 크게 어렵지 않을 것이다.
5. aws 부가기능 관련
   1. 전체 프로젝트 후반부에 원래 진행했던 부분을 AWS 같은 서비스로 migration 하는 것을 추천한다.
6. 상태 동기화 관련
   1. 서로 1등이라고 뜨는 경우나 아이템 같은 것을 동시에 주웠을 시 어떻게 판단할지 정하는 것이 중요하다.
   → 내 생각 lock을 사용하면 괜찮지 않을까 생각
7. 서버 클라이언트 관련
   1. 한 클라이언트가 모두 결정을 하거나 - host
   2. 서버가 모두 결정하게 하거나
8. 모션 블러 관련
   1. post processing 안에서만 쓰는게 좋다. 잘 쓰면 꽤 그럴듯하게 만들 수 있다.
9. 썰매가 뒤집어지는 문제
   1. 물리엔진이 할 수 있는 내에서 무게를 늘리는 parameter의 값을 늘리거나, 스크립트로 사용하는 것

• 다음 주 면담 전까지 데모 발표를 할 때, 시연 때 보여줄 수 있는 flow를 만들면 좋다. 상태 동기화가 가능한 게임. → MVP를 만들면 될듯
• 속도를 보아하니 계획한 모든것은 아니지만 뭔가 나오기는 할 것 같다.