Ndc2010 김주복, v3. 마비노기2아키텍처리뷰

NDC2010 | 김주복

완벽한 MMO 클라이언트 설계에의 도전

M2아키텍처리뷰
… 질 나 쁜 낚 시 제 목 죄 송 합 니 다 : $ …

Ⓒ 2010 NEXON Corporation & devCAT Studio. All Rights Reserved
M2 team, Game Development Team for Project M2 in longCAT (The 3rd New Development Division in NEXON Corp.). M2 team Director is Kim, Dong-Gun | Project M2 is produced by Kim, Dong-Gun
GT-R team, Engine Development Team for Project M2 and more. GT-R Team Technical Director is Jeon, Hyeong-Kyu

개발중
이 강연 내용은 현재 개발 중인 게임의
구현 방식에 대한 것으로,
최종 게임에서는 강연 내용과
다른 형태로 구현되어 있을 수도 있습니다.

“완벽”한 설계?
자동기술법에 의해서 마구잡이로 떠오르는 이미지를 따라 망상력을 전개해보면…

한국 MMO 클라이언트편

설계의 달인

“완벽”한
설계의
이미지?

내가 요즘에 게임 유지보수를 하고 있는데, 느낀게..

ㅈㄴ 급하다고 가라 코드 넣으면 안될거 같애.

근데, 우린 매주 패치하느라 넣은 코드 안빼잖아.

우린 안될꺼야. 아마.

10

MMO 설계는 어렵다
복잡한 인터랙션 | 바쁜 출시/패치 일정 | 널뛰는 게임 디자인 | 레가시 코드의 압박

하지만…잃어버린 14년?
<바람의 나라> 출시 1996년 | 2010년 현재, MMO 설계에 대한 업계의 컨센서스?

※ 전 와우 24렙에서 접었습니다, 와우 잘 몰^라요-

…우리는 그냥
여유가 있는 없든
제대로 된 설계란 걸
못 하는 거
아닐까?

직업인으로써,
엔지니어로써
당 당 하 고
후 회 없 는
완벽한 MMO
프레임워크를
만 들 어 보 자

20

난이도
대상
강연내용

김주복
마비노기 시리즈 설계 10년차
beforu.egloos.com | manarivu.tistory.com
twitter.com/eiaserinnys

2001 무선사업팀 도트디자이너
2001 마비노기팀 리드 프로그래머
2003 마비노기 프로그래밍팀 팀장
2005 그룹웨어 개발팀 팀장
2006 W팀 테크니컬 디렉터
2008 개발3본부 3실 실장
2009 프로젝트 M 2 개발 디렉터
2010 신규개발3본부 1실 실장

논의를
시작하기에
앞서…

완벽한 설계는 대체 뭐지?
요구사항에 따라 다르고 | 장르에 따라 다르고 | 예산에 따라 다르고 | …

기준을 정해야 함
확장성을 우선하는지 성능을 우선하는지…
우선 순위에 대해서 디렉터부터 모든 구성원이 동의할 필요가 있음

김주복, AOPM 세미나 “#13 일을 추진하는 방법”

성능+유지보수성
도전적인 목표 | 개념적으로 올바른 구조를 우선 | 문제가 되는 부분을 선별적으로 해결

공세적 기술개발로 대비
설계에 집중할 수 있도록 성능 문제가 될 만한 부분은 사전에 대응하는 기술을 개발

렌더링
버텍스 트랜스폼 부하 | DX 커맨드 제출 비용
전형규, NDC2010 “마비노기 2의 캐릭터 렌더링 기술”

애니메이션
늘어난 본으로 인한 L2 캐시 미스 | 절차적 본 연산 부하
김주복, NDC2009 “프로젝트 M2의 절차적 리깅 시스템”

객체 설계의 원칙 준수
요구사항과 성능을 희생하지 않고 교과서에 실을 만한 설계가 실현 가능함을 증명

유력 용의자 사전 색출
마비노기, 마비노기 영웅전 등 이전 게임의 코드를 리뷰 | 자주 설계가 꼬이는 부분에 집중

구조적 의존성 최소화
새로운 기능의 구현이 운영중인 다른 시스템에 버그나 악영향을 미치지 않도록 구조화

모듈화+데이터드리븐
기능적으로 직교인 모듈화를 통해 수평적 확장 | 결합 및 처리 절차를 데이터 드라이브

로직의 재활용
프리젠테이션 레이어 + 게임 로직의 재활용 | 신규 개발에서 뻔한 부분은 넘기고 새 기능에 집중

적지 않은 게임들이 많은 공통점들을 갖고 있다 (야)

엄밀한 레이어 구분
추상적인 게임의 동작 레이어와 실제 게임 구현 레이어를 분리 | 최대한 재활용성을 확보

충분한 문서화
라이브 기간의 인력 교체를 상정 | 개념과 동작을 충분히 명문화하는 것이 목표

40

…신규 개발하면서 문서를 꼼꼼히 쓰겠다고?

자기반영적 시스템
문서로 남기는 것은 귀찮다 한계가 있다 | 시스템이 자신의 동작을 설명하는 것을 목표
조정훈, NDC2010 “테스트 환경의 진화 : 시각화/리플레이”

해결해야 할 문제가 많고
개발 진도도 뽑아야 한다
한 번에 완벽한 설계를 내놓는 전략보다
부분적으로 작은 시도를 진행하고 끊임없이 리팩터링하는 전략을 활용
Responsive Design? (http://agile.egloos.com/5106266)

43

레이어 아키텍처
아키텍처에 대해서 생각한다면 가장 첫 단계 | 시스템을 추상화 수준에 따라서 구분

슈가
코팅

실제
컨텐츠

밑준비

DIP Dependency Inversion Principle
상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다
추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에 의존해야 한다

엄밀하게 레이어 구분
메시 관리나 애니메이션 처리와 같은 프리젠테이션 지식을 추상화
이런 식의 구분이 가능하다는 사례의 의미

0.System
게임을 OS 위에 올리기 위한 서비스

1.GenericGame 2.Presentation
‘게임’에 공통적 서비스 표현을 위한 서비스

3.Mabinogi2
1과 2를 구현하고 결합해서 게임을 정의

0.System


3.Mabinogi2

CORE.*
최하위 공통 서비스 레이어
시스템 프로그래밍 서비스 제공
50

0.System


3.Mabinogi2

Framework.*
자원 관리 등 게임에 특화된
시스템 서비스 레이어
이 레이어는 ‘게임이라는 개념’을
알고 있다고 가정

0.System


3.Mabinogi2

메인루프의 문제?
일반적으로 프로젝트 전체에서 가장 단단한(=수정할 수 없는) 구조
입출력과 게임 로직, 프리젠테이션 시스템과 강력하게 결합, 재활용을 가장 크게 방해

난제1:플레이방식변경
게임 도중에 다른 미니 게임으로 전환? | 이런 미니 게임이 여러 종류?

Grand Theft Auto 4, Rockstar

난제2:멀티세션
화면 분할로 두 명이 다른 지역에서 게임을 플레이?
한 화면에 게임 화면을, 다른 화면에 UI를 표시한다면?

Gears of War 2, Epic

난제3:Play-In-Editor
툴에서 게임 플레이를 하도록 지원해야 한다면?
정적 테스트를 위해서 게임 로직을 따로 돌려야 한다면?

60
Cryengine2, Crytek

F*E$%&^(W$EA_(G;
이걸뭐어쩌ㅏ라ㅁㄴ이ㅏ럼ㅈ49058ㅕㅂㅈ30ㄷ9ㅁㅅㅎ겨ㅓㅋ퍄ㅏ-90ㅂㅈ3ㅁㅅㄷㅎㄱ키ㅏ

2007.4.12.입력처리기구조.ppt 2008.9.9-입력에서로직까지.jpg

캐릭터 로비
객체 관리와 렌더링 로직은 공유하지만 게임 업데이트는 사용하지 않는다

루프를 기능별로 분해
입출력 배분 | 프리젠테이션 처리 (렌더링, 오디오, …) | 게임 시뮬레이션 업데이트

논리적 게임월드
물리적 출력장치
(뷰, 사운드 등)
물리적 입력장치
OS가 인지하는
메인루프

ForEach Console
UpdateInput
ForEach GameLoop
UpdateAndRender
ForEach Console
Present ForEach GameLoop
UpdateInput

※ 실제로는 멀티 코어 지원 때문에 여기에 보이는 것보다 상당히 복잡하다

다양한 테스트 모드
기본 전투 게임 플레이 테스트 모드 | 캐릭터 뷰어 모드 | 물리 테스트 모드 | …

M2GameLoop

M2DevLoop

ShowRoom
GameLoop

Parade
GameLoop

백그라운드 루프
두 루프가 한 콘솔에 업데이트 | 클라이언트 상태 로깅 | 애셋 관련 에러 로깅

…혹은 텍스트 콘솔
애니메이션 전처리 | 클라이언트 사이드 로직 유닛 테스트 등

AnimationProcessLoop

70
70

컴퍼넌트?
연관된 기능과 데이터를 추상화하고 캡슐화한 소프트웨어의 단위

컴퍼넌트는 상식?
단방향 그래프로 객체의 관계를 표현할 수 없다 | 상속은 문법적으로 끊기 어려운 의존성
컴퍼넌트를 어그리게이션하여 객체를 표현하는 것이 유연하고 세련된 방식

김성헌, KASA2008 “C++ Component System” 조정훈, NDC2009 “최소 의존 게임 컴포넌트 시스템”

컴퍼넌트의
장점에 대한
설명은 과감하게
생략하고..

컴퍼넌트통신=메시지?
혹은 다른 컴퍼넌트의 인터페이스를 사용해서 메소드를 호출
게임 개발 커뮤니티에서 컴퍼넌트 시스템을 말할 때 당연하게 언급하는 내용이지만…

GDC Canada 2009 “Theory and Practice of the Game Object
이창희, KASA2008 “Entity System” Component Architecture”

의문1:OCP위반 혐의 Open-Closed Principle
컴퍼넌트 A가 일을 하기 위해서 컴퍼넌트 B 인터페이스에 직접 의존한다면
컴퍼넌트 B에 대한 수정이 컴퍼넌트 A의 수정을 수반해야 한다

의문2:절차에 대한 지식
컴퍼넌트가 형식적 OCP를 준수하기 위해서 메시지를 사용하면
여러 컴퍼넌트가 협업해야 하는 절차에 대한 지식이 메시지 전달 순서로 전환되는 셈
다자 관계의 처리에 매우 취약

의문3:메시지 분배 과정
시리얼라이즈와 디시리얼라이즈가 객체의 책임이 아닌 것처럼
메시지 해석 및 분배도 컴퍼넌트의 책임은 아닌 게 맞지 않나?

Nebula3의 사례

극단적인 설계 실험
OCP를 만족하면서도 다자 관계 절차 처리에 적합한 방법을 찾기 위한 시도

OCP를 맹목적으로 준수
컴퍼넌트는 다른 컴퍼넌트를 절대로 알아서는 안 된다

객체Entity,Object는 없다
객체에 컴퍼넌트의 지식이 없다면 존재 의미가 없고,
반대로 컴퍼넌트의 목록을 안다면 OCP 위반이므로
객체란 것은 세상에 존재하면 안 된다

극단적인 설계 실험에 몰두하고 있는 모습 (대역 재연)

1. 다른 컴퍼넌트 참조 금지
한 컴퍼넌트가 다른 컴퍼넌트를 참조하는 것을 엄격히 규제

2. 이벤트로 통지를 선호
다음 처리가 필요한 컴퍼넌트에게 메시징하는 대신
사건 발생을 알아야 하는 쪽이 리스너를 등록

3. 메시지 자체를 객체로 간주
컴퍼넌트가 메시지를 받아서 일을 하는 게 아니라
일이 컴퍼넌트를 찾아서 절차를 수행한다

“아니, TD 양반.
이게 무슨 소리요,
메시지가 객체라니.” 80

기존의 방식
어떤 절차를 수행하고자 하면 컴퍼넌트가 다른 컴퍼넌트에게 메시지를 보낸다

실험적인 방식
어떤 절차를 수행하고자 하면 절차 객체를 만들어 실행
이벤트 와이어링은 객체의 셋업 과정에서 처리
게임 월드

핸들(itemHandle)로
컴퍼넌트 EquipmentTag를 룩업

월드 객체(=레지스트리 내의 싱글턴)의
아이디로 컴퍼넌트 FieldInventory를 룩업

깔끔한 거 같긴 한데…
컴퍼넌트간 의존성도 사라지고 절차 중심으로 기술할 수 있게 된 반면
초기부터 다른 컴퍼넌트에 의존성을 가질 수 없는 컴퍼넌트는 라이트해지고
프로시저 레이어는 난잡하고 비대화해질 것이라는 예측이 가능

…왜 슬픈 예감은 틀린 적이 없나…

재앙 발ㅋ생ㅋ
컴퍼넌트는 일도 안 하고 배째라식 세터/게터 노출
인테그레이션 레이어는 클라이언트 전 범위의 객체가 너나없이 날뛰며 해적왕을 꿈꾸고
절차를 강조했더니 작업자들이 발상하는 방식도 절차적 프로그래밍으로 퇴행

♡ 대 개 발 팀 긴 급 담 화 문 ♡

잠시 정규 업무를 중단하고
중대 현실 도피를 하겠습니다.

1차정리:규칙을 분리
절차가 아닌, 게임의 규칙을 정의하는 프로시저를 인테그레이션 레이어 최상위로 분류
객체의 기능에 해당하는 프로시저를 따로 분류 (생성/파괴 등)

2차정리:컴퍼넌트 정리
로직 프로시저 중 컴퍼넌트를 완결하는 기능에 해당하는 항목을 별도 분류

개념적인 컴퍼넌트를 구성
InventoryProc::Create PickUpItemFromWorld
class Inventory

예전과 마찬가지 상태로 객체의 생성과 어느 한 컴퍼넌트가
다른 컴퍼넌트에 대해서 이벤트 핸들러 와이어링 과정 단독으로 수행할 수
전혀 모르는 컴퍼넌트 혹은 다른 컴퍼넌트를 없는 종류의 작업들
참조하지만 (ex. 스플래시 공격)
일반적인 설계로는
이 컴퍼넌트의 기능인
프로시저들

기존 마인드모델에 부합
객체를 구분하는 동시에 컴퍼넌트 소속이 아닌 로직 프로시저를 구분하는 준거점
전통적인 OOP 방법론과 컴퍼넌트 설계 방법론을 적용 가능
무엇보다 여기 해당되는 함수들이 많지 않음

마음의 평화를 찾은 프로그래머들의 훈훈한 대화

남은 과제?
아직까지도 컴퍼넌트의 의존성을 제거하는 실험은 진행중
하지만 컴퍼넌트 프로시저 개념의 도입으로 어려운 문제는 해결

근본적인 서비스
위치나 방향, 행동 수행 가능 여부 락은 특정 컴퍼넌트가 제공하면 OCP 위반이지만
너무나 근본적인 서비스라서 많은 곳에서 의존성이 발생

컴퍼넌트가 프로시저 호출?
컴퍼넌트 프로시저는 조립 레이어에서 정의되지만
하위 레이어의 컴퍼넌트가 필요로 하는 의존성 역전이 존재하고 있음

분류되지 않은 프로시저들
순수한 유틸리티 함수, 데이터에 가까운 함수들을 정리할 기준을 세워야 함

92

요즘 유행하는 이거
주로 쉐이더 편집이나 애니메이션 편집에 사용하고, 컷신이나 카메라 등에도 활용되는 중
업계에서 합의한 용어가 없어서 임의로 모듈 서킷이라고 부름

김성익, KASA2007 “Visual Shader Editor” 김주복, NDC2008 “차세대 애니메이션 기법을 MMO 액션에 적용하기”

시각화의 힘
데이터를 만드는 사람도 코드를 만드는 사람도 절차를 시각적으로 이해
특히 새로운 기능을 고안할 때 모듈의 규격을 고려하여 설계하게 됨

UnrealEd3, Epic

모듈서킷의 일반화 시도
애니메이션 시스템에서 활용해본 결과, 많은 장점이 있었기 때문에
전체 시스템에서 모듈 서킷 서비스를 사용할 수 있도록 기반 서비스화 시도

커넥션 타입 정의
사전에 정의된 타입이 아니라 임의의 타입을 넘겨주고 넘겨 받을 수 있어야 한다
커넥션에서 임의의 값을 꺼낼 수 있어야 한다

모듈 입출력 정의
손이 많이 가지 않고 모듈의 입출력을 정의할 수 있는 방법이 있어야 한다
동적으로 입출력 연결의 개수를 변경할 수 있어야 한다

서킷 업데이트 방식
서킷의 타입에 따라서 업데이트 방식이 완전히 다를 수 있다
순회 리스트를 구축하는 것으로 간단하게 접근

100

기능 호출의 의존성
게임 로직에서 구체적인 서킷에 대해서 모르지만 서킷이 제공하는 기능을 사용하려면?
인연이 없는 두 시스템의 물리적 디펜던시를 끊을 방법은 메시지 밖에 없다 (!!!)

남은 과제?
애니메이션 시스템과 카메라 시스템을 통해서 범용화 가능성을 확인

툴과 유기적인 통합
설계 단계에서는 툴과 개념을 공유할 의도였으나 달성하지 못함
프리뷰까지 포함하여 유기적으로 통합할 수 있도록 기반 시스템 정리가 필요

스크립트 연동
숫자 더하고 빼는 수준의 절차는 서킷 모듈로 나타내기에 적합하지 않다
간단한 절차를 스크립트에서 조립할 수 있도록 할 필요가 있다

사용성 개선
템플릿 매직으로 인해서 사용성♥개판이고 서킷 로딩 코드가 매우 난잡함
좀 더 기반 시스템 쪽으로 이전할 필요가 있음

103

최적화=멀티코어활용
현 세대에서 취할 수 있는 더 이상 효과적인 전략이 없음
L2 캐시 미스가 중요한 문제로 부각됨

“AMOLED” http://beforu.egloos.com/4205502

태스크 병렬화?
MS나 인텔을 비롯하여 많은 멀티 코어 활용 관련 자료에서 강조하는 방식
AI, 렌더링, 애니메이션엔 맞지만 게임 로직 업데이트 과정에는 잘 들어맞지 않는다
Ian Lewis, GDC2008 “Getting More from Multicore”

사용성 문제
서브 시스템을 스레드로 나누고 메시징 기반으로 처리하는 것은 직관에 반한다
로직까지 태스크 패러랠하게 바꾸면서 기대할 수 있는 성능 향상도 높지 않다

GDC2009 “Intel Game Threading Tutorial”

명확한 핫스팟을 공략
태스크 병렬화를 통해서 얻을 수 있는 최대 효율을 얻는 것은 포기
사용성을 확보하면서 현 세대에서 대세인 4코어를 활용할 수 있는 방안을 고민

애니메이션 커맨드 버퍼 물리, AI…
본의 수가 10배 가량 증가 DX 커맨드 버퍼 구성 엔티티 수에 비례하는 처리들

급소만 노리자
게임 로직은 싱글 스레드로 유지, 애니메이션은 병렬로 계산
렌더링 스레드와는 더블 버퍼링, CSP에 가까운 형태

그럭저럭 고르게 4코어에 분배! 하지만…

110

헥사코어 대응은?
현재까지의 구조는 4코어 이상을 제대로 활용하지 못함
이 이상 성능을 끌어내려면 태스크 병렬 구조를 고려할 수 밖에 없다

…트랜잭션 메모리?
현재 구조는 4코어 이상을 제대로 활용하지 못함
이 이상 성능을 끌어내려면 태스크 병렬 구조를 고려할 수 밖에 없다
컴퍼넌트에 대한 모든 연산이 롤백을 지원해야 하는 무시무시한 제약 조건이 따라옴

박일, http://parkpd.egloos.com/3053881 “GameTech2010: Game Development in the Teraflop Era”

112

Bruce Dawson, GameFest2006 “Multicore Memory Coherence:
The Hidden Perils of Sharing Data”

eference
Jonathan Haas, GameFest2006 “Threading Successes of Popular PC Games and Engines”
Ian Lewis, GameFest2007 “Multicore Programming Two Years Later”
Joe Waters, GameFest2007 “Magic and Technology:
Migrating from One to Many Cores in Shadowrun”
Randall Turner, GDC2007 “Saints Row Scheduler”
김성익, KASA2007 “Visual Shader Editor 만들기”
Dmitry Eremin, GDC2008 “Comparative Analysis of Game Parallelization”
Ganesh Rao, GDC2008 “The Future of Programming for Multi-core
with the Intel® C++ Compilers”
Ian Lewis, GDC2008 “Getting More from Multicore”
Leigh Davies, GDC2008 “Optimizing DirectX on Multi-core architectures”
Phil Wilkins, GDC2008 “Designing and Implementing a Dynamic Camera System”
김성헌, KASA2008 “C++ Component System”
이창희, KASA2008 “Entity System”
Brad Werth, GDC2009 “Optimizing Game Architectures with
Intel® Threading Building Blocks”
Jonathan Bard, GDC2009 “Directing the Prince Of Persia Camera:
A Sustainable Development Approach”
Marcin Chady, GDC Canada 2009 “Theory and Practice of the
Game Object Component Architecture”
Orion Granatir, GDC2009 “Multithreaded AI For The Win!”
김주복, http://beforu.egloos.com/4034893 “게임의 객체 시스템”
김현우, KGC2009 “멀티코어를 이용한 병렬 처리 게임 엔진과 Nebula3”
조정훈, NDC2009 “최소 의존 게임 컴포넌트 시스템”
박일, http://parkpd.egloos.com/3053881 “GameTech2010:
Game Development in the Teraflop Era”

감 사 합 니 다
pangsuni, “헌터×헌터 마지막회 & 원피스 마지막회”, http://pangsuni.egloos.com/4398305
끝

Ndc2010 김주복, v3. 마비노기2아키텍처리뷰

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Ndc2010 김주복, v3. 마비노기2아키텍처리뷰

Similaire à Ndc2010 김주복, v3. 마비노기2아키텍처리뷰 (20)

Ndc2010 김주복, v3. 마비노기2아키텍처리뷰