프로그래밍 언어 입문서가 아닌 프로그래밍 기초 개념 입문서
문과생, 비전공자를 위한 프로그래밍 입문책입니다.
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. 모두 읽기 귀찮으신 분들은 굵은 글씨와 이미지파일만 보세요...
 

댓글을 달아 주세요

  1. 66v 2012.01.02 09:26  댓글주소  수정/삭제  댓글쓰기

    좋은 글 잘 읽었습니다 :)
    비주얼 베이직으로 간단한 툴을 만들다가 C#의 필요성을 느껴서 올해부터 손을 대 보려고 했는데, WPF도 같이 살펴봐야겠군요!

    • Favicon of https://gamedevforever.com 끼로 2012.01.02 11:11 신고  댓글주소  수정/삭제

      네 C#을 쓸때에는 윈폼보다 WPF를 추천합니다! 어떻게 보면 윈폼은 실패작 같아요.. MS에서도 더이상 지원을 안하는것 같기도 하고요.. 소스관리에서도 윈폼은 두명이상 같이 작업을 하게 되면 충돌도 많이 나고..

  2. Favicon of https://gamedevforever.com zinzza 2012.01.02 10:44 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다.
    저는 회사에서 WPF를 이용해서 PC용 어플을 개발하고 있는데요.
    UI쪽은 정말 강력합니다.
    MVVM패턴으로 UI와 로직의 분리도 확실히 되고요.
    하지만 한번씩... 속 뒤집히는 일들이 많죠. 만능이 없는건 확실합니다. ㅎㅎㅎ

    • Favicon of https://gamedevforever.com 끼로 2012.01.02 11:09 신고  댓글주소  수정/삭제

      아무래도 자동으로 해주는게 많다보니.. 여러 기능들을 쓰다보면 뭐 하나 실수로 빼먹어서 작동안되는 경우도 많죠.. 에러도 안내주고 ㅋㅋ 그런데 그래도 상당히 편하긴 하니까요.. 그래서 가끔은 XAML만 쓰고 나머지 기능은 거의 안쓰고 걍 노가다(윈폼을 쓰면 노가다가 아니지만 WPF에서 자동으로 해주는 여러가지것들을 안쓰기때문에 노가다인)를 해주는게 속편할때가 있는것 같아요.. 그래서 저는 간단한 툴을 만들때에는 걍 XAML'만' 씁니다..

  3. superd33 2012.01.02 11:57  댓글주소  수정/삭제  댓글쓰기

    잘 읽었습니다.

    전 기획자 이지만...wpf로 툴을 만들고 있습니다.
    기껏해야 xml,엑셀 관리에만 쓰고 있지만요~

    사실 툴 같은 경우엔 사용하는 사람이 만들어서 사용하는 것이 가장 베스트라고 생각해요. 아무리 만드는 사람이 생각해서 만든다고 해도 사용하는 사람이 불편함을 느낄 수 밖에..ㅠㅠ

    • Favicon of https://gamedevforever.com 끼로 2012.01.02 12:03 신고  댓글주소  수정/삭제

      머,멋찌다... 우와.. 보통 기획자분들중에 좀 이것저것 만들어서 쓰시는 분들은 비베스크립트로 액셀안에서 만드는건 많이 봤는데 WPF로 툴을 만든다니 놀라워요..

  4. sgpro 2012.01.02 14:01  댓글주소  수정/삭제  댓글쓰기

    고맙습니다. ^^

  5. Favicon of https://gamedevforever.com 월하 2012.01.02 15:22 신고  댓글주소  수정/삭제  댓글쓰기

    엑셀, vba로 간단한 툴을 만들어서 썼는데 저희 게임 기본 데이터가
    xml이다 보니 관리 하기가 너무 복잡하고(사실 엑셀에서 xml파일 불러오고 바로 저장 하는 법을 몰라)
    뭔가 새로운걸 배운다는 각오로 C#으로 xml파싱 해서 아이템 툴을 만드는게 목표인데...
    wpf툴이라는게 있다니 이것도 한 번 알아봐야 할 거 같네요.
    감사합니다 ^^

    • Favicon of https://gamedevforever.com 끼로 2012.01.03 02:39 신고  댓글주소  수정/삭제

      C#을 해보신적이 없다면 C#도 같이 공부를 하시는게 좋을꺼에요.. 아무래도 C#의 기반 위에서 돌아가는것이니까요..

  6. Favicon of http://dishdev.me/ Dish 2012.01.02 20:27  댓글주소  수정/삭제  댓글쓰기

    C# 만세 (?)

  7. 알콜코더 2012.01.03 01:02  댓글주소  수정/삭제  댓글쓰기

    오오 좋은 내용 잘 읽었습니다.
    아직까지 wpf를 써본적이 없었는데 고려해봐야 겠군요

    근데 게임 코드쪽은 대부분 static lib로 만드는게 일반적인데..이걸 dll로 변환해서 연결하신건가요?

    • Favicon of https://gamedevforever.com 끼로 2012.01.03 02:37 신고  댓글주소  수정/삭제

      이전에 썼던 "울트라에디트만으로 해킹이 되는 게임"에 스샷으로 잠깐 올렸었는데 저희팀은 개발 초기부터 스태틱 라이브러리와 다이나믹 라이브러리를 모두 지원하도록 작업하고 있습니다만.. 이유는 일반 개발시에는 dll을 사용하고 빌드해서 올릴때만 스태틱을 사용하는게 더 크구요.. 아무래도 dll로 작업하는게 신경쓸것도 더 없고 빌드도 좀 더 빨라서요.. 툴개발시에는 저희팀 프로그래머 '신휘재'님이 만드신 pt자료 '엔진과 툴의 그렇고 그런사이'에 보면 C#과 C++통신시에 dll을 사용한다 라고 하면서 같이 나오는게 게임 코드와 C#을 연결하기 위해 인터페이스 프로젝트를 하나 더 만드는데요 그 인터페이스 프로젝트를 dll로 만들어서 중간다리 역활을 합니다.. 툴에서 필요한 C++ 코드도 그 인터페이스 프로젝트쪽에 모두 작업을 하고 있습니다 ㅎㅎ;

  8. Favicon of https://gamedevforever.com 친절한티스 2012.01.03 10:15 신고  댓글주소  수정/삭제  댓글쓰기

    잘읽었습니다.
    저도 툴을 C#으로 작업 중인데... 이게 은근 매력적인 언어더군요.
    WPF는 아직 안써봤는데 이쪽도 손대봐야겠네욤.

  9. smilemugi 2012.01.06 15:42  댓글주소  수정/삭제  댓글쓰기

    잘 읽었습니다. ^^

    툴을 만드는 것을 대부분 개발자들은 초보나 하는 그런 잡일(?) 정도로 여기고 있습니다. 좋은 툴을 만든다는 것은 게임을 제작하는데 있어서 60% 이상 비중을 차지한다고 생각합니다. 좋은 툴을 만들어 놔야 게임 제작에 있어서 낭비되는 시간을 줄일 수 있을테니까요.

    현업에서 게임을 만들고 있는지 십몇년이 되가고 있지만, 전 아직도 게임 만드는 것 보다는 툴 만드는 것이 훨씬 재미있던데... ^^

  10. 농약원샷! 2012.01.27 17:32  댓글주소  수정/삭제  댓글쓰기

    참고로, MS 본사에 있던 WPF 팀은 해체되었다고 들었습니다.
    UI는 화려하나 너무 무겁죠...
    앞으로 계속 지원될지도 의문이구요...

    • Favicon of https://gamedevforever.com 끼로 2012.01.27 22:22 신고  댓글주소  수정/삭제

      MS에서 WPF팀을 해체한것 같긴 한데 XAML은 버리지 않을것 같습니다. 사실 WPF UI가 느린 이유는 XAML이 아닌 그 외에 다른 기능들 때문인데 XAML의 능력은 충분히 검증됐다고 생각합니다. 참고로 XML 기반이라고 해서 실행시간중에 UI 레이아웃을 읽어서 느릴꺼라고 생각하시는 분들도 가끔 계신데 XAML은 컴파일되어 바로 실행가능한 형태의 바이너리로 나옵니다.

  11. Favicon of https://blueasa.tistory.com blueasa 2012.01.29 02:07 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 정보 감사합니다.
    윈폼으로 만들어댔는데..
    WPF를 한번 봐야될 것 같네요. =_=