안녕하세요. 전에는 업무 중 일이 안되서 잠시 들러보던 중에 글을 쓴지라 오랜만에 쓴 글을 제대로 맺지도 못하고 to be continued 선언을 해버렸습니다.

이 점 나름대로 양해를 구하고요. 일단 시작해버린 말, 맺음을 지어보도록 하겠습니다.

지난 시간의 말의 핵심은 '게임의 규모가 커진다는 것은 이처럼 'factor'가 많아진다는 것을 의미하고 그 개별 factor와 factor가 치밀하게 연결되면 될 수록 게임의 완성도가 높아진다.' 라는 말로 대변할 수 있겠군요. 이 역시 지난 시간에 썼던 문장입니다.

오늘 읽은 글 중에 꽤 흥미로운 글이 하나 있었습니다. Mindmap을 이용하여 요소들을 나열한 글이 있더군요. 그 마인드 맵의 퀄리티와 완성도를 떠나 그런 시도 자체는 굉장히 좋은 시도입니다. 일단 자신의 게임에 어떤 요소가 있는 지를 하나하나 생각해볼 수 있다는 장점을 가지고 있지요.

다만, 마인드 매핑의 장점은 때로는 단점이 되어버립니다. 왜냐면 마인드 매핑의 경우 카타고리에 factor들을 나열하는 방식으로 아이디어를 늘어놓게 되어버리는 데 자칫 잘못하면 그 양을 감당못하게 되는 케이스가 벌어질 가능성도 있습니다.

마인드 매핑의 단계 이전에 사실 각 큰 카타고리 별 연관성을 규정하는 단계가 필요하다고 저는 생각합니다. 마인드 매핑으로 생각해놓은 요소가 어떤 다른 카타고리에 어떤 요소에 연결될 것인지를 고민하기 위해서 그러하겠지요.

Structure라는 말은 사실은 건축 언어입니다. 때문에 위를 건축이라는 것에 맞게 설명을 해보겠습니다. 성의 윤곽을 결정짓는데에 '어떤 파츠에 어떤 부품이 필요하다'라라는 것을 늘어놓는 것이 마인드 매핑이라고 할 수 있습니다. 그러나 '어떤 성이 될 것인가?'는 그 파츠를 조립한 결과에 따라서 달라질 것입니다. 때론 그런 생각없이 파츠부터 만들고 조립한 성이 화려한 로코코 양식의 성이나 중후한 고딕의 성이 될 수도 있습니다만 '가고일과 천사상이 공존하는 기괴한 암흑성'이 될 가능성도 있습니다. 제작하려고 했던 의도와 벗어난다는 소리겠지요.

따라서 '어떤 모양의 어떤 양식의 성이 될 것인지'를 마인드 매핑 이전에 생각할 필요가 있습니다. 각 파츠의 연관성을 묶어주는 요소가 무엇인가? 그것이 아마 게임에 있어서는 메인 컨셉이 되겠지요. 미카미 신지가 바이오해저드를 만들 때 제일 먼저 강조했던 것이 '그것이 공포스러운가?'였다는 점이 이를 잘 말해주고 있습니다.

대충 개념의 설명은 여기까지로 하고 개발에 관련된 부분으로 넘어가 보겠습니다.

프로그램을 대충이나마 공부하신 분이나 개발에 관심이 많으신 분들은 아마도 EDP라는 단어를 들어보셨을 지도 모르겠습니다.

Event Driven Programming, 즉 이벤트 중심의 프로그래밍이란 단어인데 이 단어가 전 시간에도 이야기했던 factor와 factor의 연관성에 대해서 잘 설명해주고 있습니다.

흔히 프로그래밍에 본격적으로 들어가기 전에 flow chart에 대해 배우시고 들어갈 겁니다.

시작이 주어진 형태에서 조건들의 판별로 인해 결과를 판정하는 형태이지요. 그러나, 이 형태의 플로우 차트는 시스템 구성에 있어서 한계를 불러일으킵니다.

1. 복잡한 시스템 구성이 필요할 때 다양한 조건문을 나열할 것을 요구한다.

2. 판단의 변동이 잦은 형태의 시스템 구성에 적합하지 않다.

3. LOOP, 즉 반복 순환이 필요한 구조를 설명하기에 적합하지 않다.

이를 해결해주는 개념 중에 하나를 공대에서 배울 수 있습니다.

예를 들자면 엘리베이터의 액션을 Flow chart로 구성한다고 생각합시다. 솔직히 저도 이걸 누가 시킨다면 손 놓고 포기하는 편이 빠르다고 생각합니다. 모 층수로 올라가고 있는데 다른 사람이 중간에 또 버튼을 누르거나 엘리베이터 안과 밖에서 '여기로 오세요~'라는 유혹의 호출이 떨어지는 판국을 if~ then~ else~로 설명하라니요.

이를 Event 중심적으로 설명해보겠습니다.

엘리베이터 자체가 가지는 '상태'는 정지하고 있다, 위로 이동 중이다(목표는 x층), 내려가고 있다(목표는 x층), 올라가기가 예약되었다(목표는 x층), 내려가기가 예약되었다(목표는 x층) 등이 있을 것이고 엘리베이터의 문이 열려야 엘리베이터에 사람이 타겠지요. 그러니 문이 가지는 상태는 열린다와 닫힌다가 존재할 것입니다.

상태를 변화시키기 위한 조건으로는 간단하게는 아시다시피 y층을 누른다가 되겠습니다.

그러나 y층을 누른다고 엘리베이터가 그 층으로 그냥 이동해버리면 y>x라는 가정하에 x층으로 내려가던 사람이 정지의 중력과 상승의 중력을 단시간에 경험해버리는 사태가 발생하겠지요.

거기에다가 여러 사람이 여러 층 수에서 버튼을 누를 수 있습니다. 때문에 '엘리베이터가 어떤 상태에 있을 때 y층이 입력되었다.' 라는 세부적인 조건이 필요하게 됩니다.

이런 식으로 예를 들어보겠습니다. 엘리베이터가 위로 이동 중인데 x층으로 이동 중인 상황에서 a층을 지날 때 y층의 호출이 떨어졌을 때 x>a, x>y, y>a 인 상황이라면 x층으로 이동 중이던 엘리베이터는 x층에 도착하기 전에 y층에 멈출 것이고 y층에 멈춘 뒤에야 x층을 다음 목표로 설정하게 될 겁니다.

Flow chart의 형식에 따르자면 이를 표현할 때 "y층이 눌렸는가?" "x>a를 만족하는가?" "x>y를 만족하는가?" "y>a"를 만족하는 가를 따져서 'y = x (y를 목표 x로 만들어라)'라 규정짓겠지요.

그러나 간단히 [ y가 입력되었을 때 "x>a, x>y, y>a"를 만족하면 "x층을 목표로 이동 중" 이라는 상태 → "y층을 목표로 이동 중"이란 상태로 교체 ] 라는 문장으로 바꿀 수 있습니다.

만약 동일 상황에서 y<a 라면? 상태를 변경시킬 수 없는 이벤트는 구성에서 제외할 수 있습니다.

이것이 바로 공대에서 수학하는 개념 중에 하나로 자동화 시스템을 구성할 때 쓰이는 FSM이라는 모델입니다. 위에서는 조금 복잡한 예를 들었는데 간단히 설명해볼까요?

Current State -> Condition	State A	State B	State C
Condition X	...	...	...
Condition Y	...	State C	...
Condition Z	...	...	...

위는 위키피디아에서 슬쩍 훔쳐온 표입니다. 이를 말로 설명하면 다음과 같습니다.

"State B인 상태에서 Condition Y가 발생하거나 입력되면 State C로 상태를 변경하라."

이때 컨디션 Y는 (event a & event b)가 될 수도 있고 (event a or event b)도 될 수 있습니다.

즉 하나의 상태 변화를 위해서 한개의 조건(condition)만 필요한 건 아니겠지요.

이제 위의 엘리베이터 설명이 좀 더 이해하기 쉬워졌을까요? 그랬기를 빕니다.

아, 물론 FSM이 Flow chart보다 우위의 개념이라는 것은 아닙니다. 다만 사용처가 조금 다를 뿐이지요. 시작과 끝이 매우 명확한 구조라면 굳이 FSM을 쓸 필요는 없습니다. 오히려 이럴 때는 Flow chart가 나을 때가 있지요.

실제로 위와 같은 Event나 Conditon으로 구동되는 형태의 구조는 개별 System(=object)간의 의존도를 줄이면서 구성할 수 있다는 잇점이 있습니다. 개별 시스템을 구성한 뒤 나중에 모아보면 되니까요. 프로그램적으로도 객체 지향 프로그래밍, 즉 OOP에 비해서 EDP가 가질 수 있는 장점이지요.

(물론 OOP의 모듈에 대해서 이해하지 못하는 상황에서 EDP를 논한다는 건 좀 에러겠지만요. 프로그래머라면 모를까 기획자가 깊게 파들어가면 좋지만 그러지 않아도 괜찮겠지요. 거기까지 할 수 있으면 프로그래머하는 게 더 잘 먹고 잘 살 수 있으니까요.ㄷㄷ)

지난 시간에 추신으로 가방끈이 나름 중요하게 될 수 있다고 했는데 그렇습니다. 바로 저런 이유 때문이지요. 고등학교에서는 저 개념을 좀더 수식화하기 위해 미분 적분을 가르치지만 저 개념 자체를 가르쳐주지 않습니다. 오로지 대학교에서만 만날 수 있는 것이지요.

부끄럽게도 저도 역시 대학을 다닐 때 그다지 성적에 관심이 없는 사람이었고 그런 상태에서 업계에 들어왔습니다만 설마 저게 필요해지는 상황이 올 줄 어찌 알았겠습니까?

그런 점에서 공부 좀 더 해둘껄이란 후회도 드는 때가 많습니다.

업계에 들어와서 사부 한 명 모시고 새로 배웠으니 더욱 후회 막심이랄까요.

위와 같이 State들이 conditon으로 엮이고 엮여서 하나의 요소 Factor를 만들어내고 이 Factor와 Factor가 엮여서 하나의 System을 구성합니다. 그 System과 System이 묶이면 하나의 게임이 탄생하게 되지요. 거기까지 거쳐오는 길은 결코 쉬운 길은 아닙니다만 조금 더 철저해지려고 노력한다면 못 걸을 길은 아닙니다.

앞서 이야기했듯이 이 글을 쓰는 사람은 크리에이터라기엔 좀 부끄러운 사람입니다. 때문에 게임을 어떻게 재미있게 만들까라는 주제에 대해서는 할 이야기 거리가 참 부족해서 이런 이야기 밖에 드리질 못하겠군요.

사실 저도 기획을 하면서 늘상 느끼는 것 중에 하나가 '좀 더 나은 무언가가 내게 있다면'이란 것이지요. 이런 부족한 사람이 쓰는 글입니다만 기획을 지망하는 사람들에게 '좀 더 나은 무언가'가 되었다면 이런 글을 올렸다는 것에 의미를 부여할 수 있을 겁니다.

이미 FSM은 1970년대에 래슬리 램포트 박사가 직접 프로그래밍에 응용한 이래 계속해서 쓰이고 있는 개념입니다. 따라서 이 역시 어떻게보면 '구시대의 지식'이라고 볼 수도 있겠지요.

게임 업계의 역사는 짧지만 빠른 발전 속도를 보여주고 있습니다. 이는 다양한 방면에서의 지식이 쌓여있는 가운데서 게임이 그것들을 '응용'하여 개발되었기 때문에 가능하지 않았을까요?

그런 면에서 제가 짧은 지식이나마 좋은 지식을 여러분께 선사했기를 빕니다. 더 좋은 사람들이 이 업계에서 활약하고 제 다음 사람이 더 빨리 지식을 익히고 그 다음 사람은 그보다 더 빠른 시간 안에 그 사람의 수준이 될 수 있다면 게임 산업의 발전을 가속시킬 수 있을 거라 생각합니다.

저를 가르치신 분들이 저를 가르치셨을 때 아마 그런 마음으로 가르치셨을 겁니다.

아직은 그 마음에 제가 부응하고 있을런지는 잘 모르겠지만 말이지요.

저도 좀 더 공부하면서 서로 지식을 교환할 수 있는 장을 마련하도록 노력해보겠습니다.

다음에 뵙지요.

더 많은 사람이 게임이라는 악의 구렁텅이에 빠지길 기원하며 여기서 줄입니다.

P.S:

쓰다보니 나름대로 공대생은 게임 기획자하기 좋다라는 식이 되어버렸는데 그렇지 않습니다.

말 그대로 저같은 어중간한 사람이 있는 반면 반짝이는 아이디어로 도배한 크리에이터들도 있습니다.

사실 그쪽이야말로 좀 더 기획자스럽달까요. ㅎㅎ. 저는 그 쪽이 좀 더 부럽습니다.

구조를 설계하는 건 사실 코디네이트나 서포트에 가깝습니다. 완전히 자기 게임을 만들면 모를까 게임에 대한 욕심은 약간 죽이고 들어가야지요. 솔직히 기획자이기 때문에 그건 좀 쉽지 않습니다. ㅎㅎ. 반성 중.

한가지 더 이야기하자면 FSM은 좋은 도구입니다만 정형화된 스탠다드는 아닙니다. 그저 도구 중에 하나일 뿐이지요. 개별 기획의 목적에 맞는 다양한 도구들을 찾아내고 활용하는 것도 사실 기획자의 업무 중 하나입니다. 기획의 도구 중에 맥가이버 칼이란 건 없다고 생각하세요.

다만 기획자가 맥가이버 칼이 될 수는 있습니다. 체력만 잘 받쳐준다면 말이지요. ㅎㅎ