XNA Framework의 역사
XNA는 Microsoft에서 개발한 게임 개발 프레임워크로, 2004년 GDC에서 최초로 프로젝트를 공개하여 2010년 현재 4.0베타에 이르렀습니다. your dream game - build it today - millions may play it tomorrow 라는 슬로건을 가진 XNA는 하드웨어 플랫폼에 의존하는 기존의 코딩방식에서 벗어나 PC뿐만 아니라 Xbox360이라는 게임콘솔, 미디어플레이어인 Zune, 또 현재는 Windows Phone 7까지 지원하고 있습니다.
저는 2007년부터 알게 되었지만, 당시 마케팅프로젝트를 하면서 기존의 게임시장이 철저히 플랫폼시장에 지배되고 있었던데에 반해 플랫폼에 자유로운, 보다 컨텐트에 집중할 수 있는 기술 - 당시에는 부족한 면이 없지 않았지만- 그리고 그 기술에 담긴 뜻이 참 좋았던 기억이 있습니다.
앞으로도 XNA에 대해 다루면서 나오게 되겠지만, 당시에는 XNA에 담긴 큰 뜻에 비해 마켓플레이스라든가, 정책, 라이센스 등 환경적인 요소가 열악했었던 것이 사실이었고 진입장벽이 컸던 것도 사실이었습니다. C#이라는 언어, Xbox라는 플랫폼, 마켓정책, 온라인게임시장의 전통적인 강세, 게임 콘솔 시장에서의 보급율 등은 지금도 마찬가지이지만 그 당시에는 더 큰 무언가였습니다.
또한 기술적으로도 그러했는데 http://blogs.msdn.com/b/ito/archive/2010/03/24/xna-game-studio-4-0-refactoring.aspx 를 인용하자면,
XNA는 1.0당시 Xbox360에서 .Net CF가 돌아가게 된지 고작 4개월이 지난 상태였습니다. 당시 XNA는 윈도우상에서만 가능했기 때문에 자연스럽게 Managed DirectX의 설계를 참고하게 되고, 굳이 따지자면 DirectX 9.0의 랩퍼와 같은 형태였습니다.
이러한 방침은 설계기간을 단축시킬 수는 있었지만, 추후에 Xbox360과 Windows상의 동작에 있어서의 차이점, 예를 들면, RenderTarget2D를 활용하는 차이를 깨닫게 된 때는 이미 API사양을 변경하기에는 늦어버려, 결국 Xbox 360과 Windows에서의 동작의 차이는 그대로 존재하게 되었습니다.
또한 추가한 기능을 제거하는 것이 새로운 기능을 추가하는 것보다 훨씬 더 어렵다는 것을 XNA Game Studio Express 1.0을 릴리즈 하면서 실감하게 되었습니다.
일단 추가된 기능은 사용빈도가 낮아지면 그 동안 동작했던 게임이 돌아가지 않게 됩니다. 이러한 사용빈도가 낮은 API라는 것은 귀찮은 존재로, 아무리 사용빈도가 낮아지더라도 API로 제공하고 있는 이상 해당 API가 동작되는지 여부를 확인하기 위한 테스트를 할 필요가 있습니다. 그리고 이러한 문제는 소수의 XNA팀으로서는 테스트에 드는 시간이 소요되기 때문에 신기능을 추가하는 데에 시간이 적어지면 문제가 발생하기 쉽습니다.
이 글에서도 알 수 있지만, 구조로서의 프로그램이 얼마나 많은 생각을 요하고 또 많은 시행착오를 겪어야 하는지 그 노고가 묻어납니다. 모든것은 상대적이라, 항상 그 목적에 따라 정확히 정의할 필요가 있고 발생하는 Trade-Off에 대해 적절한 선택을 해야합니다. 그런 의미에서 게임개발을 위한 Framework로서의 XNA는 다소 구조적인 접근방식으로 알아보고자 합니다.
출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=4325&MAEULNO=541&no=53339&page=1
