You are here: Home - Studies∞ - GDC2013 Day3-Class1

slide-73-1024
Under the Hood of Blizzard’s Internal Build System

Wed March 27 2013
Room 303, South Hall
Speaker: Blaine Whittle at Blizzard Entertainment

이번 강연은 블리자드의 내부 빌드 시스템을 소개하는 시간입니다.

사실 너무 복잡합니다.
스타크래프트2나 디아블로3 같이 클라이언트 패키지 용량만 수GB~수십GB이상 가는 대형 게임을 위한 시스템이기 때문입니다.

slide-2-1024
(이처럼 용량이 커져갑니다)

이렇게 큰 클라이언트를 빌드하기 위해서는 꽤나 오랜 시간이 소모됩니다.
게다가 디버깅용, 릴리즈용, 맥용… 빌드 수가 늘어날수록 무한정 시간이 소모될 겁니다.
이를 해결하기 위해 Google MapReduce, Incrdibuild, XCode Distributed Builds, Maven, Ant 등등을 모두
고려해봤지만 모두 만족하지 못했다고 합니다.
그래서 블리자드에서는 그냥 빌드 시스템을 만들어버리는군요.

요구사항은 최대한의 parallelism을 위한 그래픽 통계와 데이터 플로우를 만들 것. 멀티플랫폼을 지원할 것(호스트와 빌드타겟들). 새 프레임웍에 맞는 툴을 만들 것. 최대 실행 퍼포먼스가 나오도록 할 것.
위의 요구사항을 만족시키기 위한 Project 명이 “SANITY”라고 합니다.

데이터 플로우 architecture는 functional programming을 사용하고 각각의 노드 하나를 processor로 정의합니다.
이 패턴에서 하나의 노드는 하나의 task를 나타냅니다. task는 하나의 파일(immutable file)을 읽어 새로운 파일 하나를 생성하는 단위 작업 하나라고 보시면 됩니다.
여기에서 immutable file의 개념이 나타나는데 이것은 한번 쓰이면(생성되면) 다시는 파일이 수정되지 않는다는 뜻입니다.
빌드 과정의 가장 큰 cost인 파일 I/O를 줄이기 위한 방책인 듯합니다.

 

slide-16-1024
slide-17-1024
그래픽은 이런 식으로 보여줍니다. 그래프화하는 기능까지 직접 구현한것인지까지는 듣지 못했습니다. 아마 다른 visualization 툴을 쓴 것 같습니다.

 
slide-23-1024
sanity 파일은 이런 식으로 구성됩니다.
흡사 함수와 파라미터로 이루어진 것처럼 구성했네요.

이후 구현에 관한 자세한 내용이 나옵니다만 이 부분은 생략하겠습니다.
현재 이렇게 빌드가 힘들 정도로 복잡한 시스템을 갖춘 게임이 필요한지 의문이거니와 똑같은 시스템을 구현할 일이 없을 것이기 때문입니다.
간략히 요약하자면 파일 cache를 잘해라. repositary에서 직접 파일을 불러오는 것보다는 머신끼리 공유하는 게 낫다.
부하가 많이 걸리는 머신의 job을 다른 머신이 돕도록 설계하라 등입니다.

역시 블리자드를 비롯한 미국 회사들은 국내의 마인드와 다른 것 같습니다.
필요한 게 있으면 그냥 만들어서 사용하면 된다는 생각을 가지고 있는 듯합니다.
하긴 컴파일러든 프로그램 언어든 그것을 만드는 사람이 가까운 곳에 있다고 생각하면
그것이 나도 만들 수 있는 것이라는 생각이 들지 않을까요?

by Mason Jo

Back to top