트위터

너도나도 트위터라길래 사실 가입은 꽤 오래 전에 했었지만 이눔의 게으름 때문에 바쁨을 핑계로 쌩-하고 있다...이판사판으로 그냥 함 공개해 봅니다. ㅡㅡ;

물론 아직 내용은 없지만...관심 있는 분들은 뭐 관심들을 ㅋ

http://twitter.com/kimsama/

by kimsama | 2009/08/21 14:58 | General | 트랙백 | 덧글(0)

임포트 라이브러리



이전 '임포트 파이프라인'의 글에서 이 파이프라인에 효과적으로 사용할 수 있는 라이브러리가 업데이트 되었습니다.

http://code.google.com/p/meshimport/


릴리즈된 것은 좀 되었지만 프로젝트에 실제로 적용하기 위해서는 FBX 포맷의 지원이 필요한데 이 부분이 이번 업데이트에서는 지원하도록 추가되었네요.


by kimsama | 2009/08/18 18:28 | Development | 트랙백 | 덧글(0)

Erich Gamma 내한


내한한 Erich Gamma씨의 세미나를 다녀 왔습니다. IBM의 Jazz, RTC 마케팅 성격이 강하지 않을까 했는데 역시나...

내용은 이클립스를 시작하다 오픈 소스화 했는데 그러고 보니 전세계에 퍼져 있는 개발자들과의 협업의 중요성을 뼈져리게 느끼고 협업을 위한 플랫폼으로  Jazz를, 솔루션으로는 RTC를 개발하게 되었다... 뭐 이런 스토리였습니다. 훌륭하니 사라는 이야기지요. ^^

아주 예전에 네뷸라 커뮤니티에서 통합 툴 프레임워크로 이클립스를 사용하자는 이야기가 있었는데 (주창자는 브루스씨 -_-) 그닥 호응하는 사람이 없어서 이슈화되지 못하고 그냥 사라져 버린 일이 있습니다. 이클립스가 게임용 툴 프레임워크로는 어떨지 모르겠네요. 스펙만 보면 훌륭해 보이기도 하지만 또 이론과 실제가 틀린지라. 그런 사례를 아직 들어본 적도 없긴 합니다. (혹 아시는 분은 코멘트 부탁드려요)

눈으로 확인한 것 중에서 게임용 툴 프레임워크로 적합한 것이라고 하면 (네이티브를 고집한다는 전제하에서) 인썸니악의 Nocturnal Initiative를 추천합니다.


...사진이라도 한장 찍어 둘걸 그랬나요, 블로그에라도 걸게 말예요... ^^;

by kimsama | 2009/08/18 18:24 | Development | 트랙백 | 덧글(0)

임포트 파이프라인


원문은 Gamasutra의 Sponsored Feature: The All-Important Import Pipeline

아트 에셋을 게임 내로 삽입하는 방법에 대한 글.

아트 에셋을 게임 내로 삽입하는 방법은 크게 Export하는 방식과 Import하는 방식의 두 가지로 구분할 수 있다. 첫 번째 Export의 방법은 겜브리오나 Nebula의 DCC 툴의 플러그인을 사용하여 DCC  툴로부터 아트 에셋을 바로 게임 엔진으로 삽입할 수 있는 형태로 변경, 삽입하는 방법을 말한다. 두 번째 Import 방식은 게임 엔진에서 DCC 툴의 파일 포맷을 그대로 임포트하는 방식. 물론 나중에 게임 데이터를 베이킹(-Baking 혹은 쿠킹이라고도 한다)하는 과정에서 익스포트 방법의 플러그인이 하듯 최적화 등의 작업이 필요하다.

아트 에셋의 파이프라인 형태 여부에 따라 엔진을 구분해 보면 다음과 같이 분류할 수 있다.

익스포트 - 겜브리오, 네뷸라, Torque
임포트 - Unity3D, 언리얼(사실은 익스포트의 특징도 가지고 있다)

이를 레벨 에디터의 관점에서 살펴 보면 1) DCC 툴을 레벨 에디터로 사용하는 경우에는 익스포트의 방법이 적합하고 별도의 2) In-house 레벨 에디터가 있는 경우에는 임포트 방식이 적합하다.

개인적으로는 Unity3D의 FBX 방식이 편리해서 생산성 측면에서는 높은 점수를 주고 싶다. (최근의 Unity3D 2.5 버전부터는 .max 파일을 바로 임포트할 수도 있다.)

Nebula의 경우는 애초에 RadonLabs에서 레벨 에디터 마야를 사용하기 때문에 (사실 외국의 경우에는 이런 스튜디오가 꽤 된다) 1)의 방식에 해당한다. 그래서 엔진 코드 역시 여기에 맞게 2)에 대한 고려가 없다.

레벨 에디터의 경우 DCC 툴을 사용하느냐, 별도의 레벨 에디터를 사용하느냐는 만들고자 하는 게임의 성격에 달라지게 된다. 콘솔 게임의 경우 DCC 툴을 이용해도 무방하겠지만 MMORPG의 경우에는 반드시라고 해도 좋을 정도로 In-house 레벨 에디터가 필요하다. 라이브 서비스를 생각하면 당연한 일이다.

이를 바탕으로 정리해 보면,

Nebula로 MMO를 만드는 경우라면 아트 에셋 파이프라인에 대한 모범 답안은 우선 레벨 에디터를 만들고 맥스 데이터를 바로 임포트할 수 있는 모듈(을 만들 수 없다면 .fbx 파일을 임포트 하도록 하자)을 만드는 방법이다. 물론 최종적인 게임 데이터 빌드 과정(포스트 빌드)에서 최적화하는 것도 포함해서.


관련 글: Tom Forsyth 블로그의 Game Editor vs DCC Tools.

[1] fbx 파일 포맷은 그리 어렵지 않게 파싱이 가능하고 자료도 꽤 흔한다 .max 파일에 대한 내용은 어디에?
[2] 현실의 모범 답안은 대개 여건이 허락치 않아 우회하는 경우가 대부분...아닌가? ㅋ


by kimsama | 2009/07/28 00:48 | Development | 트랙백 | 핑백(2) | 덧글(3)

Mercurial - 장점과 활용

분산 버전 제어 시스템(DVCS, Distribute Version Control System)에 대한 이야기는 예전에 여기에서 잠깐 소개한 적이 있습니다.

그새 Google Code에서도 SVN에 이어 DVCS 중 하나인 Mercurial을 지원하는 등 근래에 들어 DVCS가 빠르게 확산되고 있는 듯. (Bazaar나 Git이 아닌  Mercurial을 Google Code의 DVCS로 지원하는 것은 Mercurial이 기존의 SVN 히스토리를 그대로 옮겨 올 수 있기 때문인듯...)

분산 버전 제어 시스템의 차이점과 장점, 그리고 간단한 사용법에 대한 내용이 최근 IBM 개발자 사이트에 (훌륭하게 번역까지 되어서!) 올라와 있습니다.


SVN의 경우 용량이 커지게 되면 많이 느려지게 되는데,  비교적 큰 팀에서 쉴 새 없이 커밋을 하다보니 어느새 불편할 정도로 느려져 버렸습니다.  위의 글에서도 DVCS가 SVN 보다 3배에서 10배 빠른 속도를 제공할 수 있다는 내용이 있는데 사내 SVN을 DVCS로 교체하면 아마 10배 이상의 속도를 얻을 지도 모르겠습니다. 물론 덤으로 강력한 저항도 따르겠지요. ㅡㅡ;

사용중인 SVN을 그대로 옮겨 오는 것도 가능하고 TortoiseHg라는  GUI 클라이언트도 있으니 변경에 무리는 없어 보입니다. (다만 Mac 에서는 빌드된 배포판이 없어  TortoiseHg을 사용하려면 번거롭지만 직접 빌드해야 합니다.)

관심 있으신 분들은 Google Code에 테스트 프로젝트를 하나 만들어서 사용해 보시는 것도 괜찮겠네요. (Mercurial을 지원하는 유사한 사이트로는 ShareSource라는 곳도 있습니다)


by kimsama | 2009/07/15 10:39 | Development | 트랙백 | 덧글(4)

근황


...같은 포스팅은 잘 안하는 편인데

최근 워낙 글이 뜸했군요.

바빴죠...뭐 -_-;


여러분들이 관심 가질만한 소식으로는...글쎄요,

올해 KGC에는 Wolfgang Engel씨가 올 듯 하다는 이야기와

저도 트위터 가입했으나 멍...때리고 있다는 이야기 정도... ^^;



N3 이야기는 또 차차 시간 나는대로 정리해서 올리도록 하지요~ 그럼 총총...

by kimsama | 2009/07/07 11:20 | General | 트랙백 | 덧글(1)

◀ 이전 페이지다음 페이지 ▶