[TOC]

[교재 설명]
24cc376ea98f25ca63207a85fdfc6b97.
<'한계를 넘어서' (엘리 골드랫 지음)>

[수업 내용]

들어가며


게임제작은 여러 가지 프로세스의 조합으로 이루어집니다. 기획-배경제작 기획-캐릭터제작 기획-프로그래밍 기획-유료아이템제작 등등...이렇게 보자면 기획과 다른 파트와의 업무흐름만 잘 조율되면 모든 제작 프로세스가 원활하게 돌아갈 것 같지만 실상은 그렇지 않습니다. 배경을 제작한다는 것은 맥스에서 모델링을 하고 포토샵에서 텍스처를 제작한 다음 데이터를 익스포트 하고 퇴근 하면 다음날 아침부터 게임플레이가 되는 것이 아닙니다. 터레인 툴에서 지형을 만들고 인하우스 툴로 빛의 방향이나 포그의 색, 스펙큘러의 강도등 여러가지 파라미터를 바꿔보면서 적정한 값을 찾기도 해야 합니다. 다시 말해 배경과 터레인/인하우스 툴을 제작하는 프로그램팀의 업무흐름 역시 중요합니다. 그럼 여기서 끝나냐 하면 배경에서 캐릭터를 움직여 보고 배경의 색감이 지나치게 화려해서 캐릭터가 돋보이지 않는 것은 아닌지 확인해보고 캐릭터 팀과 배경-캐릭터의 색감을 조율해야 합니다.

 

모든 팀들이 다른 모든 팀들과 이런 협조관계에 있는 것은 아닙니다.

 

기획

배경

캐릭터

프로그램

애니메이션

기획

.

O

O

O

O

배경

O

.

O

O

X

캐릭터

O

O

.

O

O

프로그램

O

O

O

.

O

에니메이션

O

X

O

O

.

 

배경팀과 애니메이션 팀은 협조관계에 있지 않군요;;

 

요는 한 팀이 얼마나 열심히 일하느냐 만큼 두 개 이상의 팀이 얼마나 잘 협조하고 프로세스를 잘 구성하느냐가 프로젝트 성패에 지대한 영향을 미친다는 것입니다.

TOC는 팀간의 관계와 업무 흐름이 최종 아웃풋에 얼마나 영향을 미치는지를 잘 설명해 줍니다.

 
우린 정말 열심히 일했어


제철소가 있습니다. A, B, C, D, E라는 팀이 있고 A->B->C->D->E팀의 공정을 거쳐서 최종 아웃풋이 나오게 됩니다. 각 팀은 자신의 공정을 처리하기 위해서 재료(철광석)를 쓰게 됩니다. 제철소에 500t의 철광석이 공급되었습니다. 평소와 다를 바 없던 어느 날 B팀의 팀장과 팀원들이 회사의 매출을 향상시키기 위해서 굳은 결의를 하고 철야작업을 시작합니다. B팀은 밤낮없이 일하고 공급된 500t의 철광석 중 400t의 철광석을 B팀의 아웃풋인 철근으로 바꾸어냅니다.

 문제는 A,C,D,E팀은 일하기 위한 재료인 철광이 100t밖에 남지 않게 되었다는 것입니다. 다른 팀들이 각각 25t의 철광을 자기 팀의 아웃풋으로 바꿀동안 B팀이 400t의 철광을 자기 팀의 아웃풋으로 만드는 바람에 최종 아웃풋은 결국 25t 어치 밖에 나오지 않았습니다.

 

부분 최적화의 함정


 열심히 일하는 것은 중요합니다. 직원에게는 자신의 커리어의 가장 중요한 부분이라 할 수 있는 타이틀의 출시와 성공을 위해서 회사에게는 투입된 자원 대비 높은 성과를 위해서 모든 팀들이 제각기 열심히 일하는 것은 중요합니다. 문제는 우리가 열심히 일하는 만큼 어디선가 공급된 자원을 쓰고 있을 확률 역시 높다는 것입니다. 기획자가 굉장히 스마트한 몬스터 AI를 만들고자 한다면 그런 AI를 구성하기 위해서 프로그래머에게 몬스터의 상태를 알아오고 주변 상황을 판단하기 위한 다양한 스크립트 함수를 요청할 것입니다. 그리고 더 스마트한 판단을 위해서 스크립트에서 더 많은 쿼리를 게임엔진에 날리게 될 것입니다. 이는 곧 프로그래머라는 자원과 서버의 프로세싱파워라는 두가지 자원을 사용하고 있다는 것을 의미합니다. 

 
캐릭터 디자이너 역시 더 뽀대나는 그래픽을 위해서 엔진 프로그래머와 클라이언트의 프로세싱 파워라는 두가지 자원을 쓰게 되겠죠. 만약 AI기획자가 너무 열심히 일해서 서버의 프로세싱파워의 90프로를 AI처리를 위해서 쓴다거나 캐릭터 디자이너가 동영상급의 캐릭터 퀄리티를 원해서 클라이언트 GPU프로세싱 파워의 90프로를 자기 캐릭터 하나 그리는데 쓰게 한다면물론 이것은 극단적인 케이스입니다.

 제철소의 자원이 철광석이라면 게임회사의 자원은 다른 개발자 혹은 서버/클라이언트의 프로세싱 파워라고 할수 있겠군요. 물론 개발비도 포함됩니다.

 

우선순위


자신의 위치에서 꿋꿋이 일하는 사람들이 많다는 것은 좋은 일입니다. 하지만 가끔은 너무 꿋꿋하지 말고 좀 두리번거릴 필요도 있을 것 같습니다. 프로그래머 A씨가 있습니다. A씨는 아침 9시에 출근합니다. 그리고 팀장에게 메일로 온 작업리스트를 확인하고 랜덤하게 하나의 작업을 고릅니다. 오늘은 파일 IO를 좀더 최적화해보기로 했습니다. 근데 작업리스트에는 운이 없게도 몇 달 동안 채택되지 못한 작업도 있습니다. 가령 캐릭터 지형 위에서 걷게 하기” “배경 그래픽 데이터 엔진에서 나오게 하기” “서버에서 AI/전투 스크립트 작동하게 하기

A씨가 몇 달 동안 맥스만 만지작 거리면서 이게 엔진/게임에서 어떻게 나올까 궁금해하는 디자이너 혹은 열심히 AI FSM 도표만 그리는 기획자와 좀더 친했다면 좋았겠죠.

 

안전시간

개발자들은 안전시간을 좋아합니다. 왜냐하면 개발 중에는 어떤 돌발변수가 발생할 수 있기 때문입니다. 캐릭터 디자이너 B씨는 항상 일정을 지키지 않는 원화 디자이너 때문에 골치입니다.

원화 디자이너가 2주 후에 준다고 했으니 분명히 3주 후쯤에나 원화가 올거야. 내 작업시간은 2주면 되지만 어차피 저 사람들이 늦을거니까 작업시간은 3주라고 해야겠군. 음 근데 작업을 하다보면 마음에 안들어서 재작업을 하고 싶을 수도 있잖아. 갑자기 바이러스에 걸려서 맥스가 안켜질수도 있는거구. 3일정도 더 추가해도 되겠지


 
문제는 이것입니다. 원화 디자이너가 이번에는 운좋게 2주만에 원화를 캐릭터 디자이너에게 넘겼다 하더라도 캐릭터 디자이너의 원래의 일정인 3 3일이 짧아질 가능성은 희박하다는 것입니다. 사람들은 이미 가지게 된 여유를 쉽사리 반납하려 하지 않거든요. 이러면 어떨까요?


원화 디자이너 : 내 작업이 2주 걸릴 듯 한데 1주 정도 더 걸릴지도 모르겠어요.

캐릭터 디자이너 : 내 작업은 2주 걸릴 듯 한데 3일 정도 더 걸릴지도 모르겠어요.


1
3일을 각자 쓰지 않고 뒤로 몰아놓는 것입니다. 이러면 운이 나쁘던 좋던 5 3일 혹은 그 이상의 기간이 걸리기 쉽상인 전체 일정이 운좋으면 4주 재수가 없는 경우 5 3일이 걸리게 된답니다. 솔직함과 서로간의 신뢰가 필요한 때입니다.

 

크리티컬 패스

배경디자이너 C씨는 오늘도 배경팀에 와서 기웃거리는 기획자 D씨가 꽤 거슬립니다. 기획자 D씨가 아직 완성되지도 않은 배경데이터를 달라고 맨날 와서 조르기 때문이죠. “아니 그게텍스처가 좀 안예뻐도 좋으니까… NPC배치랑 퀘스트만 시켜볼수 있으면 되니까…” 하지만 어림없는 일입니다. 아직 텍스처도 제대로 못 입힌 배경 데이터를 다른 사람들에게 내보인다는 것은 있을 수 없는 일입니다.

너무 단순화시킨게 아닌가 싶기도 하지만 게임데이터 제작을 크게 두가지 흐름으로 나누어 본다면

원화디자인 -> 배경(레벨) 제작 -> NPC, 몬스터 배치, 퀘스트 제작

                

세계관, 엔진 제작

                

                   원화디자인 -> 캐릭터 제작 -> 애니메이션 제작 -> 캐릭터관련 기획데이터 제작

 

이 두 가지 흐름이 전체 일정에 가장 큰 영향을 미친다고 했을 때 결국 전체 일정은 이 두 흐름 중 더 시간이 많이 걸리는 쪽에 의해서 좌우됩니다. 위쪽이 12개월 아래쪽이 9개월이 걸린다고 했을 때 배경(레벨)제작이 4, 그 중에서 텍스처 제작 및 다듬기가 2개월이 걸렸다고 해보죠.


배경 디자이너가 디자이너로서의 긍지를 조금만 양보하고 기획데이터를 제작 가능한 배경 데이터를 2개월만에 넘겨주고 나서 텍스처 제작 및 다듬기를 했다면 전체 일정이 2개월 줄어들수 있었겠죠.

 

크리티컬 체인


DBA E
씨는 최근 일주일 동안 집에 한번도 못 들어 갔습니다. 3년동안 개발했던 게임이 일주일 전에 오픈베타를 시작했거든요. 처음 예상보다 레코드는 훨씬 빠른 속도로 쌓여갔고 쿼리에 대한 응답속도가 앞으로 얼마나 느려지게 될지 걱정스러운 E씨에게 매일같이 찾아오는 서버 프로그래머들은 스트레스 자체입니다. 그런데 서버 프로그래머들에게도 사정은 있는 것이 DB에 테이블과 쿼리를 추가하지 않으면 신규 기능을 전혀 개발할 수 없거든요. 게임 게시판에는 이것도 안된다 저것도 안된다 유저들의 성화가 빗발치고 있는데 말이죠. 아무튼 서버 프로그래머들의 요청, DB로그를 원하는 운영팀 사람들, 오픈 초기에 왕왕 발생하는 각종 사건사고 해결을 혼자 담당하는 DBA E씨를 도와주는 사람을 최우선적으로 채용해야 전체 프로세스에 조금이라도 숨통이 트이겠죠. 채용이 쉽사리 안 된다면 서버프로그래들이 직접 테이블과 쿼리를 만드는 수고 정도는 해도 될 것 같은데 말이죠.