'게임개발'에 해당되는 글 73건
[글강, 2009/04/10 21:04, Game]
팀 테스트는 계속됨미다 'ㅅ'
'아무리 생각해도 이게 핵심 문제인거 같은데 아리까리 거시기하네잉' 싶었던 부분이 역시나 핵심이었고, 물론 아직도 '으윽 이것도 핵심 문제같은데 이건 건드리기가 쵸큼 무섭'인 부분이 없지 않지만...
암튼 독립적이되 큼지막했던 문제들 좀 쳐냈으니 이제는 설레발을 칠 차례 'ㅅ'
이제 슬슬 보이기 시작하는 문제들은 단순한 버그나 리소스, 혹은 밸런싱의 범주를 벗어나기 시작한다.
즉 애초에 의도했던 '게임 플레이'가 예측대로 구성되지 못하는 문제... 흐억. 게임 디자인이 잘못됐어!!!
냅. 업ㅂ슴미다. 여기서 타협하면 망작 'ㅅ'
문제가 발생하고 있다는 현상은 명확하며, 해결하지 않는 이상 이 문제는 사라지지 않는다.
그런데 이 문제를 어떻게 해결해야 할는지... 그 최선의 방법은 명확히 보이지 않는다.
차선책이라 할만한 녀석은 보이는가?
뭐 최선이고 차선이고 아예 답이 안보인다면 이건 뭔가 애초에 근본적으로 잘못되었다는 것이 되므로 (...) 나도 모르겠다. 이런 경우에는 어떻게 해야 할까효 ㅋ
그르나 다행스럽게도 대부분의 경우... 최소한 차선책이라 할만한 녀석은 보이게 마련이다.
최선책이라고는 못하겠지만, 그래도 차선책 정도가 보인다면?
... 라고 생각할 시간에 그 차선책을 먼저 구현해보는 쪽이 낫다... 고 생각한다.
물론 그 차선책이라는 놈이 게임의 근간을 뒤흔들어 버린다든가 -_-a 구현하는 데에 무지막지한 코스트를 요구하는 놈이라면 쓸 수 업ㅂ는 방법임미다 냅.
하지만 완전히 막장으로 게임을 구성하지 않은 이상에야, 대부분의 경우 이미 구축된 기반 위에서의 수정 작업으로 커버가 되게 마련이고...
그러므로 '고민할 시간이 있다면 그 시간에 일단 그럴싸해 보이는 놈을 닥치고 구현해보는 쪽'이 어떻게든 더 낫지 않을까 싶다.
그 차선책을 구현해서 함 볼 수 있게 된다면...
이럴 수 있지 않을까 'ㅅ'
... 라지만 역시 시간이 모질라 흑흑
크런치는 끗나지 않는다 ㄱ-
'아무리 생각해도 이게 핵심 문제인거 같은데 아리까리 거시기하네잉' 싶었던 부분이 역시나 핵심이었고, 물론 아직도 '으윽 이것도 핵심 문제같은데 이건 건드리기가 쵸큼 무섭'인 부분이 없지 않지만...
암튼 독립적이되 큼지막했던 문제들 좀 쳐냈으니 이제는 설레발을 칠 차례 'ㅅ'
이제 슬슬 보이기 시작하는 문제들은 단순한 버그나 리소스, 혹은 밸런싱의 범주를 벗어나기 시작한다.
즉 애초에 의도했던 '게임 플레이'가 예측대로 구성되지 못하는 문제... 흐억. 게임 디자인이 잘못됐어!!!
아놔 이거 어쩌나효. 애초에 디자인 단계에서부터 재검토해야 할 듯 싶은데, 이미 만들어놓은 것이 아깝기도 하고, 수정 방향도 마땅히 보이지 않으니... 어찌어찌 대충대충 날로 먹으면서 넘어갈 수 있는 방법은 없을까효? (...)
냅. 업ㅂ슴미다. 여기서 타협하면 망작 'ㅅ'
문제가 발생하고 있다는 현상은 명확하며, 해결하지 않는 이상 이 문제는 사라지지 않는다.
그런데 이 문제를 어떻게 해결해야 할는지... 그 최선의 방법은 명확히 보이지 않는다.
차선책이라 할만한 녀석은 보이는가?
뭐 최선이고 차선이고 아예 답이 안보인다면 이건 뭔가 애초에 근본적으로 잘못되었다는 것이 되므로 (...) 나도 모르겠다. 이런 경우에는 어떻게 해야 할까효 ㅋ
그르나 다행스럽게도 대부분의 경우... 최소한 차선책이라 할만한 녀석은 보이게 마련이다.
최선책이라고는 못하겠지만, 그래도 차선책 정도가 보인다면?
더 좋은 방법이 있지 않을까? 최선책을 더 고민해봐야하지 않을까?
... 라고 생각할 시간에 그 차선책을 먼저 구현해보는 쪽이 낫다... 고 생각한다.
물론 그 차선책이라는 놈이 게임의 근간을 뒤흔들어 버린다든가 -_-a 구현하는 데에 무지막지한 코스트를 요구하는 놈이라면 쓸 수 업ㅂ는 방법임미다 냅.
하지만 완전히 막장으로 게임을 구성하지 않은 이상에야, 대부분의 경우 이미 구축된 기반 위에서의 수정 작업으로 커버가 되게 마련이고...
그러므로 '고민할 시간이 있다면 그 시간에 일단 그럴싸해 보이는 놈을 닥치고 구현해보는 쪽'이 어떻게든 더 낫지 않을까 싶다.
그 차선책을 구현해서 함 볼 수 있게 된다면...
Case 1.
Case 2.
Case 3.
차선책은 역시 차선책이라서리 부족한 면이 보인다. 그렇다면 이제야 명확히 보이는 그 부족한 면을 메우는 것이 최선책이 될 수 있다.
Case 2.
여전히 차선책 정도인 듯 싶은데, 또 여전히 최선책은 떠오르지 않는다. 그럼 그게 그 개발팀 역량에서의 최선책인거다. 어쩔라미 ~_~
Case 3.
크악! 문제가 더욱 커져버렸다! 그러나 이제 더 많이, 명확하게 보이는 문제들을 통해서... 오히려 새로운 차선책, 혹은 운이 좋으면 최선책으로 가는 길이 보이게 될 가능성 역시 늘어난다.
이럴 수 있지 않을까 'ㅅ'
... 라지만 역시 시간이 모질라 흑흑
크런치는 끗나지 않는다 ㄱ-
사족으로 덧붙이는 최악의 Case 4.
여전히 차선책 정도라서리 뭔가 부족한 듯 싶어... 차선책 하나를 더 덧붙인다! 냅 이것이 바로 Feature Creep ㄳ
|
Trackback Address :: http://glekang.com/trackback/357
|
[글강, 2009/04/06 23:08, Game]
[imays]님의 글 - [게임 개발의 암세포! FEATURE CREEP]에 덧붙이는 소견 'ㅅ'/
원문에서 기획자가 feature creep의 함정에 빠지는 사례로 소개된 내용을 발췌해 보자면 다음과 같다.
... 아놔 일단 눈물부터 좀 닦고 ㄱ-
이것이야말로 기획자라는 족속들이 참으로 쉽사리 빠져들곤 하는 [개발의 함정]이나니, 이 뭐... 망작으로 가는 지름길인거졈 ㅋ
그런데 여기에 한가지 더 덧붙이고 싶은 이야기가...
이 반대의 길에도 함정은 있슴미다 'ㅅ'
기획자가 게임에 이것 저것 오만 잡다한 feature들을 추가하는 이유는 '다른 게임에서 본 감동스런 피쳐들을 우리 게임에도 넣어서 엘레강스한 완성도를 만들기 위하여'인 경우도 있지만...
그 반대로 '이 게임이고 저 게임이고 더 이상 재미도 감동도 없다 보니, 우리 게임의 피쳐들도 너무 고만고만해 보이기만 해서'인 경우도 있다.
이건 특히나 겜덕 기획자들이 빠지기 쉬운 함정이 아닐까 싶기도 한데... 솔직히 말해 나 역시 이 함정에서 완전히 자유롭다고 장담하지는 못하겠다 ㄱ-
풀어서 설명해 보자면 다음과 같은 상황이라고나 할까.
현재 20대 후반 즈음에서부터 30대 초중반에 이르는 겜덕들은 소위 '전자 게임의 역사와 함께 자라온 세대'인 경우가 많다.
8비트 뿅뿅거리던 녀석들부터 게임 인생이 시작되어... 온갖 합법 / 불법(-_-)의 길로 다양다종한 게임들을 접하고 플레이해온... 좀 유명하다 싶은 게임이라면 '당연히 해봤졈' 소리가 나오는 니마들.
(... 이라고 적어놓고 보니 정작 나는 콘솔이랑은 별로 안친하고, 순혈 PC 외길 인생을 걸어왔지만, 그렇다 쳐도 왠만큼 유명한 콘솔 게임들은 또 어찌어찌 얼추 해본 듯 oTL)
그러다 보니... '하늘 아래 새로운게 대체 뭔가효?'라는 의문에 빠져버리기가 쉽고, 여기서 특히나 로직이라는 함정에 허리를 담그고 사는 시스템 기획자들은 한발짝 더 나아가...
때깔만 좀 다를 뿐이지 본질은 똑가타! 게임 피쳐라는게 다 거기서 거기지!
... 라는 성급한(?) 결론을 내려버리게 되어버리기가 참으로 쉬운 것이다.
그러다 보니 자기가 만들고 있는 게임에 들어가 있는 피쳐들도 뭔가...
식상해! 구태의연해! 아오오 ~_~ 이건 이 게임에 있던 거고, 저건 저 게임에 있던 거고! 뭔가 좀 더 새로운 피쳐는 없나효? 머리를 굴려보자 데굴데굴. 이런건 어떨까? 함 넣어볼까? 저런건 어떨까? 함 넣어볼까? 아오오 ~_~ 좀 더 창조적이고 창의적이며 새로운 경험을 창출해낼 수 있는 무언가! 무언가! 이걸까? 저걸까? 넣자! 우걱우걱!
... 요론 사태가 벌어져 버리는 것이다 -ㅅ-
아 냅. 물론 매우 바람직하지 않슴미다. Feature Creep이졈.
다른 게임에서 감명깊게 경험한 피쳐를 게임에 억지로 쑤셔넣는 거나... 결국 다 고만고만하다고 생각하야 그 고만고만함을 벗어나 보겠다고 우걱우걱 피쳐들을 억지로 쑤셔넣는 거나... 어느 쪽 극단으로 달려간다 할지라도 종착점은 똑같이 망작.
그러니까 결국은... 애매한 중용론만이 남게 되는데, 이건 뭐 어쩔 수 없는 듯 싶기도 하다. 게임 개발이 원래 그렇지 뭐 -ㅅ-
그나마 '지금 만들고 있는 게임에 가장 어울리는'이라고 엄연히 존재하는, 잘 보이지는 않으나 그래도 따라갈 수 있는 길이 있기는 하다는 정도가 위안일라나.
... 그르니까 결론은 잘난 척 하지 말자는거졈 'ㅅ'
... 그래도 빠심으로 눈이 흐려지는 것보다는 오만함으로 가려지는 쪽이 1mg 정도는 좀 더 낫다고 생각하긴 함미다 에헷 -ㅁ-
... 요런게 바로 잘난 척 oTL
원문에서 기획자가 feature creep의 함정에 빠지는 사례로 소개된 내용을 발췌해 보자면 다음과 같다.
게임 기획자들은 대단한 게임을 만들고 싶은 마음에 여러가지 아이디어들을 계속 집어넣습니다. 다른 게임에서 감동한 기능들을 자꾸만
넣습니다. 뭔가 엘레강스한 완성도의 게임을 꿈꾸며 대량의 기획서를 작성합니다. 그리고 플레이를 해보니 별로 재미가
없습니다. 안되겠습니다. 뭔가를 추가해야겠다고 생각합니다. 장르도 늘어납니다. 처음에는 액션 게임이었는데 만들다보니 MMO +
RPG + 전략시뮬 + 커뮤니티 + 어드벤처 + 음악댄스 + 영어교육 게임이 되어버립니다.
... 아놔 일단 눈물부터 좀 닦고 ㄱ-
이것이야말로 기획자라는 족속들이 참으로 쉽사리 빠져들곤 하는 [개발의 함정]이나니, 이 뭐... 망작으로 가는 지름길인거졈 ㅋ
그런데 여기에 한가지 더 덧붙이고 싶은 이야기가...
이 반대의 길에도 함정은 있슴미다 'ㅅ'
기획자가 게임에 이것 저것 오만 잡다한 feature들을 추가하는 이유는 '다른 게임에서 본 감동스런 피쳐들을 우리 게임에도 넣어서 엘레강스한 완성도를 만들기 위하여'인 경우도 있지만...
그 반대로 '이 게임이고 저 게임이고 더 이상 재미도 감동도 없다 보니, 우리 게임의 피쳐들도 너무 고만고만해 보이기만 해서'인 경우도 있다.
이건 특히나 겜덕 기획자들이 빠지기 쉬운 함정이 아닐까 싶기도 한데... 솔직히 말해 나 역시 이 함정에서 완전히 자유롭다고 장담하지는 못하겠다 ㄱ-
풀어서 설명해 보자면 다음과 같은 상황이라고나 할까.
현재 20대 후반 즈음에서부터 30대 초중반에 이르는 겜덕들은 소위 '전자 게임의 역사와 함께 자라온 세대'인 경우가 많다.
8비트 뿅뿅거리던 녀석들부터 게임 인생이 시작되어... 온갖 합법 / 불법(-_-)의 길로 다양다종한 게임들을 접하고 플레이해온... 좀 유명하다 싶은 게임이라면 '당연히 해봤졈' 소리가 나오는 니마들.
(... 이라고 적어놓고 보니 정작 나는 콘솔이랑은 별로 안친하고, 순혈 PC 외길 인생을 걸어왔지만, 그렇다 쳐도 왠만큼 유명한 콘솔 게임들은 또 어찌어찌 얼추 해본 듯 oTL)
그러다 보니... '하늘 아래 새로운게 대체 뭔가효?'라는 의문에 빠져버리기가 쉽고, 여기서 특히나 로직이라는 함정에 허리를 담그고 사는 시스템 기획자들은 한발짝 더 나아가...
때깔만 좀 다를 뿐이지 본질은 똑가타! 게임 피쳐라는게 다 거기서 거기지!
... 라는 성급한(?) 결론을 내려버리게 되어버리기가 참으로 쉬운 것이다.
그러다 보니 자기가 만들고 있는 게임에 들어가 있는 피쳐들도 뭔가...
식상해! 구태의연해! 아오오 ~_~ 이건 이 게임에 있던 거고, 저건 저 게임에 있던 거고! 뭔가 좀 더 새로운 피쳐는 없나효? 머리를 굴려보자 데굴데굴. 이런건 어떨까? 함 넣어볼까? 저런건 어떨까? 함 넣어볼까? 아오오 ~_~ 좀 더 창조적이고 창의적이며 새로운 경험을 창출해낼 수 있는 무언가! 무언가! 이걸까? 저걸까? 넣자! 우걱우걱!
... 요론 사태가 벌어져 버리는 것이다 -ㅅ-
아 냅. 물론 매우 바람직하지 않슴미다. Feature Creep이졈.
다른 게임에서 감명깊게 경험한 피쳐를 게임에 억지로 쑤셔넣는 거나... 결국 다 고만고만하다고 생각하야 그 고만고만함을 벗어나 보겠다고 우걱우걱 피쳐들을 억지로 쑤셔넣는 거나... 어느 쪽 극단으로 달려간다 할지라도 종착점은 똑같이 망작.
그러므로 다른 게임의 엘레강스함을 너무 칭송하지 말지어다. 빠심이 지나치면 내 게임이 엘레강스해질 수 있는 길이 그 빠심에 먹혀버린다.
그러므로 다른 게임의 엘레강스함을 너무 무시하지 말지어다. 냉소가 지나치면 내 게임 역시 무미건조한 냉소로 가득 찰 뿐이니.
그러니까 결국은... 애매한 중용론만이 남게 되는데, 이건 뭐 어쩔 수 없는 듯 싶기도 하다. 게임 개발이 원래 그렇지 뭐 -ㅅ-
그나마 '지금 만들고 있는 게임에 가장 어울리는'이라고 엄연히 존재하는, 잘 보이지는 않으나 그래도 따라갈 수 있는 길이 있기는 하다는 정도가 위안일라나.
... 그르니까 결론은 잘난 척 하지 말자는거졈 'ㅅ'
... 그래도 빠심으로 눈이 흐려지는 것보다는 오만함으로 가려지는 쪽이 1mg 정도는 좀 더 낫다고 생각하긴 함미다 에헷 -ㅁ-
... 요런게 바로 잘난 척 oTL
|
Trackback Address :: http://glekang.com/trackback/356
|
[글강, 2009/04/02 20:55, Game]
알파 테스트 이전의 단계, 그러니까 걍 팀 내에서만 진행하는 구현 테스트... 같은 놈은 뭐라고 불러야 하나효?
에에... 그냥 팀 테스트? -_-a 모르겠다. 걍 팀 테스트 ㅋ
그러니까 드디어 팀 테스트를 시작했다능.
아아... 무슨 게임인지는 뭐 아직 공개가 아니된 녀석이니, 걍 수많은 개발사들이, 수없이 가지고 있으면서, 조용히 진행하다가, 혹은 조용히 접어버리기도 하는(쿠엑) 그냥저냥 개발 프로젝트인 셈인데.
암튼 기나긴 프로토타이핑의 산을 넘어, 이제야 비로소 실구현된 클라이언트의 첫 테스트.
... 당연히 개판 오분전임미다.
속출하는 버그들, 아직 제대로 붙지 못한 리소스들, 그리고 밸런싱이 뭔가효 먹는건가효?
... 게임이라 부르기도 애매한, 돌아가는게 다행인... 아니지 제대로 돌아가지도 않자나 ; 암튼 뭐 그런 상태.
당연히 수많은 문제들이 불궈져 나오고, 미처 예측하고 고려하지 못한 문제들도 수면을 박차고 튀어나오고 그러나니...
패닉에 빠지기가 참 쉽다능.
그러므로 결론은 설레발 금지.
일단은 다른 요소들과 실타래처럼 얽힌 녀석들에 손을 대는 것은 금물이다. 뭐 하나 건드리면 줄줄이 엮이는데, 건드린 녀석이 문제의 핵심이라는 보장은 '아직' 아무 데에도 없으니까.
개별 단위의 독립적인 문제들을 우선 손봐서 제대로 해놓고, 그 후에야 비로소 전체적인 그림을 다듬어가야 하나니...
뭐 이건 너무나도 당연한 일반론.
그러나 한발짝만 삐끗하면 패닉이나니, 정신줄을 잡읍시다 ㅋ
근데 그보다 더 곤란한 문제는... 쯥.
개발 외적인 이슈로 1개월을 허공으로 날려버렸는데, 그 1개월을 아무도 보상해주지 아니하나니 ㄱ-
히밤. 크런치로 극복이라니... 이게 뭔가효. 그나마 크런치를 이렇게 빡세게 하고 있는데도 그냥 대놓고 물리적 시간이 모질라.
장기적으로 보자면 이 부작용은 점점 누적될 가능성이 높은데 ㄱ- 이거이 개발 프로젝트에서 원래 발생하는 리스크인건지 에잉.
에에... 그냥 팀 테스트? -_-a 모르겠다. 걍 팀 테스트 ㅋ
그러니까 드디어 팀 테스트를 시작했다능.
아아... 무슨 게임인지는 뭐 아직 공개가 아니된 녀석이니, 걍 수많은 개발사들이, 수없이 가지고 있으면서, 조용히 진행하다가, 혹은 조용히 접어버리기도 하는(쿠엑) 그냥저냥 개발 프로젝트인 셈인데.
암튼 기나긴 프로토타이핑의 산을 넘어, 이제야 비로소 실구현된 클라이언트의 첫 테스트.
... 당연히 개판 오분전임미다.
속출하는 버그들, 아직 제대로 붙지 못한 리소스들, 그리고 밸런싱이 뭔가효 먹는건가효?
... 게임이라 부르기도 애매한, 돌아가는게 다행인... 아니지 제대로 돌아가지도 않자나 ; 암튼 뭐 그런 상태.
당연히 수많은 문제들이 불궈져 나오고, 미처 예측하고 고려하지 못한 문제들도 수면을 박차고 튀어나오고 그러나니...
패닉에 빠지기가 참 쉽다능.
아놔 이거 어쩌나효. 버그는 버그니까 일단 고쳐야 하는데, 추가 구현을 더 해야 하나? 이건 뭐 대놓고 땜빵이 될텐데 (...)
아놔 이거 어쩌나효. 리소스 전면 교체라도 해야 하나? 아니 근데 아직 비쥬얼 밸런스를 맞추지도 않았는데 (...)
아놔 이거 어쩌나효. 밸런싱 처음부터 다시 해야 하나? 아니 근데 아직 제대로 테스트도 못해봤는데 밸런싱이 적용된 거이다 할 수도 없거늘 (...)
아놔 이거 어쩌나효. 리소스 전면 교체라도 해야 하나? 아니 근데 아직 비쥬얼 밸런스를 맞추지도 않았는데 (...)
아놔 이거 어쩌나효. 밸런싱 처음부터 다시 해야 하나? 아니 근데 아직 제대로 테스트도 못해봤는데 밸런싱이 적용된 거이다 할 수도 없거늘 (...)
그러므로 결론은 설레발 금지.
일단은 다른 요소들과 실타래처럼 얽힌 녀석들에 손을 대는 것은 금물이다. 뭐 하나 건드리면 줄줄이 엮이는데, 건드린 녀석이 문제의 핵심이라는 보장은 '아직' 아무 데에도 없으니까.
개별 단위의 독립적인 문제들을 우선 손봐서 제대로 해놓고, 그 후에야 비로소 전체적인 그림을 다듬어가야 하나니...
뭐 이건 너무나도 당연한 일반론.
그러나 한발짝만 삐끗하면 패닉이나니, 정신줄을 잡읍시다 ㅋ
근데 그보다 더 곤란한 문제는... 쯥.
개발 외적인 이슈로 1개월을 허공으로 날려버렸는데, 그 1개월을 아무도 보상해주지 아니하나니 ㄱ-
히밤. 크런치로 극복이라니... 이게 뭔가효. 그나마 크런치를 이렇게 빡세게 하고 있는데도 그냥 대놓고 물리적 시간이 모질라.
장기적으로 보자면 이 부작용은 점점 누적될 가능성이 높은데 ㄱ- 이거이 개발 프로젝트에서 원래 발생하는 리스크인건지 에잉.
|
Trackback Address :: http://glekang.com/trackback/355
|
[글강, 2009/03/04 11:50, Game]
간만에 끄적여보는, 조금은 공격적인, 아는 사람만 알만한 이야기?
옛날하고도 한 옛날에 끄적였던 글에서 언급했던 바와 같이, 난 여전히 온라인 게임 개발에 있어 In-Game Play라 불리우는 영역과 Out-Game Play라 불리우는 영역이 가지는 중요성의 비율이 5:5는 된다고 생각한다.
다만 이 둘은 한 세트이기 때문에, '어느 한 쪽이 괜찮으면 다른 쪽은 좀 허접해도 된다는거냐?'라는 식의 반론은 사절.
어느 한 쪽만 괜찮아봤자 결국은 50%만 성공적인, 반쪽짜리 게임일 뿐이니 망합니다 뿌우 'ㅅ'
(예외 케이스가 아주 없는 것은 아니지만, 예외는 예외이므로 예외로 취급하야 예외적으로 예외 처리 해버림미다 -ㅁ-)
물론 중요도는 동일 비율이라 하지만... 소위 '게임 디자인'이라 지칭되는 영역은 아무래도 In-Game Play 쪽에 걸쳐 있는 경우가 많고, Out-Game Play 쪽은 '편의 기능'이나 온라인 게임이기에 가져야만 하는 일종의 '순환 구조'를 형성하는 디자인에 가깝다.
그러므로 일반적으로는 In-Game Play 쪽을 우선적으로 디자인하고, 그 쪽에서 성과가 어느 정도 보이고 나면... 그제서야 Out-Game Play 쪽의 디자인으로 접어들곤 하는데...
우리도 마찬가지.
In-Game Play를 좀 쓸만하다 싶도록 만들기 위하야... 프로토타이핑만 1년, 그리고 그 프로토타입을 기반으로 하야 다듬고 다듬으며 제대로 된 플레이어블 버전을 만드는 데에 또 1년 가까운 시간을 쓰는 중이다.
그리고 이제서야 얼추 쵸큼 Out-Game Play 쪽의 디자인으로 시선을 돌리는 중인데... 하아. 그니까 이 녀석도 결국 중요도는 50%인지라, 쓸만하게 만드려면 또 얼마나 머리를 쪼개고 쪼개며 고민해야 할는지 앞이 깜깜.
뭐 그렇다 쳐도... 요거이 개발의 정도랄까, 어차피 다들 하는 일이고, 나도 해야 하는 일이고... 앞은 깜깜해도 당연히 해야 하는 거니까리 어찌하리오. 해야제.
... 인데, 요즘 들어 사도의 길이 눈에 밟히나니 -ㅁ-
In-Game Play는 결국 결과물이 '게임'이라 불리우기 위한 성격을 결정짓는 부분이므로, 최대한 공들여 만든다 치더라도...
Out-Game Play는 앞서도 언급한 바와 같이 편의와 순환 구조의 이슈에 가까우므로... 이미 성공적으로 이러한 구조를 갖춘 다른 게임의 Out-Game Play를 그냥 통째로 들고 와버리면 되지 않카써???

... 물론 안됨미다. 그니까 둘은 한 세트라서, 남의 것을 그대로 들고 온다 해도 어차피 잘 붙게 하려면 조율을 해야 하기 때문에...
... 라지만 장르에 따라서는 그냥 그대로 붙여도 되는 경우가 없지 않다. (우린 그렇게 못한다 크흑)
그럼 장르에 따라서는 그냥 통째로 들고 와버리는게 개발 기간도 단축하고, 개발 인력도 적게 쓰고, 심지어 그러면서도 '성공적인' 녀석을 들고 와버린만치 퀄리티를 기대할 수도 있는... 캬악. 존내좋군?

... 아니 그러니까, 안된다니까.
... 그런데 그러더라니까.
대놓고 사도의 길을 표방하며 달려가고 있나니, 그걸 보고 있자면 실로 꽁기꽁기하다 -ㅅ-
(심지어 처음 그러는 것도 아니고 두번째야 ~_~; 확신범에 가깝다는 생각이 들기 시작하는데...)
물론 프로젝트라는 것은 성공을 목표로 하야 진행하는 것이고, 그 성공을 달성하기 위한 goal은 '빠르고, 싸게, 높은 퀄리티로'이니까리... 이거이 참 '좋은' 방법이라는 것은 알겠는데...

아니 '나는' 안괜찮은 것 같다능. 일단 난 누가 그러라고 하면 내 '프로 의식'에 액화 질소라도 붓기 전에는 그렇게 못할거 가터 -ㅁ-
그니까 난 울 게임의 Out-Game Play 디자인이나 해야... 아익 머리 아파 ㄱ-
ps. 물론 이거이 표절이나 무단 도용은 아님미다. 차라리 표절 or 무단 도용 = 불법이라면 이런 아햏스러운 기분은 안들겠징.
옛날하고도 한 옛날에 끄적였던 글에서 언급했던 바와 같이, 난 여전히 온라인 게임 개발에 있어 In-Game Play라 불리우는 영역과 Out-Game Play라 불리우는 영역이 가지는 중요성의 비율이 5:5는 된다고 생각한다.
다만 이 둘은 한 세트이기 때문에, '어느 한 쪽이 괜찮으면 다른 쪽은 좀 허접해도 된다는거냐?'라는 식의 반론은 사절.
어느 한 쪽만 괜찮아봤자 결국은 50%만 성공적인, 반쪽짜리 게임일 뿐이니 망합니다 뿌우 'ㅅ'
(예외 케이스가 아주 없는 것은 아니지만, 예외는 예외이므로 예외로 취급하야 예외적으로 예외 처리 해버림미다 -ㅁ-)
물론 중요도는 동일 비율이라 하지만... 소위 '게임 디자인'이라 지칭되는 영역은 아무래도 In-Game Play 쪽에 걸쳐 있는 경우가 많고, Out-Game Play 쪽은 '편의 기능'이나 온라인 게임이기에 가져야만 하는 일종의 '순환 구조'를 형성하는 디자인에 가깝다.
그러므로 일반적으로는 In-Game Play 쪽을 우선적으로 디자인하고, 그 쪽에서 성과가 어느 정도 보이고 나면... 그제서야 Out-Game Play 쪽의 디자인으로 접어들곤 하는데...
우리도 마찬가지.
In-Game Play를 좀 쓸만하다 싶도록 만들기 위하야... 프로토타이핑만 1년, 그리고 그 프로토타입을 기반으로 하야 다듬고 다듬으며 제대로 된 플레이어블 버전을 만드는 데에 또 1년 가까운 시간을 쓰는 중이다.
그리고 이제서야 얼추 쵸큼 Out-Game Play 쪽의 디자인으로 시선을 돌리는 중인데... 하아. 그니까 이 녀석도 결국 중요도는 50%인지라, 쓸만하게 만드려면 또 얼마나 머리를 쪼개고 쪼개며 고민해야 할는지 앞이 깜깜.
뭐 그렇다 쳐도... 요거이 개발의 정도랄까, 어차피 다들 하는 일이고, 나도 해야 하는 일이고... 앞은 깜깜해도 당연히 해야 하는 거니까리 어찌하리오. 해야제.
... 인데, 요즘 들어 사도의 길이 눈에 밟히나니 -ㅁ-
In-Game Play는 결국 결과물이 '게임'이라 불리우기 위한 성격을 결정짓는 부분이므로, 최대한 공들여 만든다 치더라도...
Out-Game Play는 앞서도 언급한 바와 같이 편의와 순환 구조의 이슈에 가까우므로... 이미 성공적으로 이러한 구조를 갖춘 다른 게임의 Out-Game Play를 그냥 통째로 들고 와버리면 되지 않카써???

... 물론 안됨미다. 그니까 둘은 한 세트라서, 남의 것을 그대로 들고 온다 해도 어차피 잘 붙게 하려면 조율을 해야 하기 때문에...
... 라지만 장르에 따라서는 그냥 그대로 붙여도 되는 경우가 없지 않다. (우린 그렇게 못한다 크흑)
그럼 장르에 따라서는 그냥 통째로 들고 와버리는게 개발 기간도 단축하고, 개발 인력도 적게 쓰고, 심지어 그러면서도 '성공적인' 녀석을 들고 와버린만치 퀄리티를 기대할 수도 있는... 캬악. 존내좋군?

... 아니 그러니까, 안된다니까.
... 그런데 그러더라니까.
대놓고 사도의 길을 표방하며 달려가고 있나니, 그걸 보고 있자면 실로 꽁기꽁기하다 -ㅅ-
(심지어 처음 그러는 것도 아니고 두번째야 ~_~; 확신범에 가깝다는 생각이 들기 시작하는데...)
물론 프로젝트라는 것은 성공을 목표로 하야 진행하는 것이고, 그 성공을 달성하기 위한 goal은 '빠르고, 싸게, 높은 퀄리티로'이니까리... 이거이 참 '좋은' 방법이라는 것은 알겠는데...

안괜찮은 것 같다능 'ㅅ'
아니 '나는' 안괜찮은 것 같다능. 일단 난 누가 그러라고 하면 내 '프로 의식'에 액화 질소라도 붓기 전에는 그렇게 못할거 가터 -ㅁ-
그니까 난 울 게임의 Out-Game Play 디자인이나 해야... 아익 머리 아파 ㄱ-
ps. 물론 이거이 표절이나 무단 도용은 아님미다. 차라리 표절 or 무단 도용 = 불법이라면 이런 아햏스러운 기분은 안들겠징.
|
Trackback Address :: http://glekang.com/trackback/351
|
[글강, 2009/02/06 00:06, Game]
아 영양가도 없고 쓰잘데기 없는 글이 넘 길었다. 8연작은 또 처음 해보네. 이제 좀 끝내자능.
게임 디자인이란 실로 모호한 일이다.
정답이라는건 애초에 존재하지도 않고, 최선이라 판단하여 선택한 디자인조차, 과연 이것이 최선일는지 여부를 검증할 방법이랄까 근거가 딱히 존재하지 않는 것이다.
그렇다면... 여러가지 게임 어셋들이 모여 최종적으로 완성된 게임이 재미있는 경우, 그 게임의 디자인은 최선이었다고 할 수 있지 않을까?
그러나 재미라는 것은 게임 디자인보다도 더욱 모호한 것. 이건 Case by Case도 아니고 심지어 Human by Human이다 ㄱ-;;;
그럼 출시된 게임이 상업적으로 성공한다면... 그 경우 해당 게임의 디자인은 정답은 아닐지라도 최선이라 할 수 있지 않을까?
어느정도 수긍해줄 수 있는 주장이지만, 게임의 상업적 성공에는 게임 디자인 이외에도 수많은 변수가 개입한다. 그걸 과연 게임 디자인의 공로로만 돌릴 수 있을까?
그렇기에 게임 디자이너는, 기획자라는 존재는 모호함의 강물을 헤엄칠 수밖에 없다. 글쎄, 누군가 나에게 정답을 제시해 준다면 이 생각이 바뀔 수 있을는지도 모르겠지만... 현재의 나로서는 기획자란 이런 모호함을 받아들이고 수긍하는 인간이어야 한다고 생각한다.
뭐 어찌되었든 지구는 돌고, 해는 뜨고 지며, 일은 존재하니까... 기획자는 일을 - 게임 디자인을 하게 된다.
그럼 디자인의 애매모호를 받아들이는 기획자라면... '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 어떻게 대답해야 할까?
확신을 가질 수 없는 기획자가, 자신의 디자인이 최선이었음을 인정하기 위해 필요한 것은 무엇일까?
... 신념?
... 라고?
아니.
나는 바로 이 지점이 위험하다고 생각한다.
게임 디자인은 (미칠듯이 꾸깃꾸깃 압축하고 초단순화 해보자면) 결국 '판단'이다. 하지만 기획자는 이 판단에 확신을 가질 수 없다. 그렇다고 기획자가 여기에 신념을 가져버린다면... 그리고 만약 프로세스가 기획자의 이 신념을 그대로 용인하는 구조라면!
그 순간 기획자의 신념은 개발에 독이 된다.
이것이 바로 [5번 글]에 나왔던 곤란한 상황. 기획자가 자신의 디자인에 신념을 가지고, 다른 직군에게 이 신념을 강요하는 구조.
아 물론 그 신념이 정말 재미있고, 상업적인 성공을 보장한다면 해피 엔딩... 일까?
아니.
그럼에도 불구하고 그 개발팀이 팀으로서 가질 수 있는 장기적인 비전에는 독이 된다고 생각한다. 그런 프로세스 하에서는 팀이 '우리'가 되지 못할 리스크가 너무나도 크다.
그렇다면... 기획자의 게임 디자인이 가지는 가치를 부정해야 할까? 기획자는 쓸모 없다고 인정해야 할까?
아니.
게임 디자인이라는 업무를 전담해야 하는 사람은 개발팀 내에서 반드시 필요하다.
그리하야 내가 내리는 결론은...
기획자는 프로세스를 먹고 살아야 한다는 것이다.
개발 프로세스가 기획자를 보약으로, 혹은 독으로 만든다는 점을 인지하고, 기획자가 독이 되지 않는 프로세스를 구축하는 것이 중요하다는 것이다.
혹여 프로세스가 기획자를 독으로 만들고 있다면, 기획자 자신이 스스로 나서서 이러한 프로세스를 바꾸어 나갈 수 있어야만 한다는 것이다.
하지만 안타깝게도 어떠한 프로세스가 기획자를 개발팀에 긍정적인 보약으로 기능하게 하는지, 내가 그 정답을 제시할 수는 없다. 혹은 이것 역시 정답이 없는... 개발팀의 구성, 프로젝트의 성격에 따라 Case by Case가 되는, 애매모호한 것이 아닐까 두려운데...
그럼에도 불구하고 내가 제시할 수 있는 것은, 내 경험의 한도 내에서 판단하기에...
우리 개발팀이 현재 채택하고 있는 프로세스는 기획자가 독이 되는 경로를 차단하고, 보약으로 기능하게끔 하고 있다는 것이다. 이 글을 읽는 분들이 우리의 프로세스 구조를 통해 생각해 볼 구석이 생긴다면 그것으로도 성공.
핵심 키워드는... '우리가 게임을 만든다'라는 비전의 공유일까.
기획자들이 흔히 하는 불평 중의 하나로 '문서를 써봤자 아무도 안읽어효'라는 것이 있다.
이 경우 문서를 제대로 쓰지 못한 기획자에게 문제가 있는 것일까? 혹은 문서를 읽지 않는 다른 팀원들에게 문제가 있는 것일까?
아니. 애초에 저런 불평이 발생하게 되는 근본적인 구조 자체가 문제이다.
구체적인 게임 디자인의 이전 단계에서, 그 어셋에 관여하는 모든 이들이 '우리가 무엇을 만드는지, 만들 것인지'에 대한 동일한 상을 공유하지 못하고 있기에...
기획자는 결국 자기만의 확신, 자기만의 신념으로 디자인을 할 수밖에 없게 되는 것이고, 다른 팀원들로서는 그렇게 나온 결과물 - 기획서가 그저 쌩뚱맞게 되는 것이다.
이는 명백한 악순환이다. 기획자가 열심히 일해봤자 개발에 독이 될 뿐이다.
따라서 중요한 것은, 기획자가 확신을 가질 수 없고, 섣부른 신념을 가져서도 안되는 게임 디자인에 대하여... '우리'가 참여하여 함께 논의하고 다듬으며 공유하는 프로세스를 갖추는 것이다.
아 혹여 이것을 '그냥 기획자가 무능한거네', 혹은 '그럴거면 기획자가 무슨 소용이야?', 또는 '기획자만 편하게 만들어 줄 뿐이잖아?'라고 받아들이는 분이 있다면 다시 생각해 보시길.
이 질문에 정답을 제시할 수 있는 사람은 아무도 없다. 나는 이것이 '인간'에게는 불가능한 것이라 생각한다.
그렇기 때문에 이 문제의 해답은 그 게임을 만드는 이들 모두가 함께 찾아가야 한다. 즉 '개발팀의 역량을 모두 합쳐서 찾아낸, 그만큼의 길'이 그 개발팀에게는 해답이 되는 것이다.
이 중요한 작업을 누군가에게 전담시켜서는 안된다. 개발은 '우리'가 하는 것이지 '개인'이 하는 것이 아니다. 그리고 디자인은 그 개발의 시작... 당연히 '우리'가 함께 해야 하는 시작 지점인 것이다.
그러므로 이러한 프로세스를 갖추는 것이... 기획자만 편해지고, 괜히 다른 직군의 어깨에 더 무거운 짐을 얹는다는 생각을 해서는 곤란하다.
아 물론 기획자가 만들어서 던지는 일을 수동적으로 받아서 하는 상황에 비해 보자면, 어깨에 얹어지는 짐이 더 무거워질 수는 있다. 그러나 그 짐은 원래 모든 팀원의 어깨 위에 있어야만 하는 짐이었다.
이것이 부당하게 여겨지는가? 하지만 그 짐을 기획자에게 던지는 순간, 기획자는 부당한 권력(!)을 가지게 되고, 개발자는 일개 톱니바퀴가 될 수밖에 없으며, 프로젝트의 성공 가능성은 그만큼 낮아진다. 그것이 옳은가? 프로젝트는 성공하기 위하여 진행하는 것인데도?
그렇기 때문에, 우리 팀이 현재 채택하고 있는...
...라는 프로세스가 나는 옳다고 생각한다.
프로젝트를 위해서도. 개발팀을 위해서도. 그리고 기획자를 위해서도.
이런 환경이 갖추어지고, 기획자가 그 어깨에 지워진 부당한 짐을 덜어낼 수 있다면... 그럼 기획자는 이제 무슨 일을 해야 할까? 기획자의 고유 업무라고 했던 게임 디자인과 밸런싱에만 주력하면 되나?
아니.
이젠 개발팀의, 개발 프로세스의 보약이 되도록 노력해야 하는 일이 남아있다.
드디어 기획자는 계속 언급해 온 7단계에 마음놓고 최대한 적극적으로 개입할 수 있게 되는 것이다.
아니, 이런 환경에서는 기획자가 아무리 '독점'을 하려 들어도 애초에 독점이 발생할 수 없다. 얏호~ 기획자로서는 실로 신나는 상황인 것이다.
최대한 자신이 가진 역량을 발휘하고, 오지랖을 파바박 넓히면서, 잡부 근성으로 개발의 단계 단계마다 매끄럽게 기름칠을 하면 할수록... 그것이 개발에 도움이 된다. 결코 독이 되지 않는다.
무엇보다도 두려운 지점, '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 대하여 홀로 고민할 필요도 없다. 그 대답은 '우리'가 함께 찾아 줄 것이다. '우리'가 '우리'의 역량 내에서 최선이라 믿는 길로.
마음놓고 모호함의 강물을 힘껏 헤엄쳐 나아가기만 하면 되는 것이다.
그리고 얼마나 더 멀리 나아갈 수 있을는지는 이제 전적으로 개인의 역량에 달려있게 된다.
남은 것은 '노예처럼 일하셈!!!' 뿐.
물론 여러 번 이야기한 바와 같이, 우리 개발팀의 프로세스라고 해서 우주 최강은 아니다 -_-a
[7번 글]에서 언급한 취약점들, 혹은 앞으로도 미치 깨닫지 못한 문제들이 산적해 있을 것이다.
하지만 그럼에도 불구하고... 뭐 식견 짧은 내가 듣고 봐온 중에서는, 기획이라는 직군의 독소는 독소대로 골라내면서, 등골을 쏙쏙 잘도 뽑아먹는 효율적인(?) 구조인 듯.
피식. 마지막은 또 용비어천가인가효.
뭐 읽으시는 분들이 알아서 걸러낼 것은 걸러내고, 혹은 보완할 것은 보완해 가면서 참고하시는 수밖에 없다능 -ㅅ-
언젠가 훗날, 좀 더 내공이 쌓인 후에 이 글을 다시 보게 된다면... 나는 지금 쓰잘데기 없이 길게만 주절거린 이 내용들을 비웃을 수 있을까?
'게임 기획자는 무엇무엇을 하는 사람이지. 게임 디자인이란 이러저러한 거잖아. 왜 그 때엔 이 명확한 걸 몰랐지? 피식.'
... 요로코롬 내가 나를 비웃을 수 있는 날이 오기를 기대하며, 암튼 이번에는 이것으로 끝.
쓰잘데기 없는 내용인 주제에 스크롤만 길고, 논리도 마구마구 튀는 두서없고 재미없는 글 읽어주신 분들께... (와우 내 블록에서 이런 식으로 말 해보기는 되게 오랜만인 것 같아 -_-) 감사드림미다 -ㅁ-/
게임 디자인이란 실로 모호한 일이다.
정답이라는건 애초에 존재하지도 않고, 최선이라 판단하여 선택한 디자인조차, 과연 이것이 최선일는지 여부를 검증할 방법이랄까 근거가 딱히 존재하지 않는 것이다.
그렇다면... 여러가지 게임 어셋들이 모여 최종적으로 완성된 게임이 재미있는 경우, 그 게임의 디자인은 최선이었다고 할 수 있지 않을까?
그러나 재미라는 것은 게임 디자인보다도 더욱 모호한 것. 이건 Case by Case도 아니고 심지어 Human by Human이다 ㄱ-;;;
그럼 출시된 게임이 상업적으로 성공한다면... 그 경우 해당 게임의 디자인은 정답은 아닐지라도 최선이라 할 수 있지 않을까?
어느정도 수긍해줄 수 있는 주장이지만, 게임의 상업적 성공에는 게임 디자인 이외에도 수많은 변수가 개입한다. 그걸 과연 게임 디자인의 공로로만 돌릴 수 있을까?
그렇기에 게임 디자이너는, 기획자라는 존재는 모호함의 강물을 헤엄칠 수밖에 없다. 글쎄, 누군가 나에게 정답을 제시해 준다면 이 생각이 바뀔 수 있을는지도 모르겠지만... 현재의 나로서는 기획자란 이런 모호함을 받아들이고 수긍하는 인간이어야 한다고 생각한다.
뭐 어찌되었든 지구는 돌고, 해는 뜨고 지며, 일은 존재하니까... 기획자는 일을 - 게임 디자인을 하게 된다.
그럼 디자인의 애매모호를 받아들이는 기획자라면... '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 어떻게 대답해야 할까?
확신을 가질 수 없는 기획자가, 자신의 디자인이 최선이었음을 인정하기 위해 필요한 것은 무엇일까?
... 신념?
나는 내가 내린 판단을 믿어. 이것이 내 역량 내에서 내가 내린 최선의 판단이었다고 믿어. 이 디자인은 게임을 재미있게 만들어 줄거야. 믿자!
... 라고?
아니.
나는 바로 이 지점이 위험하다고 생각한다.
게임 디자인은 (미칠듯이 꾸깃꾸깃 압축하고 초단순화 해보자면) 결국 '판단'이다. 하지만 기획자는 이 판단에 확신을 가질 수 없다. 그렇다고 기획자가 여기에 신념을 가져버린다면... 그리고 만약 프로세스가 기획자의 이 신념을 그대로 용인하는 구조라면!
그 순간 기획자의 신념은 개발에 독이 된다.
이것이 바로 [5번 글]에 나왔던 곤란한 상황. 기획자가 자신의 디자인에 신념을 가지고, 다른 직군에게 이 신념을 강요하는 구조.
아 물론 그 신념이 정말 재미있고, 상업적인 성공을 보장한다면 해피 엔딩... 일까?
아니.
그럼에도 불구하고 그 개발팀이 팀으로서 가질 수 있는 장기적인 비전에는 독이 된다고 생각한다. 그런 프로세스 하에서는 팀이 '우리'가 되지 못할 리스크가 너무나도 크다.
그렇다면... 기획자의 게임 디자인이 가지는 가치를 부정해야 할까? 기획자는 쓸모 없다고 인정해야 할까?
아니.
게임 디자인이라는 업무를 전담해야 하는 사람은 개발팀 내에서 반드시 필요하다.
그리하야 내가 내리는 결론은...
기획자는 프로세스를 먹고 살아야 한다는 것이다.
개발 프로세스가 기획자를 보약으로, 혹은 독으로 만든다는 점을 인지하고, 기획자가 독이 되지 않는 프로세스를 구축하는 것이 중요하다는 것이다.
혹여 프로세스가 기획자를 독으로 만들고 있다면, 기획자 자신이 스스로 나서서 이러한 프로세스를 바꾸어 나갈 수 있어야만 한다는 것이다.
물론 말단 기획자 따위가 무슨 수로 개발 프로세스를 바꾸냐... 라고 하신다면 할 말 없음 ㄱ- 그래서 사실 이 부분은 디렉터 분들이 좀 신경 써주시면 감사하겠는데 말이졈 -ㅁ-
하지만 안타깝게도 어떠한 프로세스가 기획자를 개발팀에 긍정적인 보약으로 기능하게 하는지, 내가 그 정답을 제시할 수는 없다. 혹은 이것 역시 정답이 없는... 개발팀의 구성, 프로젝트의 성격에 따라 Case by Case가 되는, 애매모호한 것이 아닐까 두려운데...
그럼에도 불구하고 내가 제시할 수 있는 것은, 내 경험의 한도 내에서 판단하기에...
우리 개발팀이 현재 채택하고 있는 프로세스는 기획자가 독이 되는 경로를 차단하고, 보약으로 기능하게끔 하고 있다는 것이다. 이 글을 읽는 분들이 우리의 프로세스 구조를 통해 생각해 볼 구석이 생긴다면 그것으로도 성공.
핵심 키워드는... '우리가 게임을 만든다'라는 비전의 공유일까.
기획자들이 흔히 하는 불평 중의 하나로 '문서를 써봤자 아무도 안읽어효'라는 것이 있다.
이 경우 문서를 제대로 쓰지 못한 기획자에게 문제가 있는 것일까? 혹은 문서를 읽지 않는 다른 팀원들에게 문제가 있는 것일까?
아니. 애초에 저런 불평이 발생하게 되는 근본적인 구조 자체가 문제이다.
구체적인 게임 디자인의 이전 단계에서, 그 어셋에 관여하는 모든 이들이 '우리가 무엇을 만드는지, 만들 것인지'에 대한 동일한 상을 공유하지 못하고 있기에...
기획자는 결국 자기만의 확신, 자기만의 신념으로 디자인을 할 수밖에 없게 되는 것이고, 다른 팀원들로서는 그렇게 나온 결과물 - 기획서가 그저 쌩뚱맞게 되는 것이다.
이는 명백한 악순환이다. 기획자가 열심히 일해봤자 개발에 독이 될 뿐이다.
따라서 중요한 것은, 기획자가 확신을 가질 수 없고, 섣부른 신념을 가져서도 안되는 게임 디자인에 대하여... '우리'가 참여하여 함께 논의하고 다듬으며 공유하는 프로세스를 갖추는 것이다.
아 혹여 이것을 '그냥 기획자가 무능한거네', 혹은 '그럴거면 기획자가 무슨 소용이야?', 또는 '기획자만 편하게 만들어 줄 뿐이잖아?'라고 받아들이는 분이 있다면 다시 생각해 보시길.
우리가 만드는 게임을 위하여 과연 무엇이 최선의 길이고 - 궁극적으로는 최상의 재미를 이끌어낼 수 있는 길인가?
이 질문에 정답을 제시할 수 있는 사람은 아무도 없다. 나는 이것이 '인간'에게는 불가능한 것이라 생각한다.
그렇기 때문에 이 문제의 해답은 그 게임을 만드는 이들 모두가 함께 찾아가야 한다. 즉 '개발팀의 역량을 모두 합쳐서 찾아낸, 그만큼의 길'이 그 개발팀에게는 해답이 되는 것이다.
이 중요한 작업을 누군가에게 전담시켜서는 안된다. 개발은 '우리'가 하는 것이지 '개인'이 하는 것이 아니다. 그리고 디자인은 그 개발의 시작... 당연히 '우리'가 함께 해야 하는 시작 지점인 것이다.
그러므로 이러한 프로세스를 갖추는 것이... 기획자만 편해지고, 괜히 다른 직군의 어깨에 더 무거운 짐을 얹는다는 생각을 해서는 곤란하다.
아 물론 기획자가 만들어서 던지는 일을 수동적으로 받아서 하는 상황에 비해 보자면, 어깨에 얹어지는 짐이 더 무거워질 수는 있다. 그러나 그 짐은 원래 모든 팀원의 어깨 위에 있어야만 하는 짐이었다.
이것이 부당하게 여겨지는가? 하지만 그 짐을 기획자에게 던지는 순간, 기획자는 부당한 권력(!)을 가지게 되고, 개발자는 일개 톱니바퀴가 될 수밖에 없으며, 프로젝트의 성공 가능성은 그만큼 낮아진다. 그것이 옳은가? 프로젝트는 성공하기 위하여 진행하는 것인데도?
그렇기 때문에, 우리 팀이 현재 채택하고 있는...
누구에게도 결정을 전담시키지 않고 논의를 통해 결정한다.
다양한 통로를 통하여 끊임없이 개발팀 내에서 공유하고 공유하며 또 공유한다.
다양한 통로를 통하여 끊임없이 개발팀 내에서 공유하고 공유하며 또 공유한다.
...라는 프로세스가 나는 옳다고 생각한다.
프로젝트를 위해서도. 개발팀을 위해서도. 그리고 기획자를 위해서도.
이런 환경이 갖추어지고, 기획자가 그 어깨에 지워진 부당한 짐을 덜어낼 수 있다면... 그럼 기획자는 이제 무슨 일을 해야 할까? 기획자의 고유 업무라고 했던 게임 디자인과 밸런싱에만 주력하면 되나?
아니.
이젠 개발팀의, 개발 프로세스의 보약이 되도록 노력해야 하는 일이 남아있다.
드디어 기획자는 계속 언급해 온 7단계에 마음놓고 최대한 적극적으로 개입할 수 있게 되는 것이다.
아니, 이런 환경에서는 기획자가 아무리 '독점'을 하려 들어도 애초에 독점이 발생할 수 없다. 얏호~ 기획자로서는 실로 신나는 상황인 것이다.
최대한 자신이 가진 역량을 발휘하고, 오지랖을 파바박 넓히면서, 잡부 근성으로 개발의 단계 단계마다 매끄럽게 기름칠을 하면 할수록... 그것이 개발에 도움이 된다. 결코 독이 되지 않는다.
무엇보다도 두려운 지점, '과연 내가 한 게임 디자인이 최선인가?'라는 질문에 대하여 홀로 고민할 필요도 없다. 그 대답은 '우리'가 함께 찾아 줄 것이다. '우리'가 '우리'의 역량 내에서 최선이라 믿는 길로.
마음놓고 모호함의 강물을 힘껏 헤엄쳐 나아가기만 하면 되는 것이다.
그리고 얼마나 더 멀리 나아갈 수 있을는지는 이제 전적으로 개인의 역량에 달려있게 된다.
남은 것은 '노예처럼 일하셈!!!' 뿐.
물론 여러 번 이야기한 바와 같이, 우리 개발팀의 프로세스라고 해서 우주 최강은 아니다 -_-a
[7번 글]에서 언급한 취약점들, 혹은 앞으로도 미치 깨닫지 못한 문제들이 산적해 있을 것이다.
하지만 그럼에도 불구하고... 뭐 식견 짧은 내가 듣고 봐온 중에서는, 기획이라는 직군의 독소는 독소대로 골라내면서, 등골을 쏙쏙 잘도 뽑아먹는 효율적인(?) 구조인 듯.
피식. 마지막은 또 용비어천가인가효.
뭐 읽으시는 분들이 알아서 걸러낼 것은 걸러내고, 혹은 보완할 것은 보완해 가면서 참고하시는 수밖에 없다능 -ㅅ-
언젠가 훗날, 좀 더 내공이 쌓인 후에 이 글을 다시 보게 된다면... 나는 지금 쓰잘데기 없이 길게만 주절거린 이 내용들을 비웃을 수 있을까?
'게임 기획자는 무엇무엇을 하는 사람이지. 게임 디자인이란 이러저러한 거잖아. 왜 그 때엔 이 명확한 걸 몰랐지? 피식.'
... 요로코롬 내가 나를 비웃을 수 있는 날이 오기를 기대하며, 암튼 이번에는 이것으로 끝.
쓰잘데기 없는 내용인 주제에 스크롤만 길고, 논리도 마구마구 튀는 두서없고 재미없는 글 읽어주신 분들께... (와우 내 블록에서 이런 식으로 말 해보기는 되게 오랜만인 것 같아 -_-) 감사드림미다 -ㅁ-/
|
Trackback Address :: http://glekang.com/trackback/345
|
[글강, 2009/02/05 00:14, Game]
게임 기획자가 뭐하는 놈들인지에 대한 질문에서부터 시작하야... 이제는 무슨 프로세스 이야기를 하고 있나효. 삼천포도 이런 삼천포가 업ㅂ는... ㄱ-
하지만 나름 연계되는 부분은 있다. (라고 믿자. 믿어주세효 ;ㅁ;)
그러므로 다시 전진~
NC Soft에서 Blade&Soul의 개발을 총괄하고 있는 배재현 전무가 KGC 2008에서 진행한 PT에는 다음과 같은 내용이 포함되어 있다.
물론 해당 세션을 직접 들은 것이 아닌지라, 얼핏 거칠어(?) 보이는 저 말의 이면에 어떠한 의미가 숨어있는 것인지를 명확하게 캐치할 수는 없지만...
추측하기로는 '게임 어셋 혹은 디자인을 결정함에 있어, 집단 창작이라는 허울 좋은 미명 하에 정치적(?) 타협이 존재해서는 안된다', '의사 결정권자는 명확해야 하며, 독재적 지위를 보장받아야 한다'라는 맥락을 가지는 것이 아닐까 싶다.
뭐 설마 천재 한명이 독재로 이끌어가는 개발 프로세스를 천명한 것은 아니었을거라 생각한다 ;;; 난 여전히 그것이 '인간'에게 가능한 일이라 생각하지 않는다.
혹여 가능하다 할지라도 [5번 글]에서 언급한 디자인의 독점 지위를 '기획자'가 아닌 '디렉터'에게 부여하는 경우, 발생하는 리스크는 여전히 존재할 것이므로 심히 곤란.
그런 의미에서 보자면... 현재 우리 팀이 채택하고 있는 프로세스는 다소 민주적이라고도 할 수 있겠는데, 그럼 타협과 모호한 의사 결정의 문제가 난무하고 있는 것일까?
그렇지는 않다고 생각한다.
이거이 우리 개발팀의 프로세스가 돌아가기 위하여 반드시 필요한 전제라고도 생각되는 부분인데... 다음과 같은 이유에 의하여 우리 개발팀의 민주적인(?) 프로세스는 유지된다.
1. 최종 결정은 디렉터가 한다. 디렉터의 독재적 지위가 위협받아서는 안된다.
2. 디렉터의 독재적 지위는 권위로 연결되지 않아야 한다.
3. 논의는 치열하게, 하지만 감정의 골이 발생하지는 않아야 한다.
4. 개발 팀원들이 어느 정도의 경험과 식견, 그리고 양식을 갖추고 있어야 한다.
5. 우리가 개발 중인 게임이 어떤 게임인지, 현재 어디 즈음에 와 있는지를 끊임없이 리마인드 해주는 프로세스를 갖추고 있어야 한다.
... 잠깐. 뭔가 또 용비어천가로 흘러가는 분위기인데...
글쎄 세상일이라는게 그렇게 단순하지는 않아서, 당연히 단점이 존재한다니까 -ㅅ-a
그럼 내가 보기에 우리 개발팀의 프로세스가 가지는 취약점은 무엇인지 한번 나열해 보도록 합세.
1. 아무래도 논의가 많다보니 적잖은 시간을 요구한다. 자칫 비효율적이다.
2. 정말 모든 개발팀원들이 게임 어셋의 모든 부분을 공유하고 있다고?
3. 개발팀원에게 높은 수준의 능동성을 요구하며, 강한 스트레스를 유발시킨다(?)
4. 개발 인원이 많은 경우에도 이러한 프로세스를 적용할 수 있을까?
에에... 이 프로세스가 기획자라는 직군에게 어떠한 의미를 부여하는지, 이 프로세스는 어째서 기획자를 개발에 이득이 되는 존재로 승화시키는지에 대한 이야기를 해야 하는데 -ㅁ-;
또 쓰잘데기 없이 길어져 버렸네 ㄱ- 이 무슨 갈수록 스크롤 압뷁이야 ;;;
... 그래서 결국 8번 글까지 가게 되는근 ㄱ-;;; 처음엔 한 3연작 정도면 끝날 줄 알았는데 ;;;
그래도 이제 남은건 결론 뿐이다.
게임 기획자란 대체 뭐하는 놈들인가... 에 대한 명쾌한 대답은 못될지라도, 게임 기획자는 어떠한 프로세스에서 쓸모있는 놈들이 되는가... 에 대한 대답 정도는 이제 내 경험의 한도 내에서 제시할 수 있을 듯.
그럼 마지막 글에서 ( '')
하지만 나름 연계되는 부분은 있다. (라고 믿자. 믿어주세효 ;ㅁ;)
그러므로 다시 전진~
NC Soft에서 Blade&Soul의 개발을 총괄하고 있는 배재현 전무가 KGC 2008에서 진행한 PT에는 다음과 같은 내용이 포함되어 있다.
집단 창작으로 게임은 만들어 지지 않는다.
게임은 민주적으로 만들어 지지 않는다.
게임은 민주적으로 만들어 지지 않는다.
물론 해당 세션을 직접 들은 것이 아닌지라, 얼핏 거칠어(?) 보이는 저 말의 이면에 어떠한 의미가 숨어있는 것인지를 명확하게 캐치할 수는 없지만...
추측하기로는 '게임 어셋 혹은 디자인을 결정함에 있어, 집단 창작이라는 허울 좋은 미명 하에 정치적(?) 타협이 존재해서는 안된다', '의사 결정권자는 명확해야 하며, 독재적 지위를 보장받아야 한다'라는 맥락을 가지는 것이 아닐까 싶다.
뭐 설마 천재 한명이 독재로 이끌어가는 개발 프로세스를 천명한 것은 아니었을거라 생각한다 ;;; 난 여전히 그것이 '인간'에게 가능한 일이라 생각하지 않는다.
혹여 가능하다 할지라도 [5번 글]에서 언급한 디자인의 독점 지위를 '기획자'가 아닌 '디렉터'에게 부여하는 경우, 발생하는 리스크는 여전히 존재할 것이므로 심히 곤란.
그런 의미에서 보자면... 현재 우리 팀이 채택하고 있는 프로세스는 다소 민주적이라고도 할 수 있겠는데, 그럼 타협과 모호한 의사 결정의 문제가 난무하고 있는 것일까?
그렇지는 않다고 생각한다.
이거이 우리 개발팀의 프로세스가 돌아가기 위하여 반드시 필요한 전제라고도 생각되는 부분인데... 다음과 같은 이유에 의하여 우리 개발팀의 민주적인(?) 프로세스는 유지된다.
1. 최종 결정은 디렉터가 한다. 디렉터의 독재적 지위가 위협받아서는 안된다.
이건 뭐 너무나도 당연한 이야기. 이게 흔들리면 배가 산으로, 하늘로, 안드로메다로 날아간다.
2. 디렉터의 독재적 지위는 권위로 연결되지 않아야 한다.
즉 결정을 위한 논의 과정에서는 디렉터조차도 결국 한 사람의 발언자 지위에 머물러야 하며, 권위에 의한 압박이 없어야만 한다. 더불어 서로에 대한 정치적 배려(?)를 기반으로 한 타협같은건 애초에 존재하지도 말아야 한다. 그리하야... 쪼까 과장을 섞어보자면 이런 양상이 만들어져야 한다.
...
... 어랏 적어놓고 보니 되게 소모적이네? ㄲㄲㄲ 하지만 나무를 보지 말고 숲을 보시라능.
저런 논의를 거치고 거치면서, 치열하게 치고 받으며 결정하되 절대 '타협'은 하지 않는다. 그렇다고 쓸데없는 고집을 피우지도 않으면서, 가장 합리적이고 최적화된 결론을 도출하기 위하여, 자칫 산으로 가버리는 배를 모두가 끌어내리면서 집중한다. 그리고 결국 최종 결정은 디렉터가 하며, 여기에 대해서는 이의를 제기하지 않는다.
다행히 지금까지 '절대 아니라고 생각하지만 디렉터가 까라고 하니까 깐다 내 참 더러워서'라는 상황은 발생하지 않았다. 모호하게 구부러지며 타협하는 상황 역시 발생하지 않았다. 그리고 이런 추세라면 앞으로도 발생하지 않을 듯 싶고... 애초에 나라는 인간부터가 까란다고 곱게 깔 생각이 없기 때문에 ( '')
디렉터 : 이런 아이디어 죽이지 않아?
개발자A : 당신 바보야?
개발자B : 당신 바보지?
디렉터 : 아놔 이러저러해서 끝내주잖아!
개발자A : 아놔 요로조로해서 말도 안되자늠!
개발자B : 아놔 이리저리하면 말은 되겠지만 역시 해괴한데?
디렉터 : 어 그럼 이리저리하면서 요로조로한 문제를 해결하면 의도에도 부합하게 되지 않나?
개발자A : 아니 그보다는 이러쿵 저러쿵한 쪽이 더 낫지 않아?
개발자B : 당신 바보야?
디렉터 : 당신 바보지?
개발자A : 당신 바보야?
개발자B : 당신 바보지?
디렉터 : 아놔 이러저러해서 끝내주잖아!
개발자A : 아놔 요로조로해서 말도 안되자늠!
개발자B : 아놔 이리저리하면 말은 되겠지만 역시 해괴한데?
디렉터 : 어 그럼 이리저리하면서 요로조로한 문제를 해결하면 의도에도 부합하게 되지 않나?
개발자A : 아니 그보다는 이러쿵 저러쿵한 쪽이 더 낫지 않아?
개발자B : 당신 바보야?
디렉터 : 당신 바보지?
...
... 어랏 적어놓고 보니 되게 소모적이네? ㄲㄲㄲ 하지만 나무를 보지 말고 숲을 보시라능.
저런 논의를 거치고 거치면서, 치열하게 치고 받으며 결정하되 절대 '타협'은 하지 않는다. 그렇다고 쓸데없는 고집을 피우지도 않으면서, 가장 합리적이고 최적화된 결론을 도출하기 위하여, 자칫 산으로 가버리는 배를 모두가 끌어내리면서 집중한다. 그리고 결국 최종 결정은 디렉터가 하며, 여기에 대해서는 이의를 제기하지 않는다.
... 넵. 대신 곱게 최종 결정을 내리도록 가만 놔두질 않는거졈 ( '')
다행히 지금까지 '절대 아니라고 생각하지만 디렉터가 까라고 하니까 깐다 내 참 더러워서'라는 상황은 발생하지 않았다. 모호하게 구부러지며 타협하는 상황 역시 발생하지 않았다. 그리고 이런 추세라면 앞으로도 발생하지 않을 듯 싶고... 애초에 나라는 인간부터가 까란다고 곱게 깔 생각이 없기 때문에 ( '')
3. 논의는 치열하게, 하지만 감정의 골이 발생하지는 않아야 한다.
이게 되게 중요하면서도 쉽지 않은 부분이기는 한데... 뭐랄까 다행히 우리 팀의 구성원들은 다들 사회 생활을 꽤 오래 경험한 고령자(-_-)들이 많은지라, 나름 프로페셔널하고 쿨하다.
더불어 대부분의 팀원들이 이미 예전 프로젝트부터 함께 일하던 이들인지라... 협업 경험이 보통 3~4년 이상씩은 훌쩍 넘어가는 팀. 서로를 어떻게 긁어대면 되는지를 잘 알고 있다 ㄲㄲㄲ
이건 사실 그냥 우리 팀이 가지고 있는 행운이 아닐까 싶기도.
더불어 대부분의 팀원들이 이미 예전 프로젝트부터 함께 일하던 이들인지라... 협업 경험이 보통 3~4년 이상씩은 훌쩍 넘어가는 팀. 서로를 어떻게 긁어대면 되는지를 잘 알고 있다 ㄲㄲㄲ
이건 사실 그냥 우리 팀이 가지고 있는 행운이 아닐까 싶기도.
4. 개발 팀원들이 어느 정도의 경험과 식견, 그리고 양식을 갖추고 있어야 한다.
즉 '우리'가 게임을 만들어 나간다는 비전에 모두가 공감대를 형성하고 있어야 한다. 그렇지 않으면 아무리 게임 디자인을 공유하고 오만 난리를 피워도... 애초에 응할 마음이 없는 사람에게는 하등 소용이 없기 때문.
다행히 우리 팀의 구성원들은 대부분 게임 바닥에서 꽤 오래 구른 분들인지라 (이제 개발 경력이 5년 정도 되는 내가 막내뻘), 그리고... 안타까운 일이지만 고생은 고생대로 하고서는 결국 게임을 말아먹은 경험을 함께 공유하고 계시는 분들인지라 ㄱ- 저 기조의 중요성을 뼈저리게 인지하고 있는 듯 싶다.
더불어 이는 2번에서의 논의가 자칫 소모적인 양상으로 빠지는 위험을 해소하는 데에도 도움을 준다. 다들 짬밥이 좀 되니까 -ㅅ- 말같잖은 뻘소리는 애초에 잘 나오지 않는다.
이것도 3번과 더불어 그냥 우리 팀이 가지고 있는 행운인 듯 싶다능.
다행히 우리 팀의 구성원들은 대부분 게임 바닥에서 꽤 오래 구른 분들인지라 (이제 개발 경력이 5년 정도 되는 내가 막내뻘), 그리고... 안타까운 일이지만 고생은 고생대로 하고서는 결국 게임을 말아먹은 경험을 함께 공유하고 계시는 분들인지라 ㄱ- 저 기조의 중요성을 뼈저리게 인지하고 있는 듯 싶다.
더불어 이는 2번에서의 논의가 자칫 소모적인 양상으로 빠지는 위험을 해소하는 데에도 도움을 준다. 다들 짬밥이 좀 되니까 -ㅅ- 말같잖은 뻘소리는 애초에 잘 나오지 않는다.
이것도 3번과 더불어 그냥 우리 팀이 가지고 있는 행운인 듯 싶다능.
5. 우리가 개발 중인 게임이 어떤 게임인지, 현재 어디 즈음에 와 있는지를 끊임없이 리마인드 해주는 프로세스를 갖추고 있어야 한다.
'개발자가 자신이 만드는 게임에 대해 파악하는 것, 그리고 자신이 속한 개발팀의 현재 상황을 아는 것'은 당연히 필요한 일이고 매우 중요한 일이다... 라지만 이거이 생각처럼 쉽게 달성되는 것은 또 아니다.
'개발자라면 당연히 저런 자세를 가져야 하지 않아?'라고 말하기는 쉽겠지만, 애초에 개발팀 내에 이러한 리마인드를 지속적으로 해주는 프로세스가 갖추어져 있지 않으면서 그냥 강요만 한다면... 결국은 죽도 밥도 아니될 뿐.
따라서 개발 프로세스 내에 이를 위한 자원 혹은 일정을 정기적으로 마련해야 하고, 그 외에도 개발 현황판 등의 시각적 요소를 통한 리마인드 역시 필요하다.
주의할 점은... 현황판은 아날로그여야 한다는 점. 흔히 디지털 - 보통 웹을 통한 - 이 아무래도 더 깔끔하고 업데이트 및 공유, 관리하기에 편하다는 생각을 할 수 있는데... 그러나 디지털은 아날로그에 비해 접근성이 떨어진다. 웹을 통한 액세스가 모든 이에게 편리할 것이라는 생각은 편견임. (특히 고령자들에게... 어머나 내가 무슨 말을...)
그래서 우리 팀은... 뭐 정기적인 팀 회의를 일단 기본적인 공유의 시간으로 활용하고 있으며, 현황판은... 넵. 와보신 분들은 아시겠지만 우리 사무실 벽면을 온통 덕지덕지 뒤덮고 있지효 -ㅅ-
'개발자라면 당연히 저런 자세를 가져야 하지 않아?'라고 말하기는 쉽겠지만, 애초에 개발팀 내에 이러한 리마인드를 지속적으로 해주는 프로세스가 갖추어져 있지 않으면서 그냥 강요만 한다면... 결국은 죽도 밥도 아니될 뿐.
따라서 개발 프로세스 내에 이를 위한 자원 혹은 일정을 정기적으로 마련해야 하고, 그 외에도 개발 현황판 등의 시각적 요소를 통한 리마인드 역시 필요하다.
주의할 점은... 현황판은 아날로그여야 한다는 점. 흔히 디지털 - 보통 웹을 통한 - 이 아무래도 더 깔끔하고 업데이트 및 공유, 관리하기에 편하다는 생각을 할 수 있는데... 그러나 디지털은 아날로그에 비해 접근성이 떨어진다. 웹을 통한 액세스가 모든 이에게 편리할 것이라는 생각은 편견임. (특히 고령자들에게... 어머나 내가 무슨 말을...)
그래서 우리 팀은... 뭐 정기적인 팀 회의를 일단 기본적인 공유의 시간으로 활용하고 있으며, 현황판은... 넵. 와보신 분들은 아시겠지만 우리 사무실 벽면을 온통 덕지덕지 뒤덮고 있지효 -ㅅ-
... 잠깐. 뭔가 또 용비어천가로 흘러가는 분위기인데...
글쎄 세상일이라는게 그렇게 단순하지는 않아서, 당연히 단점이 존재한다니까 -ㅅ-a
그럼 내가 보기에 우리 개발팀의 프로세스가 가지는 취약점은 무엇인지 한번 나열해 보도록 합세.
1. 아무래도 논의가 많다보니 적잖은 시간을 요구한다. 자칫 비효율적이다.
... 프로토타이핑에만 1년 가까이 쓴거 같은데 말이졈. 그 과정에서 참... 오래오래 징하게도 싸웠다능.
그렇다고 지금 실개발 단계에서는 또 안싸우느냐, 그럴리가효.
즉 아무래도 논의 베이스이다 보니, 뭐 하나 결정하는 데에도 논의 - 논쟁 - 논의 - 논쟁 왔다갔다... 적잖은 시간을 소모한다.
뭐 하지만 아직은 이러한 시간 소모가 오히려 긍정적이라고 생각된다. 섣부른 개발보다는 이렇게 신중한 개발을 진행하는 것이 - 그리고 거기에 소요되는 시간은 정당하게 지출되는 비용이라 생각하는 것이 맞는 듯.
다만 추후에... 대중에게 게임을 공개하는 시점을 넘어서게 되면, 이제는 시간을 우리 마음대로 쓰지 못하는 상황이 '반드시' 닥쳐오게 될 것이다. 그 때엔 인해전술로 쏟아져 나올 다양한 이슈에 대하여 어떻게 기민한 대처를 할 수 있도록 프로세스를 재정립할 것인가...
이거이 우리에게 남아있는 숙제랄까.
그렇다고 지금 실개발 단계에서는 또 안싸우느냐, 그럴리가효.
즉 아무래도 논의 베이스이다 보니, 뭐 하나 결정하는 데에도 논의 - 논쟁 - 논의 - 논쟁 왔다갔다... 적잖은 시간을 소모한다.
뭐 하지만 아직은 이러한 시간 소모가 오히려 긍정적이라고 생각된다. 섣부른 개발보다는 이렇게 신중한 개발을 진행하는 것이 - 그리고 거기에 소요되는 시간은 정당하게 지출되는 비용이라 생각하는 것이 맞는 듯.
다만 추후에... 대중에게 게임을 공개하는 시점을 넘어서게 되면, 이제는 시간을 우리 마음대로 쓰지 못하는 상황이 '반드시' 닥쳐오게 될 것이다. 그 때엔 인해전술로 쏟아져 나올 다양한 이슈에 대하여 어떻게 기민한 대처를 할 수 있도록 프로세스를 재정립할 것인가...
이거이 우리에게 남아있는 숙제랄까.
2. 정말 모든 개발팀원들이 게임 어셋의 모든 부분을 공유하고 있다고?
100%라고 한다면 물론 거짓말. 팀 전체에게 공유되는 부분은 아무래도 각종 어셋들의 header 정도이다. 세부 항목까지 모두 공유했다가는... 공유하는 데에만 시간을 다 쓸테니 ㄱ- 사실 그렇게까지 필요하지는 않고.
(예를 들자면 나는 우리 게임에 림 라이트가 대충 어떻게 사용된다... 라는 정도까지만 알 뿐, 그래서 구체적인 세팅은 어떻게 하나효... 뭐 이런 부분에 대해서는 그냥 모른다 -ㅁ- 거기까지 내가 알아야 함? AD와 TD를 믿읍시다 -ㅁ- 다만 내 눈에 영 이상하게 보인다면 용감무식하게 '때깔이 이상하자늠?'이라는 의견은 손쉽게 낼 수 있어야 하는거고)
그리고 인간이란 망각의 동물인지라, 아무래도 자신의 직군과 직접 연계되지 않는 부분에 대해서는 공유받는다 할지라도 시간이 좀 지나면 쉽사리 까먹게 된다. 아니 이건 자연스러운 일이니 뭐라 할 수 없다.
그럼에도 불구하고 한 번이나마 이야기를 들었던 사안은, 추후 리마인드할 때 기억을 떠올리기가 상대적으로 수월하기 때문에... 이거이 딱히 문제가 된 적은 없다.
다만 잠재적인 리스크는, 나중에 게임 어셋의 수가 지금보다 훨씬 더 많아지고, 복잡성이 증대되었을 때에도 지금과 같은 긍정적인 상황을 유지할 수 있을 것인가... 으음... 잘 모르겠다.
(예를 들자면 나는 우리 게임에 림 라이트가 대충 어떻게 사용된다... 라는 정도까지만 알 뿐, 그래서 구체적인 세팅은 어떻게 하나효... 뭐 이런 부분에 대해서는 그냥 모른다 -ㅁ- 거기까지 내가 알아야 함? AD와 TD를 믿읍시다 -ㅁ- 다만 내 눈에 영 이상하게 보인다면 용감무식하게 '때깔이 이상하자늠?'이라는 의견은 손쉽게 낼 수 있어야 하는거고)
그리고 인간이란 망각의 동물인지라, 아무래도 자신의 직군과 직접 연계되지 않는 부분에 대해서는 공유받는다 할지라도 시간이 좀 지나면 쉽사리 까먹게 된다. 아니 이건 자연스러운 일이니 뭐라 할 수 없다.
그럼에도 불구하고 한 번이나마 이야기를 들었던 사안은, 추후 리마인드할 때 기억을 떠올리기가 상대적으로 수월하기 때문에... 이거이 딱히 문제가 된 적은 없다.
다만 잠재적인 리스크는, 나중에 게임 어셋의 수가 지금보다 훨씬 더 많아지고, 복잡성이 증대되었을 때에도 지금과 같은 긍정적인 상황을 유지할 수 있을 것인가... 으음... 잘 모르겠다.
3. 개발팀원에게 높은 수준의 능동성을 요구하며, 강한 스트레스를 유발시킨다(?)
... 즉 바꿔 말하자면 일단 신입은 살아남기 힘든 구조이다 -ㅅ- 프로세스가 개발자에게 '우리는 이런 게임을 만들거등. 너 이거 다 알아야 해. 하지만 자세한 설명은 생략한다. 대충 말해도 다 알아듣겠지?'라는 부분을 계속 강요(?)하는 구조이기 땜시...
더불어 누군가 일을 던져주는 수동적인 프로세스가 아니라, 능동적으로 개발의 흐름을 지속적으로 조망하며 자신의 일을 찾아서 해야 하는 구조이기 때문에... 팀원에게 요구되는 능동성의 수준이 높다. 양날의 검이랄까? 이 흐름에 맞추어 잘하면 당연히 좋지만, 잘 못하는 경우에는... 으음 이럴 땐 또 가차없죠 -ㅅ-
그나마 다들 닳고 닳은(?) 경력자들이고, 또 대부분 파트장급 이상 출신들이 많은지라 이런 프로세스를 돌릴 수 있는 것이 아닐까?
그리고 더불어... 사실 이건 난 잘 모르겠는 부분이긴 한데, 이러한 프로세스는 개발자로 하여금 끝없는 자기 성찰(?)을 요구하고, 그만큼 또 강한 스트레스를 유발시키는 듯 싶다.
... 나야 '내 역량이 모자른다 싶으면 자르시등가. 거기까지가 내 한계인갑지. 어쩔라미?'라는 뻔뻔한 배째라 정신으로 무장하고 있기 때문에 잘 모르겠는데 -ㅅ-;;;, 몇몇 이들은 일이 자신에게 요구하는 수준을 자신이 충족시키지 못하고 있다는 생각에 괴로워하는 모습을 보이곤 한다.
으음... 내가 보기엔 다들 잘하고 있는 것 같은데 -ㅁ- 일헌 자기 자신에게 지나치게 엄격한 살암들 같으니 ;;;
아무튼 그런 문제가 있는 것... 같다.
더불어 누군가 일을 던져주는 수동적인 프로세스가 아니라, 능동적으로 개발의 흐름을 지속적으로 조망하며 자신의 일을 찾아서 해야 하는 구조이기 때문에... 팀원에게 요구되는 능동성의 수준이 높다. 양날의 검이랄까? 이 흐름에 맞추어 잘하면 당연히 좋지만, 잘 못하는 경우에는... 으음 이럴 땐 또 가차없죠 -ㅅ-
그나마 다들 닳고 닳은(?) 경력자들이고, 또 대부분 파트장급 이상 출신들이 많은지라 이런 프로세스를 돌릴 수 있는 것이 아닐까?
그리고 더불어... 사실 이건 난 잘 모르겠는 부분이긴 한데, 이러한 프로세스는 개발자로 하여금 끝없는 자기 성찰(?)을 요구하고, 그만큼 또 강한 스트레스를 유발시키는 듯 싶다.
... 나야 '내 역량이 모자른다 싶으면 자르시등가. 거기까지가 내 한계인갑지. 어쩔라미?'라는 뻔뻔한 배째라 정신으로 무장하고 있기 때문에 잘 모르겠는데 -ㅅ-;;;, 몇몇 이들은 일이 자신에게 요구하는 수준을 자신이 충족시키지 못하고 있다는 생각에 괴로워하는 모습을 보이곤 한다.
으음... 내가 보기엔 다들 잘하고 있는 것 같은데 -ㅁ- 일헌 자기 자신에게 지나치게 엄격한 살암들 같으니 ;;;
아무튼 그런 문제가 있는 것... 같다.
실제로 이로 인해 뼈아픈 손실도 몇 번 있었고 크흑 ;ㅁ;
4. 개발 인원이 많은 경우에도 이러한 프로세스를 적용할 수 있을까?
사실 이거이 가장 아리까리한 부분인데... 20여명 정도의 중규모 팀에서는 이러한 프로세스를 운영하는 데에 별반 문제가 발생하지 않는다.
하지만 개발 인원이 5~60명, 혹은 수백명인 경우에도... 과연 이런 프로세스를 적용하는 것이 가능할까?
사실 [5번 글]에서 언급한 3번째 프로세스의 문제가 발생한 원인 중의 하나는 인원이 통제하기 힘들 정도로 많았다는 점이 아니었을까 싶다.
당장 손쉽게 생각할 수 있는 것은 역시 공유 자체의 난점. 직접 공유는 힘들고 간접 공유 체제를 만들어야 하지 않을까... 그 경우에 과연 이만큼의 효과를 기대할 수 있을까...?
이 부분을 잘 모르겠다. 이 프로세스는 과연 범용적일까? 대규모 인원에 대해서는 무언가 다른 방도를 찾아야하지 않을까?
... 뭐 당장 우리 개발팀에게는 별반 문제가 되지 않는 부분이지만, 그럼에도 불구하고 프로세스 자체에 대한 탐구로써, 이 부분은 여전히 의문으로 남는다.
하지만 개발 인원이 5~60명, 혹은 수백명인 경우에도... 과연 이런 프로세스를 적용하는 것이 가능할까?
사실 [5번 글]에서 언급한 3번째 프로세스의 문제가 발생한 원인 중의 하나는 인원이 통제하기 힘들 정도로 많았다는 점이 아니었을까 싶다.
당장 손쉽게 생각할 수 있는 것은 역시 공유 자체의 난점. 직접 공유는 힘들고 간접 공유 체제를 만들어야 하지 않을까... 그 경우에 과연 이만큼의 효과를 기대할 수 있을까...?
이 부분을 잘 모르겠다. 이 프로세스는 과연 범용적일까? 대규모 인원에 대해서는 무언가 다른 방도를 찾아야하지 않을까?
... 뭐 당장 우리 개발팀에게는 별반 문제가 되지 않는 부분이지만, 그럼에도 불구하고 프로세스 자체에 대한 탐구로써, 이 부분은 여전히 의문으로 남는다.
그래서 난 대규모 팀에 속해 있으면서, 대규모에 걸맞는 프로세스가 어떻게 구축되고 운영되는지를 알려주는 산업 스파이가 필요하...
에에... 이 프로세스가 기획자라는 직군에게 어떠한 의미를 부여하는지, 이 프로세스는 어째서 기획자를 개발에 이득이 되는 존재로 승화시키는지에 대한 이야기를 해야 하는데 -ㅁ-;
또 쓰잘데기 없이 길어져 버렸네 ㄱ- 이 무슨 갈수록 스크롤 압뷁이야 ;;;
... 그래서 결국 8번 글까지 가게 되는근 ㄱ-;;; 처음엔 한 3연작 정도면 끝날 줄 알았는데 ;;;
그래도 이제 남은건 결론 뿐이다.
게임 기획자란 대체 뭐하는 놈들인가... 에 대한 명쾌한 대답은 못될지라도, 게임 기획자는 어떠한 프로세스에서 쓸모있는 놈들이 되는가... 에 대한 대답 정도는 이제 내 경험의 한도 내에서 제시할 수 있을 듯.
그럼 마지막 글에서 ( '')
|
Trackback Address :: http://glekang.com/trackback/344
|
[글강, 2009/02/04 00:18, Game]
이건 뭐 재미도 없고 감동도 없는 글이 쓰잘데기 없이 길기만 욜라리 길어서리 벌써 6번일세 ㄱ-
이 즈음 해서 잠시 정리 좀.
[1번 글]에서는 기획자와 디렉터는 서로 다른 거라고 데꿀멍.
[2번 글]에서는 그럼 기획자가 대체 뭐하는 놈인지를 함 찾아보려다가 엉뚱하게 개발 순차만 찾아냈고.
[3번 글]에서는 개발 순차 내에서 기획자가 고유 업무라 할만한 거이 뭐가 있나 함 찾아보니, 게임 디자인과 밸런싱이라는 2가지를 찾을 수 있기는 했는데... 그래서 게임 디자인과 밸런싱이 대체 뭔데? 라고 물으니 애매모호 ㄱ-
[4번 글]에서는 그럼 애매모호하기 짝이 없는 기획자라는걸 개발팀에서 확 빼버리면 어떤 일이 일어날까 싶었더니... 개발 효율이 걱정되더라.
[5번 글]에서는 반대로 기획자에게 막강한 권한을 주어서 개발팀을 컨트롤하게 해버리면 어떤 일이 일어날까 싶었더니... 기획자가 열심히 일하면 일할수록 개발이 망가지는 난감한 사태가...
그래서 이제 6번부터는...
기획자가 '개발 효율을 드높이는 슈퍼 잡부(-_-)'와 '개발의 짐덩어리, 암적인 존재' 사이의 어딘가에서 제대로 안착하고 기능하기 위하야 필요한 것은 과연 무엇인가?! 에 대한 이야기.
넵. 저는 그게 개발 프로세스라고 생각해효.
그럼 개발 프로세스에 따라 기획자라는 존재의 가치는 달라질 수 있단 말인가? 심지어 개발에 도움이 되는 존재와 암적인 존재라는 양 극단을 오갈 정도로?
그렇지만 내 짤막한 경험에 비추어 보건데, 기획자는 언제나 같은 일을 하고 그 일을 열심히 하고 있음에도 불구하고, 그것이 어떤 때에는 개발에 도움이 되고 어떤 때에는 독이 되곤 한다.
그리고 그 구분선은 역시... 좀 성급할는지 모르겠지만 개발 프로세스라고 생각한다.
그런 의미에서 내가 생각하는 부정적인 프로세스, 그리고 긍정적인 프로세스에 대하여 이야기를 진행해 보겠다능.
지금까지 내가 경험해 본 개발 프로세스는 총 4가지.
사실 1번째과 2번째는 거의 똑같았는데... 이 녀석들을 여기에서 언급하지는 않도록 하고.
[5번 글]에서 언급했던 곤란한 상황이 바로 3번째 녀석이다. 물론 과장을 좀 많이 섞었다능. 실제로 저렇게까지 막장은 아니었졈. (혹은 사람에 따라 저것보다 더 심했다고 느낄 수는 있겠지만...)
암튼 3번째가 바로 내가 생각하는 부정적인 프로세스임.
그리고 지금 우리 개발팀에서 경험하고 있는 4번째 프로세스...
물론 나는 '이것이 최고의 개발 프로세스이다'라는 말은 감히 하지 못하겠고, 결국은 내 경험과 내 생각 안에서 판단을 내린다는 한계가 있지만...
그래도 지금 우리 팀이 채택하고 있는 프로세스는 기획자의 업무가 나름대로 개발에 기여하면서, 그러나 개발에 위험 요소로는 작용하지 않을 수 있는 구조라고 생각한다.
자 이젠 신물 나도록 지겨워지는 7단계를 다시 꺼내서, 우리 팀에서는 이 단계들이 어떻게 이루어 지는지를 검토해 보자.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 어셋 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
우와... 이게 뭐야.
적어놓고 보니 용비어천가도 이런 용비어천가가 없다능 ㄱ-
아니 그렇다고 무슨 우리 개발팀이 킹왕짱 울트라 하이퍼 우주최강 개발팀인 것은 아닌데 말이졈 (...)
당연히 이런 프로세스에도 취약점이랄까, 혹은 전제되고 충족되어야 하는 조건은 존재한다.
그리고 이런 프로세스가 기획자라는 직군에게 어떤 의미를 부여하는가... 에 대한 이야기는 아직 나오지도 않았졈.
하지만 이미 스크롤 압뷁 ㄱ-
... 7번으로 넘어가야 겠네효.
이 즈음 해서 잠시 정리 좀.
[1번 글]에서는 기획자와 디렉터는 서로 다른 거라고 데꿀멍.
[2번 글]에서는 그럼 기획자가 대체 뭐하는 놈인지를 함 찾아보려다가 엉뚱하게 개발 순차만 찾아냈고.
[3번 글]에서는 개발 순차 내에서 기획자가 고유 업무라 할만한 거이 뭐가 있나 함 찾아보니, 게임 디자인과 밸런싱이라는 2가지를 찾을 수 있기는 했는데... 그래서 게임 디자인과 밸런싱이 대체 뭔데? 라고 물으니 애매모호 ㄱ-
[4번 글]에서는 그럼 애매모호하기 짝이 없는 기획자라는걸 개발팀에서 확 빼버리면 어떤 일이 일어날까 싶었더니... 개발 효율이 걱정되더라.
[5번 글]에서는 반대로 기획자에게 막강한 권한을 주어서 개발팀을 컨트롤하게 해버리면 어떤 일이 일어날까 싶었더니... 기획자가 열심히 일하면 일할수록 개발이 망가지는 난감한 사태가...
그래서 이제 6번부터는...
기획자가 '개발 효율을 드높이는 슈퍼 잡부(-_-)'와 '개발의 짐덩어리, 암적인 존재' 사이의 어딘가에서 제대로 안착하고 기능하기 위하야 필요한 것은 과연 무엇인가?! 에 대한 이야기.
넵. 저는 그게 개발 프로세스라고 생각해효.
그럼 개발 프로세스에 따라 기획자라는 존재의 가치는 달라질 수 있단 말인가? 심지어 개발에 도움이 되는 존재와 암적인 존재라는 양 극단을 오갈 정도로?
... 와 이렇게까지 이야기하니 뭔가 좀 무서운데 -ㅁ-;
그렇지만 내 짤막한 경험에 비추어 보건데, 기획자는 언제나 같은 일을 하고 그 일을 열심히 하고 있음에도 불구하고, 그것이 어떤 때에는 개발에 도움이 되고 어떤 때에는 독이 되곤 한다.
그리고 그 구분선은 역시... 좀 성급할는지 모르겠지만 개발 프로세스라고 생각한다.
그런 의미에서 내가 생각하는 부정적인 프로세스, 그리고 긍정적인 프로세스에 대하여 이야기를 진행해 보겠다능.
지금까지 내가 경험해 본 개발 프로세스는 총 4가지.
사실 1번째과 2번째는 거의 똑같았는데... 이 녀석들을 여기에서 언급하지는 않도록 하고.
[5번 글]에서 언급했던 곤란한 상황이 바로 3번째 녀석이다. 물론 과장을 좀 많이 섞었다능. 실제로 저렇게까지 막장은 아니었졈. (혹은 사람에 따라 저것보다 더 심했다고 느낄 수는 있겠지만...)
암튼 3번째가 바로 내가 생각하는 부정적인 프로세스임.
그리고 지금 우리 개발팀에서 경험하고 있는 4번째 프로세스...
물론 나는 '이것이 최고의 개발 프로세스이다'라는 말은 감히 하지 못하겠고, 결국은 내 경험과 내 생각 안에서 판단을 내린다는 한계가 있지만...
그래도 지금 우리 팀이 채택하고 있는 프로세스는 기획자의 업무가 나름대로 개발에 기여하면서, 그러나 개발에 위험 요소로는 작용하지 않을 수 있는 구조라고 생각한다.
자 이젠 신물 나도록 지겨워지는 7단계를 다시 꺼내서, 우리 팀에서는 이 단계들이 어떻게 이루어 지는지를 검토해 보자.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
일단 의도의 설정. 디렉터의 업무라고 정의한 바 있지만, 그렇다고 또 디렉터가 독고다이로 할 필요까지는 없는 일. 개발팀원들의 도움을 받을 수 있는 일이다. (물론 최종 결정은 디렉터가 함미다.)
그래서 우리 팀에서는 애초에 의도 설정 단계에서부터 '논의'를 시작한다.
아트 디렉터 출신의 현 디렉터와, 클라이언트 파트장 출신의 부팀장 플머와, 역시 기획 파트장 출신의 기획자 셋이 기본적으로 모여서 '우리는 무엇을 만들고 싶은가'를 바닥부터 이야기하고...
여기에 더하여 이 셋이 잘 모르겠는 분야에서 무엇을 하고 싶은지를 결정해야 할 때엔, 해당 직군의 팀원을 논의에 참여시킨다.
여기에 또 더하여... 혹여 직군이 다르더라도, 논의되고 있는 분야에 대하여 관심을 가지고 있는 팀원이라면 얼마든지 논의 참여 가능.
그렇게 의도 단계에서부터 '우리'는 무엇을 만들고 싶은가를 논의하며, 최종 결정은 역시 디렉터가 한다.
이렇게 의도를 설정했다면... 이를 달성하기 위한 각종 디자인들의 제안 및 논의 진행 역시 의도 설정 단계와 동일하다.
대부분의 경우 위의 3명은 기본적으로 참여하면서, 추가적으로 해당 어셋의 구현 및 제작에 관여하게 되는 팀원들이 논의에 동참. 넵. 스크럼을 구성함미다.
물론 관심있다면 누구나 또 참여 가능. 그리고 만약 이렇게 논의를 진행했음에도 불구하고 딱히 좋은 아이디어가 나오지 아니하였다면... 팀 전체에 아이디어 공모 -ㅁ-/
... 그렇게 했음에도 불구하고 아니 나온 아이디어는 세상에 없는 (적어도 우리 개발팀의 역량을 벗어난) 것이므로, 지금까지 나온 녀석 중에서 가장 쓸만한 놈으로 채택.
그렇게 게임 어셋이 채택되는 바로 그 순간... 그 어셋의 구현과 제작에 관여하고 있는 팀원들은 모두 그 어셋이 어떤 의도를 충족시키는 것을 목적으로 하며, 어떻게 구현되고 제작될 것일는지를 모두 공유하고 있게 된다. 넵. 문서 별로 필요 없어효. 물론 망각을 견제하기 위한 정리는 해놓지만서도.
여기서 끝이 아니라능. 일단 채택된 게임 어셋에 관계된 이들 사이에서는 일차적으로 공유가 이루어졌다 할지라도, 다른 팀원들은?
세상에 유아독존할 수 있는 게임 어셋이라는 것은 없으며, 모든 게임 어셋은 다른 어셋들과 일정 부분 연계되는 지점을 가질 수 밖에 없다. 따라서 개발팀원들이 자신이 개발 중인 게임의 맥락을 놓치지 않으려면, 새롭게 채택된 게임 어셋에 대해서도 파악하고 있어야만 한다.
그래서 매주 팀 회의를 열고, 그 때 그 때 새롭게 채택된 게임 어셋들을 공유한다.
여기서 한발짝 더! 정말 중요한 게임 어셋이라면 아예 상황판 같은 데에 도식도 비슷한걸 만들어서 붙여버린다. 넵. 아날로그. 하지만 그만큼 접근성이 높다능.
... 이 모든 것은 결국 '우리'가 게임을 만들기 위하여. 누구라도 개발에서 소외되지 않기 위하여.
그래서 우리 팀에서는 애초에 의도 설정 단계에서부터 '논의'를 시작한다.
아트 디렉터 출신의 현 디렉터와, 클라이언트 파트장 출신의 부팀장 플머와, 역시 기획 파트장 출신의 기획자 셋이 기본적으로 모여서 '우리는 무엇을 만들고 싶은가'를 바닥부터 이야기하고...
여기에 더하여 이 셋이 잘 모르겠는 분야에서 무엇을 하고 싶은지를 결정해야 할 때엔, 해당 직군의 팀원을 논의에 참여시킨다.
여기에 또 더하여... 혹여 직군이 다르더라도, 논의되고 있는 분야에 대하여 관심을 가지고 있는 팀원이라면 얼마든지 논의 참여 가능.
그렇게 의도 단계에서부터 '우리'는 무엇을 만들고 싶은가를 논의하며, 최종 결정은 역시 디렉터가 한다.
이렇게 의도를 설정했다면... 이를 달성하기 위한 각종 디자인들의 제안 및 논의 진행 역시 의도 설정 단계와 동일하다.
대부분의 경우 위의 3명은 기본적으로 참여하면서, 추가적으로 해당 어셋의 구현 및 제작에 관여하게 되는 팀원들이 논의에 동참. 넵. 스크럼을 구성함미다.
물론 관심있다면 누구나 또 참여 가능. 그리고 만약 이렇게 논의를 진행했음에도 불구하고 딱히 좋은 아이디어가 나오지 아니하였다면... 팀 전체에 아이디어 공모 -ㅁ-/
... 그렇게 했음에도 불구하고 아니 나온 아이디어는 세상에 없는 (적어도 우리 개발팀의 역량을 벗어난) 것이므로, 지금까지 나온 녀석 중에서 가장 쓸만한 놈으로 채택.
그렇게 게임 어셋이 채택되는 바로 그 순간... 그 어셋의 구현과 제작에 관여하고 있는 팀원들은 모두 그 어셋이 어떤 의도를 충족시키는 것을 목적으로 하며, 어떻게 구현되고 제작될 것일는지를 모두 공유하고 있게 된다. 넵. 문서 별로 필요 없어효. 물론 망각을 견제하기 위한 정리는 해놓지만서도.
여기서 끝이 아니라능. 일단 채택된 게임 어셋에 관계된 이들 사이에서는 일차적으로 공유가 이루어졌다 할지라도, 다른 팀원들은?
세상에 유아독존할 수 있는 게임 어셋이라는 것은 없으며, 모든 게임 어셋은 다른 어셋들과 일정 부분 연계되는 지점을 가질 수 밖에 없다. 따라서 개발팀원들이 자신이 개발 중인 게임의 맥락을 놓치지 않으려면, 새롭게 채택된 게임 어셋에 대해서도 파악하고 있어야만 한다.
그래서 매주 팀 회의를 열고, 그 때 그 때 새롭게 채택된 게임 어셋들을 공유한다.
여기서 한발짝 더! 정말 중요한 게임 어셋이라면 아예 상황판 같은 데에 도식도 비슷한걸 만들어서 붙여버린다. 넵. 아날로그. 하지만 그만큼 접근성이 높다능.
... 이 모든 것은 결국 '우리'가 게임을 만들기 위하여. 누구라도 개발에서 소외되지 않기 위하여.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
기획자 고유 업무이긴 하지만, 이걸 나 혼자 하지는 않는다. 역시 또 '논의'라는 놈이 끼어드는데...
애초에 게임 어셋을 채택하는 과정에서 구현 및 제작을 직접 할 사람들이 참여했으므로, 이미 그 단계에서 어느 정도 구체적인 디자인까지도 진행되는 경우가 대부분이다.
그러니 사실 2번이라 명시한 이 단계에서 내가 하는 것은 좀 더 구체적인 스펙의 정리 정도?
물론 아이디어 단계에서는 놓쳐버릴 수 밖에 없는 구멍들이 있게 마련이므로, 이런 구멍들을 메우는 것은 내 일. 그러나 이조차도 나 혼자 독고다이로 '결정'을 해버리는 경우는 매우 드물다.
스크럼 단위에서 디자인을 다듬는 논의를 진행하고, 진행하며, 또 진행한다.
역시 이 모든 것은 결국 '우리'가 게임을 만들기 위하여.
다만 이렇게 구체적으로 디자인된 내용까지 팀 전체에 공유할 필요는 없다. 나중에 구현까지 완료된 후 그 결과물을 보여주면 되는거졈.
애초에 게임 어셋을 채택하는 과정에서 구현 및 제작을 직접 할 사람들이 참여했으므로, 이미 그 단계에서 어느 정도 구체적인 디자인까지도 진행되는 경우가 대부분이다.
그러니 사실 2번이라 명시한 이 단계에서 내가 하는 것은 좀 더 구체적인 스펙의 정리 정도?
물론 아이디어 단계에서는 놓쳐버릴 수 밖에 없는 구멍들이 있게 마련이므로, 이런 구멍들을 메우는 것은 내 일. 그러나 이조차도 나 혼자 독고다이로 '결정'을 해버리는 경우는 매우 드물다.
스크럼 단위에서 디자인을 다듬는 논의를 진행하고, 진행하며, 또 진행한다.
역시 이 모든 것은 결국 '우리'가 게임을 만들기 위하여.
다만 이렇게 구체적으로 디자인된 내용까지 팀 전체에 공유할 필요는 없다. 나중에 구현까지 완료된 후 그 결과물을 보여주면 되는거졈.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
기획자들이 흔히 내지르는 비명. '죽어라 문서를 만들어봤자 아무도 안읽어!'라는 것은... 사실 해결이 난해한 일이다.
당장 기획자들 조차도 실제로 남이 쓴 문서는 잘 안보거등 -ㅅ- (저만 그런가효 ㅋ)
그래서 뭐 '기획 문서를 재미있게(?) 써서 남들이 보게 만드는 법' 같은게 대두되기도 하는데... 사실 제일 좋은 방법은 애초에 문서가 필요없게끔 만들어 버리는 것 아닌가?
어차피 문서라는 것은 두가지 목적을 가지는데, 바로 '공유'와 '기록'이다.
공유는... 우리 팀의 경우 1단계와 2단계를 거치면서 이미 다 되어버렸다. 얏호~ 따라서 만들어야 하는 문서는 그 논의 결과를 그냥 스펙의 형태로 기록하는 것 뿐. 구현을 진행하면서 참고할 수 있는 스펙 정도면 된다. 이미 자신이 참여했던 내용이 적혀있는 것이므로, 상대적으로 읽기도 편하다.
기록의 측면에서 보자면 중요한 것은 업데이트. 구현을 진행하면서 스펙이라는 것은 수시로 바뀌게 마련인데, 이 흐름을 트래킹할 수 있어야만 한다. 넵 그래서 우리는 WIKI를 씀미다. 오피스 문서는 진짜 필요할 때 아니면 잘 안써효.
당장 기획자들 조차도 실제로 남이 쓴 문서는 잘 안보거등 -ㅅ- (저만 그런가효 ㅋ)
그래서 뭐 '기획 문서를 재미있게(?) 써서 남들이 보게 만드는 법' 같은게 대두되기도 하는데... 사실 제일 좋은 방법은 애초에 문서가 필요없게끔 만들어 버리는 것 아닌가?
어차피 문서라는 것은 두가지 목적을 가지는데, 바로 '공유'와 '기록'이다.
공유는... 우리 팀의 경우 1단계와 2단계를 거치면서 이미 다 되어버렸다. 얏호~ 따라서 만들어야 하는 문서는 그 논의 결과를 그냥 스펙의 형태로 기록하는 것 뿐. 구현을 진행하면서 참고할 수 있는 스펙 정도면 된다. 이미 자신이 참여했던 내용이 적혀있는 것이므로, 상대적으로 읽기도 편하다.
... 물론 기획자가 특출난 문서 작성 능력을 발휘하야 가독성 높은 정리를 해주신다면 더욱 금상첨화이겠지만, 내가 그렇게 잘 하고 있는 것인지는 알 수 없으니 패스 ( --) 딱히 불만을 표출하시지는 않던데 말이졈 ㄷㄷㄷ
기록의 측면에서 보자면 중요한 것은 업데이트. 구현을 진행하면서 스펙이라는 것은 수시로 바뀌게 마련인데, 이 흐름을 트래킹할 수 있어야만 한다. 넵 그래서 우리는 WIKI를 씀미다. 오피스 문서는 진짜 필요할 때 아니면 잘 안써효.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
3번과 똑같다. 물론 구현이 아니라 제작이니까, 양식이랄까 그런건 좀 달라지지만 기본적인 기조는 동일하다.
모든 것은 '우리'가 게임을 만들기 위하여.
모든 것은 '우리'가 게임을 만들기 위하여.
5. 어셋 구현 후에는... 리소스들의 조립.
이건 기획자가 독고다이로 하게 되는 일이지만, 어차피 이전 단계에서 충분한 논의가 전제되었다면 기획자가 독고다이로 한다 해서 딱히 문제될 것은 없다.
그리고 레벨 디자인의 경우에는 여기에서 배경 제작자가 참여하므로 또 기획자 독고다이가 아니게 된다.
[4번 글]에서 언급한 바와 같이 이 단계는 아티스트의 센스가 발휘될 수 있는 부분. 그러니까 같이 한다.
그리고 레벨 디자인의 경우에는 여기에서 배경 제작자가 참여하므로 또 기획자 독고다이가 아니게 된다.
[4번 글]에서 언급한 바와 같이 이 단계는 아티스트의 센스가 발휘될 수 있는 부분. 그러니까 같이 한다.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
역시 기획자 고유 업무. 하지만 이 단계에서도 수많은 논의가 끼어들게 된다.
밸런싱을 하기 위하여 가장 기저에 존재하게 되는 기반 수치랄까, 기획용 상수같은 것들을 결정하는 데 근거가 되는 것은 결국 '우리는 무엇을 만들고 싶은가'의 지점이다.
만약 그 지점에서 뭔가 모호함이 발생한다면... 그럼 그건 또 논의를 하는거졈.
기저가 결정되면 거기에서부터 파생되는 미시적 밸런싱이야 물론 내가 하지만... 기저가 탄탄하다면, 필연적으로 따라오는 밸런싱 갈아엎기 작업도 상대적으로 쉬워지게 마련이고, 아울러 내가 헤까닥 돌아버리더라도 수치가 안드로메다로 날아가는 경우는 잘 발생하지 않는다.
즉 기획자가 밸런스를 안드로메다로 날려버릴 위험을 최소화하면서, 밸런스의 방향성에 대하여 모두가 공유하는 지점이 생기게 되는 것이다.
밸런싱을 하기 위하여 가장 기저에 존재하게 되는 기반 수치랄까, 기획용 상수같은 것들을 결정하는 데 근거가 되는 것은 결국 '우리는 무엇을 만들고 싶은가'의 지점이다.
만약 그 지점에서 뭔가 모호함이 발생한다면... 그럼 그건 또 논의를 하는거졈.
기저가 결정되면 거기에서부터 파생되는 미시적 밸런싱이야 물론 내가 하지만... 기저가 탄탄하다면, 필연적으로 따라오는 밸런싱 갈아엎기 작업도 상대적으로 쉬워지게 마련이고, 아울러 내가 헤까닥 돌아버리더라도 수치가 안드로메다로 날아가는 경우는 잘 발생하지 않는다.
즉 기획자가 밸런스를 안드로메다로 날려버릴 위험을 최소화하면서, 밸런스의 방향성에 대하여 모두가 공유하는 지점이 생기게 되는 것이다.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
자 즐거운 테스트 시간이야. 물론 테스트 업무 자체의 주도는 QA와 기획자가 하게 마련이지만, 참여는 모든 팀원이 함께 한다.
그리고 이 단계에서... 이미 공유된 게임 어셋의 구현 및 제작 결과물이 어떻게 나왔는지 여부를 팀원 전체가 재확인할 수 있게 된다.
뭔가 이상하다면? 자기가 알고 있던 것과 다른 지점이 있다면? 피드백을 날리는거임. 그리고 이런 피드백은 진정한 의미에서 피드백으로 작용할 수 있다.
그리고 이 단계에서... 이미 공유된 게임 어셋의 구현 및 제작 결과물이 어떻게 나왔는지 여부를 팀원 전체가 재확인할 수 있게 된다.
뭔가 이상하다면? 자기가 알고 있던 것과 다른 지점이 있다면? 피드백을 날리는거임. 그리고 이런 피드백은 진정한 의미에서 피드백으로 작용할 수 있다.
우와... 이게 뭐야.
적어놓고 보니 용비어천가도 이런 용비어천가가 없다능 ㄱ-
적는 내가 다 부끄러워서 손발이 오그라드네 ;;;
아니 그렇다고 무슨 우리 개발팀이 킹왕짱 울트라 하이퍼 우주최강 개발팀인 것은 아닌데 말이졈 (...)
당연히 이런 프로세스에도 취약점이랄까, 혹은 전제되고 충족되어야 하는 조건은 존재한다.
그리고 이런 프로세스가 기획자라는 직군에게 어떤 의미를 부여하는가... 에 대한 이야기는 아직 나오지도 않았졈.
하지만 이미 스크롤 압뷁 ㄱ-
... 7번으로 넘어가야 겠네효.
|
Trackback Address :: http://glekang.com/trackback/343
|
[글강, 2009/02/03 00:25, Game]
이제 슬슬 삼천포야 ㄱ-
뭐 시작부터 데꿀멍이었으니 삼천포로 좀 빠진다 해도 걍 그러려니 재미로 봐도 무방함 ( '')
이번엔 다른 관점에서 한 번 접근해 보자.
다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...
그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?
그럼 기획자라는 직군이 개발팀 내에서 가지는 가치 내지는 효용성 같은게 좀 더 명확하게 보이지 않을까?
개발팀을 구성하는 여러 직군들이 기획자라는 직군에 대하여 널리 가지고 있는 편견(?), 혹은 인상 중의 하나로... '일을 시키는, 혹은 만드는 사람'이라는 것이 있다.
이러한 인식은 아마도... 적지 않은 개발팀들이 다음과 같은 프로세스를 채택하고 있는 와중에 발생한 것이 아닌가 조심스레 추측해본다.
이제는 좀 지겨운 ;;; 7단계 다시 시작.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 어셋 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
요로코롬 각 단계를 기획자라는 직군이 '독점'해 버리는 경우... 이야 뭔가 기획자만의 고유 영역도 생기는 것 같고 좋은데?!
이런 프로세스라면 기획자는 아이디어를 내는 전문가이고, 게임 디자인의 전문가이고, 스펙 및 명세 작성의 전문가이며, 시스템 조립의 전문가, 그리고 밸런싱과 검증의 전문가인 것처럼 보인다.
즉, 재미 창출의 전문가처럼 보이게 되는 것이다.
더불어 이건 거의... 결정권자나 마찬가지이기까지 하다.
사실 저 단계들을 독점한다는 것은, 게임 어셋들의 디자인 및 구현 방향성을 컨트롤하게 된다는 것과 마찬가지가 되니까...
그러므로 프로그래머와 아티스트의 입장에서 보자면 기획자는 명백히 '일을 시키는 사람'이 된다.
그리하야... 전지전능한 기획자 어버이의 영도 아래 팀이 굴러가나니, 게임은 알흠답게 완성되... 려나?
과연?! 퍽이나?!
게임을 기획자 혼자서, 혹은 기획자들끼리만 만드나? 프로그래머와 아티스트는 그냥 톱니바퀴 부품인가효?
물론 이렇게 게임을 만들 수는 있다. 출시하는 데에 성공할 수도 있다.
코지마 히데오가 메기솔2를 이런 식으로 만들었다는 이야기를 들었던 것 같은데, 뭐 걍 루머인지도 모르겠지만 암튼 이론적으로야 이렇게 만들고서도 심지어 좋은 게임이 나올 수는 있다.
그러나 이런 식으로 좋은 게임이 나올 확률은 과연 얼마나 될까?
자신이 구현하고 제작하는 게임 어셋의 전후 맥락을 모른 채, 기계적으로 일한 결과물의 퀄리티를 얼마나 기대할 수 있을까?
글쎄... 아무래도 한계가 있지 않을까. 아무리 프로 정신으로 무장한다 하더라도, 애초에 퍼포먼스가 나올래야 나올 수가 없는 구조이기 때문에.
그리고 기획자가 신인가? 기획자는 완벽한 게임 어셋을 디자인 해내고, 전 직군에 걸친 업무 진행을 파악하고 있으며, 어떤 직군의 결과물이든 그 퀄리티를 검증해낼 수 있는 안목을 가진... 결정적으로 재미를 만들어낼 수 있는 존재인가?
글쎄... 절대로 한계가 있을 것 같은데. 천재를 상정하지 않는 한, 일반적인 확률로 우리가 만날 수 있는 범재에게서 과연 저런 능력을 기대할 수 있을까? 확실한 것은... 나 자신이 저런 존재가 못된다는 점과, 아직 저런 사람을 본 적이 없다는 점.
혹여 기획자가 이런 프로세스 하에서 아무리 성실하고 빡세게 일을 열심히 잘 진행한다 할지라도...
내 경험상, 혹은 편견상 아래와 같은 문제가 발생할 리스크는 여전히 남는다.
등등등. 이건 말 그대로 '일례'일 뿐이고... 하아.
수도 없이 경험했던 수많은 문제들을 일일이 나열하다가는, 안그래도 만만찮은 스크롤에 크리티컬이 뜰테니 이 정도만 -ㅁ-;
더구나 이런 문제들은 사실 깃털일 뿐이고, 보다 심각하게 따라오는 몸통이 있으니...
이런 프로세스가 진행되면 진행될수록, 각 직군들 사이에서는 감정의 골이 쌓이기가 쉬워진다.
게임 디자인의 독점은 직군 간의 소통을 저해하고, 소통이 없으니 신뢰가 생기기 힘들고, 신뢰는 없는데 일은 쌓이게 되고, 일은 쌓이는데 납득하기 힘든 부분이 생기다 보면... 결국 감정의 골이 생겨 버리는 것이... 어찌 보면 당연한 수순.
혹은 담배터에 모이는 사람들끼리만 소통을 해버리는 사태가 발생하기도 하는데 -_-a 이 경우에는 소통하는 이들과, 소통하지 못하는 이들 사이에... 뭔가 파벌 비슷한 것이 형성되기도 한다. 역시나 감정의 골로 가는 지름길 중의 하나.
어떤 식으로든 개발팀 내에서 감정의 골이 생기게 된다면... 뭐 더 할 말이 있나효.
결론을 내려 보자면...
기획자가 업무를 독점하면서 개발 진행 전반을 컨트롤하는 프로세스는,
기획자가 아무리 열심히 일을 잘 한다 할지라도,
개발팀의 다른 일원들과의 소통이 저해되기 쉬우며,
이는 개발팀의 일원들이 자신이 제작하는 게임에 대해 파악하지 못한 채,
기계적으로 일을 하게끔 만들어,
필연적으로(!) 수많은 문제를 야기하게 되고,
그러므로 결과물의 퀄리티를 보장하기가 힘들어지고,
최종적으로는 게임의 성공 가능성을 깎아먹게 된다.
... 그리고 게임이 실패한 경우, 욕은 기획자가 다 먹는다 -ㅁ-;;;
... 그리고 저러한 프로세스를 경험한 프로그래머와 아티스트는 이런 생각을 하게 된다.
'기획자가 시키는 대로 하니까 일도 잘 안되고, 결국 게임도 망하더라. 기획자는 믿을게 못된다.'
기획자 무용론에 동참하셨군효 /박수
자아, 다시 처음으로 돌아가보자.
다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...
그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?
결론은 기획자가 게임을 말아먹는(?) 상황에 처할 위험이 극도로 높아져 버린다.
역시 기획자 무용론은 진리인 건가효 -ㅁ-;;;
게임 기획자란 개발팀 내에서 그 비중이 높아지면 높아질 수록 개발의 짐덩어리가 되어버리는 직군인가효.
저 프로세스 내에서 기획자가 자신이 맡은 일을 정말 열심히, 성실하게, 악의없이, 최선을 다해 수행했다고 가정해보자.
그럼에도 불구하고...
그렇다고 해서 그 프로젝트가 성공할 확률이 과연 높아질까?
위에서 제시했던 문제들이 과연 발생하지 않을 수 있을까?
그리고 만약 프로젝트가 실패한다면... 기획자에게 책임의 무게가 씌워지는 것은 과연 부당한 일일까?
... 논리적으로만 보자면 그리 부당하지 않아 보이는데?
하아...? 잠깐만.
그럼 기획자라는건 열심히 일할수록 개발을 말아먹는 존재인가?
그럼 기획자라는걸 다 치워버리면 괜찮은건가?
하지만 기획자들을 다 치워버린 상황을 상정해 보자면...
[4번 글]에서도 이야기 했고, 당신도 쉽게 상상할 수 있겠지만... 그건 뭔가 좀 곤란하다.
그럼 무엇이 문제인가?
... 이미 충분히 길다. 다음 글로.
다음 글의 힌트.
저게 과연 기획자의 문제일까, 개발 프로세스의 문제일까?
뭐 시작부터 데꿀멍이었으니 삼천포로 좀 빠진다 해도 걍 그러려니 재미로 봐도 무방함 ( '')
이번엔 다른 관점에서 한 번 접근해 보자.
다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...
그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?
그럼 기획자라는 직군이 개발팀 내에서 가지는 가치 내지는 효용성 같은게 좀 더 명확하게 보이지 않을까?
개발팀을 구성하는 여러 직군들이 기획자라는 직군에 대하여 널리 가지고 있는 편견(?), 혹은 인상 중의 하나로... '일을 시키는, 혹은 만드는 사람'이라는 것이 있다.
이러한 인식은 아마도... 적지 않은 개발팀들이 다음과 같은 프로세스를 채택하고 있는 와중에 발생한 것이 아닌가 조심스레 추측해본다.
이제는 좀 지겨운 ;;; 7단계 다시 시작.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
여전히 의도는 디렉터가 설정하지만, 의도를 달성하기 위한 아이디어를 기획자'만' 내고, 기획자들끼리'만' 이 아이디어에 대해 논의한다. 뭐 디렉터가 여기 참여할 수는 있겠다만...
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
기획자'만' 게임 디자인을 한다. 즉 다른 직군과의 소통 없이 기획자 독고다이로.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
기획자 혼자서 작성한 구현 스펙을 '일방적으로' 프로그래머에게 전달한다. 프로그래머 입장에서는 이 스펙은 뜬금없이 떨어진 일이 되고, 게임
어셋의 전후 맥락을 파악하지 못한 상황에서 '기계적으로' 구현만 하게 된다. 물론 상호 논의를 통해 스펙을 수정하는 가운데
일방성이 조금 완화될 수는 있지만, 프로그래머가 맥락에서 소외되어 있다는 점은 여전히 변하지 않는다.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
기획자 혼자서 작성한
리소스 제작 명세를 '일방적으로' 아티스트에게 전달한다. 아티스트 입장에서는 이 명세는 뜬금없이 떨어진 일이 되고, 게임 어셋의
전후 맥락을 파악하지 못한 상황에서 '기계적으로' 제작만 하게 된다. 물론 상호 논의를 통해 명세를 수정하는 가운데 일방성이
조금 완화될 수는 있지만, 아티스트가 맥락에서 소외되어 있다는 점은 여전히 변하지 않는다.
5. 어셋 구현 후에는... 리소스들의 조립.
게임 어셋의 조립을 기획자'만' 한다.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
밸런싱을 기획자'만' 한다.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
테스트 및 검증을 QA와 기획자'만' 한다. 뭐 사람이 부족하면 다른 팀원들을 테스트에 참여시킬 수는 있겠다만, 검증해야 할 지점의 설정이나 피드백은 오직 기획자'만'.
요로코롬 각 단계를 기획자라는 직군이 '독점'해 버리는 경우... 이야 뭔가 기획자만의 고유 영역도 생기는 것 같고 좋은데?!
이런 프로세스라면 기획자는 아이디어를 내는 전문가이고, 게임 디자인의 전문가이고, 스펙 및 명세 작성의 전문가이며, 시스템 조립의 전문가, 그리고 밸런싱과 검증의 전문가인 것처럼 보인다.
즉, 재미 창출의 전문가처럼 보이게 되는 것이다.
더불어 이건 거의... 결정권자나 마찬가지이기까지 하다.
사실 저 단계들을 독점한다는 것은, 게임 어셋들의 디자인 및 구현 방향성을 컨트롤하게 된다는 것과 마찬가지가 되니까...
그러므로 프로그래머와 아티스트의 입장에서 보자면 기획자는 명백히 '일을 시키는 사람'이 된다.
그리하야... 전지전능한 기획자 어버이의 영도 아래 팀이 굴러가나니, 게임은 알흠답게 완성되... 려나?
과연?! 퍽이나?!
게임을 기획자 혼자서, 혹은 기획자들끼리만 만드나? 프로그래머와 아티스트는 그냥 톱니바퀴 부품인가효?
물론 이렇게 게임을 만들 수는 있다. 출시하는 데에 성공할 수도 있다.
코지마 히데오가 메기솔2를 이런 식으로 만들었다는 이야기를 들었던 것 같은데, 뭐 걍 루머인지도 모르겠지만 암튼 이론적으로야 이렇게 만들고서도 심지어 좋은 게임이 나올 수는 있다.
그러나 이런 식으로 좋은 게임이 나올 확률은 과연 얼마나 될까?
자신이 구현하고 제작하는 게임 어셋의 전후 맥락을 모른 채, 기계적으로 일한 결과물의 퀄리티를 얼마나 기대할 수 있을까?
글쎄... 아무래도 한계가 있지 않을까. 아무리 프로 정신으로 무장한다 하더라도, 애초에 퍼포먼스가 나올래야 나올 수가 없는 구조이기 때문에.
그리고 기획자가 신인가? 기획자는 완벽한 게임 어셋을 디자인 해내고, 전 직군에 걸친 업무 진행을 파악하고 있으며, 어떤 직군의 결과물이든 그 퀄리티를 검증해낼 수 있는 안목을 가진... 결정적으로 재미를 만들어낼 수 있는 존재인가?
글쎄... 절대로 한계가 있을 것 같은데. 천재를 상정하지 않는 한, 일반적인 확률로 우리가 만날 수 있는 범재에게서 과연 저런 능력을 기대할 수 있을까? 확실한 것은... 나 자신이 저런 존재가 못된다는 점과, 아직 저런 사람을 본 적이 없다는 점.
혹여 기획자가 이런 프로세스 하에서 아무리 성실하고 빡세게 일을 열심히 잘 진행한다 할지라도...
내 경험상, 혹은 편견상 아래와 같은 문제가 발생할 리스크는 여전히 남는다.
기획자 : 고민에 고민을 거듭해서 디자인 문서를 완벽하게(?) 만들었는데 아무도 안읽어! 뭐 하나 구현하고 제작할 때마다 계속
사람들을 감독(!)해야 하다니 아놔! 게임 나 혼자 만드냐?! 왜 이렇게들 자신이 만드는 게임에 관심이 없어? 게임의 전체적인
상에 대해서 당연히 다들 파악하고 있어야 하는거 아냐?!
프로그래머 : 뭐 이런 해괴한 시스템이 다 있노? 아무래도 이건 일관성에 문제가 있는 것 같... 기는 한데, 뭐 다른 부분들과의 연계 때문에 어쩔 수 없이 이렇게 된 것일라나? 다른 시스템을 모르니 할 말이 없네...
그런데 나한테 갑자기 50페이지짜리 문서를 휙 던져주면서, 3중 4중으로 연결된 다른 문서들도 참고해가며 구현을 하라니 어이가 좀 상실된다능.
어 잠깐만, 이거 구현하려면 예전에 만들었던 알고리즘을 갈아엎어야 하잖아? 아니 지난번에 이거 구현할 때엔 나중에 이런게 나올거라는 이야기 안하더니만!!!
그런데 나한테 갑자기 50페이지짜리 문서를 휙 던져주면서, 3중 4중으로 연결된 다른 문서들도 참고해가며 구현을 하라니 어이가 좀 상실된다능.
어 잠깐만, 이거 구현하려면 예전에 만들었던 알고리즘을 갈아엎어야 하잖아? 아니 지난번에 이거 구현할 때엔 나중에 이런게 나올거라는 이야기 안하더니만!!!
아티스트 : 만들라고 하니까 만들기는 하겠지만, 대체 이것들이 우리 게임 어디에 들어가는거지? 어라 이렇게 만들면 비쥬얼
퀄리티가 확 떨어질텐데? 다른 부분에서 퍼포먼스를 잡아먹기 때문에 어쩔 수 없는건가? 다른 부분을 모르니 할 말이 없네...
그런데 뜬금없이 날아온 컨셉 문서가 50페이지 -_-a 다 읽다가 지친다.
어 잠깐만, 이렇게 제작하면 전반적인 비쥬얼 컨셉이랑 어긋나잖아? 음? 비쥬얼 컨셉보다는 기능성을 우선하기로 결정했다고? 언제? 난 몰랐는데? 그냥 까라면 까라는거냐!!!
그런데 뜬금없이 날아온 컨셉 문서가 50페이지 -_-a 다 읽다가 지친다.
어 잠깐만, 이렇게 제작하면 전반적인 비쥬얼 컨셉이랑 어긋나잖아? 음? 비쥬얼 컨셉보다는 기능성을 우선하기로 결정했다고? 언제? 난 몰랐는데? 그냥 까라면 까라는거냐!!!
등등등. 이건 말 그대로 '일례'일 뿐이고... 하아.
수도 없이 경험했던 수많은 문제들을 일일이 나열하다가는, 안그래도 만만찮은 스크롤에 크리티컬이 뜰테니 이 정도만 -ㅁ-;
더구나 이런 문제들은 사실 깃털일 뿐이고, 보다 심각하게 따라오는 몸통이 있으니...
이런 프로세스가 진행되면 진행될수록, 각 직군들 사이에서는 감정의 골이 쌓이기가 쉬워진다.
게임 디자인의 독점은 직군 간의 소통을 저해하고, 소통이 없으니 신뢰가 생기기 힘들고, 신뢰는 없는데 일은 쌓이게 되고, 일은 쌓이는데 납득하기 힘든 부분이 생기다 보면... 결국 감정의 골이 생겨 버리는 것이... 어찌 보면 당연한 수순.
혹은 담배터에 모이는 사람들끼리만 소통을 해버리는 사태가 발생하기도 하는데 -_-a 이 경우에는 소통하는 이들과, 소통하지 못하는 이들 사이에... 뭔가 파벌 비슷한 것이 형성되기도 한다. 역시나 감정의 골로 가는 지름길 중의 하나.
어떤 식으로든 개발팀 내에서 감정의 골이 생기게 된다면... 뭐 더 할 말이 있나효.
결론을 내려 보자면...
기획자가 업무를 독점하면서 개발 진행 전반을 컨트롤하는 프로세스는,
기획자가 아무리 열심히 일을 잘 한다 할지라도,
개발팀의 다른 일원들과의 소통이 저해되기 쉬우며,
이는 개발팀의 일원들이 자신이 제작하는 게임에 대해 파악하지 못한 채,
기계적으로 일을 하게끔 만들어,
필연적으로(!) 수많은 문제를 야기하게 되고,
그러므로 결과물의 퀄리티를 보장하기가 힘들어지고,
최종적으로는 게임의 성공 가능성을 깎아먹게 된다.
... 그리고 게임이 실패한 경우, 욕은 기획자가 다 먹는다 -ㅁ-;;;
결국 기획자 잘못이니까 욕먹을 만 하다고? 글쎄.
... 그리고 저러한 프로세스를 경험한 프로그래머와 아티스트는 이런 생각을 하게 된다.
'기획자가 시키는 대로 하니까 일도 잘 안되고, 결국 게임도 망하더라. 기획자는 믿을게 못된다.'
결국 기획자 잘못이니까 그런 생각이 맞다고? 글쎄.
기획자 무용론에 동참하셨군효 /박수
자아, 다시 처음으로 돌아가보자.
다른 직군이 하려 들면 딱히 못할 것도 없는, 그러나 또 기획자라는 직군이 맡아주는게 아무래도 효율좋아 보이는 일들을...
그럼 아예 대놓고 기획자의 고유 업무라고 가정하고, 기획자가 '독점'해 버리는 상황을 상정해 본다면...?
결론은 기획자가 게임을 말아먹는(?) 상황에 처할 위험이 극도로 높아져 버린다.
역시 기획자 무용론은 진리인 건가효 -ㅁ-;;;
게임 기획자란 개발팀 내에서 그 비중이 높아지면 높아질 수록 개발의 짐덩어리가 되어버리는 직군인가효.
글쎄. 나는 의문이 든다.
저 프로세스 내에서 기획자가 자신이 맡은 일을 정말 열심히, 성실하게, 악의없이, 최선을 다해 수행했다고 가정해보자.
그럼에도 불구하고...
그렇다고 해서 그 프로젝트가 성공할 확률이 과연 높아질까?
위에서 제시했던 문제들이 과연 발생하지 않을 수 있을까?
그리고 만약 프로젝트가 실패한다면... 기획자에게 책임의 무게가 씌워지는 것은 과연 부당한 일일까?
... 논리적으로만 보자면 그리 부당하지 않아 보이는데?
하아...? 잠깐만.
그럼 기획자라는건 열심히 일할수록 개발을 말아먹는 존재인가?
그럼 기획자라는걸 다 치워버리면 괜찮은건가?
하지만 기획자들을 다 치워버린 상황을 상정해 보자면...
[4번 글]에서도 이야기 했고, 당신도 쉽게 상상할 수 있겠지만... 그건 뭔가 좀 곤란하다.
그럼 무엇이 문제인가?
... 이미 충분히 길다. 다음 글로.
다음 글의 힌트.
저게 과연 기획자의 문제일까, 개발 프로세스의 문제일까?
|
Trackback Address :: http://glekang.com/trackback/342
|
[글강, 2009/02/02 00:04, Game]
쓰면 쓸수록 '내가 이 글을 왜 시작한거랍쇼'라는 생각이 들고 있기는 하지만 -_-a
뭐 그래도 솔직히 내 인생, 내 커리어의 지금 이 시점에서 내 생각은 이러하다.
... 라고 정리, 기록하는 의미 정도는 가질 수 있을테니 계속 용감무식무쌍하게 전진 -ㅁ-/
자 자, 개발 수순의 구간에서 기획자의 전문성이 드러나는 지점을 찾아보는 것은... 일단 2가지 정도 짚을 수는 있었지만, 그 2가지는 모호함의 경계가 너무나도 넓다는 정도로 결론 ㄱ-
그래서 결국 기획자가 대체 뭐하는 놈들인지에 대한 이야기는, 그나마 희뿌옇게 무언가 보이기는 하지만서도 그거이 뭔지는 모르겠는, 혹은 알지만 너무 넓어서 모르는 거나 마찬가지인 상황 ㄱ-
그러니 여전히 '이런 애매모호한 직군 따위 필요없어'에 대한 반박은 쉽지 않은 상황이다.
아놔 데꿀멍 함 하기 참 힘드네 (...)
그럼 이번에는 기획자를 함 없애보자.
기획자를 없애고도 개발이 매끄럽게 잘 진행된다고 예상된다면... 뭐 기획자 따위 별로 필요없는거졈 ㅋ
일단 기획이라는 일이 사라질 수는 없다. 기획 없는 개발이라는건... 설계도 안하고 건물을 냅다 짓겠다는 셈이니 말이 아니된다.
즉 기획자를 없앤다는 것은... 결국 기획 업무를 다른 직군이 맡는다는 뜻이 된다.
과연 어떤 일이 벌어질까요?
일단 개발은 여전히 7단계의 수순을 따라 진행된다고 가정해보자. [2번 글]에서도 언급한 바와 같이 저건 협업 체제 개발 수순으로도 얼마든지 치환할 수 있으니까.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 어셋 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
정리해 보자면... 우와... 기획자 없이도 어케어케 일이 되기는 하겠는데?
다만 크리티컬한 문제로 대두되는 부분은 '개발 효율'이 극도로 떨어질 가능성이 높다는 지점.
그럼 기획자는 개발 효율을 높이기 위해 존재하는 건가효...?
'잡부'라는 생각이 다시 고개를 들이밀기 시작하지만... -_-a
뭐 반장난스럽게 평가절하스러븐 단어를 사용한다 할지라도, 개발 효율이라는건 매우매우 무지무지 중요한 요소이므로, 기획자는 있는 편이 좋다! 라는 실로 알흠다운 결론이 나오는군요.
음헤헤. '나는 그냥 월급 도둑이란 말인가?'라는 존재론적인(?) 자학에 빠져 사표 쓸 필요는 없겠다 (...)
자 '기획자 따위 필요없어!'에 대한 대답은... 실로 대충 떼워막기로 해버린 듯 싶지만 암튼 어떻게 했다고 치자.
그런데 '기획자가 없다!'라고 가정을 해봤다면... 그 반대 급부에 대한 의문이 꼬리를 물고 나오는근염.
만약 기획자가 저 모든 걸 다 맡아서 해치운다면 과연 어떻게 될까?
호옹... 어떤 양상으로 흘러갈는지 벌써 감이 딱 오기는 하는데...
아마도 '기획자 따위 필요없어!'라는 주장을 아직 포기하고 싶지 않으신 분들이 기꺼워 할만한 내용으로 채워질...
다음 글에서 ( '')
뭐 그래도 솔직히 내 인생, 내 커리어의 지금 이 시점에서 내 생각은 이러하다.
... 라고 정리, 기록하는 의미 정도는 가질 수 있을테니 계속 용감무식무쌍하게 전진 -ㅁ-/
자 자, 개발 수순의 구간에서 기획자의 전문성이 드러나는 지점을 찾아보는 것은... 일단 2가지 정도 짚을 수는 있었지만, 그 2가지는 모호함의 경계가 너무나도 넓다는 정도로 결론 ㄱ-
그래서 결국 기획자가 대체 뭐하는 놈들인지에 대한 이야기는, 그나마 희뿌옇게 무언가 보이기는 하지만서도 그거이 뭔지는 모르겠는, 혹은 알지만 너무 넓어서 모르는 거나 마찬가지인 상황 ㄱ-
그러니 여전히 '이런 애매모호한 직군 따위 필요없어'에 대한 반박은 쉽지 않은 상황이다.
아놔 데꿀멍 함 하기 참 힘드네 (...)
그럼 이번에는 기획자를 함 없애보자.
기획자를 없애고도 개발이 매끄럽게 잘 진행된다고 예상된다면... 뭐 기획자 따위 별로 필요없는거졈 ㅋ
일단 기획이라는 일이 사라질 수는 없다. 기획 없는 개발이라는건... 설계도 안하고 건물을 냅다 짓겠다는 셈이니 말이 아니된다.
즉 기획자를 없앤다는 것은... 결국 기획 업무를 다른 직군이 맡는다는 뜻이 된다.
과연 어떤 일이 벌어질까요?
일단 개발은 여전히 7단계의 수순을 따라 진행된다고 가정해보자. [2번 글]에서도 언급한 바와 같이 저건 협업 체제 개발 수순으로도 얼마든지 치환할 수 있으니까.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
[3번 글]에서도 언급한 바와 같이... 의도의 설정은 애초에 디렉터라는 '직급'에서 해야 할 일이고, 아이디어의 제안은 기획자만 할 수 있는 일이 아니다. 적절한 상상력과 게임에 대한 이해력을 갖추고 있다면 누구라도(넵 물론 비개발자도) 할 수 있는 일이다.
물론 적절한 아이디어를 채택하기 위한 논의 진행은 해당 개발팀의 상황에 따라 양상이 많이 달라질 수 있으므로, 이건 개발팀에 소속된 개발자들이 진행하는 것이 맞겠지만... 그렇다고 꼭 기획자라는 직군이 그 논의 테이블에 존재해야 하는 것은 아니다.
... 그럼에도 불구하고 개발 중인 게임 전반을 통찰하고 있는 기획자가 이 논의에 참여하는 경우, 일은 조금 더 매끄럽게 진행될 수 있다.
이 정도일 듯.
물론 적절한 아이디어를 채택하기 위한 논의 진행은 해당 개발팀의 상황에 따라 양상이 많이 달라질 수 있으므로, 이건 개발팀에 소속된 개발자들이 진행하는 것이 맞겠지만... 그렇다고 꼭 기획자라는 직군이 그 논의 테이블에 존재해야 하는 것은 아니다.
... 그럼에도 불구하고 개발 중인 게임 전반을 통찰하고 있는 기획자가 이 논의에 참여하는 경우, 일은 조금 더 매끄럽게 진행될 수 있다.
이 정도일 듯.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
기획자 고유의 업무! 근데 만약 기획자가 없다면?!
... 예측하건데 아마도 프로그래머 직군에서 이 일을 담당할 수 있지 않을까?
게임 디자인을 하기 위해서는 논리력이랄까, 게임의 공학적 구조에 대한 이해가 어느 정도 필요한데... 프로그래머는 이러한 소양을 이미 자기 직군의 기본 소양으로 가지고 있다.
그래서 프로그래머 출신의 기획자가 적지 않은 듯 싶기도 하지만, 암튼 저 기본 소양의 위에 경험이나 분석 능력 등이 덧대어 지기만 한다면 프로그래머는 충분히 게임 디자인을 할 수 있을 듯 싶다.
아티스트는? 글쎄... 이거이 좀 편견에 가까운데, 논리력이라면 모르겠지만 게임의 공학적 구조에 대한 소양은 아티스트의 기본 소양은 아닌 듯 싶어서, 아티스트에게 이걸 요구하는게 맞는건지 잘 모르겠다.
(다만 이거이 레벨 디자인이나 퀘스트 디자인의 영역으로 확장되면 센스가 반드시 필요해지는 부분이 있으니, 아티스트가 또 이런 센스는 발군일 듯도 싶고 -ㅅ-)
... 물론 그럼에도 불구하고 프로그래머는 비싼 몸. 디자인은 만만찮은 시간을 잡아먹는 일이고, 디자인된 시스템에 대한 지속적인 유지 보수가 꼭 필요하다. 프로그래머를 여기에 투입하는게 과연 '효율적'인가? 라고 한다면 좀 갸우뚱. 개발 효율이라는 측면에서 볼 때 이 일을 따로 맡는 이가 있는 쪽이 아무래도 나을 듯.
... 예측하건데 아마도 프로그래머 직군에서 이 일을 담당할 수 있지 않을까?
게임 디자인을 하기 위해서는 논리력이랄까, 게임의 공학적 구조에 대한 이해가 어느 정도 필요한데... 프로그래머는 이러한 소양을 이미 자기 직군의 기본 소양으로 가지고 있다.
그래서 프로그래머 출신의 기획자가 적지 않은 듯 싶기도 하지만, 암튼 저 기본 소양의 위에 경험이나 분석 능력 등이 덧대어 지기만 한다면 프로그래머는 충분히 게임 디자인을 할 수 있을 듯 싶다.
아티스트는? 글쎄... 이거이 좀 편견에 가까운데, 논리력이라면 모르겠지만 게임의 공학적 구조에 대한 소양은 아티스트의 기본 소양은 아닌 듯 싶어서, 아티스트에게 이걸 요구하는게 맞는건지 잘 모르겠다.
(다만 이거이 레벨 디자인이나 퀘스트 디자인의 영역으로 확장되면 센스가 반드시 필요해지는 부분이 있으니, 아티스트가 또 이런 센스는 발군일 듯도 싶고 -ㅅ-)
... 물론 그럼에도 불구하고 프로그래머는 비싼 몸. 디자인은 만만찮은 시간을 잡아먹는 일이고, 디자인된 시스템에 대한 지속적인 유지 보수가 꼭 필요하다. 프로그래머를 여기에 투입하는게 과연 '효율적'인가? 라고 한다면 좀 갸우뚱. 개발 효율이라는 측면에서 볼 때 이 일을 따로 맡는 이가 있는 쪽이 아무래도 나을 듯.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
넵. 프로그래머. 자기가 만들걸 자기가 직접 정리하는 거니까 오히려 훨씬 더 잘할는지도 (...)
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
넵. 아티스트. 역시 자기가 만들걸 자기가 직접 정리하는 거니까...
5. 어셋 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
요이. 또 기획자의 고유 업무.
그러나 기획자가 없다면 이걸 누가 하지?
흔히 밸런싱이라 쓰고 '계산'이라 읽는 경우가 많으니 프로그래머가 적격일는지도... 하지만 뭐 여기에 쓰이는 계산이 딱히 거창한 것도 아니니 아티스트가 이걸 못할 이유도 없고...
그러니 각 직군에서 자신이 참여한 부분에 대한 밸런싱을 직접하는 방법도 생각해볼 수는 있다. 다만 이 경우에는 직교성이랄까 수치 스케일이랄까 그런 기준들을 잡기가 쉽지 않으니, 만만찮은 시행 착오와 밸런스가 안드로메다로 날아가고 귀환하는 일이 반복되는 비효율적인 흐름이 예상되는데...
그런 의미에서 그냥 깔끔하게 기획자가 다 맡아준다면 좀 낫기는 하겠다. 에... 근거는 역시 또 개발 효율인가효?
그러나 기획자가 없다면 이걸 누가 하지?
흔히 밸런싱이라 쓰고 '계산'이라 읽는 경우가 많으니 프로그래머가 적격일는지도... 하지만 뭐 여기에 쓰이는 계산이 딱히 거창한 것도 아니니 아티스트가 이걸 못할 이유도 없고...
그러니 각 직군에서 자신이 참여한 부분에 대한 밸런싱을 직접하는 방법도 생각해볼 수는 있다. 다만 이 경우에는 직교성이랄까 수치 스케일이랄까 그런 기준들을 잡기가 쉽지 않으니, 만만찮은 시행 착오와 밸런스가 안드로메다로 날아가고 귀환하는 일이 반복되는 비효율적인 흐름이 예상되는데...
그런 의미에서 그냥 깔끔하게 기획자가 다 맡아준다면 좀 낫기는 하겠다. 에... 근거는 역시 또 개발 효율인가효?
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
넵. 원래 QA의 업무임 ㄳ
근데 이 과정에서 애초에 디자인을 한 사람이 참여하지 않는다면 검증, 보정 참 힘들죠.
그러니까 이 부분 전담해 줄 디자이너가... 아 기획자 없애기로 했으니 전담할 사람이 없어져 버렸나?
뭐 없이도 어떻게 할 수는 있겠지만, 역시 있는 쪽이 더 매끄러울 듯.
근데 이 과정에서 애초에 디자인을 한 사람이 참여하지 않는다면 검증, 보정 참 힘들죠.
그러니까 이 부분 전담해 줄 디자이너가... 아 기획자 없애기로 했으니 전담할 사람이 없어져 버렸나?
뭐 없이도 어떻게 할 수는 있겠지만, 역시 있는 쪽이 더 매끄러울 듯.
정리해 보자면... 우와... 기획자 없이도 어케어케 일이 되기는 하겠는데?
다만 크리티컬한 문제로 대두되는 부분은 '개발 효율'이 극도로 떨어질 가능성이 높다는 지점.
그럼 기획자는 개발 효율을 높이기 위해 존재하는 건가효...?
'잡부'라는 생각이 다시 고개를 들이밀기 시작하지만... -_-a
뭐 반장난스럽게 평가절하스러븐 단어를 사용한다 할지라도, 개발 효율이라는건 매우매우 무지무지 중요한 요소이므로, 기획자는 있는 편이 좋다! 라는 실로 알흠다운 결론이 나오는군요.
음헤헤. '나는 그냥 월급 도둑이란 말인가?'라는 존재론적인(?) 자학에 빠져 사표 쓸 필요는 없겠다 (...)
자 '기획자 따위 필요없어!'에 대한 대답은... 실로 대충 떼워막기로 해버린 듯 싶지만 암튼 어떻게 했다고 치자.
그런데 '기획자가 없다!'라고 가정을 해봤다면... 그 반대 급부에 대한 의문이 꼬리를 물고 나오는근염.
만약 기획자가 저 모든 걸 다 맡아서 해치운다면 과연 어떻게 될까?
호옹... 어떤 양상으로 흘러갈는지 벌써 감이 딱 오기는 하는데...
아마도 '기획자 따위 필요없어!'라는 주장을 아직 포기하고 싶지 않으신 분들이 기꺼워 할만한 내용으로 채워질...
다음 글에서 ( '')
|
Trackback Address :: http://glekang.com/trackback/341
|
[글강, 2009/02/01 00:03, Game]
[2번 글]에서 말한 바와 같이, 이번엔 개발 수순에서 기획자만의 고유한 전문성이 개입하는 구간을 함 고민해봅세.
기획자만의 전문성?!
... 그러니까 이게 뭔지를 알면 문제가 참 간단해지는 셈인데 -ㅅ- 가장 아리까리한 부분이기도 하다능.
기획자라는 타이틀을 달고 있는 주제에, 내 직업을 명확하게 정의조차 내리지 못하다니 참으로 쓸모업ㅂ는 놈이로다... 싶지만 ㄱ-
뭐 그래도 계속 함 가봅세.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 어셋 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
... 라고 한다면. 자 정리해보자.
1번부터 7번까지 중에서, 내가 보기에 기획자라는 직군의 성격을 규정짓는다고 할만한 작업은 게임 디자인과 밸런싱 2가지이다.
그러나 그래서 게임 디자인과 밸런싱에 있어 어떠한 전문성이 요구되는가... 라고 한다면 여전히 그 점에 있어서는 모호함이 나를 휘어 감싼다.
물론 필요한 스킬이 '없다'라고 할 수는 없다. 즉 일반인과 게임 기획자를 가르는 선은 분명히 존재한다.
'그 선은 이 지점이다'라고 명확히 할 수는 없겠지만, 사실 이런 식으로 분해해 가면서 접근한다면 어느 직군이든 그 선은 1차원적인 구분자로 존재하는 것이 아닌, 2차원적인 면으로서 존재할 것이다.
하지만 역시 기획자는 그 면이 너무 넓다 ㄱ-
일단 나열하기 시작하자면... 이 뭐 인문학 거의 전반, 혹은 이학이나 공학까지도 넘나들게 되어버리는 것이다. 그렇다고 또 어느 분야에 대해 Master가 될 필요까지는 없고, 이 분야 저 분야 모두 툭툭 건드림에 부족함이 없는 정도면 족하다.
(그러니 '게임 기획자가 되려면 어떻게 해야 하나효?'라는 질문에 대하여 우리가 해줄 수 있는 대답이라는게 '게임 하나 만들어 보세효' 정도 밖에 못되는 것이다. 기획자로 넘어오는 선이 너무 넓으니까 차라리 통째로 함 해보라는... 그것 참 이게 정답이라고 생각하기는 하지만, 이게 정답이라는 사실은 사실 참 슬픈 사실이 아닐 수 업ㅂ다 ㄱ-)
그리하야... 결국 '개발팀의 잡부'라는 결론이 다시 튀어나와 버리는 것이다 -ㅁ-;;;
... 뭐 잡부라는 단어를 조금 부정적인 뉘앙스로 써서 단순히 거부감이 드는 것일는지도 모르겠지만 ㄱ-;
또는 기획자는 원래 저 모호함의 넓은 면에서 헤엄치는 존재가 맞는 것인지도 모르겠지만...
혹은 애초에 내가 진행한 사고 전개가 완전히 틀려먹은 것일는지도 모르겠지만...
어찌되었든 현재로서는 내가 게임 기획자라는 직군에 대하여 설명할 수 있는 지점은 이 정도이다.
워킹 딕셔너리, 혹은 개발의 짐덩어리 사이에서 모호하게 존재하는 직군이랄까 ㄱ-;
... 이 시점에서 '역시 게임 기획자 따위는 필요없군'이라 읊조리며 고개를 끄덕이는 당신을 위한 이야기는 다음 글에서 ( '')
기획자만의 전문성?!
... 그러니까 이게 뭔지를 알면 문제가 참 간단해지는 셈인데 -ㅅ- 가장 아리까리한 부분이기도 하다능.
기획자라는 타이틀을 달고 있는 주제에, 내 직업을 명확하게 정의조차 내리지 못하다니 참으로 쓸모업ㅂ는 놈이로다... 싶지만 ㄱ-
뭐 그래도 계속 함 가봅세.
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 어셋들의 제안 및 논의 진행.
일단 의도의 설정... 이건 기획자의 일이 아님미다. 디렉터라는 '직급'에서 해줘야 하는 부분이졈.
기획자들조차 쉽게 착각하는 부분이기도 한데, 게임의 상이랄까 혹은 기조를 뚜렷이 설정하고 결정하는 것은 디렉터가 해야 하는 일이지 기획자가 할 일은 아니예효.
물론 기획자가 그걸 도와줄 수는 있겠지만... 딱히 기획자만 도와줄 수 있는 것도 아니고, 개발 팀원이라면 누구나 함께 참여해서 디렉터가 결정을 내리는 데에 도움을 줄 수 있는거졈.
그럼 의도 설정이 완료되었다고 할 때, 이 의도랄까 목적을 달성하기 위한 최적의 솔루션... 어떤 게임 어셋으로 의도를 적절히 표현하면서도, 날로 먹는(?) 개발을 할 수 있을까?! 에 대한 대답을 찾는 문제는...
요거이 흔히 '아이디어'라고도 불리우는 부분이고, 기획자가 참여할 여지가 있는 일이긴 하지만서도...
이게 '기획자만의 전문성이 드러나는 부분인가?' 라고 묻는다면 내 대답은 '아니올시다'이다.
아이디어는 기획자만 내나효? 프로그래머는 아이디어 없나효? 아티스트는? 당연히 아이디어는 누구나 낼 수 있는 거고, 개발팀 내에서 아이디어는 자유롭게 제안되고 논의될 수 있어야만 한다.
'참신한' 아이디어를 낼 수 있는 능력은 상상력의 영역에 가깝고, '유용한' 아이디어를 내기 위해서는 게임에 대한 이해가 필요하다. 그리고 이러한 상상력과 이해력은... 특정 직군에게만 종속되는 것이 아니다. (아니어야만 한다.)
고로 이건 기획자 고유의 업무는 아니라능. 물론 기획자가 이 일을 잘한다면 좋다. 기획자는 개발 중인 게임 전반에 대한 통찰을 하고 있어야 하므로, 이 일을 잘 하기에 조금 더 유리한(?) 것도 사실이기는 하지만...
그럼에도 불구하고 기획자만의 고유 업무가 되어버리면 안되는 종류의 일인지라, 기획자만의 전문성이 두드러지는, 기획자라는 직군의 성격을 규정짓는 일은 아니라고 할 수 있다.
(그래서 [예전 글]에서 기획자한테 아이디어는 사실 없어도 된다고 한거다 ㄲㄲㄲ)
그러니까 1번은 패스~
기획자들조차 쉽게 착각하는 부분이기도 한데, 게임의 상이랄까 혹은 기조를 뚜렷이 설정하고 결정하는 것은 디렉터가 해야 하는 일이지 기획자가 할 일은 아니예효.
물론 기획자가 그걸 도와줄 수는 있겠지만... 딱히 기획자만 도와줄 수 있는 것도 아니고, 개발 팀원이라면 누구나 함께 참여해서 디렉터가 결정을 내리는 데에 도움을 줄 수 있는거졈.
그럼 의도 설정이 완료되었다고 할 때, 이 의도랄까 목적을 달성하기 위한 최적의 솔루션... 어떤 게임 어셋으로 의도를 적절히 표현하면서도, 날로 먹는(?) 개발을 할 수 있을까?! 에 대한 대답을 찾는 문제는...
요거이 흔히 '아이디어'라고도 불리우는 부분이고, 기획자가 참여할 여지가 있는 일이긴 하지만서도...
이게 '기획자만의 전문성이 드러나는 부분인가?' 라고 묻는다면 내 대답은 '아니올시다'이다.
아이디어는 기획자만 내나효? 프로그래머는 아이디어 없나효? 아티스트는? 당연히 아이디어는 누구나 낼 수 있는 거고, 개발팀 내에서 아이디어는 자유롭게 제안되고 논의될 수 있어야만 한다.
'참신한' 아이디어를 낼 수 있는 능력은 상상력의 영역에 가깝고, '유용한' 아이디어를 내기 위해서는 게임에 대한 이해가 필요하다. 그리고 이러한 상상력과 이해력은... 특정 직군에게만 종속되는 것이 아니다. (아니어야만 한다.)
고로 이건 기획자 고유의 업무는 아니라능. 물론 기획자가 이 일을 잘한다면 좋다. 기획자는 개발 중인 게임 전반에 대한 통찰을 하고 있어야 하므로, 이 일을 잘 하기에 조금 더 유리한(?) 것도 사실이기는 하지만...
그럼에도 불구하고 기획자만의 고유 업무가 되어버리면 안되는 종류의 일인지라, 기획자만의 전문성이 두드러지는, 기획자라는 직군의 성격을 규정짓는 일은 아니라고 할 수 있다.
(그래서 [예전 글]에서 기획자한테 아이디어는 사실 없어도 된다고 한거다 ㄲㄲㄲ)
그러니까 1번은 패스~
2. 채택된 어셋의 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
와우. 기획자를 영어로 하면 Game Designer(사실 영어로 하면 좀 더 세분화 되기는 하지만 일단 퉁쳐서)이니까... 뭔가 기획자만의 고유 영역 같아 보이는 놈이 나왔군염.
그러나... 이걸 '어떠한 일이다'라고 명확하게 정의내릴 수 있을까.
게임 디자인이라는게 대체 구체적으로는 어떤 일인지... 즉 코딩 한다, 드로잉 한다, 모델링 한다 등과 같이 명확하게 정의내릴 수 있다면 '기획자는 xx 하는 사람'이라고 그 전문성을 명시할 수 있을텐데...
문제는 '게임 디자인을 한다'라고 해버리면 너무 모호하게 추상화되고 넓어져 버린다는 점이다.
관점을 좀 바꿔볼까? 그럼 좋은 게임 디자인이란 무엇인가?
... 아 넵. 역시나 추상적이근염. 그냥 '좋은 게임 디자인은 좋은 게임 디자인이다'라는 말과 그닥 달라보이지 않는데 말이졈 ㄱ-
관점을 다시 바꿔볼까? 그럼 좋은 게임 디자인을 하기 위해서는 어떤 스킬이 필요한가?
... 하아 그래도 모호하네. 뭐 논리력이니, 객관화 능력이니, 추상화 능력이니, 시스템 분석 능력이니 등등 뜬구름 잡는 류의 이야기는 늘어놓을 수 있겠지만, 이것들이 게임 디자인에 연결되는 지점을 설명하려 들면 다시 갸우뚱해져 버린다.
물론 그럼에도 불구하고 좋은 게임 디자인은 존재한다.
그리고 그 실체가 모호함에도 불구하고, 게임 디자인이라는 업무는 현상으로 존재하고 있다. (내가 그 일을 하고 있다 ㄱ-)
아울러 좋은 디자인을 하는 게임 디자이너 - 기획자 역시 존재한다.
그런데 그래서 좋은 게임 디자인이 뭐냐고 묻는다면, 그 좋은 게임 디자인을 위해서 무엇이 필요한지를 묻는다면... 아리까리해 넓어져 버리는 것이 우리 직군의 문제 ㄱ-
다시 또 뒤집어서, 좋은 게임 디자이너가 되려면 어떠한 스킬이 필요한지를 묻는다면... 역시 아리까리.
즉... 레퍼런스가 없다!!!
뭐 게임 기획이랄까 디자인 전반을 다루고 있는 여러 책들을 보면(넵 그렇게 많이 보지는 못했슴미다. 사실 그렇게 많이 나와있는 것도 아니고... 외서는 거진 콘솔 - Stand Alone - 이야기이고 ㄱ-) 나름의 방식대로 게임 디자인을 정의하고 있기는 한데... 이야기가 다 달라. 아니 '다르다'라고 딱 떨어지는 말을 하기엔 또 모호한 것이... 따로따로 보자면 맞는 말이긴 한데, 중앙을 관통하는 무언가가 모호해지는 것이다. 뜬구름 잡아버리는 레퍼런스라고나 할까...
상황이 이러니 유독 쓸모없다고 알려진 게임 관련 자격증 중에서도 기획 자격증은 정말 낮은 평가를 받고 있는게 아닐까. 자격증이라는건 레퍼런스가 명확한 직군에 대해서나 유의미할 수 있을텐데... 기획은 레퍼런스가 명확하지 않거등.
더욱 곤란한 지점은... '레퍼런스가 명확하지 않다는 점을 인식했다면, 기획 업무를 분류하고 정리해서 레퍼런스를 구축하면 되지 않는가?'라는 질문에 대하여 '그러기가 좀 힘든데염, 혹은 불가능해 보여효'라는 대답을 할 수밖에 없다는 점이다.
... 그 이유는 프로젝트, 혹은 개발하는 게임에 따라 Case by Case이기 때문에...
어떤 게임에서는 최악의 디자인이, 어떤 게임에서는 최선의 디자인이 될 수 있다. 물론 반대로 어떤 게임에서는 최선의 디자인이 다른 게임에서는 최악의 디자인이 될 수 있고.
게임만 놓고 보자면 최선의 디자인인데, 개발 자원 활용 효율성이 최악이라면 그건 또 최악의 디자인이 되고... 경우의 수는 계속 늘어난다.
즉 그 때 그 때 달라효. 아놔... 어쩌라고.
이러저러한 이유 때문에 결국 기획자를 'xx 하는 사람'이라 명확하게 정의할 수 없다 보니...
'아이디어 내는 사람?'이라는 쓰잘데기 업ㅂ는 인식도 생겨버리는 듯 싶고, '재미를 만들어 내는 사람?'이라는 GODLIKE ㅎㄷㄷ한 정의도 나오는게 아닐까?
더불어 '기획자 따위 필요없어'의 근원지 역시 이 지점이 아닐까.
사실 레퍼런스가 명확하지 않다 보니... 더불어 디자인이라는건 (손, 발이 돕기는 하지만서도) 결국 머리 속에서 일어나는 일이다 보니... 아무나 할 수 있는 것처럼 보이거등. 실제로 다른 직군에 속해 있는 사람이 게임 디자인을 하려 들면 '난 이러저러한 스킬이 없으니까 못하겠는데'라 할만한 명확한 지점이 없는 것도 사실이니까. 그런 상황에서 주섬주섬 한 디자인이 얼추 들어 맞는다면... 사실 그 사람은 게임 디자인을 한 것임에도 불구하고, 자기 자신이 게임 디자인을 한 것인지 여부를 명확히 인지하기도 힘들다.
'뭐 게임 기획자 필요없네. 그냥 내가 해도 되는데?'로 귀결해 버리는, 그리고 이에 대해 딱히 반론하기도 힘든 상황이 벌어지는 것이다.
정리하자면... 게임 디자인은 기획자 고유의 영역이 맞다.
하지만 그 고유의 영역을 가르는 구분선은... 모호하기 짝이 없다.
이것이 내가 '게임 기획자란 대체 뭐하는 놈들인가'라는 질문에 명확하게 '이거다'라는 대답을 제시하지 못하는 지점이기도 하고.
그러나... 이걸 '어떠한 일이다'라고 명확하게 정의내릴 수 있을까.
게임 디자인이라는게 대체 구체적으로는 어떤 일인지... 즉 코딩 한다, 드로잉 한다, 모델링 한다 등과 같이 명확하게 정의내릴 수 있다면 '기획자는 xx 하는 사람'이라고 그 전문성을 명시할 수 있을텐데...
문제는 '게임 디자인을 한다'라고 해버리면 너무 모호하게 추상화되고 넓어져 버린다는 점이다.
관점을 좀 바꿔볼까? 그럼 좋은 게임 디자인이란 무엇인가?
설정된 의도를 가장 명확하게 반영하면서도, 이를 실제로 구현할 개발자들의 능력과, 개발 자원 활용에 있어 가장 효율적이고 최적화된 게임 디자인. 이 디자인은 여러 게임 어셋들과 모순을 발생시키지 않아야 하며, 실제로 플레이할 유저로 하여금 의도에 부합하는 반응을 보이도록 이끌어 낼 수 있어야 한다... 등등.
... 아 넵. 역시나 추상적이근염. 그냥 '좋은 게임 디자인은 좋은 게임 디자인이다'라는 말과 그닥 달라보이지 않는데 말이졈 ㄱ-
관점을 다시 바꿔볼까? 그럼 좋은 게임 디자인을 하기 위해서는 어떤 스킬이 필요한가?
... 하아 그래도 모호하네. 뭐 논리력이니, 객관화 능력이니, 추상화 능력이니, 시스템 분석 능력이니 등등 뜬구름 잡는 류의 이야기는 늘어놓을 수 있겠지만, 이것들이 게임 디자인에 연결되는 지점을 설명하려 들면 다시 갸우뚱해져 버린다.
물론 그럼에도 불구하고 좋은 게임 디자인은 존재한다.
그리고 그 실체가 모호함에도 불구하고, 게임 디자인이라는 업무는 현상으로 존재하고 있다. (내가 그 일을 하고 있다 ㄱ-)
아울러 좋은 디자인을 하는 게임 디자이너 - 기획자 역시 존재한다.
그런데 그래서 좋은 게임 디자인이 뭐냐고 묻는다면, 그 좋은 게임 디자인을 위해서 무엇이 필요한지를 묻는다면... 아리까리해 넓어져 버리는 것이 우리 직군의 문제 ㄱ-
다시 또 뒤집어서, 좋은 게임 디자이너가 되려면 어떠한 스킬이 필요한지를 묻는다면... 역시 아리까리.
즉... 레퍼런스가 없다!!!
뭐 게임 기획이랄까 디자인 전반을 다루고 있는 여러 책들을 보면(넵 그렇게 많이 보지는 못했슴미다. 사실 그렇게 많이 나와있는 것도 아니고... 외서는 거진 콘솔 - Stand Alone - 이야기이고 ㄱ-) 나름의 방식대로 게임 디자인을 정의하고 있기는 한데... 이야기가 다 달라. 아니 '다르다'라고 딱 떨어지는 말을 하기엔 또 모호한 것이... 따로따로 보자면 맞는 말이긴 한데, 중앙을 관통하는 무언가가 모호해지는 것이다. 뜬구름 잡아버리는 레퍼런스라고나 할까...
상황이 이러니 유독 쓸모없다고 알려진 게임 관련 자격증 중에서도 기획 자격증은 정말 낮은 평가를 받고 있는게 아닐까. 자격증이라는건 레퍼런스가 명확한 직군에 대해서나 유의미할 수 있을텐데... 기획은 레퍼런스가 명확하지 않거등.
더욱 곤란한 지점은... '레퍼런스가 명확하지 않다는 점을 인식했다면, 기획 업무를 분류하고 정리해서 레퍼런스를 구축하면 되지 않는가?'라는 질문에 대하여 '그러기가 좀 힘든데염, 혹은 불가능해 보여효'라는 대답을 할 수밖에 없다는 점이다.
... 그 이유는 프로젝트, 혹은 개발하는 게임에 따라 Case by Case이기 때문에...
어떤 게임에서는 최악의 디자인이, 어떤 게임에서는 최선의 디자인이 될 수 있다. 물론 반대로 어떤 게임에서는 최선의 디자인이 다른 게임에서는 최악의 디자인이 될 수 있고.
게임만 놓고 보자면 최선의 디자인인데, 개발 자원 활용 효율성이 최악이라면 그건 또 최악의 디자인이 되고... 경우의 수는 계속 늘어난다.
즉 그 때 그 때 달라효. 아놔... 어쩌라고.
물론 언제 어디서나 먹히지 않는 그냥 막장이라는 것도 없지는 않지만... 이런걸 골라내는 정도를 전문성이라고 내세우기엔 (...)
이러저러한 이유 때문에 결국 기획자를 'xx 하는 사람'이라 명확하게 정의할 수 없다 보니...
'아이디어 내는 사람?'이라는 쓰잘데기 업ㅂ는 인식도 생겨버리는 듯 싶고, '재미를 만들어 내는 사람?'이라는 GODLIKE ㅎㄷㄷ한 정의도 나오는게 아닐까?
더불어 '기획자 따위 필요없어'의 근원지 역시 이 지점이 아닐까.
사실 레퍼런스가 명확하지 않다 보니... 더불어 디자인이라는건 (손, 발이 돕기는 하지만서도) 결국 머리 속에서 일어나는 일이다 보니... 아무나 할 수 있는 것처럼 보이거등. 실제로 다른 직군에 속해 있는 사람이 게임 디자인을 하려 들면 '난 이러저러한 스킬이 없으니까 못하겠는데'라 할만한 명확한 지점이 없는 것도 사실이니까. 그런 상황에서 주섬주섬 한 디자인이 얼추 들어 맞는다면... 사실 그 사람은 게임 디자인을 한 것임에도 불구하고, 자기 자신이 게임 디자인을 한 것인지 여부를 명확히 인지하기도 힘들다.
'뭐 게임 기획자 필요없네. 그냥 내가 해도 되는데?'로 귀결해 버리는, 그리고 이에 대해 딱히 반론하기도 힘든 상황이 벌어지는 것이다.
정리하자면... 게임 디자인은 기획자 고유의 영역이 맞다.
하지만 그 고유의 영역을 가르는 구분선은... 모호하기 짝이 없다.
이것이 내가 '게임 기획자란 대체 뭐하는 놈들인가'라는 질문에 명확하게 '이거다'라는 대답을 제시하지 못하는 지점이기도 하고.
3. 어셋을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
넵. 문서 작성. 물론 잘 해야 하졈... 일반적으로 플머님께 넘기는 문서이니까, 기획자는 플밍에 대한 지식도 얼추 갖추고 있어야 하고...
... 근데 가독성이 높은 이해하기 쉬운 문서를 작성해 내는 능력을 기획자 고유의 전문성이라고 할 수 있을까효?
아 물론 잘하면 좋은 일이고, 잘해야 하는 일이지만, 이 일이 과연 기획자라는 직군의 성격을 규정지을까효?
아리까리... 아니올시다... 싶다. 이건 그냥 '생각의 공유'가 필요한 '협업' 체제에 속해 있는 모든 개발자가 어느 정도 갖추어야 할 소양인 듯.
... 근데 가독성이 높은 이해하기 쉬운 문서를 작성해 내는 능력을 기획자 고유의 전문성이라고 할 수 있을까효?
아 물론 잘하면 좋은 일이고, 잘해야 하는 일이지만, 이 일이 과연 기획자라는 직군의 성격을 규정지을까효?
아리까리... 아니올시다... 싶다. 이건 그냥 '생각의 공유'가 필요한 '협업' 체제에 속해 있는 모든 개발자가 어느 정도 갖추어야 할 소양인 듯.
4. 어셋이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
아 물론 그러니까 기획자는 그래픽이나 사운드에 대한 지식을 얼추 갖추고 있어야 하지만... 나머지는 3번과 마찬가지.
5. 어셋 구현 후에는... 리소스들의 조립.
... 사실 문서화만 잘 되어 있다면 조립은 누구나 할 수 있다 -ㅁ- 매뉴얼 따라서 프라모델 조립하는 것과 크게 다르지 않으니.
물론 특히나 레벨 디자인이나 퀘스트 디자인 쪽에서는 여기에 센스가 요구되기는 지점이 겹치기는 하지만서도, 역시나 이걸 기획자만의 고유성을 결정짓는 일이라 하기엔... 이를 위해 딱히 필요한 스킬이나 전문적 지식이 요구되지는 않는다.
그냥 개발 효율상 이 일은 기획자가 맡는게 좋다. 정도가 아닐까...?
물론 특히나 레벨 디자인이나 퀘스트 디자인 쪽에서는 여기에 센스가 요구되기는 지점이 겹치기는 하지만서도, 역시나 이걸 기획자만의 고유성을 결정짓는 일이라 하기엔... 이를 위해 딱히 필요한 스킬이나 전문적 지식이 요구되지는 않는다.
그냥 개발 효율상 이 일은 기획자가 맡는게 좋다. 정도가 아닐까...?
6. 리소스들을 조립하여 어셋의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
게임 디자인과 더불어 뭔가 기획자스러운 업무가 튀어나오셨음. 밸런싱.
그러나 이 업무 역시 게임 디자인과 똑같은 문제를 가지고 있다. 레퍼런스랄까, 혹은 정답이 없고 Case by Case.
그나마 게임 디자인보다는 손에 명확히 잡히는 결과물을 내놓는 작업이기 때문에 좀 낫기는 하고, 여러 게임 어셋들과의 연계를 모두 고려해야만 하는 일이기에 기획자가 진행할만한 고유 업무라 할만한 녀석이기는 하지만서도...
그래서 밸런싱을 잘 하기 위해서 필요한 스킬이 뭔가요? 라고 묻는다면 나는 또 침묵하게 된다 (...)
아 넵. 뜬구름잡는 이야기에 더하여 '사칙 연산'이라는 스킬같지도 않은 스킬 (...) 을 추가할 수는 있겠지만... 말하기도 부끄럽다 ;
따라서 기획자 고유 업무이며, 게임 디자인보다는 좀 더 작업의 가시성이 높기는 하지만, 역시 '그래서 좋은 밸런싱이 뭔데? 뭐가 필요한데?'라고 묻는다면 그 모호함에 먼 산을 바라보아야 하는 영역.
어째 다 이 모냥이냐고효 -ㅅ-
그러나 이 업무 역시 게임 디자인과 똑같은 문제를 가지고 있다. 레퍼런스랄까, 혹은 정답이 없고 Case by Case.
그나마 게임 디자인보다는 손에 명확히 잡히는 결과물을 내놓는 작업이기 때문에 좀 낫기는 하고, 여러 게임 어셋들과의 연계를 모두 고려해야만 하는 일이기에 기획자가 진행할만한 고유 업무라 할만한 녀석이기는 하지만서도...
그래서 밸런싱을 잘 하기 위해서 필요한 스킬이 뭔가요? 라고 묻는다면 나는 또 침묵하게 된다 (...)
아 넵. 뜬구름잡는 이야기에 더하여 '사칙 연산'이라는 스킬같지도 않은 스킬 (...) 을 추가할 수는 있겠지만... 말하기도 부끄럽다 ;
따라서 기획자 고유 업무이며, 게임 디자인보다는 좀 더 작업의 가시성이 높기는 하지만, 역시 '그래서 좋은 밸런싱이 뭔데? 뭐가 필요한데?'라고 묻는다면 그 모호함에 먼 산을 바라보아야 하는 영역.
어째 다 이 모냥이냐고효 -ㅅ-
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
어랍쇼? 이건 QA의 업무인거 같은데?
기획자가 여기에 참여를 안한다면 그것도 문제이지만, 엄밀히 말해 이건 QA의 메인 업무에 기획자가 서브로 끼어드는 형태가 되는 듯 싶다.
고로 기획자를 결정짓는 업무라 할 수는 없을 터.
기획자가 여기에 참여를 안한다면 그것도 문제이지만, 엄밀히 말해 이건 QA의 메인 업무에 기획자가 서브로 끼어드는 형태가 되는 듯 싶다.
고로 기획자를 결정짓는 업무라 할 수는 없을 터.
... 라고 한다면. 자 정리해보자.
1번부터 7번까지 중에서, 내가 보기에 기획자라는 직군의 성격을 규정짓는다고 할만한 작업은 게임 디자인과 밸런싱 2가지이다.
그러나 그래서 게임 디자인과 밸런싱에 있어 어떠한 전문성이 요구되는가... 라고 한다면 여전히 그 점에 있어서는 모호함이 나를 휘어 감싼다.
물론 필요한 스킬이 '없다'라고 할 수는 없다. 즉 일반인과 게임 기획자를 가르는 선은 분명히 존재한다.
'그 선은 이 지점이다'라고 명확히 할 수는 없겠지만, 사실 이런 식으로 분해해 가면서 접근한다면 어느 직군이든 그 선은 1차원적인 구분자로 존재하는 것이 아닌, 2차원적인 면으로서 존재할 것이다.
하지만 역시 기획자는 그 면이 너무 넓다 ㄱ-
일단 나열하기 시작하자면... 이 뭐 인문학 거의 전반, 혹은 이학이나 공학까지도 넘나들게 되어버리는 것이다. 그렇다고 또 어느 분야에 대해 Master가 될 필요까지는 없고, 이 분야 저 분야 모두 툭툭 건드림에 부족함이 없는 정도면 족하다.
(그러니 '게임 기획자가 되려면 어떻게 해야 하나효?'라는 질문에 대하여 우리가 해줄 수 있는 대답이라는게 '게임 하나 만들어 보세효' 정도 밖에 못되는 것이다. 기획자로 넘어오는 선이 너무 넓으니까 차라리 통째로 함 해보라는... 그것 참 이게 정답이라고 생각하기는 하지만, 이게 정답이라는 사실은 사실 참 슬픈 사실이 아닐 수 업ㅂ다 ㄱ-)
그리하야... 결국 '개발팀의 잡부'라는 결론이 다시 튀어나와 버리는 것이다 -ㅁ-;;;
... 뭐 잡부라는 단어를 조금 부정적인 뉘앙스로 써서 단순히 거부감이 드는 것일는지도 모르겠지만 ㄱ-;
또는 기획자는 원래 저 모호함의 넓은 면에서 헤엄치는 존재가 맞는 것인지도 모르겠지만...
혹은 애초에 내가 진행한 사고 전개가 완전히 틀려먹은 것일는지도 모르겠지만...
어찌되었든 현재로서는 내가 게임 기획자라는 직군에 대하여 설명할 수 있는 지점은 이 정도이다.
워킹 딕셔너리, 혹은 개발의 짐덩어리 사이에서 모호하게 존재하는 직군이랄까 ㄱ-;
... 이 시점에서 '역시 게임 기획자 따위는 필요없군'이라 읊조리며 고개를 끄덕이는 당신을 위한 이야기는 다음 글에서 ( '')
|
Trackback Address :: http://glekang.com/trackback/340
|
[글강, 2009/01/31 01:12, Game]
자 [1번 글]에서 던져진 질문은 '게임 기획자라는건 대체 뭐하는 놈들인데?'라는 거였는데... ㄱ-
이거이 쉽게 대답할 수 있는 거였다면, 그냥 지난 글에서 휙 정답을 던져 버리고 걍 끝냈겠지.
이렇게 넘버링까지 해가면서 글을 분리하지도 않았을 터...
그러니까 솔직히 결론부터 말하자면 나는 아직 기획자라는 직군을 한 문장, 혹은 한 단어로 명확히 정의하지는 못하겠다.
([예전 글]에서 언급한 바와 같이 '잡부'라는 한 단어로... 하려면 할 수야 있겠지만 -ㅁ- 설마 이런 대답을 원하는건 아닐테고;;;)
그러니까... 같이 함 고민해봅세.
4년 전 면접에서 '기획이란 무엇이라고 생각하시나요?'라는 질문을 받았을 때, 내가 했던 대답은 '룰의 정의'였는데...
아주 틀린 말이라고 생각하지는 않으나, 이건 어디까지나 시스템 디자인의 단편에서나 먹히는 이야기인 듯 싶어서리, 역시 좀 반쪽스럽다.
그럼 기획이 대체 뭔데?
나도 잘 모르겠으니까... 기획자가 하는 일을 한 번 죽 나열해보면, 좀 더 명확해지지 않을까?
기획자라는 직군은 개발팀 내에서 무슨 일을 하고 있는가?
뭐 어쩔 수 없이 일단 내 경험에 기반하여 썰을 함 풀어보자.
내가 해왔던, 그리고 지금도 하고 있는 일들을 조금 많이(!) 단순화하고, 순차적으로 나열해 보자면...
... 뭔가 다분히 시스템 디자인스러운데... -ㅁ- 그거야 내가 시스템 디자이너이니까 (...)
레벨 디자이너라면 좀 다를까?
... 비슷하네.
퀘스트 디자이너라면 좀 다를까?
물론 매우매우매우매우 단순화하고 추상화 해버렸기 때문에, 조금은 억지로 끼워맞춘 감이 없지는 않은데...
... 중간에 몇 단계가 빠지는 경우도 있고, 시스템의 성격에 따라 내가 참여하지 않는 단계도 존재하며, 특정 단계에서 몇바퀴를 돈 다음에야 다음으로 넘어가는 경우도 있는 등등 저 문장들의 뒷면이나 행간에 숨어있는 무수한 예외들이 존재한다.
뭐 대충 알아먹으시면 된다능ㅋ
(일정 조율이나 시장 파악 등등, 내가 했었던 다른 일들이 빠져있기는 하지만... PM이라는 직급의 업무나 마케터의 영역을 기획자의 업무로 간주해도 되는건지 잘 모르겠으니까 걍 패스 ~_~ 시나리오 라이터라면 또 다를 것 같지만... 아 잠깐. 우리나라에서야 라이터를 기획자로 뭉뚱그리지만, 엄밀히 말해 라이터를 기획으로 분류하는건 좀 아닌 것 같으니 또 패스 ~_~)
암튼 마구마구 단순화시킨 저 과정을, 개별 게임 어셋들의 수만큼 무한 루프 (...) 돌리는 것이 내 일이다.
에... 그런데 말이졈. 일이라고 적어놓은 걸 보고 있자니 갸우뚱해져 버린다.
저게 기획자의 일이라고?
저건 그냥 게임을 개발해 나아가는 수순을 나열해 놓은 거잖아?
기획자만 이렇게 일하나효? 프로그래머도, 아티스트도 용어만 조금 바꾸면 일하는 순서를 이와 비슷하게 끼워맞출 수 있다.
아니 직군을 따로 나누지 않는다 하더라도, 협업이 이루어지는 순서 역시 여기 끼워맞추는 데에는 그닥 무리가 없을 듯. 원래 개발은 이런 수순으로 진행된다.
그러니 이걸 '기획자라는 직군을 정의하는 일'이라고 보기는 아무래도 힘들다. 뭐 기획자가 일련의 과정들을 모두 매니징한다... 라고 한다면 저 흐름을 만들어내는 것 자체를 하나의 일로 구분할 수는 있겠지만서도, 그건 역시 PM의 일인 것 같으니 패스.
아익 경험에 의거하여 일단 생각나는대로 썰을 풀었더니만, 이건 '기획자의 일'이라기 보다는 그냥 '일' 혹은 '개발'이 튀어나와 버렸넹.
그럼 기획자는 대체 '구체적으로' 뭐하는 놈들인데?
흐음... 저 흐름에서 기획자가 '고유의 전문성'을 발휘할 수 있는 구간이 있는지를 한번 살펴본다면 좀 더 명확해지지 않을까?
그러나 그건 다음 글에서 ( --)
...
...
...
... 이제 겨우 2번인데도 내가 무슨 짓을 하고 있는거랍쇼 ㄱ- 라는 생각이 벌써 들기 시작하는데...
뭐 그래도 일단 칼을 뽑았으니 오늘은 무를 썰고 다음엔 뜨거운 감자를 썰어봅세.
이거이 쉽게 대답할 수 있는 거였다면, 그냥 지난 글에서 휙 정답을 던져 버리고 걍 끝냈겠지.
이렇게 넘버링까지 해가면서 글을 분리하지도 않았을 터...
그러니까 솔직히 결론부터 말하자면 나는 아직 기획자라는 직군을 한 문장, 혹은 한 단어로 명확히 정의하지는 못하겠다.
([예전 글]에서 언급한 바와 같이 '잡부'라는 한 단어로... 하려면 할 수야 있겠지만 -ㅁ- 설마 이런 대답을 원하는건 아닐테고;;;)
그러니까... 같이 함 고민해봅세.
4년 전 면접에서 '기획이란 무엇이라고 생각하시나요?'라는 질문을 받았을 때, 내가 했던 대답은 '룰의 정의'였는데...
아주 틀린 말이라고 생각하지는 않으나, 이건 어디까지나 시스템 디자인의 단편에서나 먹히는 이야기인 듯 싶어서리, 역시 좀 반쪽스럽다.
그럼 기획이 대체 뭔데?
나도 잘 모르겠으니까... 기획자가 하는 일을 한 번 죽 나열해보면, 좀 더 명확해지지 않을까?
기획자라는 직군은 개발팀 내에서 무슨 일을 하고 있는가?
뭐 어쩔 수 없이 일단 내 경험에 기반하여 썰을 함 풀어보자.
내가 해왔던, 그리고 지금도 하고 있는 일들을 조금 많이(!) 단순화하고, 순차적으로 나열해 보자면...
1. 게임에서 의도하고 있는 바를 달성하기 위한 각종 게임 시스템들의 제안 및 논의 진행.
2. 채택된 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 시스템을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 시스템이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 시스템 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 시스템의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
2. 채택된 시스템에서 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 게임 디자인.
3. 시스템을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 시스템이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 시스템 구현 후에는... 리소스들의 조립.
6. 리소스들을 조립하여 시스템의 뼈대를 얼추 갖췄다면, 다양한 상황에서 다양하게 적용될 수 있도록 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
... 뭔가 다분히 시스템 디자인스러운데... -ㅁ- 그거야 내가 시스템 디자이너이니까 (...)
레벨 디자이너라면 좀 다를까?
1. 게임에서 의도하고 있는 플레이 패턴을 달성하기 위한 레벨의 컨셉 제안 및 논의 진행.
2. 채택된 컨셉을 반영할 수 있으면서, 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 레벨 디자인.
3. 레벨을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 레벨이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 레벨 구현 후에는... 각종 어셋들의 배치.
6. 어셋들을 배치했다면, 각 어셋들에게 적용될 수치들을 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
2. 채택된 컨셉을 반영할 수 있으면서, 어뷰징의 구멍 등을 제거하고, 논리적 완결성을 갖추도록 다듬는 레벨 디자인.
3. 레벨을 실제로 구현할 수 있도록 하는 스펙 혹은 명세의 작성.
4. 레벨이 구현되는 데에 필요한 그래픽, 사운드 리소스 명세 작성.
5. 레벨 구현 후에는... 각종 어셋들의 배치.
6. 어셋들을 배치했다면, 각 어셋들에게 적용될 수치들을 밸런싱.
7. 밸런싱 얼추 완료됐으면 테스트, 테스트, 테스트. 각종 이슈들에 대한 검증과 보정.
... 비슷하네.
퀘스트 디자이너라면 좀 다를까?
1. 게임에서 의도하고 있는 시나리오 전달 혹은 플레이 경험 선사, 보상 제공 등을 달성하기 위한 퀘스트의 제안 및 논의 진행.
2. 채택된 퀘스트를 디자인...
3. ... 4. 5. 6. 7. 똑같자나!
2. 채택된 퀘스트를 디자인...
3. ... 4. 5. 6. 7. 똑같자나!
물론 매우매우매우매우 단순화하고 추상화 해버렸기 때문에, 조금은 억지로 끼워맞춘 감이 없지는 않은데...
... 중간에 몇 단계가 빠지는 경우도 있고, 시스템의 성격에 따라 내가 참여하지 않는 단계도 존재하며, 특정 단계에서 몇바퀴를 돈 다음에야 다음으로 넘어가는 경우도 있는 등등 저 문장들의 뒷면이나 행간에 숨어있는 무수한 예외들이 존재한다.
뭐 대충 알아먹으시면 된다능ㅋ
(일정 조율이나 시장 파악 등등, 내가 했었던 다른 일들이 빠져있기는 하지만... PM이라는 직급의 업무나 마케터의 영역을 기획자의 업무로 간주해도 되는건지 잘 모르겠으니까 걍 패스 ~_~ 시나리오 라이터라면 또 다를 것 같지만... 아 잠깐. 우리나라에서야 라이터를 기획자로 뭉뚱그리지만, 엄밀히 말해 라이터를 기획으로 분류하는건 좀 아닌 것 같으니 또 패스 ~_~)
암튼 마구마구 단순화시킨 저 과정을, 개별 게임 어셋들의 수만큼 무한 루프 (...) 돌리는 것이 내 일이다.
에... 그런데 말이졈. 일이라고 적어놓은 걸 보고 있자니 갸우뚱해져 버린다.
저게 기획자의 일이라고?
저건 그냥 게임을 개발해 나아가는 수순을 나열해 놓은 거잖아?
목적 설정 및 최적 솔루션 모색 → 솔루션 구체화 → 문서화 → 실체화 → 수치적 보정 → 테스트 및 수정
기획자만 이렇게 일하나효? 프로그래머도, 아티스트도 용어만 조금 바꾸면 일하는 순서를 이와 비슷하게 끼워맞출 수 있다.
아니 직군을 따로 나누지 않는다 하더라도, 협업이 이루어지는 순서 역시 여기 끼워맞추는 데에는 그닥 무리가 없을 듯. 원래 개발은 이런 수순으로 진행된다.
그러니 이걸 '기획자라는 직군을 정의하는 일'이라고 보기는 아무래도 힘들다. 뭐 기획자가 일련의 과정들을 모두 매니징한다... 라고 한다면 저 흐름을 만들어내는 것 자체를 하나의 일로 구분할 수는 있겠지만서도, 그건 역시 PM의 일인 것 같으니 패스.
아익 경험에 의거하여 일단 생각나는대로 썰을 풀었더니만, 이건 '기획자의 일'이라기 보다는 그냥 '일' 혹은 '개발'이 튀어나와 버렸넹.
그럼 기획자는 대체 '구체적으로' 뭐하는 놈들인데?
흐음... 저 흐름에서 기획자가 '고유의 전문성'을 발휘할 수 있는 구간이 있는지를 한번 살펴본다면 좀 더 명확해지지 않을까?
그러나 그건 다음 글에서 ( --)
...
...
...
... 이제 겨우 2번인데도 내가 무슨 짓을 하고 있는거랍쇼 ㄱ- 라는 생각이 벌써 들기 시작하는데...
뭐 그래도 일단 칼을 뽑았으니 오늘은 무를 썰고 다음엔 뜨거운 감자를 썰어봅세.
|
Trackback Address :: http://glekang.com/trackback/339
|
[글강, 2009/01/30 11:49, Game]
... 우리나라 게임들 그래픽은 정말 끈내줘효. 개발 기술력 역시 세계 어디에 내놓는다 해도 손색이 업ㅂ졈. 하지만 문제는 기획력. 기획자들이 x같아서 재미있는 게임이 안나와효. 맨날 표절이나 해대고 궁시렁 궁시렁 ...
... 이와 같은 이야기는 게임 관련 커뮤니티에서 벌써 몇년 째 울궈먹고 있음에도, 미끼만 던졌다 하면 여전히 파닥파닥 만선인... 레전드리 떡밥이다.
심지어 개발자들 중에도 저런 생각에 동조하는 사람이 있다 보니, '기획자 따위 필요없어!'를 표방하는 게임이 나온 적도 있고... 뭐 암튼 여타 등등.
이 쉰내나는 떡밥을 이제 와 다시 돌이켜 보는 이유는...
솔직히 좀 억울해서. 헤헤헤.
데꿀멍 데꿀멍 데꿀멍 ( '')
일단 저 위에 나온 이야기에서, 기획자라고 지칭되는건 과연 누구일까? 기획자란 대체 뭐하는 사람일까?
기획자들이 x같아서 재미있는 게임이 안나온다 했으니... 그럼 기획자들이 잘하면 재미있는 게임이 나온다는 거근염.
기획자란 게임의 재미를 만들어 내는 사람?
기획자란 게임의 재미를 보장하는 사람?
기획자란 게임의 재미를 책임지는 사람?
하지만 재미라는건 게임의 궁극적인 목표이고, 개발의 모든 방향성은 결국 '재미'라는 키워드로 집중되게 마련인데... 그러한 재미를 만들고, 보장하고, 책임지는 기획자란...?
게임의 재미를 결정하는 사람인가효?
게임을 어떻게 만들면 재미있어 지는지를 아는 사람?
게임을 재미있게 만들기 위하여 컨텐츠의 방향성을 결정하는 사람?
... 하아. 이 즈음에서 개발자, 혹은 눈치가 빠른 유저라면 '어랍쇼 잠깐만?!'을 외치실 때가 되었는데...
팀이 개발하는 게임의 최종적인 상을 명확히 정립하고,
이에 기반하여 각종 컨텐츠들의 방향성을 결정하고,
결과적으로 팀이 만들어 내는 게임의 재미를 보장하고 책임지는 사람.
이에 기반하여 각종 컨텐츠들의 방향성을 결정하고,
결과적으로 팀이 만들어 내는 게임의 재미를 보장하고 책임지는 사람.
... 우리는 이런 사람을 '기획자'라는 직군으로 분류하지 않는다.
... 이런 사람은 '디렉터'라는 직급으로 분류된다.
물론 기획자가 디렉터를 맡는 경우라면 결국 같은 이야기가 되어 버리겠지만, 그럼에도 불구하고 '정립하고, 결정하고, 보장하며, 책임지는 것'은 기획자의 일이 아니라, 디렉터의 일이다.
즉 디렉터가 기획자 출신이든, 프로그래머 출신이든, 아티스트 출신이든 관계 없이 저것은 디렉터에게 요구되는 역할이고, 권한이며, 책임인 것이다.
그러니까 일개 기획자 따위는 게임이 재미없어도 책임없어효. 그만 좀 까셈. 즐. ㅂㅂ2~
...
...
...
... 요기서 싹 입씻고 도망치고 싶은 마음은 굴뚝같지만 ㄲㄲㄲ
안타깝게도 새로운 의문이 꼬리를 잇게 된다.
그럼 게임 기획자라는건 대체 뭐하는 놈들인데?
오늘은 대충 운만 띄워보고, 그 이야기는 다음 글에서 ( '')
사족 1.
게임을 디렉터 혼자 만드냐? 기획자도 결국 개발팀의 일원인데 게임의 재미에 책임이 없다고???
... 예리하기도 하셔라 ( --) 이 이야기는 기회가 닿는다면 다른 글에서 ( --)
사족 2.
디렉터가 게임의 재미를 보장하고 책임진다고? '재미를 보장한다'라는게 정말 인간에게 가능한 능력인거임? 그리고 '책임'이라는 건 대체 어떻게 질 수 있는건데?
... 자, 잠깐만. 이것도 다음에 기회 닿으면... (이라 쓰고 도망)
|
Trackback Address :: http://glekang.com/trackback/338
|
[글강, 2009/01/06 22:54, Game]
아시는 분은 아시겠지만 요즘은 액션 게임을 만들고 있슴미다.
지금 한창 1차(프로토타이핑 밸런싱을 1차라고 한다면야 2차) 전투 밸런싱 작업을 진행 중인데...
뭐 작업이 아직 완료된 것도 아니고, 테스트도 돌려 본 바 없으며, 무엇보다도 이제야 겨우 1차... 앞으로 최소한 3차에서 한 10차까지는 계속 해야 할 것 같기는 하지만서도...
그럼에도 불구하고 작업을 하다보니 느껴지는 단상들을 끄적끄적 ( '')
1. MMORPG가 더 쉬워!!!
2. 망할 놈의 직교성, 망할 놈의 테이블
PvP 밸런싱 이제 겨우 초반을 진행중인데 벌써 이 모냥이면...
나중에 보상 밸런싱, 성장 밸런싱 등등을 진행할 때엔 또 어떤 은하계로 날아가게 될라나... oTL
그래서 PvE 밸런싱은 레벨 디자이너한테 '난 몰라. 즐. 알아서 하셈. PvE면 레벨 관련이자나 레벨! 화이팅! ( --)' 해버리고 입닦아 버리려 했는데 흑흑.
암튼 뭐 그러니까...
그래도...
최소한 일은 재미있으니 다행 ( '')
인생 쉽게 살면 재미있나효 ㅋㅋㅎㅋㅎㅋㅎㅋㅎㅋㅎㅋㅋ
지금 한창 1차(프로토타이핑 밸런싱을 1차라고 한다면야 2차) 전투 밸런싱 작업을 진행 중인데...
뭐 작업이 아직 완료된 것도 아니고, 테스트도 돌려 본 바 없으며, 무엇보다도 이제야 겨우 1차... 앞으로 최소한 3차에서 한 10차까지는 계속 해야 할 것 같기는 하지만서도...
그럼에도 불구하고 작업을 하다보니 느껴지는 단상들을 끄적끄적 ( '')
1. MMORPG가 더 쉬워!!!
아니 잠깐만 ;;; 터질 듯한 머리를 싸매며 MMORPG의 전투 밸런싱 작업을 열심히 진행 중이신 분들은 거기 치켜 든 짱돌을 잠시 내려놓으시고효 ㄱ-
어디까지나 '상대적으로'.
현재 진행 중인 플젝 이전에는 MMORPG 플젝에 참여했었고, 역시나 거기서도 밸런싱 작업을 진행했었는데...
일단 플젝 후반기에 참여했던지라 얼추 밸런싱 어셋 - 핸들? 들이 결정되어 있는 상태였고, 역시나 또 '상대적으로' 그 핸들의 수가 미칠듯이 많거나 혼란스러운 지경은 아니었던지라...
'상대적으로' 더 쉬웠던 듯 싶다.
흐음... 그리고 무식하면 용감하니까 무쌍스럽게 발언하거니와...
MMORPG는 개발자가 어느 정도 유저의 플레이 패턴을 '예측'하고, '보정'하여, '유도'하는 것이 '상대적으로' 용이하다.
(넵. 물론 유저는 개발자의 의도? 그게 뭔가효. 먹는 건가효. 먹자. 우걱우걱. 해버리지만... 암튼 '상대적으로'.)
그러다보니 이전의 MMORPG 플젝은 '전투 시뮬레이터'를 엑셀 VBA로 만들어 전투 1000번 돌려보기 같은게 가능했으며, 그 결과값은 플레이 테스트에서 도출되는 결과와 크게 상이하지 않았다.
즉 유저의 '컨트롤'이라는 변수가 미치는 영향력이 그만큼 '상대적으로' 적기 때문에, 핸들 값만으로도 어느 정도 유의미한 예측이 가능했다는 것인데...
액션 게임은... 액션 게임은... 크흑. 예측이 아니됨.
일단 전투 중에 끊임없이 이동을 해대고, 이동을 어떻게 하느냐에 따라 각 액션들의 효율은 천차만별. MMORPG의 전투에서는 이동이라는 변수가 통제 가능한 범위 내에 있었는데... 액션 게임은... oTL
그리고 다수 vs 다수의 상황에서 어디서 어떤 태클이 어떻게 들어올는지 알 수가 없으며, 그 태클들이 들어오게 되는 타이밍도 예측 불가. 세계의 기준이라 할만한 Tick이 걍 실시간이다... oTL
더구나 결정적으로 일련의 액션들 사이에는... 일관성 그게 뭔가효. 먹는 건가효. 우걱우걱 oTL
그나마 MMORPG에서는 평타나 스킬 등의 효과가 명확하고, 나름 체계적이며... 뭐랄까 '기준'이라 할만한게 있었는데... 지금 만들고 있는 놈에게는 액션의 목적과 효과라는 측면에서 일관성 같은게 애초에 업ㅂ다 ㄱ- 이 시점에서 플머님과 함께 oTL
그니까 결론은 역시... MMORPG가 더 쉬워 ;ㅁ;
(물론 대신 MMORPG는 일의 '양' 자체가 압도적이라는 이슈가 있기는 하지만서도 궁시렁 궁시렁.)
어디까지나 '상대적으로'.
현재 진행 중인 플젝 이전에는 MMORPG 플젝에 참여했었고, 역시나 거기서도 밸런싱 작업을 진행했었는데...
일단 플젝 후반기에 참여했던지라 얼추 밸런싱 어셋 - 핸들? 들이 결정되어 있는 상태였고, 역시나 또 '상대적으로' 그 핸들의 수가 미칠듯이 많거나 혼란스러운 지경은 아니었던지라...
'상대적으로' 더 쉬웠던 듯 싶다.
흐음... 그리고 무식하면 용감하니까 무쌍스럽게 발언하거니와...
MMORPG는 개발자가 어느 정도 유저의 플레이 패턴을 '예측'하고, '보정'하여, '유도'하는 것이 '상대적으로' 용이하다.
(넵. 물론 유저는 개발자의 의도? 그게 뭔가효. 먹는 건가효. 먹자. 우걱우걱. 해버리지만... 암튼 '상대적으로'.)
그러다보니 이전의 MMORPG 플젝은 '전투 시뮬레이터'를 엑셀 VBA로 만들어 전투 1000번 돌려보기 같은게 가능했으며, 그 결과값은 플레이 테스트에서 도출되는 결과와 크게 상이하지 않았다.
즉 유저의 '컨트롤'이라는 변수가 미치는 영향력이 그만큼 '상대적으로' 적기 때문에, 핸들 값만으로도 어느 정도 유의미한 예측이 가능했다는 것인데...
액션 게임은... 액션 게임은... 크흑. 예측이 아니됨.
일단 전투 중에 끊임없이 이동을 해대고, 이동을 어떻게 하느냐에 따라 각 액션들의 효율은 천차만별. MMORPG의 전투에서는 이동이라는 변수가 통제 가능한 범위 내에 있었는데... 액션 게임은... oTL
그리고 다수 vs 다수의 상황에서 어디서 어떤 태클이 어떻게 들어올는지 알 수가 없으며, 그 태클들이 들어오게 되는 타이밍도 예측 불가. 세계의 기준이라 할만한 Tick이 걍 실시간이다... oTL
더구나 결정적으로 일련의 액션들 사이에는... 일관성 그게 뭔가효. 먹는 건가효. 우걱우걱 oTL
그나마 MMORPG에서는 평타나 스킬 등의 효과가 명확하고, 나름 체계적이며... 뭐랄까 '기준'이라 할만한게 있었는데... 지금 만들고 있는 놈에게는 액션의 목적과 효과라는 측면에서 일관성 같은게 애초에 업ㅂ다 ㄱ- 이 시점에서 플머님과 함께 oTL
그니까 결론은 역시... MMORPG가 더 쉬워 ;ㅁ;
(물론 대신 MMORPG는 일의 '양' 자체가 압도적이라는 이슈가 있기는 하지만서도 궁시렁 궁시렁.)
2. 망할 놈의 직교성, 망할 놈의 테이블
에... 직교성이라는게 뭔지 자세히 알고 싶으시다면 Field님의 [생산성과 직교성의 원칙(3)]을 참고하시고 ( '')
간단히 설명하자면 이런거다.
뭐 이런 곤란한 상황이 없도록... 애초에 a에 관계된 수치 A, b에 관계된 수치 B를 따로 빼놓아야 직교성이 발생하고 모두가 행복해질 수 있다.
그리고 테이블... 요건 히아니마가 예전에 정리를 했었는데 비공개로 돌려버렸근 oTL
암튼 또 간단히 설명하자면...
위의 예에서 A를 +1할 때, a가 +5되기 위하여 중간에 '공식'이라는 놈이 개입했었다.
일단 직교성을 위하야 A의 값이 b의 값에는 영향을 주지 않도록 하고, 공식은 오직 a의 값에만 영향을 주도록 했다고 치자.
그런 후에 공식을 쓰면... 기준값 A를 수정하는 것 만으로도 a1, a2, a3, a4, a5 등등의 값들이 정해진 체계에 따라 차자작 변화해주니, 어찌아니 효율적이랴! 참으로 알흠답구나!
... 라고 생각하기가 쉽지만, 히밤. 저건 아주아주아주아주아주아주(x100) 위험한 상황이다. a1, a2, a3, a4, a5 등등의 값이 필요한가? 그럼 차라리 그걸 테이블의 형태로 만들어라.
밸런싱 작업을 진행하다 보면 A를 +1하는데, a1은 +5되고, a2는 +3되고, a5는 +7되어야 하는 상황이... 거의 '반드시' 발생하기 때문이다.
그러니까 이번 플젝에서는 이런 문제가 없도록!
하나의 기준 수치는 다른 수치에 대하여 최소한의 영향력만을 가지도록!
공식 그게 뭔가효? 사칙 연산 이외의 공식같은건 다 치워뿌러! 아니 애초에 공식은 최소화 해버리고 다 테이블로 빼버려!
... 까지는 좋은데 ( --)
일관성이 없다 보니까 oTL
이 뭐 독립적이고 위계 없는 기준 수치들이 마구마구 난립하고 oTL
테이블 사이의 연계성은 안드로메다로 날아가며 oTL
무엇보다도... '직관에 기인하는 기준 수치'들이 미칠듯이 많아진다 oTL
MMORPG에서는 밸런싱 작업을 하면 계산, 계산, 계산의 연속이었는데... 이건 무슨 직관, 예측, 가라, 땜빵(?), 테스트 해보면 알겠지 뭐(...) 의 연속이라능 oTL
테스트에 기대게 되는 부분이 엄청 커져버리고 있다 -ㅁ-; 아니 테스트의 비중이 큰거야 당연한 일이기도 하지만 ; 이건 좀 심하지 않나 싶을 정도로... oTL
그럼에도 불구하고 직교성과 테이블의 원칙을 지키는 것은 맞다고 판단되므로... 차라리 테스트의 진행, 결과 저장, 열람을 자동화하는 시스템을 별도로 만들 생각이다.
즉 밸런싱 시트의 난해함은 지금보다 더하면 더했지 덜하게 할 생각은 업ㅂ다 냐하하하
... 게임이 안드로메다로 날아가는 것보다는 기획자의 머리가 끓어오르는 쪽이 낫겠지 ( '')
따라서... 이 플젝이 성공적으로 런칭한다면, 나중에 내 뒤를 이어 라이브를 맡게 되실 분이 누구실는지... 미리 애도와 사과의 말씀을 (__)
간단히 설명하자면 이런거다.
수치 A를 +1하면, 이러저러한 공식을 타고 흘러흘러 수치 a는 +5되고, 수치 b는 -5된다고 치자.
그런데 밸런싱 작업을 하다 보니... A를 +5해야 하는 상황이 발생했다.
당연히 a는 +25가 되겠지?
하지만 b가 -25가 되어서는 곤란하다!
오히려 b는 +50이 되어야 한다...
하악 어쩌면 좋나효?
그런데 밸런싱 작업을 하다 보니... A를 +5해야 하는 상황이 발생했다.
당연히 a는 +25가 되겠지?
하지만 b가 -25가 되어서는 곤란하다!
오히려 b는 +50이 되어야 한다...
하악 어쩌면 좋나효?
뭐 이런 곤란한 상황이 없도록... 애초에 a에 관계된 수치 A, b에 관계된 수치 B를 따로 빼놓아야 직교성이 발생하고 모두가 행복해질 수 있다.
그리고 테이블... 요건 히아니마가 예전에 정리를 했었는데 비공개로 돌려버렸근 oTL
암튼 또 간단히 설명하자면...
위의 예에서 A를 +1할 때, a가 +5되기 위하여 중간에 '공식'이라는 놈이 개입했었다.
일단 직교성을 위하야 A의 값이 b의 값에는 영향을 주지 않도록 하고, 공식은 오직 a의 값에만 영향을 주도록 했다고 치자.
그런 후에 공식을 쓰면... 기준값 A를 수정하는 것 만으로도 a1, a2, a3, a4, a5 등등의 값들이 정해진 체계에 따라 차자작 변화해주니, 어찌아니 효율적이랴! 참으로 알흠답구나!
... 라고 생각하기가 쉽지만, 히밤. 저건 아주아주아주아주아주아주(x100) 위험한 상황이다. a1, a2, a3, a4, a5 등등의 값이 필요한가? 그럼 차라리 그걸 테이블의 형태로 만들어라.
밸런싱 작업을 진행하다 보면 A를 +1하는데, a1은 +5되고, a2는 +3되고, a5는 +7되어야 하는 상황이... 거의 '반드시' 발생하기 때문이다.
여담이지만 이전 플젝에서는...
기준 수치 2개와, 이 수치의 상승을 결정하는 공식 2개가... 캐릭터의 '성장'과 '전투'의 거의 모든 구석에 영향을 미치는 구조였다. (하나마나한 변명 및 책임 회피를 해보자면 이 구조 내가 안 만들었다 :P)
... 매우 위험했고, 실제로 문제는 발생했고, 그래서 만만찮은 코스트를 들여 테이블의 형태로 갈아엎는 데 까지는 성공했지만 직교성의 문제는 결국 해결하지 못했다 oTL
기준 수치 2개와, 이 수치의 상승을 결정하는 공식 2개가... 캐릭터의 '성장'과 '전투'의 거의 모든 구석에 영향을 미치는 구조였다. (하나마나한 변명 및 책임 회피를 해보자면 이 구조 내가 안 만들었다 :P)
... 매우 위험했고, 실제로 문제는 발생했고, 그래서 만만찮은 코스트를 들여 테이블의 형태로 갈아엎는 데 까지는 성공했지만 직교성의 문제는 결국 해결하지 못했다 oTL
그러니까 이번 플젝에서는 이런 문제가 없도록!
하나의 기준 수치는 다른 수치에 대하여 최소한의 영향력만을 가지도록!
공식 그게 뭔가효? 사칙 연산 이외의 공식같은건 다 치워뿌러! 아니 애초에 공식은 최소화 해버리고 다 테이블로 빼버려!
... 까지는 좋은데 ( --)
일관성이 없다 보니까 oTL
이 뭐 독립적이고 위계 없는 기준 수치들이 마구마구 난립하고 oTL
테이블 사이의 연계성은 안드로메다로 날아가며 oTL
무엇보다도... '직관에 기인하는 기준 수치'들이 미칠듯이 많아진다 oTL
MMORPG에서는 밸런싱 작업을 하면 계산, 계산, 계산의 연속이었는데... 이건 무슨 직관, 예측, 가라, 땜빵(?), 테스트 해보면 알겠지 뭐(...) 의 연속이라능 oTL
테스트에 기대게 되는 부분이 엄청 커져버리고 있다 -ㅁ-; 아니 테스트의 비중이 큰거야 당연한 일이기도 하지만 ; 이건 좀 심하지 않나 싶을 정도로... oTL
그럼에도 불구하고 직교성과 테이블의 원칙을 지키는 것은 맞다고 판단되므로... 차라리 테스트의 진행, 결과 저장, 열람을 자동화하는 시스템을 별도로 만들 생각이다.
즉 밸런싱 시트의 난해함은 지금보다 더하면 더했지 덜하게 할 생각은 업ㅂ다 냐하하하
... 게임이 안드로메다로 날아가는 것보다는 기획자의 머리가 끓어오르는 쪽이 낫겠지 ( '')
따라서... 이 플젝이 성공적으로 런칭한다면, 나중에 내 뒤를 이어 라이브를 맡게 되실 분이 누구실는지... 미리 애도와 사과의 말씀을 (__)
PvP 밸런싱 이제 겨우 초반을 진행중인데 벌써 이 모냥이면...
나중에 보상 밸런싱, 성장 밸런싱 등등을 진행할 때엔 또 어떤 은하계로 날아가게 될라나... oTL
그래서 PvE 밸런싱은 레벨 디자이너한테 '난 몰라. 즐. 알아서 하셈. PvE면 레벨 관련이자나 레벨! 화이팅! ( --)' 해버리고 입닦아 버리려 했는데 흑흑.
암튼 뭐 그러니까...
그래도...
최소한 일은 재미있으니 다행 ( '')
인생 쉽게 살면 재미있나효 ㅋㅋㅎㅋㅎㅋㅎㅋㅎㅋㅎㅋㅋ
|
Trackback Address :: http://glekang.com/trackback/332
|
[글강, 2008/12/29 22:25, Game]
아직은 공력도, 경력도 미천하야... 감히 이런 글을 싸질러놓는 것이 매우 조심스럽기 짝이 없으나...
미흡한 경험에서 우러나오는 주관, 혹은 편견으로 끄적끄적.
IT 업계 전반이 어느 정도 그런 양상을 보이기는 하지만, 게임업계는 특히나 그래스 호핑(grass hopping)이 잦은 곳이다.
거기에 더하여, 역시나 IT 업계 전반이 어느 정도 그런 양상을 보이기는 하지만, 게임업계는 특히나... 좁디 좁다 -ㅁ-; 어찌나 좁으신지 한 두 다리만 걸치면 모르는 사람이 없을 정도.
이러한 업계의 양상은 개발자로 하여금 어떠한 사고 방식을 가지도록 은연중에 강요하게 된다.
혹은,
등등등?
결국 일종의 업계 불문율이랄까, 혹은 약간 거시적인 프로세스같은 것이 발생하게 된다. 이 업계가 유지되는 방식이라고까지 이야기하자면 좀 거창하겠지만 -ㅁ-;
아무튼 나는 나름대로 저런 사고 방식을 가지고 사는 것이 맞다고 생각했다.
결국 그 덕에 업계가 원활하게 돌아가고, 프로젝트는 진행되고, 게임은 개발되어 나오는 것이니까.
팀원이 나가고 들어오는 것에 따라 프로젝트가 흔들린다면, 어디 게임 개발 할 수 있겠는가.
쿨하지? 쿨할까? 쿨할라나?
반대 급부라 할만한 경우를 목격한 적도 있다.
아직도 존속되고 있을는지는 모르겠지만, 소위 '패밀리'라 불릴만한 개발자 그룹(?)이 통째로 이직을 해가면서 단순 팀원의 그래스 호핑이 아닌, 팀 단위의 그래스 호핑을 하는 것을 본 적이 있는데...
따뜻하고 애틋한... 이라기 보다는 우와 뭔가 부정적인 것 같아. 이것도 일종의 뒷담화가 되려나 -ㅁ-;
아무튼 저런 경우를 본 적이 있는데... 글쎄, 결국 그 패밀리가 패밀리의 이름으로 성공적인 결과물을 낸다면 저것도 나름 괜찮지 않을까? 싶기도 하지만, 역시 그 때나 지금이나 난 저런 방식에 대해서는 부정적이다.
그렇기에 역시 개발자가 중심에 두어야 하는 것은 프로젝트의 완수. 사람을 중심에 두어서는 곤란하다... 라고 생각해 왔는데...
솔직히 요즘은 잘 모르겠다 ㄱ-
이 뭐 내가 차가운 도시 남자. 하지만 내 여자에게는 따뜻하겠지? ... 도 아니고 말야, 쿨! 쿨! 쿨! 외치다가 얼어죽겠구만 ㄱ-
그렇다고 동료를 동료 이상으로, 더욱 살갑고 따땃하게 대하면서 살면 세상은 좀 더 아름다와지지 않을까? ... 뭐 이런 이야기를 하려는 것도 아니다.
여전히 개발자에게 있어 프로젝트의 완수를 중심에 두는 것은 맞는 것이라 생각한다.
하지만 이를 위해 개발자가 자기 스스로를, 그리고 동료들을 톱니바퀴로 치부하는 것이 과연 맞을까?
요걸 잘 모르겠다. 그렇게 돌아가는 팀이 과연 좋은 팀일까?
동료에게 동료 이상을 기대하지 않는 조직은 거의 필연적으로 정체된다고 할까, 혹은 말라붙어 버리기가 쉽다.
게임 개발이라는 직업 내에 여러가지 직군이 존재하기는 하지만, 결국 이 직군들 중 어느 하나도 독립적으로 기능하는 것은 없으며, 모든 직군은 서로 얽히고 섥히게 마련이다.
그러나 자신과 타인을 톱니바퀴로 생각하는 팀원들에게 있어 이러한 얽히고 섥히기는... 쉬운 일이 아니다. 심지어 조직이 크든 작든 관계 없이 말이다.
물론 이 얽히는 것을 중간에서 잘 관리해주는 조율자가 있다면, 서로가 서로를 톱니바퀴로 인식하면서도 얼추얼추 프로젝트가 잘 진행되는 것처럼 보이기는 하지만... 글쎄, 내 경험상 이런 방식은 결국 그 조율자를 죽이고 만다 ㄱ-
그리고 조율자가... 죽지는 않고 ㄱ-;;; 혹여 퍼포먼스가 3~40%만 저하된다 하더라도 그 조직은 급속도로 말라붙는다.
혹시 조율자가 없더라도, 팀원들이 애초에 '공적인 피드백'을 자주 할 수 있는 프로세스를 만든다면 괜찮지 않을까...?
글쎄 -ㅁ- 이거이 참 이상적이긴 한데, 인간이라는게 그렇게 공사 구분을 명확히 할 수 있는 존재가 아니라서리... 단적으로 말해 '모든 중요한 결정은 담배터에서 나온다'라는 말이 괜히 있는 것이 아니다.
즉 프로세스만으로는 부족하지 않나 싶다.
결국 조직이 말라붙어 버리게 되면... 직군 사이의 피드백이 사라지고, 누구도 게임의 어떠한 요소에 대하여 책임지지도 - 관심가지지도 않는 사태가 벌어지게 되는데...
뭐 그럼에도 불구하고 프로젝트가 완수될 수는 있다. 제대로 된 게임이 나올 가능성은 좀 많이 낮아지므로, 성공 가능성은 로또 비슷해져 버리지만 -ㅁ-;
그렇다고 공적인 동료가 사적인 영역을 마구마구 넘나드는 조직의 경우에는 반대로... 조직이 외부에 대하여 배타적이 될 가능성이 높고, 조직 내에서는 비효율적인 운영이 이루어질 가능성이 높다.
이러한 조직에서는 사람 하나의 가치가 지나치게 커지는 위험이 존재한다.
팀원의 이탈이 팀 전체의 사기에 악영향을 미칠 수 있고, 반대로 새로운 팀원의 진입은 그 조직이 배타적인만큼 쉽지가 않다.
출혈은 있을 수 있지만, 수혈은 어려운... 이게 뭔가효. 자살해가는 조직도 아니고 ㄱ-
더불어 조직 내에서 서로의 사적인 영역을 넘나들다 보면... 한국에서 특히 보기 쉬운 구도인 '형님 / 아우' 서열이 발생하기 쉽고, '형님에게 굽신굽신 / 아우니까 봐준다'와 같은... 곤란한 상황이 개발 효율을 저해하기가 쉽다.
팀원들 서로가 사적인 친분을 유지하되, 공적인 부분에 대해서는 최대한 드라이하게 접근한다면...?
위에서도 말했지만 인간이란 그렇게 공사 구분을 명확히 할 수 있는 존재가 아니...
그럼 그러한 공적인 부분을 조율해 줄 관리자를 외부에 둔다면...?
배타적인 조직은 그런 관리자를... 죽인다 ㄱ- 혹은 조직이 빠져버리등가 ㄱ- 그래스 호핑~
그래서 결국 프로젝트의 완수보다는 조직의 안녕이 우선 가치로 정립되는 사태가 벌어지고 만다. 뭐 이런걸 소위 개발을 말아먹는 정치라고 불러도 되지 않을까나...
그러니까 결국 정도의 문제인데...
가장 좋은 것은 그 중간일까?
즉, 팀원들 사이에 사적인 친분이 어느 정도 존재하기에 이는 원활한 피드백의 원천이 되어주고...
그러나 이 친분이 공적인 영역을 넘어서지 않아, 일에 대해서는 최대한(!) 냉정하면서도 대등한 관계가 형성되며...
더불어 개발 프로세스는 각 직군들이 최대한 서로 얽히고 섥힐 수 있도록 기능해 주어야 한다.
쯥. 말은 쉽다만... ㄱ-
아직은 나도 이러한 이상적인(?) 구조를 어떻게 하면 형성하고, 유지할 수 있을는지를 잘 모르겠다.
이제야 겨우 '톱니바퀴로는 안되겠는데?'를 깨달은 정도이고...
그렇다고 동료한테 어느 정도까지의 선을 걷어내고, 어느 정도까지의 선을 허용해야 하는 것인지 역시 아직은 잘 모르겠는 모호한 상태이며... -ㅁ-
더구나 그럼에도 불구하고 발생할 수 밖에 없는 그래스 호핑에 대하여... 이런 조직이 어느 정도 가지게 되는 취약성 - 그러니까 결국 대미지를 어떻게 컨트롤해야 할는지도 잘 모르겠다.
... 이거 뭔가 사회 조직론 내지는 경영학(?)을 찾아보면, 이런 이야기가 좀 나와있지 않을까 싶기는 한데 ( --)
현재로서는 현재 내가 지금 몸담고 있는 팀이 나름 줄타기를 해나가는 모습을 관찰하고, 참여하면서 좀 더 생각을 진행하는 수밖에 없을 듯 싶다.
팀 내에서 호형호제가 이루어질 만큼의 사적인 친분이 있으면서, 이것이 공적인 영역을 침범하지는 않고, 잦은 피드백을 반 강제(?)로 보장하는 프로세스... 를 일단 어느 정도는 아슬아슬 줄타기하고 있는 우리 팀은...
이건 아무래도 더 시간을 두고, 조심스레 지켜봐야하지 않을까나 싶다.
아니 잠깐, 방관자로 지켜보겠다는 것이 아니라... 결국은 나 역시 한 명의 팀원으로서.
미흡한 경험에서 우러나오는 주관, 혹은 편견으로 끄적끄적.
IT 업계 전반이 어느 정도 그런 양상을 보이기는 하지만, 게임업계는 특히나 그래스 호핑(grass hopping)이 잦은 곳이다.
오늘 함께 일하고 있는 동료가, 내일은 다른 개발사, 혹은 다른 팀으로 옮겨 가는 것은 매우 흔한 일. 너무나도 흔해서 언급할 꺼리조차 되지 않는다.
거기에 더하여, 역시나 IT 업계 전반이 어느 정도 그런 양상을 보이기는 하지만, 게임업계는 특히나... 좁디 좁다 -ㅁ-; 어찌나 좁으신지 한 두 다리만 걸치면 모르는 사람이 없을 정도.
따라서 내일 다른 개발사, 혹은 다른 팀으로 옮겨 간 동료가, 내일 모레에는 다시 같은 개발사, 혹은 같은 팀으로 돌아오는 것 역시... 흔하다고 할 정도까지는 아니지만 희귀한 일 또한 아니다.
이러한 업계의 양상은 개발자로 하여금 어떠한 사고 방식을 가지도록 은연중에 강요하게 된다.
동료의 이직에 대하여 초연하라. 그 것은 그 사람의 권리이다. 물론 프로젝트의 상황에 따라 도의적인 차원의 문제가 있을 수는 있지만, 애초에 팀원의 이탈은 프로젝트 단위에서 발생할 수 있는 리스크 중의 하나로 관리되어야 한다.
즉, 동료를 동료 이상으로 너무 깊이 생각하지 마라. 너무 기대하고 신뢰하지 마라. 쿨하라.
즉, 동료를 동료 이상으로 너무 깊이 생각하지 마라. 너무 기대하고 신뢰하지 마라. 쿨하라.
혹은,
동료의 치부에 대하여 초연하라. 그 것은 그 사람의 치부일 뿐, 왈가왈부할 성질의 것이 못된다. 이 좁은 업계에는 비밀이라는 것이 없다. 뒷담화는 돌고 돌아 결국 자기 자신의 뒤통수를 치게 될 뿐이다.
즉, 동료에게 너무 큰 기대를 하지 말아야하는 만큼, 동시에 동료의 부정적인 측면에 대해서도 너무 관여하지 마라. 쿨하라.
즉, 동료에게 너무 큰 기대를 하지 말아야하는 만큼, 동시에 동료의 부정적인 측면에 대해서도 너무 관여하지 마라. 쿨하라.
등등등?
결국 일종의 업계 불문율이랄까, 혹은 약간 거시적인 프로세스같은 것이 발생하게 된다. 이 업계가 유지되는 방식이라고까지 이야기하자면 좀 거창하겠지만 -ㅁ-;
아무튼 나는 나름대로 저런 사고 방식을 가지고 사는 것이 맞다고 생각했다.
결국 그 덕에 업계가 원활하게 돌아가고, 프로젝트는 진행되고, 게임은 개발되어 나오는 것이니까.
팀원이 나가고 들어오는 것에 따라 프로젝트가 흔들린다면, 어디 게임 개발 할 수 있겠는가.
모든 것은 프로젝트의 완수를 위하여. 팀원은 결국 톱니바퀴 중의 하나. 아 물론 나 역시도 하나의 톱니바퀴일 뿐. 서로에게 그 이상을 기대하지 않는다면... 그래스 호핑이 아무리 잦다 하더라도, 프로젝트에는 최소한의 영향만을 줄 수 있다. 모든 것은 프로젝트의 완수를 위하여.
쿨하지? 쿨할까? 쿨할라나?
반대 급부라 할만한 경우를 목격한 적도 있다.
아직도 존속되고 있을는지는 모르겠지만, 소위 '패밀리'라 불릴만한 개발자 그룹(?)이 통째로 이직을 해가면서 단순 팀원의 그래스 호핑이 아닌, 팀 단위의 그래스 호핑을 하는 것을 본 적이 있는데...
모든 것은 패밀리의 안녕을 위하여. 프로젝트 완수는 패밀리의 가치를 드높이기 위하여. 물론 패밀리 내에서는 노골적인(?) 봐주기가 횡행하며, 패밀리 외부인에 대해서는 철저히 배타적으로. 만약 패밀리의 존재가 프로젝트 완수에 걸림돌이 된다면, 차라리 프로젝트를 포기하고 그래스 호핑~ 모든 것은 패밀리의 안녕을 위하여.
따뜻하고 애틋한... 이라기 보다는 우와 뭔가 부정적인 것 같아. 이것도 일종의 뒷담화가 되려나 -ㅁ-;
아무튼 저런 경우를 본 적이 있는데... 글쎄, 결국 그 패밀리가 패밀리의 이름으로 성공적인 결과물을 낸다면 저것도 나름 괜찮지 않을까? 싶기도 하지만, 역시 그 때나 지금이나 난 저런 방식에 대해서는 부정적이다.
그렇기에 역시 개발자가 중심에 두어야 하는 것은 프로젝트의 완수. 사람을 중심에 두어서는 곤란하다... 라고 생각해 왔는데...
솔직히 요즘은 잘 모르겠다 ㄱ-
이 뭐 내가 차가운 도시 남자. 하지만 내 여자에게는 따뜻하겠지? ... 도 아니고 말야, 쿨! 쿨! 쿨! 외치다가 얼어죽겠구만 ㄱ-
그렇다고 동료를 동료 이상으로, 더욱 살갑고 따땃하게 대하면서 살면 세상은 좀 더 아름다와지지 않을까? ... 뭐 이런 이야기를 하려는 것도 아니다.
여전히 개발자에게 있어 프로젝트의 완수를 중심에 두는 것은 맞는 것이라 생각한다.
아니 이건 개발자 이전에, 돈받고 일하는 프로라면 당연한 것이 아닌가 싶은데...
아니 프로 이전이라 해도, 애초에 직업이 자아 실현의 도구라면 또 당연하지 않나...
하지만 이를 위해 개발자가 자기 스스로를, 그리고 동료들을 톱니바퀴로 치부하는 것이 과연 맞을까?
요걸 잘 모르겠다. 그렇게 돌아가는 팀이 과연 좋은 팀일까?
동료에게 동료 이상을 기대하지 않는 조직은 거의 필연적으로 정체된다고 할까, 혹은 말라붙어 버리기가 쉽다.
게임 개발이라는 직업 내에 여러가지 직군이 존재하기는 하지만, 결국 이 직군들 중 어느 하나도 독립적으로 기능하는 것은 없으며, 모든 직군은 서로 얽히고 섥히게 마련이다.
그러나 자신과 타인을 톱니바퀴로 생각하는 팀원들에게 있어 이러한 얽히고 섥히기는... 쉬운 일이 아니다. 심지어 조직이 크든 작든 관계 없이 말이다.
물론 이 얽히는 것을 중간에서 잘 관리해주는 조율자가 있다면, 서로가 서로를 톱니바퀴로 인식하면서도 얼추얼추 프로젝트가 잘 진행되는 것처럼 보이기는 하지만... 글쎄, 내 경험상 이런 방식은 결국 그 조율자를 죽이고 만다 ㄱ-
그리고 조율자가... 죽지는 않고 ㄱ-;;; 혹여 퍼포먼스가 3~40%만 저하된다 하더라도 그 조직은 급속도로 말라붙는다.
혹시 조율자가 없더라도, 팀원들이 애초에 '공적인 피드백'을 자주 할 수 있는 프로세스를 만든다면 괜찮지 않을까...?
글쎄 -ㅁ- 이거이 참 이상적이긴 한데, 인간이라는게 그렇게 공사 구분을 명확히 할 수 있는 존재가 아니라서리... 단적으로 말해 '모든 중요한 결정은 담배터에서 나온다'라는 말이 괜히 있는 것이 아니다.
즉 프로세스만으로는 부족하지 않나 싶다.
결국 조직이 말라붙어 버리게 되면... 직군 사이의 피드백이 사라지고, 누구도 게임의 어떠한 요소에 대하여 책임지지도 - 관심가지지도 않는 사태가 벌어지게 되는데...
뭐 그럼에도 불구하고 프로젝트가 완수될 수는 있다. 제대로 된 게임이 나올 가능성은 좀 많이 낮아지므로, 성공 가능성은 로또 비슷해져 버리지만 -ㅁ-;
그렇다고 공적인 동료가 사적인 영역을 마구마구 넘나드는 조직의 경우에는 반대로... 조직이 외부에 대하여 배타적이 될 가능성이 높고, 조직 내에서는 비효율적인 운영이 이루어질 가능성이 높다.
이러한 조직에서는 사람 하나의 가치가 지나치게 커지는 위험이 존재한다.
팀원의 이탈이 팀 전체의 사기에 악영향을 미칠 수 있고, 반대로 새로운 팀원의 진입은 그 조직이 배타적인만큼 쉽지가 않다.
출혈은 있을 수 있지만, 수혈은 어려운... 이게 뭔가효. 자살해가는 조직도 아니고 ㄱ-
더불어 조직 내에서 서로의 사적인 영역을 넘나들다 보면... 한국에서 특히 보기 쉬운 구도인 '형님 / 아우' 서열이 발생하기 쉽고, '형님에게 굽신굽신 / 아우니까 봐준다'와 같은... 곤란한 상황이 개발 효율을 저해하기가 쉽다.
팀원들 서로가 사적인 친분을 유지하되, 공적인 부분에 대해서는 최대한 드라이하게 접근한다면...?
위에서도 말했지만 인간이란 그렇게 공사 구분을 명확히 할 수 있는 존재가 아니...
그럼 그러한 공적인 부분을 조율해 줄 관리자를 외부에 둔다면...?
배타적인 조직은 그런 관리자를... 죽인다 ㄱ- 혹은 조직이 빠져버리등가 ㄱ- 그래스 호핑~
그래서 결국 프로젝트의 완수보다는 조직의 안녕이 우선 가치로 정립되는 사태가 벌어지고 만다. 뭐 이런걸 소위 개발을 말아먹는 정치라고 불러도 되지 않을까나...
그러니까 결국 정도의 문제인데...
톱니바퀴는 위험하다.
패밀리도 위험하다.
가장 좋은 것은 그 중간일까?
즉, 팀원들 사이에 사적인 친분이 어느 정도 존재하기에 이는 원활한 피드백의 원천이 되어주고...
그러나 이 친분이 공적인 영역을 넘어서지 않아, 일에 대해서는 최대한(!) 냉정하면서도 대등한 관계가 형성되며...
더불어 개발 프로세스는 각 직군들이 최대한 서로 얽히고 섥힐 수 있도록 기능해 주어야 한다.
쯥. 말은 쉽다만... ㄱ-
아직은 나도 이러한 이상적인(?) 구조를 어떻게 하면 형성하고, 유지할 수 있을는지를 잘 모르겠다.
이제야 겨우 '톱니바퀴로는 안되겠는데?'를 깨달은 정도이고...
그렇다고 동료한테 어느 정도까지의 선을 걷어내고, 어느 정도까지의 선을 허용해야 하는 것인지 역시 아직은 잘 모르겠는 모호한 상태이며... -ㅁ-
더구나 그럼에도 불구하고 발생할 수 밖에 없는 그래스 호핑에 대하여... 이런 조직이 어느 정도 가지게 되는 취약성 - 그러니까 결국 대미지를 어떻게 컨트롤해야 할는지도 잘 모르겠다.
... 이거 뭔가 사회 조직론 내지는 경영학(?)을 찾아보면, 이런 이야기가 좀 나와있지 않을까 싶기는 한데 ( --)
현재로서는 현재 내가 지금 몸담고 있는 팀이 나름 줄타기를 해나가는 모습을 관찰하고, 참여하면서 좀 더 생각을 진행하는 수밖에 없을 듯 싶다.
팀 내에서 호형호제가 이루어질 만큼의 사적인 친분이 있으면서, 이것이 공적인 영역을 침범하지는 않고, 잦은 피드백을 반 강제(?)로 보장하는 프로세스... 를 일단 어느 정도는 아슬아슬 줄타기하고 있는 우리 팀은...
글쎄, 어느 정도 배타성을 가지고 있지는 않을까. 어느 정도 말라있는 것은 아닐까. 혹은 팀의 규모가 중소 정도이기 때문에 겨우 유지되는 것은 아닐까. 또는 이 모든 것이 결국 한 사람의 조율자를 죽이고 있는 것은 아닐까.
이건 아무래도 더 시간을 두고, 조심스레 지켜봐야하지 않을까나 싶다.
아니 잠깐, 방관자로 지켜보겠다는 것이 아니라... 결국은 나 역시 한 명의 팀원으로서.
|
Trackback Address :: http://glekang.com/trackback/328
|
[글강, 2007/10/24 19:34, Game]
다들 여기저기서 하도 데인 덕분(?)인지... 그나마 요즘은 덜하지만...
그래도 여전히 종종 울려퍼지곤 하는 유명한 분노의 일갈.
"제발 좀 클베 수준으로 오베하지 말란 말이야~~~ 대체 왜? 어째서? 이렇게 내놓으면 망할거라는거 뻔히 알면서도~~~ 왜 오픈한거야??? 더 개발하고 오픈하란 말이야~~~!!!"
아 예. 저도 종종 그런 일갈에 동참하곤 했었슴미다 ㄳ 이 블록도 뒤져보면 저런 이야기 조낸 많아효 음하하
그런데 달리 생각해보면 실로 의아한 일이다.
4번에서 더 나아가지 못하면, 그냥 분노의 일갈 한번 싸지르고는 즐. 대답은 미궁 속으로~
아 예. 저도 저 이유를 모르겠어서 그냥 싸지르고 나서는 즐때리곤 했슴미다 음하하
하지만 이제는 어느정도 슬슬... 보이는 그 이유에 대한 이야기.
사실 산수만 한번 해보면 간단한 거였어!!!
게임을 왜 만드십니까? 돈벌려고효!
(졸라 훌륭한 게임을 만들어서 개발자의 성취감을 극대화하고, 유저들에게 인생의 새로운 길을 열어주는 경험을 선사하... 블라블라? KIN)
게임 만들어서 돈은 어떻게 법니까? 개발에 들이는 비용 < 수익이 되면 돈버는거죠!
아 그럼 당연하게도 -_- 지극히 당연하게도... 개발에 들이는 비용은 적을 수록 좋고, 수익은 많을 수록 좋은거네효? (이 뭐 장난치는 것도 아니고...)
그런데 수익이 많이 날 것인지... 이 게임이 정말 대박칠는지 여부는... 아무도 모름미다. 개발측이 컨트롤할 수 있는 부분이 아니졈.
(혹여나 이 시점에서... 재미있으면 대박친다! 개발측이 게임을 재미있게 만들면 되겠네! 라고 하실 분들은... 아 이걸 쓰기 시작하면 이게 본문이 되겠다. 걍 KIN)
그럼 결국 개발측에서 명확히 컨트롤할 수 있는 부분은 비용이근염. 그런데 비용은 어디에서 발생하는거죠?
물론... 사무실 임대료, 서버값, 회선값, 컴터값, 회식비 등등이 있지만 그런 듣보잡들은 걍 짜지고... 개발 비용의 가장 큰 부분을 차지하는 것은 인건비!!! 아 그 외에도 마케팅 비용이 있군효. 하지만 그건 개발이 완료되는 시점에서나 나가는 비용이니... 큰 부분이지만 일단 여기서는 홀드. 뒤에서 다시 나옴미다.
결국 사람값이다. 사람값을 줄이면 개발 비용이 줄어든다.
... 여기서 우리는 왜 그렇게 수많은 싸장니마들이 "뮤는 3명이서 만들었다는데?"를 외치는지 알 수 있슴미다. 하지만 요즘 세상에 3명이 만든 게임으로는... oTL
블록 버스터의 세상이 되어버려서리 일정수 이상의 인원은 어떻게든 필요함미다. 그럼 사람값을 어찌 줄이죠?
... 잘 아시면서. 연봉을 깎아버리면 되는거졈. 사람 수는 줄이고! 연봉은 깎고! 일은 많이 시킨다! 정답인거졈. ㅅㅂ
"개발자 착취를 하면 비용을 적게 들이면서 게임을 만들 수 있으니, 충분히 개발한 다음에 시장에 내놓을 수 있는거자나?! 그런데도 왜 만들다가 만 녀석을 오베하는건데?"
... 라는 반문. 그럴싸한데?
그 이유를 추적하기 위하여, 우리는 역지사지의 정신을 발휘하여 개발 비용을 대는 사람. 즉 싸장님하의 입장이 되어 볼 필요가 있다.
다음과 같은 개발 프로젝트를 가정해보자.
12개월의 기간 내내 20명이 필요할 리는 없다. 개발 초기 단계에는 기반 작업을 할 수 있는 5명 만으로 충분하다. 5명으로 시작해서... 3개월마다 5명씩 충원을 한다고 쳐보자.
이 경우 12개월 동안 소모되는 인건비는...
12월이 된 시점에서... 지금까지 3억원을 부었고! 한달에 인건비만 4천만원씩 꼬박꼬박 나가고 있다! 더구나 이제 런칭을 하게 되면 마케팅 비용으로 한 1억원 또 나가야 한다! 과연 이 프로젝트는 총 비용 4억원으로 종결될 수 있을 것인가!
그런데...
"저기요 싸장님하 아직 개발이 완료되지 않았거등효... 지금 런칭하면 망할 것 같아효. 한 반년만 더 연장을..."
6개월 더 개발 진행?!
다음해 6월이면 누적된 총 비용이 5억 4천만원! 6개월동안 더 붓는 돈이 2억 4천만원! 이런 ㅆㅂ 지난 해에는 6개월에 9천만원을 부었는데, 이제는 6개월 동안 들어가는 인건비가 2억 4천만원이라고효?!
그래도 마케팅 1억원 더해서 6억 4천만원으로 어떻게든 총 비용 종결이 되려는 순간...
"근데효 싸장님하... 아무래도 런칭 할 수준은 아니예효. 오베는 한 12월 정도에... 그리고 개발자가 한 10명 정도 더 필요할 것 같거등효?"
...
헥헥... 6개월 더 연장했더니, 그 사이에 3억 6천만원이 또 나갔네효. 지금까지의 누적은 9억원! 그나마 다행으로 12월에 오베 런칭할 수 있다면... 마케팅비 1억원. 총 비용은 10억원~ ㄳ
...
...
...
불쌍한 우리 싸장님 ㅠㅠ
만약 이 프로젝트가 첫해 12월에 성공적으로 런칭했다면 마케팅 합쳐서 총 비용은 4억원이었을 텐데... 1년을 연장 했더니만 런칭까지의 총 비용이 10억원! 기간은 2배인데 드는 돈은 2.5배야!!!
만약 당신이 '음하하하 더러운 개발자 색휘들한테 생흡 빨대 꽂아서 착취하면 1년에 넉넉잡아 5억으로 게임 하나 만들 수 있겠군하~ 여유자금도 1억이나 되니 충분하겠지! 우왕ㅋ굳ㅋ'이라고 생각했던 싸장님이라면...
개발 기간의 6개월 연장을 요청받는 시점에서... 예상되는 총 비용 6억 4천만원으로, 원래 가진 돈 5억원에서 1억 4천만원 오버합니다.
1번을 선택하셨슴미다만... 6개월 더 필요하데효. 개발자도 더 늘려달라는 군효. 예상 총 비용은 10억원으로... 5억원 다 썼고, 빚이 1억 4천만원인데... 이제 3억 6천만원의 빚을 더 져야만 가능하겠군효?
1번을 선택하시는 훌륭한 분들도 계시겠지만... 정신줄 놓지 않은 이상 상식적으로는 2번이 맞을 것 같다. 어라? 잠깐? 2번이라고?
게임이 오베 수준의 완성도를 갖추지 못했음에도 불구하고 런칭을 선택한다고?!
... 네 그렇슴미다 ㄳ
즉 정리하자면 다음과 같다.
어찌하리오. 감당이 안되면 죽이 되든 밥이 되든 런칭할 수밖에 없어효. 망하는 결과가 같더라도 최소한 신체포기각서는 안써도 되니까 ㄱ-
자금이 충분하다면?! 싸장님하가 처음부터 한 100억 들고 시작했다면?
... 그 경우에는 신체포기각서를 쓸 일은 없겠지만서도, 개발 기간을 1년 연장하는 것으로 애초에 예정되었던 개발 비용 4억원에 추가적으로 6억원이 더해져 총 개발 비용은 10억원이 되어버린다. 개발 기간 1년 연장이 과연 6억원을 초과하는 수익을 보장해 줄 수 있을 것인가?!
보장 못 해준다면... 적자임미다. 어라 잠깐! 우리 돈 벌려고 게임 만드는 건데 적자라고?!
이 뭐... 개발이 뒤로 가면 갈 수록 이러지도 저러지도 못하는 상황이 벌어지는 것이다. 게임이 성공한다는 확신만 있다면야, 적자를 보지 않을 수 있다는 확신만 있다면야 거리낌없이 돈을 붓겠지만... 글쎄 세상에 그거 확신할 수 있는 사람은 아무도 없다니까효.
...이미 쏟아부은 돈은 한가득.
...... 게임이 수익을 내기 전에는 회수할 가능성 없음.
......... 하지만 수익을 내려면 런칭을 해야하고, 런칭을 하려면 앞으로 점점 더 많은 비용을 지출해야 함.
............ 런칭하면 반드시 수익을 낼 수 있을 것인가? 그런 보장은 없음.
ㅎㄷㄷ... 이거 어디선가 많이 본 듯한 상황이지 않은가?

물론 이 외에도 수많은 요인이 존재하지만서도... 외부인도 손쉽게 계산해볼 수 있는 산수의 결과만 가지고도 이 정도이다. 그래서 결국 우리는 종종... 분노의 일갈을 지르게 되는 것. 하지만 어찌하리오? 저 쪽도 바보라서 그러는 것은 아닌 것이다.
그래서? 우리는 계속 분노의 일갈을 지를 수밖에 없는 것인가?! 아니면 싸장니마의 불쌍한 사정을 알았으니 걍 닥치고 있으면 되는 건가효?
그래서는 곤란하다. 문제는 해결되지 않는다.
그래서 이것을 해결하기 위한 다양한 방법들이 제시되고 있으니...
1. 개발자들을 더욱 착취한다.
2. 개발자들의 생산성을 극대화할 수 있는 방안을 모색한다.
3. 개발 프로세스를 정비하여, 개발 기간 1년 연장과 같은 재앙을 막는다.
4. 비용이 적게 드는 개발 초기 단계 - 프리 프로덕션 단계의 기간을 늘리고, 그만큼 그 기간에 게임의 프로토타이핑을 철저히 시행하여 검증한다.
5. 일본을 공격한다.
아직은... 요만큼 밖에 보이지 않는다. 아는 사람이 보기엔 이뭐병 수준의 분석일 듯 ㅋㅋㅋ
더구나 다음과 같은 문제들에 대해서는 아직 답을 모르겠다.
"될 성 싶은 나무와 안될 성 싶은 나무는 어떻게 구별하나효? 그 기준을 과연 세울 수 있을까효?"
"그래서 새싹을 자르면 그 개발자들은? 같이 자르는 건가효? 아무리 게임계가 그나마 그래스호핑이 자유로운 곳이라고는 해도... 글쎄효. 한국 사회에서는 좀 안맞을 텐데효?"
뭐 시간이 지나면 더 보이고, 대답이 명확해질 것 같기는 한데...
하지만 역시 말이졈 -_- 말단 개발자에게 이런 경영스러븐(?) 고민을 하게 만드는 사회는 뭔가 잘못되어 있는 것 같지 않나효?!
그래도 여전히 종종 울려퍼지곤 하는 유명한 분노의 일갈.
"제발 좀 클베 수준으로 오베하지 말란 말이야~~~ 대체 왜? 어째서? 이렇게 내놓으면 망할거라는거 뻔히 알면서도~~~ 왜 오픈한거야??? 더 개발하고 오픈하란 말이야~~~!!!"
아 예. 저도 종종 그런 일갈에 동참하곤 했었슴미다 ㄳ 이 블록도 뒤져보면 저런 이야기 조낸 많아효 음하하
그런데 달리 생각해보면 실로 의아한 일이다.
1. 만들다가 만 게임을 좋다고 해 줄 유저들은 당연히 적다.
2. 즉 그런 수준으로 오베를 하면 성공할 가능성은 당연히 낮다.
3. 이걸 개발측이라 해서 모를 리는 당연히 없다. 그 사람들이 바보인가?
4. 그런데도 대체 왜???
2. 즉 그런 수준으로 오베를 하면 성공할 가능성은 당연히 낮다.
3. 이걸 개발측이라 해서 모를 리는 당연히 없다. 그 사람들이 바보인가?
4. 그런데도 대체 왜???
4번에서 더 나아가지 못하면, 그냥 분노의 일갈 한번 싸지르고는 즐. 대답은 미궁 속으로~
아 예. 저도 저 이유를 모르겠어서 그냥 싸지르고 나서는 즐때리곤 했슴미다 음하하
하지만 이제는 어느정도 슬슬... 보이는 그 이유에 대한 이야기.
사실 산수만 한번 해보면 간단한 거였어!!!
게임을 왜 만드십니까? 돈벌려고효!
(졸라 훌륭한 게임을 만들어서 개발자의 성취감을 극대화하고, 유저들에게 인생의 새로운 길을 열어주는 경험을 선사하... 블라블라? KIN)
게임 만들어서 돈은 어떻게 법니까? 개발에 들이는 비용 < 수익이 되면 돈버는거죠!
아 그럼 당연하게도 -_- 지극히 당연하게도... 개발에 들이는 비용은 적을 수록 좋고, 수익은 많을 수록 좋은거네효? (이 뭐 장난치는 것도 아니고...)
그런데 수익이 많이 날 것인지... 이 게임이 정말 대박칠는지 여부는... 아무도 모름미다. 개발측이 컨트롤할 수 있는 부분이 아니졈.
(혹여나 이 시점에서... 재미있으면 대박친다! 개발측이 게임을 재미있게 만들면 되겠네! 라고 하실 분들은... 아 이걸 쓰기 시작하면 이게 본문이 되겠다. 걍 KIN)
그럼 결국 개발측에서 명확히 컨트롤할 수 있는 부분은 비용이근염. 그런데 비용은 어디에서 발생하는거죠?
물론... 사무실 임대료, 서버값, 회선값, 컴터값, 회식비 등등이 있지만 그런 듣보잡들은 걍 짜지고... 개발 비용의 가장 큰 부분을 차지하는 것은 인건비!!! 아 그 외에도 마케팅 비용이 있군효. 하지만 그건 개발이 완료되는 시점에서나 나가는 비용이니... 큰 부분이지만 일단 여기서는 홀드. 뒤에서 다시 나옴미다.
결국 사람값이다. 사람값을 줄이면 개발 비용이 줄어든다.
... 여기서 우리는 왜 그렇게 수많은 싸장니마들이 "뮤는 3명이서 만들었다는데?"를 외치는지 알 수 있슴미다. 하지만 요즘 세상에 3명이 만든 게임으로는... oTL
블록 버스터의 세상이 되어버려서리 일정수 이상의 인원은 어떻게든 필요함미다. 그럼 사람값을 어찌 줄이죠?
... 잘 아시면서. 연봉을 깎아버리면 되는거졈. 사람 수는 줄이고! 연봉은 깎고! 일은 많이 시킨다! 정답인거졈. ㅅㅂ
"개발자 착취를 하면 비용을 적게 들이면서 게임을 만들 수 있으니, 충분히 개발한 다음에 시장에 내놓을 수 있는거자나?! 그런데도 왜 만들다가 만 녀석을 오베하는건데?"
... 라는 반문. 그럴싸한데?
그 이유를 추적하기 위하여, 우리는 역지사지의 정신을 발휘하여 개발 비용을 대는 사람. 즉 싸장님하의 입장이 되어 볼 필요가 있다.
다음과 같은 개발 프로젝트를 가정해보자.
개발 기간 : 1월에 시작해서 12월에 오베 런칭!
초기 필요 인원 : 5명
최대 필요 인원 : 20명
월급 : 귀찮으니 딱 잘라 모두 200만원
초기 필요 인원 : 5명
최대 필요 인원 : 20명
월급 : 귀찮으니 딱 잘라 모두 200만원
12개월의 기간 내내 20명이 필요할 리는 없다. 개발 초기 단계에는 기반 작업을 할 수 있는 5명 만으로 충분하다. 5명으로 시작해서... 3개월마다 5명씩 충원을 한다고 쳐보자.
이 경우 12개월 동안 소모되는 인건비는...
1월 : 5명 1,000만원 (누적 1,000만원)
2월 : 5명 1,000만원 (누적 2,000만원)
3월 : 5명 1,000만원 (누적 3,000만원)
4월 : 10명 2,000만원 (누적 5,000만원)
5월 : 10명 2,000만원 (누적 7,000만원)
6월 : 10명 2,000만원 (누적 9,000만원)
7월 : 15명 3,000만원 (누적 12,000만원)
8월 : 15명 3,000만원 (누적 15,000만원)
9월 : 15명 3,000만원 (누적 18,000만원)
10월 : 20명 4,000만원 (누적 22,000만원)
11월 : 20명 4,000만원 (누적 26,000만원)
12월 : 20명 4,000만원 (누적 30,000만원)
2월 : 5명 1,000만원 (누적 2,000만원)
3월 : 5명 1,000만원 (누적 3,000만원)
4월 : 10명 2,000만원 (누적 5,000만원)
5월 : 10명 2,000만원 (누적 7,000만원)
6월 : 10명 2,000만원 (누적 9,000만원)
7월 : 15명 3,000만원 (누적 12,000만원)
8월 : 15명 3,000만원 (누적 15,000만원)
9월 : 15명 3,000만원 (누적 18,000만원)
10월 : 20명 4,000만원 (누적 22,000만원)
11월 : 20명 4,000만원 (누적 26,000만원)
12월 : 20명 4,000만원 (누적 30,000만원)
12월이 된 시점에서... 지금까지 3억원을 부었고! 한달에 인건비만 4천만원씩 꼬박꼬박 나가고 있다! 더구나 이제 런칭을 하게 되면 마케팅 비용으로 한 1억원 또 나가야 한다! 과연 이 프로젝트는 총 비용 4억원으로 종결될 수 있을 것인가!
그런데...
"저기요 싸장님하 아직 개발이 완료되지 않았거등효... 지금 런칭하면 망할 것 같아효. 한 반년만 더 연장을..."
6개월 더 개발 진행?!
다음해 1월 : 20명 4,000만원 (누적 34,000만원)
다음해 2월 : 20명 4,000만원 (누적 38,000만원)
다음해 3월 : 20명 4,000만원 (누적 42,000만원)
다음해 4월 : 20명 4,000만원 (누적 46,000만원)
다음해 5월 : 20명 4,000만원 (누적 50,000만원)
다음해 6월 : 20명 4,000만원 (누적 54,000만원)
다음해 2월 : 20명 4,000만원 (누적 38,000만원)
다음해 3월 : 20명 4,000만원 (누적 42,000만원)
다음해 4월 : 20명 4,000만원 (누적 46,000만원)
다음해 5월 : 20명 4,000만원 (누적 50,000만원)
다음해 6월 : 20명 4,000만원 (누적 54,000만원)
다음해 6월이면 누적된 총 비용이 5억 4천만원! 6개월동안 더 붓는 돈이 2억 4천만원! 이런 ㅆㅂ 지난 해에는 6개월에 9천만원을 부었는데, 이제는 6개월 동안 들어가는 인건비가 2억 4천만원이라고효?!
그래도 마케팅 1억원 더해서 6억 4천만원으로 어떻게든 총 비용 종결이 되려는 순간...
"근데효 싸장님하... 아무래도 런칭 할 수준은 아니예효. 오베는 한 12월 정도에... 그리고 개발자가 한 10명 정도 더 필요할 것 같거등효?"
...
다음해 7월 : 30명 6,000만원 (누적 60,000만원)
다음해 8월 : 30명 6,000만원 (누적 66,000만원)
다음해 9월 : 30명 6,000만원 (누적 72,000만원)
다음해 10월 : 30명 6,000만원 (누적 78,000만원)
다음해 11월 : 30명 6,000만원 (누적 84,000만원)
다음해 12월 : 30명 6,000만원 (누적 90,000만원)
다음해 8월 : 30명 6,000만원 (누적 66,000만원)
다음해 9월 : 30명 6,000만원 (누적 72,000만원)
다음해 10월 : 30명 6,000만원 (누적 78,000만원)
다음해 11월 : 30명 6,000만원 (누적 84,000만원)
다음해 12월 : 30명 6,000만원 (누적 90,000만원)
헥헥... 6개월 더 연장했더니, 그 사이에 3억 6천만원이 또 나갔네효. 지금까지의 누적은 9억원! 그나마 다행으로 12월에 오베 런칭할 수 있다면... 마케팅비 1억원. 총 비용은 10억원~ ㄳ
...
...
...
불쌍한 우리 싸장님 ㅠㅠ
만약 이 프로젝트가 첫해 12월에 성공적으로 런칭했다면 마케팅 합쳐서 총 비용은 4억원이었을 텐데... 1년을 연장 했더니만 런칭까지의 총 비용이 10억원! 기간은 2배인데 드는 돈은 2.5배야!!!
만약 당신이 '음하하하 더러운 개발자 색휘들한테 생흡 빨대 꽂아서 착취하면 1년에 넉넉잡아 5억으로 게임 하나 만들 수 있겠군하~ 여유자금도 1억이나 되니 충분하겠지! 우왕ㅋ굳ㅋ'이라고 생각했던 싸장님이라면...
개발 기간의 6개월 연장을 요청받는 시점에서... 예상되는 총 비용 6억 4천만원으로, 원래 가진 돈 5억원에서 1억 4천만원 오버합니다.
1. 빚이라도 지고 개발 고고싱?
2. "조까! 죽이 되든 밥이 되든 일단 지금 런칭해!"를 선택하시겠슴미까?
2. "조까! 죽이 되든 밥이 되든 일단 지금 런칭해!"를 선택하시겠슴미까?
1번을 선택하셨슴미다만... 6개월 더 필요하데효. 개발자도 더 늘려달라는 군효. 예상 총 비용은 10억원으로... 5억원 다 썼고, 빚이 1억 4천만원인데... 이제 3억 6천만원의 빚을 더 져야만 가능하겠군효?
1. 신체포기각서 쓰고 개발 고고싱?
2. "ㅆㅂ 더는 못해! 지금 런칭해!"를 선택하시겠슴미까?
2. "ㅆㅂ 더는 못해! 지금 런칭해!"를 선택하시겠슴미까?
1번을 선택하시는 훌륭한 분들도 계시겠지만... 정신줄 놓지 않은 이상 상식적으로는 2번이 맞을 것 같다. 어라? 잠깐? 2번이라고?
게임이 오베 수준의 완성도를 갖추지 못했음에도 불구하고 런칭을 선택한다고?!
... 네 그렇슴미다 ㄳ
즉 정리하자면 다음과 같다.
1. 개발 후반부로 갈수록 고정 지출 비용은 점점 더 증가한다.
2. 그런데 오베같은건 개발 후반부에나 하는거다.
3. 그러므로 오베를 늦추면 늦출수록 총 비용은 기하급수적으로 증가한다.
2. 그런데 오베같은건 개발 후반부에나 하는거다.
3. 그러므로 오베를 늦추면 늦출수록 총 비용은 기하급수적으로 증가한다.
어찌하리오. 감당이 안되면 죽이 되든 밥이 되든 런칭할 수밖에 없어효. 망하는 결과가 같더라도 최소한 신체포기각서는 안써도 되니까 ㄱ-
자금이 충분하다면?! 싸장님하가 처음부터 한 100억 들고 시작했다면?
... 그 경우에는 신체포기각서를 쓸 일은 없겠지만서도, 개발 기간을 1년 연장하는 것으로 애초에 예정되었던 개발 비용 4억원에 추가적으로 6억원이 더해져 총 개발 비용은 10억원이 되어버린다. 개발 기간 1년 연장이 과연 6억원을 초과하는 수익을 보장해 줄 수 있을 것인가?!
보장 못 해준다면... 적자임미다. 어라 잠깐! 우리 돈 벌려고 게임 만드는 건데 적자라고?!
이 뭐... 개발이 뒤로 가면 갈 수록 이러지도 저러지도 못하는 상황이 벌어지는 것이다. 게임이 성공한다는 확신만 있다면야, 적자를 보지 않을 수 있다는 확신만 있다면야 거리낌없이 돈을 붓겠지만... 글쎄 세상에 그거 확신할 수 있는 사람은 아무도 없다니까효.
...이미 쏟아부은 돈은 한가득.
...... 게임이 수익을 내기 전에는 회수할 가능성 없음.
......... 하지만 수익을 내려면 런칭을 해야하고, 런칭을 하려면 앞으로 점점 더 많은 비용을 지출해야 함.
............ 런칭하면 반드시 수익을 낼 수 있을 것인가? 그런 보장은 없음.
ㅎㄷㄷ... 이거 어디선가 많이 본 듯한 상황이지 않은가?

히든만을 남겨놓은 상황. 체크나 콜은 없다. 레이즈는 올인을 의미한다. 혹은 여기서 드랍할 것인가?
물론 이 외에도 수많은 요인이 존재하지만서도... 외부인도 손쉽게 계산해볼 수 있는 산수의 결과만 가지고도 이 정도이다. 그래서 결국 우리는 종종... 분노의 일갈을 지르게 되는 것. 하지만 어찌하리오? 저 쪽도 바보라서 그러는 것은 아닌 것이다.
그래서? 우리는 계속 분노의 일갈을 지를 수밖에 없는 것인가?! 아니면 싸장니마의 불쌍한 사정을 알았으니 걍 닥치고 있으면 되는 건가효?
그래서는 곤란하다. 문제는 해결되지 않는다.
그래서 이것을 해결하기 위한 다양한 방법들이 제시되고 있으니...
1. 개발자들을 더욱 착취한다.
아 예 한달에 200만원 너무 많군효. 한달에 100만원! 아 100만원씩 줄 돈도 없으면? 월급 체불! 우왕ㅋ굳ㅋ ... 너도나도 채택하고 있는 방법이었으나 덕분에 어떤 부작용이 생겨버렸는지는 더 말하지 않겠음 ㅆㅂ
2. 개발자들의 생산성을 극대화할 수 있는 방안을 모색한다.
아니 ㅆㅂ 야근 & 휴일 근무 의무화같은건 말고! 혹시 복지라고 들어나 보셨나효?
3. 개발 프로세스를 정비하여, 개발 기간 1년 연장과 같은 재앙을 막는다.
애자일을 비롯한 여러가지 개발 방법론, 프로세스 관리에 대한 아티클, 서적 등등... 다양한 시도들은 계속 된다. 그런 연구와 시도를 괜히 하는게 아닌거다 -_-
하지만 솔직히 이걸 아무리 잘해도 1.2~1.5배 정도의 기간 연장은 어쩔 수 없는 듯 흑흑흑
하지만 솔직히 이걸 아무리 잘해도 1.2~1.5배 정도의 기간 연장은 어쩔 수 없는 듯 흑흑흑
4. 비용이 적게 드는 개발 초기 단계 - 프리 프로덕션 단계의 기간을 늘리고, 그만큼 그 기간에 게임의 프로토타이핑을 철저히 시행하여 검증한다.
사실 1번은 이제서야 그나마 쇠퇴하고 있는 패러다임이고, 2번과 3번에 대한 시도가 나름 활발하게 이루어지고 있는 듯 싶다. 하지만 우리가 진정 나아가야 할 길은... 일단 새싹을 키워보고 안될 성 싶은 나무는 새싹부터 잘라버리는 것이 아닐까?!
나는 이 방향으로 나아가는 것이 맞고, 그렇게 나아갈 수밖에 없다고 생각한다. 이에 대한 연구와 시도와 실험도 점점 더 활발해져야 할 듯 싶고... 뭐 내가 아직 잘 모르는 영역에서는 진행되고 있겠지.
N모사의 허들 제도같은 것이 잘 쓴다면 이런 방향성을 충족시킬 수 있지 않을까? (물론 '잘' 쓴다면)
나는 이 방향으로 나아가는 것이 맞고, 그렇게 나아갈 수밖에 없다고 생각한다. 이에 대한 연구와 시도와 실험도 점점 더 활발해져야 할 듯 싶고... 뭐 내가 아직 잘 모르는 영역에서는 진행되고 있겠지.
N모사의 허들 제도같은 것이 잘 쓴다면 이런 방향성을 충족시킬 수 있지 않을까? (물론 '잘' 쓴다면)
5. 일본을 공격한다.
우왕ㅋ굳ㅋ
아직은... 요만큼 밖에 보이지 않는다. 아는 사람이 보기엔 이뭐병 수준의 분석일 듯 ㅋㅋㅋ
더구나 다음과 같은 문제들에 대해서는 아직 답을 모르겠다.
"될 성 싶은 나무와 안될 성 싶은 나무는 어떻게 구별하나효? 그 기준을 과연 세울 수 있을까효?"
"그래서 새싹을 자르면 그 개발자들은? 같이 자르는 건가효? 아무리 게임계가 그나마 그래스호핑이 자유로운 곳이라고는 해도... 글쎄효. 한국 사회에서는 좀 안맞을 텐데효?"
뭐 시간이 지나면 더 보이고, 대답이 명확해질 것 같기는 한데...
하지만 역시 말이졈 -_- 말단 개발자에게 이런 경영스러븐(?) 고민을 하게 만드는 사회는 뭔가 잘못되어 있는 것 같지 않나효?!
|
Trackback Address :: http://glekang.com/trackback/297
|
[글강, 2007/05/31 14:43, Game]
삼성, LG 등의 쟁쟁한 대기업들이 꽉 틀어쥐고 있는 백색 가전 시장에 진출을 꿈꾸는 한 중소 기업이 있다고 치자. 헌데 이 중소 기업이 제품을 개발하고 출시하는 마인드가 좀 해괴하다.
자... 이 중소 기업의 미래는 어떻게 될까요?
'그래도 운이 좋으면 살아남아 대박치지 않을까?'라는 미칠듯이 긍정적인 자세로 얄팍한 희망을 피력하는 분... 네 좋습니다. 이번주에 꼭 로또를 긁으세효.
까놓고 말해 저건 누가 보더라도 미친 짓이다. 한번 거하게 망해 보려고 억지 발버둥을 치지 않는 이상, 저런 마인드를 가지기도 힘들 것이다.
뭐 이 쯤 되면 '니마 미쳤3?'이나 '니마 그러다가 망해효'같은 이야기를 하는 것도 과분하다. 그냥 엄지를 곧추세우며 외쳐보자.
"대인배시군요! -_-)=b"
하지만 슬프게도... 저기서 백색 가전을 MMORPG로 바꾸고 나면, 저런 대인배가 무려... 졸라 많지효.
수도 없이 고꾸라진다 할지라도, 대인배의 시체를 넘고 넘어 오늘도 대인배는 전진... 아니 제자리 걸음을 계속하지효.
대인배들은 소를 수백억 단위로 잃는다 해도 절대 외양간을 고치지 않아효.
사람들이 빅3에서 배운 점이 하나도 없다는 것이 참 기기묘묘하근염.
님드라, 님들이 상대해야 하는 것은 개발 및 서비스 기간이 10년 가까이, 혹은 넘도록 누적된 리니지, WoW거등효. 그 게임들하고 정면 격돌해야 하거든효.
그 사실 알고 계신건가요? 진짜? 정말로?
시장을 선점한 쟁쟁한 제품들을 뛰어넘는 품질을 만들어낼 생각이 없다. 아니, '생각은 있는데 자금과 인력이 부족해서 그만한 경쟁력을 갖출 수가 없다'라고 이야기한다. 하지만 그럼에도 불구하고 이들이 개발하는 제품의 타겟 시장에서는 대기업 제품과의 정면 격돌이 예상된다. 틈새 시장 뭐 그런건 없는거다!
역시나 '자금과 인력이 부족해서' 개발된 제품을 제대로 테스트하지도 않고, 오히려 몇몇 기능은 누락된상태로 출시한다. 오만가지 클레임이 들어오는 것이 당연한데... A/S와 심지어는 전면 리콜을 통해 이를 극복하겠다는 대안(?)을 세우고 있다.
역시나 '자금과 인력이 부족해서' 개발된 제품을 제대로 테스트하지도 않고, 오히려 몇몇 기능은 누락된상태로 출시한다. 오만가지 클레임이 들어오는 것이 당연한데... A/S와 심지어는 전면 리콜을 통해 이를 극복하겠다는 대안(?)을 세우고 있다.
자... 이 중소 기업의 미래는 어떻게 될까요?
'그래도 운이 좋으면 살아남아 대박치지 않을까?'라는 미칠듯이 긍정적인 자세로 얄팍한 희망을 피력하는 분... 네 좋습니다. 이번주에 꼭 로또를 긁으세효.
까놓고 말해 저건 누가 보더라도 미친 짓이다. 한번 거하게 망해 보려고 억지 발버둥을 치지 않는 이상, 저런 마인드를 가지기도 힘들 것이다.
뭐 이 쯤 되면 '니마 미쳤3?'이나 '니마 그러다가 망해효'같은 이야기를 하는 것도 과분하다. 그냥 엄지를 곧추세우며 외쳐보자.
"대인배시군요! -_-)=b"
하지만 슬프게도... 저기서 백색 가전을 MMORPG로 바꾸고 나면, 저런 대인배가 무려... 졸라 많지효.
수도 없이 고꾸라진다 할지라도, 대인배의 시체를 넘고 넘어 오늘도 대인배는 전진... 아니 제자리 걸음을 계속하지효.
대인배들은 소를 수백억 단위로 잃는다 해도 절대 외양간을 고치지 않아효.
사람들이 빅3에서 배운 점이 하나도 없다는 것이 참 기기묘묘하근염.
님드라, 님들이 상대해야 하는 것은 개발 및 서비스 기간이 10년 가까이, 혹은 넘도록 누적된 리니지, WoW거등효. 그 게임들하고 정면 격돌해야 하거든효.
그 사실 알고 계신건가요? 진짜? 정말로?
|
Trackback Address :: http://glekang.com/trackback/290
|
[글강, 2007/05/07 14:24, Game]
얼마 전에 워해머 온라인WarHammer Online이 출시를 2008년 상반기로 미룬다는 뉴스가 발표된 바 있다.
히밤. 레이드 게임이 되어버린 WoW를 외면한지 어언 2년이 가까우니, 그저 워함마만 아기다리 고기다리던 나로서는 '금년은 또 뭐로 떼우라고!'라는 비명을 올리기 딱 좋은 뉴스였는데 ㄱ-
(그래서 결국 다시 WoW에 손을 대버렸음 -_-a 1년 반만에 다시 하려니 진짜 적응 안되네)
저 뉴스를 처음 접했을 때 내가 생각했던 바는 다음과 같다.
그러나 이러한 내 생각에 대한 반론이 하나.
어머나?
돌이켜 생각해보니, 1년의 연기에 대해서 나는 철저히 국내식(?)으로만 추측하고 있었다.
실제로 나는 무려 OBT 직전까지 신규 시스템을 구축하고 있었고, OBT 이후에도 기반 시스템의 개발을 계속했었기 때문에... 1년의 연장은 당연히 개발의 연장이라 생각해버린 것이다.
거기에 손쉽게 빠지기 쉬운 EA 음모론까지 덧붙여서는 자위하며 납득. 쯥. 이런걸 두고 생각이 짧다고 한다 ㅋㅋㅋ
물론 내부적인 사정까지 알 수는 없는 노릇이기에, 정말 내 예상이 맞은 것일 수도 있고, 정말 QA를 1년 정도 더 하려는 것일 수도 있다.
하지만 공식 사이트에 올라온 공지로 미루어 보건데, 아무래도 QA 쪽이 맞는 듯.
... 이라고 할 때, 다시금 떠오른 의문은 다음과 같다.
최소한 내가 아는 한도 내에서는 암울.
... 라는 고전적인 화두에 대하여 여러 성현들이 남긴 가르침은 다음과 같나니,
한줄 요약.
물론 이것은 막연한 동경일 수도 있다. EA Human Story같은 것을 보고 있자면... 그 동네나 우리 동네나 마찬가지로 막장일지도.
하지만 아무리 막장이라 할지라도 외국과 국내의 개발 프로세스에는 크나큰 차이가 존재하나니... QA의 위상이 바로 그것이다.
... 여기까지는 만국 공통.
... 국내에서는 예외가 생길 수도 있지만 -_-a 그건 말장난일 뿐이고, 기획자 없는 개발 프로세스는 없다. 즉 공통.
... 이게 가장 큰 차이이다. 국내에서는? QA 없이 게임을 만드려 드는 개발사가 조낸 많다.
외국에서는 아주 당연한 필수 요소로 인식되고 있는 QA가 유독 한국에서는, '없어도 되는거'라는 인식을 받고 있는 것이다.
... 라는 반론이 당연하다는 듯이 제기되곤 하지만, 다시 생각해 보면 그 반론의 밑바탕에도 'QA는 없어도 되는거'라는 인식이 깔려 있다.
디버깅 없이 프로그램을 출시하는 개발사는 존재하지 않는다. 즉 디버깅 버퍼는 개발 일정에 당연하다는 듯이 포함된다. 디버깅을 '없어도 되는거'라고 생각하는 경우가 과연 있을까?
하지만 게임 자체에 대한 디버깅은...? 그것이 바로 QA일진데... 해괴망칙하게도 국내에서는 자금과 일정이 압박하면 QA 기간을 날려버리고 바로 출시를 해버리곤 한다. '없어도 되는거'가 아닌 이상에야, 필수 요소라면 과연 이렇게 쉽게 날려버릴 수 있을까?
... 묵념.
어째서 애초에 개발 일정에 QA를 포함시키지 않은 것인가?
개발 초기에 6개월을 산정한다고 할 때, 그 6개월 내에 왜 QA 기간을 포함시키지 않은 것인가?
WoW는 5년의 개발 기간에서, 3년을 개발에 투자하고 2년을 QA 및 각종 수정에 투자했다. 즉 전체 개발 일정의 40%가 QA에 할당된 것이다. 하지만 어째서 우리는 기껏 할당해봐야 1%, 그나마도 그걸 0%로 못만들어 안달인 것인가?
여기에서 국내와 국외의 가장 큰 차이가 벌어진다고 생각한다. 만드는건 똑같이 잘 만들어 놓고는... 마지막에 다듬는 기간 - 그 기간이 2/5에 육박하니 '마지막'이라 하기엔 좀 애매하지만 - 을 넣고 안넣는 것에서 최종 결과물의 퀄리티 수준이 달라지게 되어버리는 것이다.
... 라는 생각이 머리 속을 스치신다면. 그럼 프로젝트 런칭하지 마시길.
QA 없이 성공하는 게임도 물론 있다. 세상에는 예외가 있게 마련이니. 하지만 절대 다수의 게임들은 패망하는 법이고, 피튀기는 블러드 오션 속에서 앞으로는 점점 더 힘들어져 가게 된다. QA없는 성공은 로또가 된다.
수십명이 수년간 동원되어 로또에 기대느니... 차라리 처음부터 프로젝트를 런칭하지 않는 쪽이 더 낫다고 생각한다. 이 쪽이 수십억을 퍼붓는 입장으로서도 생 돈 날리지 않게 되는 길이지 않을까?
... 라고 하신다면, 우리 솔직해 보아효. 우리나라에 CBT가 어디있나효?
우리나라의 CBT는 사실상 OBT다. OBT는? 무료 서비스. 그리고 상용화가 바로 유료 서비스.
CBT가 실종되어 버렸다는 것은 누구나 알고 있는 사실이지 않은가? 즉 CBT 후의 QA라는건 OBT 후에 QA 하겠다는 것과 마찬가지이다. 그 결과는? 당연히 로또.
외국 게임을 플레이 하면서 종종 Credit을 보곤 한다. 그 때마다 '어엄 부러워라'라는 생각이 드는 것은 QA의 이름을 달고 수페이지의 이름들이 주르륵 올라갈 때... 국내의 개발력과 국외의 개발력 차이는 바로 이 한 끗 차이에서 비롯되는 것이 아닐까.
혹은 이 역시도 막연한 동경일지도...?
어디 이 동경을 무참히 깨주실 해외 개발사에 재직중이신 분 없으신가효 ;ㅁ;
어찌되었든... 결론은 워함마 온라인이 내년에 나온다능거. 흑흑.
그린스킨이냐 카오스냐! 고민의 시간도 길어지겠군하. 아 제국이나 드워프 따위는 애초에 고려도 아니하고 있으니 즐. ㄲㄲㄲ
히밤. 레이드 게임이 되어버린 WoW를 외면한지 어언 2년이 가까우니, 그저 워함마만 아기다리 고기다리던 나로서는 '금년은 또 뭐로 떼우라고!'라는 비명을 올리기 딱 좋은 뉴스였는데 ㄱ-
(그래서 결국 다시 WoW에 손을 대버렸음 -_-a 1년 반만에 다시 하려니 진짜 적응 안되네)
저 뉴스를 처음 접했을 때 내가 생각했던 바는 다음과 같다.
'아 EA가 Mythic을 먹고, 개발팀을 UO:Kingdom Reborn으로 쪼개더니만 결국... 개발 인력이 딸려서 워함마의 출시가 늦어져 버렸군하. Eat All 개객기들!'
그러나 이러한 내 생각에 대한 반론이 하나.
'QA가 아직 덜 된 모양이군효. 한 1년쯤 더 QA를 하고 출시하려는 듯?'
어머나?
돌이켜 생각해보니, 1년의 연기에 대해서 나는 철저히 국내식(?)으로만 추측하고 있었다.
실제로 나는 무려 OBT 직전까지 신규 시스템을 구축하고 있었고, OBT 이후에도 기반 시스템의 개발을 계속했었기 때문에... 1년의 연장은 당연히 개발의 연장이라 생각해버린 것이다.
거기에 손쉽게 빠지기 쉬운 EA 음모론까지 덧붙여서는 자위하며 납득. 쯥. 이런걸 두고 생각이 짧다고 한다 ㅋㅋㅋ
물론 내부적인 사정까지 알 수는 없는 노릇이기에, 정말 내 예상이 맞은 것일 수도 있고, 정말 QA를 1년 정도 더 하려는 것일 수도 있다.
하지만 공식 사이트에 올라온 공지로 미루어 보건데, 아무래도 QA 쪽이 맞는 듯.
... 이라고 할 때, 다시금 떠오른 의문은 다음과 같다.
'게임 거의 다 만들어놓고 1년간 QA를 하겠다고 할 때, 이를 용납하는 스튜디오가 국내에도 있을까?'
최소한 내가 아는 한도 내에서는 암울.
외국은 저렇게 게임을 잘 만드는데 왜 우리나라 게임들은 한결같이 좆병진인가효?
... 라는 고전적인 화두에 대하여 여러 성현들이 남긴 가르침은 다음과 같나니,
외국 게임 시장은 규모가 커서 2%의 매니아만을 위한 게임을 만들어도, 그 2%가 개발사 서넛은 족히 먹여 살릴만한 풀pool을 형성하노라. 징징대고 있는 너희들이 바로 '한국에서의 2%'에 해당하지만, 한국의 2%는 개발사 하나도 먹여살리지 못하나니.
외국 개발사가 게임 하나에 쏟아붓는 자금과 인력은 국내의 몇 배를 가볍게 넘노라. WoW는 500억의 자금으로 5년의 기간 동안 수많은 개발 인력이 투입되어 개발되었나니, 시나리오 라이터만 30명에 이르더라. 한국에서는 더도 말고 덜도 말고 그 1/5 수준으로 투입되기만 하면 다행이되, 인력은 1/10도 채 아니되나니.
외국 개발사가 게임 하나에 쏟아붓는 자금과 인력은 국내의 몇 배를 가볍게 넘노라. WoW는 500억의 자금으로 5년의 기간 동안 수많은 개발 인력이 투입되어 개발되었나니, 시나리오 라이터만 30명에 이르더라. 한국에서는 더도 말고 덜도 말고 그 1/5 수준으로 투입되기만 하면 다행이되, 인력은 1/10도 채 아니되나니.
한줄 요약.
외국은 개발 환경과 시장 환경이 천국이고, 국내는 개발 환경과 시장 환경이 지옥임미다. 끗.
물론 이것은 막연한 동경일 수도 있다. EA Human Story같은 것을 보고 있자면... 그 동네나 우리 동네나 마찬가지로 막장일지도.
하지만 아무리 막장이라 할지라도 외국과 국내의 개발 프로세스에는 크나큰 차이가 존재하나니... QA의 위상이 바로 그것이다.
프로그래머 없이 게임을 만드려 드는 개발사는 존재하지 않는다.
그래픽 디자이너 없이 게임을 만드려 드는 개발사는 존재하지 않는다.
그래픽 디자이너 없이 게임을 만드려 드는 개발사는 존재하지 않는다.
... 여기까지는 만국 공통.
게임 디자이너(기획자) 없이 게임을 만드려 드는 개발사는 존재하지 않는다.
... 국내에서는 예외가 생길 수도 있지만 -_-a 그건 말장난일 뿐이고, 기획자 없는 개발 프로세스는 없다. 즉 공통.
QA 없이 게임을 만드려 드는 개발사는 존재하지 않는다. 외국에만.
... 이게 가장 큰 차이이다. 국내에서는? QA 없이 게임을 만드려 드는 개발사가 조낸 많다.
외국에서는 아주 당연한 필수 요소로 인식되고 있는 QA가 유독 한국에서는, '없어도 되는거'라는 인식을 받고 있는 것이다.
'히밤. QA하면 좋은거 누가 모르나효. 하지만 자금과 시간이 압박하는데 어쩌나효.'
... 라는 반론이 당연하다는 듯이 제기되곤 하지만, 다시 생각해 보면 그 반론의 밑바탕에도 'QA는 없어도 되는거'라는 인식이 깔려 있다.
디버깅 없이 프로그램을 출시하는 개발사는 존재하지 않는다. 즉 디버깅 버퍼는 개발 일정에 당연하다는 듯이 포함된다. 디버깅을 '없어도 되는거'라고 생각하는 경우가 과연 있을까?
하지만 게임 자체에 대한 디버깅은...? 그것이 바로 QA일진데... 해괴망칙하게도 국내에서는 자금과 일정이 압박하면 QA 기간을 날려버리고 바로 출시를 해버리곤 한다. '없어도 되는거'가 아닌 이상에야, 필수 요소라면 과연 이렇게 쉽게 날려버릴 수 있을까?
... 묵념.
어째서 애초에 개발 일정에 QA를 포함시키지 않은 것인가?
개발 초기에 6개월을 산정한다고 할 때, 그 6개월 내에 왜 QA 기간을 포함시키지 않은 것인가?
WoW는 5년의 개발 기간에서, 3년을 개발에 투자하고 2년을 QA 및 각종 수정에 투자했다. 즉 전체 개발 일정의 40%가 QA에 할당된 것이다. 하지만 어째서 우리는 기껏 할당해봐야 1%, 그나마도 그걸 0%로 못만들어 안달인 것인가?
여기에서 국내와 국외의 가장 큰 차이가 벌어진다고 생각한다. 만드는건 똑같이 잘 만들어 놓고는... 마지막에 다듬는 기간 - 그 기간이 2/5에 육박하니 '마지막'이라 하기엔 좀 애매하지만 - 을 넣고 안넣는 것에서 최종 결과물의 퀄리티 수준이 달라지게 되어버리는 것이다.
'히밤. 그럼 개발 기간을 6개월로 산정한다고 할때, QA에 2개월을 할당할 생각을 하고 8개월로 잡아야 하나효? 8개월이나 개발할 자금은 없는데효?'
... 라는 생각이 머리 속을 스치신다면. 그럼 프로젝트 런칭하지 마시길.
QA 없이 성공하는 게임도 물론 있다. 세상에는 예외가 있게 마련이니. 하지만 절대 다수의 게임들은 패망하는 법이고, 피튀기는 블러드 오션 속에서 앞으로는 점점 더 힘들어져 가게 된다. QA없는 성공은 로또가 된다.
수십명이 수년간 동원되어 로또에 기대느니... 차라리 처음부터 프로젝트를 런칭하지 않는 쪽이 더 낫다고 생각한다. 이 쪽이 수십억을 퍼붓는 입장으로서도 생 돈 날리지 않게 되는 길이지 않을까?
'QA는 일단 CBT 런칭한 다음에 하면 되지 않을까효?'
... 라고 하신다면, 우리 솔직해 보아효. 우리나라에 CBT가 어디있나효?
우리나라의 CBT는 사실상 OBT다. OBT는? 무료 서비스. 그리고 상용화가 바로 유료 서비스.
CBT가 실종되어 버렸다는 것은 누구나 알고 있는 사실이지 않은가? 즉 CBT 후의 QA라는건 OBT 후에 QA 하겠다는 것과 마찬가지이다. 그 결과는? 당연히 로또.
외국 게임을 플레이 하면서 종종 Credit을 보곤 한다. 그 때마다 '어엄 부러워라'라는 생각이 드는 것은 QA의 이름을 달고 수페이지의 이름들이 주르륵 올라갈 때... 국내의 개발력과 국외의 개발력 차이는 바로 이 한 끗 차이에서 비롯되는 것이 아닐까.
혹은 이 역시도 막연한 동경일지도...?
어디 이 동경을 무참히 깨주실 해외 개발사에 재직중이신 분 없으신가효 ;ㅁ;
어찌되었든... 결론은 워함마 온라인이 내년에 나온다능거. 흑흑.
그린스킨이냐 카오스냐! 고민의 시간도 길어지겠군하. 아 제국이나 드워프 따위는 애초에 고려도 아니하고 있으니 즐. ㄲㄲㄲ
|
Trackback Address :: http://glekang.com/trackback/285
|
[글강, 2007/04/30 19:07, Game]
로직과 스키마라는 분류를 통해 우리는 여러가지를 설명해 볼 수 있다.
전반적인 개발 프로세스에서부터, 단일 스펙의 설계에 이르기까지. MMORPG에서부터 단순한 슈팅 게임에 이르기까지. 로직과 스키마의 문제는 규모와 장르에 구애받지 않고 개발 전반부에 걸쳐있기 때문이다.
(물론 그렇다고 해서 모든 것이 설명되지는 않는다 -_-a 세상이 그리 단순한 것이 아니라서리... 쯥 ; 예를 들어 틱택톡같은 퍼즐 게임의 경우... 이건 뭐 스키마가 가지는 비중은 거의 없다시피 하고 -.-; 로직만으로 모든 생각을 진행하게 된다)
아무튼 설명이 되는 것 중에서... 로직과 스키마 연작 포스트의 마지막으로, 간단한 기획 프로세스를 한번 들여다 보도록 하자.
이전 포스트 말미에서 언급한 바와 같이, 인간은 로직보다는 스키마에 먼저 꽂히는 동물이다.
새로운 게임이 출시되었을 때, 그 게임의 스펙이나 시스템을 먼저 보게 되는가? 아니면 스크린샷이나 플레이 영상을 먼저 보게 되는가?
나는 스펙이나 시스템을 먼저 보는데... 라고 한다면 이런 게임 오탁후 저리갓 쉭쉭! (이라 해놓고는 나도 스펙을 먼저 보지만 흠흠)
일반적으로는 스크린샷을 먼저 보게 마련이다. 즉 스키마에 먼저 꽂힌다.
새로운 게임을 기획할 때에는...?
머리 속으로 로직을 먼저 구상할까? 완전히 추상적인 차원에서 A와 B가 머리 속을 휭휭 날아다니며 게임의 규칙을 형성한다...? 퍼즐을 만드는게 아닌 이상에야 -_-a 이런 경우는 매우매우 드물 것으로 예상한다.
인간이란 원래 그런 식으로 생각하게끔 되어 있는 생물이 아닐 터.
최소한 나는 그런 식으로 생각하지 않는다. 나 역시 스키마에 먼저 꽂힌다.
새로운 게임을 기획할 때에도, 그 게임의 로직을 먼저 떠올리는 것이 아니라 스키마에 먼저 로망을 불태우나니...
거기에서부터 시작하여 스키마 -> 로직 -> 스키마를 순환하는, 다음과 같은 게임 기획 프로세스가 정립된다.
(뭐 이게 정답은 아니라는 점에는 다시금 유의를...)
*** 이 예시는... 2004년 성게님의 [마린블루스]를 둘러보다가 문득 떠오른 착상을 기반으로 하여, 한 30분 만에 뚝딱 대충 구상해봤던 게임이다.
구체적인 게임 기획이 이루어진 것은 아니고, 내 안에서 스키마 -> 로직 -> 스키마가 어떻게 순환하며 하나의 게임이 상을 갖추어 나가게 되었는지에 대한 예시일 뿐이니까리 '졸라 재미없겠는데?' 뭐 이런 태클은 정중히 사양 ( '') ***
1. 스키마에 꽂히다
게임 기획자는 일과 생활을 분리하기가 참 애매한 직업이다. 일상 속에서 게임을 플레이하든, 영화를 보든, 만화를 보든, 음악을 듣든... 그 모든 것을 게임 기획으로 연결하여 생각하게 되는 것이 기획자라는 생물. 그러기 싫어도 자연스럽게 그렇게 된다 ;ㅁ; (그래서 개발자가 되면 더 이상 순수하게 게임을 즐길 수 없게 된다는 이야기가 나오는 것이다 흑흑)
게임이 게임 기획으로 연결되는 부분에 대해서는 예전에 찌질거려 놓은 글을 참고할 수 있을테고, 그 외에도 영화를 보다 보면 '우오 3만마리의 오크떼와 돌격하는 기병들! 저 로망을 게임으로 만든다면... 블라블라'같은 생각이, 만화를 보다 보면 '역시 우주를 가로짓는 로망은 총알보다는 무수한 빔이라니까! 이걸 게임으로 만든다면... 블라블라', 혹은 음악? '둥둥둥~ 그래 이런 음악을 BGM으로 깔고 고딕 양식의 웅장한 성들이 좌악 펼쳐지는 공성전이... 블라블라'
뭐 대충 이런 식이랄까?
새로운 게임을 만들어내는 착상은, 로직보다는 스키마에서 먼저 시작되는 것이 일반적이다. 다른 어떤 문화 매체를 통해서든 자극을 받았을 때, 그 자극을 그대로 계승하는 게임의 상이 번뜩 떠오르게 되는 것이다.
그리고 내가 2004년에 꽂혔던 스키마는 다음의 만화에서 비롯되었다.
이 만화를 봤을 때 내 머리 속에 꽂힌 스키마는 다음과 같다.
물론 이것은 나의 경우이다. 저 만화를 보고 아무런 꽂힘이 없을 수도 있고, 나와는 다른 스키마가 떠오를 수도 있다.
이전 포스트에서도 언급했던 바와 같이, 스키마에는 정답이 없고 철저하게 주관적인 것이니까. 아무튼 나는 저런 스키마가 꽂혔고, 거기에서 착상을 얻었다.
새로운 게임의 기획이 스키마에서부터 시작되었다.
2. 기본 규칙의 선택
그럼 이제 '도시를 파괴하는 개구리 괴수'라는 스키마를 풀어낼 수 있는 게임의 기본적인 규칙을 선택해 볼 단계이다.
기본 규칙의... '선택'이라는 점에 유의. 아직은 로직이 끼어들 단계가 아니고, 스키마를 발현시킬 수 있는 다양한 병렬적 방법론 중에서 가장 효과적인 표현이 가능할 수 있을 것이라 생각되는 규칙을 '주관적으로' 선택하는 것이다.
따라서 스키마에 정답이 없듯, 이 선택에도 정답은 없다. 소위 꼴리는 대로... 랄까.
그래서 내가 선택했던 기본 규칙은 다음과 같았다.
기본 규칙을 선택하는 단계에서는 아직 스키마가 끼어들 여지가 충분히 존재한다. 게임의 기본 규칙이란 결국 머리 속에 꽂혀 있는 스키마의 상을 게임이라는 형태로 풀어놓는 것이기 때문이다.
하지만 이러한 기본 규칙까지 정립한 후에는... 이제 스키마를 버려야 하는 단계가 온다.
3. 로직의 구축
개구리 괴수에 꽂히는 것으로부터 시작하여, 그 상을 게임으로 풀어낸 기본 규칙을 정립하였으니, 이제는 구체적으로 게임의 로직을 고민할 때이다.
이 단계에서는 개구리 괴수의 상을 철저하게 배제하고, 최대한 머리 속을 dry하게 만들어야만 한다. 로직 구축의 단계에서 스키마가 끼어들면 어떤 대환란이 벌어지는지는 이전 포스트를 참고하시압. 즉 개구리 괴수의 상은 훠어이 훠어이 내다 버리고, 기본 규칙의 위에서만 로직을 구축해야 한다.
빌딩숲은 '판'으로 추상화한다. 개구리 괴수는 'PC'로 추상화한다. 그럼 결국... 다수의 늘어선 판 위를 1칸씩 이동하는 PC, 이 PC가 한번 올라선 판은 사라지며, 최종적으로 남은 판 위에 선 PC가 승리한다는 기본 규칙이 성립된다.
이 기본 위에 온라인 게임으로서 재미를 더하기 위한 온갖 로직을 더해보도록 하자. 다만 유의할 점은 덧붙이는 로직이 기본 규칙을 침해하면 안된다는 점.
... 기타 등등. 뭐 애초에 본격적으로 기획을 한 것은 아니고, 브레인스토밍을 가볍게 해 본 정도의 수준이었기 때문에 여기까지만. 예시는 예시일 뿐이다 ( '') 만약 실제로 게임을 만들게 된다면, 필요한 로직은 여기에 언급된 내용보다 100배 정도는 더 많이 필요하게 될 것이다.
주목해야 하는 것은 그런 점이 아니라... 추상화의 차원에서 로직이 구축된다는 부분. 각종 요소들을 최대한 dry하게 추상화하고, 이 상태에서 객체와 객체 사이의 관계에만 집중해야 한다는 것이 요점이다.
만약 여기에 엄하게 스키마를 끼워 넣어서 '개구리 괴수라면 빌딩에서 떨어질 때 혀를 쭈욱~ 내밀어 빌딩에 매달릴 수도 있지 않을까?' 뭐 이런 생각을 하면서 삼천포로 빠지기 시작하면... 끝이 나질 않게 되어 버린다. 대환란에 대한 언급은 따로 더 하지 않겠심.
자~ 스키마의 유혹(?)에서 벗어나 로직의 구축에 성공하였다면...?
그럼 이제 다시 스키마의 품으로 돌아갈 수 있게 된다.
4. 스키마로의 복귀
잊혀졌던 개구리 괴수가 다시 부활할 시간이 왔도다!!!
로직을 모두 구축하였다면, 이제야 비로소 그 위에 스키마의 외피를 입힐 수 있게 된다.
뭔가 삼천포로 많이 빠져버렸는데... 아무튼 구축된 로직에 스키마의 외피를 입혀보도록 하자.
... 기타 등등. 뭐 스키마는 아무래도 좋으니 내키는 대로... 라고는 하지만서도, 위에서 언급한 함정에는 유의할 것 ( '')
처음에 꽂힌 스키마가, 기본 규칙을 통해 게임화되고, 로직을 그 뼈대로 삼아, 이제 비로소 최종적인 스키마를 입고 하나의 게임이 기획되었다. (물론 제대로 기획하려면 여기 100배 정도는 추가 분량이...)
이것이 바로 '이런 게임이 있다면 재미있을텐데...'라고 대충 쉽게 망상하는 것과, 개발자가 게임을 구상하는 것의 차이. 뭐 되게 거만해 보일는지도 모르겠지만... 생각의 방법론이라 할 수 있다.
...
...
...
하지만 정작 만들어 놓고 보니... 으 눈치채셨슴미까? 어디서 되게 많이 본 듯한 게임이 나와버렸군효 ㄱ-
로직과 스키마 연작의 예고편 포스트를 기억하시는지? 프라모델의 제작에 대한 비유를 마지막으로 한번 더 해보자면 다음과 같다.
물론 이러한 스키마 -> 로직 -> 스키마의 순환 구조는 '내 방법론'이다. 이게 정답은 아닐거라는 점, 이보다 나은 방법론은 얼마든지 있을 수 있다는 점에 무조건 유의.
하지만 그래도 로직과 스키마를 고민하는 개발자에게 참고 정도는 되어줄 수 있을 거라고 생각한다.
여기까지... 로 해서리 되도 않는 뻘소리로 점철된 3연작 끗.
...
...
...
하지만 end가 아닌 and로?
이미 이전 포스트에서 댓글로 여러가지 이야기가 오간 것에서 알 수 있듯이... 이 개념은 완벽하지 않다.
더 많은 개발자들이, 더 치열한 고민을 통해, 더 세밀한 세분화를 통해 개념을 확장해 나아가고 발전시킬 수 있기를 :)
전반적인 개발 프로세스에서부터, 단일 스펙의 설계에 이르기까지. MMORPG에서부터 단순한 슈팅 게임에 이르기까지. 로직과 스키마의 문제는 규모와 장르에 구애받지 않고 개발 전반부에 걸쳐있기 때문이다.
(물론 그렇다고 해서 모든 것이 설명되지는 않는다 -_-a 세상이 그리 단순한 것이 아니라서리... 쯥 ; 예를 들어 틱택톡같은 퍼즐 게임의 경우... 이건 뭐 스키마가 가지는 비중은 거의 없다시피 하고 -.-; 로직만으로 모든 생각을 진행하게 된다)
아무튼 설명이 되는 것 중에서... 로직과 스키마 연작 포스트의 마지막으로, 간단한 기획 프로세스를 한번 들여다 보도록 하자.
이전 포스트 말미에서 언급한 바와 같이, 인간은 로직보다는 스키마에 먼저 꽂히는 동물이다.
새로운 게임이 출시되었을 때, 그 게임의 스펙이나 시스템을 먼저 보게 되는가? 아니면 스크린샷이나 플레이 영상을 먼저 보게 되는가?
나는 스펙이나 시스템을 먼저 보는데... 라고 한다면 이런 게임 오탁후 저리갓 쉭쉭! (이라 해놓고는 나도 스펙을 먼저 보지만 흠흠)
일반적으로는 스크린샷을 먼저 보게 마련이다. 즉 스키마에 먼저 꽂힌다.
새로운 게임을 기획할 때에는...?
머리 속으로 로직을 먼저 구상할까? 완전히 추상적인 차원에서 A와 B가 머리 속을 휭휭 날아다니며 게임의 규칙을 형성한다...? 퍼즐을 만드는게 아닌 이상에야 -_-a 이런 경우는 매우매우 드물 것으로 예상한다.
인간이란 원래 그런 식으로 생각하게끔 되어 있는 생물이 아닐 터.
최소한 나는 그런 식으로 생각하지 않는다. 나 역시 스키마에 먼저 꽂힌다.
새로운 게임을 기획할 때에도, 그 게임의 로직을 먼저 떠올리는 것이 아니라 스키마에 먼저 로망을 불태우나니...
거기에서부터 시작하여 스키마 -> 로직 -> 스키마를 순환하는, 다음과 같은 게임 기획 프로세스가 정립된다.
(뭐 이게 정답은 아니라는 점에는 다시금 유의를...)
*** 이 예시는... 2004년 성게님의 [마린블루스]를 둘러보다가 문득 떠오른 착상을 기반으로 하여, 한 30분 만에 뚝딱 대충 구상해봤던 게임이다.
구체적인 게임 기획이 이루어진 것은 아니고, 내 안에서 스키마 -> 로직 -> 스키마가 어떻게 순환하며 하나의 게임이 상을 갖추어 나가게 되었는지에 대한 예시일 뿐이니까리 '졸라 재미없겠는데?' 뭐 이런 태클은 정중히 사양 ( '') ***
1. 스키마에 꽂히다
게임 기획자는 일과 생활을 분리하기가 참 애매한 직업이다. 일상 속에서 게임을 플레이하든, 영화를 보든, 만화를 보든, 음악을 듣든... 그 모든 것을 게임 기획으로 연결하여 생각하게 되는 것이 기획자라는 생물. 그러기 싫어도 자연스럽게 그렇게 된다 ;ㅁ; (그래서 개발자가 되면 더 이상 순수하게 게임을 즐길 수 없게 된다는 이야기가 나오는 것이다 흑흑)
게임이 게임 기획으로 연결되는 부분에 대해서는 예전에 찌질거려 놓은 글을 참고할 수 있을테고, 그 외에도 영화를 보다 보면 '우오 3만마리의 오크떼와 돌격하는 기병들! 저 로망을 게임으로 만든다면... 블라블라'같은 생각이, 만화를 보다 보면 '역시 우주를 가로짓는 로망은 총알보다는 무수한 빔이라니까! 이걸 게임으로 만든다면... 블라블라', 혹은 음악? '둥둥둥~ 그래 이런 음악을 BGM으로 깔고 고딕 양식의 웅장한 성들이 좌악 펼쳐지는 공성전이... 블라블라'
뭐 대충 이런 식이랄까?
새로운 게임을 만들어내는 착상은, 로직보다는 스키마에서 먼저 시작되는 것이 일반적이다. 다른 어떤 문화 매체를 통해서든 자극을 받았을 때, 그 자극을 그대로 계승하는 게임의 상이 번뜩 떠오르게 되는 것이다.
그리고 내가 2004년에 꽂혔던 스키마는 다음의 만화에서 비롯되었다.
이 만화를 봤을 때 내 머리 속에 꽂힌 스키마는 다음과 같다.
- 개구리와 같이 건물 위와 건물 위를 폴짝폴짝 뛰어다니는 거대 괴수
- 그 괴수에 의해 파괴되는 도시, 무너지는 빌딩들, 아비규환
- 그 괴수에 의해 파괴되는 도시, 무너지는 빌딩들, 아비규환
물론 이것은 나의 경우이다. 저 만화를 보고 아무런 꽂힘이 없을 수도 있고, 나와는 다른 스키마가 떠오를 수도 있다.
이전 포스트에서도 언급했던 바와 같이, 스키마에는 정답이 없고 철저하게 주관적인 것이니까. 아무튼 나는 저런 스키마가 꽂혔고, 거기에서 착상을 얻었다.
새로운 게임의 기획이 스키마에서부터 시작되었다.
2. 기본 규칙의 선택
그럼 이제 '도시를 파괴하는 개구리 괴수'라는 스키마를 풀어낼 수 있는 게임의 기본적인 규칙을 선택해 볼 단계이다.
기본 규칙의... '선택'이라는 점에 유의. 아직은 로직이 끼어들 단계가 아니고, 스키마를 발현시킬 수 있는 다양한 병렬적 방법론 중에서 가장 효과적인 표현이 가능할 수 있을 것이라 생각되는 규칙을 '주관적으로' 선택하는 것이다.
따라서 스키마에 정답이 없듯, 이 선택에도 정답은 없다. 소위 꼴리는 대로... 랄까.
그래서 내가 선택했던 기본 규칙은 다음과 같았다.
- 빌딩숲을 위에서 바라본 것과 같은 형태의 레벨
- 그 위를 점프하여 뛰어다닐 수 있는 개구리 괴수
- 하나의 빌딩 위에 일정 시간 이상 머물러 있는 경우 빌딩이 무너지면서 괴수가 추락하고 사망
- 결국 괴수는 끊임없이 빌딩과 빌딩 위를 넘어 다녀야만 한다
- 그 위를 점프하여 뛰어다닐 수 있는 개구리 괴수
- 하나의 빌딩 위에 일정 시간 이상 머물러 있는 경우 빌딩이 무너지면서 괴수가 추락하고 사망
- 결국 괴수는 끊임없이 빌딩과 빌딩 위를 넘어 다녀야만 한다
기본 규칙을 선택하는 단계에서는 아직 스키마가 끼어들 여지가 충분히 존재한다. 게임의 기본 규칙이란 결국 머리 속에 꽂혀 있는 스키마의 상을 게임이라는 형태로 풀어놓는 것이기 때문이다.
하지만 이러한 기본 규칙까지 정립한 후에는... 이제 스키마를 버려야 하는 단계가 온다.
3. 로직의 구축
개구리 괴수에 꽂히는 것으로부터 시작하여, 그 상을 게임으로 풀어낸 기본 규칙을 정립하였으니, 이제는 구체적으로 게임의 로직을 고민할 때이다.
이 단계에서는 개구리 괴수의 상을 철저하게 배제하고, 최대한 머리 속을 dry하게 만들어야만 한다. 로직 구축의 단계에서 스키마가 끼어들면 어떤 대환란이 벌어지는지는 이전 포스트를 참고하시압. 즉 개구리 괴수의 상은 훠어이 훠어이 내다 버리고, 기본 규칙의 위에서만 로직을 구축해야 한다.
빌딩숲은 '판'으로 추상화한다. 개구리 괴수는 'PC'로 추상화한다. 그럼 결국... 다수의 늘어선 판 위를 1칸씩 이동하는 PC, 이 PC가 한번 올라선 판은 사라지며, 최종적으로 남은 판 위에 선 PC가 승리한다는 기본 규칙이 성립된다.
이 기본 위에 온라인 게임으로서 재미를 더하기 위한 온갖 로직을 더해보도록 하자. 다만 유의할 점은 덧붙이는 로직이 기본 규칙을 침해하면 안된다는 점.
- 기본 규칙 : 판과 판을 넘나드는 PC가 있고, 판은 점점 사라지며, 마지막으로 남은 판 위에 선 PC가 승리한다.
- 온라인으로의 확장 : 온라인 게임이므로 하나의 게임에 등장하게 되는 PC는 복수가 된다. 개인전과 팀전이 존재할 수 있도록 한다.
--- 개인전에서는 최후에 남는 1개의 PC만이 승리자가 된다.
--- 팀전에서는 어느 한 팀의 PC가 모두 패배하는 경우 게임이 종료되도록 한다.
- 게임 요소의 확장 : 기본 규칙의 리스크는 PC가 판 위에 있지 못하게 되는 경우 게임에서 패배한다는 점. 여기에 추가적으로 PC가 판과 판 사이를 이동하는 것을 방해하는 리스크를 더한다.
--- 이 리스크는 대전성과 연계하여, PC와 PC들이 서로의 이동을 방해할 수 있는 요소를 추가한다.
------ 아이템이라는 요소를 추가하여, 자신의 PC를 강화하거나 다른 PC를 방해하는 전략적 요소로 작용할 수 있게끔 한다.
--------- 자기 자신에게 사용하여, PC의 능력을 높이는 아이템
------------ 이동 능력 / 다른 PC나 NPC의 방해에 대하여 저항하는 능력
--------- 다른 PC에게 사용하여, 적대적 PC의 리스크를 높이는 아이템
--------- NPC에게 사용하여, 적대적 PC의 리스크를 높이는 아이템
--------- NPC에게 사용하여, 모든 PC의 리스크를 높이는 아이템
--------- 판 자체에 사용하여, 모든 PC의 리스크를 높이는 아이템
--- PC로 인해 야기되는 리스크와는 별개로, 레벨 자체에 NPC를 배치하여 모든 PC에게 공용으로 적용되는 리스크가 발생되도록 한다.
------ PC의 이동을 방해하는 NPC가 존재하도록 한다.
------ PC는 이 NPC를 소멸시킬 수 있으며, 이를 통해 일시적이나마 리스크 컨트롤이 가능하게끔 한다.
------ PC가 NPC를 소멸시키는 것으로 아이템을 획득할 수 있도록 한다.
------ PC가 아이템을 이용하여 일정 시간 동안 이 NPC를 컨트롤할 수 있도록 한다.
--- PC가 자신이 올라선 판의 소멸 속도를 가속화하여 자신의 리스크를 증대시키는 대신, 특정 상황에서 이를 전략적으로 활용할 수 있도록 한다.
- 온라인으로의 확장 : 온라인 게임이므로 하나의 게임에 등장하게 되는 PC는 복수가 된다. 개인전과 팀전이 존재할 수 있도록 한다.
--- 개인전에서는 최후에 남는 1개의 PC만이 승리자가 된다.
--- 팀전에서는 어느 한 팀의 PC가 모두 패배하는 경우 게임이 종료되도록 한다.
- 게임 요소의 확장 : 기본 규칙의 리스크는 PC가 판 위에 있지 못하게 되는 경우 게임에서 패배한다는 점. 여기에 추가적으로 PC가 판과 판 사이를 이동하는 것을 방해하는 리스크를 더한다.
--- 이 리스크는 대전성과 연계하여, PC와 PC들이 서로의 이동을 방해할 수 있는 요소를 추가한다.
------ 아이템이라는 요소를 추가하여, 자신의 PC를 강화하거나 다른 PC를 방해하는 전략적 요소로 작용할 수 있게끔 한다.
--------- 자기 자신에게 사용하여, PC의 능력을 높이는 아이템
------------ 이동 능력 / 다른 PC나 NPC의 방해에 대하여 저항하는 능력
--------- 다른 PC에게 사용하여, 적대적 PC의 리스크를 높이는 아이템
--------- NPC에게 사용하여, 적대적 PC의 리스크를 높이는 아이템
--------- NPC에게 사용하여, 모든 PC의 리스크를 높이는 아이템
--------- 판 자체에 사용하여, 모든 PC의 리스크를 높이는 아이템
--- PC로 인해 야기되는 리스크와는 별개로, 레벨 자체에 NPC를 배치하여 모든 PC에게 공용으로 적용되는 리스크가 발생되도록 한다.
------ PC의 이동을 방해하는 NPC가 존재하도록 한다.
------ PC는 이 NPC를 소멸시킬 수 있으며, 이를 통해 일시적이나마 리스크 컨트롤이 가능하게끔 한다.
------ PC가 NPC를 소멸시키는 것으로 아이템을 획득할 수 있도록 한다.
------ PC가 아이템을 이용하여 일정 시간 동안 이 NPC를 컨트롤할 수 있도록 한다.
--- PC가 자신이 올라선 판의 소멸 속도를 가속화하여 자신의 리스크를 증대시키는 대신, 특정 상황에서 이를 전략적으로 활용할 수 있도록 한다.
... 기타 등등. 뭐 애초에 본격적으로 기획을 한 것은 아니고, 브레인스토밍을 가볍게 해 본 정도의 수준이었기 때문에 여기까지만. 예시는 예시일 뿐이다 ( '') 만약 실제로 게임을 만들게 된다면, 필요한 로직은 여기에 언급된 내용보다 100배 정도는 더 많이 필요하게 될 것이다.
주목해야 하는 것은 그런 점이 아니라... 추상화의 차원에서 로직이 구축된다는 부분. 각종 요소들을 최대한 dry하게 추상화하고, 이 상태에서 객체와 객체 사이의 관계에만 집중해야 한다는 것이 요점이다.
만약 여기에 엄하게 스키마를 끼워 넣어서 '개구리 괴수라면 빌딩에서 떨어질 때 혀를 쭈욱~ 내밀어 빌딩에 매달릴 수도 있지 않을까?' 뭐 이런 생각을 하면서 삼천포로 빠지기 시작하면... 끝이 나질 않게 되어 버린다. 대환란에 대한 언급은 따로 더 하지 않겠심.
자~ 스키마의 유혹(?)에서 벗어나 로직의 구축에 성공하였다면...?
그럼 이제 다시 스키마의 품으로 돌아갈 수 있게 된다.
4. 스키마로의 복귀
잊혀졌던 개구리 괴수가 다시 부활할 시간이 왔도다!!!
로직을 모두 구축하였다면, 이제야 비로소 그 위에 스키마의 외피를 입힐 수 있게 된다.
다만 여기서 또 유의해야 할 점이 한가지...
애초에 스키마에 꽂혀, 기본 규칙을 정의하고, 머리 속을 비운 채 로직을 구축한 후... 다시 스키마로 돌아와보니...
'이게 꼭 개구리 괴수여야 할 필요가 있을까?'
라는 생각이 드는 경우가 있다.
뭐 생각하는 동물의 당연한 행태라고도 할 수 있는데... 안될게 뭐 있겠는가?
이 로직을 그대로 계승하여, 아예 퍼즐 게임으로 만든다면? 가능하다.
이 로직을 그대로 계승하여, 연방의 함대들 사이를 넘나드는 세배 빠른 빨간색 로리콘 게임으로 만든다면? 가능하다.
...
...
...
하지만 안된다.
물론 여기에서 예로 들고 있는 개구리 괴수 게임은 그 스케일이 미미하니, 현 단계에서는 아직 혼자만의 망상으로 남아있게 된다. 그러나 만약 보다 큰 스케일의 게임을 팀 단위로 개발하고 있었다면...? 현 단계에서 이미 그래픽 디자이너들은 컨셉 원화 등의 준비 작업을 시작했을 것이다. 그런데 여기에서 스키마를 바꿔 버린다면...
이것을 세간에서는 '기획의 갈아엎기'라 부르며, 만악의 근원으로 온갖 지탄의 대상이 된다.
황제의 전언 - 하지마라. (워해머 40K 오탁후만 이해할 수 있는 말이니 이해가 안간다면... 당신은 정상인) 새롭게 떠오른 스키마가 모든 팀원으로 하여금 '지금까지 만든 것은 모두 하얗게 불태워 버릴지라도 새로운 로망을!'이라 외치게 하는 것이 아닌 이상은... 절대 해서는 안될 일이다.
하지만 의외로 빠지기 쉬운 함정이기도 하다. 머리를 한번 비우고, 식어버린 냉정함으로 돌아보면 처음의 꽂힘이 의외로 시시해 보이는 경우가 많기 때문이다. 그러나 가급적이면 처음의 그 불타올랐던 로망을 믿는 쪽이 대체로 옳다.
새로운 로망은... 2편이나 외전, 혹은 다른 작품에서 써먹도록 하자 :)
애초에 스키마에 꽂혀, 기본 규칙을 정의하고, 머리 속을 비운 채 로직을 구축한 후... 다시 스키마로 돌아와보니...
'이게 꼭 개구리 괴수여야 할 필요가 있을까?'
라는 생각이 드는 경우가 있다.
뭐 생각하는 동물의 당연한 행태라고도 할 수 있는데... 안될게 뭐 있겠는가?
이 로직을 그대로 계승하여, 아예 퍼즐 게임으로 만든다면? 가능하다.
이 로직을 그대로 계승하여, 연방의 함대들 사이를 넘나드는 세배 빠른 빨간색 로리콘 게임으로 만든다면? 가능하다.
...
...
...
하지만 안된다.
물론 여기에서 예로 들고 있는 개구리 괴수 게임은 그 스케일이 미미하니, 현 단계에서는 아직 혼자만의 망상으로 남아있게 된다. 그러나 만약 보다 큰 스케일의 게임을 팀 단위로 개발하고 있었다면...? 현 단계에서 이미 그래픽 디자이너들은 컨셉 원화 등의 준비 작업을 시작했을 것이다. 그런데 여기에서 스키마를 바꿔 버린다면...
이것을 세간에서는 '기획의 갈아엎기'라 부르며, 만악의 근원으로 온갖 지탄의 대상이 된다.
황제의 전언 - 하지마라. (워해머 40K 오탁후만 이해할 수 있는 말이니 이해가 안간다면... 당신은 정상인) 새롭게 떠오른 스키마가 모든 팀원으로 하여금 '지금까지 만든 것은 모두 하얗게 불태워 버릴지라도 새로운 로망을!'이라 외치게 하는 것이 아닌 이상은... 절대 해서는 안될 일이다.
하지만 의외로 빠지기 쉬운 함정이기도 하다. 머리를 한번 비우고, 식어버린 냉정함으로 돌아보면 처음의 꽂힘이 의외로 시시해 보이는 경우가 많기 때문이다. 그러나 가급적이면 처음의 그 불타올랐던 로망을 믿는 쪽이 대체로 옳다.
새로운 로망은... 2편이나 외전, 혹은 다른 작품에서 써먹도록 하자 :)
뭔가 삼천포로 많이 빠져버렸는데... 아무튼 구축된 로직에 스키마의 외피를 입혀보도록 하자.
- 빌딩숲 위을 누비는 개구리 괴수들의 대난투! 빌딩들은 괴수의 무게를 못이겨 하나 둘 씩 무너져 내리고... 추락한 괴수는 목숨을 잃는다. 하지만 마지막으로 남은 빌딩, 그 위에 최후로 올라 선 괴수는 승리자가 된다!
- 유저는 개구리 모양의 괴수를 조종하게 된다.
--- 개구리 괴수는 빌딩의 옥상 위에서 이동할 수 있다.
--- 개구리 괴수는 빌딩의 옥상과 옥상 사이를 점프하여 이동할 수 있다.
--- 개구리 괴수의 기본 점프 거리는 1칸의 옥상 간 거리만큼이다.
--- 개구리 괴수가 빌딩에서 추락하게 되는 경우 사망하게 되며, Life Point를 잃게 된다.
--- 개구리 괴수는 혀를 죽 내밀어 점프 중인 다른 괴수를 낚아채 추락시킬 수 있다.
--- 개구리 괴수는 자신이 올라 선 빌딩을 공격하여 보다 빨리 붕괴되게끔 할 수 있다.
- 레벨은 빌딩숲을 위에서 바라본 것과 같은 형태로 구성된다.
--- 개구리 괴수가 빌딩 옥상에 있으면, 점점 흔들리다가 결국 붕괴하게 된다.
--- 빌딩숲 아래에는 탱크들이 오가며, 점프하는 괴수들을 향해 발포하고, 피격된 괴수는 추락하게 된다.
--- 빌딩숲 위로는 헬기와 전투기들이 오가며, 괴수를 향해 발포하고 피격된 괴수는 그 방향으로 밀리게 되어 추락할 수 있다.
--- 개구리 괴수는 혀를 죽 내밀어 헬기나 전투기를 파괴할 수 있다. 이 때 아이템이 획득된다.
------ 아이템을 이용하여 일정 시간 동안 점프 거리를 늘릴 수 있다.
------ 아이템을 이용하여 다른 괴수에게 점막을 발사하면 이동 속도가 느려지고 점프 거리가 줄어든다.
------ 아이템을 이용하면 특정 빌딩 옥상에 파리떼를 소환하며, 그 위에 있던 괴수는 파리를 잡아먹는 데에 정신이 팔려 빌딩이 무너지는 것도 모르게 된다.
------ 아이템을 이용하면 특정 괴수에게 타겟을 찍을 수 있으며, 타겟이 찍힌 괴수는 탱크, 헬기, 전투기들에게 집중적으로 공격당하게 된다.
- 유저는 개구리 모양의 괴수를 조종하게 된다.
--- 개구리 괴수는 빌딩의 옥상 위에서 이동할 수 있다.
--- 개구리 괴수는 빌딩의 옥상과 옥상 사이를 점프하여 이동할 수 있다.
--- 개구리 괴수의 기본 점프 거리는 1칸의 옥상 간 거리만큼이다.
--- 개구리 괴수가 빌딩에서 추락하게 되는 경우 사망하게 되며, Life Point를 잃게 된다.
--- 개구리 괴수는 혀를 죽 내밀어 점프 중인 다른 괴수를 낚아채 추락시킬 수 있다.
--- 개구리 괴수는 자신이 올라 선 빌딩을 공격하여 보다 빨리 붕괴되게끔 할 수 있다.
- 레벨은 빌딩숲을 위에서 바라본 것과 같은 형태로 구성된다.
--- 개구리 괴수가 빌딩 옥상에 있으면, 점점 흔들리다가 결국 붕괴하게 된다.
--- 빌딩숲 아래에는 탱크들이 오가며, 점프하는 괴수들을 향해 발포하고, 피격된 괴수는 추락하게 된다.
--- 빌딩숲 위로는 헬기와 전투기들이 오가며, 괴수를 향해 발포하고 피격된 괴수는 그 방향으로 밀리게 되어 추락할 수 있다.
--- 개구리 괴수는 혀를 죽 내밀어 헬기나 전투기를 파괴할 수 있다. 이 때 아이템이 획득된다.
------ 아이템을 이용하여 일정 시간 동안 점프 거리를 늘릴 수 있다.
------ 아이템을 이용하여 다른 괴수에게 점막을 발사하면 이동 속도가 느려지고 점프 거리가 줄어든다.
------ 아이템을 이용하면 특정 빌딩 옥상에 파리떼를 소환하며, 그 위에 있던 괴수는 파리를 잡아먹는 데에 정신이 팔려 빌딩이 무너지는 것도 모르게 된다.
------ 아이템을 이용하면 특정 괴수에게 타겟을 찍을 수 있으며, 타겟이 찍힌 괴수는 탱크, 헬기, 전투기들에게 집중적으로 공격당하게 된다.
... 기타 등등. 뭐 스키마는 아무래도 좋으니 내키는 대로... 라고는 하지만서도, 위에서 언급한 함정에는 유의할 것 ( '')
처음에 꽂힌 스키마가, 기본 규칙을 통해 게임화되고, 로직을 그 뼈대로 삼아, 이제 비로소 최종적인 스키마를 입고 하나의 게임이 기획되었다. (물론 제대로 기획하려면 여기 100배 정도는 추가 분량이...)
이것이 바로 '이런 게임이 있다면 재미있을텐데...'라고 대충 쉽게 망상하는 것과, 개발자가 게임을 구상하는 것의 차이. 뭐 되게 거만해 보일는지도 모르겠지만... 생각의 방법론이라 할 수 있다.
...
...
...
하지만 정작 만들어 놓고 보니... 으 눈치채셨슴미까? 어디서 되게 많이 본 듯한 게임이 나와버렸군효 ㄱ-
<무슨 게임일까효? 펼쳐보아효>
뭐 이건 내가 내츄럴 본 표절 기획자라서 그런거니까 ( --) 대충 그러려니... ( --)로직과 스키마 연작의 예고편 포스트를 기억하시는지? 프라모델의 제작에 대한 비유를 마지막으로 한번 더 해보자면 다음과 같다.
1. 스키마에 꽂히다 : 결국 처음에 생각하게 되는 것은 삐까번쩍한 외양이다. 로망이 철철 넘쳐 흐르는 건담이든 뭐든 기타 등등의 멋진 모습, 혹은 움직임에 꽂히는 것에서부터 시작된다.
2. 기본 규칙의 선택 : 당신의 머리에 꽂힌게 건담인지? 혹은 노이에질? 볼? MS인지 MA인지 정도는 일단 정하고 간다.
3. 로직의 구축 : 그럼 이제 프레임을 만들어 보는거다. 이 때엔 스키마를 잊어라. 하지만... 애초에 시작은 스키마였고, 그 시작은 기본 규칙으로 승계되었다. 프레임은 스키마를 잊되, 스키마를 기본 규칙으로 승계한다.
4. 스키마로의 복귀 : 프레임을 다 만들었다면 이제 마지막으로 외부 장갑을 만든다. 1번에서 꽂힌 외양이 잘 계승되었는가? 1번에서 꽂힌 움직임이 잘 계승되었는가? 그렇다면 성공하셨슴미다 /박수
2. 기본 규칙의 선택 : 당신의 머리에 꽂힌게 건담인지? 혹은 노이에질? 볼? MS인지 MA인지 정도는 일단 정하고 간다.
3. 로직의 구축 : 그럼 이제 프레임을 만들어 보는거다. 이 때엔 스키마를 잊어라. 하지만... 애초에 시작은 스키마였고, 그 시작은 기본 규칙으로 승계되었다. 프레임은 스키마를 잊되, 스키마를 기본 규칙으로 승계한다.
4. 스키마로의 복귀 : 프레임을 다 만들었다면 이제 마지막으로 외부 장갑을 만든다. 1번에서 꽂힌 외양이 잘 계승되었는가? 1번에서 꽂힌 움직임이 잘 계승되었는가? 그렇다면 성공하셨슴미다 /박수
물론 이러한 스키마 -> 로직 -> 스키마의 순환 구조는 '내 방법론'이다. 이게 정답은 아닐거라는 점, 이보다 나은 방법론은 얼마든지 있을 수 있다는 점에 무조건 유의.
하지만 그래도 로직과 스키마를 고민하는 개발자에게 참고 정도는 되어줄 수 있을 거라고 생각한다.
여기까지... 로 해서리 되도 않는 뻘소리로 점철된 3연작 끗.
...
...
...
하지만 end가 아닌 and로?
이미 이전 포스트에서 댓글로 여러가지 이야기가 오간 것에서 알 수 있듯이... 이 개념은 완벽하지 않다.
더 많은 개발자들이, 더 치열한 고민을 통해, 더 세밀한 세분화를 통해 개념을 확장해 나아가고 발전시킬 수 있기를 :)
|
Trackback Address :: http://glekang.com/trackback/283
|
[글강, 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
|
[글강, 2007/04/26 18:58, Game]
게임을 바라보는 수많은 관점 중에는 로직(logic)과 스키마(schema)를 통해 접근하는 방법이 있다.
로직? 스키마? 일단은 이 두 단어의 정의부터 하고 보자.
정리하자면... 로직은 게임의 내적 규칙, 스키마는 그 내적 규칙에 덧씌우는 외피라 할 수 있다.
다른 용어가 더 적절할는지도 모르겠는데... 우리 팀에서는 '로직과 스키마'라고 부르고 있으니, 그걸 그대로 써보자 ( '')
로직은 말 그대로 게임의 규칙을 구성한다.
하지만 게임의 모든 내적 규칙을 로직이라고 정의할 수는 없다.
예를 들어 '우리 게임은 파티 플레이 중심으로 패턴이 구성되게끔 한다'와 같은 규칙은 로직의 부류로 들어가지 않는다.
어째서? 저것 역시 게임의 규칙임에도 불구하고?
그 이유는 저 규칙이 파티 플레이와 솔로 플레이의 병렬적 관계 위에서 선택된 것이기 때문이다.
반드시 파티 플레이 중심어야 할 필요가 있는가? 솔로 플레이 중심이어서는 안될 이유가 있는가? 파티 플레이와 솔로 플레이 중 어느 쪽
로직? 스키마? 일단은 이 두 단어의 정의부터 하고 보자.
로직(logic) : 원래는 논리, 조리, 이치, 타당성, 기준 원칙 등을 의미하는 단어이며, 특히 여기에서 말하는 로직이란 게임의 내부적인 규칙이다.
간단하게 예를 들자면 다음과 같다.
A와 B가 충돌하면, A가 소멸하고 B는 소멸하지 않는다. 따라서 유저는 B를 피하여 A를 컨트롤해야 한다.
실제 게임에서 A는 전투기일 수도 있고 전차일 수도 있겠지만, 로직의 단계에서는 그런 것을 의도적으로 배제하게 된다. 즉 로직은 dry하면서도 추상적 차원에서만 결정되는 게임의 규칙이라 할 수 있다.
간단하게 예를 들자면 다음과 같다.
A와 B가 충돌하면, A가 소멸하고 B는 소멸하지 않는다. 따라서 유저는 B를 피하여 A를 컨트롤해야 한다.
실제 게임에서 A는 전투기일 수도 있고 전차일 수도 있겠지만, 로직의 단계에서는 그런 것을 의도적으로 배제하게 된다. 즉 로직은 dry하면서도 추상적 차원에서만 결정되는 게임의 규칙이라 할 수 있다.
스키마(schema) : 원래는 개요, 윤곽, 도식 등을 의미하는 단어이며, 특히 여기에서 말하는 스키마란 게임의 외부적인 껍질이다.
위에서 예로 들었던 로직에 흔히 볼 수 있는 횡스크롤 전투기 슈팅 게임의 스키마를 입혀보자면 다음과 같다.
유저가 조종하는 전투기와 적기가 충돌하면, 전투기는 파괴되고 적기는 파괴되지 않는다. 따라서 유저는 적기를 피하여 전투기를 조종해야 한다.
즉 스키마란 추상적 차원에서 구축된 로직을 실제로 눈에 보이는 형태로 이끌어 내리는 것이다. 로직의 단계에서 의도적으로 배제했던 외피를 이제 덧입히는 것이다.
위에서 예로 들었던 로직에 흔히 볼 수 있는 횡스크롤 전투기 슈팅 게임의 스키마를 입혀보자면 다음과 같다.
유저가 조종하는 전투기와 적기가 충돌하면, 전투기는 파괴되고 적기는 파괴되지 않는다. 따라서 유저는 적기를 피하여 전투기를 조종해야 한다.
즉 스키마란 추상적 차원에서 구축된 로직을 실제로 눈에 보이는 형태로 이끌어 내리는 것이다. 로직의 단계에서 의도적으로 배제했던 외피를 이제 덧입히는 것이다.
정리하자면... 로직은 게임의 내적 규칙, 스키마는 그 내적 규칙에 덧씌우는 외피라 할 수 있다.
다른 용어가 더 적절할는지도 모르겠는데... 우리 팀에서는 '로직과 스키마'라고 부르고 있으니, 그걸 그대로 써보자 ( '')
로직은 말 그대로 게임의 규칙을 구성한다.
하지만 게임의 모든 내적 규칙을 로직이라고 정의할 수는 없다.
예를 들어 '우리 게임은 파티 플레이 중심으로 패턴이 구성되게끔 한다'와 같은 규칙은 로직의 부류로 들어가지 않는다.
어째서? 저것 역시 게임의 규칙임에도 불구하고?
그 이유는 저 규칙이 파티 플레이와 솔로 플레이의 병렬적 관계 위에서 선택된 것이기 때문이다.
반드시 파티 플레이 중심어야 할 필요가 있는가? 솔로 플레이 중심이어서는 안될 이유가 있는가? 파티 플레이와 솔로 플레이 중 어느 쪽


