1.
Mark of the Ninja
Postmortem
Jamie Cheng & Nels Anderson
from GDM Feb 2013 issue
번역: 박민수

2.
Mark of the Ninja
• 장르 2D 플랫포머 스텔스 액션 어드벤처
• 개발 Klei Entertainment
• 퍼블리셔 Microsoft Studio
• 개발 인원 초반 7명, 후반 16명
• 개발 기간 16개월
• 출시일 2012년 9월 7일(XBLA), 2012년 10월 16일(스팀)
• 개발 툴 Microsoft Visual Studio, Flash, Fmod, 자체 개발 툴
• 대사 약 8000줄
• 가격 스팀에서 $14.99

3.
What Went RIGHT

4.
1. Building on solid tech
• 이전에 스텔스 2D게임 장르가 나온 적이 없었다.
• 스텔스 게임 플레이가 2D에서 어떻게 동작할지 몰랐음.
• 기존 Shank2 파이프 라인으로 아이디어를 빠르게 프로토타이핑
• 이전 프로젝트에서는 레벨을 디자인하고, 아트를 그리고,
다시는 레벨을 변경하지 않기를 기도함
• 레벨이 변경되면 아트의 상당 부분을 다시 그려야 했기 때문
• 그래서 다른 구성원들에게 큰 영향을 주지 않으며,
레벨 디자인을 빠르게 iterate 할 수 있는 툴셋을 디자인.
• 좋은 툴을 만드는 것은 생산성을 배로 향상시켜줌

5.
2. Playtesting early and often
• 일주일에 두 번, 매번 새로운 테스터를 구해 플레이 테스트
• “게임을 매일 플레이 하지 않는 플레이어의 관점에서 보기 위해
새로운 플레이어가 우리 게임을 더듬거리며 플레이 하는 것을
관찰할 필요가 있었다.”
• 플레이어들의 요구를 구현하는 것이 아닌,
디자인이 발생시키는 근본적인 동기에 도달하도록
• ex) 플레이어들이 전투가 만족스럽지 못하다고 불평하면,
전투를 하려는 이유를 물음

6.
3. Great relationship with Microsoft
• 일주일에 한 번, 주요 리스크를 결정하기 위해서
Microsoft Studio 프로듀서에게 필요한 정보를 주고,
그것에 대해서 Skype로 토의함
• 전통적인 관계에서 성숙된 문제 해결 관계로 발전
• 자체 퍼블리싱하는 인디들이 스스로 해결해야 하는 모든 것에 대해
Microsoft는 굉장히 도움이 됨
• 심의부터 TCR 문제까지

7.
3. Great relationship with Microsoft
• 가장 어려운 부분은 “실제로 만들 수 있는가”에 대해 의문을 가질 때
• 약 6개월 동안, Klei와 Microsoft 양쪽 모두
“정말로 완성할 수 있을까?” 하는 의문을 가지고 있었음
• 고비를 넘긴 뒤, 그 의문에 대한 대답은 Yes였다.
• 좋은 관계는 일반적으로 리소스 소모적인 것들을
결과적으로 positive하게 바꾸며, 이는 양쪽의 신뢰에 달려있음.

8.
4. Polish and iteration time
• Shank는 일정에 맞추느라 중요한 폴리싱을 할 시간을 놓침.
• 전철을 밟지 않는 대신 추가 일정에 대해 비용을 지불하기로 함.
• 그래서 4월 중순에 완성할 계획이었지만 3~4개월 정도 오버
• 시네마틱 수정, 레벨 조율, 컨트롤 조절, 비슷한 아이템 병합 등…
• 게임을 완성시킬 뿐만 아니라 처음부터 끝까지 완전히 테스트했다.
• 전체적인 폴리싱 단계는 꼭 필요하다.
• 스스로에게 귀 기울인 것과
iterating을 위해 끝까지 시간을 쓴 것에 대해 기쁘게 생각

9.
5. Focus on core stealth principle
• 스텔스 게임의 네 가지 핵심 요소: 관찰, 계획, 실행, 반응
• 단순히 공식을 카피하는 것에서 떠나 이 핵심들을 목표로 함.
• 다른 캐릭터 중심 액션 어드벤처 게임과 어떻게 비교될 것인가?
• 스텔스 게임을 흥미롭게 만드는 정수를 도출:
플레이어 중심 시스템과 의도적 게임 플레이
• 스텔스 장르의 관습을 위배하는 결정이라도
우리의 목표에 가까워지는 디자인을 선택
• Ex) 은신 매커니즘
• Theif의 Light gem 등은 여러 값을 가지는 아날로그지만
Mark of the Ninja에서는 밝거나/어둡거나 단 두 가지 뿐인 binary

10.
What Went WRONG

11.
1. Initial lack of focus
• 개발 초기에, 다단계의 정교한 인과 연쇄적인
초특급 아이디어(?)를 가지고 있었고, 대부분 구현
• 하지만 재미가 없었다.
• 약 네 달간, 게임의 핵심 경험이 무엇인지에 대한
분명한 아이디어가 없었기 때문
• 그래서 핵심 경험을 찾기 위해서 그 다음 2개월을 소모.
• 그렇게 짧은 몇 개월 동안 과감하게 게임의 방향을 바꾸다 보니
수많은 아트와 애니메이션을 버리게 됨.
• 결국 게임의 본질은 찾았지만 많은 후유증을 남김.

12.
2. Story came late in the development cycle
• 가벼운 스토리 텔링에서 시네마틱이 들어간 완전한 스토리로 변경
• 하지만 스토리 애니메이션 리소스 제작 계획이 잡혀있지 않았음.
• 스크립트도 없었고, 있어도 게임 플레이에 따라 변경될 수 있었음.
• 급하게 하청업체를 써서 스크립트, 스토리보드, 씬을 구성
• 대부분의 스토리에는 만족했지만 바꾸고 싶었던 것도 있었음
하지만 스케줄을 낼 수 없었음

13.
3. Nailing down certain mechanics late
• 게임의 핵심 컨셉을 개발 뒤늦게 파악했지만,
진보된 매커니즘은 훨씬 더 늦게 나옴.
• 게임 후반의 매커니즘이 어떤 느낌일지 적어두긴 했지만,
그게 동작할지 알 수 없었고, 실제로 대부분 쓸모 없었음.
• Ex) 에어 대시와 시간 정지
• 상당한 프로그래밍, 아트, 디자인, 테스팅이 필요했지만,
테스트 하고 나니 별로 재미가 없었음.
• 게임에 들어간 순간이동 기술은 심의 받기 두 세 달 전에 구현
• 많은 투자를 한 내용물을 개발 막바지에 뜯어내는 것은 어려운 일
• 하지만 게임의 퀄리티를 최우선으로 고려해야 함

14.
4. Design crunch
• 위에서 언급한 이슈들 때문에
디자인 팀은 몇몇 큰 활동들을 프로젝트 후반으로 미룸.
• 큰 규모의 레벨 작업에 의한 속도 저하.
• 정밀한 폴리싱을 위해 수많은 시행착오를 거침.
• 모든 부서가 개발 단계로 넘어가며 영향을 받았지만,
가장 많은 타격을 받은 곳은 디자인 팀.
• 특히 개발 마지막 6개월이 힘들었음.

15.
5. Story played too straight
• 원래 전통적인 스토리 구조를 가질 계획이었지만,
더 야심있고, 독창적인 내러티브를 원함.
• 다만 처음부터 복잡하고 낯선 내러티브로 플레이어를 압도하고 싶지는 않았음.
• 그래서 초반에는 굉장히 단조로운 스토리를 플레이하고,
게임의 절반 정도에서부터 복잡함과 미묘함이 나오도록 함.
• 그런데 일부 사람들이 초반만 보고 그것이 전부라고 판단해버림.
• 다만, 몇몇 사람들이 게임의 내러티브에 경희를 느꼈다는 말을 들어서,
완전한 실패라고 생각하지 않음.

16.
결론

17.
결론
• 생산성을 위해 좋은 툴을 가지고 있는 것이 좋다.
• 프로토타이핑, 테스트, iteration 똥인지 된장인지 먹어봐야 안다
• 피드백대로 고치는 것 보다는, 근본적인 문제를 찾자.
• 퍼블리셔와 친하게 지내자. 그리고 잘 써먹자
• 아이디어만 내거나 다른 게임을 따라 하려는 것 보다
만들고 있는 게임의 핵심을 파악하자.
• 폴리싱하는 시간을 아끼지 말자. Shankㅠㅠ
• 아까워도 퀄이 우선이니 재미를 해치는 요소는 과감히 일찍 버리자.
• 큰, 오래 걸리는 일들을 뒤로 미루지 말자. 뭐든 일찍일찍 하는 게

18.
Thank you