내가 만드는 미래!!

인터페이스도 쉽고, 쓰기도 무지 간단..

이녀석으로 민희씨 이래저래 매핑해서 잘 썼는데..

혹시 필요한 사람이 있을지 몰라서 올려보네요 ㅋㅋ

01. 심각한 사람들에게서는 아이디어가 절대로 나오지 않습니다.

유머와 창조력은 절친한 친구 사이입니다.
그러므로 일할 때 재미가 없다면 인생을 낭비하고 있는 것입니다.
우선 마음을 즐겁게 하십시오. 그러면 저절로 아이디어가 떠오릅니다.


02. 무언가 서로 다른 두 가지를 합쳐 보십시오. 재미있는 아이디어가 나옵니다.

화가 달리는 꿈과 예술을 조합하여 초현실주의를 탄생시켰습니다.
허친스라는 사람은 자명종과 시계를 결합하여 자명종 시계를 발명했습니다.
리프먼은 연필과 지우개를 합쳐 지우개 달린 연필을 만들었지요.
어떤 이는 걸레에 막대기를 붙여 대걸레를 만들었습니다.


03. 아이디어를 내는 일은 문제를 해결하는 일입니다.

문제가 무엇인지 잘 알기만 하면 답은 그 속에 있는 것.
과학자들도 어떤 문제의 답이 있다고 생각하고 문제를 풀면 태도가 바뀐다고 합니다.
이미 답 쪽으로 50% 정도 다가가 있다는 것이지요. 내게 아이디어가 있다고 믿으십시오.


04. 마음속에 목표를 정하세요.

다이빙 선수는 물에 뛰어드는 장면을 골프 선수는 공이 홀에 들어가는 장면을 상상하며 경기합니다.
아이디어와 관련된 장면을 상상하십시오.
칭찬 받고, 감사의 말을 듣고, 보상받는다고 상상하십시오. 우리도 그렇게 될 수 있습니다.


05. 어린아이가 되십시오. 그들의 천재성을 배우십시오.

세상에는 규칙이 왜 그리 많을까요? 아이들은 규칙을 모르기 때문에 아예 그것을 깨어버립니다.
아이디어 낼 일이 있으면 이렇게 물어 보십시오.
"내가 여섯 살이라면 이걸 어떻게 풀까?"
우유용기에는 왜 반드시 우유라는 글씨가 가장 크게 쓰여있을까요?
예전에 어떻게 했었는지는 싹 잊어버리십시오.


06. 정보, 정보, 정보! 많이 아는 사람이 아이디어 낼 확률이 높습니다.

아이디어는 "낡은 요소의 새로운 조합"이라 했습니다.

낡은 요소를 얻는 방법은?

(1) 틀에서 벗어나 보세요.
9년 동안 매일 다른 길로 출근했다는 사람이 있습니다.
절대 듣지 않던 라디오 방송을 들어보십시오.
아동 도서를 읽어보십시오.
평소에 같이 가지 않던 사람과 점심식사를 하러 가십시오.

(2) 무언가를 새로운 눈으로 보세요.
그 연습을 위해 "본 것"을 매일 기록하십시오.
오늘 당장 쉬는 시간에 공책을 한 권 사십시오.
공책이 가득 차면 그것을 읽어보세요.
죽을 때까지 공책을 채우십시오(필자도 그렇게 하겠습니다).


07. 배짱을 가지십시오. 큰 소리로 발표하십시오.

아이디어란 너무도 예민해서 누군가 비난을 하면 바로 죽어버립니다.
그 사람은 당신의 아이디어를 두려워하고 있기 때문에 비난하는 것입니다.
또 세상에 나쁜 아이디어는 없다는 사실을 기억하십시오.
우유를 쏟고 나서 울어봐야 소용없지요.
쏟은 우유로 뭘 할지 아이디어를 내십시오. 아니면 더 좋은 용기를 개발하든지.
아울러 아이디어를 너무 많이 냈다고 야단칠 사람은 이 세상에 없습니다. 무조건 많이 내세요.


08. 생각하는 방식을 한 번 바꿔보십시오.

(1) 시각적으로 생각해 보세요.
아인슈타인은 언어로 생각한 적이 한 번도 없었다고 합니다.
개념이 이미지로 먼저 떠오르면 그것을 언어나 공식으로 표현했다는 것입니다.
사진 작가 만 레이는 여인의 토르소를 첼로로 보았습니다.
건축가 프랭크 로이드 라이트는 집이 독립된 구조물이 아니라 풍경을 이루는 필수 요소라고 생각했습니다.

(2) 수평적으로 생각하세요.
때로 너무 논리만 따지다 보면 좋은 아이디어가 나오지 않습니다.
세상일은 반드시 앞뒤가 딱딱 맞는 것은 아니거든요. 논리를 무시해보세요.
재미있는 아이디어가 팍팍 나옵니다.

(3) 있지도 않은 경계선을 긋지 마세요.
지레 짐작해서 함정을 파지 말라는 뜻입니다.
내가 판 함정에 내가 스스로 찾아가서 빠져버리는 실수를 우리는 자주 하게 되지요.
종이로 비행기를 접어 누가 가장 멀리 날리나 시합을 했습니다.
대개 원을 그리며 날다가 얼마 가지 못하고 바닥으로 곤두박질쳤지요.
그런데 어떤 사람은 종이를 골프 공만 하게 똘똘 뭉쳐 던지는 것이었습니다.
동그란 비행기는 없나요? 누가 종이 비행기는 꼭 종이 비행기처럼 보여야 한다고 했나요?

(4) 3번과는 반대되는 이야기지만, 약간의 제한을 두세요. 지나친 자유는 혼돈입니다.
아이디어를 낼 때 어떤 범위를 지정해 두지 않으면 너무 막막해서 무엇을 어떻게 해야 할지 알 수가 없거든요. 누군가가 막연히 그저 맛있는 음식을 만들어 달라면 어떻게 만들어 주어야 하나요?
재즈 음악가 듀크 엘링턴은 곡을 쓸 때 늘 악기의 종류와 연주자의 수를 제한해 놓았습니다.
월터 헌트라는 사람은 늘 돈 때문에 독촉을 받았기 때문에 무언가 정말 필요한 것, 몇 시간 내에 스케치할 정도로 단순한 것을 발명하기로 했지요.
결국 그는 안전 옷 핀을 발명했습니다.
가장 자극적인 제한은 시간입니다.
당신도 마감시간을 정해놓고 일해보세요. 초능력이 생깁니다.
마감 시간이 당신에게 박차를 가하여 뭔가 이루게 만들어 줄 것입니다.


09. 결합하는 방법을 배우십시오.

(1) 비유 방법을 찾아보세요.
만일 속도에 대한 이야기라면 세상에서 가장 빠른 것은 무엇인지, 가장 늦는 것이 무엇인지 생각해보는 것입니다.

(2) 규칙을 깨버리세요.
반 고흐는 꽃이 어떠어떠한 식으로 보여야 한다는 규칙을 깨뜨렸지요.
피카소는 여인의 얼굴은 어떤 식으로 그려야 한다는 규칙을 깼습니다.
또 베토벤은 교향곡이 어떻게 들려야 한다는 규칙을 깼습니다.
딕 포스베리라는 사람은 높이뛰기를 어떻게 해야 한다는 규칙을 깨뜨렸습니다.

(3) "......라면 어떻게 될까?"라고 생각해보세요. 느닷없이 답이 튀어나올지 모릅니다.
당신이 머리 아파하는 그 문제가 지금보다 두 배 심각했다면? 열 배 심각했다면?
아니면 반정도 심각했다면? 이 문제를 완전히 거꾸로 뒤집어보면?
이 문제가 내년까지 존재한다면? 10년 후까지 존재한다면?
만일 갑자기 이 문제가 해결된다면? 당신이 어린아이였다면?

(4) 다른 분야로 눈을 돌려 도움을 받으세요.
제임스 리티는 그의 식당에서 돈 받는 직원이 돈에 함부로 손을 대지 못하도록 현금이 들어오는 것을 기록할 방법을 찾고 있었습니다. 그러다가 증기선 위에서 프로펠러의 회전수를 세고 기록하는 장치를 보게 되었습니다. 바로 그 원리를 적용하여 세계 최초의 금전 등록기를 개발한 것입니다.

(5) 기회를 잡으십시오.
고양이 중 쓸모 있는 고양이는 바로 쥐를 잘 잡는 고양이입니다.
가끔씩 이름조차 들어보지 못한 것을 갖고 놀아보십시오.


10. 끝까지 물고 늘어지십시오. 세상의 어떤 것도 집요함을 당할 수는 없는 법입니다.

(1) 재능도 못 당합니다: 재능이 있는데 성공하지 못한 사람처럼 멍청한 사람은 없습니다.
(2) 재산도 못 당합니다: 태어날 때부터 부유한 사람이 가난하게 죽는 경우는 많습니다.
(3) 천재성도 못 당합니다: 보상받지 못한 천재성이란 말이 있습니다.
(4) 교육도 못 당합니다: 세상은 교육받은 게으름뱅이로 가득 차 있습니다.
(5) 행운도 못 당합니다: 행운의 여신이 부리는 변덕은 왕도 쓰러뜨립니다



"잠자는 아이디어 깨우기(How To Get Ideas)"
(잭 포스터 지음/정 상수 옮김/해냄 출판사 발행)


사장님이 회사 인트라넷에 올리신 글을 멋대로 퍼왔습니다..
이 글을 읽으면서 나름대로 많이 도전이 되더군요..
다른분들에게도 도움이 되었으면 좋겠네요..

[제품 간략 소개]

기본 설정 항목

시스템 최적화
ㆍ 시스템 문제 해결사 : 시스템의 문제를 검색 및 치료기능 제공
ㆍ 레지스트리 최적화 : 불필요한 레지스트리 검색 및 삭제
ㆍ 윈도우 파일 최적화 : 불필요한 파일 검색 및 삭제
ㆍ 시스템 정리 : 시스템 시작시마다 지정한 인터넷 기록과 임시 폴더의 파일의 삭제

인터넷 최적화
ㆍ 인터넷 속도 최적화 : 시스템에 알맞는 설정값을 찾아 설정
ㆍ 인터넷 설정 최적화 : 인터넷 사용에 불필요한 설정 해제
ㆍ 인터넷 사이트 차단 : 지정한 유해사이트 차단
ㆍ 악성 ActiveX 컨트롤 차단

시스템 설정
ㆍ 시스템 설정
ㆍ 인터페이스 설정
ㆍ 윈도우 내부 설정
ㆍ 제어판 설정 : 제어판 사용 제한 설정

시스템 제한 보안
ㆍ 악성코드 제거(울타리)
ㆍ 네트워크 방화벽
ㆍ 프로그램 제한 : 지정한 프로그램의 사용 제한
ㆍ 시스템 감시

시스템 도구
ㆍ 매크로(키보드/마우스 재생기) : 키보드 및 마우스의 움직임을 녹화하여 재생
ㆍ 시스템 도구
ㆍ 온팁(OnTip:온라인 팁) : 인터넷을 통한 여러가지 설정 공유
ㆍ 중복 파일 정리기 : 하드디스크에 존재하는 중복 파일 검색 및 삭제, 백업


※ 실행방법: 다운 받은 후 바로 실행

※ 주의사항: 잘못만지면 PC가 맛탱이 갈 수 있음 -_-;;


 

 

1. 요구 사항 분석서 작성

마케팅 팀에서는 기존의 컴퓨터 게임, 각 장르별 세분화되는 게이머의 심리에 대한 이해, 통계적인 자료, 사회의 유행과 문화가 변화하는 흐름변화에 따른 게이머들의 요구사항을 조사/분석하여 구매력을 갖는 요소를 파악한다.

컴퓨터 게임이라고 불리우는 전자적(Electric) 환각제에는 어떠한 요소가 포함되어 있어야 하는지를 알아내는 일이다.

제품의 개발기간이 비교적 길게 소요되는 관계 또는 지금 순간적으로 구매욕구 요소가 출시 시점에서 어떻게 변할지 모르는 일이기 때문에 단지 ‘요구 분석을 실시했던 당시의 상황’만을 반영한 요구 사항의 설계를 가지고 가는 것은 몹시 위험한 일이다.

릴리즈 시점까지 변화되는 게이머의 성향과 사회 문화적인 성향을 자료 분석을 통해 예상하고 그 변동폭을 그려내야 할 것이다. 포함되어야 할 요구 사항은 미리 예측된 미래의 게이머들의 욕구를 대변하는 것이 되며, 추후에 이를 기반으로 작업에 들어가는 제안서(Treatment)에서 마케팅의 요구사항과 게임 제작 기본원칙, 현실적인 개발 환경 사이의 합의점을 찾아 실제로 구현 가능한 요구 사항을 걸러내게 된다.

게임 제작에 관한 요구사항 분석서(MRD)는 게임 제작용 제안서(treatment)의 기초를 잡는 참고 자료가 될 뿐이며, 세부적인 기획의 하부 단계를 애매모호하게 작성해서는 안된다.


2. 제안서(Treatment) 작성

개발팀의 전원이 작성하였다. 대개 ‘게임 시나리오’라고 불리우는 것을 말한다. 요구사항 분석서(MRD)에서 조사된 게이머들의 요구사항(REQUIREMENT)을 참고하여 작성한다. 게임 플레이에 대한 간략한 묘사를 포함하며 전반적인 프로젝트의 스펙(SPEC)을 결정하는 기초 자료가 된다. 또한 이 문서는 시나리오와 게임플레이, 모든 그래픽 아트에서 동일한 관점이 느껴지도록 모든 작업자에게 기획의도를 공유시키는 것을 목적으로 한다.


3. 제안서(Treatment) 작성

A. 스토리(story)

영화로 비유하자면 시놉시스를 말하는 것으로 판타지, 호러, SF, 웨스턴, 밀리터리 등의 문학적인 장르를 먼저 구분 및 선택하고 기획팀 내의 작가가 관련된 스토리를 서술한다.

스토리의 문학적인 품질과 자극성은 게임으로서 완성도와 초기 소비자에 애한 구매력에 큰 영향을 끼치는 부분이다. 어떠한 컨셉이든 기초적인 배경스토리를 갖고 시작하며 향후 과정(기획서, AS 등)에서 더욱 상세한 백그라운드 스토리(Background Story)의 묘사가 필요하다.

이 부분은 리드 게임디자이너(기획자), 리드 그래픽아티스트, 리드 프로그래머가 전체적인 게임의 방향을 논의하고 동일한 비전을 공유하는데 있어서 중요한 역할을 한다.

B. 게임 방식(게임 플레이 묘사)

기초적이며 대략적인 게임 시스템의 디자인이다. 여기서 팀원들의 Brain storming을 통해 나온 아이디어들과 이를 적당히 조율하는 작업이 필요하다. 다른 개발진과의 기획에 대한 커뮤니케이션을 능률적으로 하기 위하여 명확한 장르(ADV, ARC, RPG, SIM, SPO, PUZ 등)의 구분과 시스템 디자인의 소스가 된 기존 게임 방식의 공개가 필요하다. 간단하게 묘사된 인터페이스와 함께 캐릭터의 성장 및 관리에 대한 정책, 게임 방법(How To Play)의 간략화된 설명이 필요하다. 간략한 묘사 안에서도 재미를 느낄 수 있겠다는 기대감을 유도할 수 있어야 한다.

C. 게임 목적

게임의 최종 목적(Goal)에 대한 묘사로 게임의 전체적인 테마에 대한 설명과 함께 결국 엔딩(Ending)을 갖는 단방향 구조인지 루핑(looping)을 통해 반복되는 게임의 사이클을 갖는지 등의 내용을 간략히 기술한다.

D. 기본 스펙(Basic Spec)

하드웨어 수준 또는 어떤 플랫폼(flatform)에서 실행되는지에 대한 대략적인 게임의 스펙을 고려한다. 이부분은 추후에 본격적으로 기획 작업이 이루어지며 변경될 수 있다.

E. Selling Point Feedback

요구사항 분석서에 기초하여 제안서 내에 반영된 메리트(merit)의 요소들을 정리하는 부분이다. 이 부분을 통해 요구사항 분석서를 제작한 마케팅 팀과 제안서 수정의 과정을 피드백(feedback)을 통하여 원활히 한다. 메리트에 대한 설득력을 가지지 못하는 제안서는 실제 프로젝트로 진행되지 못한다.


4. 기획서(Architecture Desing Document) 작성

제안서가 통과되면 리드 디자인 그룹(Lead Desing Group)이 결성이 되고, 여기에 속한 프로그램과 그래픽, 기획의 실무자들이 합의하여 기획서를 작성한다. 기획팀에서 주 메인이 되어 진행하며, 그래픽팀(Graphics Team), 프로그램팀(Program Team)의 실무자들은 기존 제안서의 세부화한 기획서의 기초가 되는 항목에 대하여 기술적인 측면에서 감수한다. 제안서에서 상세한 기술내용, 피드백에 의해 수정되는 모든 항목에 있어서 각 파트의 실무자가 참석한 회의를 통해 평가되어야 한다. 앞서 언급했듯이 각 파트의 실무자 들은 구체화되는 기획서의 각 항목들에 대해 구현 가능성과 난이도를 가늠하고 기획파트에 기술적인 권고안을 제시하도록 한다. 이 권고안과 제안들은 각 파트의 리더들이 접수하여 리드 디자인 그룹의 회의를 통해 반영된다.

프로그램 설계에 관련된 항목들은 리드 디자인 그룹내 리드 아키텍쳐 그룹(Lead Architecture Gorup)의 협의를 통해 결정되며 리드 아키텍쳐 그룹은 리드 게임 디자이너와 리드 프로그래머가 주축이 된다. 기획 문서는 아래와 같은 내용을 포함하고 있으며, 기획서가 제작되면 대력적인 개발 일정을 예상해 볼 수 있다.

A. 시나리오

제안서에서 기술되었던 스토리(story)가 발전된 형태이다. 단일한 컨셉(Concept)을 선정하고 그에 대한 구체적인 자료 제시가 필요하다. 구체적인 배경스토리와 게임이 진행되는 플롯, NPC의 대사와 나레이션의 내용을 모두 포함한다. 던전을 비롯한 모든 이벤트(event)도 논리적인 구조와 처리방법에 대해 미리 정의되어야 한다. 캐릭터의 대사와 같이 우선순위가 낮은 시나리오의 세부적인 항목들은 프로젝트 후기에 제작되어도 무방하다. 아래 자료구분은 RULE DESIGN에 근거한다.

B. Game Spec 설정(Setting)

- MAP 방식

- WORLD SCALE

- 그래픽의 표현 방식

- 총 SPRITE 객체 종류/수

- 총 NPC 종류/수

- 총 ITEM 종류/수

- PC, NPC, ITEM의 자료구조 정의

- 적용 하드웨어(Hardware)의 수준

C. GAME SYSTEM DESIGN

- 상세 인터페이스의 초기 외형과 구동 방식 설계

(유저 인터페이스부터 이동, 통신, 전투 방식 등. 모든 인터렉티브 요소 포함)

- 구체적인 게임플레이 진행 방식

- 유저 행동패턴에 따른 발생 예측 사항 점검

D. RULE DESIGN

- 이 작업은 보통 GMAE SYSTEM DESIGN 작업에 포함

- RULE MAKING : pc system, combat system, interface system, npc system(ai pattern)

- BALANCING : RULE에 적용될 기초 데이터의 설정

E. LEVEL DESIGN

- NPC ARRANGE : NPC의 적절한 배치, NPC AI에 대한 이해가 필요

- MAP ARRANGE : 전체지도 구성, 세부도시 설계, 던전 디자인, 특정필드 지정

- EVENT ARRANGE : 로그인을 포함한 전체적인 이벤트의 작성과 분포

F. 운영/사후 관리 정책

- 스프라이트 에디터(Sprite Editor), 룰 시뮬레이터(Rule Simulator), 시나리오 에디터 등 개발 진행을 위한 각종 개발 지원 툴 제작의 요구사항 작성

G. 운영/사후 관리 정책

- 게임의 확장성을 고려한 구조 설계


5. 상세 기획서(Detailed Design Document) 작성

A. 그래픽용 상세 기획서

- PC, NPC, ITEM, MAP SPRITE 등 그래픽 작업 전반에 대한 Artwork Concept

- PC 애니메이션 동작 리스트

- VISUAL EFFECT 체크 리스트

- NPC 동작/체크 리스트

- MAP ARRANGE 지침서.(일반 필드, 도시, 던전, 배경 스프라이트 포함)

- 대외 홍보용 2D/3D Image Concept

B. 프로그램용 상세 기획서

- GAME SYSTEM DESIGN 상세 기획서(게임 플레이 다이어그램)

- 게임 내 객체(NPC, ITEM, SPRITE) 코드 리스트

- LEVEL DESIGN 상세 기획서

- 게임 플레이 상황에 따른 연출 리스트 : VISUAL EFFECT, SOUND, BGM 포함

- 시나리오 에디터(Scenario Editor) 제작용 요구사항 분석서

- 튜토리얼(Tutorial) 정책에 대한 기획서

C. 기타 상세 기획서

- SOUND 작업 지시서 : 게임 컨셉의 BGM, 연출에 필요한 효과음 리스트

- 게임 플레이 다이제스트 : 마케팅/홍보팀을 위한 가상적인 게임 플레이 설명, 보안을 위해 중요한 내부의 구조 은닉

- 개발 일정표 : 각 파트(Part)의 상세 작업 일정의 기술 및 Director 작성


6. 개발 기획

A. 작업 공정 관리(Director, Coordinator)

각 파트에서 제시한 스케줄대로 일정이 진행되고 있는지를 수시로 점검한다. 계획한대로 진행되고 있지 않다면 그 원인은 어디인지 무엇인지 분석하고 문제점을 해결하는 작업이 필요하다. Coordinator가 스케줄과 작업 공정을 점검하여 발생 가능한 문제를 미리 진단하고 Director와 함께 문제를 분석하여 Director가 신속히 해결책에 대한 결정을 내릴 수 있다.

B. 중간 결과물 품질 관리(Director, Game Designer)

실제 개발 과정에 있어 중간 결과물들이 기획 의도에 맞는 형태와 품질을 갖추었는지 분기를 나누어 점검하도록 한다. 이 단계를 충실히 수행함으로 ‘먼 길을 돌아가게 만드는’ 치명적인 실책을 미연에 방지할 수 있다.

- 그래픽

n Artwork, Modeling, Animation 등의 각각의 과정마다 점검, Map Sprite의 품질과 기본 컨셉과의 부합 여부, 의도한 곳에 제대로 배치되어 있는가, Visual Effect의 중간 점검

- 프로그램

n 기능이 원래의 설계 목적에 의해 구현되고 있는지 점검

n 그래픽 중간 결과물을 이용한 중간 테스트

n 구현 난이도와 일정을 비교하여 득보다 실이 많은 기능에 대한 판다.

- 기타

n 사운드(Sound)에 관련한 점검

C. 일정 점검 및 조정(Director, Coordinator)

Director와 Coordinator는 A의 공정과 같이 스케줄을 항상 감독 및 관리하며 여러가지 이유로 인해 일정을 조정해야 할 경우가 생겼을 때, 마케팅 팀, 각 파트 리더, 실무자들과 일정 조정 회의를 즉시 소집한다. 여기서 상황을 정확히 판단하여 필요한 만큼 일정을 조정하고 새로운 일정을 모두에게 공포하여야 한다.

D. 상세 기획의 수정 및 버전 관리(Game Designer)

공정상에 상세 기획서에서 뒤늦게 문제점이 발견되었을 경우 상세 기획서의 기능별 상호 독립성, 모듈성, 유연성, 시스템의 내구력 등에 대하여 필드(Field)에서 다시 점검하고 각 파트의 컴플레인(Complain)과 피드백(Feedback)을 받아 수정이 필요한 부분에 대하여 조속히 조치하고 기획 수정으로 인한 업무 혼손을 피하기 위하여 철저한 버전 관리를 병행한다. 만약 수정하려는 사항이 기본 컨셉과 각 파트의 작업 일정에 수준 이상의 영향을 끼친다면 Director와 협의하여 그의 결정을 따르도록 한다.

이러한 경우에, Director는 각 파트 리더 및 실무자와 회의를 열어 문제가 되는 수정 계획의 타당성과 실효성을 판단하고 그에 따라 합리적인 결정을 내려야 한다. 만약 일정을 조정하게 된다면, 일정 조정회의를 소집한다.

E. 중간 플레이 테스트 및 QA

품질 관리를 위하여 모든 상황에 대한 반복적인 테스트를 실시한다. 단순히 프로그램 버그(Program Bug)와 그래픽 불량, 논리적인 오류를 찾는데에서 그치는 것이 아니라 난이도, 재미, 컨셉의 전달이 제대로 되는지에 대한 여부 등을 심도있게 검토하고 문제가 있는 부분을 피드백해야한다. 이 작업에는 모든 스텝이 참여하며 여러가지 소비자 집단의 샘플 테스트도 병행하도록 한다. 각각의 테스트가 끝나는 중간 시점에서 디렉터(Director)와 리드 디자인 그룹은 수집한 데이터들을 분석하여 문제 해결 방법에 대한 정책을 수립하고 다시 테스트하는 작업을 반복하여 결과물의 완성도를 높이도록 한다.


7. 제품 지원

이 과정은 1차 알파 테스트 버전의 제작 완료 시점과 맞추어 시작되며 제품이 정상적인 궤도에 오르기까지 계속되어야 한다. 보통 이런 작업을 위하여 Game System Design팀과 Level Design Team에서 실무자로 구성된 TF를 조직하기도 한다.

A. 테스트 계획 수립(Director)

- 알파 테스트

- 베타 테스트

- 스트레스 테스트

B. 게임 내 이벤트 조정(Game Designer, Level Designer)

이벤트의 장치된 상태를 점검, 문제가 있는 부분을 수정, 필요하다고 판단되는 새로운 이벤트를 추가한다. 이 작업들은 이미 고정된 각 파트의 설계에 영향을 주지 않는 범위에서 이루어져야 한다.

C. 밸런싱 데이터 조정(Game Designer, Level Designer)

QA의 보고서에 기반하여 Lead Game Designer와 Lead Level Designer는 밸런싱 정책을 세우고, 게임 전체의 운용 룰(RULE)에 들어가는데이터, 레벨의 설계 등을 조율한다. 이 작업은 흔히 완성도로 대변되는 게임의 품질을 좌우하는 중요한 작업이며 합리적인 수준을 이를 때까지 계속 진행된다. 예를 들어 해외 유명 개발사(‘Starcraft’ Blizzard)의 경우를 보면 게임이 정식 출시된 후에 이 작업이 이루어져 몇 번의 Patch를 다시 보급하는 일도 있다.

D. QA(QA Task Force)

해외 개발사의 경우 QA팀과 QA팀 매니저가 따로 존재하지만, 국내의 경우 기존의 QA팀이 없다면 QA, TF를 결성하여 각 단계의 테스트 버전마다 게임의 품질(시나리오, 인터페이스의 편리성, 게임 플레이의 다양성, 집중도 등), 게임 플레이의 이상 패턴 등을 세밀하게 테스트하고 결과를 작성한다. 최종 리포트는 보고서 형식으로 분석/정리가 된 후에 각 파트별로 분류되어 수정 계획을 수립하는 데 기초가 되어야한다.

E. 매뉴얼(Manual), 게임 내 도움말 제작(Scenario Writer)

- 매뉴얼

n 알파 테스트 : 사내 테스트를 위한 간단한 매뉴얼, QA를 위한 점검사항의 지침도 포함

n 베타 테스트 : 거의 상용화 수준과 비슷한 매뉴얼 작성. 단 베타테스터에 대한 온라인 배포이기 때문에 HTML이나 일반 텍스트로 구성

n 상용화 : 시각적인 미학과 컨셉과 연관성도 고려. 필요하다면 텍스트 자체도 시나리오와 연결되도록 문학적인 조율이 필요. 이미 나온 테스트의 출판물로써 규격과 그래픽 이미즐 ㄹ입혀야 하는데 팀내에 DTP 관련 디자이너가 있다면 작업을 팀 내에서 진행하여 기획파트에서 감독하고, 그렇지 않다면 외주업체에 맡겨 관리

- 도움말

n Tutorial과 툴팁에 관한 텍스트 제작

n 반복적인 필드 테스트

F. 대외 홍보 지원(Scenario Writer)

- 기사 자료 및 Web Homepage의 컨텐츠 아이더어

- 게임 플레이에 관한 간략한 설명의 대외용 버전 제작

- 운영팀을 위한 게시판 관리 원칙 제시


8. 사후관리

게임기획팀, 마케팅 팀, 운영 팀이 작성한다.

A. 홍보용 이벤트 기획 수립

- 지속적인 게이머의 유치를 위한 캠페인 기획 수립

- 추가 지원, 수정 필요, 기본적인 게임 시스템에 영향을 주지 않는 범위 내에서 기획

B. 게임 내 이벤트 추가 및 MAP 확장 기획(Game Designer, Level Designer)

에디터를 통한 게임 시나리오 추가, 확장 팩 개념의 MAP, NPC, ITEM, EVENT 추가 기획을 작성한다.

C. 대외 홍보 지원(Scenario Writer)

제품의 Life Cycle이 지속되는 한 이 작업은 계속 이루어진다.


9. 게임 기획팀 인력 구성

1개의 프로젝트를 기준으로 게임 기획팀 필요 인력이다.

A. Director : 필요 인원 1명

B. Project Manager : 필요 인원 1명

프로젝트 매니저란 작업 공정을 항상 관리 및 감독하며 각 파트 간의 의견을 조정하고 인력과 기술의 투입과 예산 관리, 일정 변경 등의 중요한 업무에 대한 결정을 한다. 프로젝트의 흥망을 결정하는 중요한 직책이므로, 대형 프로젝트를 완결시킨 게임 스텝으로서 실전 경험(Field Exp)과 게임에 대한 종합적인 지식 및 이해부터 강한 리더쉽, 연출자로서 커뮤니케이션 능력과 판단력, 붆석력, 결단력 등의 필요하다.

C. Game Designer : 필요 인원 2명/ 미국의 경우 5~6명

디렉터(Director)가 관리자의 성격이 강하다면 Game Designer는 실무자의 성격이 강하다. Game System Designer라고 불리기도 하며 대략적으로 묘사된 게임 시스템의 룰을 구체화한다.

게임의 기본 컨셉과 상세한 구조(Game System Design)를 설계한다.

게임의 구조와 기능에 관련된 대부분의 결정을 내린다.

작업 공정의 관리에 있어 각 파트에 대한 감독의 실무자 역할을 맡는다. 역시 그래픽, 프로그램에 대한 정규적인 교육 과정을 마친 수준의 기본 개념과 문학적인 창작력, 이미지에 대한 상상력, 대중 음악에 대한 이해 등 문화, 예술적인 재능을 겸비하고 있어야 한다.

D. Level Designer : 필요 인원 2명

미국의 경우 8~10명 정도의 개별적인 팀 단위로 있다. MAP의 배치, 도시, 던전 디자인, NPC의 배치, 향후의 밸런싱 작업 등을 전담한다.

합리적으로 맞물리는 공식과 데이터, 논리적인 근거를 제시하는 작업을 해야하기 때문에 논리적이고 수학적인 사고를 지니고 있는 것이 유리하다. 게임 내 건축물과 지형의 배치에 대한 정책 결정을 전담하기 때문에 레벨 디자이너들은 건축이나 공간에 대한 미적 감각이 필요하다. 리드 그래픽 아티스트와 협의하여 맵 내의 텍스처(Texture) 사용에 대한 정책을 수립하는 것도 레벨 디자이너의 몫이다.

E. Scenario Writer : 필요 인원 1~2명

미국의 경우 3~4명이다. 매뉴얼 작성 팀은 따로 2~3명 구성되어 있다. 게임의 컨셉 제시, 배경 스토리 묘사, 내부 이벤트와 전체적인 플롯 작성한다. 또한 매뉴얼, 도움말 작성한다. 기타 사항으로는 기사, 홍보 자료 작성핟나.

이러한 직업은 재능이 있으며 다(多)장르의 글을 쓸 수 있는 신세대 작가가 적합하고 매뉴얼, 기사 자료에 관계된 부분은 전혀 다른 영역이기 때문에 시나리오 작가 보다는 저널리스트 출신이 유리하다.

F. Coordinator : 필요 인원 1명

대게 디렉터(Director)가 겸임하며 전체적인 작업 프로세스를 점검하고 문제점을 진단한다. 현재까지 작업 결과에 대한 현황 파악을 언제든지 하고 있어야 하며, 일정에 대한 급격한 변동을 일선에서 예방하는 역할을 한다.

G. Lead QA TF : 필요 인원 1명

게이머 성향이 짙은 운영팀에 전담팀 구성하여 리포트를 받는 것이 좋으며 기획팀에서 이 리포트를 필요한 부분을 추려내어 정리한다. 필요에 따라 기획팀에서 일부 차출되어 구성될 수도 있다.

------------------------------------------------------------------------------------

출처 : Inside Game Design (네이버블로그)