Programming

이번 포스트는 에픽 게임즈 (Epic Games) 의 창업자이자 언리얼 엔진의 메인 프로그래머인 Tim Sweeney 의 2006 년 Principles of Programming Languages (POPL) 에서의 invited talk 프리젠테이션에 관한 것이다. POPL 은 프로그래밍 언어 분야에서는 가장 권위있는 심포지움 중 하나이니 굳이 다른 설명은 필요없을 것 같다.

팀 스위니는 오래 전부터 GDC 에서도 OOP 를 이용한 엔진 개발의 중요성을 강조해왔으며 최근에 이르러서는 둠, 퀘이크를 만든 존 카멕의 엔진보다 팀 스위니의 언리얼 엔진이 대세로 떠오르고 있다. 언리얼 엔진은 모듈화가 매우 잘 되어 있어서 범용으로 사용 가능한 유일한 게임 엔진이라는 말을 들을 정도이다. (렌더링 미들웨어스러운 게임브리오는 예외로 하자.) 그리고 자체 스크립트 언어인 UnrealScript 로도 유명하다.

프리젠테이션 제목은 “The Next Mainstream Programming Language: A Game Developer’s Perspective” 이다. 사실 보통 3D 게임 엔진 개발자라면 imperative programming 의 달인이고 주로 SIGGRAPH 논문만 볼거 같은데 의외로 프로그래밍 언어에 대해 깊은 관심을 가지고 있어서 놀랐다. pure functional language 인 Haskell 에도 관심을 가지고 있어서 하스켈의 유용한 기능들을 많이 도입하려고 하고 있었다.

그 외에도

“우리는 절대 어셈블리어를 사용하지 않는다! (We never use assembly language)”

라든지 언리얼의 정수 변수 중 90%가 배열 인덱스로 사용되기 위해 존재했다는 것과 사용된 for 루프 중 40%가 functional comprehensions 그리고 50%가 functional folds 였다는 것도 매우 흥미롭다.

PT 를 보면 기어즈 오브 워(Gears of War)의 예를 들어 몇명의 프로그래머와 몇명의 아티스트가 얼마의 예산을 가지고 몇개월 동안 작업했는가 하는 구체적인 데이터로부터 시작하여 게임에 사용한 라이브러리들도 자세히 설명하고 있다.

그리고 게임 코드를 약 3가지-Game Simulation, Numeric Computation, Shading-로 분류해서 각각에서 중요한 요소들과 우선시되는 요소들(OOP, 속도, 병렬성 등) 을 설명하고 그에 맞는 언어를 소개하고 있다. 게임을 이루는 각 부분마다 특성에 맞는 서로 다른 언어들을 사용하는 것이 매우 흥미롭다. 혹시라도 난 게임 개발만 할거니까 functional language 는 알 필요없어! 라고 하는 분이 있다면 꼭 일독하길 바란다. 이 PT 를 보면 학부 수준에서 배우는 과목은 모두 다 중요하다는 진리를 다시 한번 일깨워준다.

특히나 경험을 바탕으로 한 게임 개발의 구체적인 수치들과 정상급 개발자의 식견은 돈 주고도 배우기 힘든 귀중한 내용들이니 꼭 읽어두도록 하자.

오른쪽 하단의 버튼을 클릭해서 풀스크린 모드로 보기를 추천한다.

외부 링크

• “The Next Mainstream Programming Language: A Game Developer’s Perspective” PPT 파일

디지츠님이 남겨주신 리플을 보고 STL 같은 표준 라이브러리나 기타 여러 라이브러리들을 사용할 때 저도 그렇고 누구에게나 드는 의문일 거 같기 때문에 그에 대해 간단하게 저의 생각을 적어봤습니다.

“홀짝도 구분 못하는 STL” 에서 볼 수 있듯이 C++ Standard Template Library 의 경우 표현력과 재사용성을 서로 trade-off 했기 때문에 STL 로만 코드를 짜는데는 표현력에 많은 제한이 있습니다. 제가 불평한 것도 그런 표현력이 몇가지 부분에 있어서 많이 부족했기 때문입니다.

하지만 오히려 그 덕분에 STL 로만 작성할 수 있는 경우에 그 코드의 가독성과 논리적 명확성은 오히려 더욱 뚜렷해진다고 생각합니다. 반면 아무런 라이브러리도 사용하지 않은, 언어 자체의 expression 과 statement 를 사용한 코드의 경우 그 표현에 있어서 제한이 없으니 더 쉬운 코드나 아니면 이해할 수 없을 정도로 복잡다단한 코드도 나올 수 있을 겁니다. 따라서 저는 단순히 STL 사용 여부가 코드의 복잡성이나 가독성을 높이거나 낮춘다고 생각하지는 않습니다.

Read the rest of this entry »

다툴래? 나와 갈등을 빚어볼래? 급의 제목인거 같지만[..] 여튼 오늘 심심해서 코딩해보다가 다시금 STL(Standard Template Library) 에 조금 실망하게 되는 점(?)이 있어서 글을 써봅니다. 우선 평상시에는 boost 를 거의 상용하기 때문에 이런 불편함을 못느꼈었는데 STL 만 사용하는 경우 가끔씩 이런 불편함을 느끼게 되네요.

사건의 발단(?)은 오늘 누군가 인터넷 게시판에 “정수 10개를 입력 받아서 홀수와 짝수를 구분하여 각각 출력”하는 문제의 소스 코드를 디버깅 해달라고 올린걸 본 것부터였습니다. 간단한 문제니까 한번 C++ 의 표준 라이브러리와 STL 만 가지고 짜볼까? 하는 생각이 들어서 짜보게 되었는데 그게 재앙의 시작일 줄은 그때는 미처 몰랐습니다[..]

평소에 주로 SGI 의 STL 문서를 보기 때문에 당연히 입력은 copy_n 으로 받고 홀짝 구분은 partition 과 compose1, bind2nd, equal_to, modulus 로 만들 생각이었습니다.

자, 문제 조건이 정수 10 개를 입력받는 거니까. 우선 정수 10 개를 입력 받아서 벡터로 복사해볼까?

vector<int> input;
copy_n(istream_iterator<int>(cin), 10, back_inserter(input));

… 컴파일 중 …

어라? 컴파일이 되지 않습니다?!
Read the rest of this entry »