이름 : 최흥배E-mail : jacking75@gmail.comHomePage : jacking75.cafe24.comBlog : http://blog.naver.com/jack-ing75

What is Game Server ?

1. 온라인 게임서버의 OS 플랫폼

Windows한국에서 게임서버를 만드는 경우 가장 일반적으로 선택하는 OS 이다 .게임 개발자들에게 가장 익숙한 OS.

Linux비 Windows OS 중에서 가장 대중성을 가지고 있는 OS 이다 .Windows 보다는 덜 익숙하지만 점점 대중성 및 관련 자료를 늘리고 있다 .

FreeBSDUnix 계열의 OS 로서 Linux 와 거의 비슷함 .Linux 에 비해 대중성은 약하지만 Unix 를 사용하였던 사람들로부터 지지를 받음 .

온라인 게임서버가 실행되는 OS 플랫폼은 거의 대부분이 Windows, Linux, Free-BSD 이 셋 중의 하나이다 .

이중 Windows 플랫폼용이 가장 많다 .

게임 서버 프로그래머가 보는 각 OS 의 장단점

Windows Linux FreeBSD

장점

1. 가장 익숙한 OS.

2. 타 OS 에 비해 개발환경이 우수 .

3. 개발자 구인이 타 OS 에 비해 쉽다 .

1. 개발 및 서비스 비용 감소( 툴 및 OS 구입 측면 ).

2. 개발자의 능력에 따라 최적화 할 수 있음 .

1. 전체적으로 Linux 와 비슷 .

2. 타 OS 에 비해 네트웍 성능이 뛰어난 편임 .

단점

1. 운용 해야 될 OS 수가 늘어나면비용 증가 .

2. OS 최적화에 한계가 있음 .

1. 개발자 구인이 쉽지 않다 .

2. OS 의 사용이 익숙하지 않다 .

3. 개발에 관련된 정보가 Windows 에 비해 부족하다 .

1. 단점도 Linux 와 비슷 .

2. Linux 에 비해 오픈 소스 지원이 떨어짐 .

2. 게임 장르에 따른 게임서버의 특징

2. 1 . 온라인 보드 게임

일반적으로 높지 않은 성능을 요구하며 , 게임의 규모가 크지 않다 .

C/S 방식으로 통신을 하며 기능별로 서버를 분산하기 보다는 하나의 서버에서 모든 것을 다하는 경우가 많다 .

보드 게임 특성상 기본 틀은 비슷하지만 게임 룰만 다른 경우가 일반적이므로 프레임워크 식으로 서버를 만들면 좋다 .

개발 툴 및 프레임 워크가 잘 갖추어져 있으면 한 명의 프로그래머가 서버 , 클라이언트 모두를 할 수 있다 .

2. 2 . 캐주얼 게임

보드 게임 서버에 비해 게임의 규모가 더 크며 , 액션 성이 높은 게임이 많다 .

게임 플레이에서는 주로 P2P 방식을 이용하여 그 외 부분에서는 C/S 방식 사용 ( P2P 에서는 UDP, C/S 에서는 TCP 사용 ).

보드 게임 서버와 MMORPG 게임서버의 중간 정도의 규모 급이다 .

요즘에는 ‘캐주얼’이라는 이름에 걸맞지 않게 개발 기간이 MMORPG 와 비슷 .

2. 3 . MMORPG 게임

게임의 규모가 크고 그에 따라서 개발 인원도 많다 .

거의 C/S 방식의 TCP 프로토콜을 사용한다 .

많은 기능과 높은 성능을 필요로 하므로 큰 기능별로 서버가 분산된다 .

3D 환경의 경우 지형 처리 및 NPC 의 길 찾기가 중요 해진다 .

3. 온라인 게임서버 제작을 위한 기술 및 개발 환경

3. 1. 각 OS 의 비 동기 IO 방식

Windows IOCP.Windows 2000 이상부터 지원 .참고 자료 : MSDN

Linux epoll.2.5.x 커널에 추가 되기 시작하였으며 2.6.x 커널 대에서는 기본으로 탑재 .참고 자료 : http://www.xevious7.com/tag/epoll

FreeBSD Kqueue.Windows, Linux 에 비해 일찍부터 비동기 I/O 지원 .참고 자료 : http://jacking75.cafe24.com/Network/FreeBSD_Index.htm

3. 2. Multi-Thread

일반 PC 와 달리 서버 PC 는 이전부터 단일 CPU 보다는 듀얼 CPU 이상의 CPU 를 사용 했으므로 Thread 를 도입한 경우가 많으며 서버 프로그래머들이 많은 관심을 가지고 있는 분야이다 .

현재 출시되는 CPU 는 듀얼코어 이상의 CPU 가 출시되고 있으므로 이전보다 더욱 더 Thread 기술이 중요해지고 있음 .

Windows 의 경우 Windows OS 의 Thread 라이브러리를 사용하고 , 유닉스계열 (Linux, FreeBSD 등 ) 에서는 Pthread 라이브러리를 사용한다 .

Boost 의 Thread 라이브러리를 사용하면 OS 독립적인 Thread 기술 사용 가능 .

Intel 에서 스레딩 빌딩 블록 (TBB) 라는 Thread 관련 라이브러리 공개( 단 유료로 구입한 경우에만 기술 지원을 받을 수 있음 ). http://blog.naver.com/jacking75/140040961225

Thread 사용 시에는 동기화와 성능 분산이 중요하다 .일반적으로 과도한 동기화는 Thread 컨텍스트 스위칭에 따른 비용 증가로 오히려 성능이 더 내려 갈 수도 있다 .

Thread 관련 툴을 사용하면 좋다 .인텔에서 제공하는 Thread Checker, Thread Profiler 등이 있다 .

Thread 사용은 이익과 위험이 따른다 . 보수적인 관점에서 접근을 해야 된다 .특히 서버의 로직 처리 부분을 Multi-Thread 로 할 때에는 트랜잭션 처리에 아주 조심해야 된다 .

3. 3. Database(DB)

온라인 게임 서버에서 중요한 것 중의 하나가 DB 이다 .

일반적으로 규모가 큰 회사 등은 DBA 가 있어서 이들을 통해서 DB 작업을 하지만 아직까지는 대다수가 서버 프로그래머가 DBA 의 역할까지 한다 .

일반적으로 많이 사용되는 DB 는 MS SQL, MySQL, Oracle 등이다 .보통 게임서버가 운용되는 OS 에 따라가는 편이므로 MS SQL 을 많이 사용한다 .

DB 프로그래밍 시 MS SQL 의 경우는 ODBC, DO, OLE DB 중에서 하나를 사용 ,My SQL 및 Oracle 은 네이티브 라이브러리를 주로 사용한다 .

원활한 개발 및 이후의 서비스를 위해서는 관계지향적인 모델링이 아주 중요하다 .

3. 4. P2P

캐주얼 게임에서 주로 사용하는 네트웍 연결 방식 .

C/S 방식에서는 주로 TCP 를 사용하지만 P2P 에서는 UDP 를 사용한다 .

액션 게임처럼 빠른 움직임이 필요한 경우 사용한다 .

NAT( 이른바 공유기 ) 은 Full Cone NAT, Restricted Cone NAT, Port Re-stricted Cone NAT, Symmetric NAT 의 4 가지 방식이 있다 .

모든 상황에서 홀펀칭에 의한 연결이 이루어 지지 않으므로 비상책으로 릴레이 서버는 필수 이다 .

3. 5. 길 찾기

주로 MMPRPG 에서 사용한다 .

3D 방식의 게임에서 지능적이며 빠른 처리를 위해서는 길 찾기 기능이 중요 .

길 찾기 관련 라이브러리 구입 및 자체 개발을 한다 .

한국에서 많이 사용하는 상용 라이브러리로는 PathEngine 이 있으며 , LandMaster 라는 국산 상용 라이브러리가 있다 .

상용 라이브러리를 구입하더라도 게임에 따라 변경이 필요 할 수 있으며 그래픽 파트에서 관련 데이터를 잘 만들어줘야 된다 .

3. 6. 유닉스 계열 OS 에서의 프로그래밍 환경

Windows 에서 Visual Studio 툴에서 개발 및 디버깅을 한 후 최종적으로 실제 서비스 할 OS 에서 빌더 한다 .

GUI 환경에서 이클립스나 KDevelop IDE 에서 코딩 및 디버깅 한다 .

콘솔 환경에서 Vim(vi) 등을 사용하여 코딩을 한 후 gdb 로 디버깅 한다 .

KDevelop

3. 7. 서버의 비정상 종료

서버 개발자가 가장 무서워 하는 것 중 하나가 서버가 갑자기 죽어버리는 경우이다 .

덤프 파일 ( 유닉스 계열에서는 코어 파일 ) 이 있으면 빠르게 대처 할 수 있다 .

Windows 에서는 VS 에서 관련 옵션 설정을 하고 MS 사이트에서 심볼을 가져오면 된다 .참고 : http://www.debuglab.com/index.html

유닉스 계열 OS 에서는 프로그램이 죽으면 실행 파일이 있는 위치에 .core 파일이 생성 , gdb 를 사용하여 죽었을 때의 프로그램 상태를 파악한다 .

WinDBG

4. 서버 구성

4. 1. DataBase 와 연결되는 서버

단순하게 쿼리문을 실행하고 통보를 해주는 것과 캐싱 기능을 가지는 것으로 나눌 수 있다 .

보통 회원 정보 등의 DB 와 연결되는 서버는 Common DB, Account SQL DB, Member DB, Web DB, Cache DB 등으로 불린다 .

게임 플레이에 대한 정보가 있는 DB 와 연결되는 서버는 Game DB, User Data SQL DB, Agent DB, Procy DB 등으로 불린다 .

4. 2. 게임 서버 ( 실제 게임을 하는 ) 를 연결 해 주는 서버

하나의 월드 ( 서버군 ) 에 있는 각 게임서버 사이를 연결 해준다 .

커뮤니티 기능 역할 (채팅 , 파티 등 ), 전체 월드 관리 기능 , 게임서버 사이의 중계 기능을 한다 .

World Management Server, Community Server, Messenger Server, Center Server 등으로 불린다 .

4. 3. NPC 를 관리 하는 서버

NPC 의 AI 를 처리하면서 게임서버와 연결된다 .

NPC 기능이 게임서버와 분리 되는 경우 부하 분산과 게임서버가 간결해지는 장점이 있지만 게임서버와의 통신을 해야 되므로 내부 통신량 증가와 딜레이 타임이 있을 수 있다 .

NPC Server, Mob Server, AI Server 등으로 불린다 .

4. 4. 서버를 관리 하는 서버

위의 서버들을 관리하는 서버 .

서버의 비 정상 종료 감지 , 서버 ON/OFF 등을 기본적으로 한다 .

Management Server, Monitoring Server 등으로 불린다 .

4. 5. 로그인 서버

Common DB

Login Server

Messenger Server

Game DBGame Server

NPC Server

Messenger Server

Game DBGame Server

NPC Server

5. 툴 제작 및 데이터의 분리

5. 1 . 툴 제작

빠른 개발 , 편한 개발 , 실수 방지에 도움이 된다 .

툴 개발에는 실제 만들 게임만큼 제대로 된 요구분석이 필요하다 .

서버 파트에서는 서버 관리 , DB 조작 툴 등이 필요하다 .

5. 2 . 데이터의 분리

게임에서 사용하는 데이터를 프로그램과 분리 한다 .

서버의 경우 DB 에 게임에서 사용할 데이터를 저장 후 사용하고 , 클라이언트는 DB 에서 필요한 데이터만 파일로 저장 후 사용한다 .

게임의 유연성이 높아지며 비 프로그래머의 참여도가 높아진다 .

데이터의 잘못된 입력에 따른 부작용을 조심해야 된다 .

6. 게임 개발 흐름서버 프로그래머의 입장에서의 게임개발 흐름은 아래와 같다 .

서버 OS 플랫폼 선정

서버 구조 설계

네트웍 라이브러리 제작 및 구입

DataBase 선정

기획 및 클라이언트와 협의

구현 구상 및 패킷 정의

구현

클라이언트와 테스트

기획 및 QA 에 통보

만들 게임에 대한 전체 계획을 잡는 단계

게임을 각 기능별 구현 단계

7. 테스트

테스트는 아주 중요하다 .

테스트는 QA 에서 하는 테스트도 있지만 여기서는 프로그래머가 구현 이후 자체적인 테스트를 하는 것을 말한다 .

보통 구현 해야 될 작업의 30 ~ 50% 테스트를 통해서 소비 된다 .

테스트는 중요하지만 어렵고 아주 지루하다 .

테스트는 클라이언트와 서버의 협력이 절대적으로 필요하다 .

원활한 테스트를 하기 위해서는 사전에 어떻게 하면 테스트를 편하게 더 빨리 끝낼 수 있을까 생각을 하고 준비를 해야 한다 .

가능하면 Cheat 기능 (또는 GM 기능 ) 을 사전에 만들어 테스트에서 사용한다 .

7.1. GM 및 Cheat 기능

HP, MP, 돈 , 경험치 , 레벨 등 변경 .

워프 기능 . 지정된 위치로 이동 , 지정된 캐릭터로 이동 , 상대방을 호출 .

현재 서버의 특정 유저의 정보 보기 .

현재 서버의 파티 정보 보기 .

채팅 창을 이용한 Text Command 도 좋지만 간단한 GUI 를 제공하면 더 좋다 .

그러나 Cheat 기능을 사용 할 때는 side effect 를 조심 해야 한다 .예 ) 캐릭터의 HP 를 증가 시킨 경우 주위의 다른 클라이언트에 통보 해 주지 않으면 서로 간에 HP 정보가 다르게 나와서 버그로 오인 .

7.2. 버그 없는 서버를 만들기 위한 방법

1. 서버 / 클라이언트의 협력이 아주 아주 중요하다 .

2. 클라이언트의 요청이 실패한 경우 어떤 이유의 실패인지 결과를 통보한다 . 예 ) // 길드를 만들 수 있는지 체크 if( 돈이 부족 ) return -1; if( 레벨 부족 ) return -2; …………. return 1; // 성공

3. GM 기능 , Gheat 기능 및 실행 중인 서버의 상태를 알 수 있는 기능 구현 .- 테스트를 하면서 스트레스를 덜 받고 빨리 할 수 있다 .

4. QA 팀에 의한 지속적인 테스트 .- 주기적으로 구현 되어 있는 것을 테스트 해야 된다 .- 새로운 기능을 구현 하거나 기존에 구현 된 것을 수정하다 보면 이전에 잘 돌아가는 기능에 버그가 발생 한다 .

8. 문서화

유지보수 측면에서 문서화는 중요하다고 할 수 있다 .

그러나 문서화는 아주 지루하며 어떤 것이 좋은 문서인지 알기 힘들다 .

좋은 문서를 만들기 위해서는 수련이 필요하다 .

문서화는 구현 전 설계를 할 때 하고 이후 구현을 하면서 변동이 생기면 수정을 해야 된다 .

너무 많은 문서를 만들면 문서 자체의 유지보수가 힘들어지기 때문에 꼭 필요한 부분만을 하는 것이 좋다 .

자신만의 문서 포맷을 만들어 나가데 주위 동료의 피드백을 받는 것이 가장 좋다 .

9. 책 소개 및 참고 사이트

9. 1 . 책

9. 2 . 사이트

GpgStudyhttp://gpgstudy.com/

게임 및 프로그래밍 관련 블로그 모음http://mypage.sarang.net/gdblog/

레이옷님의 사이트http://reiot.com/

Code Projecthttp://www.codeproject.com/

데프피아http://www.devpia.com/

JoicChttp://www.joinc.co.kr/

온라인 게임 제작자 모임http://cafe.naver.com/ongameserver

MS TechNethttp://www.microsoft.com/technet/technetmag/Default.aspx?loc=ko

MSDN 매거진http://msdn.microsoft.com/msdnmag/issues/07/08/default.aspx?loc=ko