꽃미남 프로그래머 김포프가 창립한 탑 프로그래머 양성 교육 기관 POCU 아카데미 오픈!
절찬리에 수강생 모집 중!
프로그래밍 언어 입문서가 아닌 프로그래밍 기초 개념 입문서
문과생, 비전공자를 위한 프로그래밍 입문책입니다.
jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다.
Posted by 알 수 없는 사용자
오늘 포스팅할 주제는 '툴' 입니다!
이전에 가벼운 해킹에 대한 주제를 골랐었는데..
웬지 이번에도 해킹에 대해 쓰게 되면 계속 그 주제만 만지게 될 것 같아서..
이번엔 툴! 툴에 대해서 이야기를 해보려고 합니다.

게임을 만들때에는 툴도 항상 만들게 됩니다.
특히 요즘에는 툴의 중요성이 더욱 늘어난 것 같습니다.
물론 좋은 엔진을 구입하면 좋은 툴이 포함되어 나오기 때문에 만들지 않는 경우도 있습니다..
하지만!! 저희팀은 좋은 엔진을 구입하지 않았기 때문에.. 툴을 만듭니다!


그런데 툴을 만들때에 툴만 전문으로 만드는 프로그래머가 있는 팀은 거의 없을겁니다.
그렇다보니 툴에 대해 전문적이지 않은 게임프로그래머들이 툴을 만들게 되고 그러다보면 가끔씩은 툴툴대며 만들기도 합니다.. 

또 툴을 만드는것이 익숙하지 않다보니 실수아닌 실수가 많이 생기게 됩니다.그 중에 가장 큰 실수는 아무래도 툴을 위한 코드가 생각보다 커지는것이 아닐까 생각됩니다. 이것을 줄일 수 있다면 이것 자체만으로도 오버엔지니어링을 최소화하는 방법이라고 볼 수 있을것입니다.

툴을 만들때 중요한것은 레이아웃이라고 생각합니다. 레이아웃을 쉽고 빠르게 만들 수 있어야 좋은 툴을 만들 수 있습니다. 그렇지 않고 정말 기능만을 가진 벽돌같은 툴을 만든다면 작업자들이 사용하는데 굉장히 불편해할 것입니다. 속도가 빠른것보다는 편의성이 좋아야 작업자가 작업을 더 빠르게 할 수 있을테니까요.. 

그런데 가끔 팀 내부에서 쓰는 툴이라고 해서 레이아웃에 신경쓰지 않고 만드는 경우를 종종 보게 되었습니다. 그렇게 되면 툴을 사용하는 작업자들이 불편하게 계속 쓰게 되고 그런것들이 쌓여서 전체적인 개발 시간에도 영향을 주게 되기도 합니다. (그래서 좋은 엔진을 사는게 좋은것 같습니다. 좋은 엔진에는 좋은 툴이 있으니까요.)

또는 레이아웃에 신경을 쓰지만 그것을 위해 툴을 위한 코드가 과하게 많아지는 경우도 존재합니다. 이것은 툴의 개발 및 유지를 힘들게 하고 또한 마찬가지로 개발 시간에 영향을 주게 될 것입니다.

그래서 저는 C# WPF로 툴을 만드는것을 추천하려고 합니다.

C#으로 툴을 만드는것에 거부감을 가지시는 분들이 생각보다 많은것 같습니다. 거부감을 가지고 계신 분들은 대부분 C#으로 툴을 만들게 되면 엔진은 보통 C++이기 때문에 C++과 C#의 통신을 위해 CLR을 작업했던 분들입니다. C++에 있는 기능을 C#에서 쓰기 위해 CLR로 C++ 클래스들을 모두 랩핑을 하고.. 또 C++이지만 C++이 아닌 이상한 환경에서의 비정상적인것처럼 보이는 동작을 CLR 작업을 하면서 겪으셨기 때문일것입니다. 그런데 MFC로 작업을 하게 되면 어차피 C++이니 이러한 작업이 필요없어지고 또 MFC도 많은 발전을 해와서 레이아웃을 작업하는데 굉장히 편해졌기 때문에 MFC를 더 선호하시는 분들이 많습니다.

일단 이부분에 대해서 말씀드리자면 저도 역시 CLR로 C++과 C# 통신을 만드는것은 추천하지도 않고 저희팀에서는 CLR 작업은 전혀 하지 않습니다. CLR이 쉽게 익숙해지지 않아서 작업하는데 많은 불편함이 있고 클래스들을 랩핑하는것 또한 위에서 말한 오버엔지니어링에 속한다고 생각하기 때문입니다.

그래서 저희팀에서 사용하는 방법은 Dll Interop을 사용하여 C++과 C#의 통신을 합니다.
 (출처 - 신휘재님의 '엔진과 툴의 그렇고 그런 사이')

이에 대한 자세한 내용은 신휘재님의  '엔진과 툴의 그렇고 그런 사이'을 참고해주세요.. 어쨋든 그래서 저희팀은 C#을 사용합니다.

그리고 WPF를 사용합니다.

WPF를 사용하게 된 이유는 상당히 단순하지만... WPF의 장점은 WPF를 사용하는것을 후회하지 않게 만들어줄 것입니다. WPF는 툴의 레이아웃을 굉장히 쉽고 빠르게 그리고 강력하게 만들 수 있습니다. 

툴을 만들때는 먼저 레이아웃을 잡아보고 기능을 사용하는데 문제가 없는지 불편하지는 않은지의 확인이 빠르게 되어야 합니다.

애니메이션 프레임에 이벤트를 설정하는 기능을 툴에 넣어야 한다고 예를 들어봅시다. 필요한 기능은 먼저 애니메이션을 볼 수 있어야 하고, 재생할 수 있어야 하고, 특정 프레임에 이벤트를 설정하고 어느 위치에 설정되었는지를 볼 수 있고 이벤트의 특성에 따라 작업자가 다르기 때문에 구분하기 쉽게 만들고.. 등등

이러한 용도로 제가 만든 레이아웃은 아래와 같습니다.

필요한 기능들은 모두 들어있고 사용하기 편한건 모르겠지만 뭐 나쁘지는 않은것 같습니다. 이 레이아웃을 만들고 테스트를 해보는데 걸린 시간은 얼마나 들었을까요?


WPF에서는 위의 코드가 전부입니다. xaml을 이용하여 레이아웃을 만들기 때문에 작업하기도 상당히 쉽습니다. 해당 레이아웃을 테스트해보기까지 걸린 시간은 웹서핑을 하면서 딴생각을 하면서 작업을 해도 몇십분 정도면 충분히 테스트가 가능할 정도입니다.

물론 테스트를 어느정도 해본 이후에 이 코드를 기준으로 커스텀 컨트롤을 만들거나 정리를 하는 시간이 필요하긴 합니다만, 그렇다 하더라도 레이아웃 자체에 들어가는 시간은 많지 않습니다. 커스텀 컨트롤을 만들어야 할 때에도 컨트롤 안에 컨트롤을 넣는것이 자유롭기 때문에(어찌보면 당연한것이지만 MFC나 윈폼에서는 쉽지 않죠..) 컨트롤을 만드는것에 부담이 거의 없습니다.

여기에 조금만 더 신경을 쓰면 프로그래머 센스이어서 이쁘지는 않지만 보기에 나쁘지는 않게 만드는것도 어렵지 않습니다.

레이아웃을 만드는데에 부담이 거의 없기 때문에 툴을 만들때에는 실제 기능과의 연결에만 신경써주면 좋은 툴을 보다 쉽게 만들 수 있을 것입니다.

게다가 WPF는 접근하기도 상당히 쉬운 언어입니다. 사실 WPF는 XAML로 레이아웃을 만든다는것 외에도 굉장히 많은 기능들을 제공합니다. 간단하게 나열해보면..
  • Dependency Property 
  • Attached Property 
  • Routed Event 
  • Attached Event 
  • Trigger 
  • Style 
  • Animation 
  • Rendering
  • 등등등
많은 기능들을 제공하고 있고 실제로 이런것들을 모두 알면 더 쉽고 더 이쁘게 WPF로 작업을 할 수 있습니다. 심지어 WPF에서는 컨트롤들 렌더링이 DX기반으로 돌아가기 때문에 픽셀쉐이더도 사용할 수 있으니까요..

하지만!! 이런것들을 모두 몰라도! XAML과 C#의 기본적인 문법만 알고 있어도 툴을 만들기에는 충분합니다! C#을 공부해야 하는것은 어쩔 수 없지만 XAML은 XML을 써본적이 있다면 따로 공부할 필요도 없습니다! XAML이 XML을 그대로 가져다 사용한 것이니까요. 다른 기능들은 차근차근 천천히 알아가면 되는 것입니다..

또 툴을 만들때에 C#으로 만들다보면 C++에 이미 구현되어있는 기능들도 C#에서 다시 한번 구현하는 경우도 있습니다.. 물론 이런 경우는 많이 없겠지만 어쨌든 이것 역시 하지 않아도 될 일을 하는 것이기 때문에 오버 엔지니어링이 된다고 생각합니다. 예를 들면 툴에서 카메라를 사용하기 위해서 카메라 제어를 C#에서 하기 위해 카메라 관련된 모든 코드를 C#에 따로 만든다던지..

또는 조금 극단적인 얘기지만 C#에서 게임내 시스템을 제어하기 위해 과하게 많은 코드를 만드는 경우가 생길수도 있습니다.

이런 코드는 유지해나가는데에도 상당히 힘듭니다. 있는건 있는걸 그대로 쓰고 C#에서는 정말 레이아웃과 기능의 연결 부분 위주로만 만드는것이 여러가지로 좋을 것입니다.


툴을 만드는 프로그래머나 툴을 사용하는 작업자분들이나 모두 스트레스 받지 않고 일할 수 있도록 합시다! 화이팅!



ps. 모두 읽기 귀찮으신 분들은 굵은 글씨와 이미지파일만 보세요...
 
반응형
,