einsub 님이 10대 공개 게임 엔진 (Top 10 Open Source Engines)을 올려주셨군요.
  1. OGRE
  2. Irrlicht
  3. Crystal Space
  4. jME
  5. Panda3D
  6. Reality Factory
  7. The Nebula Device 2
  8. RealmForge GDK
  9. Blender Game Engine
  10. OpenSceneGraph
이중에서 접해본 건 Ogre3D 하나뿐이네요.

Reality Factory는 "C++ 코딩을 할 줄 모르는 사람들이 간편하게 게임을 제작할 수 있도록 래핑했다"는데, 그래서 어느 정도의 프로그래밍 실력이 필요한지 궁금합니다. XNA와 비교할 때, 어느 쪽이 더 나을런지. (요즘 주요 관심사 중의 하나는 쉽고, 간단하게 Prototype을 만드는 거라.)

혹시 위의 엔진들 중에서 사용해 보신 게 있으면 경험담을 Trackback이나 답글로 달아주시면 감사하겠습니다!


(마지막으로 출처인 DevMaster3D Engines Database을 통해서 상용 및 공개 게임 엔진들에 대한 정보를 제공하고 있으며, 여러가지 기준들(예: 물리, Graphics API, 지원 OS 등)에 따라서 손쉽게 찾아볼 수 있습니다.)
:

지난번의 "실전 애자일 게임 개발"의 지속적인 통합(Continuous Integration)을 하려면, 코드가 제출될 때마다, 구축을 해야 합니다.

이걸 일일히 하려다 보면, 프로그래밍할 시간을 앗아갈 것이 틀림없죠. 그런데 만약 이걸 놀고 있는 PC에게 대신시킬 수 있다면? 이걸 자동화해주는 게 바로 "CruiseControl"입니다.

CruiseControl이 하는 일은 크게 두 가지입니다:
  • 자동 구축: 정기적으로 혹은 필요할 때마다(예: 코드가 제출될 때마다) 자동으로 구축을 시도한다.
  • 결과 보고: 구축이 완료된 후, (HTML 형태의) 결과 보고서를 생성한다.
    • 왼쪽에서는 해당 프로젝트의 이름이전 빌드에 대한 정보를,
    • 오른쪽에서는 빌드의 결과(예:컴파일 오류, 테스트 결과, 이전 빌드 이후로 변경된 파일들)에 대한 정보를 제공한다.

사용자 삽입 이미지

CruiseControl의 결과 화면



따라서 CruiseControl를 사용하(여 지속적인 통합을 하):
  1. 프로그래머가 프로그래밍에 집중할 시간이 늘어나고,
  2. 오랜 시간이 걸리는 빌드를 퇴근한 후, 자동적으로 시행되게 할 수 있으며,
  3. 일일 빌드를 통해 모든 코드가 제대로 동작하는지 검증할 수 있습니다.

CruiseControl가 다른 도구들에 비해 가지는 장점들은:

CruiseControl 설치시에 참고할만한 글이나 서적은 다음과 같습니다:

지속적인 통합(CI)에 도움이 될만한 글들은 아래와 같습니다:

CruiseControl외의 고려해볼만한 CI Server들은 다음과 같습니다:

마지막으로 현재 CruiseControl을 사용하고 계신 분이 있다면, 그 사용 후기를 Trackback(혹은 답글)으로 부탁드립니다. 불행히도 저는 프로그래머도 아니고, TDD를 반기는 프로그래머들을 만나지 못해서, 아직까지 CruiseControl를 사용해보지 못했네요.
:

애자일 이야기에 "극과 극"으로 올라온 글로 생산성의 원동력에 대한 색다른 시각을 던져줍니다. (아래는 일부만 발췌했으니 원문을 꼭 보세요.)

XP 개발을 위한 개발 생산성 향상 파노라마 (2006/12/16)

"마이크로소프트(이하 MS)의 XIT Sustained Engineering 팀은 MS의 80여개의 애플리케이션을 유지 보수한다. 주로 버그 수정(작업 시간이 120시간 미만인 것들) 같은 작은 변경 요청을 처리하는데, 하나의 변경 요청이 처리되기까지 걸리는 시간(리드타임)이 통상 5개월이었다. 해당 팀은 비즈니스 유닛에서 최악의 퍼포먼스를 차지한 셈이다.

그런데, 새로운 자원을 추가하지 않고, 기존의 설계, 코딩, 테스팅 등의 엔지니어링 작업 방식에 변화를 주지 않으면서 어떻게 작업이 쌓이고(queue) 추정하는지를 바꾸는 것만으로 9개월 만에 리드타임을 14일로 줄였다. 아무리 긴 변경 요청도 5주를 넘지 않았다. 납기일을 맞추는 확률은 이전의 0%에서 90%가 넘는 수치로 바뀌었다.

이제 이 팀은 해당 유닛에서 최고의 팀으로 바뀌었다. 최악에서 최고로.

이 사례의 성공 요인은 린(Lean)과 제약 이론 그리고 애자일 원리를 적용한 데서 찾을 수 있다.

사람들은「우리는 인력이 부족해」라는 말을 쉽게 뱉는다. 그 말은 모든 다른 문제를 탈색시켜 버리는 강력한 효과가 있다. 「입 다물어」가되는 셈이다. 인력이 부족하다고 말하는 순간 더 이상 논의가 필요 없게 되는 것이다. 필자는 그 이면에 우선 상상력의 빈곤이 자리 잡고 있다고 본다."

출처: 마이크로소프트 (ZDnet에서 재인용)

참고로 제가 김창준 님을 익스트림 프로그래밍의 역자 이전에, ZDnet의 기고가로 기억하게 만든, 아주 인상깊은 글입니다.
:

고맙게도 남기룡 님께서 Noel LlopisA Day in the Life를 번역해주셨군요:

01


말마따나 XP 중에서짝 프로그래밍을 게임에 활용하는 모습을 생생하게 보여주고 있습니다.

(참고로 A Day in the Life는 개발자 지망생들에게 게임 개발자들의 일상을 소개하고자 하는 목적으로 개설된
Game Developer Magazine의 취업 안내서(Career Guide)의 한 코너입니다.)

마지막으로 시간을 쪼개서 번역해주신 남기룡 님께 감사드립니다!
:
이번 GDC 2007에서 Multi Core Process가 대세이더니, 어느 새 The Transition to Concurrency라는 Article이 나왔다.

차세대 Console을 거의 개발하지 않는 한국에서는 먼 이야기처럼 들릴지 모르지만, 이미 이것은 곧 다가올 (당연한) 미래라고 생각한다.

GITISS에 번역을 요청했는데, 과연 얼마나 걸릴런지.
: