어디까지나 개인적인 경험에 비추어 이야기 하는 것임에 유의하세요.
***
최근에는 모발일 게임 개발이 늘어나고, 그에 따라 프로젝트 인원이 줄어들면서 기획자도 데이터(DB)를 관리하는 경우가 늘어나고 있습니다.
테이블은 시스템의 유연성이 스크립트 방식보다는 떨어지지만 관리가 편하다는 장점 때문에 많이 쓰이고 있습니다.
웬만한 기획자들도 쉽게 데이터를 조작하고 조절할 수 있게 되는 것이죠.
그래서인지 테이블 구조를 짜는 것도 나름 중요해졌습니다.
잘못 빠졌다가는 인당수에 몸을 던질 정도로 현질하게 된다는 그 게임.
요즘 확산성 밀리언 아서가 꽤 인기인 듯 합니다.
이번의 설명을 위해 확밀아의 전투 시스템 구조를 간추려서 역기획해보았습니다.
자, 이 구조만 짜고 끝이냐?
그렇지 않죠.
이 구조 안에 또 구조가 있습니다.
바로 카드의 테이블 구조입니다.
***
아무리 멋지고 기능적인 부엌이 갖춰졌다고 해도 재료가 없으면 아무 요리도 못 만드는 것과 마찬가지로, 카드 데이터가 들어가야 비로소 저 구조가 작동할 수 있는 것이죠.
자 그럼 저기에 들어갈 데이터는 어떤 구조로 만들어야 할까요?
결론부터 말하자면...
정답은 없습니다.
여기서부터는 시스템 기획자의 센스와 융통성이 발휘되어야 할 부분입니다.
일단 예시를 들죠.
아래의 테이블은 카드의 일부 데이터만 나름 정리한 것입니다.
실제로는 더 많은 데이터들이 있겠지만 예시용으로 이름, 공격력, 체력, 기간, 배수 정도만 추렸습니다.
Ex1) 현재와 가장 가까운 형태
아마도 현재 확밀아 게임과 가장 유사한 형태라 생각됩니다.
기간의 날짜까지 숫자에 적힌 배수가 적용되는 형태입니다.
Ex2) 배수 기간 확장형
배수에 컬럼을 추가하였고, 각 컬럼에 날짜를 입력하게 했습니다.
이런 식으로 테이블을 변경할 경우 각각의 4배수, 3배수, 2배수에 날짜를 입력하여 13년 6월 31일까지 4배수였던, 카드가 기간이 되면 3배수, 2배수로 줄어들며 서서히 약해지는 기능 추가가 가능합니다.
또한 이름 앞에 ‘분류’가 추가되어 ‘분류’와 ‘이름’으로 나누어졌습니다.
이러한 구분을 통해 카드를 분류별로 정리해서 보는 기능을 넣을 수 있게 됩니다.
Ex3) 테이블 연결형
보통 한 테이블로 끝내지만, 카드에 엄청나게 많은 기능들을 넣고 싶을 경우 다음과 같이 테이블을 따로 만들어 버리는 수가 있습니다.
저 코드를 따라가면 앞의 테이블과 같은(또는 더 기능이 많은) 테이블이 연결되어 그곳의 데이터를 받아들이게 됩니다.
기능을 확장하기는 좋으나, 이런 형태는 필연적으로 2개 이상의 테이블을 조작하게 되어 관리가 불편해집니다만,
카드가 웬만한 RPG캐릭터 이상으로 데이터가 많을 경우에는 오히려 이런 형태가 나을 수도 있습니다.
***
이렇게 같은 데이터라도 어떤 방식으로 테이블을 짜느냐에 따라 게임의 융통성과 확장성이 늘어나게 됩니다.
물론 관리하는 사람의 편의성도 마찬가지.
때문에 시스템 기획자는 게임에 따라 적절한 테이블 구조를 만드는 것도 중요합니다.
부득이하게 테이블 구조가 적절하지 않을 경우 수정이나 추가가 가능하긴 합니다.
다만 프로젝트가 진행되면 진행될수록 수정할 때는 드는 작업과 테스트가 많아져 야근야근한 상황이 펼쳐질 가능성이 높아집니다.
개인적인 생각이지만,
프로그래머보다는 아무래도 게임의 의도를 많이 접하게 되는 기획자가 이러한 것을 짜는 것이 이치에 맞다고 생각합니다.
***
스크립트 방식은 솔직히 말해 기획적으로 딱히 설명할 거리가 없어 간단하게 넘어가겠습니다.
회사마다 스크립트가 다르고 함수가 다를 수 있으나
기본은 대충 이런 형식입니다.
어떠한 기능을 넣겠다고 프로그래머에게 전달합니다.
프로그래머는 그 기능을 작동시킬 수 있는 함수를 만들어 줍니다.
그 함수를 가지고 스크립트를 작성합니다.
이미 함수들이 만들어져 있을 경우, 한 일주일 정도 시간을 들여 작성법을 배웁니다.
WOW의 매크로가 일종의 스크립트 언어입니다. (LUA)
하드코딩한 방식이죠.
하나의 구조와 데이타를 프로그래머처럼 일일이 작성할 수 있어,
유연성 있게 기능들을 추가할 수 있으나 다루기가 불편하고,
유연하게 작성할 수 있다 해도 결국은 평소 자주 쓰는 기능만 쓰는 경우가 많아 요즘에는 엑셀에 VBA 등을 활용하여 스크립트를 테이블화 시키는 경우도 많습니다.
한 번 정도는 써보는 것도 나쁘진 않으나 이걸 주력으로 하면 다른 기획일을 하기가 힘들어집니다.
아무래도 작성과 테스트에 시간을 많이 빼앗기기 때문이죠.
상당히 프로그래머 친화적인 방식입니다.
***
이번에는 달리 정리할 거리가 없군요.
게임에 따라 적절하게 테이블을 짜라.
스크립트는 해당 회사에서 요청하거나 배우면 된다.
정도네요.
