어디까지나 개인적인 경험에 비추어 이야기 하는 것임에 유의하세요.
***
“우리 게임의 캐릭터들은 어떻게 죽어?”
시스템 기획자에게 이렇게 물었을 때.
“엌! 하고 죽어요.”
라고 하면 엌! 소리 나게 패줍시다. -_-
시스템 기획자, 아니 기획자들은 이러한 단순한 행위를 구조화 시킬 수 있어야 합니다.
그러니 최소한‘우리 게임의 캐릭터들은, HP가 0이 되면 죽고, 50m 이상에서 떨어지면 죽고, 실연당하면 죽습니다.’ 라는 식으로 말하거나,
아니면 다음과 같이 정리할 수 있어야 합니다.
시스템의 구조는 이러한 사고방식에서 시작합니다.
논리적인 사고방식이죠.
어쨌든 시스템 디자이너는 기본적으로 모든 것을 논리적으로 체계화 시킬 수 있어야 합니다.
‘적을 공격한다.’라는 단순한 행위도.
위의 그림처럼 세부적으로 나눌 수 있어야 합니다.
여기에서 한 발자국 더 나아가면 게임 의도에 맞춰 구조를 조정할 수도 있어야 합니다.
다음 두가지 예시를 보죠.
ex1) 대규모 인원이 싸우는 전쟁게임의 전투
이렇게 줄인 이유는 시스템 구조를 최소화 하여 서버와 클라이언트의 부하를 최소화하기 위해서입니다.
이렇게 극단적으로 줄이는 경우까지는 없을지 몰라도, 있는 데이터도 날려버릴 각오로 구조를 변경하는 경우는 더러 있습니다.
ex2) 1~4명이 즐기는 MO액션 게임의 전투.
이번에는 연속기라는 것을 넣어 전투를 좀 더 화려하게 만든다는 가정 하에 추가했습니다.
연속기에 관련된 루틴이 추가되어 대충 봐도 복잡한 구조가 되어가는 것을 알 수 있습니다.
대부분의 시스템 구조는 이런 식으로 계속 조건이 붙고, 수정되고, 시행착오 등을 겪으면서 완성되어 갑니다.
그러니 한 번 만들면 끝이 아니라, 그 때 그 때의 상황 변화에 따라 유연하게 구조를 바꿀 수도 있어야 합니다.
다만 이미 완성된 게임에서는 이런 구조변화가 불가능한 경우가 있습니다.
이유는 간단합니다.
변화로 인해 문제가 생기면 당신이 책임질 건가요? -_-+
어떤 새퀴냐?
서비스 중인 서버에 당당히 테스트 한 쥐새퀴가.
존 말 할 때 당장 튀어 나와라.
*** ***
이런 구조 변화에 따라 ‘매번 문서를 만들고 회의를 해야 하는가?’라고 생각하는 분도 있을 겁니다.
회사에 따라, 작업의 중요도에 따라 차이가 있기는 하나 그 정도는 아닙니다.
이런 구조는 담당 프로그래머와의 공조로 이루어집니다.
즉 기획자 혼자가 아니라 프로그래머랑 같이 짜는 경우가 더 많습니다.
대략 이런 느낌입니다.
기획자 -> A
프로그래머 -> B
A: B씨 이거 이런 구조로 만들려고 합니다.
B: 그래요? 한 번 해볼게요.
잠시 후...
B: 이 구조로 하니 이런 문제가 생기네요. 이 문제는 어떻게 할까요?
A: 이 문제는 요렇게 구조를 변경해서 해보죠.
B: 그럼 요런 상황이 발생하면 어떻게 하나요?
A: 요런 상황은 저런 루틴을 추가해서 처리하죠.
B: 저런 루틴을 추가하면 이게 좀 걸리네요. 이건 그대로 할까요?
A: 음... 이건 조금 생각해볼게요.
B: 저는 요렇게 하는 게 좋아 보이는데요.
A: 아, 그거 좋네요. 그럼 그렇게 해보죠.
B: 오케이 한 번 해보죠.
이렇게 인던은 어떻게 들어갈지, 부활은 어떻게 할지, 루팅은 어떻게 할지, 퀘스트는 어떻게 받을지 등등등...
다양한 것을 수시로 상의하면서 공조하여 만들어 갑니다.
전에도 말했듯이 게임은 혼자 만드는 것이 아닙니다.
이렇게 서로 협동하고 상의하며 만들어지는 것입니다.
기획자는 위의 대화처럼 원활한 상의가 가능하게끔 기본적인 지식정도는 갖춰야 하는 겁니다.
그리고 모르면 물어보세요.
그래도 모르면 두 번 물어보세요!
세 번 물어볼 땐 커피라도 한 잔 드리면서 물어보세요~!
정리하자면...
시스템 구조를 짜기 위해서는 논리적으로 체계화 시킬 수 있어야 한다.
시스템 구조는 상황에 따라 의도에 맞춰 변경할 줄 알아야 한다.
시스템 구조(게임)는 혼자 만드는 것이 아니다!
대략적으로 구조를 설명했으나, 이게 끝이 아닙니다.
이를 통해 수치를 입력하는 방법까지 나와야 합니다.
이 후 스크립트 함수나 테이블이 만들어지데 이 또한 구조적인 융통성과 센스가 필요합니다.
그건 다음에~
