굉장히 오래전 이야기입니다만 징가에서 이런 자료를 발표했더군요, 기술적인 부분에 있어서는 현재 더 많은 발전을 이룩했을것이라 봅니다만 여기서 나오는 개념이나 컨셉은 아직도 유효하다 생각되어 한번 제 생각을 정리해 봅니다. 혹시나 해서 미리 말해두자면 이것은 번역이 아니라 그냥 제 코멘트를 붙여보는 것입니다. 제가 이해를 잘못한게 있다면 꼬집어 주시기 바랍니다^^
징가에서 2009년 12월에 발표한 자료입니다. 1년도 더 된 자료입니다. 지금 봐도 손색 없을 정도의 멋진 내용이 이제 시작됩니다.
당시에 엄청나게 인기가 있었던 팜빌(FarmVille)의 Retention에 대한 언급입니다. 여기서 말하는 Retention이란 유지력 정도로 보시면 되겠습니다. 하루 플레이 하는 사람의 숫자(DAU:Daily Active User)가 2800만??명이나 된다고 하는군요. 한달에 한번이상 접속하는 플레이어의 총합(MAU:Monthly Active User)는 8천만명이나 되는군요.
징가는 어떤식으로 게임을 디자인 했길래(여기서 말하는 디자인은 게임의 기획/설계를 말합니다) 많은 사람들에게 어필할 수 있었고 끊임없이 사용률을 유지할 수 있었을까요?
이번 페이지의 주제는 사용자의 흥미를 잃게 만들지마라 정도가 되겠습니다. 게임의 테마나 컨셉을 정할때 사람들이 이해할만한 주제를 선택하여야 한다고 합니다. 식물이 어떻게 자라는가에 대한 룰을 정할때는 누구아 알만한 일반적인 상식선의 룰을 가져야 한다고 합니다. 사용자를 불쾌하게 만들만한 그러니깐 이해하기 어려운 테마를 선택하면 게임이 어렵게 될 수 있습니다.
이번 페이지의 주제는 소셜한 값어치를 만드는 것에 대한 이야기입니다. 게임을 즐기는 동안은 항상 사용자는 관계를 형성해 나가야 합니다. 혼자서 게임을 플레이 하다가 어떤식으로든지 게임을 그만두게 만들 요소를 다른 사용자와 지속적인 관계를 맺고 함께 플레이 하는 식으로 대체하도록 게임을 구성해야 합니다. 사진의 이미지는 Joel이라는 사용자가 나의 작물을 비옥하게 만들어 주었는데 고맙다고 전할꺼냐 물어보는 화면이네요. Premium Crops! 라는 커다한 메시지는 친구로 인하여 내가 큰 은혜를 입은것만 같아 보이게 만들어 결국 게임에 다시 참여할 수 밖에 없도록 만들고 있군요.
여기서 보여주는것은 매우 당연한 이야기가 될 비쥬얼적인 어플에 대한 이야기입니다. 밝은 그래픽을 언급한 이유는 아무래도 디자인을 밝고 화사하게 만드는것이 다양한 사용자들에게 어필할 수 있다는 뜻이 아닐까 싶네요. 어두 컴컴하고 매니악한 디자인은 좋은 선택이 아닐것입니다.
업데이트와 이벤트의 순서 혹은 주기에 대한 이야기입니다. 우선 플레이어를 가둬두기(?)위한 중요한 점은 계속해서 게임을 업데이트 하는 것이라고 합니다. 전에 게임기획자 후배를 만나 이야기 할때도 게임이 정점에 달했을때 가장 쉽게 할 수 있는 방법을 컨텐츠 추가로 말하더군요.
또 중요한것은 게임의 업데이트가 필요하다고 해서 게임을 복잡하게 만들 필요가 없다는 것입니다. 심지어는 새로운 아이템을 만드는 간단한 방법도 있습니다. 게임을 운영중일때는 사용할 수 있는 통계자료나 여러 데이터가 있을것입니다. 이제 무언가를 측정할 수 있을테니 이런 데이터와 사용자의 피드백을 활용하면 게임의 방향성을 설정할 수 있습니다. 여기서 마케팅을 굉장히 중요하다고 언급하고 있네요.
여기서 말하는 마케팅은 게임 내부의 마케팅을 말합니다. 새로운것이 추가되었다면 그것을 사용자에게 홍보하는것이 매우 중요하다고 하는군요. 위의 사진에서는 크리스마스 이벤트로 축제분위기의 전구로 집을 꾸미거나 정원이 눈으로 가득차게 바꾼다거나 할수 있게 되었음을 알려주는 군요.
자, 이제 어떤식으로 게임을 만들것인지 정하였습니다. 이제 이것을 어떻게 구현할 수 있을까요?
여기서부터 개발 이야기입니다. 설계에 대한 이야기인데요. 여기서 언급한 중요한 것들은 일명 DDD(Data Driven Design)인데요. 개발자들이 익숙한 말로는 Domain-Driven Design이라는 말이 있겠습니다. 데이터를 중심으로 하는 설계인데요. 저도 이번에 간단한 SNG개발을 경험해 보니 이것이 중요한것 같습니다. 왜냐하면 게임은 계속해서 변화하고 규모가 확장되는데 평범하게 생각없이 개발했다가 문제가 많이 생기더군요. 로컬라이징도 중요한 요소라고 시간을 투자해야 할 요소로 언급되었군요. 글로벌 서비스 기업다운 접근 방법입니다.
두번째로는 사실 정확히 무슨 말인지 잘 모르겠는데 플랫폼의 호출에 종속적으로 개발하지 말고 추상적으로 개발하라는 말인것 같습니다. [이곳]에 추상팩토리 패턴에 대한 언급이 있습니다. 이런식으로 개발하게 되면 새로운 아이템이나 컨셉을 넣었다 뺐다 하기 편리할 것으로 예상됩니다.
세번째로는 징가가 페이스북 플랫폼에 많이 의존적이기 때문에 페이스북과의 통신 채널을 단순화 하라는 것입니다. 확실히 여러 이종 시스템들 간의 통신이 복잡해 질수록 잦은 오류도 발생하고 문제가 발생할 소지가 많아지는것 같습니다.
네번째는 클라이언트와 서버가 한가지 접점만을 가지고 통신을 하도록 구성을 해야 한다는 언급입니다. 예를 들면 모든 통신에 대해 일괄적으로 서버에서 유효한 접근인지를 체크하는데 서버 개발자가 뒷구멍을 만들어 놓았다면 이런 일괄적인 개발이 어려워 지고 버그나 해킹의 위험을 가지게 됩니다.
그렇다면 클라이언트상에서 느껴지는 퍼포먼스는 어때야 할까요? 로딩 시간이 오래 걸리고 프레임의 움직임이(플래시 게임이라 이런 언급이 나오는듯) 느릿느릿하다면 사용자의 유지력을 KILL한다고 하네요. 무언가가 눈에 보이는데는 가능한한 빠르게 보여져야 하고요. 데이터를 주고 받을때 로딩중이 뜨는 등의 사용자의 액션이 블록되는 경우는 무엇을 필요로 하는 경우에만 하도록 합니다.
예를 들면 HUD(Head-Up Display: SNG에서는 게임에 필요한 상태 정보를 말합니다.) 또는 사용자 데이터를 불러오는 경우 등을 말합니다. 사용자가 다른 사용자의 정보를 보겠다고 프로필을 눌렀을때 로딩이 뜨는 경우와 가만히 게임화면을 지켜보고 있는데 로딩이 갑자기 자기 혼자 뜨는것과는 기분이 많이 다르겠죠.
마지막도 플래시에 대한 언급입니다만 프레임레이트에 맞게 화면을 그리라는 것입니다. 개발은 슈퍼 컴퓨터에 해서 잘 돌아가고 애니메이션에도 아무문제가 없었는데 고물 PC에서 돌렸는데 엄청나게 버벅인다면 큰일이겠죠. 위의 언급은 가변적으로 상태에 맞는 렌더링을 할 수 있도록 하라는 말입니다.
서버의 확장에 대한 페이지 입니다. 클라우드의 자동 스케일링을 언급하는군요. 실제로 아마존EC등에서는 이 자동 스케일링을 지원하고 있습니다. 사용량에 따라 자동으로 클라우드 시스템도 추가되는 것인데요. 저도 경험해 보진 않았습니다.
모든것을 비동기로 처리하고 캐시처리 하라고 하는군요. 동기로 처리하면 네트워크 상황에 따라 블록킹 되는 경우가 많고 많은 문제를 일을킬 수 있습니다. 캐시의 경우에는 메인 DB로의 직접적인 부하를 피하기 위한 방법이고요.
또한 모든 시스템의 아키텍쳐의 부분들을 병렬로 구성하라는 말이 있는데요. 보통 요즘의 시스템이 일명 Vertical 확장을 기본 모델로 하고 있습니다.(NoSQL등) 이런것들은 쉽게 말하자면 기존의 시스템이 1대에서 2대로 확장하고 또 3대로 확장되는데 있어 다른 서버들과 동등한 레벨에 손쉽게 추가하여 시스템 자체의 규모를 키울 수 있는 방법을 말합니다. 음…맞을까요?;;
DB에는 예비 저장소를 가져야만 한다…일까요…MySQL등에서 리플리케이션을 구성하는것처럼 예비 시스템을 갖추어야 한다는 말인것 같은데 제가 영어 실력이 짧아서 저게 정확히 무엇을 뜻하는지 잘 모르겠군요…흠..
캐싱에 대한 이야기입니다. 여기서 보면 꽤 놀라운 이야기가 나옵니다. 페이스북의 API나 심지어 운영중인 DB가 없이도 게임이 동작할 수 있어야 한다고 합니다. 이렇게 되면 시스템에 장애가 생겨도 게임상에 아무런 낌새를 눈치챌수 없게 됩니다.
사용자 정보를 캐시하게 되면 서버로의 요청이나 DB요청을 심지어 0까지 낮출수 있습니다. 페이스북 API중 SQL형태로 데이터를 꺼낼 수 있는 FQL의 호출도 iframe을 이용하여 캐시할 수 있다는데 이것은 정확히 어떻게 한다는것인지 모르겠습니다.^^a
아래에 나온 예시는 페이지를 로드함에 있어 DB 연결 한번도 없이 캐시만을 이용하여 페이지를 로드한 결과를 보여줍니다.
정말 멋지게 시작했지만 무슨 말인지도 모르겠는게 많아서 어려움을 겪은 이야기였습니다. 어찌보면 당연하지만 중요한 이야기들도 많았고요, 길지 않은 PPT라서 다행이었습니다;