[Unreal 게시판] UE4의 blue print는 과연 좋은 선택이었을까요

Question>

질문 원문 link:
http://cafe.naver.com/unrealenginekr/1270

UE4의 blue print를 분석해보는 도중인데, 너무 어렵다는 생각이 듭니다.
개인적인 생각인데, blue print는 designer들을 위한 배려는 아닌거 같습니다.
너무 난해하단 생각이 드네요.

저는 디자이너는 아닌데요. C/C++ 만 꽤나 오랫동안 해온 사람입니다.
나름 system level의 assembly language도 잘 다루는 편이구요.
그러다보니 blue print를 보면서 딱 느껴지는 느낌이 있네요.. 마치...
무슨 H/W 회로 짜는 듯한 느낌이 드네요. -_-;

그냥 blue print로 보면 단순해 보이는데
작동시키면서 step by step으로 들어가면서 보다보니 못보던 graph들이 막 나오네요.
겉으로 보는건 그냥 단순한거지만
사실 모든 component들마다 graph 구조로 code가 들어가있나보더군요..
그래서 그런지 추적하면서 보다보니까 이거 진짜 빡시다란 생각이 드네요..

차라리 C/C++ 이던 C# 이던
코드를 훑어서 쭈~욱 보는게 훨씬 편리할거 같다는 생각이 들고
블루프린트가 훨씬 더 빡셔보이네요..

물론, 심플한 구조는 간단하다고 할지모르겠습니다만
블루프린트로 만드는 것이 좀 무거워 진다면 거의
하드웨어 회로 분석하는 느낌이 들거 같다는 생각이 드네요..
그래서 제가 생각이 든게 이 블루프린트라는건
디자이너를 위한게 아니구나라는 생각이 들었네요..

홍보로는 프로그래밍 한줄없이 게임을 만든다고 홍보를
하고 있지만 사실상 블루프린트의 모듈들 전부가 프로그래밍 짤때 로직을 이용하고 있는데요..
그 로직이 거의 하드웨어 회로로직이라는 거져..

마치,
전자분야에서!!!!!!!!!!!!!!!!!!
PLC 라는 자동화칩에 프로그래밍할때 래더라고 부르는
사다리꼴 그래프를 이용하거든요!!!!!!!!!!!!!!!!!!!!
프로그래밍을 모르는 아저씨들이 할 수 있도록 래더라는 그래프구조로 짜게
해주는데요.. 블루프린트랑 거의 비슷한 식이라고 보면될듯요..

근데,
사실 그 전자분야는요 추세가 어떻게되어 가고 있냐면요..
더이상 래더(그래프)로 프로그래밍하던 것들은 사장되어가는 추세이구요!!!!!!!!!!
요즘은 전부 C 로 프로그래밍하는 식으로 차차 바뀌어가고 있슴돠!!!!!!!!!!
무슨 얘기를 하고 싶었던 거냐면요..



첫번째는,
blue print는 programming을 전혀 모르는 사람이
배우고 시작하는데 약간 도움이 될지 모르지만
그렇다고 들어가는 노력이 C/C++ 을 공부하는 것보다 적느냐?

그건 아닐거 같다라는 생각이 들구요.

게다가 덩치가 조금이라도 커지면 눈돌아갈듯하네요.. 미쳐버릴듯.. -_-;
(최소한도로 사용해야 맞는거 같다는 생각이듬!!!!!!!!!!!!)



두번째는,
programming을 원래 하던 사람은 blue print를 접하면 상당히 답답할거 같다는 생각이 듭니다.

code로 몇줄이면 알기쉬운 내용이 graph로 이뤄져 있다보니
명확하게 뭘 의미하는지 처음에는 의미파악이 좀 힘드네요!!!!!!!!!!!!!!!

그리구,
블루프린트를 공부하는게 C/C++ 공부보다 더 빡신레벨일거 같다는 생각이 듭니다.
왜 이런생각이냐면, C/C++ 을 잘하는 사람들도 어려워하는 분야가 저수준 분야인데
마치 인풋 아웃풋만 갖고 하드웨어제어를 할때 느껴지는 그런 느낌이 블루프린트 냄새임.. -_-;

사실상, blue print가 H/W 회로 짜는거랑 거의 비슷함!!!!!!!!!!!!!!!! -_-;

잘 모르는 사람들은 인풋과 아웃풋만 갖고 짜면 쉽다고 생각할 수
있는데 원래 아무것도 모르는 사람은 인아웃만 생각하면 되니까 쉬울수도..

근데, 좀 아는 사람은 인아웃만으로
만족하지 못하고 내부작동 구조를 알아야 뭘 할 수 있다고 생각하기 때문에
오히려 기존에 지식이 있던 사람들이 더 접근하기 어려울거 같음.



여튼.. 깊이 있게 본건 아니지만..
제가 그냥 겉으로 느낀 결과로는요..
블루프린트는 진짜 단순 로직을 짜는데만
사용해야겠다라는 생각이 듭니다..

나머지는 전부 직접 코드로 짜고 갖다가 이어 붙이기할때만 그니까 로직조합
에만 단순하게 사용해야지 안그러면 이거 완전 하드웨어 회로만드는거랑
비슷하겠다라는 생각이 듬.. 그만큼
블루프린트가 사실상 저수준 제어작업에 가깝다는 느낌..
어쩌면, 상당히 숙련된 프로그래머들을 위해서 만든거 라고 보는게 맞을듯..

홍보는 근데 programming 한줄 모르는 designer도
game 직접 만들고 제어할 수 있다라고 홍보하니까..
상반된 면이 좀 있네요..

제 생각과 다른느낌.. -_-;
완전 고도로 숙련된 programmer를 위해서
만들어진 저수준 제어용 tool이 blue print 아닌가라고 정리를 해봄..
뭐 다들 느낌차가 있겠지만..

-------------------------------------------------------------

Answer>

초기의 unreal은
kismet이나 blue print가 없었습니다.

그러다가,
visual object과 source code의 연결을 '편하게' 할 필요가 생겼고,
( 예> character가 문 앞에 갔을 때, 문이 열리는 거 )
그래서, UE3에서 kismet나 나타나게 됐고,
이후 발전해서 UE4의 blue print가 된 거고요.

즉, kismet이나 blue print가 생긴 이유는
visual object과 source code의 편한 연결 때문이지,
'쉬운' coding을 위해서가 전~혀~ 아니라는 거죠~

그런데,
많은 분들이 blue print의 목적이
'쉬운' coding에 있는 걸로 착각을 하시더라구요.^^;;;;

kismet이나 blue print의 목적은
본래 '편하게 작업하는 것'에 있었고,
그리고, 목적의 본질은 지금도 변하지 않았습니다.

저는 blue print가 '편하다'고 생각하지만,
님처럼 '쉽다'고 생각하지는 않아요.

'쉬운 것'과 '편한 것'은 다른 개념이고요.
'편의' 제공한다는 측면에서 blue print는 잘 만들었다고 봅니다.

하지만,
쉬운 coding을 광고했다면, 그건 과장이라고 생각하고요.







Tag:
안기훈, Kee Hoon Ahn, 언리얼, Unreal, UDK, iPhone, iPad, app, 앱, iOS

[안기훈123]

우와~ named가 오셨네요~ ^^;;;;;
댓글 감사합니다.^^