이미 소장하고 있다면 판매해 보세요.
|
▣ 제0장 _ [속성] 온라인 게임 프로그래밍
0.1 [온라인 게임 프로그래밍을 위한] 네트워크 프로그래밍의 기초 ___네트워크 프로그래밍은 필수(!) ___네트워크 프로그래밍, 인터넷 프로그래밍 ___인터넷 프로그래밍의 역사와 사상 ___OSI 참조 모델 _____온라인 게임 시스템과 레이어 _____레이어4는 대부분의 경우 TCP를 사용하고, 레이어3 이하는 직접적인 조정이 필요 없음 _____레이어5 이상은 게임단에서 구현한다 ___소켓 API의 기초 지식 ___온라인 게임과 소켓 API _____커넥션 지향(스트림형), 커넥션리스 지향(데이터그램형) 0.2 [소켓 프로그래밍 입문] 복수의 동시 접속을 처리, 성능을 추구한다 ___통신로의 특정 ___소켓 API의 기본 ___TCP 통신로의 상태 전이와 소켓 API ___복수의 동시 접속을 처리한다 ___동기적 호출(블로킹)과 스레드 _____스레드 방식의 처리 부하 문제 ___싱글 스레드, 논블록킹, 이벤트 구동 ___온라인 게임에서의 입출력 구현의 특징 ___온라인 게임과 구현 언어 ___성능의 최대화 & 개발 효율 향상 _____온라인 게임 고유의 특성에 의한 언어별 성능 차이 ___멀티코어 서버의 성능을 끌어낸다 _____컨텍스트 스위치 - CPU의 설정 상태를 일시적으로 보관해 둔다 _____멀티코어 머신이며 서버 프로세스 수를 너무 늘리지만 않으면 OK ___멀티코어 머신과 네트워크의 스루풋 _____이더넷 프레임 _____네트워크 계층별 헤더 _____멀티코어 머신의 송신 능력 ___서버 구현의 간소화 _____libevent의 특징 0.3 [RPC 공략] 최소 기능의 통신 미들웨어 ___통신 라이브러리의 필요성 ___포맷을 결정하고 송수신한다 ___온라인 게임에서 사용하는 RPC의 전체적인 모습 _____RPC 스터브 코드를 자동 생성하는 RPC 툴 _____온라인 게임과 바이너리 데이터 교환 포맷/라이브러리 ___[보충] UDP의 이용 0.4 게임 프로그래밍의 기초 ___게임 프로그래밍의 역사 ___「점만 찍을 수 있다면 게임은 만들 수 있다」 인베이더 게임 ___가상의 코드로 알 수 있다! 게임 프로그램의 기본 해부 _____초기화 _____무한 루프 _____각 스프라이트의 동작 - 게임 로직의 본체 _____화면 표시 _____서브루틴 ___게임 프로그래밍의 비결 ___두 가지 프로그래밍 기법의 유사성 0.5 요약 ▣ 제1장 _ 온라인 게임의 역사와 진화 1.1 온라인 게임의 기술사 ___온라인 게임의 역사는 아직 50년 ___1950년 이전 : 계산기의 등장 ___1950년대: 초기 비디오 게임 ___1960년대 : 영향력을 가진 각종 머신의 등장 ___1970년대: 온라인 게임 기본 요소가 갖추어짐 ___1980년대: 네트워크 대전 게임의 등장 ___1990년대: 게임 시장의 확대 ___2000년대 전반 : 온라인 게임의 상업적 성립 ___2000년대 후반: 웹 브라우저 기반 MMOG의 상업적 성공 ___2010년대 이후 : 과연 어떤 일이 일어날 것인가? 1.2 [기술의 변천에서 알 수 있는] 게임 문화/경제권 ___기술의 변천도를 읽자 ___3개의 영역(카테고리) _____해커 문화권 _____콘솔/아케이드 게임 비즈니스권 _____마이크로소프트권 _____두 가지의 게임 경제/문화권 ___문화, 경제, 기술의 관계 1.3 요약 ▣ 제2장 _ 온라인 게임이란 무엇인가? 2.1 「온라인 게임」이라는 용어의 정의 ___온라인 게임의 4개의 측면 2.2 온라인 게임의 물리적 측면 ___물리적 구성요소 _____컴퓨터 네트워크 ___물리 모델/ 물리적인 네트워크 구성 _____이 책이 대상으로 하는 회선은 「인터넷」 기반 2.3 온라인 게임의 개념적인 측면 ___온라인 게임과 기본구조 _____게임 플레이의 기본 - 「인지」, 「판단」, 「조작」의 반복 _____비디오 게임의 구조 ___게임 플레이 공간 ___게임의 진행 ___하나의 게임의 진행을 공유한다 _____공유가 「가능하다」 2.4 온라인 게임의 비즈니스적 측면 ___비즈니스적 관점의 요구 ___테스트 플레이어를 효과적으로 모으고 싶다 _____클로즈 베타 테스트(CBT) _____오픈 베타 테스트(OBT) ___자주 갱신하고 싶다 _____(1) 정기적 패치 _____(2) 대규모 패치(확장 디스크, 추가 패키지) _____(3) 긴급 메인터넌스 ___머신의 대수와 회선 대역을 절약하고 싶다 _____(1) 인건비& (2) 설비 코스트 - 운영, 개발 후에 소요되는 코스트가 큼 _____머신 코스트의 견적 - 서버가 고장 날 확률을 포함해 둔다 _____회선 코스트의 견적 - 대역은 가능한 절약한다 ___작게 시작하고 싶다. 스케일러빌러티를 지니게 하고 싶다 ___다양한 과금 옵션을 제공하고 싶다 _____게임 포인트의 등장 - 과금의 세분화, 리얼타임화의 실현 ___공격자를 저렴한 비용으로, 빨리, 확실히 배제하고 싶다 _____상업적 의도의 어뷰즈 _____상업적 의도가 없는 어뷰즈 - 여러 가지의 공격, 3D 온라컀 게임 전용 게임 클라이언트 ___서비스 정지 시간과 횟수를 줄이고 싶다 _____(1) 계획적인 메인터넌스로 인한 정지 _____(2) 결함이나 공격에 의한 서비스 정지 ___게임 플레이 결과를 피드백하고 싶다 _____게임 플레이의 메타 정보 _____(1) 하이스코어 랭킹 _____(2) 플레이 실적 _____(3) 그 외의 통계 _____한층 더 고도의 기술이 요구되는 플레이 실적 ___더욱 간단하게 다른 플레이어와 만날 수 있게 하고 싶다 _____(1) 자동 선택식 _____(2) 전용 로비 _____(3) 가상 세계(비쥬얼 로비, 버추얼 로비) _____전용 로비 형식과 가상 세계의 차이점 _____플레이어 매칭의 향후 2.5 온라인 게임의 사람과 조직적 측면 ___온라인 게임 서비스의 운영에 관한 사람들 _____세 가지 기능과 분담 패턴 ___온라인 게임 서비스 운영의 3가지 전문 기능 _____만드는 사람들 _____반드시 필요한 4가지 직종 _____소규모 팀 _____대규모 팀 _____직종의 밸런스에서 엿볼 수 있는 게임 개발의 특유한 점 - 데이터 작성 스텝의 비율 ___운용하는 사람들 _____서버 설비 2.6 온라인 게임 프로그래머에 요구되는 지식군 ___온라인 게임 프로그래머에 필요한 능력과 경험 _____프로그래밍 기초 스킬 _____게임 프로그래밍의 기초 지식(온라인 게임 개발에서도 필요) _____게임 클라이언트 개발 지식 _____DB 지식 _____시스템 운용 지식S ___여러 방면에서 필요한 온라인 게임의 개발 지식 2.7 온라인 게임을 뒷받침하는 기술의 대구분 ___온라인 게임을 뒷받침하는 기술의 4가지 형식 _____C/S형과 P2P형 - 물리적인 구조의 두 가지 전형적 패턴 _____MMO형과 MO형 - 논리적인 구조의 두 가지 전형적 패턴 _____온라인 게임의 4가지 형식 - 물리적 구조×논리적 구조 2.8 개발 코스트를 좌우하는 기술적 포인트 ___온라인 게임과 개발 기법의 현재 ___온라인 게임의 게임 본체를 뒷받침하는 3가지 축 _____게임 데이터 형식 _____게임 통신 형식 _____게임 반응속도 2.9 요약 ▣ 제3장 _ 온라인 게임의 아키텍처 3.1 [게임 프로그램의 특성] 좋은 리스폰스를 계속해서 유지한다 ___리스폰스의 중요성 ___온 메모리가 필요한 이유 ___(1) 16밀리초마다 변화 _____게임 진행을 표현하는 데 필요한 정보와 그 사이즈 _____RDBMS를 이용해 구현할 수 있을까? - 온 메모리와의 비교 ___(2) 대량의 오브젝트 표시 _____패밀리컴퓨터와 CPU 사이클 _____플레이스테이션 3(PS3)과 CPU 사이클 - RDBMS 방식으로 개발할 수 있을까? ___(3) 플레이어의 조작을 예상할 수 없다 _____RDBMS 방식으로는 실현할 수 없는 정보량, 처리 속도 ___CPU와 동일 머신에 게임 진행 데이터를 배치해야 한다 3.2 온라인 게임 특유의 요소 ___통신 레이턴시 _____통신 시간의 내역 _____피할 수 없는 지연 - 지연과 게임 장르 ___대역 ___서버 머신 ___보안 _____치트 - 최대의 보안 이슈 _____치트는 왜 행해지는가? _____치트 행위의 수단 _____치트의 조작 대상 _____노이먼형 컴퓨터의 숙명 - 치트 행위에 대한 방지 서비스 _____무서운 치트 행위의 파급 효과 ___보조 시스템(주변 시스템) 3.3 물리 아키텍처의 상세 해부 C/S형, P2P형 ___기본적 네트워크 토폴로지 _____실제로 사용되는 것은 스타와 버스, 풀 메시 - 통신 레이턴시의 최소화 ___물리 아키텍처의 종류 ___C/S형 _____리플렉터형 ___P2P형 _____NAT 트래버설 ___C/S+P2P 혼합형 ___ad-hoc 모드 3.4 논리 아키텍처의 상세 해부 MO형 ___MO, MMO란? _____MMO와 MO의 하이브리드(혼합) ___MO형, MOG ___동기식 ___동기식/풀 메시형의 구현 _____각 단말(플레이어)이 송수신하는 정보의 내용 _____동기식/풀 메시형에 필요한 조건과 메리트 _____동기식/풀 메시형의 3가지 문제점 - 통신망과 송수신의 완전성의 취약점, 게임의 중도 참가 _____통신로의 신뢰성 _____「가장 느린 단말의 속도에 맞춰진다」는 문제 ___동기식/스타형 _____스타형이 가지고 있는 4가지 문제 _____동기식 전반의 큰 문제 - 게임 도중에 참가할 수 없다 _____동기식의 메리트와 문제 해결 방법 ___비동기식 ___비동기식의 구현 방침의 세우는 방법 - 게임 내용의 상세한 분석이 필수 ___3가지 기본 요소 「자신」, 「상대」, 「환경」 _____3가지 요소의 관계 ___(1) 자신과 상대 _____격투 게임의 예 _____공격, 방어, 타격 판정 _____격투 게임의 시퀀스 그림 _____추상도가 낮은, 원인을 알 수 있는 데이터를 송신할 필요가 있다 - 결과의 납득 _____결과가 어긋나는 문제 발생! ___결과의 정합성을 유지하는 방법 _____데미지를 발생시킨 쪽의 결과를 사용한다 _____데미지를 받은 쪽의 결과를 사용한다 _____방식 선택의 원칙 - 플레이어의 만족감 향상을 위해 ___(2) 자신과 환경 _____배타 제어가 필요한 타입의 환경 요소 - 경합하는 자원 「폭탄」 _____배타 제어가 필요 없는 타입의 환경 요소 - 줄지 않는 자원 「물」 _____게임의 환경 요소는 의외로 다루기 어렵다 - 일단 게임 내용을 상세하게 이해한다 ___배타 제어의 구현 _____아이템 듀프 문제 _____아이템에 고유한 ID를 부여한다 - 듀프가 일어났는지를 판정, 발생하는 문제 _____아이템 듀프의 대책 - 중재 역할의 소프트웨어를 배치한다. _____중재역의 기본 기능과 사용법 _____폭탄 이외의 환경 요소의 경우 ___자동적으로 상태가 변화하는 환경 _____동적인 환경에서 일어나는 문제 - 완전하게 병행 관리하는 방법으로는 어렵다 ___동적 환경에서 일어나는 문제의 대처법 선택 _____(1) 상대와 환경의 관계 3.5 논리 아키텍처 상세 해부 MMO형 ___MMO형, MMOG _____영속적이란? - 게임 플레이 소요 시간과 축적성 _____영속적인 데이터, 대량으로 축적되는 데이터의 일관성 유지의 어려움 _____클라이언트와 서버의 완전 분리 ___MMOG의 구조 _____MMO형의 구현 방침 - 브라우저식, 순수한 C/S모델 _____브라우저식과 동기식 및 비동기식의 차이 _____MMO형에 있어서 서버, 클라이언트의 기능 _____서버의 처리 - 서버 측의 게임은 계속 진행된다. ___MMO형만의 과제 3.6 정리 ▣ 제4장 _ [실전] C/S MMO 게임 개발 4.1 온라인 게임 개발의 기본적인 흐름 ___프로젝트 자료/성과물 _____준비와 초기 구현은 동시에 병행한다 ___개발의 진행과 자료 준비의 순서 ___기술자의 자료/성과물 4.2 C/S MMO 게임의 경향과 대책 ___C/S MMO 게임의 특징 ___C/S MMO형(MMO형) 게임의 특성 _____C/S MMO형의 제약 4.3 [기획 자료와 5개의 설계 자료] 가공의 게임 「K Online」의 개발에서 배운다 ___샘플 게임의 소재 찾기 ___기획 상세 자료 _____기획 상세 자료의 필요성 ___MMOG의 방대한 게임 설정 _____5가지 설계 자료 ___설계상의 중요한 판단 4.4 [1]시스템 기본 구조도의 작성 ___시스템 기본 구조도의 기본 ___확장성을 가진 서버 시스템이 필요 _____다양한 보틀넥 - 스케일업 방식의 선택에 대해서 ___게임 서버/DB의 보틀넥을 해소한다 ___아무것도 고려하지 않는 경우 ___공간 분할법 _____공간 카피 ___인스턴스법 ___패러렐 월드 방식 _____가장 보틀넥이 되기 쉬운 것은 DB의 쓰기 처리 _____패러렐 월드 방식의 DB 분할 _____패러렐 월드 방식의 문제 ___복수의 방법을 병용 ___각 방식의 도입 난이도 ___각 월드의 DB(게임 DB) 서버의 절대 성능 향상 _____애플리케이션단의 개선점 연구 ___K Online의 설계 사이징 _____보틀넥의 확인 _____설계 사이징에 대한 판단 원칙 ___게임 로직의 처리 부하로부터 사이징 ___게임 DB의 처리 부하로부터 사이징 ___규모에 대한 최소한의 검토 결과, 보다 나은 유저 체험을 위하여… ___서버의 기본 구조, [1]시스템 기본 구조도의 작성 4.5 [2]프로세스 관계도 작성 ___[2] 프로세스 관계도 준비 ___서버 접속 구성 ___서버의 접속 구성 ___패러렐 월드 방식을 사용하여 확장하는 경우 4.6 [3] 대역/머신 리소스 계산 자료의 작성 ___프로세스 리스트를 토대로 머신 리소스를 사이징 ___CPU 센트릭(중심적, 의존적) 머신, 스토리지 센트릭 머신 ___머신 리소스의 코스트 견적 _____머신 리소스 유지 코스트 ___대역 코스트의 견적 _____트래픽의 98%가 플레이어/NPC의 이동 통지이다 ___대역 반감을 위한 지침 _____기획의 조정 - 대역 삭감 작전 [1] _____프로그램을 연구 - 대역 삭감 작전 [2] ___대역 삭감에는 기획 내용의 재검토가 효과적 4.7 [4] 프로토콜 정의 자료의 작성 프로토콜의 기본적인 성질 ___[4] 프로토콜 정의 자료의 기본 ___「프로토콜의 기본적인 성질」의 핵심요소 ___프로토콜의 종류와 프로세스 관계의 종류 ___8 종류의 프로토콜 ___C/S MMO에서는 TCP를 이용한다 ___「프로토콜의 기본적인 성질」과 그 대응 일람표 _____프로토콜 설계의 기본 전략 4.8 프로토콜 정의 자료 프로토콜의 API 사양(개관) ___프로토콜 구현의 원칙 _____백엔드에 기본/범용 기능을, 프론트엔드에 전용 기능을 구현한다 _____백엔드에 프론트엔드가 의존하는 구조 _____프로토콜은 스테이트리스&단순한 기능으로 한다 _____외부로부터 오는 예외적 현상은 한 곳에 집중시킨다 _____우수한 API의 호출 시퀀스 - 호출하지 않는 것이 우수!? ___8가지 프로토콜의 기능/형태 개요 _____gmsv 프로토콜 _____loginsv 프로토콜 _____msgsv 프로토콜 _____dbsv 프로토콜 _____worldsv 프로토콜 _____commondbsv 프로토콜 _____authsv 프로토콜 _____logsv 프로토콜 ___4.9 [4] 프로토콜 정의 자료 프로토콜의 API 사양(상세) ___프로토콜의 API 사양(상세) 작업 ___API의 함수 정의 _____gmsv 프로토콜 _____API 타입과 메시지의 특성 _____loginsv 프로토콜 _____msgsv 프로토콜 _____dbsv 프로토콜 _____worldsv 프로토콜 _____commondbsv 프로토콜 _____authsv 프로토콜 _____logsv 프로토콜 ___정수 정의 ___API의 호출 시퀀스 _____필요한 시퀀스도 - 복수의 프로세스가 관계하는 일반적인 처리란 무엇인가? _____(1) 인증 _____(2) gmsv의 캐릭터 작성 _____(3) gmsv, msgsv에 로그인 _____(4) gmsv로부터 로그아웃 _____(5) gmsv의 캐릭터 이동 _____(6) gmsv의 캐릭터 인벤토리 조작(숍, 트레이드) _____(7) msgsv의 친구 목록에 친구를 추가, 삭제 _____(8) 온라인 친구에게 메시지를 송신한다. ___시퀀스도의 작성 포인트 4.10 [4] 프로토콜 정의 자료 패킷의 포맷 ___C/S MMO에서는 주로 TCP를 이용한다 ___C/S MMO는 전용 바이트 배열을 가지는 ___바이너리 프로토콜을 사용한다 ___바이너리 프로토콜의 구현 _____레코드의 크기 _____헤더 _____데이터 부분의 압축과 암호화 _____구현상의 요령 4.11 DB 설계도 ___중요한 테이블의 설계는 프로그래밍을 시작하기 전에 ___C/S MMO에서의 DB 구현의 역사적 변천 _____70~80년대:데이터의 영속화 없음. 부활의 주문 _____90년대:파일로 저장 _____2000년대 전반~:RDBMS ___K Online에 필요한 테이블 추려내기 _____영속화가 필요한 정보와 데이터의 포함 관계 _____데이터의 특성과 개별 테이블의 준비 ___DB의 성능 예측 _____DB의 처리 성능과 사이즈 _____테이블의 특성, 주의해야 할 테이블 _____발행하는 쿼리의 내용 - read편 _____발행하는 쿼리의 내용 - write편 4.12 서버/클라이언트 소프트웨어+미들웨어 실전에 빠뜨릴 수 없는 개발 기반 ___온라인 게임의 미들웨어 _____C/S MMO용의 미들웨어 _____풀 장비형 미들웨어 _____소규모형 MMOG 미들웨어 _____통신 미들웨어만을 이용 ___개발 기반 소프트웨어 즉시 시험해 볼 수 있는 C/S MMO 개발 체험 _____서버 관련 소프트웨어 _____클라이언트 관련 소프트웨어 4.13 프로그램을 작성할 때 기본 원칙 ___프로그래밍을 시작하는 방법, 이어가는 방법 ___데이터 구조 우선의 원칙 _____비디오 게임에서의 데이터 분류 ___데이터 구조를 구현하기 전의 검토 _____적 캐릭터와 팝 설정 ___플레이 가능 상태 유지의 원칙 ___백엔드는 나중에 만든다는 원칙 ___계속적 측정의 원칙 _____클라이언트 개발에서의 계속적 측정의 예 _____서버 개발에서의 계속적 측정 4.14 C/S MMO 게임 「K Online」의 구현 프로그래밍 작업 스타트! ___개발의 순서 ___K Onilne의 분담 계획 ___K Online에서의 「스켈레톤」과 「프로토타입」 단계 나누기 ___[스텝 1~2]스켈레톤~프로토타입 단계 _____스켈레톤 코드의 준비 _____[1] autocli _____[2] cli _____[3] 프로토콜 _____[4] ID _____[5] gmsv _____[6] dbsv ___「작동해 보지 않으면 알 수 없다!」 _____게임 개발의 난항 - 기업에 의한 온라인 게임 개발 ___스켈레톤의 전체 모습 _____cli의 내용 _____gmsb, dbsv, proto의 내용 _____어떤 순서로 무엇을 작성할 것인가 ___먼저 프로토콜 정의 파일 k.xml를 작성한다 ___프로토콜 정의 포인트 ___통신 소통 확인:ping 함수 ___어카운트 등록&어카운트 인증: ___캐릭터 작성:createCharacter 함수 ___로그인:login 함수 ___지상 이동:move함수, moveNotify _____매스 단위 _____경로 탐색과 실제 이동 처리 _____이동 경로를 송신하는 방법 - 최종 결과를 우선하여 송신한다 _____이동 결과의 통지 범위 _____moveNotify 함수 _____attack 함수, attackNotify 함수 ___gmsv/Makefile를 작성한다 ___gmsv/climain.cpp와 gmsvmain.cpp를 샘플에서 카피 _____sv.cpp에 signup 함수를 구현 _____「dbsv 1회 왕복」형의 요구와 스레드 ___자동 테스트 클라이언트 autocli의 구현 _____테스트 상태 변화 _____autocli의 main() 함수 _____signup() 함수 ___그래피컬 클라이언트 cli의 작성과 동작 확인 _____SDL _____그림을 그린다 _____동작 확인 _____폰트 처리의 구현 _____적을 등장시킨다, 적을 뒤쫓는다 _____적을 쓰러뜨린다, 경험치가 쌓인다 _____다음에도 플레이 가능하게 한다 - 플레이 상태의 저장 ___스켈레톤 이후의 개발 4.15 정리 ▣ 제5장 _ [실전] P2P MO 게임 개발 5.1 P2P MO 게임의 경향과 대책 ___P2P MO와 액션 게임 - 게임 상태가 높은 빈도로 변화한다 ___RPC형의 구현과 공유 메모리형의 구현 ___P2P MO 게임의 특징 ___P2P MO 게임의 이점 ___기획 초기부터 「멀티 플레이」를 의식한다. 5.2 가공의 게임 「J Multiplayer」의 개발에서 배운다 ___J Multiplayer - K Online과 비교 ___P2P MO 게임 개발의 기본적 흐름 ___P2P MO 게임 개발의 성과물 - 개발의 단계와 각종 자료 _____기획 상세 자료 ___C/S MMO와의 데이터량/규모의 차이 5.3 P2P MO 게폀의 설계 자료 ___시스템 기본 구조도 ___프로세스 관계도 _____스타형인가, 풀 메시형인가 _____우선은 스타형을 검토한다 _____게임 도중에 참가하는 구현 ___대역/머신 리소스 계산 자료 ___프로토콜 정의 자료, API 사양 _____프로토콜의 시퀀스도 _____함수나 정수의 정의 ___대역 소비량의 사이징 _____「600분의 1」 - 게임 기획 내용을 정밀 조사하여 해결책을 찾는다. ___그 외의 자료 5.4 서버/클라이언트 소프트웨어+미들웨어, 기본 원칙 ___P2P MO 개발 성과물의 실제의 모습 ___P2P MO용 미들웨어 ___프로그램 작성 시의 기본 원칙 5.5 P2P MO 게임 「J Multiplayer」의 구현 ___J Multiplayer의 작업 분담 계획 ___구현 작업의 흐름 - K Online의 복습 ___J Multiplayer의 개발 요령 ___제1단계에 필요한 요소 ___클라이언트 프로그램의 구현 예 ___「공유 메모리형」으로 구현 - 구현 개시 _____경합상태 - 공유 메모리형에서의 주의점 _____락(Lock) _____P2P MO와 경합상태 ___P2P MO의 구현에서 어떤 방식으로 경합을 방지하는 것이 좋은지에 대한 판단 _____동기화 관련 구현 예 _____가동물 열거와 클래스 설계 _____기본 동작의 취급을 매트릭스화 _____게임 진행 상태를 변경하는 조작에 대한 사양 정의 _____PlayerCharacter 처리의 사양 정의 _____Enemy 처리의 사양 정의 Enemy/Create _____Bullet 처리의 사양 정의 ___공유 메모리를 어떻게 코드화할까 _____RPC형 - C/S MMO의 경우 _____공유 메모리형 - P2P MO의 경우 _____RPC형의 코딩량 - move(5,5) _____공유 메모리형의 코딩량 - move(5,5) _____공유 메모리형의 강점, 약점 ___[보충]코드를 간략하게 할 수 있을까? ___SyncValue 클래스 5.6 C/S MO 게임을 뒷받침하는 기술 [보충] ___C/S MO와 NAT 문제 ___NAT, NAT 문제란? ___NAT 트래버셜 - 접속 통신로를 확립하는 기술 _____NAT 트래버셜 기술의 한계 _____NAT 트래버셜 기술을 사용하는 경우의 또 다른 단점 ___NAT 문제의 현실적 대처 ___릴레이 서버 ___릴레이 서버의 트레이드오프 _____(1) 지연이 커지는 문제 _____(2) 서버 대역 코스트가 발생하는 문제 5.7 정리 ▣ 제6장 _ 온라인 게임의 보조 시스템 6.1 보조 시스템에 요구되는 각종 기능 ___기존 서비스로 알아보는 보조 시스템의 기능 _____범용 _____게임기용 _____웹 브라우저 베이스 게임 전용 _____기존 미들웨어 ___기존 서비스의 기능 일람 ___Web 베이스 개발 방법과 C/S형의 개발 방법 6.2 커뮤니케이션/ 통신 보조 시스템 ___플레이어 매칭 _____P2P MO 게임에서 멀티 플레이가 가능한 조건 _____매칭 서버 _____멀티 플레이를 실현하는 두 가지 조건의 구체화─J Multiplayer의 경우 _____멀티 플레이를 실현하는 두 가지 조건의 실현─J Multiplayer의 경우 _____매칭 결과 화면 ___로비 _____로비와 매칭 _____스타크래프트 II의 예 _____구현 포인트 ___릴레이 서버 _____릴레이 서버에 요구되는 성능 ___채팅 _____자작 채팅의 구현 _____자작 채팅의 기본 동작 _____메시지 전달의 규모 ___메일 ___친구 목록 ___프레젠스 _____게임 서비스의 프레젠스 특징 _____프레젠스의 구현 ___락 서버 _____락 서버의 구현 ___블랙 리스트 _____블랙 리스트의 구현 ___보이스 채팅 6.3 게임 클라이언트 구현의 보조 시스템 ___플레이 실적 관리 _____플레이 실적 관리의 구현에 대해 ___스토리지 기능 ___(게임 클라이언트) 업데이트 _____업데이트의 기본 기능 _____업데이트와 액세스 패턴 _____업데이트 기능을 자작하는 방법 ___랭킹 _____랭킹 기능의 구현─온라인 게임 특유의 요구 사항 ___잠정 랭킹법 6.4 운영 보조 시스템 ___뉴스 배포 _____뉴스 전달 방법 6.5 과금 결제 관련 보조 시스템 ___과금 인증 _____온라인 게임의 과금 _____결제 처리의 구조 _____결제 시퀀스 _____결제 회사를 사용하는 이점 ___버추얼 포인트 관리 _____P2P MO의 경우, C/S MMO의 경우 _____버추얼 포인트 관리 서버의 구현 _____버추얼 포인트 관리의 주의점 6.6 그 외의 보조 기능 ___게임 데이터 열람/검색 툴 _____플레이 데이터의 저장 상태 _____깔끔하지 않은 저장 상태 _____기계도 인간도 읽을 수 있는 형식으로 해 둔다 _____키워드 검색을 위한 방법 연구 _____게임 설정 데이터와 DB ___워드 필터 6.7 정리 ▣ 제7장 _ 온라인 게임 운영을 뒷받침하는 인프라 7.1 인프라 구축의 기초지식 ___C/S MMO와 P2P MO의 인프라[복습] ___인프라 구축에 필요한 작업 ___인프라에 소요되는 코스트와 견적 ___코스트의 감각, 단위 ___온라인 게임 서버에서 어느 정도 허용되는 조건 ___하드웨어, 정보 기기 _____서버 머신 _____스토리지 _____네트워크 스위치 _____라우터/방화벽 ___소프트웨어 _____서버 OS _____DBMS _____바이러스 스캔 소프트웨어 _____가상화 소프트 ___데이터 센터 관련 _____데이터 센터 이용료 _____데이터 센터 구축 비용 ___서비스(데이터 센터 관련 제외) _____서버 감시 서비스 _____도메인 사용료, 전자서명 서비스료 ___회선 이용료 ___전기세 7.2 개발자를 위한 인프라 구축 노하우 ___서비스 스케일의 확대/축소 ___일반적인 환경 _____사이징이 어려운 조건 ___부하 곡선 _____최초에 피크가 온다는 전제로 설계한다 _____K Online의 경우 _____J Multiplayer의 경우 ___개발자를 위한 인프라 구축의 포인트 ___서버 디플로이먼트 _____메인터넌스 시간과 디폴로이먼트의 자동화 ___스테이징 _____온라인 게임 고유의 주의점 ___서버 모니터링, 생사 감시 ___로그 출력/관리 _____로그 방침 - 「가능한 모두」, 「원인과 결과 양쪽 모두」 _____로그 출력 방법 - 추천하는 방법, syslog의 문제점 _____로그 서버 7.3 K Online, J Multiplayer의 인프라 구축 ___K Online의 인프라 _____알파 테스트 _____클로즈 베타 테스트 _____오픈 베타 테스트 ___J Multiplayer의 인프라 _____일부 보조 시스템은 자작한다 _____먼저 부하 검증을 실시하여 인프라를 사이징한다 _____동시 플레이수, 등록 유저수 - 랭킹의 경우의 일반적인 부하 검증 절차[1] _____플레이 스타일을 예측한다 - 랭킹의 경우의 일반적인 부하 검증 절차[2] _____부하 검증 결과를 설계에 반영시킨다. 7.4 부하 테스트 ___부하 테스트의 준비 ___K Online의 상용 환경 부하 테스트 _____K Online의 테스트 시나리오 _____테스트의 분할 _____부하 테스트에 필요한 환경 ___부하 테스트에서 사용하는 서버 감시 커맨드 _____vmstat, /proc/interrupts _____ps _____top _____netstat ___J Multiplayer의 상용 환경 부하 테스트 _____J Multiplayer의 테스트 시나리오 _____부하 테스트에 필요한 환경 7.5 운용 개시 ___운용 개시 직전 - 시큐리티 설정의 확인부터 _____시스템 외부로부터의 공격에 대한 시큐리티 _____시스템 내부의 관리 수단에 관한 시큐리티 ___운용 개시 직후 - 시스템 감시 ___수십 대의 서버를 그룹화 ___트러블이 발생했을 때의 대응 7.6 요약 ▣ 제8장 _ 온라인 게임의 개발 체제 8.1 게임의 기획 내용과 개발 팀 온라인 게임 특유의 과제 ___「게임의 기획 내용」이 팀 운영의 열쇠를 쥐고 있다 ___게임 데이터의 영속화 정도 _____운영 개시 후 3개월이 가장 힘들다. 운영은 5~10년 계속한다 _____게임의 운영과 기술자 _____실제의 프로젝트 관리에 있어서의 과제 ___게임에 있어서의 플레이어들 간의 관계 ___플레이 결과의 공유 범위 ___채팅 시스템의 내용 ___메인터넌스와 업데이트의 스케줄 ___소스 코드의 규모 _____빌드 시간 _____프로그램의 기동에 걸리는 시간 _____평가를 위한 스텝 수 _____서버 프로그램의 기동 절차 _____데이터의 밸리데이션 8.2 온라인 게임 개발 팀의 실제 일반 소프트웨어 개발에도 공통되는 화제 ___작업 분담 ___온라인 게임 프로그래머의 지속적인 스킬 업 방법 _____무예의 스텝 업 지침 「수·파·리」에서 배운다 _____「수」의 단계 - 흉내부터 시작할 것 _____「파」의 단계 - 세미나, 컨퍼런스, 그리고 경계 영역으로 뛰어들 것 _____「리」의 단계 - 엔지니어의 스텝 업, 그 다음에 놓여 있는 것은... ___프로젝트 관리방법 ___개발 환경의 선정 ___프로젝트 이관 _____테스트 준비 _____개발 환경의 구축 시간은 짧다 _____정보 시큐리티의 조절 8.3 요약 |
|
지금으로부터 약 20년 전인 고등학교 시절, 밤마다 나는 구세주 아바타가 되어 브리타니아를 여행했다. 활과 석궁의 명수인 음유시인 이올로, 언제나 믿음을 주는 강직한 기사 듀프레, 술과 여자를 좋아하는 레인저 샤미노. 이들은 브리타니아라는 세계에서 둘도 없는 나의 벗이었다.
환상의 세계에서 벗어나 다음날 지친 몸을 이끌고 학교에 가면 이 울티마 6라는 게임을 하는 다른 현실 세계의 친구들과 어젯밤 겪었던 서로의 무용담을 이야기했다. "야, 어디어디 좌표에 가니까 보물이 숨겨져 있더라", "아마겟돈 마법을 쓰면 로드 브리티쉬만 남기고 브리타니아의 모든 사람들이 죽는대." "정말? 해봤어?" "아니 아직 레벨이 안 돼서 아마겟돈 못써" 이렇게 서로의 정보를 다음 날이 돼서야 조각 맞추듯 공유할 수밖에 없던 우리는 어느 날 놀라운 생각을 해내게 된다. "우리가 이렇게 따로 떨어져서 게임을 하는 게 아니라 동시에 같이 플레이할 수 있다면 정말 재미있지 않을까?" "모뎀으로 연결해서 말이지!!" "맞아, 맞아. 이 브리타니아의 모든 사람이 실제로 살아있는 플레이어이고 게임 안에서의 사람들과의 대화가 곧 실제 사람과의 채팅이 되는 거지" "그거 괜찮겠다!!" 이 시절의 PC통신이란 2400bps급 모뎀을 이용한 것이었으며, PC통신의 가장 큰 즐거움은 모르는 사람과의 대화, 즉 채팅 정도에 지나지 않았다. 모든 게임은 아니었지만 모뎀을 이용해 1:1대전을 지원하는 게임이 간간히 있었던 것으로 기억한다. 하지만 RPG 장르의 게임에서 모뎀 플레이나 2인용 플레이를 지원하는 게임은 아직 없었다. 그중 조금 똑똑한 친구(공부도 잘했다)가 말을 꺼냈다. "게임이란 한 사람이 주인공이고 그 사람을 중심으로 하는 스토리가 있고 거기에는 기승전결, 즉 엔딩이 있게 마련이야. 근데 만약 이런 방식이라면 누가 주인공이 되는 거지? 네가 이 게임을 클리어 해버리면 같이 하던 나머지 사람들은 중도에 끝나버리게 돼. 모두가 주인공이라면 그 세계의 스토리는 누구에게 맞춰야 하지? 따라서 이러한 방식은 성립될 수 없어. " 그 친구의 말에 우리는 이렇다 할 해결책을 내놓지 못했다. 인터넷이 존재하지도 않던 그 시절, 우리가 얼마나 대단한 발상을 해낸 것인지도 모르는 채 으레 그러한 대화는 흐지부지 끝나게 마련이었다. 하지만 세월은 흐르고 인터넷이 일반에 보급되기 시작했으며, 그 후 얼마 지나지 않아 그 시절 우리가 꿈꿨던 바로 그러한 방식의 게임이 세상에 나타난다. 그것도 우리가 해결하지 못했던 공부 잘했던 친구가 던졌던 물음을 보란 듯이 해결한 채. "함께 플레이하는 것의 즐거움"이란 그 어떤 장르의 게임이라도 감히 부정할 수 없는 것이다. 아무리 재미있는 내용과 콘텐츠를 준비한 게임이라도 이 "함께 플레이하는 것의 즐거움"을 뛰어 넘을 수는 없다. 일본의 게임 시장도 이러한 사실을 모르는 것은 아니었다. 하지만 콘솔이 가진 하드웨어의 특성, 또 그동안 이뤄낸 시장에 대한 폐쇄적 자존심, 또 일본 내 PC게임 유저는 극히 드물다는 세 가지 이유로 게임에 네트워크를 접목시키는 작업을 소홀히 하고 만다. 그 사이 한국은 리니지, 라그나로크 등의 타이틀이 흥행에 성공을 거두며 온라인 게임에 관한 한 세계 어느 게임업계보다 앞서 나가게 됐다. 이러한 상황을 고려해 볼 때 이러한 내용의 책이 온라인 게임 강국인 대한민국에서 먼저 출간되지 못했다는 사실이 조금은 안타깝긴 하지만 일본에서 출간됐다는 사실 자체는 무척이나 고무적인 일이다. 이 책의 저자인 나카지마 켄고는 메탈기어 솔리드의 제작자인 코지마 히데오나, 그란투리스모 시리즈의 야마우치 카즈노리와 같은 콘솔 계열에서 활동하는 스타 제작자는 아니다. 어디까지나 매일 매일 코드와 싸워야 하며, 고객과 부딪혀야만 하는 평범한 IT 업계의 프로그래머다. 하지만 오히려 그렇기 때문인지 콘솔 계열의 게임 기획자가 가질 수 없는 서버/인프라에 대한 식견, 프로젝트 운영 노하우, 소프트웨어 개발론 등에 대해 곧바로 현장에서 적용할 수 있는 "자신의 경험에서 비롯된 살아있는 지식"을 독자에게 전해준다. 이 책의 원서 부제가 "장엄한 플레이 공간의 뒷무대"이듯 게임의 가상세계라는 무대의 뒷편에서 벌어지는 일들에 대해 저자는 단순히 코드 위주의 설명을 넘어서는 기획, 기술, 노력, 설비, 관리 등의 폭넓은 관점을 가지고 쫓아나간다. 따라서 이 책은 온라인 게임 업계에 종사하는 사람들을 위한 바이블이 될 수 있을 것이다. 단순히 코드가 궁금한 사람들을 위한 책이 아닌, 이 업계가 업무가 흘러가는 모습은 이러이러하다, 라는 종합적인 식견을 쌓고 싶은 독자가 있다면 반드시 이 책을 읽어보길 권한다. 훗날 게임 업계에 뛰어들 준비를 하고 있는 학생들은 물론이거니와 게임은 아니지만 서버 관리 등 IT서비스 분야에 종사한다면 큰 도움이 될 것이다. 더 나아가 IT 관련 종사자가 아닌, 단지 게임을 좋아하는 사람들에게도 본문의 코드를 이해해야 한다는 의무감만 던져버린다면 부담 없이 읽을 수 있는 흥미로운 내용으로 가득하다. ---본문 중에서 |
|
이 책은 리얼타임 통신을 하고 대량의 통신량을 동반하는 멀티플레이어 타입의 게임 개발에 중점을 두고 설명하고 있으며, 일반 프로그래머가 고가의 미들웨어나 특수한 개발환경을 이용하지 않고도 온라인 게임을 제작할 수 있게 철저히 기초 지식을 설명합니다. 책에서 예로 드는 일반적인 코드에 대해서도 C/S MMO 게임과 P2P MO 게임의 두 가지 패턴을 기술합니다. 아울러 게임의 운영이나 인프라에 관한 주제도 소개함으로써 온라인 게임 개발 기술의 전체적인 면모를 살펴볼 수 있습니다. 이 책의 내용은 프로그래머를 대상으로 하지만 온라인 게임을 둘러싼 기술의 전체적인 개요를 살펴볼 수 있다는 점에서 온라인 게임 비즈니스에 뛰어들고자 하는 게임 프로듀서나 기업 경영자, 혹은 온라인 게임에 관심이 있는 여러분들께 도움될 것입니다.
★ 이 책에서 다루는 내용 ★ 제0장 [속성] 온라인 게임 프로그래밍 - 네트워크 × 게임 프로그래밍 기술 기초 제1장 온라인 게임의 역사와 진화 - 게임이 「네트워크」를 도입하다! 제2장 온라인 게임이란 무엇인가? - 다양한 각도에서 보는 「온라인 게임」 제3장 온라인 게임의 아키텍처 - 게임의 재미와 기술적인 제약과의 싸움 제4장 [실전] C/S MMO 게임 개발 - 상시 가동하는 서버 제5장 [실전] P2P MO 게임 개발 - 전용 서버 없이 액션 게임을 구현한다 제6장 온라인 게임의 보조 시스템 - 서비스 강화를 위해 빠질 수 없는 장치들 제7장 온라인 게임 운영을 뒷받침하는 인프라 - 구축, 부하 테스트, 운영 개시 제8장 온라인 게임의 개발 체제 - 팀 운영의 과제 |