Fighting Latency on Call of Duty Black Ops III
Room 2006, West Hall
Speaker : Benjamin Goyette | Senior Engineer, Activision

혹시 온라인 게임 PVP를 하다가 스킬 한번으로 승패가 결정되는 순간에 분명 내가 먼저 스킬을 썼는데 패배 한 경험을 한 적이 있나요? 아니면 분명히 상대를 공격했는데 무효가 된 적은 없나요? 또 제자리 달리기를 한 적은 없나요?

이러한 현상을 latency라 하는데, 단순한 행동에서의 latency는 치명적이지 않을 수 있지만, 어떠한 결과를 만들어내는 과정에서 발생하는 latency는 플레이에 아주 큰 방해가 될 것입니다. 이로 인해 많은 유저들이 좋지 않은 경험을 하고 이탈 하게 될 것이구요.

이번 강연에서는 이 latency를 해결하기 위해 어떤 방법을 사용했는지 소개했습니다.

먼저 문제를 해결하기 위해선 원인이 무엇인지 파악해야 하는데, latency가 발생할 수 있는 부분은 controller에서의 입력, 애니메이션 rendering, 서버 / 클라이언트간 통신 등이 있습니다.

그리고 어느 부분에서 얼마 만큼의 latency가 발생하는지 측정 하기 위해서 CPU / Network profiling tool을 사용하고, 제게는 아주 인상 깊었던 비디오 촬영을 한다고 합니다.
프레임이 아주 높은 카메라로 플레이 화면을 촬영하며 얼마 만큼의 latency가 발생하는지 측정 하는 것이지요.

만약 초당 100프레임을 촬영하는 카메라를 사용했고, 두 클라이언트 사이의 동작이 5프레임 차이가 났다면 50ms의 latency가 발생했다고 판단 할 수 있는 것입니다.

이러 방법을 사용해 발표자는 controller 입력, 서버 / 클라이언트간 통신에서 발생하는 latency를 해결 하였는데, 유저들의 불만은 여전했다고 합니다.
그래서 애니메이션 rendering에 문제가 있는지 확인 해보기 위해, 모든 애니메이션을 끄고 테스트를 진행했는데도 아무런 문제가 없었다고 합니다.

과연 이 latency는 어디서 발생 한 것일 까요?

정확한 원인 파악에 어려움을 겪고 있던 때에, 특정 방향으로 움직이는 유저들의 승률이 높다는 것을 알아낸 발표자는 캐릭터가 특정 방향으로 움직이는 애니메이션 rendering에 문제가 있다는 것을 알아낼 수 있었다고 합니다.

온라인 게임에서 발생 할 수 있는 latency는 단순 서버 / 클라이언트 통신에서만 발생하지 않는 다는 것과, 조그마한 부분이라도 놓치지 않고 테스트 해봐야 하다는 것을 다시금 일깨워준, 앞으로 개발 하게 될 실시간 통신 feature개발에 큰 도움이 되는 강연이었습니다.

By Justin Hwang

Effective Testing for Free-to-Play Games
Room 132, North Hall
Speaker : Emily Greer | Co-Founder & CEO, Kongregate

성공적인 게임 출시를 위해서 반드시 선행되어야 할 것은 바로 정확한 테스트입니다.
테스트에서 긍정적인 결과가 나온 제품은 업데이트 하여 출시하면 성공 가능성이 훨씬 높아 질 것 입니다.
헌데 이런 테스트를 언제, 얼만큼, 무엇을 확인 하기 위해서인지 목표를 설정하지 않고 진행 한다면 비용만 낭비하는 꼴이 될 수 있습니다.

발표자는 이러한 경우를 없애기 위해 효과적인 테스트 계획에 대해 설명 했습니다.

먼저 테스트의 종류와 그 장단점을 비교해 보면 다음과 같습니다.

1. 현장 테스트
   • 장점 : 유저의 행동과 몸짓 언어를 직접 관찰 할 수 있다.
   • 단점 : 심리적 압박감이 행동을 변화 시킬 수 있다. 샘플이 너무 적고, 편향된 행동을 할 가능성이 있다.
2. 원격 테스트
   • 장점 : 심리적 압박이 적고, 새로운 관점을 관찰 할 수 있다
   • 단점 : 행동이나 몸짓 언어를 관찰 할 수 없다. 샘플이 적고 비용이 늘어 날 수 있다.
3. 지인/내부 테스트
   • 장점 : 비용이 적게 들고, 버그를 찾기에 용이 하다
   • 단점 : 편향적인 반응을 보일 수 있다. 샘플이 적다
4. 클로즈 베타 테스트
   • 장점 : 테스터들이 열성적이다. 출시 전 커뮤니티 형성을 할 수 있는 기회가 있다.
   • 단점 : iOS에서는 불가능 하다. 통계가 부풀려질 가능성이 있다.
5. 지역 테스트
   • 장점 : 작지만 실질적인 데이터를 얻을 수 있다.
   • 단점 : iOS에서 확인 하기엔 시간이 오래 걸린다. 데이터가 대표성을 갖기 힘들다.

그래서 효과적인 테스트를 위해선 <내부 테스트> ⇒ <지인 테스트> ⇒ <클로즈 베타 테스트> ⇒ <지역 테스트> 순으로 진행 하는 것이 좋다고 합니다.
하지만 이러한 이론이 모든 게임에 동일 하게 적용 될 수는 없고, 현재 상태에 따라 유동적으로 선택 할 수 밖에 없다고 합니다. 테스트 결과가 나쁘다고 해서 무조건 다음 패치를 준비 할 것이 아니라 현실적인 자본과 시간에 대해 충분히 고려해야 한다는 것이지요.

가장 중요한 것은 앞에서 언급 한 것처럼 테스트의 ‘목표’를 설정 하는 것이라고 합니다. 이번 테스트로 튜토리얼 후 이탈 유저가 몇 %인지 파악하고, 다음 패치로 그 비율을 몇 %까지 줄이겠다, 또는 이번에 추가된 PVP feature의 이용률이 목표치를 달성 했는지, 달성하지 못했다면 다음 패치로 몇 %까지 수치를 올릴 것인지에 대한 목표 말입니다.
또 데이터가 충분히 모이기 전까지는 성급하게 결단을 내리지 말라는 충고도 덧붙였습니다.

이번 강연을 들으면서 그동안 저희의 패치 process에 대해 되돌아 보게 되었습니다.
그저 막연하게 어떤 효과가 있을 것이다, 하는 추측만 가지고 패치를 한 것은 아닌지, 그 때문에 실질적 효과를 보지 못하고 비용만 낭비한 것이 아닌가 하고 말입니다.

By Justin Hwang

How & Why to Write an Autopatcher for Your Game
Room 2006, West Hall
Speaker : Robby Zinchak  |  Founder & CEO, Archive Entertainment

이번 강연은 PC binary 패치 방법에 관한 내용입니다.

발표자는 패치를 하기 위해서 binary diff를 사용하여 blob을 생성하고 그 리스트를 관리하는 방식을 사용한다고 했습니다.

만약 버전 1이 서비스 중이고, 버전 2로 패치하는 경우를 가정하면,
버전 1 과 버전 2의 binary diff에 따른 blob 1을 생성하고, 패치 목록에 등록해 둡니다.
또 만약을 대비한 버전 2의 full binary 파일도 목록에 등록 해 둡니다.
해서 버전 1이 버전 2로 업데이트 할 때 blob 1을 다운로드 받아 업데이트 하는 것입니다.

또 버전 3이 준비 된다고 하면, 버전 1에서 버전 3으로 업데이트 하는 경우와 버전 2에서 버전 3으로 업데이트 하는 경우, 총 2가지가 존재하고 이에 따른 blob2, blob3 을 패치 목록에 등록하는 것이지요.
이전 버전의 full binary는 최신 버전의 full binary로 교체 하여 등록 해 둡니다.

업데이트 과정에서 에러가 발생한다면 자동 재시도를 하고, 방화벽이나 하드디스크등의 정보를 로깅하여 에러 핸들링을 한다고 합니다.

이러한 패치 방식의 단점은 역시 패치 목록 생성이 복잡해 지고, 패치 목록 자체가 커질 수 밖에 없다는 것 입니다. n개의 버전이 존재 한다면 패치 목록은 n(n-1) / 2 + 1개 만큼 생성 되어야 하니까요.
다만 업데이트 할 때 다운로드 받는 파일의 크기는 확연히 줄어 들게 될 것입니다.
모바일에서는 어차피 각 Market / Store에서 업데이트 해주기 때문에 이러한 시스템이 필요 없을 수 있습니다. 하지만 CDN을 사용하는 앱이라면 어느정도 고려 해 볼 만한 내용이라고 생각 했습니다.
저희도 CDN을 통한 리소스 업데이트를 하고 있는데, 전체 리소스를 full patch 하다 보니 그 비용이 만만치 않기 때문입니다.

최적화 된 패치를 하기 위해 위 시스템을 도입하면 어떨까 하고 생각해 봤습니다만, 한번의 패치를 위해 여러 리소스의 binary diff를 구해야 하기 때문에 패치 목록 생성 / 관리에 너무 많은 비용이 들고, 각 리소스 별 diff로 생성된 blob을 적용하는 process가 복잡해질 뿐 아니라, 예외 상황도 더 늘어나기 때문에 현재 패치 시스템과 좀 더 비교한 후에 결정을 내려야 할 것 같습니다.

By Justin Hwang

Building Higher Level Functionality For Games Using AWS
Room 3014, West Hall
Speakers : Dhruv Thukral | Gaming Solutions Architect, Amazon Web Services
Greg McConnel | Solutions Architect, Amazon Web Services
Greg Murphy | TBD, Amazon

이번 강연에서는 AWS를 사용하여 얼마나 효율적으로 게임 개발을 할 수 있는지에 대해 소개했습니다.
이러한 것이 가능하게 해주는 2가지 중요 요소는 바로 Lambda와 DynamoDB 입니다.

실제 개발 시뮬레이션을 하기 전에 각각에 대해 살펴보도록 하겠습니다.

먼저 Lambda는 AWS에서 제공하는 Cloud 서비스로, DB 업데이트 / 사용자 입력 / 시스템 상태 변화에 따라 트리거가 동작하여 자동으로 등록된 코드를 실행시켜주는 역할을 합니다.
예를 들어 유저가 아이템을 사는 경우, DB에 구매 로그를 남기도록 서버 구현을 해야만 했습니다. 이러한 경우 Lambda를 적용하면 서버 로직에는 단순히 유저 인벤토리를 업데이트 하는 구현부만 있으면 됩니다. DB가 업데이트 될 때 트리거가 발동하여 구매 로그를 남기는 코드를 Lambda가 실행 시켜 줄 것이기 때문입니다. 이러한 feature 뿐 아니라 시스템 상태에 따른 트리거를 동작하게 하여 서버 인스턴스 관리를 자동화 할 수 있습니다.

이 Lambda와 함께 거의 형제처럼 붙어다니는 DB가 있는데 그것이 바로 DynamoDB 입니다.
DynamoDB는 MongoDB나 Redis와 같은 NoSQL DB로 key-value 형태의 데이터를 디스크 I / O 없이 빠르게 읽고 저장할 수 있습니다. 하지만 단순히 데이터를 메모리에서 관리하는 NoSQL DB의 특성 뿐 아니라, RDB에서 사용하는 index기능을 특정 key값 들을 묶어서 사용 할 수 있다는 것이 가장 큰 매력이 아닐까 합니다. (이것을 Global Secondary Indexes, GSI 라고 합니다.)
이 부분에 대해서도 예를 들면, 여러 앱을 서비스하면서 랭킹 시스템을 구현 해야 하는 상황을 놓고 보면 이해가 쉬울 것 입니다. 전형적인 NoSQL DB를 사용 하는 경우, 유저 ID 하나만을 key로 사용해야 하기 때문에 각각의 앱 별로 테이블을 생성하고 관리해야만 합니다. 하지만 DynamoDB는 하나의 테이블에서 유저 ID와 앱코드를 index로 사용 할 수 있기때문에 하나의 테이블만 관리하면 된다는 이점이 있습니다.
그럼 이제 위의 두가지 핵심 요소 Lambda와 DynamoDB를 사용해 얼마나 효율적으로 게임을 개발 할 수 있는지, 강연에서 얘기한 친구초대 시스템 구현 시뮬레이션을 해보겠습니다.

먼저 친구 초대 시스템의 동작 flow는 다음과 같을 것입니다.
1. 대상에게 요청 (sender)
2. 대상자의 정보 업데이트 (receiver)
3. 대상자의 수락 (receiver)
4. 요청자의 정보 업데이트 (sender)

그리고 DB 테이블의 구조는 name, pending_request, received_request, friends 의 4개 column이면 될 것 같습니다.

이제 동작 flow에 따라 한 스텝씩 진행 해보겠습니다.
A가 B에게 친구 요청을 합니다. 그럼 DB의 데이터가 다음과 같이 업데이트 될 것입니다.

다음 스텝에서 B의 정보가 업데이트 되어야 하는데, 이 부분에서 Lambda가 사용됩니다.
A 정보의 업데이트로 인해 트리깅 되어 자동으로 B의 데이터를 업데이트 할 수 있게 되는 것입니다.
만약 Lambda를 사용하지 않았다면 서버 로직에 B의 정보를 업데이트하는 코드를 써야 했을 겁니다.
그리고 이때 B의 정보를 선택하기 위해 DynamoDB의 GSI가 사용 되어 부하 없이 동작을 수행하게 됩니다.

그렇다면 Lambda로 인해 B의 정보가 업데이트 되고, 그 결과는 다음과 같이 됩니다.

 

그 다음 단계에서 B가 A의 요청을 수락하고, B의 데이터가 업데이트 됩니다.

 

또 Lambda에 의해 A의 정보도 자동으로 업데이트 될 것이고 최종 적으로 이렇게 업데이트 될 것입니다.

 

전체적인 flow는 총 4단계이지만, 실제 서버 사이드 구현은 2단계로 마무리가 될 수 있게 되었습니다.

현재 사내에서 꾸준히 개발하고 있는 PV의 친구 관리 시스템도 총 4단계의 로직으로 구현 되어 있는데, Lambda와 DynamoDB를 적용한다면 지금 보다 훨씬 좋은 성능을 발휘하면서 효율적으로 개발을 완료 할 수 있지 않을까 기대하게 만드는 강연이었습니다.

by Justin Hwang

Lightning Talks (Presented By Google)
Room 2020, West Hall
Speakers : Shannon Woods | Technical Program Manager, Chrome + 14

이번 강연에서는 Cloud Computing 서비스인 Google Cloud Platform, Game Engine의 빌드 간편화 툴, 유저 관리 등, 게임 개발에 필요한 전반적인 부분을 5분 내외로 간략하게 소개 / 설명 했습니다.

그 중 인상 깊었던 모바일 기기의 렌더링 방식 변화, Gaming Youtube, Project Tango에 대해 조금 더 자세히 알아보겠습니다.

먼저 모바일에 사용되는 렌더링 방식이 전통적인 방식에서 변화 될 수 밖에 없는 이유는 기기의 물리적 특성 때문인데, 적은 전력 소모, 작은 칩셋, 적은 발열 이라는 3가지 이슈가 있습니다. 결국 전체 화면을 매번 갱신하는 전통적인 방식의 렌더링보다 더 부하가 적은 방식을 찾을 수 밖에 없었고, 이러한 이슈를 해결하기 위해서 Vulkan이라는 그래픽 라이브러리를 사용하게 되었습니다. 이 Vulkan은 Tile-based Rendering이라는 방식으로 화면을 출력하는데, 이는 화면을 일정 크기의 타일로 나누고, 출력되어야 하는 타일만 갱신하는 방식입니다. 이로써 갱신하지 않아도 되는 부분을 출력해야 하는 오버헤드가 줄어들었고, 모바일 기기에 더 적합한 렌더링 방식이 된 것입니다.

다음은 Gaming Youtube에 관한 내용인데, 과거 PC게임인 StarCraft의 관전 맵에서, 현재의 League Of Legend의 관전 시스템, 또 모바일의 Clash Royale의 TV를 생각하시면 어떤 서비스를 의미하는지 쉽게 이해 할 수 있을 것입니다. Gaming Youtube는 플레이어가 자신의 플레이를 실시간 스트리밍 할 수 있도록 지원해주고, 다른 유저들과 채팅도 가능하게끔 해주는 서비스 입니다. 이를 통해 기존의 정적인 느낌의 community를 더 동적이고 상호적이게 구축 할 수 있게 되었습니다. 그리고 이미 국내에서는 인터넷 방송을 통한 앱 홍보가 많은데, 글로벌 시장에 홍보하기 위해 Gaming Youtube를 활용 할 수 있지 않을까 싶습니다.

마지막으로 소개하는 내용은 Project Tango라는 모바일 기기입니다. 이 Tango는 Motion Tracking과 Area Learning, Depth Perception이 가능해서, 어느 곳을 어느속도로 이동 했는지, 몇 가지의 사물이 어디에 있는지, 얼마만큼 멀리 있는지 자체적으로 판단이 가능하다고 합니다. 이 주제에 대해 들으면서, Tango기기를 사용 해 AR이 적용된 어드벤처 게임을 만든다면, 모든 유저별로 색다를 경험을 줄 수 있지 않을까 하고 생각했습니다. 단순히 화면의 버튼만 누르는 것이 아닌, 직접 공간을 돌아다니고, 가상의 아이템을 획득하며 기믹을 해결 한다면 모든 유저가 완전히 같은 장소에 있지 않는 이상 다른 화면을 보게 될 것이고, 여러 공략법등이 등장 할 수 있을 것입니다. 그리고 실제로 유저가 행동하기 때문에 현장감과 몰입감도 높아 질 것이라 기대해 봅니다.