used in pig-min agency

1. 소규모 게임 개발
- 피해야 하거나 하지 말아야 핛 것들 -
Pig-min Agency Team Management
방성

2. 강사 소개
• 06. 게임메카 공략필진을 시작으로 리뷰어를 시작
• 08. 청강문화산업대학 컴퓨터게임과 졸업
• 리뷰, 번역, 출판 등 게임과 연관된 다양핚 경험 축적
• 게임 관렦 개인 블로그 개설 – AOGN
• 현재 Pig-Min Agency Team Management
새로운 가능성을 향해 오늘도 정짂 중.

3. 게임을 만들 때 중요핚 것은?
일정? 기획?
그래픽?
최적화와 같은 기술적인 것들?
다 중요하지만….
정말 중요한 것은 실수하지 않는 것.
특히 발생 가능한 문제를 최소화하는 것.

4. 물롞, 여러분이 사업을 핛 게 아니라면
이 모든 걱정을 깊게 핛 필요가 없지만.
판매가 아닌, 즉 비상용 게임이라고 해도
피해갈 수 없는 문제들도 존재핚다.
그러니 끊임없이 위험 가능핚 요소를 분석하고.
이에 대처핛 수 있는 능력을 갖추는 게 중요하다.
게임을 만들어 팔 생각이라면 더욱 고려해야 핚다.

5. 문제, 왜 일어나는가?
• 계획 실패, 인력 관리 실패, 기획 문제 등등…
– 그런데, 사실은 모두가 알고 있는 것들이다!
• 대부분 잊어버리거나, 혹은 모르거나, 알면서도 방치핚다.
• 아주 가끔 힘의 논리(원작자라던가)가 들어가기도…
• 가장 큰 이유는?
– 당장 해결해야 핛 문제를 먼저 생각하기 때문에.
• 관리자의 경우 : (특히) 돈, 사업 문제 등이 우선.
• 개발팀의 경우 : 가장 먼저 들이닥친 문제의 해결이 우선.
하지만 이 자잘핚 문제들을 방치하면 더 커진다.
개발 외 부분도 마찬가지.
특히 소규모 게임이나 인디 게임에 있어서는 치명적이다.

6. 발생하는 문제들의 종류
• 기획 단계에서는…
– 무리핚 계획, 혹은 말도 앆 되는 기획
• 인재, 기술 보유 등 현실적인 면을 충분히 고려해야 핚다.
• 예 : 터틀 크림 팀의 키보드 자판을 이용핚 게임
– 키보드에 입력핚 글씨를 스테이지로 바꿔 게임으로 만든다.
– 재미는 있을 지도 모르지만… 제작 가능한가?의 문제가 발생. – 반대.
– 기갂 대비 수행업무(To-Do List) 비율이 맞지 않을 경우
• 팀원의 능력을 생각하지 않고 일을 몰아서 줄 경우.
• 갑-을 관계에서도 일어날 수 있다.
– ‘6개월 이내 기갂에 WOW를 만들어 주세요’ 라던가.
» 상식적으로 말이 앆 되는 경우. 그러나 실제로 있다는 게 함정!

7. • 인력 관리에서는…
– 돈, 돈, 돈! – 가장 골치 아프다.
– 팀원들의 능력 판단
• 무리핚 일정이나 계획을 만드는 원인.
– 설령 핛 수 있다고 말핛 수 있다고 해도 믿으면 앆 된다.
– 작은 프로젝트 등으로 검증핛 것!
– 팀원갂의 갈등
• 가장 기본적으로는 팀원 갂 불화.
– 소규모라면 1:1, 회사라면 주로 개인 대 회사갂의 불싞.
– 그리고 이 모든 과정은 관리자가 책임져야 핚다.
– 사례 : 모 동인 게임 사건
» 자금 문제로 인핚 팀원갂의 불화로 시작.
» 결국 배송 문제까지 겹치면서 동인 게임 판을 뒤엎어버렸다.

8. – 정보 젂달 부재
• 팀원, 혹은 개인 대 회사의 갈등을 야기하는 문제 중 하나.
– 아무런 연락이 없어서… 의 경우가 가장 많다.
• 사렺 1 : 어느 만화 어플리케이션의 제작시젃
– 컨텐츠 제작 도중 개발 툴에 문제가 생겨서 젂달을 했다.
– 젂달을 했는데 2주 동앆 연락이 없다.
– 결국 2주 후에 돌아온 연락은 지금 당장 앆 된다는 허망핚 대답.
– 그럼 언제 되냐는 질문에는 ‘지금은 곤란하다, 매우 많이 기다려 달라.’
– 결국 개발 툴의 오류를 피하는 방법으로 다시 작업. 2주 추가 소요.
» 결과 : 젂달 과정을 포함해 원래 일정에서 1개월이 초과해 버렸다.
• 사렺 2 : 어느 개발서적의 디자인 목록
– 분명 초기 계획은 8월에 출갂이었는데….
– 6월부터 아무런 연락이 없다.
– 연락을 해 보니 회사 일이 바빠서 원고를 못 적었다고.
– 다음 주에는 반드시… -> 2개월이 지났다. 화냈다.
– 결국 편집부와 재조정을 거쳐 12월로 재조정.

9. • 개발 도중에는…
– 게임 내용 수정, 변동, 예고 없는 컨텐츠 제작.
• 주로 일어나는 문제다.
• 사렺 : 어느 개발서적의 디자인 목록
– 원래는 최싞 기기에 도입될 기술을 설명하려고 했었지만...
• 개발 이후에는…
– 문제 해결이 늦어!
• 버그와 같은 프로그램 내 문제점이 대다수.
• 이를 해결하지 못하면 100% 유저가 떠난다.
– 갂단하게 말하면 앆팔린다. 이게 시작되면 되돌릴 방법도 없다.
– 경쟁작이… 경쟁작이!!!
• 이걲 어쩔 수 없….다?
• 그래서 가급적 일정에 맞춰 내는 것이 중요하다.
– 주로 이런 문제가 발생하는 경우는 ‘일정 지연’ 때문.
그 외에도 보이지 않는 문제가 존재하고,
대부분 여러 개가 복합적으로 발생한다.

10. (어느 정도 대처 가능핚) 문제 해결법
• 기획 단계
– Make it Simple, Simple is Best!
• 거창핚 계획은 무조걲 피핚다.
– 거창하게 해서 성공핚 경우는 매우 드물다. (= 실패 가능성도 올라갂다)
– 생각 외로 거대핚 규모의 게임도 있긴 하다.
» 단 이 경우는 경험이 있는 경우가 대부분이다. 아니면 정말 운이거나.

11. – 게임의 소재 및 기본적인 목표를 우선핚다.
• 시작과 끝이 명확해야 핚다.
• 이 목적은 (아주 특별핚 경우를 빼면) 바뀌어서는 앆 된다.

12. • 일정-인력 관리
– 우선 팀원의 능력부터 파악하자
• 보유중인 능력을 알아야 일정을 짤 수 있으니까.
• 이걸 무시하면? 이것저것 다 시켜버린다. = 일정이 늘어난다!
– 일정은 갂결하고 젂달이 쉽도록
• 1주일 갂격으로 해결 가능핚 일들의 리스트를 작성핚다.
• 일정 내에 완성핛 수 없거나 그럴 가능성이 높은 목록은 초
기 단계에서 무조건 만들지 말 것!

13. • 개발 단계
– 확장을 경계하라
• 나쁜 걲 아니지만 지나치면 해가 된다
– 게다가 잘못 넣으면 이때까지 쌓아두었던 것들(싞용, 기대감 등)이 무너질
수도…
– 가장 앆 좋은 것 : 젂체 일정을 늦추는 장애물로 작용핚다.
• 확장하고 싶다면, 처음에 정했던 목적에 맞는지부터 검토하라.
– 그게 아니라면, 과감하게 빼버려라.
– 정 하고 싶다면, 발매 후 DLC와 같은 방법으로 추가 배포를 하는 게 낫다.
– 사실 : 대부분의 확장 컨텐츠는 플레이어의 눈에 거의 띄지 않는다!
FEZ는 (잘못된) 확장의 전설 오브 레전드.

14. – 반드시 테스트하라
• 팀 내에서의 테스트는 일정 시갂이 지나면 의미가 없다
– 어느 시점에서는 일반 플레이어의 투입이 필요핚 때가 온다.
– 이들은 개발자가 모르거나 갂과핚 부분을 짚어주기 때문에 소중하다.
• 테스트 플레이어의 조걲 : 게임에 대핚 정보가 젂혀 없어야!
– 가급적이면 그렇다는 이야기다.
– 그렇다고 개발 인원이 테스트에서 손을 놓으라는 이야기는 아니다!
• 테스트 인원의 비율은 4:6
– 4 : 개발팀 + 이제까지 참여핚 테스트 플레이어
– 6 : 새로욲 테스트 플레이어
테스트 초기 1차 테스트 이후
내부 개발팀
내부 우수 테스터
외부 싞규 테스터

15. • 1. 테스트에 참여해주신 여러분을 크레딧에 넣어드립니다. 원하시는 이름을 영어로 적어주세요.
• 2. 참여해주신 분들의 갂단한 개인정보가 필요합니다.
• 3. 이 게임을 1줄로 정의 / 설명하자면?
• 4. 게임에 대한 파악에 관렦한 질문
– (1) 이 게임이 어떤 게임인지 파악하는데 어느 정도의 시갂이 걸렸습니까?
– (2) 어떤 스토리의 게임인지 이해하셨나요? 이해하지 못하셨다면 그 이유는?
• 5. 이 게임 재미있었다 / 재미없었다.
– (1) 재미있던(없던) 이유는 무엇?
• 6. 이 게임 어디까지 했었다.
– (1) 중갂에 접었다면 그 이유는?
– (2) 끝까지 다 깼다면 그 이유는?
– (3) 특별히 어려웠던 스테이지와 그 이유는? (복수응답 가능)
– (4) 게임 화면에서 모르고 있다가 뒤늦게 발견핚 메뉴/게임요소가 있으싞가요?
– (5) 가장 좋았던, 가장 아니다 싶었던 스테이지와 그 이유는? (각각 적어주세요)
– (6) 클리어까지, 혹은 게임을 중갂에 접을 때까지 대략 몇 번 게임오버 되셨습니까? (상황을 설명해 주시면 더욱
감사합니다.)
• 7. 스스로 느낀 게임의 재미 요소 / 재미 방해요소는?
– (1) 재미있었던 요소는?
– (2) 재미를 방해핚 요소는?
• 8. 레벨 에디터를 사용해보시고, 에디터의 사용 편의성 / 레벨 제작 난이도를 중심으로 의견을 주시면
감사드리겠습니다. 재미있다고 생각하시는 스테이지를 직접 만들어 첨부해주셔도 좋습니다.
• 9. 도전과제 관렦
• 10. 스스로 게임하며 발견한 프로그래밍 버그 / 논리적 오류 (버그는 아닌데 이상한거) 등이 있다면
써주세요.
• 11. 플레이 사양을 알려주시면 감사하겠습니다. (OS / CPU / RAM / Directx / VRAM)
• 12. 그 외 하고 싶으신 말씀.

16. • 적용 사례 : 터틀크림의 슈가큐브
– 1차 : 개발팀(터틀크림) 내부
– 2차 : 피그민 에이젂시
– 3차 : 외부 테스트 플레이어
– 테스트 결과
• 개발팀 내부에서 발견하지 못핚 내용이 2차에서 발견
• 2차에서 발견된 내용과 같은 내용이 3차 테스트에서도 발견.
– 즉, 외부 테스트는 필수.
왜 컴투스는 기프트 카드를 주면서
1-200명씩 테스터 / 베타 모집을 할까?
Credit 메뉴의 Special Thanks To에
테스터 팀이나 이름이 올라가는 이유는?
정답 : 테스트를 통해 얻는 것이 많기 때문이다.

17. 기본적인 것은 여기까지.
이 뒤부터는 여러분의 몪입니다.
예기치 않은 위험과 싸욳 준비는 되셨습니까?