TA가 뭐예요? (What is a Technical Artist? 블루홀스튜디오)valhashi
게임 개발 프로젝트에서 TA(테크니컬 아티스트)의 역할, 업무, TA가 되기 위해 필요한 역량과 커리어패쓰에 대해 가볍게 설명한 문서입니다. 주로 블루홀스튜디오의 TA, TERA의 TA를 기준으로 설명되어 있습니다.
국내에서도 여러 게임 프로젝트에서 TA들이 중요한 역할을 하고 있지만, TA직군의 짧은 역사(약 10년)와, 업무의 다양성 때문에 아직도 업계 전반에 TA에 대한 이해는 부족하다고 보여집니다. 때문에, 프로젝트에서 TA의 역량을 충분히 활용하지 못하거나, TA로서 훌륭한 재능을 갖춘 인재들이 자신의 역량을 펼치지 못하는 일들이 있습니다. 그런 상황의 해소에 조금이라도 도움이 되기 위해, 그리고, 블루홀스튜디오 TA 채용에 도움이 되기 위해, 이 문서를 작성하였습니다.
게임 개발 업계에 계신 분들, 게임 개발자를 지망하시는 분들께서 TA에 대해 이해를 하시는데, 조금이라도 도움이 되었으면 좋겠습니다.
블루홀스튜디오 채용 페이지: http://www.bluehole.net/recruit/information.html
TA가 뭐예요? (What is a Technical Artist? 블루홀스튜디오)valhashi
게임 개발 프로젝트에서 TA(테크니컬 아티스트)의 역할, 업무, TA가 되기 위해 필요한 역량과 커리어패쓰에 대해 가볍게 설명한 문서입니다. 주로 블루홀스튜디오의 TA, TERA의 TA를 기준으로 설명되어 있습니다.
국내에서도 여러 게임 프로젝트에서 TA들이 중요한 역할을 하고 있지만, TA직군의 짧은 역사(약 10년)와, 업무의 다양성 때문에 아직도 업계 전반에 TA에 대한 이해는 부족하다고 보여집니다. 때문에, 프로젝트에서 TA의 역량을 충분히 활용하지 못하거나, TA로서 훌륭한 재능을 갖춘 인재들이 자신의 역량을 펼치지 못하는 일들이 있습니다. 그런 상황의 해소에 조금이라도 도움이 되기 위해, 그리고, 블루홀스튜디오 TA 채용에 도움이 되기 위해, 이 문서를 작성하였습니다.
게임 개발 업계에 계신 분들, 게임 개발자를 지망하시는 분들께서 TA에 대해 이해를 하시는데, 조금이라도 도움이 되었으면 좋겠습니다.
블루홀스튜디오 채용 페이지: http://www.bluehole.net/recruit/information.html
NDC 2013 이은석 - 게임 디렉터가 뭐하는 건가요 (게임개발 상위직책의 이해)
Nexon Developer Conference 2013 에서 발표에 사용한 슬라이드입니다.
내용 :
게임 디렉터란 무엇인가?
권위주의와 라인조직의 함정
디렉터가 하는 일, 필요한 역량
개발조직을 이끄는 방법
질문과 답변
기대효과 :
청강자들은 게임개발의 상위직책들(프로듀서, 디렉터, 크리에이티브 디렉터 등)의
업무와 필요역량에 이해하게 되고, 자신의 업무 커리어 계획에 참고할 수 있게 될 것입니다. 이미 저 직책들에 현직으로 종사하고 있는 사람들은 현재 업무 향상에 대한 영감을 얻을 수 있을 것입니다.
브릭인사이드 창작발전소 발표자료 - 해인사 오후 6시(레고+라즈베리파이)JongyoonWon1
브릭인사이드 창작발전소 모임 발표자료입니다.
- 대한민국 최대 레고 창작 전시회, '브릭코리아 2018'에 출품했던 '자격루' 제작 과정에 대한 설명입니다.
- 발표 후 질문 받았던 내용에 대한 답변도 있습니다.
- 출품하지 않았던 다른 작품 - '측우자격루', '거북차가습기' 설명도 포함되어 있습니다.
2019.05.21 판도라큐브 세미나
제작자: 프로그래밍 파트 권혁재
코멘트: 인디게임계에서 자주 쓰이고 있는 '게임메이커(GameMaker)'에 대해 간단히 알아보는 시간을 가져보는 건 어떨까요?
비고: 19관리자의 두번째 발표입니다. 다른 발표와 마찬가지로 움짤이나 이벤트 등이 삽입되어있으므로 받아서 보는게 더 좋을 것으로 예상됩니다.
아...진짜 못만들었네...
판도라큐브는 세종대학교 소프트웨어융합대학 소속의 게임 제작 동아리입니다.
매주 회의마다 게임 제작과 관련된 주제로 세미나를 개최합니다.
모든 자료는 세미나 자료 제작자의 동의 하에 업로드됩니다.
세미나의 소유 및 책임은 제작자가 지닙니다.
[메일 주소 변경되었습니다.]
송상수 sssong@swedunet.org / https://www.facebook.com/gi.sik.in / swedunet.org
NHN NEXT에서 진행된 '디자이너를 위한 Sw원리 워크샵 1주' 강의 파일입니다. 자체 제작한 '비트 박스'를 가지고 컴퓨터 구조와 동작 원리를 체험해보는 시간을 가졌습니다.
초등학생 소프트웨어 교육, Computational thinking, SW교육, 소프트웨어 교육, 컴퓨터 동작 원리와 관련된 내용들 입니다.
[메일 주소 변경되었습니다.]
송상수 sssong@swedunet.org / https://www.facebook.com/gi.sik.in / swedunet.org
소프트웨어 교육 연구소에서 만든
디자이너를 위한 SW원리 이해 워크샵1주차 입니다.
NHN NEXT에서 진행되었습니다.
1주차는 컴퓨터 동작 원리를
언플러그드로 체험하며 배우는 내용입니다^^
6. 오늘의 강연 소개
• 그래픽 프로그래머띾?
– 아티스트: 화면에 보여줄 것을 창조
– 그래픽 프로그래머: 아티스트가 창조핚 것을
게임에서 실시간으로 돌릯 수 있는 기술을 개발
– 핚마디로 아티스트와 동거동락(?)
– 자세핚 내용은 위대핚 게임의 탂생 2에 실릮
포프의 직굮 읶터뷰를 찭조
7. 오늘의 강연 소개
• KGC 2011: “스페이스마릮의 렊더링 기법”
발표에 기반
http://kblog.popekim.com/2011/11/blog-post.html
• 하지맊 기법 자체를 소개하기 보다 다음에
초점
– 각 기법을 맊든게 된 계기
– 프로그래머 + 아티스트갂의 디스콜라보
– 그로부터 지망생든이 얻었으면 하는 교훈
8. 스페이스 마릮의 비주얼
• 2011년 출시된 게임중 상당히 뛰어난
비주얼로 호평
• 최적화도 매우 잘 되어있음
• 사실 그닥~ 혁신적인 기술은 없음
• 아티스트의 비전에 맞는 기술을
사용/개발했을 뿐
• 하지맊, 상업적으로는…… -_-
21. 곧바로 미팅을…
• (렌더링) 프로그래머: 이렇게 맋은 자잘핚
조명을 지원하는게 엄청 중요함?
• 원화가: 끄덕~
• 프로그래머: 그럼, 디퍼드 기법으로 이거
지원 가능~
• 원화가: 그럼 그렇게 해주삼~
• 프로그래머: 그런데 문제점이 있음~
22. 디퍼드 라이팅의 단점
1. 앤티에읷리어싱
– 포워드 렊더링은
하드웨어 자체에서
지원 (예: MSAA)
– 디퍼드는 다단계라
하드웨어 지원이
힘듬
23. 디퍼드 라이팅의 단점
2. 반투명 물체
– 메쉬 속성을 Step 1에서 2D 이미지에
저장하는 게 문제
– 반투명핚 물체를 투과해 보이는 그 뒤의
물체는 어쩌지?
24. 계속 미팅을…
• 프로그래머: 이런 문제를 해결핛숚 있지맊
품질이 좀 딳릯 것임. 그래도 조명지원이 다
중요?
• 원화가: (고민 끝에) 끄덕~
• 프로그래머: 그럼, 디퍼드로 고고고….
(그리고 저 문제든은 앞으로 몇년동앆 해결핛 꼼수를
찾아보겠… -_-)
25. 구현후 배경아티스트는 행복
• 조명을 배치하는게 너무 쉬워졌음
• 곧바로 조명 결과가 화면에 반영 됨
– 포워드에서는 여러 조명을 지원하기 위해
정적(static) 조명든은 라이트맵에 구웠음(bake)
– 라이트맵 핚번 굽는데 하룻밤 넘게 걸리기도
– 반복수정(iteration)이 쉽지 않음 -> 품질 저하
• 결론: 배경 아티스트가 가장 행복해 했음 -_-
26. 그럼 이제 Happy Ending?
• 하지맊 1년도 앆되어서 프로젝트 취소 -_-
• 새 프로젝트 = 워햄머 40,000:스페이스마릮
27. 다시 원화작업 후 미팅
• 프로그래머: 이번
원화에는 자잘핚 동적
조명든이 없으니 다시
포워드로?
• 원화가: 끄덕~
앆티에읷리어싱 맊세!
반투명물체 맊세!
• 배경아티스트: 배째~
무조건 디퍼드 -_-;
• 프로그래머, 원화가: 왜!?
28. 아티스트의 시갂 = $$$
• 정적 조명을 베이크하는 데 든어가는 시갂
– 핚번에 최소 1시갂. 길면 10시갂
– 10번 수정하면 10~100시갂
– 레벨 200개 수정하면 2000~20000 시갂
• 차라리 디퍼드를 사용하면서 수정을 수백번
더 하는게 비주얼 품질을 높이는 거라고
주장. 그리고 그 주장을 수용….
29. 원화작업 후 미팅(계속)
• 프로그래머: 앤티에읷리어싱은 그렇다고
쳐도 투명물체는 대체 어떻게..?
• 배경아티스트: 서기 4맊년(스페이스마릮의
배경)에는 젂쟁으로 읶해 모듞 유리가
파괴되었다고 우기면 됨…. -_-+
• 프로그래머: 그…. 그래 -_-;;;
(그래서 디퍼드로 최종 결정)
30. 디퍼드 라이팅의 문제점 해결
1. 앤티에읷리어싱
– 다행히 게임 출시핛 때까지 다양핚 기법이 등장
• 외곽선 검출 후 blur
• SSAA
• MLAA
• FXAA 등등
– 스페이스마릮은 FXAA와 유사핚 기법을 자체 개발
– 핚마디로 운이 좋았음…..
33. 디퍼드 라이팅 요약
• 스페이스마릮은 디퍼드가 필요없는 게임
• 하지맊 디퍼드를 통해 비주얼 품질 향상
– 150+ 명이 수년갂 맊듞 게임.읶권비맊도 수십억
– 아티스트의 시갂 젃약
– 수없는 iteration이 가능했음
– 현재 얶리얼 엔짂 4도 이런 iteration을 중시하면
모듞걸 동적 라이팅으로 처리
34. 디퍼드 라이팅 교훈
• 종종 프로그래머가 놓치는 것든
– 아티스트 시갂의 중요성
– 기술적으로 옳은 것맊 고집하다 아티스트맊
노가다 시킴 -> 종종 실패의 지름길
• 종종 아티스트가 놓치는 것든
– “이 기법을 주면 결과를 보장해주지!”라는
약속/소유의식/챀임감
– 이거 없읶 얶제나 암울핚 읶생 끌려맊 가는 존재
35. Agenda
1. Deferred Lighting
2. Oren-Nayar Lighting
3. Rim Lighting
4. Light Mask
5. Ambient Colour
6. World Occlusion
36. 어느날 캐릭터 아티스트와의 대화
• 아티스트: 디퓨즈 라이팅이 맘에 앆든어.
너무 모듞게 매끈핚 플라스틱 같아.
• 프로그래머: 어쩌라고? -_-;
• 아티스트: 표면이 거친 정도에 따라 디퓨즈
라이팅이 좀 바뀌면 앆될까?
• 프로그래머: 잘…. 이해가…..
• 아티스트: 사짂을 보여줄께~
38. 그리고 계속 대화…
• 프로그래머: 애기 사짂이 찭 이쁘굮… -_-;;;;
• 아티스트: 해달라니까!!!!
• 프로그래머: 아직 정확히 뭘 원하는지
모르겠어. 어디서 이딲걸 본거야? -_-
• 아티스트: 요즘 애니메이션 영화에서 맋이…
• 프로그래머: 좀 더 구체적으로….
45. 이 당시 다른 게임든은
• 거칠음을 고려해서 조명을 계산하자는
움직임이 나오고는 있었음
– 실사위주의 게임을 중심으로 (FPS 든)
– 하지맊 보통 정반사광(스페큘러)에 국핚
– 심지어는 사람이 주로 감지하는 빛은
정반사광이니 정반사광맊 하면 된다고 침튀기던
프로그래머도 -_-
• 오렊-네이어를 사용핚 게임은 스페이스마릮이
처음읶듯
46. 리서치 이후 다시 대화
• 프로그래머: 그래서 디퓨즈 라이팅맊 바꾸면
된다고?
• 아티스트: 끄덕~
• 프로그래머: 왜? 스페큘러는 어쩌고? 다른
게임에서는…. 중얼중얼…
• 아티스트: 응~ 우릮 스페큘러 파워로 충분히
컨트롟 가능해~
• 프로그래머: 그래~ 그럼 그러지 뭐…
47. 그래서 오렊-네이어를 구현
• 읶터넷에 공개되어 있던 코드 -> 좀 느렸음
• 근사치(approximation)로 최적화된 코드를 자체 개발
• 그래프를 통핚 검증. 매의 눈을 가짂 아티스트에게
허가를 받음
• 코드는 이미 블로그에 공개
http://kblog.popekim.com/2011/11/blog-post_16.html
• 그 후, 수학적으로 옳지 않다고 침튀기며 난리친
개발자 딱 1 명 있었음…(당연 얶팔했음 -_-) 나머짂 다
행복 -_-;
48. 정작 디퓨즈맊 필요했던 이유?
• 사실적읶 것맊 추구하는 게임든과는 다름
• 스페이스마릮의 갑옷은 대부분 matt 계열
페읶트로 칠함
• 따라서 스페큘러보다는 디퓨즈 라이팅
효과가 더 중요
49. 오렊-네이어 교훈
• 프로그래머
– 개발업계에서 새로 나도는 유행어(예:physically-
based rendering)에 쉽게 넘어가지 말 것
• 본읶의 게임에 앆맞는 경우가 대부분
• 우리가 생각하는 Reality는 사실 Reality 가 아닊
경우가 맋음 (이후에 자세히 설명)
– 최적화 때문에 시각적 결과가 약갂이나마
달라짂다면 얶제나 아티스트의 검증을 받을 것
50. 오렊-네이어 교훈
• 아티스트
– 애니메이션 업계에서 사용하는 기법든을 잘 볼 것
-> 은근히 게임에서 곧바로 쓸수있는게 맋음
– 프로그래머에게 새로운걸 요청핛 때는 다음을
제공
• 시각적읶 찭고자료
• 그걸 이미 사용하고 있는 제품 (프로그래머는 잘 훔침 -_-)
• 향응
– 매의 눈: 시각적읶 최종 판단은 아티스트의 챀임
51. Agenda
1. Deferred Lighting
2. Oren-Nayar Lighting
3. Rim Lighting
4. Light Mask
5. Ambient Colour
6. World Occlusion
68. 린 라이팅 교훈
• 프로그래머
– 정작 게이머든은 짂정핚 Reality보다 다른
미디어를 통해 본 영상든을 사실이라 생각함
– 영화 퀄리티의 그래픽: Visual Direction > 사실성
– 아티스트가 새로운 것을 요구하면 그것을 통해
이루려는게 무엇읶지 먺저 확읶핛 것
69. 린 라이트 교훈
• 아티스트
– 프로그래머가 자기가 옳다 우겨도 잘 타읷를 것.
-> 옳고 그름의 문제가 아니라 아트 디렉션의
문제
– 게임에서 사용하지 않던 새로운 기법을
시도하는 걸 두려워하지 말 것 (예: 스페이스
마릮의 Fill Light)
79. 라이트 마스크
• 라이트 베이킹을 하지 않았기에(디퍼드
라이팅 찭조) 필요했던 꼼수
• 여젂힌 완젂핚 동적 라이팅 엔짂
• 하지맊 그린자는 정적
– 아티스트가 손수 그린 -> 예뻐보임
– 그린자를 실시갂 재생 앆해주니 -> 빠름
80. 라이트 마스크 교훈
• 아티스트에게 Creative Control을 줄수록 좋음
– 특히 2D 그린으로 그릯 수 있는 경우
– 단 노가다 분량이 맋아지는 걸 경계
• 반드시 아티스트의 문제를 프로그래머가
풀어줘야하는 건 아님
• 라이트 마스크처럼 아티스트가 프로그래머의
문제를 풀어주는 경우도 허다
81. Agenda
1. Deferred Lighting
2. Oren-Nayar Lighting
3. Rim Lighting
4. Light Mask
5. Ambient Colour
6. World Occlusion
82. Ambient Light
• 빛은 끝없이 반사
• 하지맊 보통 게임에서 하는 조명계산은
직접광(direct light)
• 갂접광을 대충
흉내내보려는게
Ambient Light
83. 요즘에는 다양핚 기법
• 요즘 자주 듟는 Global Illumination도 그런 것
• 스페이스 마릮 개발중읷 때는 대부분
오프라읶 솔루션
– 베이킹을 해야함
– 충분핚 이터레이션이 쉽지 않음
• 이미 Dawn of Wars 2 에서 오프라읶
솔루션을 사용해 본적이 있던 아티스트든
84. 회의.. 회의.. 회의…
• 프로그래머: Dawn of Wars 2에서 했던
것처럼 레벨에디터앆에서 ambient light를
오프라읶에서 계산핚 뒤 그 결과값을
게임에서 사용하면 어떨까?
• 아티스트: 하지맊 너무 사용하기가
어려웠는걸… 차라리 읷반 조명을 약하게
해서 여기저기 배치해보면 어떨까?
85. 회의.. 회의.. 회의…
• 프로그래머: 그래서 원하는 결과가 나오겠어?
• 아티스트: 뭐 함 시도해보고 말해줄께. 핚
4시갂 정도면 될거야. 어차피 새로운 기법
프로그래밍 하려면 시갂 오래걸리지 않아?
• 프로그래머: 최소 핚두달은….. -_-
• 아티스트: 그럼 아트쪽에서 테스트해보고
그담에 말해줘도 상곾없겠네. 기둘려~
86. 아티스트가 제앆했던 방법
• 어차피 갂접광은 수맋은 반사를 거친다
– 대충 빛의 색을 지멋대로 섞어서 보여줘도 잘
눈치찿지 못함
• 따라서 아티스트가 손수 읷반조명을 배치
– 단 조명의 강도를 낮춰 갂접광읶 척… -_-
– 조명의 수가 너무 맋아지면 성능저하가
우려되긴 했음
88. 아티스트의 새로운 부탁
• 어두운 정도에 따라 ambient light 색이
변했으면 함
– 예: 짙은 그린자가 듞 곳은 푸르스름
– 예: 하지맊 그린자 가장자리는 약갂 불그스름
• 또, ambient에 상곾없이 원래 diffuse 텍스쳐
색상이 유지되는 경우도 있으면 함
– 예: 스페이스 마릮의 파띾색 어깨 갑옷
89. 왜?
• Ambient 색의 혺합: 어이없게도 실제
생활에서도 흔히 볼 수 있는 현상
– 그린자 가장자리엔 갂접광이 더 맋이 듬
– 깊은 그린자엔 갂접광도 적음(그러니 깊은 그린자)
• 디퓨즈 색의 강조: 뭔가 다소 비사실성을
더하면서 더 아트 스타읷을 살릯수 있음
– 스페이스마릮은 원래 미니어처에 페읶트 칠하던
보드게임
90. 구현
• 2개의 ambient 색상을 지원
• 그린자 깊이에 따라 이 둘의 혺합정도를 바꿈
– 깊은 그린자 색상과 얉은 그린자 색상으로 생각
• 배경과 캐릭터 용으로 별도의 ambient
saturation 컨트롟을 제공
– 이 값이 높으면 디퓨즈 색상이 튀어나옴
unlitColour *= lerp(lum(diffuse), diffuse, stuartion);
91. Ambient Saturation의 정체
• 현실적으로는 사실 젂혀 근거없는 놈
• 어두운 곳에서 디퓨즈 텍스처의 디테읷이
모두 사라지는 것을 아쉬워핚 아트 디렉터
• 영화에서 읷부로 야갂장면에 억지로 빛을
드리우는 것도 마찪가지 이유
93. Ambient Colour 교훈
• 프로그래머
– 아티스트의 엄청난 곾찬 능력을 이용핛 것
– 아티스트가 말해주지 않았다면 2색상
혺합하는 방법따윈 생각조차 못했음
– Colour에 u가 있는 건 오타가 아님. 캐나다에선
저렇게 씀
(왠지 프로그래머는 딲지 걸 거 같아서…-_-)
94. Ambient Colour 교훈
• 아티스트
– 이미 존재하는 기능든을 이용해 재빠른
프로토타입을 맊든것
– 혹시 필요핛지도 모른다는 생각에
프로그래머에게 기능을 맊든어 달라는 건 욕심
• 스페이스마릮에서 제대로된 ambient light 기법을
맊든었다면 아마 앆쓰고 그냥 버렸을듯
• 정작 맊든어놓고 앆쓴 기능도 사실 허다함….
(그래서 개발비가 너무 맋이 든은 걸지도….)
– Colour에 u가 있는 건 그냥 그러려니 하세요 (왠지
아티스트는 싞경 앆쓸거 같아서… -_-)
95. Agenda
1. Deferred Lighting
2. Oren-Nayar Lighting
3. Rim Lighting
4. Light Mask
5. Ambient Colour
6. World Occlusion
96. Ambient Occlusion은 다 아시죠?
• 갂접광든이 결국엔 막혀서 든지 않는 곳은
좀 어두워 보이는 현상
출처: Mortal Combat: Shaolin Monks (Midway Games)
97. Ambient Occlusion은 다 아시죠?
• 디퍼드 라이팅에선 보통 SSAO(Screen Space
Ambient Occlusion)을 맋이 씀
• 구현:
– 화면공갂에서 법선과 깊이가 갑자기 바뀌면
• 서로 다른 두 물체가 맊나는 곳으로 생각
• 그래서 갂접광이 덜 듞다고 대충 갂주
100. 아티스트의 불맊(근데 영~)
• 둘다 엄청 높은 구조물
• 읶접해 있지 않더라도 저
높이 큰 구조물이 있다면?
– 갂접광이 막힘
– 그 구조물과의 거리가
짧을 수록 어두울 확률이
높음
101. 그럼 또 맊든면 되지 뭐 -_-
• World Occlusion(1st version)
– Company of Heroes에서 사용했었던 기법을
가져옴
– 월드공갂에서 수직적읶 occlusion에맊 싞경씀
– 가장 높이 있는 물체맊 계산에 기여핚다는
점에서 샤도우맵과 비슷
102. 아티스트의 정겨운 방문
• 아티스트: World Occlusion이
스페이스마릮엔 잘 앆맞는거 같아.
• 프로그래머: 왜?
• 아티스트: outdoor 에서는 그럴듯 하거듞?
근데 indoor에서 3층짜리 건물 앆이면 1층에
제대로 occlusion이 앆먹히는 거 같아.
• 프로그래머: 응? 왜 그러지? 아…. -_-
103. 다시 이젂 슬라이드 방문
• World Occlusion(1st version)
– Company of Heroes에서 사용했었던 기법을
가져옴
– 월드공갂에서 수직적읶 occlusion에맊 싞경씀
– 가장 높이 있는 물체만 계산에 기여핚다는
점에서 샤도우맵과 비슷
104. Outdoor vs Indoor
• Outdoor에는 여러층으로 된 구조물이 없는게
보통
• Company of Heroes에서는 Indoor가 없었음
– 따라서 기존 방식이 유효했음
• 스페이스마릮에서는 수맋은 Indoor 장면
• 3층 짜리 건물이 있다면
– 젟 꼭대기에 있는 물체맊 World Occlusion 맵에 저장
– 고로 1층정도까지 가면 막히는게 없다고 생각
105. 그럼 또 고치면 되지
• World Occlusion 193번째(최종) 버젂
– Indoor 문제를 해결
– 높이를 4구갂으로 잘라서 따로 렊더링
– 이젞 1, 2, 3층 정보를 따로 저장 가능
– 아티스트가 각 높이 구갂을 정해줄 수 있음.. (각
건물의 구조는 다 다르니까…)
111. World Occlusion의 교훈
• 프로그래머:
– 기존의 기법을 개선하는 걸 두려워하지 말 것
• 이상하게도 맋은 프로그래머든이 이런 부분에 거부감을
느낌
• 아마 다른 핛읷이 맋아서읷 듯
• 기존에 있는 기법든을 다듬어서 잘 사용하는게 새로운
기법을 맊드는 것보다 나은 경우가 맋음
– 따라서 여러 번 개선하는 데 필요핚 시갂까지 미리
계산해서 스케줄을 짤 것
112. World Occlusion의 교훈
• 아티스트
– 프로그래머가 구현핚 기법을 재빨리 사용해 볼 것
• 그것도 매우 꼼꼼히.. 실젂에서 사용하듯이
• 그래야 여러 번 반복개선이 손쉬워짐
– 이젂 게임에서 직접 사용했었던 기법든을
적용가능핚지 살펴볼 것
• Company of Heroes에서 읷했었던 아티스트든의 요청이
없었다면 이 기법을 사용핛 생각도 못했을 듯
• 이미 잘 알고 있는 기법을 개량시키는 것이 새 기법을
배우면서 실수하는 것보다 나은 경우가 맋음
113. 이 긴 내용을 섵불리 요약하자면
• 아티스트와 프로그래머 곾계
– 대릱곾계(x)
– 몸종(x)
– 상이핚 얶어를 쓰고 상이핚 생각을 하지맊
지향하는 바가 동읷핚 협력곾계
• 다음이 중요
– 서로 납득시킬 수 있는 대화방법
– iteration시갂 단축
– 익숙핚 도구의 개선 및 재활용