[NDC 2016] <야생의 땅: 듀랑고> 중앙 서버 없는 게임 로직

---

객체가 중심이 되는 서버?

하나의 지역을 물리적인 서버가 담당하는 것은 땅의 크기가 서버의 성능에 의해 제한될 수 밖에 없다

=> 서버는 모종의 규칙에 의해 배정된 객체를 담당한다

 

장점

서버에 소속된 객체의 시야 외에는 관심이 없어 전체 세계의 크기와 상관 없는 구조

=> 이론적으로 무한한 크기의 세계를 표현 가능

특정 서버에 문제가 생겼을 때 재 접속하면 바로 그 위치에서 정상적인 플레이 가능

=> 안정성의 향상

 

 

동기화

동기화가 잦을 수록 DB에 부담이 된다

분산 환경에서는 서버간 동기화가 이루어지므로, N배 부담이 된다

 

동기화 최적화

1. 미래를 예측해 동기화 횟수를 줄이자

변화량을 입력하면 그래프 방식으로 데이터를 보여주는 라이브러리

https://github.com/what-studio/gauge

GitHub - what-studio/gauge: Deterministic linear gauge library

 

 

2. 농사와 날씨

자연물과 건축물은 눈에만 보이고 실체가 없다

인터랙션이 발생하는 순간 실체화

- 메모리 사용랑 최소화

- 동기화 비용이 감소

- 시간이 지나면 변하는 것들은 만료시간을 넣고, 캐시를 버리고 DB에서 정보를 새로 생성

- 결정론적인 것들은 언제 어디서 결과를 확인하더라도 같은 결과가 나와야 하므로, 결과를 결정하는 데이터(장소 시간등)들을 seed로 설정한다

 

 

3. 건설

누군가가 건설을 시작하면 동료들이 옆에서 같이 건설을 한다 => 완성 속도가 빨라짐

간단하지만 장시간 루프를 돌려줄 주체가 없다 => 여러 개의 서버가 동시에 관여하기 때문에

로직을 개선해서 1명이 건설을 시작하고 완성을 기다림 => 동료가 도와주면 완성 시간이 감소

2개 이상의 객체에 동시에 영향을 주는 작업은 구현 비용이 비싸고 버그 가능성이 높다 => 디자이너와 협의를 통해 회피

 

사유지

친구 / 외부인 / 부족원에게 권한을 일부 또는 전부 허용해줄 수 있다

오프라인일 때는 해당 캐릭터의 DB 속 데이터를 직접 수정해야 한다

여러명이 동시에 사유지에서 활동할 경우 서로 다른 서버에 있을 경우에도 안전하게 처리할 수 있어야 한다

 

DB에 태스크 큐

객체마다 태스크 큐를 DB에 만들어 작업을 큐잉해두고 접속중이라면 rpc를 통해서, 아니라면 접속할 때 내 큐를 확인해서 수행한다.

 

 

4. 부족

부족과 플레이어의 관계는 서로 참조, 가입이나 탈퇴는 양쪽 문서를 모두 수정해야 한다.

안전한 트랜잭션을 위한 특징

RDB => ACID

Nosql => BASE

트랜잭션에 내용을 따로 문서로 작성, 애플리케이션 레벨에서 해당 문서를 참조하여 결과적으로 일관성을 보장

 

가입 신청 / 탈퇴 / 초대 수락

-> 플레이어 데이터만 수정

가입 수락 / 강제 탈퇴 / 초대

-> 부족 데이터만 수정

상호 요청과 토큰을 발행해 상호 참조와 토큰 유효를 체크

 

 

중앙 서버가 없다는 것은?

이미 웹 서비스외 여러 분야에서 다양하게 활용 중임

 

분산 구조에 대응하는 전략

- 복잡한 계산은 최대한 한 곳에서, 다른 서버에서는 결과만 받자

- 모든 서버에서 계산해야 한다면 시드 값 조절을 통해 어디에서 하든지 결과가 동일하게

- 동기화를 최대한 하지 않는다.

- 다른 서버의 객체에 동시에 적용되어야 하는 작업을 최소화 한다

---

출처: http://ndcreplay.nexon.com/NDC2016/sessions/NDC2016_0072.html