[글강, 2007/04/27 16:43, Game]
한 손에는 로직을, 한 손에는 스키마를 들고 게임에 어떻게 접근할 것인가?
하지만 얼핏 보기에는 게임을 굳이 이렇게 2가지 개념으로 쪼개는 것이 쓰잘데기 없는 개똥 철학처럼 보이기도 한다. 특히나 유저 입장에서는 하등 쓸모가 없는 분류랄까?
당연한 일이다. 유저가 접하는 것은 이미 로직과 스키마가 결합된 최종 단계의 결과물이니까, 이 녀석을 애써 거꾸로 다시 분리해서 생각하려 드는 것은 오히려 더 힘들 뿐이다.
하지만... 아직 결과물이 나오지 않은 개발 단계에서, 개발자에게는 이러한 개념의 분리가 매우매우매우매우매우매우 중요하다. (특히 기획자라면 이걸 잘 쪼개서 역기획서를 작성할 수도 있어야 한다)
개발을 진행 중인 상태에서 이 둘을 분리하지 못하는 경우... 다음과 같은 대환란이 벌어지게 되나니...
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
인간이란 로직보다는 스키마에 먼저 꽂히는 동물인지라... 모든 것을 추상의 차원에서만 생각해야 한다는 것은 생각만큼 쉬운 일은 아니다.
무엇보다도 로망은? 내 로망은 어떻게 되는거야?!
...라는 외침에 대한 대답은 다음 기회에~
하지만 얼핏 보기에는 게임을 굳이 이렇게 2가지 개념으로 쪼개는 것이 쓰잘데기 없는 개똥 철학처럼 보이기도 한다. 특히나 유저 입장에서는 하등 쓸모가 없는 분류랄까?
당연한 일이다. 유저가 접하는 것은 이미 로직과 스키마가 결합된 최종 단계의 결과물이니까, 이 녀석을 애써 거꾸로 다시 분리해서 생각하려 드는 것은 오히려 더 힘들 뿐이다.
하지만... 아직 결과물이 나오지 않은 개발 단계에서, 개발자에게는 이러한 개념의 분리가 매우매우매우매우매우매우 중요하다. (특히 기획자라면 이걸 잘 쪼개서 역기획서를 작성할 수도 있어야 한다)
개발을 진행 중인 상태에서 이 둘을 분리하지 못하는 경우... 다음과 같은 대환란이 벌어지게 되나니...
게임을 개발하던 도중... 파티 플레이 내에서 각 클래스에게 역할을 분담시킨다고 가정해보자.
현재 이 게임에는 8개의 클래스가 존재하는데, 7개 클래스에는 적절한 역할 분배가 이루어져 있는 상태이고 오직 힐러 역할만이 남아있는 상태이다. 남겨진 1개 클래스에 힐러 역할을 주면 깔끔하게 해결될 것 같은데...
문제는 남아 있는 클래스가 네크로맨서Necromancer라는 점이다. 시체를 일으키고, 온갖 사악한 주술을 사용하는 네크로맨서가 힐러를 한다? ... 그래도 될까?
개발자A : 네크로맨서한테 힐러 역할을 줄 수는 없어! 절대로! 영 이상하잖아! 그러니까 다른 7개 클래스에게 할당되었던 역할을 전면 재조정하자!
개발자B : 네크로맨서가 힐링을 하는게 뭐 어때서? 난 별로 이상하지 않은데? 그냥 얘한테 힐러 역할을 주자!
개발자B : 뭐가 이상하다는거야! 난 괜찮아 보이는데!
개발자A : %)($#&)&$#)@&$)!!!
개발자B : @#()@*$)(@#$(&&($!!!
현재 이 게임에는 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
|
















