2 minute read

nil

Make your tools “bullet-proof”

bullet-proof는 총알을 막는 방탄을 의미한다. 죽지 않고 잘 돌아가는 프로그램을 가리킨다. 이거 당연한 거 아냐? 다만, 여기서 추가로 생각해야 할 게 만약 디자이너가 무사히 익스포트했다면 게임 엔진에서도 알 수 없는 이유로 죽지 않고 잘 돌아가야 한다는 거다. 아티스트가 몇 시간 시도하다가 포기하면서 프로그래머에게 던져주면 디버깅 끝에 “influences가 버텍스당 4개 이하여야 합니다.”라는 대답이 돌아온다면? 쏟아부은 시간을 생각하면 피눈물이 날 것이다. 당연히 죽지 않고 익스포터에서 경고를 해야 한다.

Make the tool, not the artist, do the non-artistic work.

니도 할 수 있는 쿼드를 트라이앵글로 잘라내는 일 따위를 아티스트에게 시키지 마라는 것이다. 이런 건 당연히 툴에서 지원해줘야 한다.

Make it possible for your tools to work as part of a one-step build process.

익스포트는 빌드 머신이 해주자는 거. 분명히 아티스트에게 편리하겠지만, 작업자가 게임 클라이언트에서 잘 보이는 걸 확인하는 단계를 건너뛸 수 있기 때문에 조금 부정적이다. 하지만, 익스포터가 정말 잘못된 모델링 데이터를 잘 걸러준다면 한번 시도해볼만 하다고 생각한다. 분명 된다면 많이 편할 것 같은데, 이런 경험담을 들어본 적이 없어서 정확히 판단하기가 어렵다.

Make your tools show errors that can be noticed, understood and useful.

맞다. 아티스트가 프로그래머에게 말을 걸 필요가 없게 만드는 게 가장 최선이다. 술 한잔, 밥 한끼하자고 말 거는 것은 오케이.

Never let your tools fail.

텍스쳐 경로가 잘못되었다면 어떻게 하면 될까? 보통은 에러다. 텍스쳐 경로를 잘못 입력한 모델링 데이터를 받은 이후부터는 클라이언트 실행조차 불가능하다. 과연 이게 옳은 일일까?

에러를 내는 이유는 간단하다. 뭐, 귀찮아서 그냥 에러를 내는 사람도 있겠지만 보통 에러를 안 내면 잘못된 데이터를 바로 수정하지 않아서 에러를 낸다. 어디까지 에러를 내지 않고 어디서부터 에러를 내야 할까? 것 참, 결정하기 어려운 문제다. 릴리즈 버전에서는 무조건 에러를 내는 게 맞지만 개발 버전에서는 텍스쳐나 모델링 데이터 같은 경우는 에러를 내지 않고 널 텍스쳐나 널 모델링 데이터를 화면에 출력해줘도 되지 않을까 싶다.

최상은 빌드 머신에서 이런 걸 다 검증해서 바로 경고해주는 거지.

Don’t force your artists to remove helper objects.

이건 익스포터 대부분이 잘 지키는 것 같다. 있는 모든 데이터를 무조건 통채로 익스포트해서 진짜 필요한 것만 익스포트하려면 필요없는 것을 지워야 한다면, 아아…

익스포트를 할 때, 모든 항목이 체크되어 있는 상태에서 지우는 방식이 아니라 선택이 비어 있는 상태에서 딱 필요한 항목만 체크하는 방식을 권하고 있다.

Don’t force your artists to check export settings more than once.

파일 단위로 설정 캐시를 만들어라. 똑같은 파일을 다시 익스포트할 때, 세팅을 변경할 필요가 있을 때만 살펴보게 하자는 것이다. 실수를 줄이기 위해 이런 건 일일이 디자이너가 선택하도록 놔두는 편인데, 오히려 이런 방식이 실수를 더 줄일 수 있을 것 같다. 구현 아이디어가 필요한 항목.

Don’t force your artists to collapse hierarchies.

아티스트가 작업하기 편한 계층구조(hierarchy)를 유지한 채, 게임에 최적 모델을 익스포트할 수 있도록 해야 한다. 예를 들어 디자이너는 여러 모델을 나눠서 작업하는 게 편한데, 모델을 하나로 통합해서 익스포트하는게 최적 모델이라면 “계층구조에서 이 노드 이하에 있는 모든 자식 모델들을 하나로 통합해서 익스포트” 이런 메뉴를 지원해주는 게 좋다.

Don’t use the hidden or frozen attribute to filter the export.

익스포터는 hidden, frozen 속성에 상관없이 지정된 놈들은 다 익스포트해라. 편집을 편하게 하기 위해 숨겨 놓는 때도 있기 때문이다.

Don’t require manual exporting.

I can’t believe how many teams put up with manually exporting things

명령어 하나만 치면 맥스/마야로 만들어진 모든 3D 애셋(asset)들을 게임 데이터로 로딩할 수 있어야 한다. 아니면 3D 포멧에 변화가 있을 때마다 싸워야 한다. 다~ 수동으로 익스포트를 다시 해야 되기 때문에… ’이렇게 되면 좋겠다.’였는데, 이게 당연한 거였구나.

Conclusion: happy artists make better games!

맞아. 아티스트들이 하얗게 불태울 수 있도록 도와줘야 한다.

아티스트에게만 한정된 게 아니고 기획자를 위한 툴을 만들때도 새겨야 할 것들이 가득하다.

원문은 가마수트라 Effective 3D Exporter Design: How to Make Artists Love You. gitiss에서 번역본(로그인 필요)을 제공한다.

PS : 아아~ 그동안 불편하게 쓰신 아티스트분들 죄송합니다.