• 2004-11-24

    데이터 주도적인 게임 설계

    예전에 이런 일이 있었다

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

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

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

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

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

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

    그리고는 깨달음을 얻었다

    밸런싱툴을 제공할 것

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

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

    다양한 콘솔 명령어들을 제공

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

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

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

    데이터 주도적인 게임 설계

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

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

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

    맺음말

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

  • 2004-11-24

    CPB

    • Windows 환경에서 PDB 파일에 저장된 심볼을 DIA SDK 를 이용해서 접근, 루아 스택에 바인딩해주는 라이브러리.
    • 코드를 수정하지 않아도 lua 레벨에서 원하는 변수에 접근해서 수정하는 것이 가능하다.
    • tweaking 라이브러리가 필요하다면 강력 추천!
    • namespace 지원 안함. 즉 std:: 시리즈나 namespace 안에 있는 변수들은 바인딩 불가. (version 006)

    see also:

  • 2004-11-24

    Code Review Tips

    당신의 프로그램이 다운된다면, 혹은 메모리 누수가 심하다면 다음과 같은 룰을 기반으로 코드를 리뷰하라. 이때, 코드 작성자가 아닌 다른 프로그래머를 항상 옆에 대동하면 버그를 찾을 확률은 200% 증가할 것이다. (사실 이건 내부 자료인데 몰래 공개하는 것이다. 헤헤)

    • 상속 관계의 베이스 클래스에 virtual destructor 를 선언했는가?
    • 배열 포인터를 delete[] 로 삭제하는가?
    • delete:Wh*[]으로 정규식 검색을 하면 편하다.
    • 배열이 아닌 포인터를 delete[] 로 삭제하는가?
    • memcpy(), memset(), memmove(), strcpy() 메모리 관련 함수들의 BoundCheck가 잘 되어 있는가?
    • 배열을 인덱싱할 때 파라미터의 BoundCheck 가 잘 되어 있는가?
    • 다른 peer 로 부터 넘어온 모든 정수형 파라미터에 대한 BoundCheck가 잘 되어 있는가? (특히 문자열 길이에 유의)
    • STL string 을 사용한다면, %s 포맷팅할 때 c_str() 을 사용하는가?
    • Singleton 이나 STL 컨테이너에 대해서 2개 이상의 쓰레드가 동시에 읽기/쓰기 모드로 접근하는 경우 lock 을 걸고 있는가?
    • 사용하지 않는 copy constructor, assignment operator 가 private 로 선언되어 있는가?
    • 포인터 멤버를 가진 객체를 복사할 때 assignment operator 를 재정의했는가?
    • Warning Level 을 4 로 높인 다음 컴파일해봤는가?
    • 초기화하지 않고 사용하는 변수(또는 클래스 데이터 멤버)가 가장 위험하다.
    • try ~ catch( ... )은 절대 사용하지 말라. SEH Exception 까지도 캐치해버린다.버그를 숨겨서 더 큰 버그를 만들 뿐이다.
    • set_se_translator() 를 쓰지 마라. 쓰레드 로컬이라, 매 쓰레드마다 해줘야 한다. SetUnhandledExceptionFilter()는 프로세스 글로벌이다.

    see also:

  • 2004-11-24

    MMORPG 밸런싱은 너무 힘들어요

    부끄러운 이야기이지만 한때 MMORPG 기획물을 먹을 때, 공식 혹은 비공식적으로 밸런스를 더이상 하고 싶지 않다고 선언한 적이 있습니다. 꿈 많은 기획 초보에서 일년만에 타락한 실패한 기획자가 된 거죠. 알게 모르게 욕도 많이 먹었습니다. 대놓고 실력없다고 욕먹은 적도 있습니다. 그 암울했던 시절의 밸런싱 스토리를 한번 풀어내보겠습니다.

    완벽한 밸런스?

    모든 유저들의 마음에 쏙 드는 리밸런싱은 있을 수 없다. 그러나, 가장 많은 유저들이 만족한다면 그게 바로 제대로 된 밸런스다.

    기술이 추가되거나, 전투 공식이 수정되거나, 몬스터 배치가 바뀌거나, 아이템 가격이 변동되면 분명히 누군가는 불만을 토로하게 되더군요. 그 누군가가 게임 내에서 길마 등 일정 지위(--)에 도달해 있거나, 덕망(--)이 높거나, 사장과 안면이 있거나, 게시판 글발이 좋을 경우 후폭풍이 무조건 몰아치더라구요.

    물론 개발팀 특히 기획팀이 최선을 다하지 않아서 그랬겠지만, 결국 불쌍한 운영팀만 욕을 먹게 되더군요. 결국, 패치 후 필연적으로 발생하는 유저들의 불만을 눈가리고 아웅하기 위해, 불쌍한 기획자와 운영자들은 다음과 같은 얍삽한 노하우를 얻게 되었습니다.

    • 모든 아이템의 가격은 시간이 흐름에 따라서 점차 떨어져야 한다
    • 모든 기술의 MP 소모량은 시간이 흐름에 따라서 점차 줄어들어야 한다
    • 동일 레벨의 필요경험치는 시간이 흐름에 따라서 점차 줄어들어야 한다
    • 동일 레벨의 육성 시간은 시간이 흐름에 따라서 점차 짧아져야 한다
    • 모든 제한 요소는 시간이 흐름에 따라서 점차 완화되어야 한다

    즉, 어떤 새로운 기능이 들어갈 때 페널티 관련 파라미터들은, 이후 플레이어들의 비난을 감안해서, 약간 높게 책정되어야 한다는 건데요, 처음부터 적정 수준을 잡았다가 플레이어들이 시위를 할 경우 더이상 낮추다간 큰일나게 되기 때문입니다.

    이런 식의 데미지를 한번이라도 입어봤던 분들은, 요즘도 종종 이런 이야기를 합니다.

    일단은 이정도로 하고 분위기를 봐서 낮추든가 합시다
    

    아무도 믿지 말라?

    이 부분에 대해서는 제 잘못이 아주 큽니다. 왜냐하면, 기획자라는 넘이 캐릭터를 처음부터 끝까지 키워보지 않았기 때문이지요. 아무튼, 게임이 어떻게 돌아가는지, 요즘 플레이어들의 불만이 뭔지, 스스로 상황 파악이 안되고 주위 사람들에게 불평 불만을 들어야만 아는 상황이었으니... 이사람 말에 솔깃, 저사람 말에 갸웃하게 되는 지경이었습니다.

    그러다가, 열혈 플레이어였던 사장 운전사의 피를 토하는 한마디!

    "아.. 캐릭터 키우기가 너무 힘들어. 지금 다들 게임을 접으려고 하고 있단 말이야. 길마들 다 난리야!!!"

    이 말을 듣고, 한쪽 종족의 성장 곡선을 완화시키는 패치를 내보냈더랍니다. 그 결과는... 다들 짐작하시겠지요. 그 이후, 열렙하는 개발자들의 하소연은 30-40% 허풍으로, 플레이어들의 게시판 이야기는 70-80% 과장으로 인식하게 되는 병을 얻었습니다. 게임 자체가 종족간 대립 구도를 채택해서 이런 불신증상은 더했다는... 웬만한 불만은 무시하고, 게시판에서 호소력이 있는 명문을 발견하거나, 여러 명한테서 동일한 불만을 듣게 되면, 보완 작업에 들어갔습니다.

    그나마, 이쪽 저쪽 불만을 모두 접하는 운영팀의 이야기가 가장 중립적이었습니다. 그치만, 자기 캐릭을 키우는 넘은 또 그게 아니더군요.

    제가 좀더 많이 플레이를 했더라면 충분히 막을 수 있었던 실패담이지만, 웬지 모르게 그게 안되더군요. 다들 저보고 제발 플레이좀 해보라고 이야기하곤 했지만, 그냥 한귀로 흘려버렸다는.... (물론 다들 속으로 정말 답답해하고 어떤 사람은 욕도 많이 했겠지요) 프로페셔녈이라면 절대 그럴리가 없었겠지요. 자기가 만든 게임에 대한 애정 부족! 그때 저때문에 피보신 많은 분들께 여기서나마 잠시 사죄를 드려봅니다.

    밸런싱에 대한 주관적인 접근(X)

    사실 이게 본론이 되겠습니다. 사실 나리티님의 글에서 나온 목록중에서 많은 부분에 대해서 고민을 안해본게 아닙니다만, 그런 데이터 수집 활동이 너무 주관적이며 신용도가 낮다는데 문제가 있습니다. 결론부터 말하자면, 플레이어들의 게임 플레이에 대한 로그 분석 활동이 기획자들의 주요 업무가 되어야 한다는 거구요. 그에 따른, 프로그래머들의 서포트가 있어야 한다는 겁니다. (라기보다는, 아예 초기 개발 시점부터 기획팀에서 이후 조사를 위한 필요 데이터를 명시한 기획서를 넘기고, 프로그램팀에서 관련 데이터를 가공하기 쉽도록 DB에 남긴다..가 되겠네요)

    지금 참가중인 프로젝트에서도 이런 부분이 너무 미숙해서, 회의에 들어가면 대체로 주관적인 평가들을 많이 하곤 합니다. 더군다나 퍼블리셔에서 누군가가 한마디한 것들이 점차 증폭되어 정말 진리인양 개발팀으로 흘러 들어오는 걸 보고 있노라면.. 으..

    • 게임이 어려워서 동접이 늘지 않아요.
    • 처음에 몇 번 해보고 다들 접어요.
    • 유저중 절반이상이 어느 수준에서 게임을 포기해요.
    • 하다보면 자꾸 튕기고, 짤려요.

    분명히 이런 부분은 데이터를 가지고 객관적으로 접근해야 하는 것임에도 불구하고, 다들 너무 즉흥적이면서 주관적으로 접근하는 경향이 있더군요. 처음부터 이런 부분을 감안하고 데이터를 남겨놓지 않으면, 정작 필요할 때 문제의 원인을 파악하기 힘든 경우가 많은데... 그렇다고 특별한 지시 없이도 알아서 필요 데이터를 잘 축적해주는 프로그래머는 드물지요.

    그렇다고 데이터 만능주의로 흐르다가는 게임의 본연의 모습을 잃어버릴지도 모르겠네요. 가령, 플레이 시작후 일주일만에 총 신규가입자의 10%가 떨어져나가는데 이 원인은 20레벨에서 25레벨의 경험치가 너무 많아서 그런게 아니라 퀘스트의 복잡도가 너무 높고 플레이 시간이 길어져서 중얼 중얼중얼... 퀘스트를 하루에 1.5개 이상 주어지고 초보들의 소지금액을 현재의 20%로 증가시키기 위한 대책안을 마련해서 중얼 중얼... 물론 비지니스로의 가치는 충분하겠습니다만.

    시스템 디자인 시점에서도 분명 나리띠님의 글처럼 안배가 되어 있어야 하겠지만, 과연 그게 원안대로 잘 적용되고 있는지, 플레이어들이 만족하고 있는지를 파악하려면, 테스트 시점이나 오픈 이후에도 분명 데이터 분석을 통한 사후 검증 및 개편작업은 필연적일 것입니다.

    결론 : 데이터 마이닝(?)

    전개가 좀 산만했네요. 억지로 정리를 해본다면, 완벽한 밸런싱이라고 하는 것은 다른 사람이나 자신의 주관적 판단보다는 객관적인 데이터를 토대로, 다수 플레이어들의 불평불만(?)을 가지치기하듯 최소화한다. 라고 우길 수 있겠습니다.

    DB 전문인 후배에게 물어보니, 다들 한번쯤 들어봤을 데이터 마이닝이나 OLAP 등의 분야가 이런 부분을 다루는 거라고 하네요. 단순한 데이터에서 의미를 마이닝(mining)해내어 트렌드를 찾아내고 정책을 결정하는 거라나요? 맨 위의 그림을 보면 대충 무슨 의미인지는 아시겠습니다만.

    큰 회사라면 몰라도, 고만고만한 작은 회사들에서는 이런 부분을 제대로 갖추기가 힘들지 않을까 합니다. 우선 무엇을 저장할지를 골라주는 경험많은 기획팀과, 어떻게 저장할지를 결정해주는 DBA, 그리고 데이터를 분석해서 적절히 플랜을 작성할 마케팅 담당자가 필수적이겠습니다. 물론, 프로그래머는 당연히 시키는 데로 데이터를 DB로 넘겨야죠.

    물론 지금도 많은 회사들은 접속 회수와 시간, 지역/성별/나이별 통계 자료, 시간대별 분포도 등을 기반으로 마케팅 플랜을 작성하는 곳은 많겠습니다만, 게임 내부적인 수많은 파라미터들을 남겨서 이후 리밸런싱에 활용하는 회사는... 글쎄요 NCSoft 라면 아마 그렇게 할지도 모르겠습니다.

    KGDA의 어딘가에서 본 글처럼, 아무래도 한국에는 이를 제대로 할 줄 아는 개발자가 많지 않은 듯 합니다. 이게 개발자가 알아서 해야 할 일은 아니겠지만요.

    그나저나, 이렇게 결론지으면 뭐하나요? 동접이 늘어나질 않는데... ㅠㅠ