You are here: Home - Author: admin

Author

  • 실베스타

    “그런 썩어빠진 근성, 내 300마력 교정펀치로 수정해 주겠어!”

    푸른돌 조사단(이하 푸돌단)은 시장에 출시되어 있는 다른 컬렉션&배틀 게임들과 궤를 달리하는 요소들이 수없이 많은데,그 중에 하나는 남자들의 말초신경을 자극하기 위해 너나 할 것 없이 전면에 내세우는 미소녀 카드게임들의 홍수 속에서 벗어나있다는 점입니다.

    피쳐폰 시절부터 하얀섬 시리즈와 함께 디바이스와 장르를 넘나들며 이어지고 있는 ‘비욘드 더 바운즈’라는 거대한 세계관 안에서 캐릭터 하나하나가 살아 숨쉬며 각각의 이야기를 만들어가고 있으며, 푸돌단에서는 그 등장인물들이 카드의 형태로(카드라 쓰고 조사단이라 읽는다)표현되고 있는 것입니다. 그렇기 때문에 남녀노소, 각양각층의 다양한 조사단들이 등장하고 있는데 여러 개성 강한 동료들 중 이름으로만 치자면 지상최강의 생물이라고 할 수 있는 할아버지가 있습니다.

    바로 ‘실베스타 슈왈제네거’옹 입니다.

    왕년에 어마어마했던 백전노장의 할아버지가 기획되어 러프디자인이 먼저 나왔었고, 네이밍작업 당시 ‘제이슨 스ㅇㅇ’, ‘장 끌로드ㅇㅇ’, ‘웨슬리 ㅇㅇ입스’등이름만으로 상대를 압도할 것 같은 포스 넘치는 캐릭터를 떠올리다 스탤론형과 아놀드형을 조합했더니 가히 범접할 수 없는끝판왕격의 이름이 나와버렸습니다.

    상당히 만족스러운 이름이 지어지고 나자 일러스트 작업은 탄력을 받기 시작했고, 진화형에서는 더 나이가 들어 머리숱은 많이 없어졌지만더욱 인생의 연륜이 뭍어나는 고혹(?)적인 자태를 뽐내게 되었습니다. 마치 화룡점정과 같이 진화형의 이름에는 그 앞에 ‘척’이라는 글자가 붙어더 이상의 자세한 설명은 생략해도 될만한 궁극의 할베가 탄생하게 된 것입니다.

    만족스럽게 즐기면서 작업한 캐릭터라서인지, 이 할베는 푸돌단에서 귀하디 귀한 라이벌 이벤트 캐릭터에 등극되고 한 커뮤니티에서는 긴급 서버점검 당시 어느 유저의 팬픽에 등장해 향년 81세의 일기로 운명하게 됩니다.

    비록 확밀아의 ‘멀린’과 같이 널리 알려진 할베는 아니지만 기획-찰진네이밍-바이럴의 3박자를 맛 본 애착이 가는 캐릭터로 기억에 남습니다.

  • 여러분 안녕하십니까? 인턴마스터 인사 드립니다.
    아직은 여러분들께 말씀 드릴 수 없는 프로젝트를 열심히 개발하다 보니 어느새 또 일주일이 흘렀네요.
    머지 않아 이 프로젝트에 대해서도 말씀 드릴 수 있을 때가 오겠지요.

    이번 시간엔 그 이름도 화려한! ‘비주얼샤워 티셔츠’에 대해서 알아보도록 하겠습니다.

    ‘수식어가 화려한 비주얼샤워 티셔츠’… 하얀섬을 해 보셨다면 한번쯤 보신 적이 있으실 텐데요.
    이 티셔츠가 비주얼샤워의 어드벤처 타이틀에 단 한 번도 빠짐없이 등장했었다는 사실!
    또한 단순히 게임 속의 이미지만이 아닌, 실제로 존재한다는 놀라운 사실! 여러분은 알고 계셨나요?

    역사와 전통이 살아 숨쉬는 비주얼샤워 티셔츠, 지금 바로 만나 보시겠습니다!

     

     

    3화_1

     

    3화_2

     

    3화_3

     

    3화_4

     

    3화_5

  • bombclock234

    푸른돌 조사단 서비스 초기, 유저 수가 늘어나면서 데이터베이스 서버의 부하 문제가 생기게 되었습니다.
    CPU 점유율이 특정 퍼센트를 넘어가면 경고 문자를 받았는데, 하루에 100통 정도 받은 경우도 있습니다. (제가 본 것중 최대치는 96%였습니다…)
    언제 서버가 다운되더라도 이상하지 않을 상황이었습니다.

    그래서 가장 빠르게 이 문제를 해결하기 위해 DB 서버의 스펙을 거의 2배로 업그레이드 했지만 이런 임시방편으로는 한계가 있을 수 밖에 없었고, 며칠 지나지 않아 또다시 문자를 받는 상황이 되었습니다.

    결국 서버의 근본적인 문제를 해결 해야 하는 상황이 되었고, 원인을 찾다보니 실시간으로 유저의 랭킹 구하는 부분이 정말 너무도 용감하게 구현되어 있는 것을 확인하였습니다.

    점수에 따라 정렬을 하고, 그중에 원하는 유저가 어디에 있는지 차례대로 등수를 매겨가며 찾는 방식이었습니다. 간단한 등수를 구하기 위해 DB를 너무 혹사 시키고 있었던 겁니다.

    허나 REDIS라는 in-memory dataset을 사용하면서 이 문제가 해결 되었습니다.
    REDIS에서 제공하는 sorted-set을 활용하면 랭킹을 쉽고 빠르게 구할 수 있습니다.
    zadd라는 명령어로 유저의 ID와 점수를 넣어두면 내부에서 점수에 따라 정렬된 상태로 유저 ID를 저장하게 됩니다.
    그럼 zrevrank라는 명령으로 해당 유저가 내림차순으로 몇번째인지 쉽게 알아 낼 수 있습니다.
    이런 일련의 과정이 메모리에서 처리 되기 때문에 접근이 굉장히 빠르고, 부하도 많이 줄어 들었습니다.

    REDIS 도입하고, 유저 수는 더 늘었지만 DB 서버의 CPU 점유율은 10% 대를 유지하는 쾌거를 이루었답니다.
    그리고 랭킹 리스트를 보여주는데 10초 남짓 걸렸던 것이 1초 안에 처리되었습니다.

    이렇게 여유가 많이 생겼지만, 업그레이드 했던 DB 서버는 아직 그대로 사용하고 있습니다 :-)

    by Justin Hwang

  • [인턴마스터의 불꽃 개발비화] 두번째 이야기

    하얀섬은 어떻게 만들어졌을까요? 비욘드 더 바운즈의 제목의 유래는?
    네박자 쿵짝은 왜 원숭이가 공을 던지고 참치 배트를 휘두를까요?

    유저들에게 완성도 있는 게임을 전달하기 위해 개발 과정에서 수없이 컨펌당해 스러져간 아이디어와 시안, 미련들…

    이에 개발자들의 한을 담아 저 인턴마스터가 그 동안 알리지 못한 개발 비화를 마침내 여러분들께 공개합니다.

    ————————————————————————————————

    오랜만입니다! 다들 일주일간 잘 지내셨나요?

    첫 번째 시간에 이어 오늘도 화이트 아일랜드 이야기로 엮어보고자 합니다.

    지훈, 재욱, 서현, 해선, 진아… 주인공들이 헤매고 다니던 각종 장소들은 어떤 과정을 거쳐 만들어졌을까요?

    지훈루트 챕터 0에 등장하는 거문도 씬을 예시로 들어 그 과정을 따라가 보도록 하겠습니다.

     

    2화_1

     

     

     

    2화_2

     

     

     

    2화_3

     

     

     

    2화_4

  • IsaacSulcata

     

    소스 버전 관리는 개발에 없어서는 안 되는 주요한 항목입니다. 저희는 이전에 계속 소스세이프를 사용하다가 푸른돌조사단 프로젝트를 진행하면서 svn을 본격적으로 도입하게 되었는데, 이 과정에 대해 얘기해보는 것도 재미있을 것 같아 글을 쓰게 됐습니다.

    소스세이프는 사실 평이 좋지 않은 버전 관리 툴이기 때문에 소스세이프를 계속 사용했다는 것에 대해 의문이 있는 분들이 꽤 있을 것입니다. 여기에는 몇 가지 이유가 있었는데요. 먼저 비주얼스튜디오에 통합하여 사용할 수 있는 툴이라는 점이 이유였습니다. 하지만 이것만으로는 사용 이유가 충분치 않을 것입니다. 이미 비주얼스튜디오에 플러그인을 설치해서 svn을 사용할 수 있기 때문이지요.
    그렇다면 다른 이유를 들어봐야겠지요. 그것은 branch 같은 기능을 지원하지 않는다는 점 때문입니다. 모두들 이 점을 단점으로 생각하시겠지만 소스세이프는 이런 기능이 없기 때문에 오히려 굉장히 사용방법이 단순하지요. 그래서 그래픽 디자이너도 사용하기에 큰 무리가 없는 수준입니다. 그래픽 작업물들도 히스토리 관리를 하고싶은데 그렇다고 svn의 개념을 프로그래머가 아닌 다른 팀에게 학습시키는 것은 오버헤드이고 또 그렇게 해도 잘 관리되기가 어려울 것입니다. 그리고 여기에 덧붙여 프로젝트의 크기가 대체로 크지 않아 주로 한 명의 프로그래머가 하나의 프로젝트를 담당하게 되는만큼 branch를 만들게 될 필요성도 크지 않았습니다. 오히려 기능이 적은 것이 적합하다고 판단되었기에 소스세이프를 선택한 것이지요.

    하지만 점차 프로젝트 규모가 커지고 하나의 프로젝트에 참여하는 프로그래머 수가 많아지는만큼 소스세이프로는 한계가 발생하기 시작했습니다. 당시 네박자쿵짝을 개발하던 쯤이었는데 이 때에 처음으로 svn 도입을 하게 되었습니다. 그래픽 디자이너나 레벨 디자이너들은 기존대로 소스세이프를 사용하고, 프로그래머들만 svn으로 migration하는 방향으로 진행하였습니다. 하지만 결과적으로 도입에 실패하였고 프로그래머들도 다시 버전 관리를 소스세이프로 하는 것으로 돌아왔습니다. svn 사용법이 익숙치 않은 데다 프로젝트 관리 규칙을 미리 합의하지 않고 들어간 것이 문제였습니다. 프로젝트 히스토리를 잘 관리하기 위함이 목적이었는데, branch가 중구난방 네이밍도 제멋대로이니 오히려 히스토리를 쫓아가기가 버거웠습니다.
    그러다가 푸른돌조사단 개발에 들어가면서 다시 svn 도입에 대한 필요성이 제기되었고, 이번에는 규칙을 잘 정하고 시작해서 이전과 같이 히스토리 관리가 엉망이 되지 않도록 하자고 얘기가 되었습니다. 그래서 이에 대한 논의를 시작하게 되었고, 중요한 방침 두 가지를 정했습니다.

    첫째, 어느 피씨에서든 svn을 세팅하기만 하면 쉽게 프로젝트의 빌드가 가능한 상태가 될 수 있도록 하자.
    둘째, 버전 히스토리를 추적하기가 용이하게 하자.

    이를 가지고 잡았던 구조는 대략 이랬습니다.

    Projects (프로젝트 루트 폴더)
    -+ 프로젝트A
    —+ trunk
    —–+ Source
    ——-+ Client
    ——-+ Server
    ——-+ Resource
    —+ branches
    ——-+ 브랜치명A
    —+ tags
    -+ …
    Common (라이브러리 루트 폴더)
    -+ 라이브러리A
    -+ …

    일반적인 svn 사용법처럼 프로젝트 하위에 trunk, branches, tags를 만들었습니다. 여기서 trunk 폴더의 하위를 보면 Source라는 폴더가 하나 끼어있습니다. 이렇게 depth를 하나 추가한 이유는 프로젝트의 branch를 만들 때에 브랜치명으로 폴더가 하나 만들어지면서 depth가 하나 늘어나게 되는데, 이로 인해 프로젝트에서 참조하는 라이브러리의 상대 경로가 trunk와 branch에서 달라지는 경우를 방지하기 위해서입니다. Source 하위에는 Client, Server, Resource의 폴더를 나누었습니다. 리소스 파일을 다른 곳에서 관리하면 관리가 이원화되어 빌드에 문제가 생길 것으로 여겨져 Resource 폴더도 추가하게 되었습니다. 그래픽 팀이나 다른 팀의 작업물까지 svn으로 관리하기는 버거우니 프로그램에서 런타임에 사용하는 바이너리 파일만을 업로드하기로 했습니다.
    이 방향으로 잡고 관리를 시작했고 trunk만 사용 중일 때에는 특별한 문제가 없었습니다만, branch를 만들게 되면서 문제가 생겼습니다. svn 루트 폴더를 통째로 받기만 하면 프로젝트를 빌드할 수 있게 하자는 것이 목적이었는데, 프로젝트 루트 폴더를 갱신하면 프로젝트의 branch들까지 모조리 받게 되니 branch가 하나씩 늘 때마다 같은 프로젝트를 여러 개 복사해서 받는 꼴이니 괜한 시간이 허비되는 것이었습니다. 그래서 아래 방향처럼 바꾸게 되었습니다.
    ProjectBranches
    -+ 프로젝트A
    -+ …
    Projects
    -+ 프로젝트A
    —+ Client
    —+ Server
    —+ Resource

    Common
    -+ 라이브러리A

    -+ …
    trunk, branches, tags의 폴더를 사용하는 것이 널리 쓰이는 방식이지만 꼭 따를 필요는 없으니, 각 프로젝트에서 branches 폴더를 떼어내고 branch만을 관리하기 위한 상위 폴더를 만들었습니다. tags 폴더는 사실상 사용하는 경우가 없어 지워버렸습니다. svn 가장 상위에서 Projects는 trunk 같은 역할, ProjectBranches가 branches 같은 역할을 맡도록 한 것입니다. 그리고 ProjectBranches 폴더는 따로 받지 않고, 필요한 경우 Projects의 폴더에서 switch를 하는 식으로 사용하기로 했습니다. 아무래도 branch를 전부 받게 되지 않기 때문이었습니다. branch를 전부 받지 않게 되다보니 depth를 맞추기 위해서 억지로 끼워 넣었던 Source라는 불필요한 폴더도 삭제하게 되었습니다.
    branch 폴더를 분리하고나니 좀 더 사용이 수월해져 한동안 잘 사용을 했습니다. 하지만 시간이 지나고나니 서버 프로그래머에게 불편한 점이 생겼습니다. 클라이언트 프로그래머인 저는 개발을 진행하면서 계속 로컬 파일이 최신으로 업데이트 되지만, 서버 프로그래머가 간만에 클라이언트 프로토콜을 확인하려고 프로젝트를 업데이트하면 변경된 리소스까지 왕창 받아오게 되었습니다.
    그리고 리소스의 바이너리 파일을 관리하는 측면에서 또 다른 종류의 불편함이 있었습니다. 그래픽 디자이너나 레벨 디자이너가 작업물을 만들고 빌드에 포함시키기로 확정이 되면 프로그램에서 사용하는 바이너리 파일로 변환을 하는 작업까지 마치게 되는데, 이를 업로드하려면 항상 프로그래머를 거쳐야 하는 것이지요. 그러다보니 다른 팀에서 작업물을 빌드에 반영하는 것이 누락되는 과정이 빈번히 생기고, 빌드를 하는 날이면 프로그래머는 야근을 하게 되는 것이 반복되었습니다.
    소스코드가 들어간 프로젝트 폴더만을 받고 싶은데 리소스까지 왕창 받아오는 문제, 그리고 리소스 파일 업로드를 프로그래머를 거쳐야하는 문제를 해결하기 위해 Resource 폴더도 상위로 빼내고 이 폴더는 그래픽 디자이너나 레벨 디자이너들이 업로드를 하고, 프로그래머는 update로 받아오도록 다시 관리 구조를 바꿨습니다.
    ProjectBranches
    -+ 프로젝트A
    -+ …
    Projects
    -+ 프로젝트A
    —-+ Client
    —-+ Server
    -+ …
    Resources
    -+ 프로젝트A
    —-+ 그래픽리소스
    —-+ 레벨링데이터
    —-+ …
    -+ …

    Common
    -+ 라이브러리A

    -+ …
    프로그램 팀이 아닌 다른 팀에서는 svn을 사용하지 않도록 하려 했으나, 빌드 리소스 관리에 문제가 지속적으로 발생했고 어차피 리소스 파일들도 히스토리가 관리되어야 할 거면 이미 잘 만들어진 툴인 svn을 사용하는 게 좋겠다는 생각이 들었습니다. 그리고 svn을 통해 업로드한 파일은 CDN 관리 서버에서도 받아올 수 있고, 빌드 자동화 서버에서도 스크립트를 이용해 빌드 시에 최신 리소스를 받아올 수 있으니 추가적인 이점도 있었지요. 그래서 그래픽 디자이너와 레벨 디자이너 분들에게 Tortoise SVN을 세팅을 해드리고 지속적으로 사용법을 익힐 수 있도록 서포트를 해드렸습니다. 초반에는 파일 conflict가 발생한다거나 add 해야 할 파일들이 누락되는 등의 문제로 리소스 파일이 제대로 업데이트 되지 않아 푸른돌조사단 컨텐츠 패치 시에 몇 번 문제를 겪기도 했지만, 후에는 담당자 분들의 숙련도가 올라가 패치 프로세스도 안정화 될 수 있었습니다.
    처음 생각했던 것만큼 원활히 진행되지는 않았지만 몇 차례 구조를 수정하면서 처음에 원했던 원칙들인 쉽게 프로젝트를 세팅하고, 버전 히스토리 추적을 용이하게 하자는 목표를 어느 정도 만족할 수 있게 되었습니다. 이전 svn 도입이 실패했을 때와 비교해보면, 단순히 툴에 대한 평이 좋다거나 혹은 주변에서 다들 쓴다거나 해서 도입하는 것이 아니라 원하는 목표나 원칙을 잘 세우고 들어간 것이 이런 차이를 만든 것이 아닐까 합니다. 어떤 일이든 항상 방향성을 잘 잡고 시작하는 것이 중요하다고 느끼게 해준 경험이었습니다.
    by Jake Noah
  • 하얀섬은 어떻게 만들어졌을까요? 비욘드 더 바운즈의 제목의 유래는?
    네박자 쿵짝은 왜 원숭이가 공을 던지고 참치 배트를 휘두를까요?
    유저들에게 완성도 있는 게임을 전달하기 위해 개발 과정에서 수없이 컨펌당해 스러져간 아이디어와 시안, 미련들…
    이에 개발자들의 한을 담아 저 인턴마스터가 그 동안 알리지 못한 개발 비화를 마침내 여러분들께 공개합니다.
    ————————————————————————————————
    오늘은 그 첫 번째 시간으로, 화이트 아일랜드 포스터에 대해 알아보겠습니다.
    게임 포스터가 제작하기 위해 비주얼샤워는 어떤 노력을 기울일까요?
    단 한 장의 포스터가 완성되기 위해 얼마 만큼의 이미지가 시안 단계에서 어둡고 축축한 하드 디스크 밑바닥으로 가라앉았을까요?

    비주얼샤워 스타일팀의 피와 땀이 서린 화이트 아일랜드 포스터 시안들을 최초로 공개 합니다!

     

    1화_1

     

    1화_2

     

    1화_3

     

    1화_4

     

    1화_5

     

    1화_6

     

    1화_7

     

    1화_8
  • SONY DSC
    Strange Love: Game Theory vs. Game Design

    Wed March 27 2013
    Room 3005, West Hall
    Speaker: Frank Lantz at NYU Game Center

    이번 강연은 게임 이론을 간략히 설명하고 이를 게임에 어떻게 적용시킬 수 있는지에 대한 강연이었습니다.

    다들 아시다시피 ‘게임 이론’은 게임 개발과는 전혀 다른 분야의 학문입니다.
    수학에서 파생되었으며 경제학에서 주로 다루는 게임 이론은 표면적으로는 게임을 개발하는 상황과는 거리가 있습니다.
    게임 개발 과정에서 직접적으로 적용되는 이론은 아니죠. 하지만 강연자는 내부적으로 연관이 되어 있다고 생각한답니다.

    강연은 게임 이론을 간략히 설명하는 것으로 시작합니다.
    어떤 사람(또는 그룹)이 무엇인가를 선택을 하는 과정이 다른 사람(또는 그룹)의 선택에 영향을 받는 현상을 수학적으로 분석하는 학문입니다.
    파티 복장을 선택하는 상황에서 자신을 돋보이게 하는 선택은 자신을 제외한 다른 사람의 선택을 고려해야만 하는 것과 같은 상황 같은 것입니다. 모두가 검은 색 옷을 입은 파티에서 혼자 흰색 옷을 입으면 돋보이지만 모두 흰색 옷을 입은 파티에서 흰색을 선택하면 돋보이지 않겠지요.

    간단한 예를 들어봅시다.
    한 사람은 케익을 자르고 한 사람은 잘라진 케익을 먼저 선택하는 상황이라면 자르는 사람(cutter)의 선택은 어떻게 될까요?
    이 답은 명백합니다. 자르는 사람은 무조건 케익을 동일한 크기로 자를 것입니다.
    왜냐하면 서로의 크기가 다르게 자른다면 선택하는 사람이 큰쪽을 선택할 것이 명백하기 때문에 자신의 몫은 작을 수밖에 없기 때문입니다.
    이런 제로섬은 언제나 해결책이 있습니다. 이것을 가리켜 “MINIMAX”라고 합니다.

    실생활에서는 이런 제로섬이 아닌 게임들이 존재합니다.
    치킨 게임 같은 것이죠. – 여기에 세계 평화를 위협하는 유명한 독재자의 사진이 등장했습니다. –
    치킨 게임은 게임을 포기하는 것이 가장 이득인(손해가 가장 적은) 게임이죠.
    게임 자체가 서로에게 손해를 주는 구성인데도 우리는 이러한 게임을 하게 되기도 됩니다.

    죄수의 딜레마는 유명한 이야기죠?
    죄수 두명을 각자 다른 방에서 심문하는데 상대를 배신하고 죄를 인정하면 감형을 해주겠다고 하는 상황 말입니다.
    상대가 배신하지 않고 자신만 배신하면 가장 좋은 상황이 되고 둘다 배신하지 않으면 둘다 배신한 것보다 조금 더 좋은 상황이 되며
    자신은 배신하지 않았는데 상대만 배신하면 최고로 높은 처벌을 받게 되는 상황을 만들었을 때 어떻게 행동할지에 대한 이야기입니다.
    여기에서 게임 이론은 두 사람다 배신할 것으로 기대합니다.
    상대가 자신을 배신하든 안하든 나는 상대를 배신하는 것이 무조건 이득이기 때문입니다.

    이것을 국제 관계에 대입하면 정말로 딜레마가 생깁니다.
    핵을 가진 두 나라가 상대에게 핵 공격을 하는 상황을 위에 대입시켜봅시다.
    두 나라는 모두 상대를 공격하는 것이 무조건 이득입니다. 상대가 공격을 하든 안 하든 자신은 공격하는 것이 무조건 이득이니 말이죠.
    하지만 이렇게 하는 것이 진정한 이득일까요?
    그래서 강연자는 포커가 세계를 구했다고 합니다.

    만일 죄수의 딜레마 상황을 반복적인 상황에 놓는다면 우리는 다른 해결책을 찾을 수 있습니다. Axelrod는 반복적인 죄수의 딜레마 토너먼트 실험을 했습니다. 이 상황에서 재미있는 상황이 발생했는데 가장 성공적인 해결책을 발견한 것인데요, “tit for tat”이라 이름지어진 방법입니다. 처음에는 서로가 서로를 배신합니다. 서로를 믿고 배신하지 않아야 모두 이득을 볼 수 있는데도 말이죠. 여기까지는 위와 같습니다. 하지만 이 게임에서 이기는 방법인 “tit for tat”은 내가 먼저 상대를 믿는 것입니다. 상대가 나를 배신해도 말입니다. 그리고 같은 상대와 다시 한번 게임을 합니다. 이번에도 나는 상대를 믿습니다. 한번까지는 상대를 용서하는 것입니다. 만일 상대가 이번에도 자신을 배신하면 다음은 나도 상대를 배신합니다. 그 후에 상대가 배신하지 않으면 상대를 용서합니다. 이런 식으로 반복하게 되면 상대는 자신이 상대를 배신하는 것이 손해임을 깨닫고 나에게 협조하게 됩니다. 그 후 서로간에 믿음이 형성되면 지속적인 동반 협조 관계가 형성되는 것입니다. – 이렇듯 지속적인 관계에서는 상대방을 먼저 용서하는 것이 중요한 것을 알 수 있습니다. 지속적인 관계에서의 인간 관계가 이와 참 비슷한 것 같습니다. -

    그럼 게임 이론이 어떻게 게임 디자인에 적용될 수 있을까요?

    Legacy : 이것은 포커에 대해 생각하면서 수학, 과학의 가지로써 생겨났습니다. 가능성, 계산, 정보 이론 등 역시 게임(전통적 게임)을 연구하면서 생겨난 것입니다.

    Inspiration : 게임이론은 많은 경험을 생각하며 나왔고 우리는 그것을 뛰어넘을 수 있습니다. 간단하지만 사소하지 않은 역설적인 시나리오를 생각해볼 수도 있습니다.

    Reconciliation : 전통적인 게임의 관점과 반대되는 관점에서 플레이어들간의 관계를 재설정해볼 수 있습니다.

    강연자는 끝으로 논리적인 생각이 재미있는 게임 디자인과 떨어질 수 없다고 말합니다.

    체계적, 논리적으로 게임을 디자인하고 설계하는 이들에게는 필수적인 마인드인 듯합니다.
    일반적인 사람들의 행동 방식을 분석한 게임 이론을 숙지하고 있으면 좀더 체계적인 과금 모델을 설계하고 재미있는 장치들을 설계할 수 있지 않을까요?

  • SONY DSC

    Counterplay and Teamplay in Multiplayer Game Design

    Fri April 1 2013
    Room 134, North Hall
    Speaker: Tom Cadwell at Riot Games

    이번 강연은 counter play와 team play를 재미있게 설계하는 과정에 대한 이야기입니다.
    강연 내용은 전반적으로 리그오브레전드와 같은 게임을 재미있게 만든 요소에 대한 이야기라고 보시면 됩니다.
    개인적으로 평소 Riot Games의 League of Legend를 재미있게 즐겼던지라 기대가 컸습니다.

    먼저 counter play에 관한 이야기입니다.
    짐작하시는대로 1:1의 상황을 재미있게 만들기 위함입니다.
    가능성(Possible), 명백함(Clear), 흥미(Interesting)의 세가지 요소로 나누어 재미를 평가합니다.

    가능성 : 상대의 공격에 반응하는 것이 자신에게 이득이 될 가능성이 있는가 하는 것입니다. 예를 들어 리그오브레전드의 코르키의 Hextech Shrapnel Shells(마법공학 유산탄) 스킬 – 기본 공격력을 올려주는 기본 스킬입니다. 항상 적용됩니다. – 은 상대의 반응이 전혀 의미가 없습니다. 기본 공격은 피할 수 없고 여기에 무조건 적용되기 때문입니다. 그래서 이 스킬은 counter play를 재미있게 설계하는 데 실패한 예입니다.

    명백함 : 상대의 공격에 대해 반응하는 것이 이득이라는 것을 명백히 알 수 있는가 하는 것입니다. 슈퍼마리오에서 fireball이 확실히 눈에 보이는 것이 좋은 예입니다. 우리는 날아오는 fireball을 보고 점프해서 피하는 것이 이득이라는 것을 확실히 알 수 있죠. 그렇기 때문에 우리는 여기에 반응하고 성공한 경우에 재미를 느낍니다.

    흥미 : 원래 버전의 이블린은 상대에게 완전히 보이지 않았습니다. 이것은 너무 극과극이어서 아무도 재미를 느낄 수 없는 상태였습니다. 이것을 상대 플레이어에게 은신 감지를 할 수 있도록 패치했더니 재미가 증가했습니다. 이블린이 가까이 다가가면 보이도록 한 것인데 이 때문에 이블린은 들키지 않도록 숨어다녀야 하고 상대가 약한 순간적인 타이밍을 노려 공격하도록 제한되었습니다. 이로 인해 상대방의 플레이는 이블린이 보이는 짧은 순간의 반응 시간을 얻었습니다.

    이것들을 이용한 다른 예들을 들었는데요.

    가렌의 스킬 중 에너지를 채워주는 스킬이 있습니다. 이것은 언제나 에너지를 채워주는 스킬이었는데 아무런 리액션의 기회가 없기 때문에 공격받지 않는 동안 채워주는 방식으로 바꿨습니다. 가렌을 공격하는 것은 이전에는 이 스킬에 대한 반응이 없었지만 이제는 조금 더 의미가 있게 되었다는 겁니다.

    케이틀린의 Ace in the Hole(비장의 한발) 스킬은 counterplay의 훌륭한 예인데 이 스킬은 한 플레이어를 조준하고 총을 발사합니다. 만약 그 총알의 궤도에 다른 플레이어가 끼어들면 그 총알을 대신 맞아줄 수 있습니다. 이것은 훌륭한 counter play의 예시이자 team play의 예시가 됩니다.

    다음으로 team play에 관한 이야기로 이어집니다.
    counter play와 마찬가지로 3가지의 요소로 나눕니다.

    가능성 : 어떤 능력이 팀플레이의 가능성을 만들어주느냐 하는 것입니다. Twisted Fate의 패시브 스킬(같은 팀이 골드를 좀더 많이 얻게 해주는 스킬)은 팀플레이의 기회을 높여주지 않습니다. 따라서 팀워크를 증가시키지 않습니다.

    명백함 : 팀원이 능력을 이해하고 사용했을 때 알아차릴 수 있는가 하는 것입니다. Nunu의 Blood Boil(끓어오르는 피) 스킬은 팀공격에서 팀원들이 제대로 반응하기에는 적절하지 않은 예입니다.

    흥미 : 어떤 능력이 다양한 팀플레이를 가능하게 하는가 하는 것입니다. 워크래프트의 Death Knight의 Gorefiend’s Grasp 기술은 타겟의 20야드 안에 있는 몬스터들을 한곳에 모으는 기술인데 이것은 팀플레이를 만들 가능성이 생겨 성공적인 예라고 할 수 있습니다.

    강연자는 플레이어가 팀플레이는 매우 즐거운 경험을 줄 수 있다고 합니다. Thresh의 플레이 동영상을 보여 주며 모두에게 박수 갈채를 받았습니다. 굉장한 팀플레이를 보여주었는데요 아래 링크를 확인해보시면 재미 있으실 겁니다.

    Thresh Play

    이렇게 각각의 요소로 체계적으로 나눠서 각 부분을 재미있게 만들려는 노력이 현재의 League of Legend가 재미있는 게임으로 만들어진 비결이 아닐까 싶습니다.

  • SONY DSC
    The Art of Understanding Social and Mobile Players

    Thur March 28 2013
    Room 2008, West Hall
    Speaker: Ben Liu at Pocket Gems

    Pocket Gems, Ben Liu CEO의 강연이었습니다.
    그는 지금이 역사상 가장 게임 제작자에게 좋은 시기라고 합니다.
    플랫폼이 확장되고 있고 사람들은 언제나 게임을 즐길 수 있으며 유저 또한 많아졌으니 말이죠.

    하지만 게임을 만드는 것은 여전히 어렵습니다. 매우 어렵습니다.
    게임을 만들기에 좋은 시기이니 세상에는 게임이 너무 많아 사람들이 우리 게임에 정착하기 쉽지 않다는 것이죠.
    그러므로 유저들이 우리의 게임에 정착하도록 하려면 어떻게 하면 좋을지 많은 고민을 했을 겁니다.

    그는 게임의 요소가 어떻게 작동하고, 작동하는 요소를 어떻게 개선할 수 있을지에 대해 고민해야 한다고 말합니다.
    그러기 위해서는 우선 “게임의 요소” 중 어느 부분에 초점을 맞춰야 할지 알아야 하는데 그것은 “재미(FUN)”과 “열정(PASSION)”이라고 합니다.
    유저가 당신의 게임을 얼마나 재미있다고 느끼는지와 그 게임을 위해 얼마만큼의 노력을 들이는지를 측정해야 한다는 것입니다.
    FUN factor를 측정하기 위해서는 유저가 얼마나 자주 게임에 진입하는지(retention), 한번에 얼마나 오랫동안 플레이하는지(length of session)을 측정하면 된답니다.

    ppt1
    소셜 게임에서의 좋은 예와 나쁜 예.
    왼쪽 그래프에서는 한번 게임을 시작하면 1시간 이상을 플레이하고 자주 게임으로 돌아오는 것을 볼 수 있죠.

    ppt2
    모바일 게임에서의 좋은 예와 나쁜 예.
    (여기서 모바일 게임은 소셜 게임을 제외한 일반적인 게임들을 지칭하는 것 같습니다)

    열정의 측면에서는 무료사용 유저가 과금 유저로 전환되는 비율을 측정하고, 이 게임을 얼마나 추천하는지 알아보라고 합니다.
    유저 스스로 게임을 아낄수록(소중하게 생각할수록) 과금을 한번이라도 할 가능성이 높아지고, 입으로 전하는 비율과 별점을 후하게 줄 거라는 것이죠.

    ppt3

    ppt4
    소셜 게임과 일반 모바일 게임에서 이 표가 기준이 될 수 있습니다.

    물론 이렇게 측정을 하는 것에는 조건이 있습니다.
    소셜 게임의 경우 첫번째 게임에는 모든 요소가 포함되어 있어야 하고 계속 플레이하기 위해 과금할 정도로 첫 플레이에 재미를 느껴야 한다고 합니다. 그리고 유저가 게임을 끝낼 수 있는 계획을 세우라고 합니다.
    모바일 게임의 경우에는 소셜 게임과 같지만 차이점은 게임 자체가 짧고 다음 버전에 대한 힌트가 포함되어 있어야 한다고 합니다.
    또한 우리 게임을 많이 하고 자주 하는 유저에게 보상하라는 내용이 포함됩니다.

    그리고나서 후반부에는 이렇게 바꿨을 때 그래프가 얼만큼 달라졌는지 보여주더군요. 한번 게임을 수정할 때마다 지표가 급격히 바뀌는 것을 보니 경이롭습니다.
    이미 게임을 재미있게 만드는 방법을 초월해 그 다음 모네타이제이션을 체계적으로 설계하는 방법에 대한 강연이었습니다.

  • Analytics for Achieving Mobile Game StartdomAnalytics for Achieving Mobile Game Startdom

    Wed March 27
    302 South Hall
    Bertrand Schmitt at App Annie

    앱애니의 CEO가 직접 발표를 한 세션입니다.
    다양한 측면에서 iOS 및 안드로이드 앱의 성적을 매겼는데요,
    아쉬웠던 점은 digest가 부족했다고 느낀 점입니다. 워낙 간단명료해서 인지는 몰라도 어수선한 데이터들이었습니다.

    App Annie Overview

    앱애니는 현재 마켓 데이터 차트 서비스를 하고 있습니다.
    50년대에는 Nielsen 등에서 TV 프로그램의 서비스의 등급을 매겼고, 90년대에는 comScore 등에서 웹사이트의 방문자 등에 대해 등급을 매겼습니다.
    2010년대에는 앱애니에서 앱스토어들의 마켓 데이터를 분석&공급하고 있습니다.

    앱애니는 전세계적으로 5개의 사무실을 두고 있으며, 약 80명의 임직원으로 구성되어 있습니다.
    미국의 샌프란시스코, 영국의 런던, 홍콩, 중국의 베이징, 일본의 도쿄에 사무실이 있습니다.
    또한 $700,000를 전세계적인 VC에게서 투자를 받았습니다.
    중국의 IDG Capital Partners, 미국의 Greycroft, e.ventures, 일본의 Inifinity Venture Partners 가 그 투자사들 입니다.

    전세계적으로 수많은 기업들이 앱애니를 이용하고 있고, 보도자료의 근거자료로 활용하고 있습니다.
    전세계 Top 100에 드는 퍼블리셔들 중의 80%가 이 서비스를 이용하고 있다고 합니다.

    앱애니가 지원하는 서비스는 총 세가지이며, 각 항목 및 세부 설명은 다음과 같습니다.

    - Analytics; 내 앱의 sales, downloads, reviews를 트래킹합니다.
    분석을 하기 위해 필요한 데이터는 마켓의 로그인 정보입니다.
    SDK가 전혀 필요 없으며, stat 수집을 위한 정보 외에 빼가는 것은 없습니다.

    - Store Stat; 앱스토어에 등록된 어떤 앱이든 rank, pricing, placement를 트래킹합니다.
    각 마켓에서 랭킹데이터와 가격변동, featured 데이터를 수시로 수집합니다.

    - Intelligence; 유료서비스로, 어떤 앱이든 revenuew와 downloads를 정확하게 예측합니다.
    경쟁사의 마켓 데이터를 모니터링하여 분석합니다.
    급성장 중인 마켓을 찾아내어 앱이 성공할 수 있도록 도와줍니다.
    어떤 종류의 앱이 마켓에서 성공을 하고 있는지 알 수 있습니다.
    모네타이제이션 전략을 구성하고, 탑차트에 올라가기 위한 광고 전략을 제시합니다.
    마켓에서 소위 잘나가는 업체들을 가려내고, 잠재력이 높은 파트너 혹은 고객을 찾아냅니다.

    지원하는 앱스토어는 iOS, Mac AppStore, 구글플레이, 아마존스토어입니다.

    App Store Trends
    아래 데이터는 모두 2013년 2월 한달을 기준으로 작성되었습니다.

    - 역시 게임이 마켓을 주도하고 있습니다.
    - 구글플레이가 나날이 급성장 중이고, 다운로드 성적은 iOS앱스토어와 비슷합니다만, 아직까지는 iOS가 구글플레이의 두배 이상의 매출을 보이고 있습니다. (구글플레이가 두배까지 따라잡았다고 보는게 좋습니다. 성장 중입니다.)
    - 구글플레이는 iOS앱스토어에 비해 매출이 게임에만 집중되어 있습니다.
    - 지난 한해 동안, IAP(In-App Purchase, 앱 내 구매)가 급성장했습니다만, 게임에만 특히 국한되어 있습니다.

    국가별 출시전략은,
    - 한국; 구글플레이에서 아주 강력한 모습을 보입니다. 어느정도냐면, 구글플레이에서 35%정도 게임다운로드, iOS에서는 5%미만입니다 :(
    - 일본과 미국; iOS앱스토어와 구글플레이 매출이 비등합니다.
    - 기타국가; iOS앱스토어가 구글플레이보다 낫습니다.

    어떤 마켓이 게임 출시에 유리한가요?
    - 러시아, 브라질, 멕시코; 다운로드 수가 급격히 늘고 있습니다.
    - 중국; iOS앱스토어에서 매출이 급격히 늘고 있습니다.
    - 홍콩; 구글플레이에서 매출이 급격히 늘고 있습니다.
    - 아시아; 게임분야에서 특히 지출을 하는 경향이 있습니다.

    국가/마켓별 게임 다운로드와 매출의 관계?
    - 중국은 iOS다운로드가 대부분, 구글플레이는 5% 미만
    - 한국은 구글플레이가 대부분, iOS다운로드는 5% 미만
    - 나머지 국가들은 비슷합니다.
    - 그러나 매출에서 큰 차이를 보이는데요,
    - 한국을 제외하고 모두 iOS에서 매출이 훨씬 높습니다.
    - 미국은 25%가 구글플레이, 100%가 iOS에서 매출이 납니다.
    - 일본은 각각 50%로 균형적인 매출을 보입니다.

    장르별 다운로드 및 매출 관계
    - iOS앱스토어는 다운로드 많은(인기많은) 장르와 돈 잘 버는 장르는 다릅니다. 그러나 구글플레이는 비슷합니다.
    - iOS 다운로드 순위; 액션 > 아케이드 > 퍼즐 > 어드벤처 > 시뮬레이션
    - iOS 매출 순위; 롤플레잉 > 시뮬레이션 > 액션 > 전략 > 어드벤처
    - 구글플레이 다운로드 순위; 아케이드&액션 > 캐주얼 > 두뇌&퍼즐 > 레이싱 > 스포츠
    - 구글플레이 매출 순위; 아케이드&액션 > 캐주얼 > 브레인&퍼블 > 카드&카지노 > 스포츠

    아래 그림은 2013년 2월 각 국가의 마켓별, GooglePlay와 iOS의 게임장르 수치입니다.
    위의 그림은 download, 아래 그림은 revenue입니다.
    한국 마켓이 참 재미있습니다.
    Markets GooglePlay/iOS Game Downloads in Feb 2013

    Markets GooglePlay/iOS Game Revenue in Feb 2013

    Top Games
    - Temple Run 2; iOS와 구글플레이 모두 최상위 유지
    - Puzzle & Dragons; 양 스토어에서 top grossing 유지
    - iOS Downloads
    – Temple Run 2가 지난달부터 1위를 유지하고 있습니다.
    – 오래된 것이 좋다; Infinity Blade, Galaxy on Fire 2 HD, Plant vs. Zombies 세 게임이 top 10을 유지하였습니다.
    - GooglePlay Downloads
    – 아케이드 게임이 top 10을 주도하고 있습니다.
    – Temple Run 2 가 1월 중순 늦게 출시하였는데, 결국 top에 올랐습니다.
    – 위메이드에서 만든 윈드러너가 5위를 차지하였네요.
    - iOS Revenue
    – Puzzle & Dragons; 꾸준히 1위를 유지하고 있습니다.
    – Supercell에서 출시한 게임 2개가 top list를 유지하고 있습니다.
    - GooglePlay Revenue
    – Puzzle & Dragons; iOS에 이어 1위를 차지하고 있는데요, 이것이 일본에서의 경악스러운 성적 때문이라고 합니다.
    – 그 다음으로는 Kakao 플랫폼의 위력으로 top 10 중 5개를 차지하고 있습니다.

    Top Publishers
    - Temple Run 2와 Puzzle & Dragons 때문에 Imangi Studios와 GungHo Online이 선정되었습니다.
    - 일본과 한국에서는 구글플레이에서 매출랭킹을 쓸어담았습니다.
    - iOS Downloads
    – EA와 Disney, Gameloft가 수많은 앱으로 상위권을 유지하고 있습니다.
    – Temple Run 시리즈로 인해 독립개발스튜디오 Imangi Studios가 2위입니다.
    – LOTUM; 이번에 새롭게 4위에 올랐는데, 다국어 지원으로 한 단어추리게임 4 Pic 1 Word 덕분입니다.
    – NHN이 9위에 있네요. 비 게임을 포함하여 183개를 런칭하였습니다.
    - GooglePlay Downloads
    – Imangi Studios; Temple Run 시리즈로 인해 1위입니다.
    – 국내기업 NHN과 WeMade가 각각 6위, 8위를 차지하였습니다.
    - iOS Revenue
    – Supercell; Clsh of Clans와 Hay Day 덕분에 1위를 차지하였습니다.
    – GungHo Online; Puzzle & Dragons
    – EA, GREE, Gameloft, Zynga, DeNA 등이 있습니다.
    - GooglePlay Revenue
    – 일본과 한국 기업이 top 10을 싹쓸이 했습니다.
    – GungHo Online; Plzzue & Dragons
    – 한국기업; CJ E&M, WeMade, NHN, Com2uS, 4:33, Actoz Soft

    발표가 끝난 후, Q&A 시간에 한국 혹은 일본으로의 진출에 필요한 것이 무엇이냐는 질문에 로컬라이징 테스트가 필수적이라고 답하였습니다.
    한국만 보더라도, iOS 매출은 너무 적고 구글플레이 매출은 카카오 플랫폼이 독보적이지요.
    이와 마찬가지로 비주얼샤워에서 해외 진출을 꾀하고 있는데, 안그래도 localization(언어 번역 뿐만 아니라 해당 문화에 맞도록 수정)을 신중히 준비하는 중입니다.

    다음은 다른분이 나와서(이름을 메모하지 못했습니다. 죄송합니다) 사이트 이용 방법에 대해 설명하였습니다.
    사이트가 한국어도 지원하던데, 제가 예전에 접속했었을 때에는 한국어가 없더니, 언제부터 지원하기 시작했죠?
    디자인도 꽤 많이 바뀌어 있네요. 요즘은 꾸준히 관심을 가지고 지켜보지 않으면 금새 뒤쳐지는 세상입니다..
    구글플레이 매출이 급격히 늘면서 지원하게 되지 않았나 추측해 봅니다.
    사실 한국어로 번역되지 않아도 이용하는데 큰 어려움은 없습니다.

    대부분의 설명은 프로모션을 위한 설명으로 보이고, 실제로 하나씩 해 보시면 어려움 없이 이해할 수 있습니다.
    그 중 돋보이는 기능을 하나 말씀드리면, 위에 설명했듯이 analytics를 위해 매출 데이터를 자동으로 받아두는데, 앱스토어에선 이 데이터가 시간이 지나면 사라집니다. 앱애니에서 이 데이터를 백업하고 있다가 csv 등으로 다운받을 수 있습니다.

    마지막으로 앱애니 블로그에 방문하면 최신 트렌드 기사를 만나보실 수 있습니다.

    2013-04-08 01.30.41
    App Annie Analytics: http://www.appannie.com/analytics
    App Annie Store Stats: http://www.appannie.com/storestats
    App Annie Index: http://www.appannie.com/index
    App Annie Intelligence: http://www.appannie.com/intelligence
    App Annie Blog: http://blog.appannie.com

Back to top