특별한주제/게임

게임개발을 위한 게임제작프로세스 세미나

Namu(南無) 2007. 11. 2. 02:21
2007년 11월 1일 오후 3시부터 강남에 위치한 삼정 호텔에서 Head of research Electronic Arts이자 현재 카네기멜론 대학 ETC 교수인 John Buchanan의 게임개발을 위한 게임제작프로세스 세미나가 있어 참석하고 왔습니다. 1부는 배포된 자료 중 일부로 흔히들 알고 있는 게임 개발의 방법론 - 컨셉 디자인 프리프로덕션, 알파, 베타, 선적 - 을 이야기한 것이라 좀 무미건조 했습니다. 게다가 마이크 상태도 안좋고 통역 분들도 좀 헤메시는 거 같았어요. 그래서인지 1부가 끝나고들 많이 갔습니다. 특히 저랑 함께 온 팀원 분중 몇분은 1부 끝나자 사무실로 돌아가시더군요. 그러나 2부는 꽤 재미있었습니다. 1부가 끝나자, 준비된 자료의 나머지 부분은 학생들에게 주로 이야기하는 것으로 현역에 계신 분들에겐 별 의미가 없을 거 같다며, 자료를 준비할테니 잠시 기다려 달라고 하더군요. 그 다음에 준비한 것이 Proto-typing에서 Game Sketch라는 방법론을 도입하는 이야기를 하더군요. 그럭저럭 재미있게 볼 수 있었습니다.

질문과 답변 시간의 마지막에 영어 할 줄 안다고 영어로 질문하셨던 분! 부럽사옵니다!!!

이렇게 간단하게 쓰자면 재미없으니까, 세미나 시간 동안 OneNote 2007로 메모해뒀던 거 기록 차원에서 남겨봅니다. 다만 단순히 메모고 고치질 않아서 장난스럽게 써놓은 부분도 있습니다. 그런데 그렇게 장난스러운 부분은 세미나에서도 그랬던 것도 있고, 제가 메모 남기다가 그냥 장난 친 것도 있고 그래요. 3시간 동안 무릎 위에 노트북 놓고 세미나 들어보세요. 지나면 지날 수록 장난치고 싶어지죠!

  • 강연자
    John Buchanan
    Director etc-oz
    Adelaide, sa
    'stralia
    juancho@cmu.edu
  • Build a major game which is going to make millions of dollars
    • QA
      QA와 개발자가 개인적으로 대화하지 않도록 하고 매니저를 통하도록 하자
      이것은 서로 기분이 나쁘지 않도록 하기 위한 것이다.
      퍼블리셔가 요구하는 사항도 확인해야 한다. 로고의 표시 방법, 시간 등이라던가 PS2에서 게임을 저장할 때 특정한 방법을 꼭 통하도록 한다던가 가 그 예이다.
    • 알파
      알파는 더 이상 새로운 feature를 추가하지 않는 것을 의미한다. 하지만 모두 완성되지 않았을 수도 있다.
      Feature ALPHA: 각기 모듈 별로 알파 단계를 알파 단계를 따로 두는 것이다.
      Lock down on feature introduction
    • 베타
      Lock down on development
  • How do you structure your team
    • Team Structure
      ISO14000은 다른 업계에서나 가능한 이야기이다.
    • 관리 방법 1: 기술 중심 (technology oriented)
      1980년 처음에는 아트적인 요구사항이 적었다.
      프로그래머+아트로 시작해서 점점 세분화되었다.
      이런 두 개의 커뮤니티를 위해서 계층 구조가 만들어졌다.
      • Lead Engineer + Lead Artist의 관계
    • 관리 방법 2: 기능 중심 (feature oriented)
      기존 방법이 각 그룹 간의 대화가 줄어든다는 단점.
      각 단계별로 각 기능을 하나 하나 완성해 나가는 성취감을 얻을 수 있다.
      관리의 목적은 창의적인 사람에게 권한을 줘서 재미있는 게임을 만들 수 있도록 하는 거다.
      개발 이외의 쓸데없는 부담을 줄이고 그런 것들은 매니저가 대신 해주는 거다. (That's it!)
    • 앞으로는…
      프리프로덕션 기간이 훨씬 길어가고 더 재미있는 게임을 만드는 것을 목표로 할 것이다.
    • 개발자들은…
      독립성이 높은 커뮤니티이다.
      관리자나 경영자가 강요를 하는 것은 좋지 않다. 또한 잘 굴러가는 팀의 운영 방법을 다른 팀에 바로 적용할 수 없다.
      어떤 방법으로 어떤 기술을 쓸 것인가 하는 것은 팀이 직접 선택할 수 있도록 해야 한다.
    • 결론은…
      각 팀은 모두 독특하다.
      각 게임은 모두 독특하다.
      정답은 없다. 개발하면서 발견되는 위험 요소를 계속 줄여나가는 것이 아닐까.
    • 엔진을 살까요, 직접 개발할까요?
      내가 보기엔 우선 사고 필요한 것만 쓰고 없는 건 직접 만드는 게 가장 좋은 거 아닐까.
  • 기타
    • 내가 가장 좋아하는 사례
      이 사례는 영화보다 게임에 애니메이션을 적용하는 게 얼마나 어려운 질 이야기하는 사례이다.
      영화의 경우에는 감독 마음대로 컨트롤할 수 있지만 게임은 유저가 컨트롤하기 때문에 그게 재미있는 점이면서도 위험한 점이다.
  • First Proto-typing
    • Game sketching
      개발을 하면서 시행 착오 때문에 비용을 까먹는 일을 줄이기 위해서 1주일 안에 아이디어를 가시화할 수 있는 방법
      EA에서 2006년에 16개의 프로젝트를 진행했는데, 실제로 모두 취소 되었다.
      어떤 게임을 만들 것인가? 를 위해서 들어가는 대화 비용이 크다.
      플레이를 하기 위해서 오랜 시간을 개발해야 하고 그 동안 게임의 내용을 제대로 이해하지 못 하고 개발하고 있지 않은가? 그래서 기대치가 일치하지 못 하여 비용을 많이 소모하는 경우가 있다.
    • Example
      해리포터의 연습 레벨에서 마법봉으로 용을 잡고 다른 캐릭터와 협력을 배운다.
      게임 플레이의 요소는 마법을 걸어 용을 죽이고 협력을 하고 문을 열어 나가는 것으로 무척 단순하다.
    • 학생들에게 2주 안에 만들 수 있는가?
      그렇다고 했다. 그런데 화요일에 불러서 금요일까지 완성하라고 했다. 이제 학생들은 3일이 남았다.
      간단한 엔진 (여기서는 아마도 퀘이크 3) 에서 각기 캐릭터를 사람이 직접 플레이해서 일종의 연극처럼 게임 플레이를 진행한다.
      거짓말을 했는데 마법을 캐스팅하는 모습을 보이기 위해 7줄 정도의 스크립트를 작성했다.
      완성 후 이것을 학생들에게 플레이하도록 하고 다른 학생들에게는 바로 해리포터를 하도록 했는데 이것을 플레이한 사람들이 훨씬 쉽게 할 수 있었다. 왜냐면 게임의 모든 재미가 있으니까.
      만드는데 1일, 리허설에 3일 걸렸소!
    • Sketch
      A Sketch is not a prototype.
      이슈를 만들기 위한 소재에요.
      최소한의 아트를 이용해서 가능한 보는 사람들이 많은 상상을 하도록 하자.
    • 결론
      People love changing their characters.
      People doesn't love protect their charades
      Mistakes lead to neat feature.
      Its all about the team not technology.
  • Questions and answers
    • 엔트리브 ○○○
      Q: 기능 중심으로 개발할 때 서로 조화가 되지 않을 때 어떻게 하면 좋은가?
      A: Technical. Arts, game design documents(지침서?)가 필요하다. 기능 중심의 팀 구성에서 중요한 건 서브 팀에서 대화하고 서브 팀끼리 경쟁하지 않도록 해야 한다.
      Q: 각 서브 팀끼리 일정이 어긋날 경우에는 어떡하나연?
      A: 우와 어려운 질문이오. 이 접근 방식의 단점을 잘 지적했소. 모든 게임 개발에 이 방식을 적용할 수 있진 않을 것이다. 기능을 잘 분배해서 서브 팀에게 잘 분배하는 게 좋다.
    • 엔트리브 ○○○
      Q: 이거 자체가 애자일 개발론과 유사성이 모이는데. 이런 걸 퍼블리셔가 이해 못 하는 경우가 있을 때 이걸 어쩌죠?
      A: 원래 그런 거죠. 3개월 전에 2개 회사와 이야기했소. 하나는 퍼블리셔 하나는 개발사. 스크럼 방식은 개발사 입장에선 재미있죠. 하지만 마일스톤도 없고 이건 진행하면서 만들어지는 거죠.
      뭐 여튼 어려운 거 맞는데 니마는 잘된 사례가 있나연.
    • 이름을 밝히지 않은 한 분
      Q: 게임 디자이너는 스케치에서 던젼 마스터가 되야 하냐? 만약 그렇지 않다면 왜 그런지 궁금하다.
      A: 게임 디자이너는 두 가지 방향이 있다. 하나는 추상적인 걸 쉽게 표현하는 거지요. 그리고 실제로도 게임 디자이너가 던젼 마스터가 되는 게 일반적이죠. 다른 회사랑 컨설턴팅할 때도 그렇게 했고. 말한대로 게임 디자이너가 하는 게 가장 좋다.
    • 엔씨소프트 ○○○
      Q: 각 단계별 진행하는 체크하는 특별한 방법 in EA.
      A: 아까 질문으로 돌아가는거 같근영. 아까 그 지침서에 잘 써있어야 하오. 처음부터 그게 제대로 안되어있으면 각 단계에서 목적을 달성했는지 알 수 없다.
    • 이름을 밝히지 않은 다른 분
      Q: 개발 도중에서도 실수를 통해 프로덕션 단계에서 새로운 재미가 나올 수 있는데 이걸 어떻게 하는 게 좋은가연?
      A: 아까 질문은 기능 중심 개발의 단점을 이야기한 거 같고 이 질문은 반대로 기능 중심 개발의 장점을 잘 살려준 거 같소. 그런데 EA에는 이런 저주가 있어요. E3의 저주. 디렉터가 E3를 가더니 '모두 바꿉시다'라고 하더라구. 그래서 기능 중심으로 그게 취소되면 버리면 되는 거죠.
  • 마지막
    e-mail 주소가 자료에 있으니 원하면 발표 자료를 줄게요. 질문도 환영해요.
그리고 이 위의 맑은 고딕으로 쓰여진 부분은 모두 OneNote 2007로 쓴 다음 블로그로 게시하는 기능을 이용한 것입니다. 이글루스도 블로그 API를 제공하고 있으니까 이런 기능을 이용할 수 있는 거죠. 다음에는 이거 어떻게 하는 건지 간단하게 써봐야겠군요.

덧글로 아르젤님이 맑은 고딕은 보기 불편하다 하여서 기본 폰트로 바꿨습니다.
저작자표시 비영리 변경금지