1. 정 의
제작 초기 단계는 최초 프로젝트 진행이 결정된 이후 실무자들이 모여서 앞으로 만들어질 게임의 스타일 및 목표를 확인하고 차후 본격적인 제작에 앞서 여러 가지 문제를 미리 예측하고 점검해 보기 위한 ‘프로토타입’ 을 제작， 태스트하는 단계를 말한다. 또한 실무 단계는 프로토타엽의 완성 이후 본격척으로 완성도 있는 게임을 제작하기 위한 여러 단계， 즉 알파버천 및 베타버전 둥을 작성하는 단계이며， 이 과정에서 여러 가지 컨셉 및 셰부 디자인 내용을 작성하거나 수정하는 목적으로 본 문서를 사용하게 된다. 위에서 언급한 프로토타입，알파•베타버전의 단계들은 일반척인 예시로써，각 업체의 사갱에 따라 다양하게 분리 혹은 통합될 수 있다.
2. 제작 초기 및 실무 단계에서 필요한 문서
가. 버전 수준 결정 문서
프로젝트 진행 과정에서 작성하고자 하는 단계별 버전의 수준을 결정하는 문서이다. 여기서 ‘버전’ 이라 함은， 프로토타엽 및 그 이후의 단계에 따른 결과물(알파버전， 베타버전)틀을 돗한다. 제작 초기에는 설무자틀에 의해서 프로혜트의 각종 예측 가능한 문제를 대스트 해볼 수 있는 ‘프로토타업’ 의 수준을 결정한다 프로토다업은 프로젝트의 성격과 규모 등에 따라 그 완성 수준이 다를 수 있으므로， 프로토타업 제작에 앞서 게임 제작 실무자들이 서로의 개념을 공유하고 조율하기 위한 목적으로 이 문서를 작성한다. 프로토타엽의 완료 후에는 프로젝트를 본격적으로 구현하는 과정에 있어서 알파버전， 베타버전 풍의 세부 단계에 대한 수준 결정 및 계획 문서로써 활용한다.
나. 버전 컨셉 및 세부 디자인 문서
다음 단계， 즉 프로토타업 또는 각 단계별 버전의 수준이 결정된 이후에는 그것을 제작하기 위하여 기획 파트가 다른 파트(그왜픽，프로그래멍 둥)들과 유기적으로 협조하여 세부적인 각 요소를 디자인한다 이 문서를 토대로 하여 각 파트별 제작이 진행되기 때문에， 파트별 책임자들이 적극 참여하여 최대한 세부적으로 작성한다. 세부 디자인 문서의 내용틀은 ‘III. 공통 컨셉 디자인 단계’ 와 ‘IV. 공통 세부 디자인 단계’에 자세히 설명되어 있기 때문에 여기서는 설명하지 않는다
다. 개발 평가서
제작이 완료되고 테스트가 친행된 후，테스터들이 차기 버천에서 수정 및 보완되어야 할 사항을 서술하는 문서이다. 해당 버전의 제작이 환료되면 그 결과물을 태스터들이 직접 플레이하며 전반적인 대스트 작업을 수행한다(여기서 대스터는 해당 버전의 특성에 따라 그 인력과 인원수가 변청될 수 있다) 해당 버전에서 발생한 문제， 오류 및 보완해야 할 사항틀이 도출되면 그것을 개발 형가서로 작성하게 되며， 파트별 책임자는 이 문서틀을 종합하여 다음 단계의 버전을 어떻게 만들어 나갈 것인지에 대한 의견을 얻게 된다.
3. 각 문서별 표준안 설명
가. 버전 수준 철정 문서
(1) 구성 항목별 설명
(가) 문서 번호
프로젝트 리더에 의해서 매겨진 번호로서， 차후 세부 기획서 동에서 참고하기 위한 번호로사용된다.
예> Version-20040125-v.001 : 2004 년 1 월 25 일 작성된 버전 수준 결정문서이다.
(나) 프로젝트 명칭
프로젝트의 상품명을 표기한다.
예〉 프로젝트 명칭 : ‘Zestinder’ (가칭)
(다) 작성 일자
해당 문서 작성을 완료한 일시로서， 연월일을 표기한다. 추가로 초안 작성 일자를 함께 표기하기도 한다.
예〉 작성 일자 : 2004-1-25
(라) 작성자
해당 문서를 작성한 작성자의 생명을 표기한다. 보통 프로토타업의 경우 프로젝트 리더가 결정을 하여 작성하게 된다 내규에 의해서 설명 이외의 자체적인 ID 둥을 사용할수도 있다.
예〉 작성자 홍길동， 작성자 : kjy6408
(마) 버전의 정의
현재의 프로젝트에서 해당 버전에 대한 정의를 서술한다 프로젝트의 특성에 따라서 각 버전의 정의가 달라질 수 있으며， 이것을 상정적으로 표현할 수 있는 짤막한 문장을 작성하도록 한다. 예를 틀연 ‘아트 컨셉을 미리 확인하기 위한 프로토타입’ 이라든가， ‘동시 접속자수에 대한 스트레스테스트를 위한 프로토타입’ 이라든가 하는 식의 중점을 요약하는 형태로 작성한다. 보다 세부적인 구현 내용은 이후의 ‘주요 제작 포인트’ 항목에서 서술해주도록 한다.
(바) 제작 기간
해당 버전을 제착하기 위해 펼요한 기간을 전체적으로 표기한다 제작기간은 태스트 기간을 포함하여 산출하고 표시한다.
(사) 주요 제작 포인트
해당 버전을 제작함에 있어서 가장 중점적으로 구현해야 하는 내용을 좀 더 세부적으로 설명하는 부분이다. 이 부분은 게임의 천체적인 내용을 포괄하도록 작성하며， 될 수 있으면 파트별로 작성하는 것이 참조하기에 좋다. 문서를 읽는 작업자로 하여금 본 버전에서 가장 중요한 ‘요점 (포인트)’ 을 이해할 수 있도록 작성한다
1) 항목 번호
각 항목을 구별할 수 있는 번호를 서술한다.
2) 항목 명칭
혜당 항목을 대표할 수 있는 제목을 표기한다.
3) 담당 파트
본 항목을 구현하는데 중심적인 역할을 해야 하는 파트를 서술한다 필요한 경우 유기적으로 협력해야 하는 다수의 파트를 표기할 수도 있다.
4) 내용
본 항목에서 설명하고자 하는 중요 구현 포인트에 대해서 설명한다. 읽는 사람으로 하여금 중요 요소를 쉽게 이해할 수 있도록 이유， 목적 둥을 효과적으로 작성한다 그렴，사진 등의 첨부이미지 및 여러 가지 자료를 통원하여도 무방하다
5) 기대효과
본 항목을 성공적으로 구현하였을 때 기대되는 효과 및 결과물을 설명한다. 이 항목은 후에 대스트 파정에서 해당 버전의 완성도를 평가할 때 참조될 수 있다.
6) 확인 방법
프로토타입 및 기타 버전에서 해당 기획적인 요소를 확인하기 위한 구체적인 방법을 설명한다. 예를 들어， 전투 밸런스를 반드시 테스트하여야 하며，이 때 시간당 어느 정도의 전투를 해야 하는가 하는 둥의 구체적인 방볍을 설명한다
7) 기간
프로토타입 및 기타 버전에서 해당 기획적인 요소를 확인하기 위한 구체척인 기간을 설명한다. 펼요에 따라서 횟수로 표기할 수도 있다.
(2) 버전 수준 결정 문서의 예
| 문서 번호 | Version-20040202-v.001 |
| 프로젝트 명칭 | 마법의 성(가징) |
| 작성일자 | 2004-1-31 |
| 작성자 | 홍길동 |
| 관련문서 | Proposal-20040125-v.003 |
프로토타입 수준 결정 1 프로토타입 정의 현재 작업진행을 앞두고 있는 프로토타입의 목적은 마트 켠셉을 미리 확민하며 전처|적인 게임의 분위기를 구성하기 위한 척도로서 사용한다. 아울러 동시 접속자수에 대한 스트레스테스트를 위해 간단한 시율레이션 자료를 준비한다. 2 므로토타입 제작 기간 흥 제작기간은 3 개월로 하되， 세부 디자민 단계가 어느 정도 마무리 되는 것을 고려해 본다면 결과적으로 4 개월이 소요된다고 생각할 수 있다 게임 내부의 시스템이나 효과는 크게 고려하지 않기 때문에 ...(이하 생략) 3 각 파튿열 프로토타입 수준 결정 •디자인 파트
| |
나. 버전 컨셉 및 세부 디자인 문서
프로토타입， 알파버전 및 베타버전 등의 제작에 따른 컨셉 및 세부 디자인 문서를 작성한다 이 문서에 대한 내용은 ‘III. 공통 컨셉 디자인 단계’ 와 ‘IV. 공통 세부 디자인 단계’ 에서 통합적으로 다루고 있다.
다. 개발 평가서
(1) 구성 항목별 설명
(가) 문서 번호
개발 평가서가 갖는 고유한 번호이다 차후 버전 수준 결정문서 동에서 참고하기 위한 변호로사용된다.
예> Valuation-20040207-v.001 : 2004 년 2 월 7 일 작성된 개발 평가서이다
(나) 프로젝트 명칭
프로젝트의 이름을 표기한다.
예〉 프로젝트 명칭 : ‘Zestinder’ (가칭)
(다) 작성 일자
해당 문서 작성을 완료한 일시로서， 연월일을 표기한다 추가로 초안 작성 일자를 함쩨 표기하기도 한다.
예〉 작성 일자 : 2004-1-25
(라) 작성자
해당 명가서를 작성한 작성자의 성명을 표기한다. 내규에 의해서 설명 이외의 자체적인 ID 동을 사용할 수도 있다.
예〉 작성자 . 홍길동， 작성자 : kjy6408
(마) 관련 문서
해당 문서와 관련된 문서를 표기한다. 보통 버전 수준 결갱 문서를 표기하게 되며， 기타 판련 있다고 생각되는 분서들 또한 표기할 수 있다. 문서번호 혹은 문서명칭을 표기할 수 있으며，문서 명칭을 표기할 경우 해당 문서의 최선버전을 참조하는 것으로 한다.
(바) 평가 내용
해당 프로젝트의 평가 내용을 표기한다. 각 파트별로 평가항목 및 세부 내용을 표기하고，이에 대한 평가 결과와 차기 버전에서의 수정방안을 서술한다.
1) 항목 변호
해당 평가 항목의 번호를 표기한다
2) 항목 명칭
해당 명가 항목의 제목을 표기한다
3) 담당 파트
해당 평가 항목이 포함되는 파트의 명칭을 표기한다. 다수의 파트를 서술할 수도 있으나， 혼동을 피하기 위해서는 그래픽， 디자인， 프로그래밍 파트중 하나만 연관시키는 것이 좋다. 태스터가 외부 인력으로 파트에 대한 개념이 부족한 정우에는 굳이 서술하지 않을 수도 있으며， 이 경우 디자인 파트에서 내부 회의를 거쳐서 반영한다.
4) 항목 요소 설명
해당 평가 항목의 요소를 설명한다 해당 요소의 평가 방법과 함께 그 결과를 구체적으로 나열한다 ‘테스트 체크리스트’ 에서 추출한 자료 및 필요한 정우 직접 찍은 스크린삿 둥을 첨가하는 것도 좋다
5)평가 결과
해당 평가 항목 요소를 평가한 결파를 서술한다. 물론，이 내용은 평가자의 주관적인 내용이 될 수 있으며， 펼요에 따라서 객관적인 자료(사진， 스크린삿 둥)를 함께 첨부할 수 었다 또한 해당 결과가 차기 버전에서는 어떻게 반영되어야 하는지 자세히 서술한다
(2) 개발 평가서의 예
| 문서 번호 | Valuation-20040128-v.001 |
| 프로젝트 명칭 | 마법의 성(가칭) |
| 작성일자 | 2004-1-28 |
| 관련문서 | Version-20040202-v.001 |
개발 평가서 1 프로그래밍 파트 가) 낙하속토 어잭함 (val-0001) 주민공이 아래로 떨어질 때의 속도가 조금 어색하다. 처음에는 상당히 천천히 떨어지다가， 갑자기 빠르게 떨어지는 느낌이다. 떨어지는 속도가 느리거나 혹은 빠르면서도 균일하게 떨어지면 보다 일관성 있는 움직임을 강게 될 것이라고 생각한다 나) 방울 날아가는 형태 깨짐 (val-0002) 5 스테이지에서 쩍들이 발사하는 방룰과 주민공이 알사하는 화살이 부딪힐 경우 그래픽이 깨지는 현상이 발생하였다 수정이 필요하다..(이하 생략) 2 그래픽 파트 가) 어잭한 악어 모델링 (val-0009) 1500 개 정도의 폴리곤을 썼다고 보기맨 막어의 형태가 너무나 어색하다 텍스쳐도 다소 밀리는 느잉 특히 눈 부위의 형태가 상당히 일그러지는 것 같다 쩍당히 최적화하고， 텍스쳐를 손봐야 할 것이다 나) 하늘 텍스쳐 깨졌음 (val-0010) 구름이 흘러가게끔 만든 부분에서 컬러가 이상하게 변해있는 상태를 발견하였다. 아마도 구름이 지나가는 방항을 표시한 것이 아직 수정되지 않고 그대로 남아있는 것 같다 아마도 이미지 파일 자체를 수정해야 할 것이다.....(이하 생략)
| |
Labels