Game

You are currently browsing articles tagged Game.

게임 개발이란 굉장히 소모적인 작업이다. 일단 게임 어플리케이션을 만들어야 하고, 또 그 위에 컨텐츠까지 생산해내야 하기 때문이다.

일반적인 응용 어플리케이션 개발은 프로그램을 만들어서 사용자들이 컨텐츠를 생산해내는데 도움을 주는 것이 목적인 반면, 게임과 같은 엔터테인먼트 관련 개발은 프로그램은 물론 컨텐츠 생산까지 개발자가 다 하고 사용자는 오로지 그것들을 소비하기만 하기 때문이다.1

게임을 만드는 일에서 프로그래머가 해야 하는 일은 크게 두가지로 분류할 수 있다.

우선 첫번째로 외부 고객, 즉 유저들을 상대로 하는 부분들을 제작하는 일이다. 보통 바깥에서 보면 개발의 전부라고 생각할 수 있는 부분이다. 예를 들면 프로그램의 UI 작성, 내부 로직 작성 등이다.

그리고 앞서 이야기했던 게임 제작의 특성상 두번째 일이 추가된다. 즉, 내부의 고객(기획파트와 그 외 파트들)을 상대로 하는 부분들을 만드는 일이다. 예를 들면 새 캐릭터를 추가하는 캐릭터 에디터, 맵을 만드는 맵 에디터, 퀘스트를 작성하는 퀘스트 에디터, 몬스터를 추가하는 몹 에디터 등이 있을 것이다.

이러한 내부 고객용 프로그램의 경우 비 프로그래머가 사용하는 프로그램이긴 하지만, 굉장히 특정한 소수의 사람들만 사용하기 때문에 불특정 다수가 사용하는 게임처럼 자동 업데이트를 공들여 만드는 것은 약간 비효율적이다. 하지만 그렇다고 매 변경시마다 바이너리를 수동으로 배포하는 방식은 문제가 많다.

  1. 소스 변경시 개발자가 빌드해서 새 바이너리를 만든다.
  2. 이 바이너리를 사용자들이 접근할 수 있는 공간에 업로드 한다.
  3. 바이너리가 변경되었음을 사용자들에게 알린다.
  4. 사용자들은 새 바이너리가 릴리즈 된 것을 확인하고 다시 다운로드를 한다.

보다시피 이런 일련의 과정은 자동화가 되어 있지 않아서 위 과정 중 한 군데에서만 문제가 발생해도 제대로 작동하지 않는다. 그리고 바이너리의 버전 관리가 되지 않으므로 문제가 발생하면 원인을 파악하기 어렵다.

원활하고 신속한 게임 개발을 위해서는 내부툴들의 자동 업데이트 기능이 필수적이다. 하지만 앞서 이야기했듯이 이 자동 업데이트 기능은 게임 어플리케이션의 그것과는 달리 특정 소수의 인원만 사용하므로 게임 패처처럼 잘 만들 필요는 없다.

따라서 이 포스트의 초점은 쓸만한 자동 업데이트 기능을 간단하게 구현하는 것에 있다.

Read the rest of this entry »


  1. 그래서 현실 세계에서는 UCC 나 MOD 같은 개념들이 등장하고 있다. []

Tags: , ,

이번 포스트는 에픽 게임즈 (Epic Games) 의 창업자이자 언리얼 엔진의 메인 프로그래머인 Tim Sweeney 의 2006 년 Principles of Programming Languages (POPL) 에서의 invited talk 프리젠테이션에 관한 것이다. POPL 은 프로그래밍 언어 분야에서는 가장 권위있는 심포지움 중 하나이니 굳이 다른 설명은 필요없을 것 같다.

팀 스위니는 오래 전부터 GDC 에서도 OOP 를 이용한 엔진 개발의 중요성을 강조해왔으며 최근에 이르러서는 둠, 퀘이크를 만든 존 카멕의 엔진보다 팀 스위니의 언리얼 엔진이 대세로 떠오르고 있다. 언리얼 엔진은 모듈화가 매우 잘 되어 있어서 범용으로 사용 가능한 유일한 게임 엔진이라는 말을 들을 정도이다. (렌더링 미들웨어스러운 게임브리오는 예외로 하자.) 그리고 자체 스크립트 언어인 UnrealScript 로도 유명하다.

프리젠테이션 제목은 “The Next Mainstream Programming Language: A Game Developer’s Perspective” 이다. 사실 보통 3D 게임 엔진 개발자라면 imperative programming 의 달인이고 주로 SIGGRAPH 논문만 볼거 같은데 의외로 프로그래밍 언어에 대해 깊은 관심을 가지고 있어서 놀랐다. pure functional language 인 Haskell 에도 관심을 가지고 있어서 하스켈의 유용한 기능들을 많이 도입하려고 하고 있었다.

그 외에도

“우리는 절대 어셈블리어를 사용하지 않는다! (We never use assembly language)”

라든지 언리얼의 정수 변수 중 90%가 배열 인덱스로 사용되기 위해 존재했다는 것과 사용된 for 루프 중 40%가 functional comprehensions 그리고 50%가 functional folds 였다는 것도 매우 흥미롭다.

PT 를 보면 기어즈 오브 워(Gears of War)의 예를 들어 몇명의 프로그래머와 몇명의 아티스트가 얼마의 예산을 가지고 몇개월 동안 작업했는가 하는 구체적인 데이터로부터 시작하여 게임에 사용한 라이브러리들도 자세히 설명하고 있다.

그리고 게임 코드를 약 3가지-Game Simulation, Numeric Computation, Shading-로 분류해서 각각에서 중요한 요소들과 우선시되는 요소들(OOP, 속도, 병렬성 등) 을 설명하고 그에 맞는 언어를 소개하고 있다. 게임을 이루는 각 부분마다 특성에 맞는 서로 다른 언어들을 사용하는 것이 매우 흥미롭다. 혹시라도 난 게임 개발만 할거니까 functional language 는 알 필요없어! 라고 하는 분이 있다면 꼭 일독하길 바란다. 이 PT 를 보면 학부 수준에서 배우는 과목은 모두 다 중요하다는 진리를 다시 한번 일깨워준다.

특히나 경험을 바탕으로 한 게임 개발의 구체적인 수치들과 정상급 개발자의 식견은 돈 주고도 배우기 힘든 귀중한 내용들이니 꼭 읽어두도록 하자.

오른쪽 하단의 버튼을 클릭해서 풀스크린 모드로 보기를 추천한다.

외부 링크

Tags: , ,

스나이퍼?

스나이퍼란 간단히 설명하자면 라이플을 사용하여 원거리에서 대상을 저격하는 병과이다. 보통 우리가 흔히 보는 스나이퍼는 영화나 일반적인 FPS 게임들에서 보는, 스코프 달린 라이플을 들고 다니며 단순히 크로스헤어 가운데에 대상이 오도록 한 후 호흡 조절을 하면서 방아쇠만 당기면 끝나는 매우 편해보이는(?) 병과이다. 원거리이기 때문에 위치만 발각되지 않으면 적들과 총격전, 백병전을 벌이지 않고도 임무를 완수할 수 있고 특히 한명만 있어도 적의 부대를 제자리에 꽁꽁 묶어둘 수 있는 이점이 있다.

하지만 현실의 스나이퍼에게는 매우 복잡한 탄도 계산과 신중한 위치 선정 그리고 기회를 잡을 때까지 무한한 인내심을 가지고 기다리는 것이 필요하다. 일반적인 FPS 게임에서처럼 뛰어다니면서 쏘거나 심지어 점프해서 쏘는 것[..]은 절대 불가능하다. 기본적으로 스나이퍼는 잠복하는 지역의 환경에 따라 길리 슈트 등을 입어서 위장을 하고 엄폐물 뒤에서 관측병과 2인 1조 또는 혼자서 대상이 저격 가능할 때까지 기다린다.

1

즉, 위와 같은 모습으로 원거리에서 적을 노리는 것이다. 이런 복장을 하고 엎드린 채로 수시간에서 수십시간까지 찰나의 기회를 잡기 위하여 집중하면서 기다려야 한다. 물론 움직일 수 없으므로 소변도 그냥 자세를 유지하면서 해결하기도 한다. 그러면 여기서 Loren 님이 Armed Assault 라는 시뮬레이션에 가까운 FPS 게임에서 촬영하신 저격 동영상을 보면서 실제 스나이퍼들은 어떤 식으로 탄도 계산을 하고 위치 선정을 하는지 등에 대해서 알아보자. 다행히 자막으로 친절하게 설명해주므로 관련 지식이 없는 나같은 사람들도 편하게 볼 수 있다.

Loren 님의 ArmA 스나이핑 동영상

  1. ArmA 2167m 저격 동영상
  2. ArmA 정밀 탄도학 계산 동영상

Read the rest of this entry »


  1. http://en.wikipedia.org/wiki/Image:Marine_sniper_ghillie_suit.JPG []

Tags: , ,