사례 연구: ‘Pong’을 만들어보자

처음 쓰는 컬럼을 이런 진부한 설명으로 시작하고 싶지는 않았지만, 어쩔 수 없을 것 같다. ‘Pong’은 게임 역사상 처음으로 흥행에 성공한 게임이다. 게임 자체는 지금도 오락실 등에서 볼 수 있는 아이스하키 게임과 비슷하다. 두 명의 사람이 각자 단순한 컨트롤러를 사용하여 상대방 쪽으로 공을 넘겨 통과시키면 이기는 게임이다.

그림1

▲(Pong, 출처: 위키피디아)

하고 많은 게임 중에 이 게임을 선택한 이유는, 실시간 동기화를 구현하기 좋은 게임이라고 판단했기 때문이다. 다르게 말하자면 이 게임은 재미있고, 구현하기도 쉬워 보인다. 그렇다면 어떤 게임이 실시간 게임으로 만들기 쉬운지 어떻게 판단해야 할까? 이 컬럼은 이에 대한 부분을 다룰 예정이다. 추가로 사례 연구를 통하여 어떤 식으로 동기화를 만들어 가는지, 그 꼼수와 우회로 이루어지는 향연에 있어서 전채의 맛을 살짝 느끼는 것도 목표로 삼는다.

실시간 멀티플레이를 구현하기 위해 가장 먼저 고려해야 할 부분 중 하나는 바로 무엇을 동기화 할 것인가 하는 것이다. ‘Pong’은 아마도 화면을 돌아다니는 ‘공’, 그리고 플레이어가 공을 튕겨내기 위해 움직이는 ‘막대’ 부분이 될 것이다. 이 컬럼에서는 공을 어떻게 동기화 할 것인가에 대하여 집중적으로 이야기할 것이다.

공은 게임의 시작부터 끝까지 계속 움직이는 물체이다. 이는 동기화 해야 하는 정보가 쉬지 않고 변한다는 것을 의미한다. 현재의 좌표, 속도, 벽이나 막대에 충돌했는지 끊임없이 파악하고 동기화 해야 한다. 보편적으로 이렇게 끊임없이 변화하는 데이터를 가진 객체를 동기화 하는 것은 매우 어려운 일이다.

하지만 ‘Pong’은 물리 엔진을 사용할 수 있는 게임이다. 어느 한 쪽 막대에 공이 충돌했을 때의 좌표와 속도만 동기화 하면, 같은 환경에서 같은 물리 엔진임을 활용해, 이후의 진행을 추가 작업 없이 자동으로 똑같이 맞출 수 있다. 실시간 게임을 만들 때 동기화 해야 하는 정보와 순간을 최소화하는 것은 매우 중요하다. ‘Pong’은 이를 극단적으로 줄일 수 있기 때문에 상당히 구현하기 쉬운 편이다.

그림3

▲(직접 만든 멀티플레이 Pong의 모습, 양쪽의 위치가 조금은 다를 수 밖에 없다.)

 그러나 네트워크를 통한 데이터의 송수신은 시간을 소모한다. 특히 모바일 기기의 무선망은 최소 수십 밀리세컨드 이상의 지연 시간을 감안하는 것이 정석이다. 이 것도 국내는 아주 좋은 편이라 이 정도, 만약 미국이나 심지어 중국이라면 더 긴 시간이 걸린다고 보는 것이 맞다. 이런 상황에서 Player A의 공 정보를 아무리 빠르게 전송한다 한들, Player B의 정보가 맞춰지는 시간에는 차이가 생기기 마련이다.

그렇다면 어떻게 해야 할까? 가장 먼저 떠오르는 아이디어는, 양 쪽이 같은 정보를 공유할 때까지 잠시 기다리는 것이다. 흐름을 생각하면 다음과 같다.

  1. Player A > 서버 : ‘나의 공이 지금 좌표 (100,100)에 있다’
  2. 서버 > Player B : ‘A의 공이 지금 좌표 (100,100)에 있다고 한다’
  3. B > 서버 : ‘공의 좌표를 (100,100)으로 설정했다’
  4. 서버 > A : ‘B의 공 좌표가 업데이트 되었다’
  5. 이제 다시 A의 공 좌표를 업데이트 한다

여기서 센스 있는 개발자 분들은 바로 ‘어 이러면 안되지 않나?’하고 생각하실 것이다. 맞다. 이렇게 끊임없이 정보를 갱신하는 객체, 특히 그게 바로 화면에 보이는 것은, 이렇게 여러 번 통신을 하면서 지연 시간이 길어지면 바로 플레이의 불편함(랙)으로 이어진다. 위와 같은 방식은 상대적으로 덜 활동적인 장르나 게임 시스템 내부의 처리가 턴제 형태로 이루어지는 게임에서 사용한다.

그렇다면 다시, 어떻게 해야 할까? 다음으로 할 수 있는 방법은 네트워크를 통해 수신하는 데이터에 보정을 가하는 방법이다. 네트워크의 지연 시간을 측정 혹은 추정하고, 그 만큼의 시간이 지난 후의 상태를 계산해서 ‘적절히’ 맞춰 놓는 식이다. 이 것은 실제로 자주 쓰이는 방법이지만, 경험이 많은 개발자라면 알 것이다. ‘적절히’라는건 개발자에게 세상에서 구현하기 제일 어려운 것 중 하나 이다. 마치 ‘플레이어가 느끼기에 적절한 난이도로 몬스터 AI를 만들어 주세요’ 같은 요구랄까..

이제 마지막으로, 그럼 어떻게 하면 좋을까? 실시간 게임을 만들어보지 않은 개발자라면 이 결론이 아주 어색할지도 모른다. 그건 바로 ‘굳이 딱 맞출 필요 없다’이기 때문이다. 어차피 물리 엔진이 계산해주는 공의 이동과 충돌은, 같은 위치에 같은 방향만 맞춰 놓는다면, 결국 같은 곳으로 움직이기 마련이다. 어느 한 쪽의 화면이 조금 늦을 수는 있지만, 최종적으로 보는 화면이 같아진다면 문제가 되지는 않는다.

하지만 여기서 구현을 마무리하면 문제가 생긴다. 바로 앞의 이야기를 뒤집는 것 같지만  ‘최종적으로 보는 화면이 같아’져야 한다는 것이 중요한 기준이 된다. 예를 들어 공의 속도가 매우 빨라진 상태에서 네트워크 지연 시간이 늘어나는 경우, A의 화면에서는 이미 승리한 상태로, B의 화면에서는 아직 공이 다가오는 상태로 보일 수 있다. 이런 상황을 방지하는 것을 보장할 필요가 있다. 단, 네트워크 지연 시간이 수백 밀리세컨드 이상 비정상적으로 계속 늘어나거나, 아예 끊기는 경우는 여기서 고려하지 않는다.  물론 이런 상황의 예외 처리도 게임의 상용화를 위해 꼭 필요하지만, 네트워크에 문제가 생긴 다른 플레이어를 기다릴 지, 패배 처리를 할지, AI를 투입할지 같은 식으로 기술보다는 게임 정책의 문제가 된다.

그렇다면 네트워크 지연 시간을 보정하는 것은 어떻게 접근해야 할까. 이 것 역시 개발자가 단독으로 처리하기 보다는 기획과 유기적으로 이야기를 나누며 진행하는 것이 더 좋은 결과물을 만드는 경향이 있다.

다시 ‘Pong’으로 돌아오자. 플레이어 A가 공을 보내 B가 반응 해야 하는 거리까지 도달하는 동안, 벽에 두 번 부딪히면서 가는 일반적인 상황을 생각해보자. 네트워크 전송이 제대로 이루어지고 있는지, 네트워크 지연 시간은 얼마나 되는 지를 확인하기 위해 벽에 충돌할 때에도 정보를 전송한다고 가정하면, 흐름은 다음과 같다.

  1. 공이 A의 막대에 충돌했을 때의 위치와 속도의 변화를 서버를 통해 B로 보냄
  2. B는 해당 정보를 물리 엔진에 적용
  3. 공이 벽에 충돌한 위치와 속도를 서버를 통해 B에 보냄
  4. B는 해당 정보를 물리 엔진에 적용
  5. 공이 벽에 충돌한 위치와 속도를 서버를 통해 B에 보냄
  6. B는 해당 정보를 물리 엔진에 적용
  7. 이제부터는 B가 충돌했을 때의 위치와 속도의 변화를 A에게 보냄

위 흐름에서 네트워크 지연은 모든 부분에서 발생할 가능성이 있다. 1)에서 상대적으로 높은 네트워크 지연이 발생하고, 3), 5)에서 점점 더 빠르게 도착하는 경우에는, 공이 벽에 충돌할 즈음에 순간 이동을 하여 예상보다 더 빠르게 움직이게 되고, 1)보다 3), 5)에서 네트워크 지연이 커지는 경우, 진행하던 공이 다시 벽으로 돌아가는 현상이 발생한다.

솔직히 말하자면, 실시간 게임에서 종종 순간 이동이 일어나는 것은 사실 심각한 문제는 아니다. 모든 실시간 게임은 일정 부분 이런 문제를 가지고 있고, ‘Pong’역시 마찬가지로 볼 수 있다. 하지만 잦은 순간 이동은 플레이를 불편하게 만든다. 좀 더 보기 좋게 만드는 방법은 없을까?

여기서 게임의 특성, 재미 요소와의 조율이 이루어진다. 네트워크 지연 시간으로 인한 순간 이동이 피할 수 없는 것이라면, 그건 가능한 플레이어가 막대로 반응하기 최대한 이전에 이루어지는 것이 좋다. 플레이어가 막대로 반응하기 바로 직전, 벽에 충돌하면서 보정이 일어나 순식간에 공이 앞으로 다가온다면 당연히 짜증이 날 수 밖에 없을 것이다.

이에 따라 B에서 1)은 정보가 날아오는 순간 바로 적용하고, 3)과 5)는 내용과 현재 공의 위치에 따라 큰 차이가 나는 것이 아니라면 적용을 하지 않고 넘어가는 것도 좋은 방법이다. 다시 말하자면, 어떤 상황에서는 정보의 업데이트를 최대한 빠르게 하기보다는 오히려 뒤로 미루는 것이 더 나은 게임성을 제공하기도 한다는 것이다. 아이러니하지 않은가. 이와 같이 실시간 게임의 동기화 정책은 기본적으로 기술적인 문제이지만, 결정은 개발자 뿐 아니라 기획자는 물론, 팀원 전체가 플레이를 통해 다듬어 가는 것이 가장 좋은 결과물을 만드는 길이다.

지금까지 나온 이야기를 세줄 요약한다면, 다음과 같이 할 수 있겠다.

  • 실시간 멀티 플레이 게임은 동기화 해야 하는 정보와 빈도가 적을 수록 만들기 쉽다.
  • 네트워크 지연 시간이 존재하기 때문에, 이론적으로 완벽한 동기화는 불가능하다.
  • 완벽한 동기화를 추구하기 보다는, 게임을 플레이하기 좋은 방향으로 접근해야 한다.

물론 이 외에도 개선해야 할 사항은 얼마든지 남아있다. 이는 꾸준한 고민과 테스트를 통해서 찾아내고 다듬는 작업이 된다. 그 것은 개발 초기에 발견할 수도 있고, 런칭 직전에나 떠오를 수도 있으며, 심지어 출시하고 꽤 긴 시간이 지난 이후에 알게 될 수도 있다. 시기와 상관 없이, 위의 큰 틀을 따른다면, 아마도 좋은 게임을 만들 수 있지 않을까 생각한다.

아이펀팩토리는 곧 위에서 설명한 ‘Pong’ 게임의 소스코드 전체를 공개할 예정이다. 또한 향후 개발자 세션을 통하여 어떤 식으로 구현했는지, 이 컬럼에서 언급하지 않는 막대는 어떻게 다루었는지, 추가로 최적화 할 수 있는 여지는 어디에 있는지도 함께 이야기 나누는 시간을 가질 예정이다.

또한 아이펀 엔진을 정식으로 사용한다면, 위와 같은 초기 아키텍팅에 대한 고민도 개발자와 함께 나눈다.

감사합니다.

아이펀팩토리 박근환 아이펀 엔진 테크니컬 디렉터

[인벤기고컬럼 4] P2P vs 클라이언트-서버 모델, 각각의 장단점은?

P2P vs. 클라이언트-서버 모델 Part 1

첫 회에서 게임 서비스를 구성할 때 사용하는 네트워크 모델들에 대해서 간단하게 언급했었는데, 이 중에서 클라이언트-서버 모델과 P2P 모델에 대해 두 회에 걸쳐 좀 더 깊이 살펴보도록 하자. 이번 회에서는 클라이언트-서버 모델에 대해 설명을 하고 다음 회에 이어서 P2P 모델에 대해서 설명을 하도록 하겠다.

클라이언트-서버 모델: 중앙 집중 방식

집집마다 ADSL 인터넷이 설치된 것은 채 20년도 되지 않는다. 그전에 인터넷이라는 것은 학교 전산실에서나 경험해 볼 수 있었고, 컴퓨터 전공자들에게만 익숙한 것이었다. 지금은 컴퓨터를 사도 메인보드에 랜 포트가 달려나오고, 노트북 컴퓨터 같은 경우는 유선 랜 포트가 거추장스럽다고 아예 WiFi만 지원할 정도로 네트워크 연결 측면에서 많은 진보를 이루었지만, 당시에 랜카드는 당연히 별도로 사서 설치하는 것이었고, 그나마도 OS에서 이를 인식시키는 것은 나름 까다로운 작업이었다. 조금 더 쉽게 설명하면, 컴퓨터에 랜 카드를 설치해주는 것만으로도 컴퓨터 잘하는 동네 오빠로서 이성에게 호감을 얻을 수 있는 정도? (물론 나에게는 그런 여자 후배는 없었다… 왜냐면…. 나는 공대니까…)

인벤기고컬럼4.png
▲ 예전에는 랜카드를 별도로 설치해야했다. 크고 아름다운 랜카드의 위용(출처 : wikipedia)

이런 초고속 인터넷 (영어로는 broadband Internet) 의 대중화 과정은 비단 우리나라에서만 그런 것이 아니었고, 그 때문에 일반적으로 서버라는 존재는 압도적인 계산 능력을 갖춘, 특별히 관리되는 존재로 인식되었다. 우리가 일반 컴퓨터에서 사용하는 인텔 x86 CPU가 서버에도 활용되기 시작한 것 역시 역사가 그다지 오래되지 않았다.

이런 배경 때문에 대부분의 인터넷 서비스는 가장 직관적이고 일반적인 형태로, 정보를 몰아넣고 중앙에서 관리하는 강력한 컴퓨터가 빈약한 사용자 컴퓨터에 서비스를 제공해주는 형태로 갖춰지게 되었다. 정보를 제공(서빙)해주는 사람이라는 뜻에서 ‘서버’라고 불리게 되었고, 정보를 활용하는 고객이라는 의미에서 ‘클라이언트’라고 불리게 되었다. 그러니 클라이언트-서버 모델은 컴퓨터 네트워크 초창기부터 가장 일반적으로 활용되어온 서비스 구성 방식이다.

인벤기고컬럼 본문 더보기>

[인벤기고컬럼 3] 왜 게임 서버는 오픈 전에 완벽하게 나오지 않을까?

클라 프로그래머와 서버 프로그래머. 비슷해 보이지만 서로 다른 고민의 사람들. Part 2

지난 회에서는 게임 클라이언트에서의 성능 병목으로 1) 화면 만들어 내기 (렌더링), 2) 길찾기를 포함한 AI, 3) 현실감을 담아내기 위한 물리 엔진에 대해 설명했다. 그리고 가능하면 16 밀리세컨드 (60fps), 못해도 33 밀리세컨드 (30 fps) 안에 이런 작업들을 모두 마무리 해야된다는 말도 했다. 끝으로 이 작업들은 각각 난이도 있는 작업이긴 하지만, 복잡한 테스트 환경 없이 개발자의 작업 환경에서 화면에 물체들을 많이 올려보는 것으로도 클라의 성능 테스트를 할 수 있다고 이야기했다.

이번 회에서는 서버 쪽의 성능 병목과 서버는 어떻게 성능 테스트를 하는지에 대한 이야기를 해보겠다. 서버에서의 병목을 설명하기 위해서는, 클라가 서버에 접속해서 플레이하는 동안 어떤 일들이 발생하는지를 먼저 살펴볼 필요가 있다.

 

1) 패킷이 클라에서 생성되어 서버에서 처리되기 까지

인벤기고컬럼3.png

위 그림은 언뜻 보기에 복잡해 보이는데, 일단 용어가 낯설어서 그런 것일뿐 그다지 복잡한 그림은 아니다. 용어부터 살펴보자.

게임 클라와 서버가 데이터를 주고 받는 단위를 ‘패킷’ 이라고 한다. (컴퓨터 네트워크 학문 관점에서 엄밀히 구분하면 ‘메시지’ 라고 부르는게 맞지만, 한국에서는 아무도 메시지라고 부르지 않고 편의상 모두 ‘패킷’ 이라고 부른다. 그러니 우리도 그냥 ‘패킷’이라고 부르자. 사실 패킷 (packet) 이라는 단어가 프로그래머들이 쓰다 보니 컴퓨터 네트워크 전공 용어라고 생각하기 쉬운데, packet 은 ‘포장하다’ 라는 pack 에 작은 것을 뜻하는 접미사 -et 를 붙여서 작은 우편물/꾸러미를 뜻하는 실제 사용하는 영어 단어이다. 그러니 네트워크상에서 왔다 갔다 하는 작은 우편물이라는 의미로 packet 이라고 불린다고 보면 되겠다.)

 

인벤기고컬럼 본문 더보기>

[인벤기고컬럼 2] 게임 클라이언트의 ‘과부하’ 원인, “이것 때문입니다.”

클라 프로그래머와 서버 프로그래머. 비슷해 보이지만 서로 다른 고민의 사람들. Part 1

지난 칼럼 이후 많은 분들이 나의 지난 직장 생활이 연애 한 번 못 해 볼 정도로 힘들었는지 몰랐다며 위로를 보내주셨다. 그러나 사실 연애가 문제가 아니라 당시에 머리가 너무 빠져서 탈모치료까지 받고 있었다는 것을 아는 사람은 몇 없다.

i13333167277
▲으흐흑!

그리고 비단 나뿐만 아니라 게임 회사의 프로그래머들은 나처럼 골머리 앓다가 조기에 탈모가 오는 경우가 더러 있다. 그럼 대체 무엇이 그들의 청춘을 힘들게 하는 걸까?

당연한 이야기겠지만, 프로그래밍에 있어 성능의 병목이 되는 것이 있다. 그런데 클라와 서버의 경우가 다르다. 병목은 작업이 원래 복잡해서 병목인 경우도 있고, 작업 자체는 단순하지만 처리해야 되는 양이 워낙 많아서 병목이 되는 경우도 있다. 그럼 클라와 서버의 어떤 작업이 성능상의 병목이 되고, 어떻게 그것들을 사전에 확인하는지를 두 번으로 나눠서 살펴보도록 하겠다. 먼저 이번 편에서는 클라에서 주로 처리하는 작업에 대한 내용을 살펴보고 다음 편에서는 서버 쪽 작업을 살펴보도록 하겠다.

Part 1. 클라에서의 병목: 화면 만들어내기와 AI, 그리고 물리 엔진

1) 가장 빈번하면서 쉽게 병목이 되는 작업: 화면 만들어내기

예전 배불뚝이 TV 에서부터 최신 LED 디스플레이까지, 우리가 일상적으로 사용하는 디스플레이들은 일정 시간 단위로 화면을 다시 그려주는 방식으로 동작한다. 이를 주사율 (refresh rate)이라고 부르는데, 보통 초당 60번, 혹은 120번, 경우에 따라서 240번까지 화면을 다시 그리게 된다. 그리고 이 작업에 상당한 전력을 소모한다. 초당 다시 그리는 횟수가 많을수록 화면 상의 움직임은 자연스럽게 보이게 된다. (물론 우리 눈의 한계 때문에 일정 이상의 주사율은 별 의미가 없다고도 한다)

인벤기고컬럼 본문 더보기>

[인벤기고컬럼 1] 게임 서비스 구성 방법 연대기 : 갤러그부터 H.I.T까지

필자는 대학 3학년 시절이던 1999년 5월, 넥슨에서 처음으로 회사생활을 시작했다. 독자들 입장에서는 실망스러울지 모르겠지만, 게임이 너무 좋아서 학교를 때려치우고 게임 회사에 투신했다거나 하는 감동 스토리는 아니고, 가난한 자취생이 먹고 살기 위해 방학기간 동안 웹개발 알바로 지원을 한 것이다.

면접을 마치고 무척 존경하던 95학번 선배가 게임 개발을 하고 있어서 인사나 하고 가려던 참에 넥슨 정상원 부사장을 우연히 만났다. 당시 그는 넥슨 게임 개발부서의 맏형 역할을 하던 게임업계의 뚝심이었다. 우연히 만났지만 필자가 학과 시스템 관리자 출신이라는 이유만으로 게임 서버 프로그래머로 채용이 됐다.

그 뒤 어쩌다보니 알바가 아니라 휴학을 하고 정직원이 되었고, 다시 어쩌다보니 대학원 유학을 떠나기 전까지 넥슨에서 만 6년이 넘는 시간을 보내며 황금 같던 20대 시간의 대부분을 검은색 터미널 위에 서버 코드를 들여다보며 보내게 되었다. (덕분에 넥슨 나갈 때까지 연애를 못해봤다. 주륵 ㅠㅠ)

필자가 처음 맡은 작업은 당시 동접이 몇 백명도 안되던 바람의 나라의 하급 몬스터의 AI 를 수정하는 일이었다. 지금 생각해보면 굉장히 단순한 작업이었지만, 온라인 게임이라는 것이 낯설던 시절이라 필자에게는 어떤 것이 클라이언트 작업인지, 어떤 것이 서버 작업인지조차 낯설기만 했다.

지금은 그로부터 꽤 많은 시간이 흘렀고, 산업 자체가 고도화 되어 게임 클라이언트와 서버의 개념을 낯설지 않게 느끼는 독자들이 많을 것이다. 그래도 혹시 몰라서 게임 서버가 어떤 일을 하는지, 그리고 우리를 즐겁게 했던 게임들은 어떤 방식으로 서비스가 구성 되었는지에 대해 소개를 하기로 한다.

(우리 회사 담당 직원이 쉽게 써야 된다고 필자를 엄청나게 압박하고 있는데, 주변에 공돌이 밖에 없어서 민간인의 언어로 이야기하는 것에 어려움을 겪고 있는지라 시작도 하기 전부터 걱정이 앞서고 있다. ㅠ 아재개그와 더불어 이것도 넥슨 다니면서 얻은 산재리라..)

눈에 보이는 것이 전부가 아니다: 게임 클라이언트 외에 게임 서버와 디비 서버

우리가 다운로드 받아서 설치하는 것이 바로 게임 클라이언트다. (이후에는 그냥 ‘클라’라고 부르겠다) 구글 플레이에서 휴대폰에 넷마블의 ‘모두의 마블’을 설치하든, PC 에 네오위즈 ‘블레스’를 설치하든, 다운로드 받아 설치하는 것은 모두 클라에 해당한다.

유저가 보고 듣고 조작하는 것이기 때문에 보통 클라를 ‘게임’으로 오해하게 된다. 사실 이런 오해가 나름 이유가 있는 것이, 서버 없는 게임은 있지만, 클라 없는 게임은 존재하지 않는다. 여러분이 게임 서버와 직접 교감을 하면서 희열을 느끼는 이상한 사람이 아니라면 말이다. 흠좀무..

인벤기고컬럼 본문 더보기>

[GDC 2016] GDC 2016 엑스포 현장공개!

개발자들의 축제! GDC 2016 엑스포 현장공개!

GDC 로비
▲ 출처 : Officail GDC / GDC의 열기를 느낄 수 있는 로비의 모습

▲ GDC EXPO 도입

올해로 30회를 맞이한 세계 최대 규모 게임 개발자 컨퍼런스인 ‘GDC(Game Developers Conference) 2016’ 엑스포 정문의 모습입니다. GDC는 세계에서 가장 큰 규모의 개발자 축제로 게임업계에 종사하는 수 많은 개발자들의 지식과 정보를 공유할 수 있는 자리입니다. 업계 가장 최신 트렌드를 볼 수 있는 장소입니다. 거기다 전 세계의 개발자들을 한자리에서 만나 볼 수 있다니 이만큼 매력적인 일이 있을까요? 보통 첫날은 조금은 한산하기 마련인데 개막 첫 스타트부터 열기가 가득한 모습이었습니다.

아이펀팩토리는 이번 GDC 2016 에 한국공동관 전시 부스로 참여하였습니다.
개발자들의 열정과 열기가 가득한 GDC 엑스포 생생한 현장의 모습, 아이펀팩토리가 담아보았습니다.

▲ GDC  입장을 위해 등록데스크에줄서 있는 모습 

GDC 입장을 위해 길게 늘어선 줄입니다. 개발자분들의 열기를 한껏 느낄 수 있는 풍경이었습니다.

▲ GDC 한국공동관(좌)/ 한국공동관안에 아이펀팩토리 부스(우)

GDC 엑스포의 중앙 명당자리에 위치한 한국 공동관의 모습입니다. 이번 GDC 한국 공동관에는 ‘아이펀팩토리’를 비롯하여 각종 기술 솔루션업체부터 국내 게임 개발사, 그리고 대세 중의 대세인 VR까지 다양한 한국 기업의 참가로 다채롭게 이루어졌습니다.

7▲ GDC 아이펀팩토리 부스 미팅 중인 모습

플래쉬 애니메이션으로 재밌게 제작하여 방문객들의 눈길을 사로잡은 아이펀팩토리의 서비스 운영툴 ‘아이펀 디플로이’의 소개영상입니다. 혹시 서비스 운영툴 ’아이펀 디플로이’가 궁금하신분들은 이곳을 클릭해 주세요. (아쉽게도 아이펀 디플로이 소개영상은 영문으로만 지원하고 있습니다. )

 

▲ 일렉스 홍보관(Clash of Kings)

GDC 엑스포에서 굉장히 반가운 얼굴을 볼 수 있었습니다.  바로 손예진씨와 소지섭씨인데요!  GDC 클래시 오브 킹즈(Clash of kings)부스로 참여한 일렉스 홍보관에서는 광고모델인 두 사람의 모습을 볼 수 있는 광고영상이 플레이되었습니다.  타국 광고판에서 만난 연예인의 모습은 지인을 만난 것처럼 반가웠습니다.

 

▲ GDC 플레이에서 게임을 체험하고 있는 모습

GDC 참관객들을 위한 휴게 공간과 중소 게임 개발사들의 다양한 게임을 즐길 수 있는 ‘GDC 플레이’ 이벤트 부스 입니다. 직접 게임을 체험해 볼 수 있어 다양한 게임을 즐길 수 있었습니다.

 

▲ 컬러감이 돋보이는 구글 부스

멀리서도 눈에 딱 띄는 구글의 아이덴티디가 돋보이는 구글 부스 입니다. 구글의 메인 컬러들의 조합으로 꾸며진 구글 부스는 경쾌함이 느껴지는 장소였습니다.

 

▲ IGF 인디 개발사 부스(좌) / 인디게임 체험중인 개발자들(우)

VR과 함께 이번 GDC 2016에서 주목을 받은 이슈 중 하나인 인디게임 부스입니다. 전 세계 인디게임을 소개하는 부스로 자리에서 직접 게임을 즐겨보고 설명을 들을 수 있었습니다.

 

이번 GDC 2016에서 가장 큰 이슈 한 가지를 꼽는다면 당연 VR이라 말씀드릴 수 있을 만큼 대다수의 참가부스에서 VR을 만나볼 수 있었습니다. GDC의 부대행사로 VRDC(Virtual Reality Developers Conference)도 열리고 행사장 안에 VR Lounge를 만들어 10여개의 게임을 VR로 체험해볼 수도 있었고 엑스포에 참여한 기업들 중에서도 VR 기기나 그와 관련된 소프트웨어를 소개하는 업체가 꽤 많았을 정도로 게임업계의 VR에 대한 뜨거운 관심을 느낄 수 있었습니다.

15▲ 플레이스테이션 VR 체험 공간

GDC 전시회장 한가운데에 위치한 플레이스테이션의 체험공간입니다. 모바일 앱으로 예약 신청을 하고도 몇 시간씩 줄을 서서야 겨우 입장을 할 수 있었는데요. 그만큼 VR에 관심도가 높음을 느낄 수 있었습니다.

 

16▲ 에픽게임즈 단독 부스

GDC에서 가장 주목 받은 VR을 놓치지 않고 에픽게임즈도 VR개발툴을 공개했습니다. 곧 테스트를 ‘파라곤’과 VR에디터 등에 대한 개발자들의 많은 관심을 알 수 있듯이 에픽게임즈의 부스는 굉장히 붐볐습니다.

 

오큘러스▲ 오큘러스 VR 체험관

오큘러스의 VR 체험관의 모습입니다. 최신 오큘러스만의 VR 기술을 선보여 개발자들의 폭발적인 호응을 볼 수 있었던 부스였습니다.

 

18▲ XBOX 로비바

사우스홀 로비에 크게 자리잡고 있는 마이크로소프트 로비바입니다. Xbox 체험 공간과 함께 한쪽에선 간단한 마실거리(주류도 있었어요)를 판매하여 굉장히 자유로운 분위기의 부스였습니다.

 

19-1▲ 인텔 게임 체험 존

인텔에서도 체험 공간을 운영하고 있었어요. 실제로 탑승한 것 같은 리얼리티를 느낄 수 있는 게임 체험존이 준비되어 있었습니다.

 

▲ 이탈리아 공동관

이탈리아 공동관에서도 많은 개발자들의 미팅이 이루어지고 있었습니다. 세계 각국의 개발자들을 한 자리에서 만나볼 수 있는 GDC의 매력이 한껏 느껴지지 않나요?

 

24▲ GDC Career Center

세계 여러 나라의 기업들이 취업상담 부스에 모여 숨은 인재를 찾기 위해 채용박람회인 ‘커리어센터’도 열리고 있었습니다. 인재를 찾고 있는 기업이 간단한 기업소개를 할 수 있는 시간을 갖고 관심 있는 구직자들이 찾아가서 듣는 형식의 채용박람회였습니다.

 

세계 각국의 다채로운 게임과 국경없는 기술공유의 축제였던 GDC 2016, 이번 GDC 2016 출장으로 전 세계 개발자들의 노하우를 한자리에서 볼 수 있었던 멋진 경험이었습니다. 내년에 더 풍성해진 아이템들을 기대해보며 포스팅은 이만 줄이겠습니다.

– 아이펀팩토리 사업팀 훈남 1호 –

[GDC 2016] 아이펀팩토리 개발자가 말하는 “GDC 2016 최고의 이슈”

아이펀팩토리 개발자가 말하는 “GDC 2016 최고의 이슈”

1. 대세 중의 대세 VR 체험기 – 파라노말 액티비티(htc vive)

2016년도의 GDC의 가장 큰 화제는 단연코 VR기기를 이용한 게임들이었습니다. 회장 한 켠에 마련된 데모 시연 부스에서는 컨퍼런스 참여자들이 직접 게임을 해볼 수 있도록 준비가 되어있었습니다. 컨퍼런스 첫날인 월요일에 예약을 했음에도 불구하고 수요일까지 모든 예약이 꽉 차 있을 정도로 열기를 느낄 수 있었습니다. 다행히 목요일에 기회가 되어 파라노말 액티비티 게임을 VR로 즐길 수 있었습니다.

VR1
▲ 파라노말 액티비티 VR 체험 모습

 

VR▲ 세계적인 유튜브 스타로 발돋음 할 아이펀팩토리 미녀 개발자님의 VR 체험 모습 / 유튜브 13만 조회 돌파 / 출처 : 유튜브 ICN – Paranormal Activity  (체험영상 보기)

VR 추가2파라노말액티비티 실제 사용자 화면 / 출처 : 유튜브 ICN – Paranormal Activity (체험영상 보기)

진행은 일반적인 호러게임의 큰 요소를 충실히 따릅니다. 오디오를 이용한 긴장감과 시야를 제대로 확인할 수 없는 어둠, 적절한 곳에 놀라는 요소를 배치하여 게이머의 긴장감과 스릴을 극대화 시킵니다. 데모에서 게이머는 손전등 하나를 들고 불이 꺼진 대저택을 탐험하다 여러 이상 현상을 만나게 됩니다. 짧은 플레이타임이었지만 일반적인 PC게임과 비교했을 때 손색없을 정도의 분위기와 구성이었습니다. 다만 시야를 돌리면 더 이상 보이지 않는 모니터와는 다르게 시야를 돌려도 게임 내 공간이라 심약자에겐 충분한 주의가 필요할 듯 보였습니다. 실제로 시연에 참여한 여러 게이머들이 컨트롤러를 집어 던지거나 주저앉는 등 일반적 호러게임 혹은 영화에서 보일 수 있는 반응보다 더 격렬한 반응을 보여 주변을 즐겁게 해주기도 했습니다. 본인에겐 즐거운 경험이었을지는 모르겠지만요.

이 외에도 에베레스트를 등반하는 게임, 매가 되어 비행을 경험하는 게임 등 많은 새로운 컨셉의 게임이 회장 내 부스를 메우고 있어, VR 기기에 대한 열기를 확인할 수 있었습니다. 취재진의 열기 또한 뜨거웠는데요, IGN과 같은 여러 게임 매체에서도 취재를 나와 열기를 더했던 시간이었습니다.  이러한 열기가 많은 개발사들의 참여로 이어져 2017년 GDC에는 더 많은 VR 게임들이 소개되길 바랍니다.

– 아이펀팩토리 개발팀 차도녀 작성 –

 


 2. diablo post mortem – David Brevik

david brevik  1
▲ 출처 : Official GDC / 전설적인 개발자 ‘데이비드 브레빅’의 강연 모습

GDC 세션 중 가장 인기가 많은 세션을 고르라면 해당 세션을 빼놓고 얘기 할 순 없을 겁니다. 97년에 출시된 게임임에도 불구하고 수많은 사람들로 인산인해를 이룬 건, 이들에게 있어 이 전설적인 게임은 이들의 인생에 큰 획을 그었거나 지금의 직업을 선택하게 된 계기가 되었기 때문이겠죠. 실제로 세션 종료 후 Q&A 시간에 많은 이들이 자신의 학창시절이 디아블로로 인해 얼마나 망가졌나 웃으며 고백하는 시간이 되기도 했습니다.

david brevik  2
▲ 출처 : Official GDC / 강연장을 가득 채운 개발자들의 열기

그런 디아블로를 당시 리드 프로그래머였던 데이비드 브레빅이 시작부터 끝까지 하나하나 직접 해부해주었습니다. 개발 뒷 이야기는 덤. 이번 세션을 통해 백발의 개발자는 디아블로는 둠이나 넷핵과 같은 여러 게임에서 영감을 받았다고 고백했는데요, 그 중 하나가 바로 엑스컴이었습니다.

처음 기획은 isometric 형식의 턴제 게임이었답니다. 이를 위해 엑스컴에서 말그대로 “스크린샷처럼 타일을 찍어” 붙여 넣었다더군요. 그래서 지금도 타일 크기를 비교하면 두 게임이 동일하다고 합니다. 하지만 개발이 진행되던 중 게임의 기획이 턴제에서 실시간 액션으로 바뀌었고 리드 프로그래머로써 많은 불만을 가졌다고. 하지만 그런 불만은 개발이 끝나고 스켈레톤을 워해머로 내려침과 동시에 희열로 바뀌었답니다. “It was awesome!”

그 외에도 많은 뒷 이야기들로 세션 참여자들을 즐겁게 해주었는데요, 그는 캐릭터 제작에만 25분이상이 걸리는 기존 RPG게임들을 싫어해서 단순한 UI를 고집했답니다. 이를 위해 한 것이 “엄마 테스트”. “우리 엄마가 이걸 할 수 있나?”라는 명제를 가지고 접근을 하여 지금의 직관적인 디아블로 UI가 탄생했습니다.

지금 30-40대 게이머들에게 있어서 디아블로는 듣기만 해도 흥분되는 단어일겁니다. 디아블로2의 문이 활짝 열리는 그 순간에 피씨방에선 환호성이 터져 나왔을 정도였으니까요. 그리고 앞서 얘기했던 것처럼 많은 분들의 학창시절 성적을 지옥으로 끌고 간 주범이며, 불법복제의 범람의 시작이었습니다. 실제로 세션 참가자 중 한 분은 자신의 불법복제 사실을 고백하며 브레빅에게 뒤늦게나마 게임 값을 지불하기도 했습니다. 그 분도 자신의 강렬한 경험을 그런 일로 더럽히고 싶지는 않으셨던 거겠죠. 저 역시 제작자를 직접 만나 뒷 이야기를 듣고 세션장 안의 그 많은 사람과 같은 경험을 공유하였다는 사실에 가슴이 벅차 오르는 시간이었습니다. 앞으로도 더 많은 사람들에게 전율을 느끼게 해주길 기대합니다.

– 아이펀팩토리 개발팀 곱창집 아들 작성 –

 


 3. 5 mistakes by good teams that produce bad free-to-play games – Don Daglow

댄 더글로 사진
▲ 출처 : Don Daglow blog / Don Daglow의 프로필 사진

게임계의 살아 있는 전설을 만나는 시간이었습니다. Don Daglow. 퍼스널 컴퓨터가 발명되기도 전인 1971년부터 게임을 디자인한 사람이며, 최초의 컴퓨터 야구 게임의 개발자이자, 첫번째 컴퓨터 RPG 개발자이며 페르시아의 왕자 개발에도 관여했으며 네버윈터 나이츠와 에버퀘스트, 월드 오브 워크래프트를 만든 전설입니다. 연혁과 위업을 늘어놓자면 한도 끝도 없겠군요. 운 좋게도 저는 이번 GDC를 통해 이분의 조언을 듣는 기회를 가지게 되었습니다.

사실 세션을 듣고 난 뒤, 개인적으로 느끼기에 이 교훈들은 Free-To-Play 게임들에만 국한된 것이 아니라고 생각합니다. 이 분의 경험을 통해 삶 속에 녹아있는 교훈들을 전해준다는 느낌을 받았기 때문이죠.

서두는 게임의 진정한 악은 비즈니스 모델이 아니라는 이야기로 시작했습니다. 오히려 비즈니스 모델을 수립하고 그에 대한 추정치(KPI같은)들로 게임의 방향을 결정하는 것이 진짜 위험한 일이라고 말했죠. 이러한 추정치들에 사로잡히다 보면 생각이 제한되고 이로 인해 정작 해야 되는 행동들을 하지 못하는 경우가 생길 수 있다고 전했습니다.

또한 게임에 있어서 첫날 화려하고 할 것이 많은 것보다 시간이 지날 수록 부담이 적고 쉽게 익숙해질 수 있는 게임이 낫다고 봤습니다. 전자의 경우는 얼핏 보기엔 화려해 보이지만 유저의 입장에선 시간이 지날수록 이러한 것들은 고통이 될 수 있다는 게 근거였습니다.

그리고 요즘 많은 개발사들이 포럼의 유저 피드백을 중요시 여기는데, 물론 이 또한 중요하지만 그에 못지 않게 중요한 것이 수치, 통계 그리고 데이터라고 했습니다. 포럼에 활동적으로 피드백을 올리는 유저는 플레이하는 유저들 중에서도 매우 한정적인 집단이기 때문에, 이러한 얇은 유저층에 휘둘리게 된다면 오히려 놓치는 것이 많을 것이니 그보다 데이터에 집중하는 것이 나을 것이라고 했습니다. 하지만 또한 이러한 숫자들이 모든 것을 알려주지는 않을 것이라며 두 가지 방식을 적절히 섞어 사용하는 것을 제안하기도 했죠.

이번 GDC는 여러 방면에서 지평을 넓힐 수 있는 좋은 기회였습니다. 특히나 이러한 경험이 많은 원로 게임 개발자들의 생각을 엿보고 조언을 들을 수 있는 시간이야말로 무엇과도 바꿀 수 없는 소중한 것이었던 것 같습니다. 어떻게 보면 이러한 조언들은 단순히 게임 개발에만 국한되는 것이 아니고 조금 생각을 달리하면 삶에도 적용할 수 있는 그런 것들이었습니다. 어느 한 분야의 정점에 달하면 그 끝은 하나로 귀결된다고들 하던데 정말로 그러한가 봅니다. 기회가 된다면 이분의 다른 세션들도 들어보았으면 좋겠네요. 이로써 GDC 2016 참여 후기를 마칩니다.

– 아이펀팩토리 개발팀 곱창집 아들 작성 –