콘텐츠로 이동

`Maze`와 멀티플레이어 모드

전자-건축

Comment 1

사이트가 메모리라고 하는 순간 이 메모리에 타인이 존재할 수 있어야 하는데, 중요한 건 이 타인도 본인의 메모리를 가지고 있을 것이기 때문에 나에게 보이는 타인과 실제 타인이 구분될 수밖에 없다. 내가 알고 있는 타인은 두 가지 버전이 있을 수 있는데, 하나는 내 클라이언트가 만들어낸 환상으로서의 타인이고, 하나는 서버로부터 건네받은 정보로서의 타인이다. 클라이언트가 만들어낸 타인은 타인을 모방한 환상이라고 할 수 있고, 서버로부터 받은 타인의 정보는 직접 생성해낸 정보는 아니지만 그렇다고 하더라도 개인의 입장에서는 이 정보의 유래를 정확하게 알 방법이 없으니(타인으로부터 유래되었다고 하더라도 변조되지 않았을 거라고 보장할 수 없다.) 이 또한 일종의 환상이라고 보는 것이 가능하다.

Comment 2

멀티를 지원하는 순간 본인 및 타인은 이들이 존재하는 클라이언트와 서버의 수만큼 복제되어 존재한다. 흥미로운 것은, 이 존재를 시각화시켜주는 것은 클라이언트이므로 나, 그리고 타인이 어떤 형태로든 시각화되어 존재한다면 이에 대한 정보는 철저히 클라이언트에 의존적이라는 것이다. 아주 간단한 예시로, 내 캐릭터에 이름이 존재하고 이 이름을 다른 사람들이 볼 수 있는데, 내가 이 이름을 바꿨다고 해보자. 그러면 다음의 일들이 순서대로 진행된다.

  1. 내 이름 수정
  2. 서버에 수정 알림
  3. 서버가 다른 클라이언트에 수정된 정보를 제공
  4. 클라이언트에서 이름을 보여줌 여기서 각 단계에서 문제가 발생한 상황을 상상해보자.

Scenario 1: 내 이름을 수정하는 과정에서 오류 발생

이름을 수정하는 과정에서 문제가 발생하면 수정에 실패하여 원래 상태로 돌아오거나, 혹은 수정하던 중 프로그램이 터져서 게임에서 튕기거나 둘 중 하나의 일이 발생할 것이다. 두 경우 모두 딱히 흥미로운 일이 발생하지 않는다.

Scenario 2: 서버에 수정을 알리는 과정에서 오류 발생

내 클라이언트에서는 이름이 수정되었는데 이를 서버에 알리는 과정에서 문제가 발생한다면, 수정 사항이 로컬에만 적용되고 서버 및 이와 연결된 다른 클라이언트에는 아무런 일도 일어나지 않은 것과 같다고 할 수 있다. 서버는 처음부터 영향을 받지 않았으니 이름을 수정한 클라이언트 쪽에서 수정된 이름과 연관된 데이터를 보내서 오염이 전파되지만 않는다면 서비스는 안전하다. 이름을 수정한 클라이언트 측에서는 본인이 수정된 이름으로 보일 수 있고, 다른 클라이언트에서는 기존의 이름으로 보일 것이다. 이런 상황에서 문제가 발생하는 것을 막기 위해서는 클라이언트의 이름과 서버가 알고 있는 이름을 서버, 클라이언트 양쪽에서 체크하는 방어 로직을 작성하는 편이 좋아보인다. 예를 들어, 클라이언트에서 이름이 반영된 어떤 액션을 취하려고 하는 순간 서버가 알고 있는 내 캐릭터의 이름을 한 번 받아와서 데이터가 일치하지 않을 경우 서버의 이름을 적용하는 식.

Scenario 3: 서버가 다른 클라이언트에 수정된 이름을 알릴때 문제 발생

서버는 수정된 내 캐릭터의 이름을 알고 있고, 이 정보를 다른 유저들에게 알리는 것을 실패한 경우. 보통 이런 문제는 상대방이 클라이언트를 종료했다가 다시 실행하거나, 혹은 상대의 이름을 확인해야 하는 액션을 취하면 수정된 이름으로 제대로 뜰 것이다.

Scenario 4: 클라이언트가 수정된 이름을 보여주는 과정에서 문제 발생

서비스 자체에 영향을 주지는 않으므로 크게 흥미롭지는 않으면서, 동시에 무슨 일이든 발생할 수 있으므로 꽤 흥미로워질 수 있다. 다른 캐릭터의 이름을 내 클라이언트 한정으로 마음대로 바꿔서 볼 수 있는 모드를 만들었다고 생각하면 된다.

Comment 3

끊임없이 새로 생성되는 미로에 타인이 들어올 수 있는가? 이를 위해서는 아주 잘 설계된 시스템이 필요할 것이다.

좌표계

내 캐릭터가 존재하는 위치와 다른 캐릭터가 존재하는 위치의 싱크를 맞출 수 있어야 한다. 이를 위해서 모든 플레이어들이 공통된 좌표계 위에 존재하도록 게임 설계가 필요하다.

재생성: 로직

기존의 Maze의 로직으로는 '내가 보고 있지 않은 영역'이 재생성된다. 그렇다면 이 게임을 멀티 플레이어 모드로 확장하기 위해서는 모든 플레이어들이 보지 않고 있는 영역만 재생성 되도록 해야 하는 것일까? 그렇다면 한 위치에 많은 플에이어들이 존재할 경우 맵은 영영 재생성될 수 없는 것일까? 게다가 기존의 로직으로는 새로 생성된 복도는 절대 서로 겹칠 수 없었는데, 이는 플레이어가 한 명만 존재하기 때문에 가능한 것이었다. 멀티 플레이어 모드로 확장을 하면 서로 겹치는 복도가 발생할 수 있는데, 이를 우회할 방법도 마련해야 할지도 모른다.

재생성: 딜레이

복도를 재생성하는 문제를 서버-클라이언트 구조에서 생각하면 좀 더 복잡해진다. 기존에는 클라이언트에서 모든 판단을 진행하고 복도를 생성했는데 여러 사람들이 같은 공간에 있다면 복도 생성 로직을 서버에서 돌리고 클라이언트에 뿌려주는 것이 좋아보인다. 그런데 문제는 서버-클라이언트 통신에 딜레이가 있을 수 있다는 것이다. 서버에서 복도를 계산하기 위해서는 서버가 여러 캐릭터들의 위치와 시선 방향을 알아야 한다는 이야기인데, 서버가 복도 계산을 끝내서 클라이언트에 뿌려주는 사이 플레이어들의 위치와 시선 방향이 충분히 달라져있을 수 있으므로 여기서 문제가 발생할 수 있다. 이 경우 원래는 캐릭터가 보고 있지 않은 공간만 수정되어야 하는데, 갑자기 내가 보고 있던 복도가 변형되거나, 최악의 경우 내가 서있던 복도가 제거되어버리는 일이 발생할 수도 있다.

전자-건축