yuchi's development

게임의 규칙과 관련된 물리(간단한 모델이든 복잡한 모델이든)는 서버에서도 똑같이 적용되어야 한다. 모든 시뮬레이션의 기준은 서버이고 클라이언트는 단지 터미널의 역할이어야 한다.
따라서 게임의 룰을 결정짓는 엔진의 기능들은 클라이언트와 서버 사이에 완전히 공유되어야 한다.

이것이 내 온라인 게임 개발의 철학이다. 내 기술은 철저하게 이러한 철학 위에서 구현된다.

이러한 방식의 장점은

1. 해킹을 근본적으로 차단할 가능성이 높다.

2. 온라인 모드에서의 컨텐츠를 추가함에 있어서, 상당량의 코드가 서버와 클라이언트 사이에 공유된다. 서버에 추가하는 코드는 클라이언트의 코드이기도 하고, 클라이언트의 코드는 서버의 코드이기도 한다.

3. 많은 클라이언트/서버 시스템들이 클라이언트가 서버에 요청하면 그제서야 클라이언트의 위치와 속도를 부분적으로 검증한다. 내 방식은 이렇게 하지 않는다. 임의의 시간에 서버는 클라이언트의 위치와 속도들 정확히 알고 있다. 따라서 서버측에서 능동적으로(클라이언트에 뭔가를 묻거나, 클라이언트의 요청을 기다리지 않고) 클라이언트의 상태를 제어할 수 있다.

4. 클라이언트 A, 클라이언트 B, 서버 사이의 위치와 속도는 물리적인 공식에 의해서 정확히 동기화 되므로 시간차는 있을 망정 움직임의 궤적은 정확히 동기화된다. 캐릭터가 나무나 바위를 뚫고 지나가거나 하는 일은 완벽하게 방지된다.

5. 쓰레기같은 보안 솔루션을 플레이어의 머신에 설치하도록 강제하지 않아도 된다.

[요약하면]
1. 해킹차단에 상당히 유리하다.
2. 온라인 모드의 기능(이동처리와 관련된 까다로운) 추가가 쉽다.
3. 유지보수 비용이 비약적으로 감소한다.

이걸 구현하려고 시도했던게 2004년.
실제로 구현체를 세상에 보인건 2008년.
실제 서비스를 했던건 2014년.
거기에 복셀처리까지 더한 것을 출시한 것이 2020년.

그리고 내 결론은 다음과 같다.
이런 기술은 플레이어도, 개발사도, 누구도 원하지 않는다.

[개발사의 입장]
기반 플랫폼을 만들고 검증하는데 시간이 꽤 걸리는데, 그럴 시간에 게임 기능 하나 더 넣고 그래픽 하나 더 이쁘게 만들자.
해킹은 보안솔루션을 플레이어의 디바이스 설치하도록 강제하는것으로 해결.
그래도 안되면 운영으로 땜빵.

[플레이어의 입장]
절대 대다수의 플레이어들은 핵쉴드던 n프로젝트던 100개쯤 깔아도 게임만 돌면 상관 안한다. (난 보안솔루션을 설치하느나 그 게임 안하고 말지만)
캐릭터가 벽을 뚫고 지나가든 바위를 뚫고가든 상관없다.
해킹으로 피해를 보는건 싫지만 자신이 해킹으로 득을 본다면 그건 OK.

그렇다. 그렇더라고.
게임 몇카피 팔고 못팔고는 전혀 중요하지 않다. 내가 전의를 상실한건 돈 때문이 아니다.

‘게임은 그런거야. 재밌으면 장땡. 더 나아가서 돈 벌면 장땡’
이런 아픈 현실을 받아들여야 하기 때문이다