주요 내용은 Agile 기법들 중의 하나인 XP를 다루고 있습니다. Clinton Keith가 주로 다룬 Scrum이 프로젝트 관리에 가깝다면, XP는 좀더 프로그래밍에 가깝습니다. 실전이라는 표현답게, 비교적 구체적인 실천 사항들(practices)을 이야기합니다. (from the trenches를 직역하면 '(최전선의) 참호로부터'가 됩니다.)
(가급적 아래의 압축 파일을 받으시길 권합니다. 위의 슬라이드에는 '슬라이드 노트'가 없습니다.)
제1부: 일정 맞추기 1. 아는 체 하지 마라. 2. 상황을 파악한 다음에 움직여라. 3. 제품-일정-비용의 삼각형을 기억하라. 4. 어둠 속으로 돌진하지 마라. 5. 무결점 이정표를 사용하라. 6. 팀워크를 유지하라. 7. 일정에는 조삼모사가 없다. 8. 일정이 밀리면, 전열을 가다듬으라. 9. 밑바닥 기술이 중요하다. 10. 설계할 때는 설계만 한다. 11. 만들어야 출시할 수 있다. 12. 호환성은 카누 만들 때나 필요하다.
제2부: 위대한 소프트웨어 13. 고객을 감동시켜라. 14. 통일성이라는 한 가지 명제만 기억하라. 15. 설계 사상을 명확하게 잡아라. 16. 비교하라. 17. 균형을 맞춰라 18. 발전시켜라. 19. 제품을 층층이 쌓아라. 20. 공유할 비전을 정하라.
게임의 목적은 서쪽과 북쪽에서 들어오는 적들이 각각 동쪽과 남쪽에 도달하지 못하도록 막는 것입니다.
이를 위해서 공격 기능을 갖춘 탑들을 배치합니다.
적을 죽이면 돈을 얻고, 그것으로 새로운 탑을 건설하거나, 기존 탑을 업그레이드할 수 있습니다.
팁을 알려드리면, 동쪽과 남쪽 주변의 길을 빙돌아가도록 탑을 건설하는 것입니다.
단, 날아다니는 적(Flying)은 지상의 진로를 무시하니, X축과 Y축에 따라 별도의 대공망(Antiair Tower)를 구축하시길 권해드립니다.
이런 게임을 유럽과 북미에서는 Casual Game이라고 부릅니다.Popcap과 EA의 Pogo.com에 가시면 플래쉬 기반의 설치가 필요 없는 게임들을 보실 수 있을 겁니다.
반면 우리가 캐주얼이라고 부르는 게임은 Middlesession(혹은 Middlesection?) MACG(Multiplayer Advanced Casual Game?)라고 불리는 것 같습니다.
이런 게임들이 매출을 내는 방법은 여러가지 방법이 있지만, 이 게임의 경우는 광고이군요:
처음 게임이 로딩되는 몇초간 광고가 출력됩니다.
북미 광고 시장의 규모는 상상을 초월합니다. 2007년에는 20조 원에 달할 것으로 예상되니까요. 유명한 Google의 수입 대부분은 광고이고, 이제는 인터넷 검색뿐 아니라, 음성, 인쇄물, 게임, 라디오 등 다양한 분야의 광고 시장 진출을 모색하고 있을 정도입니다. (그리고 유명한 트루먼 쇼도 PPL 광고 수입으로 매출을 낸다고 하죠.) 미국에 한 번 가보신 분은 얼마나 광고가 (중독이라고 할만큼) 그들의 삶에 침투해 있는지 아실 겁니다.
한국은 북미나 유럽보다 발전된 온라인 게임들이 많은 것은 분명하지만, 반면에 다채로움이 적은 듯 합니다. 어쩌면 시장 규모가 작아서 하위 문화가 생존하기 어렵고, 유행이 빨라서 그런지도 모르겠습니다.
게임을 개발하는 "또 다른 길"이 있다는 것을 잊지마세요. 언제 기회가 되면 Casual Game에 대해서도 한 번 다루어 보겠습니다.
Reality Factory는 "C++ 코딩을 할 줄 모르는 사람들이 간편하게 게임을 제작할 수 있도록 래핑했다"는데, 그래서 어느 정도의 프로그래밍 실력이 필요한지 궁금합니다. XNA와 비교할 때, 어느 쪽이 더 나을런지. (요즘 주요 관심사 중의 하나는 쉽고, 간단하게 Prototype을 만드는 거라.)
혹시 위의 엔진들 중에서 사용해 보신 게 있으면 경험담을 Trackback이나 답글로 달아주시면 감사하겠습니다!
(마지막으로 출처인 DevMaster는 3D Engines Database을 통해서 상용 및 공개 게임 엔진들에 대한 정보를 제공하고 있으며, 여러가지 기준들(예: 물리, Graphics API, 지원 OS 등)에 따라서 손쉽게 찾아볼 수 있습니다.)
마지막으로 현재 CruiseControl을 사용하고 계신 분이 있다면, 그 사용 후기를 Trackback(혹은 답글)으로 부탁드립니다. 불행히도 저는 프로그래머도 아니고, TDD를 반기는 프로그래머들을 만나지 못해서, 아직까지 CruiseControl를 사용해보지 못했네요.
"마이크로소프트(이하 MS)의 XIT Sustained Engineering 팀은 MS의 80여개의 애플리케이션을 유지 보수한다. 주로 버그 수정(작업 시간이 120시간 미만인 것들) 같은 작은 변경 요청을 처리하는데, 하나의 변경 요청이 처리되기까지 걸리는 시간(리드타임)이 통상 5개월이었다. 해당 팀은 비즈니스 유닛에서 최악의 퍼포먼스를 차지한 셈이다.
그런데, 새로운 자원을 추가하지 않고, 기존의 설계, 코딩, 테스팅 등의 엔지니어링 작업 방식에 변화를 주지 않으면서 어떻게 작업이 쌓이고(queue) 추정하는지를 바꾸는 것만으로 9개월 만에 리드타임을 14일로 줄였다. 아무리 긴 변경 요청도 5주를 넘지 않았다. 납기일을 맞추는 확률은 이전의 0%에서 90%가 넘는 수치로 바뀌었다.
이제 이 팀은 해당 유닛에서 최고의 팀으로 바뀌었다. 최악에서 최고로.
이 사례의 성공 요인은 린(Lean)과 제약 이론 그리고 애자일 원리를 적용한 데서 찾을 수 있다.
사람들은「우리는 인력이 부족해」라는 말을 쉽게 뱉는다. 그 말은 모든 다른 문제를 탈색시켜 버리는 강력한 효과가 있다. 「입 다물어」가되는 셈이다. 인력이 부족하다고 말하는 순간 더 이상 논의가 필요 없게 되는 것이다. 필자는 그 이면에 우선 상상력의 빈곤이 자리 잡고 있다고 본다."