알고리즘
소수 한번 구하기 어렵네 - 유정 튜터님의 조언
약수나 소수 구하는데 쓰이는 메커니즘이 여러개가 있었는데, 그중 제곱근을 이용한 방법이 있어 따라해봤다.
어떤 수의 제곱근을 구해서 1 ~ 제곱근 사이에서 약수를 구했을 때 약수가 나오면 그것의 2배를 하면 되고, 그 범위 사이에서 약수가 없었다면 어차피 제곱근 ~ 원래 수 사이에서도 약수는 나오지 않을 것이라고.
그렇기 때문에 나는 2 ~ 제곱근 사이에서만 약수를 구해보고 그 사이에서 약수가 없으면 소수로 보기로 했다. 그런데 뭔가 잘 되지 않았다. 🤔
유정 튜터님이 처음부터 너무 효율적인 방법을 쓰려고 하기보다는 일단 단순한 방법으로 해보고 되면 그 다음에 효율을 찾자고 조언해 주셨다.
주특기 플러스
왜 클라만 켜면 핸들러가 없다고 에러가 날까 -> 클라코드의 문제였다
서버단에서 일어나는 문제는 모두 해결했다고 생각했는데, yarn client로 클라만 켜면 자꾸 터지는 것이었다.
handler가 함수가 아니라고?
쟤가 말하는 핸들러는 이건데, 이건 서버단 코드고 핸들러는 함수가 맞고 문제가 없었다.
고칠 게 아예 보이지 않으니 당황스러웠는데, 생각해보니 클라만 켜면 터진다는건 혹시 클라의 문제는 아닌가? 싶었다.
아직 뭘 이해한 상태가 아니라서 그냥 client.js 코드를 스니펫을 이용해서 오버라이트 했더니 무사히 해결되었다. 빨리 듣고 넘어가도 모자랄 마당에 계속 시간을 끌고 있어 곤란했지만 어쨌든 해결...
이 아니라 계속 터져서 결국 호영 튜터님께 도움 요청.
// 1. 클라가 안보냈나? -> 패킷 잘 보내고 있음 버전도 들어있음
// 2. 파싱이 잘못됐나?
// 3. 프로토버퍼의 정의가 잘못됐나?
// 4. 나의 오타?
이 네 가지의 가능성 중에 4번이 압도적으로 많았다. 강의를 들었다고 생각했는데 거의 안 들은 수준이었다.
레이턴시?
레이턴시: 한 지점에서 다른 지점으로 이동하는데 걸리는 시간 (편도)
랩탑 -> 와이파이 (공유기) -> ISP(KT같은 인터넷 공급자) -> 물리 계층 케이블 -> ISP -> 이더넷 -> 목적지
이 경로가 왕복이 되면 RTT 혹은 RTL이라고 한다. Round Trip Time(Latency).
-> 'Ping' 명령어를 통해 측정된다
-> 옛날 온라인 게임들은 로딩창에서 핑을 볼 수 있었다. (어몽어스는 지금도 볼 수 있다.)
레이턴시 마스킹 이라는 것이 있다.
네트워크 지연을 사용자가 느끼짐 못하도록 숨기는 기술. 예측 및 보정, 보간, 평활화 등이 존재.
이 중 우리는 '추측항법(Dead Reckoning)' 이라는 것을 배울 것.
추측항법?
이미 지난 약간의 시간(우리가 다루는 내용에서는 레이턴시) 만큼 예측해서 전달하는 방법.
레이턴시가 100ms인 상황에서 속도가 1, 1초에 1번 패킷 전달하는 경우,
1초 뒤에 보낼 패킷은 1.1초 걸려 도착하니 <거리 = 속력 x 시간> 공식에 따라 1 x 1.1 만큼의 값을 전달.
- 주의할 점: 공식이 '속도'가 아닌 '속력'이라 이동 방향마다 다른 계산이 필요하다. (일단 여기서는 x축으로만 이동하는 것을 고려)
그러면 우리는 누구의 레이턴시를 어떻게 맞춰줘야 하는거에요? 🤔
대충 게임 세션과 유저가 이렇게 있다고 치면, 같은 세션 내에 있는 유저들의 레이턴시를 동기화 해주면 된다.
이렇게 있다면 이 8명의 환경을 맞춰주면 되는 것. 방법은 크게 두 가지.
- 이 여덟 명의 레이턴시를 다 더해서 평균낸 다음, 이 평균 레이턴시로 추측항법 계산해서 보내주는 것
- 가장 높은 레이턴시 기준으로 추측항법 계산해서 보내주는 것 -> 안정적인 게임 플레이 가능
가장 높은 레이턴시는 왜 써요? 너무 구린 수치 아닌가요? 🙄
가장 높은 레이턴시를 가진 유저는 네트워크 환경도 그렇지만 컴퓨터 사양이 낮아서 게임이 버벅댈 확률이 높다. 그래서 캐릭터가 허공답보 하고 난리가 날 것.
-> 그래서 이 사람한테 맞춰주면 모두의 게임 세션이 똑같이 (느리게) 돌아간다. (안정적이라고 했지 잘 돌아간다고 안했다.) 롤이 이 방식을 쓴다.
동기화?
내 모니터 혹은 내가 하는 게임의 FPS가 60이라고 가정하면 1씩(한 프레임씩) 움직이려면 1/60초가 걸린다. 그리고 우리가 기대하는 모습은 서버에서 클라로 캐릭터의 위치를 보내주는(상태 동기화)게 스무스하게 일어나는 것.
-> 그러나 실제로는 항상 그렇지만은 않다. 클라이언트에서 이 처리를 못 해준다면 상태 동기화의 렌더링 주기는 더 길어져서 두두두둑 끊어지는 걸로 보일 것.
NDC 2016에서 듀랑고 분산서버에 대한 자료를 본 적이 있다. 듀랑고의 초기 서버 로직이 동기화를 엄청나게 시도하는 구조였다고.
그렇다면 이런 동기화로 인한 지연(렉)에 대한 해결책은 없을까? 🤔
아잇 다 밀어버려 - 선형 보간
상황에 따라 몇 프레임씩 밀어서 좌표가 자연스럽게 이동하도록 처리하는 것.
대충 이렇게 되는것. 부드럽게 움직이긴 하는데 약간 딜레이가 있는 느낌.
우리가 쓸 방법 - 추측 항법
레이턴시 만큼 이동한 거리를 미리 계산해서 전송한다.
서버에서 계산해서 보내주기도 하는데, 클라에서 직접 처리하는 경우가 좀더 많은듯.
- 클라에서 미리 처리 후 서버에 전송 -> 서버가 계산하고 다시 클라에 전송 -> 클라가 서버 응답 받은 후 수정 반영 등
인터벌 매니저?
이렇게 한 세션에 모인 유저들이 일정 주기를 가지고 각자 자신의 핑을 보낼 것. 그러면 그 일정 주기는 누가 관리하냐는 것.
각각의 유저들이 관리를 해줘도 되지만, 같은 성격의 무언가이니 한번에 공통적으로 어딘가에서 관리를 해주면 좋겠다 - 그래서 나온 개념이 매니저이고, 그 안에서 생긴 것이 인터벌 매니저.
(매니저는 여러 종류가 있을 수 있다. 유저 위치공유를 위한 로케이션 매니저, 레이드 보스 관련 정보를 관리해주는 보스 매니저, 몬스터에 관한 몬스터 매니저 등등...)
-> 아무튼, 인터벌이라고 하면 게임 하나 당 인터벌 매니저가 하나씩 존재할 것이고, 매니저가 그 게임 세션에 참여한 모든 유저들의 인터벌 관련 정보들이 들어가 있을 것.
