비시스템 기획과 시스템 기획의 비용
기능을 비시스템적으로 개발하게 되면
최소한의 비용으로 개발을 할 수 있다.
그렇기 때문에 속도와 비용이 중요한 프로토타이핑에서는
시스템 개발을 하지 않고, 되는 대로 빠르게 개발을
하는 것이다.
근시안적인 관점에서의 시스템 개발은 효율이
떨어지는 경우가 많다.
하지만 장기적인 관점에서는 시스템 개발을 통한 기능이
오히려 더 경제적으로, 비용을 줄일 수 있다.
시스템 기획의 비용
먼저 시스템 개발을 통해 얻는 높은 완성도는
장기적인 관점에서 개발 비용이 줄어듦을 알 수 있다.
기능의 완성도가 증가함에 따라 결함과 하자가 줄어들고,
줄어듦에 따라 수정해야 하는 상황도 적어진다.
게임의 결함은 시간이 지날수록 그 수정 비용이
엄청나게 커진다는 것을 생각해 보면,
높은 완성도가 줄여주는 비용은 상당히 크다.
또한 개발된 시스템은 기능의 관리와 사용을
위한 내용을 포함하기 때문에,
이후 시스템을 조정하거나 컨텐츠 제작을 할 때 드는
비용을 줄일 수 있다는 것은 큰 이점이다.
기능 개발만 놓고 보면
시스템 개발을 하는 경우가 비싸긴 하지만,
기능과 관련한 다른 작업들에 대한 비용은
줄일 수 있다는 것이다.
이에 대해 수식으로 정리하면 다음과 같다.
수식이 보기 불편하다면, 수식에 대한 설명을 하는
[그림 8, 9]만 간단히 읽어도 좋다.
시스템 기획 비용에 대한 분석
먼저 개발과 관련한 개발 비용인
『C1』(시스템 개발 비용)과 『C2』(비시스템 개발 비용)를
비교해 보겠다.
단순한 개발 비용만 비교하면 『SDC』 > 『NSDC』의 관계가
성립한다.
따라서 『C1』>『C2』의 관계를 합리적으로 기대할 수 있다.
하지만 기능 개발에 테스트를 하는 것까지 포함시키면,
『C1』과 『C2』의 관계가 달라질 수 있다.
『테스트(Test)』라는 것은,
현재의 상태를 모니터링하고, 이를 개선하는 작업을 말한다.
따라서 『테스터(Tester)』는 특정 현상을 보거나 특정 값을 수정할 수 있어야 한다.
시스템은 테스트에 사용할 수 있는 데이터를 가지고 있기 때문에
데이터를 조정하여 원하는 테스트 상황을 만들기가 쉽다.
반면에, 이런 테스트 인터페이스가 없다면
직접 게임을 하면서 확인해야 한다.
간단한 테스트를 할 때는 큰 차이가 없지만,
여러 상황에 대해 많은 테스트를 할 때는 테스트 인터페이스,
즉 데이터가 있고 없음의 차이가 크게 난다.
전투 피해 공식을 테스트한다고 가정해보자.
1. 실제 게임을 하면서 테스트 하는 방법
2. 스테이터스를 조작할 수 있는 환경에서 테스트하는 방법
첫 번째 경우에는 다양한 스테이터스 조합에 대한 테스트 케이스를
만들기가 굉장히 어려울 뿐더러, 그 결과를 계산하고 확인하는 과정도
결코 쉽지 않을 것이다.
두 번째 경우에는 공식을 확인하기 위해서 만들어진 테스트 케이스대로
세팅한 뒤에 테스트를 수행하면 되기 때문에, 테스트에만 집중하여
빠르게 처리할 수 있다.
게다가 시스템이 각종 수치들을 확인할 수 있는 인터페이스가
제공된다면 테스트 결과를 분석할 때도 원하는 내용을 확인하기가
더 쉬워질 것이다.
정리하자면, 시스템 개발은 테스트 비용을
많이 줄여주기 때문에,
테스트를 많이 하게 되는 상황에서 비용 절감을
더 많이 할 수 있게 된다.
어떤 경우는 『C1의 TC』(시스템 개발 테스트 비용)가
『C2의 TC』(비시스템 개발 테스트 비용)보다 획기적으로 줄어들게 되어
『C1』이 『C2』보다 적게 될 수도 있다. (『C1』 < 『C2』)
요구하는 기능의 완성도가 높을수록, 테스트도
그만큼 많이 하는 것을 고려해보면,
완성도 높은 기능을 개발할 때는 비용 측면에서조차
시스템 개발이 유리할 수도 있다.
테스트 비용의 비교
《 가정된 상황 설명 》
게임에 적용되는 물리(Physics) 중에 『중력』에 대한
개발을 하기로 한 상황이다.
이와 관련하여 경사면에서의 중력을 처리하기로 했으며,
중력 가속도를 '일반 상태'와 '경사면상태'로 나누어
처리하기로 했다.
이 두 중력 가속도에 대해 『기능 명세(specification)』를 한 뒤,
현재 괜찮을 것으로 예상되는 중력 가속도들의 값들과 함께
개발자에게 넘겨주었다.
이윽고 구현이 끝나고, 테스트를 해본 결과 이 값들에 대한
변경이 필요하다는 것을 알게 되었다.
시스템 개발을한 경우에는 설정할 수 있는 데이터 까지
설계하여 구현된 상태다.
다음 그림은 데이터 인터페이스(데이터 파일)라고 볼 수 있다.
《 비시스템적인 접근 시 테스트 진행 시나리오 》
구현이 끝난 이후에 이를 게임 엔진에서 실행하면서 확인해보았다.
중력값이 너무 작아서 캐릭터가 허공에 뜨는 느낌이다.
『G(중력)』라는 값을 바꾸면 될 것 같은데,
본인에게는 스크립트를 수정한 권한도, 능력도 없다.
A라는 값보다는 B라는 값 정도면 될 것 같은데 확신은 없다.
어쩔 수 없이 개발자에게 B로 변경을 요청했다.
개발자가 처리해준 다음에 다시 실행해 값을 확인해 보니
결과는 만족스럽지만 D 정도면 더 좋을 것 같다.
다시 D로 변경을 요청하니, 개발자가 약간 짜증을 내는 것 같다.
근데 굳이 큰 차이는 없지만서도, C 정도면 정말 괜찮을 것 같다.
그래서 개발자 근처로 가보니, 뭐든 간에 수정해달라고 말하면
과로사 해버리겠다라는 표정을 짓고있다.
《 시스템적인 접근 시 테스트 진행 시나리오 》
개발이 끝난 이후에, 이를 게임 엔진에서 실행을 하면서 확인했다.
중력값이 너무 작아서 캐릭터가 허공에 뜨는 느낌이다.
상수 관련 데이터에서 『G(중력)』값을 B로 수정했다.
빌드를 하고 다시 실행해서 확인해보니, 뭔가 모자란 느낌이다.
D로 수정하고 빌드해보니 뭐 나름 괘찮긴 한데
C 정도면 진짜 마지막일 것 같아서 수정 후 다시 테스트 하였다.
음, 이제 만족스럽다.
이제 상사에게 확인을 받고 테스트를 종료해야겠다.
위의 상황에서는 다소 극단적으로 가정된 상황인
것은 맞지만,
실제로 기획자가 직접 데이터를 조정할 수 없을 때는
개발자에게 수정 요청을 해야 하는 것을 생각해 보면
현실성이 아예 없다고는 할 수 없다.
앞서 든 예시의 『중력』과 같은 기능은
게임의 장르에 따라 근간을 이루는 중요한 요소다.
이와 같은 중요 기능은 높은 완성도가 요구되고
개발 시에 많은 테스트와 수정을 필요로 하기 때문에
비시스템적인 접근으로 개발하면 어려운 점이
더 많이 발생할 수 있다.
비효율적인 테스트를 많이 할수록 개발 비용이 증가하고,
테스트를 소홀히 하게 되면 완성도가 낮아질 수도 있다.
기획자와 개발자 사이의 추가 의사소통 없이 테스트를 진행할 수 있다는 것과
기획자가 직접 시스템을 조정할 수 있다는 것은 엄청나게 큰 장점이다.
참고 및 출처
 |
|
