'팀테스트'에 해당되는 글 2건
[글강, 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/02 20:55, Game]
알파 테스트 이전의 단계, 그러니까 걍 팀 내에서만 진행하는 구현 테스트... 같은 놈은 뭐라고 불러야 하나효?
에에... 그냥 팀 테스트? -_-a 모르겠다. 걍 팀 테스트 ㅋ
그러니까 드디어 팀 테스트를 시작했다능.
아아... 무슨 게임인지는 뭐 아직 공개가 아니된 녀석이니, 걍 수많은 개발사들이, 수없이 가지고 있으면서, 조용히 진행하다가, 혹은 조용히 접어버리기도 하는(쿠엑) 그냥저냥 개발 프로젝트인 셈인데.
암튼 기나긴 프로토타이핑의 산을 넘어, 이제야 비로소 실구현된 클라이언트의 첫 테스트.
... 당연히 개판 오분전임미다.
속출하는 버그들, 아직 제대로 붙지 못한 리소스들, 그리고 밸런싱이 뭔가효 먹는건가효?
... 게임이라 부르기도 애매한, 돌아가는게 다행인... 아니지 제대로 돌아가지도 않자나 ; 암튼 뭐 그런 상태.
당연히 수많은 문제들이 불궈져 나오고, 미처 예측하고 고려하지 못한 문제들도 수면을 박차고 튀어나오고 그러나니...
패닉에 빠지기가 참 쉽다능.
그러므로 결론은 설레발 금지.
일단은 다른 요소들과 실타래처럼 얽힌 녀석들에 손을 대는 것은 금물이다. 뭐 하나 건드리면 줄줄이 엮이는데, 건드린 녀석이 문제의 핵심이라는 보장은 '아직' 아무 데에도 없으니까.
개별 단위의 독립적인 문제들을 우선 손봐서 제대로 해놓고, 그 후에야 비로소 전체적인 그림을 다듬어가야 하나니...
뭐 이건 너무나도 당연한 일반론.
그러나 한발짝만 삐끗하면 패닉이나니, 정신줄을 잡읍시다 ㅋ
근데 그보다 더 곤란한 문제는... 쯥.
개발 외적인 이슈로 1개월을 허공으로 날려버렸는데, 그 1개월을 아무도 보상해주지 아니하나니 ㄱ-
히밤. 크런치로 극복이라니... 이게 뭔가효. 그나마 크런치를 이렇게 빡세게 하고 있는데도 그냥 대놓고 물리적 시간이 모질라.
장기적으로 보자면 이 부작용은 점점 누적될 가능성이 높은데 ㄱ- 이거이 개발 프로젝트에서 원래 발생하는 리스크인건지 에잉.
에에... 그냥 팀 테스트? -_-a 모르겠다. 걍 팀 테스트 ㅋ
그러니까 드디어 팀 테스트를 시작했다능.
아아... 무슨 게임인지는 뭐 아직 공개가 아니된 녀석이니, 걍 수많은 개발사들이, 수없이 가지고 있으면서, 조용히 진행하다가, 혹은 조용히 접어버리기도 하는(쿠엑) 그냥저냥 개발 프로젝트인 셈인데.
암튼 기나긴 프로토타이핑의 산을 넘어, 이제야 비로소 실구현된 클라이언트의 첫 테스트.
... 당연히 개판 오분전임미다.
속출하는 버그들, 아직 제대로 붙지 못한 리소스들, 그리고 밸런싱이 뭔가효 먹는건가효?
... 게임이라 부르기도 애매한, 돌아가는게 다행인... 아니지 제대로 돌아가지도 않자나 ; 암튼 뭐 그런 상태.
당연히 수많은 문제들이 불궈져 나오고, 미처 예측하고 고려하지 못한 문제들도 수면을 박차고 튀어나오고 그러나니...
패닉에 빠지기가 참 쉽다능.
아놔 이거 어쩌나효. 버그는 버그니까 일단 고쳐야 하는데, 추가 구현을 더 해야 하나? 이건 뭐 대놓고 땜빵이 될텐데 (...)
아놔 이거 어쩌나효. 리소스 전면 교체라도 해야 하나? 아니 근데 아직 비쥬얼 밸런스를 맞추지도 않았는데 (...)
아놔 이거 어쩌나효. 밸런싱 처음부터 다시 해야 하나? 아니 근데 아직 제대로 테스트도 못해봤는데 밸런싱이 적용된 거이다 할 수도 없거늘 (...)
아놔 이거 어쩌나효. 리소스 전면 교체라도 해야 하나? 아니 근데 아직 비쥬얼 밸런스를 맞추지도 않았는데 (...)
아놔 이거 어쩌나효. 밸런싱 처음부터 다시 해야 하나? 아니 근데 아직 제대로 테스트도 못해봤는데 밸런싱이 적용된 거이다 할 수도 없거늘 (...)
그러므로 결론은 설레발 금지.
일단은 다른 요소들과 실타래처럼 얽힌 녀석들에 손을 대는 것은 금물이다. 뭐 하나 건드리면 줄줄이 엮이는데, 건드린 녀석이 문제의 핵심이라는 보장은 '아직' 아무 데에도 없으니까.
개별 단위의 독립적인 문제들을 우선 손봐서 제대로 해놓고, 그 후에야 비로소 전체적인 그림을 다듬어가야 하나니...
뭐 이건 너무나도 당연한 일반론.
그러나 한발짝만 삐끗하면 패닉이나니, 정신줄을 잡읍시다 ㅋ
근데 그보다 더 곤란한 문제는... 쯥.
개발 외적인 이슈로 1개월을 허공으로 날려버렸는데, 그 1개월을 아무도 보상해주지 아니하나니 ㄱ-
히밤. 크런치로 극복이라니... 이게 뭔가효. 그나마 크런치를 이렇게 빡세게 하고 있는데도 그냥 대놓고 물리적 시간이 모질라.
장기적으로 보자면 이 부작용은 점점 누적될 가능성이 높은데 ㄱ- 이거이 개발 프로젝트에서 원래 발생하는 리스크인건지 에잉.
|
Trackback Address :: http://glekang.com/trackback/355
|

















