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

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

• 1.
  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
• 2.
  개발중 이강연 내용은 현재 개발 중인 게임의 구현 방식에 대한 것으로, 최종 게임에서는 강연 내용과 다른 형태로 구현되어 있을 수도 있습니다.
• 3.
  “완벽”한 설계? 자동기술법에 의해서마구잡이로 떠오르는 이미지를 따라 망상력을 전개해보면…
• 4.
  한국 MMO 클라이언트편 설계의 달인
• 5.
  …
• 6.
  “완벽”한 설계의 이미지?
• 7.
  내가 요즘에 게임유지보수를 하고 있는데, 느낀게..
• 8.
  ㅈㄴ 급하다고 가라코드 넣으면 안될거 같애.
• 9.
  근데, 우린 매주패치하느라 넣은 코드 안빼잖아.
• 10.
  우린 안될꺼야. 아마. 10
• 12.
  MMO 설계는 어렵다 복잡한인터랙션 | 바쁜 출시/패치 일정 | 널뛰는 게임 디자인 | 레가시 코드의 압박
• 13.
  하지만…잃어버린 14년? <바람의 나라>출시 1996년 | 2010년 현재, MMO 설계에 대한 업계의 컨센서스?
• 15.
  사례연구: 블리자드
• 18.
  ※ 전 와우24렙에서 접었습니다, 와우 잘 몰^라요-
• 19.
  …우리는 그냥 여유가있는 없든 제대로 된 설계란 걸 못 하는 거 아닐까?
• 20.
  직업인으로써, 엔지니어로써 당 당 하고 후 회 없 는 완벽한 MMO 프레임워크를 만 들 어 보 자 20
• 21.
  난이도 대상 강연내용
• 22.
  김주복 마비노기 시리즈 설계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실 실장
• 23.
  논의를 시작하기에 앞서…
• 24.
  완벽한 설계는 대체뭐지? 요구사항에 따라 다르고 | 장르에 따라 다르고 | 예산에 따라 다르고 | …
• 25.
  기준을 정해야 함 확장성을 우선하는지 성능을 우선하는지… 우선 순위에 대해서 디렉터부터 모든 구성원이 동의할 필요가 있음 김주복, AOPM 세미나 “#13 일을 추진하는 방법”
• 28.
  성능+유지보수성 도전적인 목표 |개념적으로 올바른 구조를 우선 | 문제가 되는 부분을 선별적으로 해결
• 29.
  공세적 기술개발로 대비 설계에집중할 수 있도록 성능 문제가 될 만한 부분은 사전에 대응하는 기술을 개발 렌더링 버텍스 트랜스폼 부하 | DX 커맨드 제출 비용 전형규, NDC2010 “마비노기 2의 캐릭터 렌더링 기술” 애니메이션 늘어난 본으로 인한 L2 캐시 미스 | 절차적 본 연산 부하 김주복, NDC2009 “프로젝트 M2의 절차적 리깅 시스템”
• 30.
  30
• 31.
  객체 설계의 원칙준수 요구사항과 성능을 희생하지 않고 교과서에 실을 만한 설계가 실현 가능함을 증명
• 32.
  유력 용의자 사전색출 마비노기, 마비노기 영웅전 등 이전 게임의 코드를 리뷰 | 자주 설계가 꼬이는 부분에 집중
• 34.
  구조적 의존성 최소화 새로운기능의 구현이 운영중인 다른 시스템에 버그나 악영향을 미치지 않도록 구조화
• 35.
  모듈화+데이터드리븐 기능적으로 직교인 모듈화를통해 수평적 확장 | 결합 및 처리 절차를 데이터 드라이브
• 37.
  로직의 재활용 프리젠테이션 레이어+ 게임 로직의 재활용 | 신규 개발에서 뻔한 부분은 넘기고 새 기능에 집중 적지 않은 게임들이 많은 공통점들을 갖고 있다 (야)
• 38.
  엄밀한 레이어 구분 추상적인게임의 동작 레이어와 실제 게임 구현 레이어를 분리 | 최대한 재활용성을 확보
• 40.
  충분한 문서화 라이브 기간의인력 교체를 상정 | 개념과 동작을 충분히 명문화하는 것이 목표 40
• 41.
  …신규 개발하면서 문서를꼼꼼히 쓰겠다고?
• 42.
  자기반영적 시스템 문서로 남기는것은 귀찮다 한계가 있다 | 시스템이 자신의 동작을 설명하는 것을 목표 조정훈, NDC2010 “테스트 환경의 진화 : 시각화/리플레이”
• 43.
  해결해야 할 문제가많고 개발 진도도 뽑아야 한다 한 번에 완벽한 설계를 내놓는 전략보다 부분적으로 작은 시도를 진행하고 끊임없이 리팩터링하는 전략을 활용 Responsive Design? (http://agile.egloos.com/5106266) 43
• 46.
  레이어 아키텍처 아키텍처에 대해서생각한다면 가장 첫 단계 | 시스템을 추상화 수준에 따라서 구분 슈가 코팅 실제 컨텐츠 밑준비
• 47.
  마비노기의 사례
• 48.
  DIP Dependency InversionPrinciple 상위 레벨의 모듈은 하위 레벨의 모듈에 의존해서는 안되고, 양자 모두 추상화에 의존해야 한다 추상화는 구체적인 구현에 의존해서는 안된다. 구현이 추상화에 의존해야 한다
• 49.
  엄밀하게 레이어 구분 메시관리나 애니메이션 처리와 같은 프리젠테이션 지식을 추상화 이런 식의 구분이 가능하다는 사례의 의미 0.System 게임을 OS 위에 올리기 위한 서비스 1.GenericGame 2.Presentation ‘게임’에 공통적 서비스 표현을 위한 서비스 3.Mabinogi2 1과 2를 구현하고 결합해서 게임을 정의
• 50.
  0.System 1.GenericGame 2.Presentation 3.Mabinogi2 CORE.* 최하위 공통 서비스 레이어 시스템 프로그래밍 서비스 제공 50
• 51.
  0.System 1.GenericGame 2.Presentation 3.Mabinogi2 Framework.* 자원 관리 등 게임에 특화된 시스템 서비스 레이어 이 레이어는 ‘게임이라는 개념’을 알고 있다고 가정
• 52.
  0.System 1.GenericGame 2.Presentation 3.Mabinogi2
• 53.
  0.System 1.GenericGame 2.Presentation 3.Mabinogi2
• 54.
  0.System 1.GenericGame 2.Presentation 3.Mabinogi2
• 55.
  55
• 57.
  메인루프의 문제? 일반적으로 프로젝트전체에서 가장 단단한(=수정할 수 없는) 구조 입출력과 게임 로직, 프리젠테이션 시스템과 강력하게 결합, 재활용을 가장 크게 방해
• 58.
  난제1:플레이방식변경 게임 도중에 다른미니 게임으로 전환? | 이런 미니 게임이 여러 종류? Grand Theft Auto 4, Rockstar
• 59.
  난제2:멀티세션 화면 분할로 두명이 다른 지역에서 게임을 플레이? 한 화면에 게임 화면을, 다른 화면에 UI를 표시한다면? Gears of War 2, Epic
• 60.
  난제3:Play-In-Editor 툴에서 게임 플레이를하도록 지원해야 한다면? 정적 테스트를 위해서 게임 로직을 따로 돌려야 한다면? 60 Cryengine2, Crytek
• 61.
  F*E$%&^(W$EA_(G; 이걸뭐어쩌ㅏ라ㅁㄴ이ㅏ럼ㅈ49058ㅕㅂㅈ30ㄷ9ㅁㅅㅎ겨ㅓㅋ퍄ㅏ-90ㅂㅈ3ㅁㅅㄷㅎㄱ키ㅏ 2007.4.12.입력처리기구조.ppt 2008.9.9-입력에서로직까지.jpg
• 62.
  사례연구: 마비노기
• 63.
  캐릭터 로비 객체 관리와렌더링 로직은 공유하지만 게임 업데이트는 사용하지 않는다
• 65.
  루프를 기능별로 분해 입출력배분 | 프리젠테이션 처리 (렌더링, 오디오, …) | 게임 시뮬레이션 업데이트 논리적 게임월드 물리적 출력장치 (뷰, 사운드 등) 물리적 입력장치 OS가 인지하는 메인루프 ForEach Console UpdateInput ForEach GameLoop UpdateAndRender ForEach Console Present ForEach GameLoop UpdateInput
• 66.
  ※ 실제로는 멀티코어 지원 때문에 여기에 보이는 것보다 상당히 복잡하다
• 67.
  적용사례: 프로젝트M2
• 68.
  다양한 테스트 모드 기본전투 게임 플레이 테스트 모드 | 캐릭터 뷰어 모드 | 물리 테스트 모드 | … M2GameLoop M2DevLoop ShowRoom GameLoop Parade GameLoop
• 69.
  백그라운드 루프 두 루프가한 콘솔에 업데이트 | 클라이언트 상태 로깅 | 애셋 관련 에러 로깅
• 70.
  …혹은 텍스트 콘솔 애니메이션전처리 | 클라이언트 사이드 로직 유닛 테스트 등 AnimationProcessLoop 70 70
• 72.
  컴퍼넌트? 연관된 기능과 데이터를추상화하고 캡슐화한 소프트웨어의 단위
• 73.
  컴퍼넌트는 상식? 단방향 그래프로 객체의 관계를 표현할 수 없다 | 상속은 문법적으로 끊기 어려운 의존성 컴퍼넌트를 어그리게이션하여 객체를 표현하는 것이 유연하고 세련된 방식 김성헌, KASA2008 “C++ Component System” 조정훈, NDC2009 “최소 의존 게임 컴포넌트 시스템”
• 74.
  컴퍼넌트의 장점에 대한 설명은 과감하게 생략하고..
• 75.
  컴퍼넌트통신=메시지? 혹은 다른 컴퍼넌트의 인터페이스를 사용해서 메소드를 호출 게임 개발 커뮤니티에서 컴퍼넌트 시스템을 말할 때 당연하게 언급하는 내용이지만… GDC Canada 2009 “Theory and Practice of the Game Object 이창희, KASA2008 “Entity System” Component Architecture”
• 76.
  의문1:OCP위반 혐의 Open-ClosedPrinciple 컴퍼넌트 A가 일을 하기 위해서 컴퍼넌트 B 인터페이스에 직접 의존한다면 컴퍼넌트 B에 대한 수정이 컴퍼넌트 A의 수정을 수반해야 한다
• 77.
  의문2:절차에 대한 지식 컴퍼넌트가형식적 OCP를 준수하기 위해서 메시지를 사용하면 여러 컴퍼넌트가 협업해야 하는 절차에 대한 지식이 메시지 전달 순서로 전환되는 셈 다자 관계의 처리에 매우 취약
• 78.
  의문3:메시지 분배 과정 시리얼라이즈와디시리얼라이즈가 객체의 책임이 아닌 것처럼 메시지 해석 및 분배도 컴퍼넌트의 책임은 아닌 게 맞지 않나? Nebula3의 사례
• 79.
  극단적인 설계 실험 OCP를만족하면서도 다자 관계 절차 처리에 적합한 방법을 찾기 위한 시도 OCP를 맹목적으로 준수 컴퍼넌트는 다른 컴퍼넌트를 절대로 알아서는 안 된다 객체Entity,Object는 없다 객체에 컴퍼넌트의 지식이 없다면 존재 의미가 없고, 반대로 컴퍼넌트의 목록을 안다면 OCP 위반이므로 객체란 것은 세상에 존재하면 안 된다 극단적인 설계 실험에 몰두하고 있는 모습 (대역 재연)
• 80.
  1. 다른 컴퍼넌트참조 금지 한 컴퍼넌트가 다른 컴퍼넌트를 참조하는 것을 엄격히 규제 2. 이벤트로 통지를 선호 다음 처리가 필요한 컴퍼넌트에게 메시징하는 대신 사건 발생을 알아야 하는 쪽이 리스너를 등록 3. 메시지 자체를 객체로 간주 컴퍼넌트가 메시지를 받아서 일을 하는 게 아니라 일이 컴퍼넌트를 찾아서 절차를 수행한다 “아니, TD 양반. 이게 무슨 소리요, 메시지가 객체라니.” 80
• 81.
  기존의 방식 어떤 절차를수행하고자 하면 컴퍼넌트가 다른 컴퍼넌트에게 메시지를 보낸다
• 82.
  실험적인 방식 어떤 절차를수행하고자 하면 절차 객체를 만들어 실행 이벤트 와이어링은 객체의 셋업 과정에서 처리 게임 월드
• 83.
  핸들(itemHandle)로 컴퍼넌트 EquipmentTag를 룩업 월드 객체(=레지스트리 내의 싱글턴)의 아이디로 컴퍼넌트 FieldInventory를 룩업
• 84.
  깔끔한 거 같긴한데… 컴퍼넌트간 의존성도 사라지고 절차 중심으로 기술할 수 있게 된 반면 초기부터 다른 컴퍼넌트에 의존성을 가질 수 없는 컴퍼넌트는 라이트해지고 프로시저 레이어는 난잡하고 비대화해질 것이라는 예측이 가능
• 85.
  …왜 슬픈 예감은틀린 적이 없나…
• 86.
  재앙 발ㅋ생ㅋ 컴퍼넌트는 일도안 하고 배째라식 세터/게터 노출 인테그레이션 레이어는 클라이언트 전 범위의 객체가 너나없이 날뛰며 해적왕을 꿈꾸고 절차를 강조했더니 작업자들이 발상하는 방식도 절차적 프로그래밍으로 퇴행
• 87.
  ♡ 대 개 발 팀 긴 급 담 화 문 ♡ 잠시 정규 업무를 중단하고 중대 현실 도피를 하겠습니다.
• 88.
  1차정리:규칙을 분리 절차가 아닌,게임의 규칙을 정의하는 프로시저를 인테그레이션 레이어 최상위로 분류 객체의 기능에 해당하는 프로시저를 따로 분류 (생성/파괴 등)
• 89.
  2차정리:컴퍼넌트 정리 로직 프로시저중 컴퍼넌트를 완결하는 기능에 해당하는 항목을 별도 분류 개념적인 컴퍼넌트를 구성 InventoryProc::Create PickUpItemFromWorld class Inventory 예전과 마찬가지 상태로 객체의 생성과 어느 한 컴퍼넌트가 다른 컴퍼넌트에 대해서 이벤트 핸들러 와이어링 과정 단독으로 수행할 수 전혀 모르는 컴퍼넌트 혹은 다른 컴퍼넌트를 없는 종류의 작업들 참조하지만 (ex. 스플래시 공격) 일반적인 설계로는 이 컴퍼넌트의 기능인 프로시저들
• 90.
  90
• 91.
  기존 마인드모델에 부합 객체를 구분하는 동시에 컴퍼넌트 소속이 아닌 로직 프로시저를 구분하는 준거점 전통적인 OOP 방법론과 컴퍼넌트 설계 방법론을 적용 가능 무엇보다 여기 해당되는 함수들이 많지 않음 마음의 평화를 찾은 프로그래머들의 훈훈한 대화
• 92.
  남은 과제? 아직까지도 컴퍼넌트의의존성을 제거하는 실험은 진행중 하지만 컴퍼넌트 프로시저 개념의 도입으로 어려운 문제는 해결 근본적인 서비스 위치나 방향, 행동 수행 가능 여부 락은 특정 컴퍼넌트가 제공하면 OCP 위반이지만 너무나 근본적인 서비스라서 많은 곳에서 의존성이 발생 컴퍼넌트가 프로시저 호출? 컴퍼넌트 프로시저는 조립 레이어에서 정의되지만 하위 레이어의 컴퍼넌트가 필요로 하는 의존성 역전이 존재하고 있음 분류되지 않은 프로시저들 순수한 유틸리티 함수, 데이터에 가까운 함수들을 정리할 기준을 세워야 함 92
• 94.
  요즘 유행하는 이거 주로 쉐이더 편집이나 애니메이션 편집에 사용하고, 컷신이나 카메라 등에도 활용되는 중 업계에서 합의한 용어가 없어서 임의로 모듈 서킷이라고 부름 김성익, KASA2007 “Visual Shader Editor” 김주복, NDC2008 “차세대 애니메이션 기법을 MMO 액션에 적용하기”
• 96.
  시각화의 힘 데이터를 만드는사람도 코드를 만드는 사람도 절차를 시각적으로 이해 특히 새로운 기능을 고안할 때 모듈의 규격을 고려하여 설계하게 됨 UnrealEd3, Epic
• 97.
  모듈서킷의 일반화 시도 애니메이션시스템에서 활용해본 결과, 많은 장점이 있었기 때문에 전체 시스템에서 모듈 서킷 서비스를 사용할 수 있도록 기반 서비스화 시도
• 98.
  커넥션 타입 정의 사전에정의된 타입이 아니라 임의의 타입을 넘겨주고 넘겨 받을 수 있어야 한다 커넥션에서 임의의 값을 꺼낼 수 있어야 한다
• 99.
  모듈 입출력 정의 손이많이 가지 않고 모듈의 입출력을 정의할 수 있는 방법이 있어야 한다 동적으로 입출력 연결의 개수를 변경할 수 있어야 한다
• 100.
  서킷 업데이트 방식 서킷의타입에 따라서 업데이트 방식이 완전히 다를 수 있다 순회 리스트를 구축하는 것으로 간단하게 접근 100