2004년 RuneScape가 56k 모뎀에서 MMORPG를 굴린 방식: 600ms 틱과 바이트 절약
- 2004년 RuneScape 2는 서버가 약 600ms 틱마다 각 플레이어의 가시 상태를 계산해 전송해야 했고, 56k 모뎀 환경에서 실제 다운로드 대역폭은 약 5KB/s 수준이었음
- 브라우저 Java 애플릿의 보안 샌드박스는 UDP와 원시 소켓 사용을 막았고, 게임 트래픽은 순서 보장과 세그먼트 오버헤드가 있는 단일 TCP 연결을 사용했음
- 로그인 뒤 각 패킷의 opcode 1바이트만 ISAAC 스트림 암호로 암호화했으며, 클라이언트와 서버는 공유한 4개 정수 시드에 방향별로 50을 더해 서로 다른 키스트림을 만들었음
- 이동 클릭 시 클라이언트는 로컬 충돌 지도에서 BFS 경로 탐색을 한 뒤 첫 경유지 절대 좌표와 이후 경유지 델타를 서버로 보냈고, 가변 길이 본문은 길이 1바이트로 구분했음
- 이동 요청 본문은 시작 좌표 4바이트, 첫 지점 이후 각 경유지당 2바이트, Ctrl 상태 1바이트로 구성돼 길이가 4 + 2 × (경로 길이 - 1) + 1이었음
Hacker News opinions
이 글은 사실상 Lost City 코드베이스를 분석한 것 같은데, Lost City 링크가 없는 점이 아쉬움.
코드 조각은 JavaScript인데 글에서는 Java만 언급함. 원본이나 사용한 코드베이스를 밝혔어야 함.
비슷한 규모의 게임을 14.4k에서도 구현한 사례가 있었음. 저자는 Ultima Online 에뮬레이터도 보면 흥미로울 듯함.
Ultima Online은 1997년에 28k 모뎀만으로도 돌아갔고 더 복잡한 게임이었다고 봄.
RuneScape가 WoW와 같은 2004년에 어떻게 그렇게 퍼졌는지 잘 모르겠음.
무료였고 학교 도서관 PC에서도 바로 할 수 있었음. WoW보다 먼저 나왔다는 점도 큼.
내 부모님 PC는 WoW를 설치조차 못 했지만 브라우저 RuneScape는 됐음. 당시 아이들한테는 그 접근성이 엄청났음.
Miniclip에 올라간 것도 꽤 큰 요인이었다고 봄. 다운로드 없이 2분 만에 시작할 수 있었음.
목적지만 보내는 대신 왜 클라이언트가 경유 지점을 전부 보내는지 궁금함. 서버 경로 탐색 비용을 피하려는 설계였나?
격자에서 벽을 통과하지 않는지만 검사하는 비용은 경로 탐색보다 훨씬 쌈. 서버는 어차피 그 검증도 해야 함.
클라이언트는 이미 전체 지도 데이터를 받았으니 경로 계산이 싸고, 2004년 하드웨어에서 동시 접속 2,000명을 처리할 서버 부담을 줄였을 것 같음.
Jagex는 2005년쯤 이미 마우스 움직임 휴리스틱으로 봇을 잡았음. 글이 안티치트가 시간에 따라 어떻게 바뀌었는지도 더 다뤘으면 했음.
내 경험상 공개 스크립트 대신 직접 만든 스크립트를 쓰면 탐지를 아주 오래 피할 수 있었음. Jagex의 탐지에도 빈틈은 계속 있었음.
최근 6개월은 새 CEO 이후 봇 단속이 훨씬 엄격해져 대형 봇팜이 거의 사라졌다고 체감함.
Dreamcast의 Phantasy Star Online도 다이얼업에서 잘 돌아갔음.