게임서버

한 플레이어가 게임에 입장할 때 클라이언트와 서버 사이에는 입장요청부터 다른 플레이어의 정보까지 여러가지 정보를 주고받는다. 새로운 플레이어가 게임에 입장하는 상황을 나타낸 그림은 아래와 같다.

이동기능을 구현할 때 나의 이동방식과 다른 사람의 이동방식은 비슷하지만 다른 사람의 이동방식은 서버의 정보를 바탕으로 움직인다는 것이 다른점이다. 만약, 싱글게임을 먼저 구현한 후 멀티게임으로 이식하는 과정을 거친다면

멀티게임에서 플레이어 공격을 구현할 때 어디까지 클라이언트가 담당하고 서버가 어디까지 처리해야 안정적인 공격환경을 만들 수 있을까? 가장 이상적인 방법은 클라이언트를 완전히 신뢰하고 클라이언트가 보낸 정보를 바탕으로 서버에서 처리하는 방법일 것이다.

플레이어의 상태정보는 서버가 가지고 있고 클라이언트는 서버로부터 상태정보를 받아 화면에 표시하는 구조를 가진다. 플레이어의 상태로는 플레이어의 위치, 체력, 마나와 같은 정보나 스텟과 관련된 정보가 될 수 있다.

싱글플레이게임에서의 몬스터 AI는 몬스터의 기능에 대한 연산을 몬스터 GameObject의 컴포넌트로 붙여 현재 상태를 계산함으로 구현할 수 있다. 스킬쿨타임이나 애니메이션같은 경우 코루틴을 이용한 시간계산으로 구현하였는데 온라인게임같은 경우

로그인을 처리를 구현할 때 서버는 클라이언트가 넘긴 정보에 대한 검증과 실제 데이터베이스에 존재한 정보인지 확인을 해야한다. 물론 데이터베이스에는 사용자의 정보(아이디, 비밀번호)에 대한 테이블이 존재해야 한다.

lock과 데이터베이스에 접근하는 기능을 동시에 사용하면 시스템 성능이 떨어지는 상황이 발생할 수 있는데 그림으로 나타내면 아래와 같다. PlayerB와 PlayerC의 요청을 처리하는 쓰레드들이 오랜시간동안 대기하게 된다.

서버에서 아이템을 구현하려면 데이터베이스에 아이템 테이블을 정의해야 한다. 하지만 데이터베이스에는 아이템의 모든 정보를 담고 있을 필요는 없다. 아이템의 이름이나 기본공격력같은 기본정보는 클라이언트에게 데이터시트를 참고하라고 하고 서버는 클라이언트에게 데이터시트의 식별

플레이어가 아이템을 사용하고자 할 때 서버는 이를 어떻게 처리해야 할까? 첫번째로 플레이어는 서버에 어떤 아이템을 사용할 것인지에 대한 요청을 보내야할 것이다. 요청을 받은 서버는 요청한 플레이어가 실제로 사용이 가능한 상황인지 확인할 것이다.

MMORPG에서는 한 공간에 얼마나 많은 유저가 모여있는지가 관건이다. 대표적인 문제는 패킷을 Broadcast하는 문제인데 사람이 늘어날수록 보내야 하는 패킷의 양은 점점 더 많아지게 된다.

대형 구조에 대해서 다뤘을 때 오픈월드 환경에서 Zone을 나누어 같은 Zone에 있는 다른 플레이어들에게만 패킷을 전송하는 구조를 아래 그림과 함께 이야기를 했었다. 하지만, 굳이 오픈월드가 아니어도 매우 넓은 맵에서 Zone의 개념을 사용할 수 있다.

플레이어가 게임을 종료할 때 항상 정상적인 방법으로 종료한다는 보장은 없다. Alt+F4로 프로그램을 강제종료할 수도 있고 컴퓨터 전원이 나가거나 비정상적으로 종료할 수 있다.

게임을 하다보면 흔히 '핵'이라고 말하는 게임 해킹 프로그램을 사용하는 유저들을 볼 수 있다. FPS의 월핵, RPG의 쿨타임 핵, 레이싱 게임의 스피드 핵, 어렸을 때 리그오브레전드의 '무한 몰락 핵'등이 게임 해킹의 예시 중 하나이다.

보통 게임을 시작할 때 로그인을 먼저하고 그 다음에는 서버를 선택하는 화면이 나온다. 서버를 선택하는 구조는 보통 메이플, 던파, 로아와 같은 대형 RPG게임에서 주로 사용한다.