[펌] 데이터 주도적(Data Driven)인 게임 설계

예전에 이런 일이 있었다.

 

몬스터마다 Drop 하는 아이템의 종류 및 확률 테이블의 설정을 변경하느라고 프로그래머와 신경전을 벌이고 있었다. 내 불만의 주된 원인은, (사실은 게임내에서 얼마나 잘 떨어지는지 추적도 하지 않는 주제에) 기획서대로 아이템이 떨어지기 위한 게임의 구현이 정확하지 않다는 것이었다. 당시의 구현은 그럭저럭 확률이 기획서와 비슷하지만 정확하지는 않았고, 몬스터마다 다르게 설정하기도 힘들었다. (즉, D&D의 보물 타입과 같이 구현되어 있었다)

 

전직 프로그래머(-_-)이었고 그 프로그래머가 친한 학과 후배이다 보니, 생각해오던 구현을 강요하게 되었고, 그러다가 서로의 약점을 건드리는 바람에 폭발 직전에까지 갔다가, 어째어째 양보하여 전투가 끝이 났다.

 

웃긴 건, 그 당시 나의 피해의식은 "왜 이렇게 밸런스 수정하기가 어려운거지?"라는 것이었다. 실제로 기획 작업을 해보면서 느낀 점이, 서비스중인 게임의 경우 미세한 조정이 항상 발생하게 되는데, 그때마다 프로그래머들의 눈치를 계속 봐야 한다는 게 정말 불만이었다.

 

물론 코드 수정이라는 것이 오랜동안의 전체 빌드와 패치, 업로드, 재시작, 그리고 최종점검까지 걸리는 시간동안 프로그래머들이 느끼는 심적 부담감이 막중하다는 것은 사실이다. 더군다나 전투 공식이나 객체의 파라미터 같은 부분적 코드/데이터 수정이 아니라, 기존의 DB에 누적된 데이터를 보정해야 하는 밸런싱 패치의 경우, 스트레스는 정말 상상 못할 만큼 어마어마하다. (세상의 게임 기획자들이여.. 당신들은 이것만큼은 이해해줘야 합니다)

 

그러나, 아무리 코드 내부에 각종 데이터들이 하드코딩으로 박혀 있을지라도, 꼭 필요한 것은 해야 하는 법. 결국 유저들 눈치 보고, 프로그래머 눈치 보고, 그래픽 디자이너 눈치를 보고, 불쌍한 운영팀 눈치를 보느라 기획자의 마음은 곪아 들어게 되고, 밸런싱 이야기만 나오면 쥐구멍으로 숨고 싶어지는 지경에까지 이르렀다.

 

이제 다시 프로그래머로 전업한 레이옷은, 우리팀의 기획자들은 그런 슬픔에 젖지 않도록 애를 쓰고 있다. 가능한한 파라미터들은 XML 에 명시, 실시간으로도 리로딩할 수 있게 했고, 몇몇 로직들은 lua 스크립트로 빼내서 역시 손쉽게 수정할 수 있도록 했다. 하지만, 진정한 데이터 주도적인 게임이 되려면 아직도 한참 멀었다. 아직도 수정하기 위해서는 프로그래머에게 구두 요청을 해야 하기 때문에... (우리 기획자들도 여전히 스트레스를 받을지도 모른다. 물어보진 않았지만...)

 

그리고는 깨달음을 얻었다.

 

1. 기획자들에게 밸런싱툴을 제공할 것

 

가장 이상적인 케이스가 바로 WarCraft3 (그리고 NWN과 모로윈드) 의 에디터. 

 

그러나, 아직 실력이 되지 않아서, 각종 룰과 객체들을 툴 레벨로 빼내는 것이 쉽지는 않다. 모드를 제작할 수 있을 정도의 툴을 만드는 그날까지 노력하는 수밖에. 아무튼, 프로그래머의 도움 없이 기획자들이 알아서 척척척 스스로 어린이~ 가 되도록 해주면 되겠지. 그동안의 밸런싱 히스토리까지도 로그로 남겨주면 금상첨화.

 

2. 기획자들이 손쉽게 테스트할 수 있는, 다양한 콘솔 명령어들을 제공할 것

 

이 깨달음의 핵심은 실시간 Modification 이다.

 

때와 장소를 가리지 않고, 테스트하고 싶은 기능들을 실시간으로 고칠 수 있도록 한다는 것이 주목적. MMORPG 의 경우 더더욱 필요한 기능이리라. 콘솔창을 띄우고 각 객체의 속성에 접근, 수정 후 테스트할 수 있도록 하는 것인데, 좀더 나아간다면 자동화된 밸런스 테스트까지도 실시간으로 이루어질 수 있으면... :)

 

이를 위해서는 각종 접근 제어 및 암호화와 보안 관련 작업이 선행되어야 할 듯.

 

3. 데이터 주도적인 게임 설계

 

온갖 게임 관련 서적에서 항상 주장하던 유명한 명제.

 

그네들도 다들 피를 봤기 때문에 그런 말을 하는 것이리라. 손쉬운 수정, 손쉬운 테스트, 손쉬운 기능 추가... 더이상 말하지 않아도 다들 잘 이해할 것이다.

 

주의할 것은, 기획팀에서 아예 손쉽게 수정할 수 있는 툴을 제공하라고 처음부터 전방위 압박 공격을 해야지 개발 후반부가 편해진다는 거다. 너무 이해하다가는 서로서로 피곤해지니, 기획팀과 프로그램팀이 힘을 합해 PM과 경영진에게 툴 개발 스케줄을 따내는 것도 좋은 방책일 듯. ㅋㅋㅋ

 

----

 

"구현 신경쓰지 말고, 밸런싱이나 잘해요!" 라고 맞받아치던 후배의 한마디를 아직도 잊을 수가 없다. 이놈의 원죄는 언제쯤 씻겨질 것인가...