'Game Development'에 해당되는 글 94

  1. 2012.03.02 Near 평면으로 투영된 구의 크기 구하기 (13)
  2. 2011.08.23 퍼포스 changelist 로그로 검색하기 (11)
  3. 2011.06.22 SIKULI를 이용한 GUI 테스트 자동화 (12)
  4. 2011.05.23 해스켈 수도쿠 살버 (6)
  5. 2011.01.18 자료구조에서 사이클 찾아내기 (7)
  6. 2010.04.28 뒤늦게 올리는 GDC 2010 리포트 (12)
  7. 2010.02.17 [해외 개발자 인터뷰] Tiago Sousa (6)
  8. 2010.01.04 Game Developer Blog Network 인증용 vefe3cc49 (냉무) (4)
  9. 2009.12.18 차세대 게임개발 언어로 D에 주목하는 이유 - 마지막 (7)
  10. 2009.12.02 크라이텍 아카데미 (12)

Near 평면으로 투영된 구의 크기 구하기

최근에 구로만 이루어진 장면을 위한 초간단 레이트레이서를 구현할 기회가 있었습니다. 무식한 방법으로 초기 구현을 한 뒤, 최적화를 위해 구를 화면 타일(near 평면을 균일 격자로 나눔)로 미리 분류해놓는 방법을 시도하였습니다. 그러면 각 픽셀에서 광선 추적 시, 그 픽셀이 포함된 타일에 등록된 구들만 조사하면 되니까요. 원근 투영에서 구를 2차원 평면에 투영하는 경우 그 결과가 원이 아니어서, 구현이 생각만큼 간단하지 않더군요. 기하 및 삼각함수 지식을 적용해 투영된 구의 최소 사각 경계를 구할 수 있었습니다. 사각 경계를 얻고 나면, 쉽게 구를 관련 타일들에 등록할 수 있지요.


제가 손수 그린 아래 그림에서 상황 및 관련 기하 매개변수들을 확인할 수 있습니다. 나름 최선을 다한 그림이니 못마땅 하더라도 양해를...;



위 그림은 수직 단면(y축 방향)만을 보여줍니다만, 수평 단면(x축 방향)으로도 마찬가지로 적용할 수 있습니다. 반지름 r의 구를 투영하고 있습니다. Near 평면에 투영되면서 작아지는 r'는 닮은꼴 비례 관계로 쉽게 계산할 수 있습니다(Eq. 1). 아래쪽 확대한 그림에 y축 방향 투영 크기를 구하는데 필요한 변수들이 자세히 나와 있습니다. 종국에 다음과 같이 y방향 범위가 나옵니다.

r'/cos(theta) - Ydown < (Y - projected_sphere_center) < r'/cos(theta) + Yup

여기서, projected_sphere_center는 구 중심을 near 평면으로 투영한 점을 나타냅니다. theta는 시야 벡터와 시점으로부터 투영된 구 중심으로의 벡터 사이의 각도를 말합니다. YupYdown을 구하려면, 역시 닮은꼴 비례 관계를 두 번 활용해야 합니다(파란색 및 보란색 선으로 표시된 비례 관계 참조). 위 그림에서 닮은꼴들을 쉽게 발견할 수 있기를 바랍니다. Eq. 2Eq. 3으로 YupYdown을 구하고나면, Y의 범위는 위 부등식으로 주어집니다(시계 반대 방향으로 theta가 양이라 하면, 구가 시야 벡터 위가 아닌 아래에 있는 경우에도 위 방정식 쌍을 그대로 쓸 수 있습니다). X축 범위도 마찬가지로 구할 수 있습니다. 이렇게 2차원 경계가 나오면, 이 사각 영역과 겹치는 화면 타일들을 바로 찾아낼 수 있습니다.

이렇게 결과를 얻고 나면, 참 간단해 보입니다. 실제 필요한 기하 및 삼각함수 지식도 초보적인 수준이고요. 그래도 그 유도 과정을 이렇게 한 번 정리해 두는 것도 의미가 있다고 생각했습니다. 이 글이 누군가에게 도움이도 되기를 바랍니다. 오류가 있거나 더 나은 방법을 알고 계시면 꼭 댓글로 남겨주시길 부탁 드립니다. ^^


[업데이트] 저의 무지가 드러났습니다; 이 글의 영문 버전에 달린 댓글에 따르면, 타원체의 투영 결과는 타원이라는군요. 따라서, 구의 투영도 (반드시 원은 아니지만) 타원이 되겠습니다. 증명은 이 문서를 참고하세요. 또다른 댓글에 타원체를 기준으로 한 쌍대(duality) 원리에 대한 언급도 나옵니다. 도 알아두면 좋게네요. ^^
Trackback 1 Comment 13

퍼포스 changelist 로그로 검색하기

퍼포스는 상용 버전 관리 시스템으로 많은 회사들이 쓰고 있습니다. 제가 다니고 있는 회사에서도 이 놈을 쓰고 있는데, 제가 쓰면서 놀란 것 중 하나는, 어찌보면 기본 기능 중 하나인 커밋한 변경사항(changelist)들은 커밋로그(퍼포스 용어로는 description)로 검색하는 기능이 GUI client에서 지원이 안된다는 점이었습니다. 물론 이것이 불가능한 것은 아닙니다. 여기 보면 여러 해법들이 나와있지요. 어쨌든 상당히 자주 쓰이는 기능이고 다른 오픈소스 도구들고 잘 지원하고 있는 이런 기능이 간편한 UI로 제공이 안된다는 것은 실망이 아닐 수 없습니다.

그래서 위 스택오버플로 답변 중 하나에 힌트를 얻어 AutoIt 스크립트로 간단한 유틸을 만들어 보았습니다. 이름은 p4search입니다. 프로젝트 위키에도 나와있지만 여기 사용 방법 다시 정리해놨습니다.

  • 먼저, p4sql을 이용하기 때문에 P4Report를 퍼포스 사이트에서 다운/설치하셔야 합니다.
  • 코드에 p4sql 경로가 "C:\Program Files (x86)\Perforce\P4Report\p4sql.exe"로 하드코딩 되어 있습니다; 필요하면 바꾸세요.
  • 소스 .au3 파일에서 실행 파일을 빌드하려면 AutoIt 관련 도구가 필요합니다. 여기서 받으세요. (이조차 귀찮은 분들은 여기 미리 빌드된 놈들을 받아주세요.)
  • 빌드된 명령행 도구는 퍼포스 사용자아뒤파일스펙, 찾고자 하는 로그 내용의 세 인자를 받습니다. 셋 미만의 인자를 줄 경우, 대화 상자가 나와 각 정보를 묻습니다.
  • 더 편리하게, 다음과 같이 이 유틸리티를 퍼포스 클라에 사용자 도구로 통합할 수 있습니다.

사용자 도구 설정 화면

저장소 내 아무 폴더 우클릭 -> 등록된 p4search 항목 클릭


나오는 대화상자에 찾고자 하는 글 입력


결과 화면

몇몇 분들에게나마 도움이 되었기를 ^^;
Trackback 0 Comment 11

SIKULI를 이용한 GUI 테스트 자동화

현재 직장에서 툴 프로그래머로 일하고 있습니다. 소스 코드 규모가 커지고 작업하는 사람들이 많다보니, 한쪽에서 작업한 변경으로 다른 모듈 기능에 의도치 않은 장애가 발생하는 일이 잦았습니다. 특히 엔진 쪽 변경으로 에디터 관련 기능에 장애가 생기는 일이 자주 생겼습니다. 이 문제를 해소하고자 에디터 테스트를 일부라도 자동화할 수 있는 방법을 찾게 되었습니다.
(이하에서는 GUI 관점에서의 black-box testing에 대해서만 다룹니다.)

고려했던 대안들
기존에 익숙했든 AuotIt부터 시작해서 다음과 같은 도구들을 고려해봤습니다.
AutoIt
  • 윈도 플랫폼에서 돌아가는 Basic과 유사한 스크립트 언어
  • 컨트롤 아이디, 클래스, 텍스트 등으로 특정 UI 요소 식별
  • 일반 용도의 자동화 도구로도 매우 유용
TestComplete
  • 상용 테스트 자동화 도구
  • 일반적으로 위의 AutoIt 유사한 UI 요소 식별법 사용
  • 편리한 IDE 제공
  • 여러 스크립트 언어 지원
SIKULI
  • Jython 기반으로 멀티플랫폼
  • 컴퓨터 비전 기반 UI 요소 인식
    • 이미지 비교 결과(퍼센티지 문턱값 지정)에 따라 매치 여부 결정
  • 기본적인 IDE 제공
  • 개발 초기 단계
신선한 개념과 이미지 인식 기반이라 화면 상 임의의 요소에 반응할 수 있다는 장점에 끌려 시쿠리로 방향을 잡았습니다. 시쿠리가 어떻게 기능하지는 아래 동영상이나 튜토리얼 페이지를 보시면 금방 감잡으실 수 있습니다.

이하에서는 저의 시쿠리 실험이 어떻게 진행되었는지 이야기합니다.

진행 상황

일단 QA 팀에서 하고 있는 에디터 수동 테스트의 상당수를 자동화 하는 것이 첫 목표였습니다. 현재까지 대략 기존 수작업 테스트의 70% 정도는 자동화 했습니다. 등록된 테스트가 모두 끝나면 html 형식의 리포트를 만들게 했습니다. 각 테스트 항목의 성공 여부를 보여주고, 실패한 경우 어떤 이미지 매치가 문제였는지 표시하였습니다.
[예제 테스트 항목들]
  • 에디터 실행/종료
  • 각종 서브에디터 창 열기
  • 새 레벨 생성 및 저장
  • 기존 레벨 불러오기
  • 레벨 익스포트
  • 뷰모드 전환
  • 각 서브에디터별 기능 테스트
하지만 작업 과정이 생각했던 것만큼 수월치는 않았습니다. 가장 큰 문제는 역시 컴퓨터 비전 기반이라는 점에 있었습니다. 화면 상 이미지에 의존한다는 것이 양날의 검이었던 것이죠.

느낀 점
  • 유지보수가 힘들다: UI가 변할 때마다(아이콘, 컨트롤 텍스트, 리사이징) 테스트에 사용되는 이미지도 적절히 갱신해주어야 합니다. 상당히 번거롭습니다.
  • UI 요소를 식별하기 위해 적절한 비교 이미지 영역을 선택하는 것이 쉽지 않다: 너무 작은 부분을 고르면 매치 영역이 여럿이 되어버리고(정밀도가 떨어지고), 그렇다고 확실하게 크게 잡으면 UI 리사이즈같은 작은 변화에 너무 민감하게 되어서 유지보수가 번거로워지는 일이 다반사였습니다.
  • 테스트 성공 여부 식별의 문제: 테스트 성공 여부도 특정 UI 요소 혹은 특정 텍스트가 보이는지 여부로 결정하게 됩니다. 이 역시 노이즈에 너무 약합니다. 이론적으로는 렌더링 결과 비교도 가능합니다만, 역시 개발 중에는 렌더링 변경이 잦은 관계로 안정적인 테스트가 힘들었습니다. 가령, 백버퍼 클리어 색상이 바뀌었다든지 하면 역시 잘못된 실패 보고가 뜨고 그 때마다 테스트 이미지들을 갱신해주어야 했습니다. 결국에는, 컴퓨터에 의존하지 않고, 뷰포트 스샷을 찍어 최종적으로 테스터가 성공 여부를 판별케 하는 반자동(?) 방식을 일부 도입해야 했습니다.
  • 아직 개발 초기라 다듬어지지 못한 부분이나 버그가 많다: 특정 함수 관련 메모리 릭과 같은 버그도 있었고, 키보드 레이아웃이 영어가 아닌 경우 키입력 함수(type())가 오작동하는 버그도 있었습니다(이 경우, 클립보드 함수인 paste()를 이용하는 방법으로 문제를 우회할 수 있었습니다). 매치에 사용되는 이미지 관리에도 리네이밍 같은 필수적이 기능이 IDE에 빠져있었고(최근 버전에서 해결), 테스트 세트가 커질 경우 중요한 모듈화 및 그 관리에도 현재로선 명쾌한 해답이 없는 상황입니다. 다행히, 버그에 대한 개발자의 응답 및 임시방편 제시는 생각보다 빨랐습니다. 질답 게시판도 도움이 되었고요.
  • 디버깅의 어려움: 전문적인 디버깅 환경이 지원되지 않다보니, 긴 테스트 함수에서 특정 매치가 실패할 경우, 문제 지점을 파악하고 수정하는 과정이 더딥니다.
  • 수행 성능도 이미지 비교 기반인지라 아주 빠르지는 않습니다만, 크게 문제될 정도는 아니었습니다. 개발 시에 IDE의 특정 동작이 매우 느리게 동작하는 경우가 있어 답답하긴 했습니다.

결론
쓰다보니 아주 몹쓸 물건처럼 묘사된 것 같습니다만...; 꼭 그렇지는 않습니다. 사실 다른 대안들에서 사용하는  컨트롤 아이디나 클래스 기반 UI 식별도 빈도는 적을지 몰라도 유사한 유지보수 문제를 안고 있습니다. 그리고 분명 그런 대안들에서는 아예 불가능한 것들이 시쿠리로는 쉽게 되는 부분도 많았습니다.
  • 아직은 개발 초기로 거친 면이 많은게 사실입니다. 하지만, 개발자가 계속 의지를 가지고 개선해나가면 전망은 밝다고 봅니다.
  • 내부 코드의 도움없이 순수히 외부 UI 식별만으로 안정적인 UI 테스트 자동화를 이루기는 거의 불가능합니다. 내부 스크립팅 기능을 외부에서 접근해서 자동화할 수 있다면, 훨씬 견고하고 유지보수가 용이한 테스트 세트를 구축할 수 있습니다.
  • 렌더링 회귀 검사에 유용해보입니다.
  • 개인 작업의 자동화 용도로도 강추입니다.


Trackback 0 Comment 12

해스켈 수도쿠 살버

얼마 전, Clojure & Python, Side by Side 글을 보고 나도 수도쿠(참고1) 살버를 해스켈로 포팅해보자 마음 먹었습니다. 먼저 원 고안자인 Peter Norvig의 글(참고2)을 읽고 찬찬히 읽고 알고리즘을 이해했습니다. 알고리즘을 특별히 함수형 언어에 적절하게 바꾸거나 하지 않고 그대로 포팅할 작정이었으므로, 기껏해야 네다섯 시간 투자하면 되겠거니 생각했습니다... 실제로는 투자한 시간을 합쳐보니 총 24시간은 넘을듯 하더군요;

  • 일단, 여기 최종 해스켈 코드

  • 결과

파이썬 코드는 214행이었습니다. 제 해스켈 코드는 276행이군요. 원 노빅씨의 해법이 상당히 간결하다고 봤을 때, 나쁘지 않다고 봅니다.

성능은 다음처럼 나왔습니다. 보시다시피, 해스켈 버전이 약간 느리군요. 그래도 첫 시도로는 준수한 결과라 봅니다;

  • 배운 것
    • 수도쿠(참고1) 퍼즐 푸는 알고리즘, 노빅씨가 잘 설명해놓으셨습니다(참고2).
    • 노빅씨의 파이썬 해법(참고2), 아름답습니다. (물론, 저는 파이썬 전문가 아닙니다;)
    • 두 언어가 거의 동일하게 list comprehension(참고3)을 지원해서 편했습니다.
    • C++에서와 같은 의미의 변수가 없다는 사실이 생각만큼 큰 차이로 느껴지지 않더군요.
    • 후글(http://haskell.org/hoogle/)과 구글이 없었다면 24시간 정도만에 어림도 없었습니다.
    • 기존 C 스타일의 언어에서 너무 익숙한 반복문과 반복문 내에서의 이른 탈출이 아예 없다는 것이 포팅에서의 가장 큰 걸림돌이었습니다.
    • 함수형 언어에서는 반복이 아닌 재귀로 생각해야 합니다.
    • 혹은 한단계 더 나아가 foldmonad(참고5)로 생각해야 합니다.
    • 해스켈에는 fold가 참 많습니다. foldl, foldr, foldl' 그리고 foldr'. 어떤 놈을 써야 할지 많이 헷갈리더군요(참고4).
    • 이해하기 까다롭기로 소문난 모나드(참고5)가 자연스럽게 필요하게 되더군요. 이 놈 없으면 과도하게 중첩된 case 문을 사용하게 됩니다.
    • 해스켈이 type inference를 지원하여 필수 사항은 아님에도, 형 선언을 꼬박꼬박 해주는게 이해하는데도 그렇고 디버깅 시에도 도움이 많이 되더군요.
    • 책에서 읽은대로, 정말 해스켈로 짤 때에는, 컴파일이 되면 보통 바로 그대로 문제없이 동작하더군요. 물론, 컴파일이 되게 하기가 저한테는 쉽지 않았습니다만;
    • IO 모나드에서 do 용법은 해스켈에서 일반 순수 함수를 짤 때와는 정말 다른 느낌이더군요. 흡사 다른 언어인 것처럼...;
    • 해스켈의 특징인 laziness가 또 머리를 더 복잡하게 합니다. (제 코드에서 볼 수 있는 것처럼, 특정 상황에서는 결과를 얻기 위해 strict 계산을 강제해야 했습니다.)

  • 결론
    • 해스켈은 imperative programming language와는 완전 다른 세상이다...
    • 해스켈 책 하나(제 경우는 "Real World Haskell"(참고9)) 읽은 것으로는, 해스켈로 적절히 코딩하기 힘들다. (파이썬 배울 때랑은 다르던군요.)
    • 제 코드 분명 최선과는 거리가 멀겁니다. 노빅씨의 알고리즘을 그래도 포팅한다는 제약 조건 하에서도 분명 더 우아한 해법이 존재할겁니다. 그 제약 조건이 없으면, 물론 훨씬 다양한 해법이 존재하겠죠(참고10).
    • 시간이 참 많이 걸렸지만, 그래도 유익한 코딩 연습이었다고 생각합니다. ^^

  • 참고자료
  1. Sudoku - Wikipedia: https://secure.wikimedia.org/wikipedia/en/wiki/Sudoku
  2. Solving Every Sudoku Puzzle: http://norvig.com/sudoku.html
  3. List comprehension - Wikipedia: https://secure.wikimedia.org/wikipedia/en/wiki/List_comprehension
  4. Implications of foldr vs. foldl (or foldl'): http://stackoverflow.com/questions/384797/implications-of-foldr-vs-foldl-or-foldl
  5. Monads for the Curious Programmer: http://bartoszmilewski.wordpress.com/2011/01/09/monads-for-the-curious-programmer-part-1/ http://bartoszmilewski.wordpress.com/2011/03/14/monads-for-the-curious-programmer-part-2/ http://bartoszmilewski.wordpress.com/2011/03/17/monads-for-the-curious-programmer-part-3/
  6. Functional Programming For Beginners: http://ontwik.com/scala/functional-programming-for-beginners/
  7. A Taste Of Haskell: http://ontwik.com/haskell/simon-peyton-jones-a-taste-of-haskell/
  8. Learn You a Haskell for Great Good!: http://learnyouahaskell.com/
  9. Real World Haskell: http://book.realworldhaskell.org/
  10. Sudoku - HaskellWiki: http://www.haskell.org/haskellwiki/Sudoku
  11. Haskell Cheat Sheet: http://blog.codeslower.com/static/CheatSheet.pdf

본 글의 영문 버전을 #AltDevBlogADay"Sudoku Solver in Haskell"로 게시하였습니다.
Trackback 0 Comment 6

자료구조에서 사이클 찾아내기

Tortoise racing hare


Linked list가 있다고 합시다. 이 연결 목록에 사이클이 있으면 무한루프를 돌게 되므로, 반복문을 돌기 전에 사이클이 있는지 검사하고 싶습니다. 어떻게 하면 될까요?

루프를 돌면서 한번 나온 노드들은 그 신분(C++의 경우 노드의 주소값이 편리하겠죠)을 기록해두었다가, 다 돌기 전 같은 놈이 또 나오면 사이클이 있다고 판단할 수 있겠죠. 한번 나온 놈들을 기록하는 자료구조로는 해쉬테이블이나 이진트리를 쓰면 될겁니다.

그러나 목록에 있는 아이템의 개수에 상관없이 단 두 개의 포인터만으로 사이클을 검출해내라 한다면 어떨까요? 다시 말해, 추가적인 저장소 오버헤드(위의 해쉬테이블이나 이진트리 같은)를 없게하고 알아내라는 말입니다.

이미 알고 계셨던 분을 제외하고는 방법을 짜내기가 쉽지 않을 겁니다.











그 차이는... 직선 경로에서는 속도가 다른 토끼와 거북이가 출발선 이외에서는 서로 만날 일이 다시 없지만, 원형 경로를 계속 달리는 경우에는 주기적으로 다시 만나게 된다는 것입니다. 이에 착안하여 나온 것이 Floyd의 알고리즘입니다. 하나씩 아이템을 살피는 거북이 iterator(혹은 포인터)와 하나씩 걸러서 아이템을 살피는 토끼 iterator를 사용합니다. 이를 개선한(이해하기는 좀 더 어렵지만) Brent의 알고리즘도 있군요. (해당 위키피디아 페이지에 알고리즘의 파이썬 코드와 자세한 설명이 나와 있으니 꼭 한번 읽어보세요.)

저장소 오버헤드에 대한 제약이 없다면, 굳이 이런 트릭을 써야 할 필요는 없습니다만, 사이클에 대한 토끼와 거북이의 통찰은 일반적인 패턴으로 익혀둘만 하다고 생각합니다. ^^




* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.
Trackback 0 Comment 7

뒤늦게 올리는 GDC 2010 리포트

첫째 날 20100309
둘째 날 20100310
셋째 날 20100311
넷째 날 20100312
다섯 째날 20100313
기타
공개된 슬라이드들



Advanced Visual Effects with Direct3D
  • D3D11에서는 'Tessellation'과 'DirectCompute'가 큰 테마더군요.


  • 저에겐 헷갈리는 주제였던 'HullShader'와 'DomainShader'의 역할에 대해 명확히 설명해 주었습니다.

간단한 로컬 방식과 비싸지만 더 그럴듯한 Catmull-Clark 근사 중 하나를 택할 수 있습니다. 



각 방식의 비교 

Left4Dead 2에서 피격 부위 렌더링에 관하여


 DirectCompute를 사용한 Diffusion DOF

Metro에서는 간단한 Phong tessellation 방식을 사용

  • D3D11에서 지원하는 D3D 리소스들의 별도 스레드 로딩은 상당히 유용해 보입니다.


Intel Game Performance Workshop (Presented By Intel)
  • 인텔의 프로파일링 도구들의 체험 위주였습니다.
  • 하지만 인텔의 'Smoke' 데모에 사용된 스레딩 전략은 흥미로워 보였습니다.

병렬 패턴들


더블버퍼링Overlapping Subset 방식의 비교




Designing for Performance, Scalability & Reliability: StarCraft II's Approach
  • 스타크래프트2에 사용된 게임내 프로파일링 도구에 관해 주로 다룸


심지어는 메모리 단편화 검사 도구도 제공

부하 테스트. 모든 스타크래프트 유닛 총출동!

  • 프로파일링 데이터를 수집한 후 저장해 놓아, 나중에 fps 그래프에서 튀는 부분을 찾아내어 그 시점에 어느 함수에서 가장 많은 시간이 소모되었는지 조사하는 등의 작업이 가능
  • 특별히 규모가변성을 위한 공학적 선택을 하였다고 진술 (가령, 전통적인 포워드 렌더링 대신 지연 렌더링을 선택)


Data is a Four-Letter Word
  • 어셋 스트리밍 관련

'Refgraph' 개념이 꽤 유용해보입니다.





'treap'이라 부르는 자료구조를 쓰고 있다더군요.

  • 현재 툴팀에 있는지라 관심이 갔던 세션
  • WAF라는 빌드 시스템 사용
  • 대부분의 파이프라인 도구룰 파이썬으로 개발
  • 자체 데이터 포맷인 ADF의 경우, 시리얼라이제이션 프레임웤이 포맷 규격에서 자동으로 C++ 헤더와 파이썬 코드를 생성해내는 방식 사용



Concrete Practices to be a Better Leader
"Everthing is my teacher."


"Training is the opposite of hoping"

 
GPU 정글쥬스나 쿠다 리브레 한잔 하실 분? (엔비디아 파티에서)
 

넷째 날 20100312
Agile: No Silver Bullet
  • 특별한 내용은 없었음
  • 트위터를 사용해 청중들한테 질문 받음

The Psychology of Game Design (Everything You Know Is Wrong)
  • 유명한 시드 마이어의 강연

  • 게임 플레이어와 기획자 사이의 암묵적 약속을 의미하는 'Unholy Alliance'라는 용어를 만들어냄
  • Protect players from themselves!(플레이어를스스로 게임의 재미를 망치는 것을 막아라!)



Animation Warping for Responsiveness in FIFA Soccer
  • 애니메이션 프로그래머들에게 귀중한 세션
  • 자연스러운 애니메이션 기반 턴 동작 처리를 위해, 'warp segments'라는 영리한 개념을 사용했습니다.


  • IK에 더해 별도의 와핑 기법을 사용함으로써 자연스러운 발의 볼 터치를 구현



APB: Creating a Powerful Customisation System for a Persistent Online Action Game
  • Real Time Worlds가 커스터마이제이션 엄청난 투자를 했더군요. APB의 개발이 왜 오래 걸리는지 알 것 같았습니다...


  • 일종의 텍스처 아틀라스(격자로 나뉜)와 메시 세그먼테이션으로 이음새 없는 캐릭터 커스터마이제이션과 런타임 성능이라는 두 마리 토끼를 동시에 노림




  • 매우 깔끔해보이는 엔드유저 커스터마이제이션 도구도 제공하더군요.







다섯째 날 20100313
Three Big Lies: Typical Design Failures in Game Programming

Texture compression in real-time, using the GPU

  • 짧았지만 매우 실용적이었던 세션이었습니다.

  • PC, Xbox 360, PS3를 모두 지원하는 크로스플랫폼 솔루션

  • 텍스처 압축에 관심이 있는 분이라면 슬라이드를 꼭 찾아보시길 권합니다.

The Imlementation of Rewind in Braid
  • 조나단 블로Jonathan Blow는 리와인드 기능을 위해 매우 무식해 보이는 방법을 택했습니다. 매 프레임 전체 월드 상태를 저장하는 것이지요.

  • 물론, 다양한 압축 기법을 적용하였습니다.






Animation and Player Control in Uncharted: Drake's Fortune and Uncharted II: Among Thieves
  • 애니메이션 프로그래머들을 위한 또다른 세션
  • 크라이엔진에서 했던 유사한 고민을 똑같이 하고, 비슷한 해법을 적용했음을 알 수 있었습니다.
레이어링 지원

애니메이션 미러링


애니메이션 제어에서 플레이어 제어로의 전환 곡선
  • 가산(additive) 애니메이션의 몇가지 영리한 활용 예를 보여주었습니다.
한프레임짜리 포즈 + idle 숨쉬는 동작 = 다양한 포즈에서의 idle 애니메이션

크라이엔진의 LMG 개념과 유사해보입니다.



Shears - Squeeze the Juice Out of the CPUs: Post Mortem of a Data-Driven Scheduler
  • 'Shears'라는 명칭의 멀티플랫폼 병렬 프레임웤

  • 굉장히 흥미로워 보였지만, 아쉽게도 자세한 기술적 내용의 공개는 꺼리는 눈치였습니다.
  • 아래와 같은 스케줄링 에디터도 제공하더군요.
  • 크로스플랫폼(PS3 SPU에 대해서도 추상화된 인터페이스 제공)
  • 락프리 컨테이너 활용

  • 쉬운 디버깅을 프레임웤의 핵심 기능으로 보고 작업했다더군요.


 

  • RAD game tools에서 몇가지 새로운 도구들을 선보였습니다.
    • Telemetry: 크로스플랫폼 지원의 타임라인 프로파일링 시스템
    • Iggy: 플래시 기반 UI 미들웨어
  • Hero Engine http://www.heroengine.com/ 부스에서 제공하는 에디터를 살펴볼 수 있었습니다.
    • 서버 기반 협업 편집 지원
    • C# 윈폼 기반의 깔끔한 GUI
    • 크라이엔진의 샌드박스와 같이 효율적인 작업 공정을 위한 빠른 이터레이션을 지향
  • 트위터에서의 GDC 2010 http://www.jesperjuul.net/ludologist/?p=953

공개된 슬라이드들

크라이텍 디너


 * 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.


Trackback 1 Comment 12

[해외 개발자 인터뷰] Tiago Sousa

오랜만의 개발자 인터뷰입니다. GDC 강연과 GPU Gems 및 ShaderX 기고글로 유명한 렌더링 가이, 티아고입니다.


  • 이름이 어떻게?
    • 티아고 소사  일명 미스터T
  • 어디 출신인가요?
    • 포르투갈 리스본
  • 어떤 일을 하고 있나요?
    • 7년간 크라이텍에서 시니어 그래픽스 프로그래머로 일하고 있습니다. 파크라이, 크라이시스 및 GDC/E3/테크데모 작업에 참여했고,최근에는 CryEngine3 작업을 하면서 여러 플랫폼에 걸쳐 불가능을 가능으로 만들고 있습니다. 
  • 간단히 이전 경력을 요약해주세요.
    • 여기가 첫 직장입니다 – 대학 일학년 때 크라이텍에 합류했지요.I came to Crytek when I was in my 1st year at college
  • 비디오 게임 업계에서 일하는 이유는?
    • 메가드라이브/슈퍼패미콤/스펙트럼 등 비디오게임 황금기의 게임과 콘솔들을 보면서 게임을 만들어보고 싶었습니다.
  • 직업과 관련하여 필수 사이트를 알려주세요. (최대 셋)
    • 셋은 너무 적군요. 일단 모든 그래픽스/콘솔 하드웨어 제조사 웹사이트가 필수고요, cgsociety.org에 영감을 주는 글들이 꽤 있고, realtimerendering.com과 같은 블로그도 매우 유용합니다.
  • 5년 후의 본인 모습은?
    • 실시간 그래픽스를 더욱 현실에 가깝도록 주무르고 있을듯 ^^
  • 삶에서 가장 중요한 것은 무엇인가요? (혹은 인생관이 있다면 무엇인가요?)
    • 제 아내와 가족, 그리고 무엇보다도 매일 하는 일에서 재미를 찾는 것
  • 이 분야에 들어오고자 하는 사람들에게 조언이 있다면?
    • 노력, 또 노력


바쁜 일정에도 짬을 내어 설문에 응해준 티아고에게 다시 한번 감사를 전합니다.  Thank you, Mr.T!


 * 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.


Trackback 0 Comment 6

Game Developer Blog Network 인증용 vefe3cc49 (냉무)


http://kgdn.tk/blog/
Trackback 0 Comment 4

차세대 게임개발 언어로 D에 주목하는 이유 - 마지막

2009/09/19 - [Game Development] - 차세대 게임개발 언어로 D에 주목하는 이유 - 1
2009/10/20 - [Game Development] - 차세대 게임개발 언어로 D에 주목하는 이유 - 2

~ The Sunny Side ~
~ The Sunny Side ~ by ViaMoi 저작자 표시비영리변경 금지

드디어 마지막입니다. 마지막인 만큼 강력한 놈들이 많이 나옵니다. 그 사이 시스템 프로그래밍 언어라는 같은 분야를 노리는 Go라는 강력한 경쟁자가 나타났습니다만... 여전히 D 언어만의 장점이 있습니다.


병렬 프로그래밍concurrent programming

제가 이전 글 2009/06/03 - [Game Development] - Double-checked locking 이디엄의 함정 에서 설명한 것처럼 아래와 같은 double checked lockingdata race라는 문제가 있습니다. 메모리 배리어가 필요하지만 사용도 까다롭고 포터블하게 제공하기도 어렵죠. 그래서 C++0x에서 이를 위한 별도의 라이브리러 함수 std::call_once()를 제공하는 것이죠. 이렇듯 병렬 프로그래밍에서의 race 문제는 저수준에서 접근하기에는 문제가 너무 많습니다. 그래서 언어 차원에서의 지원이 중요한 것이죠.

D에서는 모든 변수가 기본으로 thread local 입니다. 여러 스레드 간 공유를 위해서는 변수 선언 시 따로 shared로 명시해주어야 합니다. 공유 가능하나 불변하는 값을 가지는 변수를 위한 immutable이라는 형 수식 키워드도 제공합니다. 이런 접근을 통해서 컴파일러는 shared로 지정된 변수들에 대해서는 읽기/쓰기 재정렬을 방지하고 해당 변수 접근에 대해 자동으로 메모리 배리어을 삽입할 수 있습니다. 위 DCL 문제는 다음과 같이 하면 해결되는 것이죠. (아래 코드에서는  scope(exit) 라는 D 언어의 RAII 지원도 확인하실 수 있습니다.)


또한 함수형 언어의 기반인 순수 함수도 지원합니다. 순수 함수란 수학 함수에서와 같이 결과값이 입력인 함수 인자에만 의존하고 부수 효과(side effect, 전역 변수나 멤버 변수를 수정하는 것과 같은 상태의 변화)가 없는 함수를 말합니다. 따라서 같은 인자를 주면 언제나 같은 값을 리턴합니다. 이러한 순수 함수의 장점은 그 본성으로 인해 동기화가 필요 없다는 것입니다. 병렬화가 아주 쉽다는 것이지요. D에서는 다음과 같이 순수 함수를  선언하면 컴파일러 순수 함수로 동작하도록 보장해줍니다. 보장이 안될 경우 컴파일 에러가 난다는 뜻이지요.


이를 이용하면 최근 manycore의 대두와 함께 각광을 받고 있는 함수형 프로그래밍 방식으로 개발하는 것도 가능합니다. 물론 메모리 배리어는 성능 손실을 가져오므로, shared 변수를 남용하면 느려질 수 있습니다. 따라서 shared 변수는 최소화하고, immutable 변수와 순수 함수의 사용을 극대화하는 것이 좋습니다.

어쨌든 결론은 D는 언어 차원에서 병렬성에 대한 해법을 어느 정도 제시해준다는 것입니다. D에서의 병렬 프로그래밍에 관해 더 알고 싶으시면 http://su.pr/1h5Anx의 문서를 참고하세요.


계약 프로그래밍contract programming

D 언어는 계약에 의한 설계(DbC, Design by Contract) 개념을 지원합니다. 단순한 assertion에 차원을 넘어 precondition, postcondition, invariant의 개념에서 스펙을 명시할 수 있습니다. 아래의 제곱근 함수에서 precondition, postcondition, 함수 바디가 각각 in, out, body 키워드를 통해 어떻게 사용되는지 확인하실 수 있습니다.


불변식invariant도 다음과 같이 invariant 키워드를 통해 지정할 수 있습니다. 다음의 Date 클래스에서는 제대로 된 날짜라면 갖춰야 할 조건이 항상 만족되도록 불변식을 지정하고 있습니다.


이러한 계약에 의한 프로그래밍은 상속 개념과도 어울려 동작하도록 되어 있습니다. 더 자세한 사항은 곧 출간 될 The D Programming Language를 참고해주세요.


다중 서브타이핑multiple subtyping

마지막은 개체 지향 프로그래밍 관련 기능입니다.  많은 개체 지향 언어들어 서브타이핑의 방편으로 상속을 제공합니다. 하지만 상속은 워낙 결합도가 강해 의외로 단점이 많습니다. 또한 다중 상속은 구현상의 어려움도 많고 사용상의 주의점도 많아 C++ 이후의 대부분의 언어들이 지원하지 않고 있습니다. 보통 인터페이스 다중 상속만을 지원하지요. D도 마찬가지입니다. 인터페이스의 다중 상속만 가능합니다. 한편, 상속이 가지는 이러안 너무 강한 결합도라는 단점 때문에, 상속 보다는 composition을 통합 기능 결합을 추천하기도 합니다.

상속 이외에도, D 언어는 composition 기반 하에 상속과 같은 편의성을 제공하는 매우 유용한 서브타이핑 기능을 제공합니다. 예를 들어 Shape에서 상속 받아야 하는 구체 클래스가 있는데, DB와의 연동 기능(DBObject 클래스가 제공)도 필요하다고 가정해봅시다. D에서는 다중 상속 없이도 다음과 같이 할 수 있습니다.


alias this가 핵심인데요. 그렇게 해주면 unittest 섹션에서 볼 수 있는 것처럼 DBObject의 기능을 마치 상속 받은 것처럼 활용할 수 있습니다! (this()는 짐작대로 생성자입니다.) 더욱 놀라운 것은 다음과 같이 DBObject를 오버라이드하여 사용할 수도 있다는 것입니다. 이때는 D 언어의 또다른 강력한 기능인 nested class가 활용됩니다. (C++에서의 inner class 처럼 단순히 scope만 제한되는 기능이 아닙니다. 실제 outer 클래스 인스턴스에 멤버에 접근이 가능한 형태로 기능합니다. 더 자세한 설명은 역시 서적을 참고해주세요...;)


개인적으로 정말 깔끔하고 참신한 해법이라 생각합니다.

참고자료

D (programming language) - Wikipedia


이상으로 3회에 걸쳐 D 언어의 장점에 대해 살펴보았습니다. 역시나 본인의 이해력, 필력 부족으로 제가 느꼈든 참신함과 강력함이 제대로 전달되었을지 걱정입니다. 조금이나마 D 언어에 관심이 생기도록 일조했다면 다행이고요, 그런 분들은 필히 서적을 구입하여 일독하시기를 권합니다. ^^

잘 살펴보세요... 오묘합니다;;;

* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.


Trackback 0 Comment 7

크라이텍 아카데미

크라이텍 10주년 파티와 더불어 자체 컨퍼런스 행사, "Crytek Academy"가 11월 26,27일 양일간 있었습니다. 파티와 마찬가지로 프랑크푸르트 본사뿐만 아니라 다섯 군데 지사에서 모두 참여하는 이벤트였습니다.

내부 인력이 진행하는 마스터 세션과 대학 및 인텔, 엔비디아 등의 업체에서 초빙한 강사가 진행하는 세션들이 있었습니다. 회사도 처음 시도하는 행사라 파티 준비와 함께 나름 부산했는데요, 처음치고는 비교적 매끄럽게 진행되었습니다.


기가복셀, 라라피, 페르미, 다해상도 셰이딩, 인지 기반 가시성에 따른 LOD 적용 등 흥미로운 세션들이 많았습니다. 아쉽게도 세션 자료들을 공유하기는 힘들어 보입니다. 휴대폰 사진으로나마 크라이텍 아카데미의 분위기를 감상하시길...;






매우 유익하고 재미있는 시간이었고, 앞으로도 꾸준히 이런 행사들이 있었으면 좋겠군요. 국내 몇몇 게임 개발사들도 이런 행사를 진행하는 것으로 아는데... 더욱 많은 개발사들이 도입하여 인재 계발과 지식 공유의 장으로 활용했으면 합니다.


* 이 포스트는 blogkorea [블코채널 : 웹, 컴퓨터, it에 관련된 유용한 정보 및 소식] 에 링크 되어있습니다.


Trackback 0 Comment 12

top