태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

오랜만에 블로그를 다시 재개합니다.



일단 메인 주제는 게임 기획이고, 아직 30대 중반이긴 하지만 고리짝때의 기획 방식을 많이 사용하는 편이라


"고리짝 게임기획"이라는 제목으로 연재를 한번 시작해보려고 합니다.


잘부탁드립니다.




첫 주제는 그리드 및 비트연산을 활용한 데이터 제작입니다.


어디에 쓰냐고요? 다양한 곳에 쓸 수 있습니다.


저는 개인적으로 레벨 디자인 데이터 관리를 할 때 이 방식을 많이 사용하는데요.


현재 개발 환경에서는 고리짝 방식이라 사용할 필요가 없긴 합니다.


뭐 그래도 탑뷰나 쿼터뷰 방식의 2D 게임에서 나름 쓸만할 수 있으니 참고는 해보시기 바랍니다.



1. 그리드를 그린다.


자 그럼 그리드에 대해서는 뭔지 다들 아실텐데요.


근데 굳이 그리드를 그리는 프로그램이 필요할까요?


당연히 필요 없습니다. 우리에게는 Microsoft EXCEL이라는 훌륭한 그리드 프로그램이 있기 때문이죠.


이렇게 한번 그려봅니다.

ID

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

1

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

2

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

3

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

4

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

5

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

6

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

7

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

8

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

9

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

10

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

11

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

12

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

13

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

14

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

15

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

16

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

<그리드1>


엑셀에서 그리드를 그렸습니다.


가로 16 X 세로 16이고 총 256개의 셀이 존재하는 필드입니다.


개인적으로 2의 제곱수를 사랑하기 때문에 위처럼 그린겁니다. 사실 숫자는 아무 관계없습니다.


취향껏 그리시면 됩니다.



레벨디자인의 예로 캐릭터의 이동 가능 셀 여부를 설정한다고 가정합시다.



ID

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

1

0

0

0

0

0

0

0

0

0

1

1

1

1

0

0

0

2

0

0

0

0

0

0

0

0

0

1

1

1

1

0

0

0

3

0

0

0

0

0

0

0

0

0

1

1

1

1

0

0

0

4

0

0

0

0

0

0

0

0

0

1

1

1

1

0

0

0

5

0

0

0

0

0

0

0

0

0

1

1

1

1

0

0

0

6

0

0

0

0

0

0

0

0

0

1

1

1

1

0

0

0

7

0

0

0

0

0

0

0

0

0

1

1

1

1

0

0

0

8

0

0

0

0

0

0

0

0

1

1

1

1

1

0

0

0

9

0

0

0

0

0

0

0

1

1

1

1

1

1

0

0

0

10

0

0

0

0

0

0

1

1

1

1

1

1

1

0

0

0

11

1

1

1

1

1

1

1

1

1

1

1

1

1

0

0

0

12

1

1

1

1

1

1

1

1

1

1

1

1

1

0

0

0

13

1

1

1

1

1

1

1

1

1

1

1

1

1

0

0

0

14

1

1

1

1

1

1

1

1

1

1

1

1

1

0

0

0

15

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

16

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

<그리드2 : 이동가능 구역 정의>


이동 가능한 셀은 1, 이동 불가능한 셀은 0으로 표시합니다.


푸른색 0은 물

노란색 1은 모래

초록색 1은 초원

갈색(?) 0은 산


과 같이 간주하여 그렸습니다.


실제로는 위의 셀 구분도 테이블 또는 Enum화 시키는 것이 좋겠죠.


ID

Enum

1

Water

2

Sand

3

Grass

4

Mountain

<Enum1 : 바닥 타일 구분>


뭐 대충 이렇게 Enum화 하여 배열화 시켜놓습니다.


각 Enum별 기능은 여기서 정의할 필요는 없습니다. 그건 제가 이야기하려는 것과는 다른 이야기죠.


아무튼, 위 방식대로 그리드를 정의했습니다.


그럼 저걸 리스트화해야겠죠?


<그리드2>를 기준으로 OFFSET 함수를 사용하면 간단하게 리스트화가 가능합니다.


ID

rows

columns

Value

1

1

1

0

2

1

2

0

3

1

3

0

4

1

4

0

5

1

5

0

6

1

6

0

7

1

7

0

8

1

8

0

9

1

9

0

10

1

10

1

11

1

11

1

12

1

12

1

13

1

13

1

14

1

14

0

15

1

15

0

16

1

16

0


Value 값에는 다음 함수를 사용합니다. 



그럼 <그리드2>에서 정의한 값이 Row와 Column에 따른 값으로 추출 및 리스트화 되죠.


그럼 0과 1로 구분된 이진값 리스트화가 되었습니다.


그럼 Value는 Bool로 정의되는 True / False만 정의된 값이 되겠습니다.


(1, 2) 좌표에는 이동이 False 라는 것이죠.



자 그럼 비트연산을 쓰는 이유를 추가해보도록 하겠습니다.


이미 이진값 하나는 추출이 되었습니다. 그럼 다른 데이터를 추가해보도록 합시다.



위의 바닥 타일별 Enum1에서 정의한 값 중, Sand에서는 이동 속도가 절반이 된다고 합니다.


그럴 경우 간단히 Sand에서 이동속도 절반을 소스코드에 추가하면 되긴 하지만,


그러면 이 방식으로 테이블화 하는 의미가 없겠죠?


사실 이정도까지 사용하지는 않지만, 굳이 해보자면 그렇다는겁니다.


ID

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

1

0

0

0

0

0

0

0

0

0

1

0

0

0

0

0

0

2

0

0

0

0

0

0

0

0

0

1

0

0

0

0

0

0

3

0

0

0

0

0

0

0

0

0

1

0

0

0

0

0

0

4

0

0

0

0

0

0

0

0

0

1

0

0

0

0

0

0

5

0

0

0

0

0

0

0

0

0

1

0

0

0

0

0

0

6

0

0

0

0

0

0

0

0

0

1

0

0

0

0

0

0

7

0

0

0

0

0

0

0

0

0

1

0

0

0

0

0

0

8

0

0

0

0

0

0

0

0

1

1

0

0

0

0

0

0

9

0

0

0

0

0

0

0

1

1

1

0

0

0

0

0

0

10

0

0

0

0

0

0

1

1

1

1

0

0

0

0

0

0

11

1

1

1

1

1

1

1

1

1

1

0

0

0

0

0

0

12

1

1

1

1

1

1

1

1

1

1

0

0

0

0

0

0

13

1

1

1

1

1

1

1

1

1

1

0

0

0

0

0

0

14

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

15

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

16

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

0

<그리드3: 이동 속도 1/2 지역>


모래 지역에서만 이동속도가 저하되기 때문에 모래 지역만 1 값을 넣습니다.


그럼 위와 마찬가지로 똑같이 OFFSET을 사용하여 정의합니다.


그럼 다음과 같이 정의됩니다. Value_2에 값을 지정합니다.


ID

rows

columns

Value_1

Value_2

1

1

1

0

0

2

1

2

0

0

3

1

3

0

0

4

1

4

0

0

5

1

5

0

0

6

1

6

0

0

7

1

7

0

0

8

1

8

0

0

9

1

9

0

0

10

1

10

1

1

11

1

11

1

0

12

1

12

1

0

13

1

13

1

0

14

1

14

0

0

15

1

15

0

0

16

1

16

0

0


그럼 다음과 같이 정의됩니다.


자 그럼 이것을 어떻게 비트연산에 활용하느냐?


바로 값을 합치는 것입니다.


간단하게 CONCATENATE 함수를 사용합니다. 그리고 BIN2DEC 함수를 사용하여 십진화합니다.


ID

rows

columns

Value_1

Value_2

BIN

DEC

1

1

1

0

0

00

0

2

1

2

0

0

00

0

3

1

3

0

0

00

0

4

1

4

0

0

00

0

5

1

5

0

0

00

0

6

1

6

0

0

00

0

7

1

7

0

0

00

0

8

1

8

0

0

00

0

9

1

9

0

0

00

0

10

1

10

1

1

11

3

11

1

11

1

0

10

2

12

1

12

1

0

10

2

13

1

13

1

0

10

2

14

1

14

0

0

00

0

15

1

15

0

0

00

0

16

1

16

0

0

00

0



이와 같이 이진화 합성 후 십진화하면, 바닥 타일 특성에 따른 유니크한 십진값이 도출됩니다.


다양한 값을 더 많이 사용해서 이진화 및 십진화하면 다음과 같이 표현할 수 있습니다.


ID

rows

columns

Value_1

Value_2

Value_3

Value_4

Value_5

Value_6

BIN

DEC

1

1

1

0

0

0

0

0

1

000001

1

2

1

2

0

0

0

0

0

0

000000

0

3

1

3

0

0

0

0

0

0

000000

0

4

1

4

0

0

1

0

0

0

001000

8

5

1

5

0

0

0

0

0

0

000000

0

6

1

6

0

0

0

0

0

0

000000

0

7

1

7

0

0

0

0

0

1

000001

1

8

1

8

0

0

0

0

1

0

000010

2

9

1

9

0

0

0

0

0

0

000000

0

10

1

10

1

1

0

0

0

0

110000

48

11

1

11

1

0

0

0

1

0

100010

34

12

1

12

1

0

0

0

0

0

100000

32

13

1

13

1

0

1

0

1

0

101010

42

14

1

14

0

0

0

0

0

0

000000

0

15

1

15

0

0

0

0

1

1

000011

3

16

1

16

0

0

0

0

1

0

000010

2


여기서 실제로 사용하는 값은 DEC 필드 하나입니다.


즉, 데이터 관리는 각각의 값을 직접적으로 기획에서 컨트롤하지만,


실제 프로그램팀에 제공되는 데이터는 ID / rows / columns와 최종적으로 추출한 DEC값 뿐입니다.


DEC 값은 Value로 정의하고 다음과 같은 테이블이 도출됩니다.


ID

rows

columns

Value

1

1

1

1

2

1

2

0

3

1

3

0

4

1

4

8

5

1

5

0

6

1

6

0

7

1

7

1

8

1

8

2

9

1

9

0

10

1

10

48

11

1

11

34

12

1

12

32

13

1

13

42

14

1

14

0

15

1

15

3

16

1

16

2


실제 위에서 적용한 값이 Value6까지이므로 2^6인 64개의 값을 정의합니다.


소스에서는 0부터 63까지 값에 대한 속성을 정의해주면 됩니다. 뭐 이렇게 말이죠.


변수정의


0 : 이동불가지역

1 : Value6에서 정의한 조건만 적용

2 : Value5에서 정의한 조건만 적용



비트연산에 익숙한 프로그래머들은 테이블에서 정의해준 십진값을 이진화한 다음 알아서 적용해줍니다.


 

대부분은 그냥 각 Value 별 TRUE / FALSE 정의해서 때려박자고 하더군요.



이게 무슨 삽질이냐 하는 분들이 엄청 많을 것이라 생각합니다만........ 뭐 고리짝 기법이니 어쩔 수 없죠...


아무튼 첫 고리짝 게임기획 기법은 여기까지입니다.



기획서 작성만 하다가 이런 글 쓰려고 하니 어렵네요.


이제부터 심심할때마다 고리짝때 쓰던 방법 하나씩 올리겠습니다.


물론 제가 쓰는 글에 대해서는 이런 방법도 있다 정도만 알아두시고 실무에서는 되도록 응용하지 말아주세요.


개발자들에게 혼날 수도 있어요.






게임 기획에 대해서 여러가지 생각해왔고
또 내가 기획서를 작성하는 것에 대해 다시한번 생각하는 계기가 된 글...

현재 팀장이라는 직책을 갖고 있지만 결국 난 아직 아마추어일뿐이다.


The Wafer-Thin or Ellipsis Special Document
매우 얇거나 생략 부호로 특화된 기획서

These thin little volumes, certainly none longer than thirty pages, startle and amaze the experienced game designer with their total and complete lack of any useful content whatsoever. They use meaningless descriptions like “gameplay will be fun” and “responsiveness will be sharp.” In these documents, many comparisons to other games are made: “This plays like Super Mario 64” or “The game has a control scheme similar to Quake.” While such comparisons can be slightly useful, as I have discussed, the writer of the Wafer-Thin Document almost always fails to explain the control scheme of Super Mario 64 or Quake in any detail, let alone the scheme to be used by the game in question.

분명히 30 페이지도 안 되는 이 얇은 기획서들은 아무 것도 쓸모있는 것이 없기 때문에 읽는 사람을 깜짝 놀라게 한다. 이 기획서에는 "이 기능은 재미있을 것이다", "반응이 격렬할 것이다"와 같은 아무 의미 없는 설명이 들어있다. 이런 설명 이외에도 다른 게임과의 비교가 많이 들어간다. "이 기능은 슈퍼 마리오 64와 비슷하다." 또는 "이 게임은 퀘이크와 같은 콘트롤 시스템을 가진다." 같이 말이다. 이런 비교가 약간은 쓸모 있을지도 모르나, 이런 기획서를 쓴 사람은 슈퍼 마리오 64나 퀘이크에 대해 추가적인 설명을 요구하면 아무 말도 하지 못한다. 결국 이런 기능들은 끝까지 의문점으로 남아있게 된다.

Often these documents spend a lot of time, maybe half their pages, talking about back-story. Usually this back-story is very weak and poorly developed and is only tangentially related to the game being developed. The Wafer-Thin Document also spends a lot of time talking about how the menus will work. Not the in-game menus, but the system menus where users select what type of game they want to play, set their options, and so forth. Many mock-ups are made and options are carefully listed. What exactly the options will affect in the game is seldom described in any detail, since the game itself is barely defined. Figuring out the menu system is something best pursued once the game is working, when the designer knows what sort of options might be important and what different gameplay choices players will have; it is certainly far from the most difficult part of game design, nor the most important system to nail down first.

이런 문서들은 종종 게임 배경을 설명하는데 반 이상의 분량을 할애한다. 대부분 이 배경들은 그리 치밀하지 못하고, 개발하고 있는 게임과 거의 관계가 없다. 또한 이 얇은 문서들은 메뉴가 어떻게 동작하는지에 대해 설명하는데 많은 시간을 할애한다. 게임 메뉴가 아니라, 사용자가 게임 설정을 조정하는데 쓰이는 시스템 메뉴에 말이다. 메뉴 레이아웃은 물론이고, 설정할 수 있는 옵션도 주의깊게 나열한다. 하지만 게임 자체에 대한 언급이 거의 없기 때문에, 이 설정들이 게임에 미칠 영향에 대해서는 아무 것도 설명하지 못한다. 게임이 돌아가는 상황에서는, 즉 기획자가 어떤 옵션이 중요하고, 플레이어가 어떤 선택을 할 수 있는지에 대해 알 수 있는 상황에서는 메뉴를 잘 구성하는 것이 중요한 일이다. 그러나 게임 기획의 가장 어려운 부분도 아니고, 가장 먼저 처리해야하는 부분도 아니다.

Wafer-Thin Documents are often constructed by managers who like to think they are game designers. The reason these can also be called Ellipsis Special Documents is that they are often littered with ellipses. For example, the worlds players will encounter in the game will be described in the following manner: “Jungle World is a very hot and sticky place where the Garguflax Monkeys swing around and torment the player...” And that will be all the document provides in way of description for the world, ending at an ellipsis, as if to say “insert game design here.” It is unclear whether the writers of these documents plan to come back and fill in at the ellipsis later or that perhaps they do not deem it worthy of their valuable time to actually explain how their game works. They just assume someone somewhere will fill it in and make them look good.

자신이 기획자라고 생각하는 매니저들이 이런 얇은 문서를 자주 만든다. 이 문서들을 생략 부호로 특화된 문서라고 부를 수 있는 이유는 이 문서들이 생략 부호로 점철되어 있기 때문이다. 예를 들어 게임 안에서 플레이어가 마주칠 월드에  관한 서술이 다음과 같다. "정글 월드는 매우 뜨겁고 끈적한 곳이다. 가구플랙스 원숭이가 나무를 타고 돌아다니며 플레이어를 괴롭힌다..." 생략부호로 끝나는 이 설명이 월드에 대한 설명의 전부이다. 마치 "실제 게임 기획을 여기에다 넣으시오"라고 말하는 듯 하다. 이 문서를 쓴 사람이 나중에 이 부분을 채워넣을 것인지, 자신들의 게임이 어떻게 돌아가는지에 대해 설명하는데 자신들의 소중한 시간을 소비할 가치가 없다고 생각할 것인지는 확실하지 않다. 그들은 그냥 어딘가의 누군가가 생략된 부분을 채워넣고 근사하게 보이도록 만들 것이라고 생각한다.

Another example of the content found in Ellipsis Special Documents might be: “Players will be given an option of many cool weapons. For example, the Gargantuan Kaboom does twice the damage of the players’ other weapons and has a special effect. The Barboon Harpoon will allow users to kill enemies at a distance with a nice camera effect. Other weapons will be just as fun and cool...” Here the writer of the Ellipsis Special fails to describe the weapons the game will have to any useful level of detail, and then, having listed two weapons, decides to leave the rest up to the imagination of the reader. Of course, readers are very usefully told that the other weapons will be “fun and cool.” The writers of the Ellipsis Special mistakenly think that is all the description necessary to develop a game.

이런 생략 부호로 특화된 문서에서 발견할 수 있는 또 다른 예는 다음과 같다. "플레이어는 여러 가지의 멋진 무기를 가질 수 있다. 예를 들어 가간츄안 폭탄은 다른 플레이어의 다른 무기에 비해 두 배의 데미지를 가지고, 특수 효과도 가진다. 바분 작살은 멋진 카메라 이펙트와 함께 적을 먼 거리에서 죽일 수 있다. 다른 무기 또한 재미있고 멋지다..." 이 문서를 작성한 사람은 게임에서 쓰이는 무기에 대해 자세히 설명하지 못했을 뿐만 아니라, 두 가지 무기에 대해서만 기술해 놓았다. 나머지는 모두 읽는 사람의 상상력에 달려 있다. 당연히 나머지 무기들은 '재미있고 멋지다'. 이 문서를 쓴 사람은 이 설명이 게임을 개발하는 데 필요한 전부라고 생각한다.

The only upside to the Wafer-Thin or Ellipsis Special Document is that it allows whoever gets to implement the design to pretty much take over the project and turn it into her own. I say this is an advantage, since usually the ideas the manager included in the Wafer-Thin Document are beyond ridiculous and do not make for viable gameplay. But one must be wary. Problems arise when the manager shows up six months later and complains: “But that’s not what I wrote!”

매우 얇거나 생략 부호로 특화된 문서의 단 하나의 장점이 있다. 이 문서를 기반으로 실제로 게임을 구현한 사람이 프로젝트 자체를 그 자신의 것으로 만들 수 있다는 점이다. 이것 분명히 장점이다. 매니저와 같은 사람이 쓴 이런 얇은 문서는 코미디에다가 눈에 보이는 게임 플레이를 만들어내지 못하기 때문이다. 그러나 조심해야한다. 매니저가 6개월 후에 나타나, "이건 내가 쓴 게 아니잖아!"라고 불평할 지도 모르기 때문이다.


The Back-Story Tome
배경 시나리오 책

Unlike writers of Ellipsis Special Documents, the designer who writes the Back-Story Tome spends a lot of time working on her document. These books (it is hard to call them merely documents) usually stretch into the hundreds of pages ? 300-, 400-, even 500-page documents are not out of the question. There’s a lot of information in there.

생략 부호로 특화된 문서를 만드는 사람들과 달리 배경 시나리오 책을 만드는 사람들은 문서를 작성하는 데 많은 시간을 할애한다. 이 책(문서라고 부르기는 어렵다.)들은 일반적으로 300에서 400 페이지, 심지어는 500 페이지 이상의 분량이 된다. 많은 정보들이 이 안에 있다.

The first mistake these documents make is usually a poor table of contents and the lack of an index. In a design document, well-ordered information and a good table of contents can replace an index, but the absence of both is a huge error. The problems are compounded when the document is as long as War and Peace. The primary reason for the existence of game design documents is to allow team members to quickly look up information about a section of the game they are working on. If a programmer wants to know how the AI for a particular enemy is going to work, she needs to find that information quickly and easily. If she cannot find it, she may just make something up. Similarly, when an artist wants an idea of the textures that will be needed for a given area in the game, she wants to be able to find where that area is described as quickly as possible. Design documents are not read like novels. No one starts at the beginning and comes out at the end. Primarily, design documents are reference materials, and if team members cannot easily retrieve the data they are seeking, they are liable to give up.

이런 문서들의 첫번째 실수는 빈약한 목차 또는 찾아보기가 없다는 점이다. 게임 기획 문서를 작성할 때, 정보를 잘 나열하고, 목차를 잘 쓰면 찾아보기 같은 것이 없어도 된다. 하지만 이 둘 모두 없으면 큰 잘못이다. 게다가 문서가 "전쟁과 사랑"만큼이나 두꺼운 것이라면 문제는 더욱 커진다. 게임 기획 문서가 존재하는 가장 큰 이유는 팀 멤버들이 자신이 원하는 정보가 어디에 있는지를 빨리 찾아내는 데에 있다. 프로그래머가 어떤 몬스터의 AI가 어떻게 돌아가야하는지를 알고 싶다면, 그 프로그래머는 그 정보를 쉽고 빠르게 찾아볼 수 있어야 한다. 프로그래머가 그것을 찾을 수 없다면 자기 마음대로 만들게 된다. 비슷하게 아티스트가  게임 안의 특정 지역에 쓰일 텍스쳐에 대해 알고 싶다면, 문서 안에서 그 지역에 대한 설명을 가능한 한 빨리 찾을 수 있어야 한다. 기획 문서는 소설처럼 읽히지 않는다. 그 누구도 처음부터 시작해서 끝까지 읽지 않는다. 근본적으로 기획 문서는 참조 문서다. 팀 멤버들이 자신이 원하는 정보를 쉽게 찾을 수 없다면  그들은 포기하기 쉽다.

However, once one starts hunting through one of these Back-Story Tomes, one is startled to find that, indeed, there is no information about the gameplay in there. It is all back-story. And at 500 pages, it is far more back-story than most computer games will ever use. The history of all the characters in the game, the friends of those characters, and all the relevant parents and siblings are all described in minute detail. It may be very interesting stuff (though usually it is a disorganized mess), but in the end the reader is left with very little idea of how the game is supposed to function. These documents are often the sign of the frustrated novelist or a writer from a non-interactive medium who does not truly understand game development. A lot of games make storytelling one of their central concerns, and a story bible can be quite useful to game creation. In such a case, it makes sense to discuss the game’s story in the design document to some extent. But first and foremost, a design document is supposed to contain the game’s design, which is very different from a game’s story. Remember, your most important consideration when writing a design document must be, “what can the player do?” Though these tomes are very significant in terms of weight and will probably impress the venture capitalists, the programmer who has to work with such a document as her only guidance is going to end up designing the game herself.

어쨌든 누군가가, 이 배경 설명 책을 읽어나가다 보면, 실제로는 게임 플레이에 대한 설명은 아무 것도 없다는 데 놀라게 된다. 모두 배경 이야기다.  게다가 500 페이지나 되는 분량은 실제 컴퓨터 게임에서 사용하는 분량보다 훨씬 많다. 게임 안에 나오는 캐릭터들에 대한 역사, 그들의 친구, 그들의 부모와 사촌들에 대해 모든 것이 기술되어 있다. 분명히 재미있을 수 있겠지만(비록 전혀 조직화되지 않은 통짜 덩어리라도...), 게임이 어떻게 동작할 것인지에 대한 아이디어는 아무 것도 남지 않는다.  이런 문서들은 소설가와 같이 상호작용이 없는 매체를 주로 다뤄온 사람들이 만든다. 게임 개발이 무엇인지 이해하지 못하는 사람들 말이다. 많은 게임들이 이야기를 풀어나가는 것을 중요하게 여긴다. 그런 경우에는 게임의 스토리와 관련된 부분을 좀 더 자세히 다루는 것은 의미가 있다. 하지만 첫번째이자 가장 중요한 사항은 게임 기획 문서는 게임 배경 문서와는 틀리다는 것이다. 기획 문서를 작성함에 있어서 가장 중요하게 고려할 사항은 "플레이어가 무엇을 할 수 있는가?"이다. 이런 책들이 무게가 꽤 나가고, 벤처 투자가에게 감명을 줄 수 있을지는 몰라도, 이런 책을 들고 게임을 만드는 프로그래머는 최종적으로 자신이 게임을 디자인하게 될 것이다.


The Overkill Document
불필요하게 자세한 문서

Some designers think they can describe every last aspect of a game in the design document. It is certainly true that many design documents lack the necessary detail to be useful, as we found in the Ellipsis Special Document discussed above, but at the same time, going to an excessive level of detail can be a waste of the designer’s time as well as that of the person who has to sift through all of that excess information. Furthermore, excessive documentation can lead to the illusion that the designer has created a complete, thorough document, when in fact she has gone into far too much detail about certain subjects while skipping other areas that need to be addressed.

어떤 기획자들은 게임의 가장 작은 요소들까지 일일이 설명할 수 있다고 생각한다. 생략 부호로 특화된 문서의 예에서 보았듯이, 많은 기획 문서들이 너무 두리뭉실해서 쓸 수 없는 경우가 많다는 것은 사실이다. 하지만 반대로 너무 자세한 기획서는 기획자의 시간 뿐만 아니라, 읽는 사람의 시간 또한 잡아먹게 된다. 한 걸음 더 나아가, 하나의 분야에 너무 집중하다보면, 완전한 기획서를 작성했다는 환상에 빠지기 쉽다. 다른 분야는 전혀 언급되지 않았는 데도 말이다.

For example, suppose that the game being documented has a number of characters that perform certain actions in the game-world. Say the game has townspeople, and they need to walk around, sit down and stand up, talk to each other, and sleep. The document should describe these behaviors in the AI section. A truly thorough document might break this down into separate animations: stand from sitting, sit from standing, idle sitting, idle standing, walk, converse with hand gestures, and so on. Probably this is not necessary, since good animators and artists will be able to break this down better than a designer can. But some designers may go overboard and actually sketch or list the individual animation frames. This is absurd. There is no way to know in the design document stage how many animation frames will be required for a given animation. This sort of decision can only be made and adjusted during the game’s production. Not to mention that listing animation frames is insulting to the animator who will only feel demoralized by this degree of micro-management. Furthermore, the design document should stick to gameplay design, and not veer into the territory of the art bible or other art documentation.

예를 들어, 몇명의 캐릭터가 게임 월드 안에서 하는 행동들에 대해 설명하는 문서를 생각해 보자. 게임 안에 마을 사람이 있다고 하자. 이들은 돌아다니고, 앉고 일어서며, 서로 이야기하고 잠을 잔다. 이런 행동들에 대해서는 AI 부분에서 다루어야 한다. 진정 완벽한 기획서라면 이 행동들을 애니메이션 레벨까지 분리해야한다. 앉아 있다 일어서기, 일어서 있다 앉기, 앉아있기, 서있기, 걷기, 손을 움직여 가며 대화하기 등으로 말이다. 아마도 이들이 다 필요하지는 않다. 좋은 애니메이터는 기획자가 하는 것보다 더 자세하게 이들을 분리할 수 있기 때문이다. 하지만 몇몇 기획자는 좀 더 나아가, 각각의 애니메이션 프레임을 스케치하기까지 한다. 이것은 어리석은 짓이다. 기획 문서를 제작하는 단계에서는 에니메이션이 몇 프레임이 될 지 알 수 있는 방법이 없다. 이런 것은 게임을 제작하는 단계에서나 결정될 수 사항 중의 하나다. 애니메이션 프레임을 일일이 나열하는 것은 이것을 실제로 제작하는 사람을 모욕하고, 사기를 떨어뜨릴 뿐이다. 기획 문서는 게임 플레이 기획에 집착해야지, 미술 영역 쪽으로 방향을 돌려 버리면 안 된다.

Another example might be what I call “balancing data.” These are the actual statistics for the weapons, items, and characters found in the game. The design document should probably list what different attributes weapons and characters will have. For instance, a weapon might have a range, accuracy, number of shots, and rate of fire. Furthermore, the design document might want to describe the qualities of a given weapon: “The Double Barreled Shotgun has a short range and a low accuracy, but does a large amount of damage in a large area.” However, actually listing the values for a weapon’s attributes is not very useful in the design document. Saying “Shotgun Accuracy: 2” does not really serve any purpose since the number “2” does not have any context and therefore no meaning. These values are best determined when the game is actually functioning, when a designer can balance the weapons as they will be used by the players and thus the designer can experiment with different settings to achieve the desired effects. Creating large tables full of data before this information is actually testable is by and large a waste of time. Filling in a chart quickly may be a way to convey some raw ideas that were hard to describe through words alone, but at best such a table is a first pass that will no doubt change many times before the game ships.

As with animation minutia and precise balancing data, source code also does not belong in the document. Designers who start writing out algorithms in their design documents are going too far. It does not matter if the designer is also a programmer. There should be no code, not even pseudocode, in the design document. Including code will only serve to bloat the document and distract from omitted information that needs to be covered. Some simple if-then-else type logical explanations may be useful and are completely appropriate. Such examples may help communicate all the contingencies to the person actually writing the code, and if nothing else force the designer writing the document to consider all the possible cases and outcomes that the game will need to support. But by the time the examples start looking like compilable C++ code, you know your document is overdoing it.

If there is any useful information in the Overkill Document, it is so hidden in the river of useless data that team members will be too intimidated to look for it. The author thinks that she can preplan everything, and that she is far more talented than any member of her team. While such excessive attention to detail can be impressive to those who do not really know what they are doing, a design document that goes too far will only infuriate the team that has to work with it.


The Pie-in-the-Sky Document
붕 떠있는 문서

These design documents often have noble intentions with grand ideas for truly magnificent gameplay. Sadly, the writers of them typically lack any technical grasp of what the computer is capable of or what a team of twenty people is likely to accomplish in a year and a half. As a result, these overly ambitious documents put forth fancy ideas with no basis in reality or feasibility and end up frustrating and infuriating the teams assigned to “make them happen.”

이런 기획 문서들은 장대한 게임에 대한 웅대한 아이디어를 기술한다는 숭고한 목적을 가진다. 슬프게도 이런 문서를 작성하는 사람들은 컴퓨터가 무엇을 할 수 있는지나, 20명의 개발자가 1년 6개월 동안 무엇을 만들 수 있는지에 대한 개념이 전혀 없다. 결과적으로 야망이 너무 큰 이 문서들은 상상으로서만 그칠 뿐, 그것을 실제로 구현해야하는 팀을 실망시키고, 노하게 한다.

Pie-in-the-Sky Documents include ideas such as “a fully modeled replica of Manhattan will be the players’ primary game-world, complete with AI agents representing all of the city’s seven million inhabitants in real-time.” The authors of Pie-in-the-Sky Documents do not want to be bothered with messy details such as the reality that no existing computer system can simulate seven million humans in any sort of reasonable time frame (let alone real-time). Another feature suggested might be “a natural language parser will be included that allows users to type in full, complex English sentences, which the characters will respond to with their own dynamically generated dialog.” The guilty designer does not want to hear that research institutions have been working for decades on natural language processors that still have trouble with short, simple sentences. When confronted with a Pie-in-the-Sky Document that you must work with, the first thing to do is call a reality check meeting involving key programmers and artists as well as the management who want this document implemented. With them all in the same room, some simple and quick calculations on a piece of paper or white board will often reveal how fundamentally impractical the game proposed is, and if the management still refuses to accept the reality of the situation, it might be time to start looking for a new job. Pie-in-the-Sky Documents are often combined with Ellipsis Specials to create truly wretched design documents, where the guilty designer outlines a completely impractical project without bothering to go into much detail about it.


The Fossilized Document
화석화된 문서

Any of the above flawed design documents can also be a Fossilized Document. Indeed, a design document that does not necessarily suffer from any of the above problems and was once a fine reference tool will become a Fossilized Document over the course of a project if the designer is not diligent in her efforts to keep the document up to date. I know of no original game project whose design has not changed significantly during the course of its development, and when the design changes but the design document does not, that document starts to become fossilized.

위와 나오는 잘못된 기획서들은 모두 화석화된 문서일 수도 있다. 사실 위에 나오는 사항들에 하나도 해당하지 않고, 한 때는 멋진 참조 문서였던 기획 문서라도, 기획자가 문서를 최신 버전으로 유지하기 위해 노력을 기울이지 않으면, 프로젝트가 진행됨에 따라 화석화될 수 있다. 개발 중에 기획 내용이 심각하게 변경되지 않는 게임은 없다. 게임 기획은 변경되었지만, 문서는 변경되지 않았을 때 문서는 점점 화석화되기 시작한다.

Suppose a programmer on the development team looks something up in the Fossilized Document and the information she finds is out of date. She may start implementing the old, long-since-modified functionality. At some point, a designer or producer who is aware of the changes that have taken place in the design will notice that the programmer is creating a system that is no longer appropriate, and will chastise the programmer for doing so. This creates frustration for both parties, not to mention wasting the programmer’s time. Furthermore, whenever the programmer needs to know something about the design in the future, she will not trust the design document, and instead will go hunt down a designer or producer to find out how a given system is supposed to function. Of course, this defeats the purpose of the document, as the designer must stop whatever she is working on to explain the system to the programmer. This new system may be described correctly in the document, but the programmer is not going to get burned again by using the Fossilized Document. When the designer fails to update the document when design changes occur, the entire document becomes useless. No one can trust it, and as a result no one will bother to read it.

개발팀의 프로그래머가 화석화된 문서 안에서 어떤 사항을 찾아봤는데, 그 사항이 오래된 것이었다고 하자. 그 프로그래머는 오래된 기획에 있는 것을 구현하기 시작한다. 어느날 기획자는 프로그래머가 더 이상 올바르지 않은 시스템을 구현했다는 것을 알고, 프로그래머에게 왜 그렇게 했냐고 질책한다. 이것은 프로그래머의 시간을 낭비할 뿐만 아니라, 프로그래머와 기획자 모두에게 서로에 대한 불신을 안겨준다. 나중에 프로그래머가 기획 내용이 필요하게 되었을 때, 그는 기획 문서를 믿지 않을 것이다. 대신 그는 무엇이 어떻게 돌아가는지 기획자에게 가서 물어보게 될 것이다. 문서에 있는 내용이 비록 올바른 것이더라도 말이다. 기획자가 문서에 있는 특정 내용을 갱신하는 데 게을러지면, 전체 문서 자체가 쓸모없어져 버린다. 누구도 믿을 수 없는 기획서는 결과적으로 누구도 읽지 않을 것이다.

Wiki systems can be great for more easily keeping a document or collection of documents up to date. With Wiki, any member of the team can update a section of the document through their web browser, and full version control and history is supported to prevent the accidental loss of data. So, for example, the programmer who is implementing a particular feature can slightly modify the text of the design document to match how the feature actually ended up working, to add more information, or to link to the newly created technical design document for that particular feature. On a large enough project, keeping the design document completely up to date can be a full-time job.


[##_kaAmo_##]

+ Recent posts