Programming

You are currently browsing articles tagged Programming.

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

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

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

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

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

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

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

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

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

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

Read the rest of this entry »


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

Tags: , ,

C++ 의 모든 base class 의 destructor 는 꼭 virtual 이어야 할까요?

당연한 이야기지만 정답은  “아니다.” 입니다.

polymorphic base class 의 경우는 그래야겠지만 단순히 base class 라면 꼭 그럴 필요는 없습니다. 일단 non-virtual destructor 가 문제되는 경우가 하위 클래스의 인스턴스를 상위 클래스로 업캐스팅 해서 사용하다가 삭제하는 경우이므로 이런 경우가 발생하지 않는다면 문제가 없다는 이야기입니다.

예를 들면 boostnoncopyable 등의 클래스를 상속한 하위 클래스에서 noncopyable 로 업캐스팅해서 사용하다가 delete 하는 경우는 상상하기 어렵겠죠? 따라서 이런 클래스들은 소멸자가 가상 함수가 아닙니다.

물론 그럴리가 없다고 생각하는 경우라도 혹시나 다른 프로그래머가 그렇게 할지도 모른다는 염려가 든다면 아래와 같이 작성해주면 됩니다.

class BaseClassNotPolymorphic
{
  protected:
    ~BaseClassNotPolymorphic() {}
};

이렇게 base class 의 destructor 를 protected 로 설정해두면 이 클래스의 포인터로 delete 등을 시도할 때 컴파일 타임 에러가 발생하므로 문제를 미연에 방지할 수 있습니다. :) 그리고 실제로 boost 의 noncopyable 클래스의 경우 생성자와 소멸자가 전부 protected 입니다.

Tags: , ,

Subversion 의 로그 메시지를 수정하는 기능은 기본적으로 막혀있습니다.

왜냐하면 로그 메시지를 바꾸는 일은 리비전이 남지 않기 때문입니다. 즉, 데이터를 날릴 수 있는 가능성이 존재하므로 이는 롤백조차 리비전으로 남기는 섭버전의 타임머신 철학상 그다지 추천할만한 기능이 아닙니다.

그래서 섭버전은 로그 메시지 수정, 즉 리비전 속성 변경 (revision properties change) 의 경우에는 무조건 pre-revprop-change 훅 스크립트가 있어야 실행됩니다. 만약 스크립트가 없다면 로그 메시지를 수정할려고 할 때 아래와 같은 에러 메시지를 볼 수 있습니다.

섭버전 배포판에 기본적으로 pre-revprop-change 예제가 포함되어 있지만 이것은 리눅스 계열의 쉘 스크립트이기 때문에 윈도우 기반에서는 따로 작성해야 합니다.

정말 새로 작성해야 될까 하는 의문을 품고 섭버전 유저들의 제 2의 바이블인 TortoiseSVN 의 도움말을 뒤져보다 보면 “4.3. Hook Scripts” 섹션에서 아래와 같은 윈도우 용 pre-revprop-change.bat 예제를 찾을 수 있습니다.

rem Only allow log messages to be changed.
if "%4" == "svn:log" exit 0
echo Property '%4' cannot be changed >&2
exit 1

pre-revprop-change.bat

이렇게 pre-revprop-change.bat 를 만들어주면 로그 수정이 가능해집니다.

trac 을 같이 쓰고 있을 때

trac 을 같이 사용하고 있다면 로그 수정을 해도 트랙의 Timeline 이나 Browse Source 에서 표시되는 섭버전 로그들은 수정되지 않는다는 것을 발견하게 될 겁니다. 따라서 로그 수정시 trac 과 자동으로 싱크를 맞춰주는 기능을 구현해줘야 합니다.

이 기능은 수정된 로그를 반영하는 것이므로 pre-revprop-change 가 아닌 post-revprop-change 에 구현해야 합니다. 안그러면 수정된 로그 메시지가 반영되지 않습니다. trac 과 subversion 다시 싱크 맞추기를 참고해서 아래와 같이 post-revprop-change 스크립트를 만들어주면 됩니다.

rem Only resync when log messages are changed.
if "%4" == "svn:log" C:\Python25\scripts\trac-admin.exe (trac_proj_dir) resync

post-revprop-change.bat

파이썬 경로와 (trac_proj_dir) 은 자신의 환경에 맞게 수정해주도록 합니다. :)

Tags: , ,

« Older entries § Newer entries »