Q&A와 스터디
지금 공모전 참가를 위해 기획서를 쓰고 있는데..... 어느정도 까지 세부적으로 써야 하는건가요?
일단 저는 게임의 특성과 화면 인터페이스, 조작 인터페이스 이런 식으로 나누어 쓰고 있습니다.
혹시 각 종족의 직업이나 아이템, 스킬의 종류와 특성, 효과 까지 세부적으로 써야 하는 건가요?
공모전 양식에는 기획서 한부와 게임 개요서를 한부 제출하라고 되어 있는데 종족이나 아이템 스킬 같은 요소들은 기획서가 아니라 개요서에 쓰는 건가요?
구체적으로 기획서는 어느 정도까지 세부적이고 구체적이어야 하는 건가요?
일단 저는 게임의 특성과 화면 인터페이스, 조작 인터페이스 이런 식으로 나누어 쓰고 있습니다.
혹시 각 종족의 직업이나 아이템, 스킬의 종류와 특성, 효과 까지 세부적으로 써야 하는 건가요?
공모전 양식에는 기획서 한부와 게임 개요서를 한부 제출하라고 되어 있는데 종족이나 아이템 스킬 같은 요소들은 기획서가 아니라 개요서에 쓰는 건가요?
구체적으로 기획서는 어느 정도까지 세부적이고 구체적이어야 하는 건가요?
![[레벨:3]](http://old.lameproof.com/modules/point/icons/default/3.gif "포인트:1099point (45%), 레벨:3/30"){kind=icon}
제리
2007.02.04 00:41:57 (*.62.229.47)
![[레벨:7]](http://old.lameproof.com/modules/point/icons/default/7.gif "포인트:4676point (19%), 레벨:7/30"){kind=icon}
Excelsis 프로그래머 입장에서 어떤 기획서가 좋은지 이야기하자면...
인터페이스 쪽은 게임 공략집같은데 보면 각 버튼별로 어떤 역할인지 어떻게 표시되는지 등등 설명해놓은거 그런식으로 하면 되구요
진행순서든 화면 레이아웃이든 글로만 설명해놓으면 프로그래머 미칩니다. 그림을 바로 놔두고 설명하면서, 이거 누르면 어떻게 진행되는지 식으로 플로우차트 그리듯이 설명하면 좋습니다.
그리고 각 종족... 각 직업... '각' 이라는 말이 나오는 순간 프로그래머 머릿속에서는 아놔 이거 내가 정리해야되네 라는 생각으로 빠집니다.
'모든 캐릭터'는 어떤 스탯을 가지고 있고, 각 스탯은 어떤 능력치나 특성에 관련되어있다
'모든 스킬' 은 어떤 속성치와 데이터들을 가지고 있고, 각 속성이나 데이터들은 어떻게 표현된다
이 다음에, 어떤 구체적인 캐릭터 종족, 직업, 스킬들을 위에 서술된 것들을 이용해 표현하시면 됩니다.
사실 누구나 그렇듯이, 남이 쓴 긴 문서 읽는거 별로 안 좋아합니다.
프로그래머도 마찬가지로 수십장 수백장 쓰인 기획서는 읽던 도중에 앞엣내용 다 까먹습니다.
생각의 순서 자체가, '모든' 요소에 부합되도록 정리하는 과정이 맨 마지막이기도 하고 기획자 머릿속엔 원래 자기생각은 자기머리에 다 들어있게 마련이라
완전히 정리하긴 어렵습니다만 뭐 이런걸 제대로 해 주는 기획자일수록 일하기가 수월하고, 결과적으로도 좋습니다.
분명히 한번 정리한 기획도, 뭔가 추가하게 마련입니다.
그리고 추가 전에는 당연히 기존요소에 주는 영향에 대한 평가를 하게 마련입니다.
이럴 때, 각 종족의 각 캐릭터별로 다 나뉘어있는 요소들을 다시 다 확인해서 이 요소를 추가했을 때 어떤 영향을 미칠 지 검토하는 게 가능할 리가 없습니다;;
인터페이스 쪽은 게임 공략집같은데 보면 각 버튼별로 어떤 역할인지 어떻게 표시되는지 등등 설명해놓은거 그런식으로 하면 되구요
진행순서든 화면 레이아웃이든 글로만 설명해놓으면 프로그래머 미칩니다. 그림을 바로 놔두고 설명하면서, 이거 누르면 어떻게 진행되는지 식으로 플로우차트 그리듯이 설명하면 좋습니다.
그리고 각 종족... 각 직업... '각' 이라는 말이 나오는 순간 프로그래머 머릿속에서는 아놔 이거 내가 정리해야되네 라는 생각으로 빠집니다.
'모든 캐릭터'는 어떤 스탯을 가지고 있고, 각 스탯은 어떤 능력치나 특성에 관련되어있다
'모든 스킬' 은 어떤 속성치와 데이터들을 가지고 있고, 각 속성이나 데이터들은 어떻게 표현된다
이 다음에, 어떤 구체적인 캐릭터 종족, 직업, 스킬들을 위에 서술된 것들을 이용해 표현하시면 됩니다.
사실 누구나 그렇듯이, 남이 쓴 긴 문서 읽는거 별로 안 좋아합니다.
프로그래머도 마찬가지로 수십장 수백장 쓰인 기획서는 읽던 도중에 앞엣내용 다 까먹습니다.
생각의 순서 자체가, '모든' 요소에 부합되도록 정리하는 과정이 맨 마지막이기도 하고 기획자 머릿속엔 원래 자기생각은 자기머리에 다 들어있게 마련이라
완전히 정리하긴 어렵습니다만 뭐 이런걸 제대로 해 주는 기획자일수록 일하기가 수월하고, 결과적으로도 좋습니다.
분명히 한번 정리한 기획도, 뭔가 추가하게 마련입니다.
그리고 추가 전에는 당연히 기존요소에 주는 영향에 대한 평가를 하게 마련입니다.
이럴 때, 각 종족의 각 캐릭터별로 다 나뉘어있는 요소들을 다시 다 확인해서 이 요소를 추가했을 때 어떤 영향을 미칠 지 검토하는 게 가능할 리가 없습니다;;
2007.02.04 00:47:18 (*.62.229.47)
Excelsis 아 그리고 모든 이라고 하니까 약간 두루뭉실한데,
모든 캐릭터가 서로간의 상호작용에 필요한 필수 요소들의 모음으로 만들어주면 됩니다.
전투를 할 수 있는 게임이라면 전투에 필요한 필수요소는 공격력 방어력 체력 이런 게 있겠죠
SP라는 요소가 있는데, 자신이 스킬 쓰는 결정시점에만 이 요소가 필요하고 타인의 SP에 어떤 작용을 할 수 없는(깎거나 빼앗거나...) 게임이라면 SP는 이 요소들의 모음에서 제외될겁니다. 없어도 전투 프로세스에 아무 영향이 없습니다.
이런식으로 분할하시면 됩니다.
모든 캐릭터가 서로간의 상호작용에 필요한 필수 요소들의 모음으로 만들어주면 됩니다.
전투를 할 수 있는 게임이라면 전투에 필요한 필수요소는 공격력 방어력 체력 이런 게 있겠죠
SP라는 요소가 있는데, 자신이 스킬 쓰는 결정시점에만 이 요소가 필요하고 타인의 SP에 어떤 작용을 할 수 없는(깎거나 빼앗거나...) 게임이라면 SP는 이 요소들의 모음에서 제외될겁니다. 없어도 전투 프로세스에 아무 영향이 없습니다.
이런식으로 분할하시면 됩니다.
2007.02.08 08:01:43 (*.250.190.140)
![[레벨:0]](http://old.lameproof.com/modules/point/icons/default/0.gif "포인트:10point (11%), 레벨:0/30"){kind=icon}
김광수 기획 단계에서 대부분의 (적당한)수치들과 특정 상황에 따른 다양한 예외 상황의 대처방안 까지도 나와 줘야 합니다.
구현 해 놓고 보면 다른 게임 내의 기능이나 기획안과 모순이 되어 이도저도 안되는 애매한 상황이 발생하죠.
구현 해 놓고 보면 다른 게임 내의 기능이나 기획안과 모순이 되어 이도저도 안되는 애매한 상황이 발생하죠.
2007.02.08 18:41:58 (*.248.18.30)
![[레벨:1]](http://old.lameproof.com/modules/point/icons/default/1.gif "포인트:328point (88%), 레벨:1/30"){kind=icon}
김현욱 ㄴ적당한 수치와 특정상황에 따른 예외상황의 대처방안이라는건 구체적으로 어떤걸 말하는 건가요? 제가 기획서는 완전히 처음 써보는 거라 쉽게 이해하지 못하는점 이해해 주셨으면 합니다;;
그동안 게임을 해보기만 했지 정말 프로가 쓴 기획서 같은건 찾아보지를 못해서 구체적으로 어떤 상황인지 이해하기가 힘드네요;;
적당한 수치라고 하는것은 뭐 공격력이나 방어력 등의 계산식이나 수치를 말하는 건가요?
그리고 예외적 상황의 대처방법이라는 것은 혹시 유저들이 해킹 툴 등을 사용할때의 상황... 그런건가요?
수고스러우시겠지만 간단하게 예를 좀 들어주시면 감사하겠습니다
그동안 게임을 해보기만 했지 정말 프로가 쓴 기획서 같은건 찾아보지를 못해서 구체적으로 어떤 상황인지 이해하기가 힘드네요;;
적당한 수치라고 하는것은 뭐 공격력이나 방어력 등의 계산식이나 수치를 말하는 건가요?
그리고 예외적 상황의 대처방법이라는 것은 혹시 유저들이 해킹 툴 등을 사용할때의 상황... 그런건가요?
수고스러우시겠지만 간단하게 예를 좀 들어주시면 감사하겠습니다
2007.02.10 13:32:53 (*.62.229.47)
Excelsis 예외상황이라 함은,
(이런건 없어야 하지만) 기획상 모순이 발생하는 경우, 이에 따른 처리방안.
(이런것도 없어야 하지만) 계산이 불가능한 공식이 발생하는 경우 ( 수치 계산 중, 0으로 나누는 경우가 발생하는 케이스 )
기획상 특정 상황에만 발생하는 '기본 룰'을 따르지 않는 케이스
가 대표적입니다.
1. 모순의 케이스에는 실제로 웬만하면 별 문제없이 프로그램은 돌아갑니다. 원하는 대로 안돌아가서 문제죠. 이거 희안한 케이스 많이 발생합니다.
프로그램상에서는 보통 방어가 이깁니다. 데미지 계산 실컷 다 해놓고, 방어 공식 적용해보니 절대적으로 못뚫더라- 그럼 방어가 이기죠.
근데 만약 공격이 이기게 하고 싶은 게 기획의도라면? 이런것들을 정의해줘야 합니다.
2. 기획상 나눗셈은 상당히 나쁜 연산입니다. 생각없이 나누기 남발해서 공식 짜다보면 0으로 나누게 되는 케이스가 꼭 있습니다.
정말 필요한 케이스가 아니라면, 소숫점 곱하기를 해주던가( 2로 나누는것과 0.5를 곱하는 것은 같습니다... ) 덧셈뺄셈으로 해결하는 게 낫구요
굳이 꼭 필요하다면 0으로 나누는 경우 어떤 숫자- 예를 들면 1.0으로 나눠라 라고 적어주는 게 필요합니다.
3. 예를 들자면, 모든 캐릭터는 숲에서 속도가 떨어지지만, 엘프는 속도가 떨어지지 않는다 같은 내용이 있습니다.
경우에 따라서 다른데- 숲에서 속도가 떨어지는 캐릭이 많으냐 적으냐에 따라서 이걸 예외로 처리할 지, 아니면 숲 속도 배율 (인간:0.4, 엘프 1.0, 오크 0.7 등등) 같은 변수를 모든 캐릭터에 추가할지를 결정해야 합니다.
(이런건 없어야 하지만) 기획상 모순이 발생하는 경우, 이에 따른 처리방안.
(이런것도 없어야 하지만) 계산이 불가능한 공식이 발생하는 경우 ( 수치 계산 중, 0으로 나누는 경우가 발생하는 케이스 )
기획상 특정 상황에만 발생하는 '기본 룰'을 따르지 않는 케이스
가 대표적입니다.
1. 모순의 케이스에는 실제로 웬만하면 별 문제없이 프로그램은 돌아갑니다. 원하는 대로 안돌아가서 문제죠. 이거 희안한 케이스 많이 발생합니다.
프로그램상에서는 보통 방어가 이깁니다. 데미지 계산 실컷 다 해놓고, 방어 공식 적용해보니 절대적으로 못뚫더라- 그럼 방어가 이기죠.
근데 만약 공격이 이기게 하고 싶은 게 기획의도라면? 이런것들을 정의해줘야 합니다.
2. 기획상 나눗셈은 상당히 나쁜 연산입니다. 생각없이 나누기 남발해서 공식 짜다보면 0으로 나누게 되는 케이스가 꼭 있습니다.
정말 필요한 케이스가 아니라면, 소숫점 곱하기를 해주던가( 2로 나누는것과 0.5를 곱하는 것은 같습니다... ) 덧셈뺄셈으로 해결하는 게 낫구요
굳이 꼭 필요하다면 0으로 나누는 경우 어떤 숫자- 예를 들면 1.0으로 나눠라 라고 적어주는 게 필요합니다.
3. 예를 들자면, 모든 캐릭터는 숲에서 속도가 떨어지지만, 엘프는 속도가 떨어지지 않는다 같은 내용이 있습니다.
경우에 따라서 다른데- 숲에서 속도가 떨어지는 캐릭이 많으냐 적으냐에 따라서 이걸 예외로 처리할 지, 아니면 숲 속도 배율 (인간:0.4, 엘프 1.0, 오크 0.7 등등) 같은 변수를 모든 캐릭터에 추가할지를 결정해야 합니다.