glekang.com
my life, but a game
SEARCH BLOG | TAGS

[글강, 2007/04/27 16:43, Game]
한 손에는 로직을, 한 손에는 스키마를 들고 게임에 어떻게 접근할 것인가?

하지만 얼핏 보기에는 게임을 굳이 이렇게 2가지 개념으로 쪼개는 것이 쓰잘데기 없는 개똥 철학처럼 보이기도 한다. 특히나 유저 입장에서는 하등 쓸모가 없는 분류랄까?

당연한 일이다. 유저가 접하는 것은 이미 로직과 스키마가 결합된 최종 단계의 결과물이니까, 이 녀석을 애써 거꾸로 다시 분리해서 생각하려 드는 것은 오히려 더 힘들 뿐이다.

하지만... 아직 결과물이 나오지 않은 개발 단계에서, 개발자에게는 이러한 개념의 분리가 매우매우매우매우매우매우 중요하다. (특히 기획자라면 이걸 잘 쪼개서 역기획서를 작성할 수도 있어야 한다)



개발을 진행 중인 상태에서 이 둘을 분리하지 못하는 경우... 다음과 같은 대환란이 벌어지게 되나니...

게임을 개발하던 도중... 파티 플레이 내에서 각 클래스에게 역할을 분담시킨다고 가정해보자.

현재 이 게임에는 8개의 클래스가 존재하는데, 7개 클래스에는 적절한 역할 분배가 이루어져 있는 상태이고 오직 힐러 역할만이 남아있는 상태이다. 남겨진 1개 클래스에 힐러 역할을 주면 깔끔하게 해결될 것 같은데...

문제는 남아 있는 클래스가 네크로맨서Necromancer라는 점이다. 시체를 일으키고, 온갖 사악한 주술을 사용하는 네크로맨서가 힐러를 한다? ... 그래도 될까?

개발자A : 네크로맨서한테 힐러 역할을 줄 수는 없어! 절대로! 영 이상하잖아! 그러니까 다른 7개 클래스에게 할당되었던 역할을 전면 재조정하자!

개발자B : 네크로맨서가 힐링을 하는게 뭐 어때서? 난 별로 이상하지 않은데? 그냥 얘한테 힐러 역할을 주자!

개발자A : 영 이상하잖아! 안돼!

개발자B : 뭐가 이상하다는거야! 난 괜찮아 보이는데!

개발자A : %)($#&)&$#)@&$)!!!

개발자B : @#()@*$)(@#$(&&($!!!

OK! 거기까지! 이 싸움은 결코 끝나지 않는다. 왜? 정답이 없으니까.

이 상황에서 개발자A의 생각에 동조해서 '그래 좀 이상하지'라고 생각하고 있다거나, 개발자B의 생각에 동조해서 '뭐 어떻게든 네크로맨서 힐러를 만들 수도 있을거 같은데?'라고 생각하는 사람이 있다면... 낚이셨슴미다 파닥파닥.

예문에 나와 있는 개발자들의 대화는 완전히 잘못되어 있는 것이기 때문이다.

로직과 스키마가 혼용되어, 로직의 문제에 스키마가 끼어들고, 반론의 근거로 사용되고 있다. 즉 애초에 제기된 이슈는 로직적으로 결론을 내야 하는 부분인데, 정작 논의는 스키마의 차원에서 진행되고 있으니... 애초에 핀트가 어긋나 있는 것이다.

더구나 스키마에는 정답이 없다. 이것을 가지고 '옳다'와 '그르다'를 가리려 들면... 끝이 없다. 네크로맨서가 힐링을 하면 이상하다고 생각하는가? 나는 그렇지 않다고 생각한다. 내 생각에 동조하는가? 나는 이상하다고 생각한다. 정답? 일관성? 그딴건 스키마의 세계에서는 없다.

그러므로... 밑줄 쫙. 개발자는 로직을 먼저 생각하고, 스키마를 나중에 덧씌운다.

파티 플레이 패턴을 구성하기 위하여 8개 클래스 내에 다양한 역할을 분배하는 것은 전적으로 로직의 문제이다.

만약 8개 클래스를 A, B, C, D, E, F, G, H라고 추상화 해버린다면, A ~ G에 역할 분배를 마치고 마지막으로 남겨진 역할인 힐러를 H 클래스에게 할당하는 데에 아무런 문제가 없다. 즉 로직의 차원에서 정답은 이미 나와 있는 상태이다.

'하지만 남겨진 H 클래스가 네크로맨서인데...?' 라고 의문을 제기하면 다시 대환란으로 돌아갈 뿐. 애초에 개별 클래스에 역할을 분배하지도 않고, 즉 로직적인 체계를 정립해놓지도 않은 상태에서 클래스에 네크로맨서라는 구체적인 스키마를 덧씌운 것 자체가 문제인 것이다.

개발자는 로직을 먼저 생각하고, 스키마를 나중에 덧씌운다.

로직은 추상적 차원에서 이루어지는 논리의 문제이므로, 여기에서는 스키마를 완전히 배제하고 생각해야 한다. 즉 이 때 클래스 8개는 A, B, C, D, E, F, G, H여야 하는 것이다. 여기에 어줍잖게 'A는 전사이지 않을까...?' 뭐 이런 생각을 하는 순간, 수만의 정의와 수만의 편견과 수만의 로망에 의해 모든게 망가진다.

A, B, C, D, E, F, G, H로 놓고 모든 역할 분배를 마쳤다면, 즉 로직적 체계를 다 세웠다면... 스키마는 그 때부터 덧씌우는 것이다. H 클래스에 힐러 역할이 주어졌는가? 그럼 H 클래스에 프리스트Priest라는 스키마를 씌우면 적절할 것이다. 아 F 클래스에게는 디버퍼Debuffer와 도터DOTer의 역할이 주어졌는가? 그 녀석이 네크로맨서를 하면 적절하겠구나.

아 프리스트가 힐링을 하고, 네크로맨서가 디버퍼를 하는게 마음에 들지 않는다고? 이미 로직은 결정되어 있으니 스키마는 아무래도 좋다. A, B, C, D, E, F, G, H에 마음껏 적절한 클래스를 배분하시압.

(물론 세상일이 이렇게 간단하지는 아니하야 로직과 스키마가 깔끔하게 분리되지 않는 경우도 발생할 수 있으며, 실제로 혼용될 수밖에 없는 경우도 생기지만... 그건 예외적 상황. 여기에서 이야기하는 분리는 기초의 문제이다. Basic~ Basic~)



정리해 보자면 다음과 같다.

개발자는 반드시 로직과 스키마를 분리하여 생각할 줄 알아야 한다. 즉 추상적 차원에서의 문제와 현실적 차원에서의 문제를 분리하고, 생각을 이원화할 수 있어야 한다. 그리고 일단 분리된 개념은 서로의 영역을 침범하지 말아야 한다.

개발은 반드시 로직이 선행, 스키마가 후행되는 형태로 이루어져야 한다. 로직에는 정답이 있지만, 스키마에는 정답이 없다. 정답이 없는 것을 미리 결정해 놓은 후에, 거기에 규칙을 거꾸로 짜맞추는 것은 어불성설. 반드시 정답을 미리 정한 후에, 그 정답을 어떻게 하면 예쁘게 꾸밀 수 있을 것인지를 고민해야 한다.

즉...

프레임을 먼저 구상하고 외부 장갑을 덧씌워야 한다. 만약 외부 장갑을 먼저 만들고, 거기에 프레임을 맞춘다면...? 겉으로 보기에는 삐까번쩍한 외양이 나올 수도 있다. 하지만 가동성은 포기해야 할 것이다.

문제는 우리가 가만히 세워 놓고 감상하기 위한 주석 피규어를 원하는 것이 아니라는 점이다. 가동성과 외양이라는 두마리 토끼를 모두 잡을 수 있는... 동전줍기 자세같은 것을 잡아놓고 낄낄댈 수 있는... 사용자와의 interaction이 가능한 프라모델을 만들어야 - 게임을 개발해야 할 것이 아닌가?



그럼에도 불구하고 -_-a

인간이란 로직보다는 스키마에 먼저 꽂히는 동물인지라... 모든 것을 추상의 차원에서만 생각해야 한다는 것은 생각만큼 쉬운 일은 아니다.

무엇보다도 로망은? 내 로망은 어떻게 되는거야?!

...라는 외침에 대한 대답은 다음 기회에~

Trackback Address :: http://glekang.com/trackback/281
가람해무 | 2007/04/27 17:10 | PERMALINK | EDIT/DEL | REPLY
에 그러니까...어. 음....(=ㅅ=)
그러니까 결론은 8번째를 네크로맨서로 만든 넘 나와!!! 라는 거죠? +_+ (농담)

어찌 보면 로직과 스키마의 절차는 지극히 상식적인 것 같기도 한데, 이런 실수가 생기는 것은 분업이 제대로 이루어지지 않아서거나 너무 많은 분업이 이루어졌기 때문이라는 가정과 어느 정도 연관이 있을까용?
저는 최근에 로직이 좋아지기 시작했지만요. ㅎㅎ
글강 | 2007/04/27 17:24 | PERMALINK | EDIT/DEL
결론은 '네크로맨서는 독술에 능하고, 자고로 훌륭한 독술사는 언제나 훌륭한 의사였으니, 따라서 네크로맨서도 힐링을 아주 잘 할 수 있다'입니다 ㄲㄲㄲ

로직과 스키마의 구분은 분명 상식입니다만... 충돌이 생기는 것은 스키마가 개발자의 머리를 꽉 쥐고 놓아주지 않는 경우이거나, 분업시 서로에 대한 신뢰가 미약한 경우에 종종 발생하는 듯 싶습니다.

스키마가 개발자의 머리를 꽉 쥐고 놓아주지 않는 경우에 대해서는...
FieldKim님의 "D&D의 함정. Gathering과 Synchronization (1)" 이 포스트를 참고하시면 좋을 듯 싶습니다 :)

http://fieldkim.egloos.com/3134889
손님 | 2007/04/27 18:22 | PERMALINK | EDIT/DEL | REPLY
워~ 우연히 왔다가 깨달음을 얻고 갑니다.
감사드립니다.
글강 | 2007/04/27 18:44 | PERMALINK | EDIT/DEL
어이쿠 ; 깨달음이라고 하실만한 내용은 아닙니다 ^^;
감사합니다 :)
정상택 | 2007/04/27 19:05 | PERMALINK | EDIT/DEL | REPLY
로직과 스키마라는 것이
시스템과 컨텐츠를 뜻하는 것인가요?
즉 시스템에서는 문제가 없는데
이미 생각했던 스토리라던가, 판타지 직업의 이미지때문에 고민이 생길경우는
시스템을 뜯어 고치는 것이 아닌 스토리를 뒤엎는 것이 정답이라는 것 같은데
제가 이해를 제대로 했는지 궁금합니다.
글강 | 2007/04/27 19:27 | PERMALINK | EDIT/DEL
이해하신 바가 맞습니다.
다만 애초에 스토리나 직업의 이미지같은 것을 생각하기 전에 시스템을 먼저 갖추어놓고 나서야 거기 짜맞추는 쪽이 더 낫다고 생각합니다. 뭐 이미 스토리나 직업 이미지를 결정해버린 상태라면, 그 쪽을 갈아엎는 것이 정답이 맞다고 생각하고요.
아울러 로직 / 스키마 개념을 조금 더 모호하게 포괄적인 것으로 부풀리면 보다 미세한 개별 스펙 단위에까지 적용이 가능합니다 :)
Bums | 2007/04/27 21:11 | PERMALINK | EDIT/DEL | REPLY
추상성에 대한 이야기를 보니 크리스 크로보드의 저서에서 '목적부터 설계하라' 라는 애기가 떠오르네요. 흔히 게임을 만들면 소재와 시나리오가 잡힌다고 하지만 크리스 크로포드도(제 개인적으로도) 게임 플레이를 하면서 느끼게 되는 추상적 감각을 먼저 잡는게 맞다고 생각하거든요. 같은 맥락에서 스키마보단 재미 로직의 실체화가 먼저 필요하겠네요. 실 개발에도 이런 추상적 접근을 합니다만, 쉽지 않은 애기라 그런지 윗분들이 보고 받을때 햇갈려하더군요. '이 게임은 복합적 팀 플레이에 의한 개체의 창조를 목적으로 합니다' 라고 하면 '그게 뭐야? 누가 뭘해서 뭘 만든다는건데?' 라는 답이... ㅜㅜ
Bums | 2007/04/27 21:16 | PERMALINK | EDIT/DEL | REPLY
개인적으론 말씀하신 로직중심적인 사고를 하는지라 이미지컨셉을 잡을때도 로직에 어긋나지 않다면 무엇이든 상관없다는 주의입니다(퀄리티가 일정선 이상이란 전제하에) 만약 수동적 역활을 하는 캐릭터a는 부끄러움 많은 소녀의 이미지를 충분히 전달할 수 있다면 전 더이상 신경쓰지 않지만, 가끔 로망에 불타시는 분들은 안경! 절대영역! 촌! 모에!? 등을 외치시기도 하더라구요. ㅎㅎ 아 좋은글 잘봤습니다. 이런 저런 과거들이 떠오르네요 홋홋
글강 | 2007/04/28 06:07 | PERMALINK | EDIT/DEL
윗분들께 설명할 때에는 로직은 저 멀리 제껴두고 스키마로 승부하는거죠! (그래야만 먹히는 상황이 있다는 것 자체가 좀 서글프지만)

음 사실 본문에서는 좀 의도적으로 스키마의 비중을 축소시켜버린 감이 없잖습니다만... 사실상 결과물을 놓고 봤을 때의 비중은 로직이나 스키마나 50:50이겠죠 :)

뭐 이런 부분은 현업 계신 분들이라면 알아서 이해하셨으리라 믿고 ㅌㅌㅌ
fieldkim | 2007/04/27 21:59 | PERMALINK | EDIT/DEL | REPLY
우연치 않게도, 제 최근 포스트와 주제가 겹치게 되는 부분이 많군요 :)
(당연히, 저도 글강님의 포스트에 크게 공감합니다.)

게임 로직이 명확하게 '플레이어가 어떠한 게임 플레이를 경험하게 되는가'를 확정했다면 기실 텍스트만 돌아다니는 게임으로 만든다 하더라도 결과물은 보통 대동소이 하죠. (나머지는 그야말로 그래픽 디자이너 & 엔진 프로그래머의 몫이라고 생각합니다.)

충분한 상상력을 지니고 있는 사람이라면 극도로 허접한 그래픽만으로 만들어져 있는 게임을 보고도 상황을 알아서 맞출 수가 있겠지요.

어차피 그 정도의 마음의 눈을 가지지 못한 사람이라면 어차피 시나리오든 뭐로든 많은 사람들에게 어필한다는 건 어차피 무리일 것이니, 근거를 가지고 만들어진 '로직'에 변형을 요구하는 건 주제 넘은 짓이라고 봅니다. lol
글강 | 2007/04/28 06:10 | PERMALINK | EDIT/DEL
하지만 게임은 혼자 만드는 것이 아니기에... 마음의 눈이 없는 개발자도 있게 마련이고, 그러면 이러저러한 소모적 논쟁도 생기고 뭐 그렇게 되곤 하죠 ;ㅁ;

그래도 소모적 논쟁을 몇번 거치고 나면 점점 감잡아 나가는 것이 또 개발자이니 그나마 다행이겠죠 ㅎㅎㅎ
야근압박 | 2007/04/28 12:22 | PERMALINK | EDIT/DEL | REPLY
글의 전체 내용에 100% 동감하지만 단 한줄, '스키마가 선행되면 X된다'라는 문장은 조금 다르게 받아들이고 싶네요. '스키마가 선행되면 개발이 불가능하다'라는 뜻이었다면요. 저도 스키마가 선행됐을때의 그 엄청난 고충을 경험해봐서 무엇을 말씀하시고자 하시는지는 팍팍 와닿습니다. 허나 절대적인건 아니라고 생각해요. 마치 귀납법과 연역법의 차이랄까요? 대부분이 쓰는 방법인 로직을 선행하는 방식의 경우 연역법과 비슷하다고 보는데요. 이 로직이라는것이 일반적으로 경험에 의거해 조직된 로직인 경우가 대부분이므로 기존에 존재하던 '개념'의 재정렬이나 그로부터의 추론 형태로 이루어지는 경우가 많고 결국 같은 '개념'으로부터 얻어지는 답(스키마)은 비슷한 형태가 나올 수 밖에 없는 작업 방식이죠. 새로움 또는 독창성을 추구해야하는 우리네 입장상 이런점이 로직선행(연역법)의 난점이 아닐까 싶네요. 반대로 스키마선행은 귀납법과 비슷하다고 보는데 일단 전제하고 싶은점은 로직선행 보다 훨씬 더 어려운 방식이라고 봅니다. 기존에 존재하던 '로직'(경험)으로부터의 추론이 아니라 새로운 '개념 또는 스키마'를 창안하고 거기로 부터 일반적 납득이 가능한 로직을 얻어내는 방식이기 때문이고 이는 전자보다 추상적인 형태를 갖추고 있기 때문인것 같습니다. 설명을 위해서였겠지만 예를드신 '스키마 선행 에피소드'는 창안하는 과정이 빠져있기 때문에 왜곡되어 보이는것 같습니다. 정리하자면 이렇습니다. -'스키마 선행'은 일반적으로 쓰이는 '로직 선행' 보다 매우 어려운 작업 방식이지만 절대 불가능해서 기피해야 할 작업방식은 아니며 오히려 새로움 또는 독창성 추구에는 '스키마 선행'이 더 유리하거나 맞는 작업방식이라는것-입니다. 독창적인 게임이 밥먹여주는것(성공을 보장)은 아니기에 두 작업방식의 우위를 따질 필요는 없겠지만 게임사에 기록될 독창적인 게임 하나 내놓아보는게 꿈인 개발자라면 '스키마 선행'을 불가능한 방법으로 치부하면 안된다고 생각합니다. 뭐 '로직 선행'만 잘해도 잘먹고 잘사는 즐리자드도 있지만 말입니다.
글강 | 2007/04/28 19:56 | PERMALINK | EDIT/DEL
개념에 대한 접근이 조금 다른 듯 싶습니다 :)

언급하신 내용 중 '새로운 개념 또는 스키마의 창안'이라 하신 부분은, 제 생각에 아무래도 새로운 방식의 게임 규칙 착상을 언급하신 것이 아닐까 싶은데요... 저는 이 부분 역시 스키마가 아니라 로직의 범주로 들어가게 되고, 이를 선행하는 것 또한 로직 선행이 아닌가 싶습니다.

괴혼을 예로 들어본다면... '공을 굴리고, 공보다 작은 물체는 공에 붙어서, 공이 계속 커진다'라는 참신한(현실 세계에서는 겨울마다 꼬마들이 눈덩이로 하는 짓이지만) 로직이 선행되었고, 그 로직에 맞추어 왕자님과 아바마마의 스키마가 붙은 것이라 할 수 있겠죠.

물론 로직과 스키마가 깔끔하게 떨어지는 것은 아니기에 =_= 어중간하게 mix되어서 같이 이야기가 진행될 수밖에 없는 경우는 많이 있으며... 소모전의 악몽이 시작되죠 oTL 역시 저로서는 기피 대상입니다 ㅎㅎㅎ
엄훠나 | 2007/04/29 17:36 | PERMALINK | EDIT/DEL | REPLY
글강님 글엔 정말 지식인 분들의 답변이 넘치네용,
저같으면 이런 글 보면 "흐으응" 하고 말겟지만용,[무지해서 잘 알아 들을수가 없음;]
글강님 글을 이해하고 거기에 대해 같이 생각하고 그런 생각을 공유하는 분들이 일케나 많으시다닝,,
부러워용 ,
글강 | 2007/04/29 18:38 | PERMALINK | EDIT/DEL
으... 정작 저는 도망치고 싶은 심정이 한량없죠 ㅋㅋㅋ
정시퇴근(이글루) | 2007/04/30 12:22 | PERMALINK | EDIT/DEL | REPLY
다음편도 기대하고 있습니다.

잘 공부하고 갑니다. ^^

감사합니다.
글강 | 2007/04/30 13:51 | PERMALINK | EDIT/DEL
감사합니다 :)
★조조 | 2007/08/19 20:56 | PERMALINK | EDIT/DEL | REPLY
워...ㅋㅋㅋ
다른책 찾아봐도 어렵게 설명한걸 형이 예시 들어가며 로직과 스키마 설명해둔게 훨씬 쉽네용 ㅋㅋ
정리가 되는듯한 ㅋㅋ 저도 깨달음을 얻고 갑니다 ㅋㅋ
글강 | 2007/08/20 19:12 | PERMALINK | EDIT/DEL
엄. 이런 내용 나오는 책 좀 알려주3.
Name
Password / Secret
Homepage
◀ PREV : [1] : ... [67] : [68] : [69] : [70] : [71] : [72] : [73] : [74] : [75] : ... [275] : NEXT ▶






BLOG main image

«   2010/08   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

전체 (275)
Life (154)
Game (121)

넹~ ㅇㅅㅇ
글강 07/27

한마디 - 잠언箴言
고어핀드의 망상천국 2009
왕멀의 생각
wangmul's me2DAY 2009
새해 덕담 - 진정한 위로
고어핀드의 망상천국 2009
실패한 스쿼드 게임 '블..
게임을 만드는 한사람의.. 2008
한마디 첨언하자면.
하이얼레인의 얼음집'▽.. 2008

SharedSHELL

Tattertools

rss