2013년 KASA Study 발표자료.

1. 서버와 클라이언트 같은 엔진
공유하기
유영천
http://yuchi.net
Twitter:@dgtman

2. 뭣하러?
• 개발 프로세스의 측면
• 기술적인 측면

3. 개발 프로세스의 측면
• 서버 프로그래머? 클라이언트 프로그래머?
왜 나눠야 하나?

4. • 서버 프로그래머는 3D 프로그래밍을 전혀
모르는 경우가 많다.
• 클라이언트 프로그래머는 네트워크프로그
래밍이나 DB 다루는 법을 전혀 모르는 경
우가 많다.
• 컨텐츠 프로그래머는 둘 다 모르는 경우가
많다.

5. 서버/클라 구분하지 맙시다.
• 신뢰할 수 있고 사용법이 간단한 네트워크
라이브러리가 있다면…
• 신뢰할 수 있고 사용법이 간단한 DB라이
브러리가 있다면…
• 클라이언트와 서버에서 동일한 인터페이
스로 3D씬을 다룰 수 있다면…->3D엔진을
공유할 수 있다면?

6. 이런 구성도 가능
• 네트워크 프로그래머 1명
• 3D엔진 프로그래머 1명
• 나머지 다 게임 프로그래머
• 프로젝트 엡실론의 경우 상주 프로그래머
총 3명이었음.
• 네트워크/3D엔진 프로그래머 1명
• 게임 프로그래머 2명

7. 기술적인 측면
• 클라이언트에서 패킷을 주기적으로 보내
는 방식은 해킹에 99% 뚫린다.
• 별별 꼼수를 다 써봐도 클라이언트와 서버
의 위치 동기화가 쉽게 안된다.
정공법으로 가자. 클라이언트와 서
버가 똑같이 작동하면 된다.

8. 요약하면…
• 키보드&마우스 컨트롤 방식에서 최대한 완벽
하게 동기화를 맞추고 싶다면…
• 비슷한 일을 하면서도 원치 않게 다르게 동작
하는 코드를 두벌씩 작성하고 싶지 않다면…
• 서버프로그래머와 클라이언트프로그래머가
책임을 떠넘기는 일을 줄이고 싶다면…
서버와 클라이언트가 동일한 엔진
을 사용하면 된다.

9. 대략 이런 구성

10. 어떻게 만들까?

11. Server와 Client의 관계정립
• 간단하게 생각하자.
• 게임은 서버에서 돌아간다.
• 클라이언트는 입출력 디바이스일 뿐이다.
• 눈에 보이는 처리 빼고 몽땅 다 서버에서
가능해야한다.

12. 기본 인터페이스 예시
게임 맵생성-클라이언트/서버 공용
virtual ULONG __stdcall CreateSceneGraph(
ISceneGraph** ppGraph, DWORD dwFlag
) = 0;
맵 로딩-클라이언트용
virtual DWORD __stdcall ReadFile(
char* szFileName, ProgressCallBack pFunc
, char* szCommonObjectPath,
DWORD dwFlag) = 0;
맵 로딩-서버용
virtual DWORD__stdcall ReadFileWithoutMesh(
char* szFileName, char* szCommonObjectPath,
DWORD dwFlag) = 0;

13. 캐릭터 생성-클라이언트/서버 공용
virtual ICharacterObject*__stdcall CreateCharacterObject(
char* szFileName, GXSchedulePROC pProc,
VECTOR3* pv3InitPos,
void* pData,
char** ppExtModFileNameList,
DWORD dwExtModFileNum,
DWORD dwFlag) = 0;
서버에서 사용시
dwFlag = GXOBJECT_CREATE_TYPE_NOT_USE_MODEL;

14. 캐릭터 위치 설정 – 서버/클라이언트 공용
virtual void __stdcall SetPosition(
VECTOR3* pv3Pos,
BOOL bDoInterpolation) = 0;
충돌처리를 적용한 캐릭터 이동 – 서버/클라이언트 공용
Non-block mode요청
virtual DWORD__stdcall QueryCollisionTest(
COLLISION_REACTION_TYPE reactionType,
float Elasticity,
VECTOR3* pVel) = 0;
Block mode 결과획득
virtual BOOL __stdcall CollisionCompleteTest(
DWORD dwQueryIndex,
COLLISION_TEST_RESULT* pOutColResult,
BOOL bInterpolation) = 0;

15. C/S공용 엔진 요구사항
• 다수의 맵을 동시에 로드하고 관리할 수 있을
것
• 복수의 캐릭터들에 대한 충돌처리 기능.
• 복수의 레이체크 기능.
• 64bit 코드(64Bit 주소공간) 사용 가능할것.
• 그래픽API에 독립적일 것-렌더러만 분리할
수 있을 것.
• 하나의 리소스로 여러개의 맵을 인스턴싱할
수 있을 것.

16. 다수의 맵을 동시에 로드
• 클라이언트는 한번에 1개의 맵을 로드한
다.
• 서버는 모든 맵을 다 로드한다.
※특정 오브젝트 , 특정 공간에서 오브젝트를
골라내거나 픽킹을 위한 레이체크 기능은 기
본.

17. 동시에 여러개의 맵을 로드한 경우

18. 다수의 오브젝트충돌처리
• 접속 유져가 5000명이든 10000명이든 동
시에 충돌처리가 가능해야한다. - 클릭게
임이면 그럴 필요 없다.
• 초당 30,60프레임 정도로 돌아갈 수 있는
퍼포먼스가 필요하다.
• 부하가 적지 않으므로 효율적인 코드를 짜
는게 중요하다.
• 멀티스레드는 기본, SIMD, GPGPU는 선택.

19. 복수의 레이체크 기능.
• 총들고 다니는 게임은 필수.
• 클라이언트의 요청에 상관없이 서버에서
는 항상 추적하고 있어야한다.
• 이것도 병렬처리가 필요하다. 멀티스레드
기본,SIMD,GPGPU은 선택.

20. 64bit 코드 사용 가능할것.
• 서버에선 메모리가 많이 필요하다.
• 32bit/64bit에서 모두 잘 작동하는 것은 안
정성을 증명하는 하나의 척도가 될 수 있
다.

21. 그래픽API에 독립적일 것
• 서버에선 그래픽API가 작동하지 않는다고
가정하는 것이 좋다.
• 경험상 그래픽 API에 찰싹 붙어있는 엔진
은 서버에서 돌리는게 거의 불가능하다.-
애초에 설계가 맞지 않음.

22. 게임 맵 인스턴싱
• 하나의 리소스로 여러 개의 맵을 생성한다.
• 채널 사용을 위해선 필수.
• 그 밖에도 수백 수천개의 인스턴스 맵이
생성될 수 있다.
• 메모리를 절약하고 성능을 높이려면 반드
시 필요하다.

23. 하나의 리소스 여러개의 맵 인스턴스

24. 결론

25. 장점
• 굳이 서버/클라이언트 프로그래머 나눌 필요
없다.
• 비교적 적은 코드양을 유지할 수 있다.
• 서버사이드의 키보드&마우스 컨트롤 게임을
만들기 좋다.
• 툴 만들 때 편하다.엔진/네트워크라이브러리
/DB라이브러리등을 갖다 쓴다. - 게임과 툴에
서 언제나 같은 결과를 보장한다.
• 렌더러의 교체가 쉽다. DX8->DX9->DX11 -
그러나 OpenGL이라면 어떨까?-_-;

26. 단점
• 설계단계부터 신경써서 만들어야한다.
• 그래픽 프로그래밍에 치중하기 어렵다.
• 엔진에서 사용하는 미들웨어가 많으면 더
더욱 적용이 어렵다.
기존에 만든 엔진이 위에서 언
급한 요구사항을 만족하지 않으
면 작업량이 대박 많다.

27. 시연

28. Q/A 및 토론