1. 2부
증명된 컨셉을 바탕으로
게임디자인 하기
박수영

2. 이제 본격적으로 게임 디자인을 해 봅시다

3. 그런데 무엇부터 시작해야 할까요

4. Legacy 라는 것이 있습니다

5. - 예시 -
며칠 일이 있어서 신입 사원들이
설계하는 것을 보지 못하고 금요일 업무
회의 시간에 들어갔습니다.
제가 회의에 들어 갔을 때 마침 고참
설계자가 신입 사원들이 설계한 것을 잠깐
체크했는데요, 신입사원이 시킨 일을
제대로 하지 못했는지 고참 설계자가 화를
냈습니다.

6. - 예시 -
이 구멍을 이렇게 크게 뚫으면 어떻게 해?
이 구멍이 뭔지나 알어?
환기구 아닌가요?
환기구 맞는데, 이걸 무작정 이렇게 크게
뚫으면 어떻게 해!
구멍이 크면 열이 더 잘 빠져 나갈 것
같아서요.

7. - 예시 -
구멍이 크면 열이야 잘 빠져 나가겠지,
하지만 얘들이 그 구멍으로 젓가락이라도
집어 넣어서 감전이라도 되면 어떻게 할래?
……
도면만 그릴 생각하지 말고, 선배들이
어떻게 설계했는지 좀 보라고.

8. - 예시 -
우리 선배들이 오랜 시간을 들여서 만든
산출물, 설계나 코드 아니면 요구사항이든,
이런 것들을 흔히 레가시(legacy), 즉
유산이라고 부릅니다...
선배들이 만들어 놓은 레가시를 무시하고
제로 베이스에서 시작한다는 것은,
선배들이 경험한 실패를 다시 반복한다는
뜻일 수 있습니다.
- Talk with Hani "레가시의 저주?" 중에서

9. 게임 디자인도 마찬가지 입니다
창작은 순수하게 게임 디자이너의
역할이지만
다른 게임들을 리서치 함으로해서
개발 과정에서 벌어질 수 있는 시행착오를
줄일 수 있습니다

10. 리서치는 베끼기가 아닙니다
다양한 게임의 사례를 찾아보고
자신의 게임에 맞게 적용하는 것입니다
삽질을 줄이자는 것이 목표인 것이죠

11. 리서치의 형태는 다양합니다
기본적인 움직임도 있고
공격 기술도 있고
심지어 상점이나 도전과제
같은 것도 있습니다

12. 리서치의 대상도 다양합니다
같은 장르의 것은 물론이고
다른 장르에서라도 도움될 만한 것은
모두 리서치 대상이 될 수 있습니다

13. 리서치를 할 때 주의할 점은
3가지가 있습니다
1. 최대한 다양한 게임을 리서치 할 것
2. 리서치한 자료를 쌓아둘 것
3. 리서치한 자료를 자기 것으로 만들 것

14. 리서치를 할 때 주의할 점은
3가지가 있습니다
1. 최대한 다양한 게임을 리서치 할 것
2. 리서치한 자료를 쌓아둘 것
3. 리서치한 자료를 자기 것으로 만들 것

15. 현재 만들고 있는 게임도
후속작의 기준에 보면
하나의 리서치 대상입니다
따라서 지금 만들고 있는 게임에 대한
문서는 항상 남겨둘 필요가 있습니다

16. 만들고자 하는 게임에 대한
리서치를 하였다면
이제 본격적으로 디자인을 할 차례입니다

17. 그런데 디자인을 어떻게 해야 할까요

18. 만일 여러분이 아래와 같은 문서를 써서
작업자에게 전달했다고 합시다

19. 그러면 아마 작업자들은
이렇게 말 할 것입니다
"이걸로 뭘 어쩌라고?"

20. 그래서 이번엔 아래와 같은 문서를 써서
작업자에게 전달했다고 합시다

21. 그러면 아마 작업자들은
이렇게 말 할 것입니다
"그래서 뭘 만들겠다는 건데?"

22. 그래서 저는 일단 게임 디자인을
두 가지 레이어로 나눠서 합니다

23. 하나는 디자인의 의도를
이해시킬 수 있는 것이고
다른 하나는 세부적인 구현에 대한
내용을 정리한 것 입니다

24. 의도를 정리한 내용은 해당 작업자가 아닌
팀의 다른 구성원이 보아도
알 수 있는 정도의 내용 만을 담습니다
작업자가 아니더라도
게임이 만들어지는 과정은 알아야 하니까요
저는 이것을 인터랙션 디자인(Interaction
Design) 단계라 부릅니다

25. 인터랙션 디자인 단계에서는
디자이너의 의도를 작업자가 쉽게 이해할 수
있는 것에 초점을 맞춥니다

26. 그런데 문자라는 것은
추상화된 기호이기 때문에
아무리 문서를 잘 써도 받아들이는 사람의
맥락에 따라 의미가 달라질 수 있습니다

27. 반면 이미지나 동영상은
실체화된 형상이기 때문에
보는 즉시 바로 이해 가능합니다

28. 글로만 가득찬 문서를 던져 주는 것보다
이미지나 동영상을 보여주고
말과 몸짓으로 추가적인 설명을 하는 편이
훨씬 빠르고 분명합니다
그렇게 하면 작업자는
문서를 이해하기 위한 별도의 시간을 들일
필요 없이 빠르게 의도를 캐치하여 작업할
수 있습니다

29. 물론 이 이야기는 문서를 쓰지 말라는 것이
아닙니다
글보다는 이미지와 동영상으로 문서를
구성하고, 너무 세세한 영역은 어렵게
서술하는 것보다 직접 얼굴을 맞대고
설명하는 것이 효율적이라는 이야기입니다

30. 구체적인 동작 방식을 정리한 내용은
의도를 이해한 작업자가
실제 작업하면서 알아야 할 내용을
담습니다
의도만 가지고서는 구체적인 구현 단계에서
세세한 영역까지 알 수는 없으니까요
저는 이것을 시스템 디자인(System Design)
단계라 부릅니다

31. 시스템 디자인 단계에서는
실제 작업시에 알아야 할 내용을 정리하는
것에 초점을 맞춥니다

32. 예컨대 밸런싱 공식이라든가
실제적인 테이블, 요소들 간의 관계도, 예외
상황 처리 등에 대한 내용을 정리합니다

33. 한 번에 완벽한 밸런싱을 한다거나
모든 예외 상황에 대한 처리를 예측하기는
매우 어렵기 때문에
의도가 바뀌지 않는 한 변할 일 없는
인터랙션 디자인 단계와 달리
시스템 디자인은 개발 과정 중에 생기는
변화에 따라 수시로 변하게 됩니다
따라서 개발 중 변화가 발생하면
항상 즉시적인 업데이트를 해야 합니다

34. 의도를 전달하는 인터랙션 디자인을
기획안에 비유한다면
세세한 내용을 담고 있는 시스템 디자인은
백과사전이나 전화번호부와 비슷합니다
개발 하면서 필요한 내용을 찾아 볼 수
있어야 하고 변화된 내용은 항상 최신으로
업데이트 되어야 하기 때문입니다

35. 시스템 디자인의 내용은
항상 바뀔 수 있음을 염두해 두어야 하고
변화 되는 내용을 기록해 두었다가
필요할 때 찾아볼 수 있게끔 한다고
생각해야 합니다

36. 또한 변경되기 이전의 내용을 항상
남겨두어
어떻게 디자인이 변화 왔는지에 대한
히스토리를 기록해 두고 추적할 수 있도록
해야 합니다

37. 디자인을 두 번으로 나누긴 했지만
저는 좀 더 나은 디자인을 위해
두 디자인 사이에
하나의 단계를 더 만들었습니다

38. 저는 그것을
디자인 리뷰(Design Review)라 부릅니다

39. 디자인 리뷰는 디자이너가 의도를 정리한
인터랙션 디자인을
전체 팀원이나 관련 작업자들에게
브리핑하면서 리뷰를 받는 것을 말합니다

40. 디자인 리뷰는 디자인이 잘 되고 못 되고를
평가받는 시간이 아닙니다
디자인 리뷰는 작업자들의 아이디어를
수렴하고, 개발 상의 어려움에 대한
해결책을 찾는 시간입니다

41. 디자인 리뷰를 통해
게임은 디자이너의 단독 의견이 아닌
개발팀 모두가 지향하는 방향으로
나아갈 수 있습니다

42. 또한 자신의 디자인에 대한
피드백을 수렴하는 디자인 리뷰는
디자이너의 역량을 증진 시키는데도
밑거름이 될 수 있습니다

43. 설명 하는데 순서가 엉망이었으니
마지막으로 정리하겠습니다

44. 1. 아이디어가 있다면 정제하여 컨셉화 한다
2. 프로토타입을 통해 컨셉을 증명한다 - POC

45. 3. 디자인에 들어가기 앞서 리서치를 한다
4. 의도를 전달 하기 위해 인터랙션 디자인을
한다

46. 5. 디자인 리뷰를 통해 의견을 수렴하고
디자인을 수정한다
6. 실제 개발을 위한 시스템 디자인을 한다

47. 7. 개발이 완료될 때까지
변경 되는 사항을 즉시 업데이트 하고
변경된 사항에 대한 히스토리를 남겨둔다

48. The End

49. Your feedback please
suyeongpark@live.com
http://suyeongpark.net
http://www.facebook.com/suyeong.park