아무튼 언리얼 좀 써보니까 감이 잡히는게
아무래도 소규모 팀이면 언리얼로 생산성 뽑기가 극악임
우선 기획자랑 그래픽이 엔진을 어느정도 알아야 개발이 수월한데
유니티 다룰줄 아는 사람은 꽤 되니까 유니티 개발은 소규모라도 문제 없음
근데 언리얼은 할줄 아는 사람이 많이 없음 그러니까 개발이 상당히 지지부진해지는 면이 있음
주변에서 하는 이야기로는 애초에 게임 개발이라는건 어느 엔진이 좋다 나쁘다 해서 엔진을 결정하는게 아니라
개발하려는 게임의 볼륨과 기능에 적합한 엔진을 사용하는게 좋다고 함
예를 들어서, 2D 인디게임 같은 경우는 애초에 볼륨이 큰 경우는 별로 없고 성능적인 제약도 거의 없음
그런 상황에서 굳이 언리얼 엔진을 쓸 필요가 없다는거임
닭 잡는데 닭 잡는 칼 쓰고, 소 잡는데 소 잡는 칼 쓰듯이
만약에 완전 대규모에 퍼포먼스가 좀 나와야 된다고 하는 경우라면
언리얼을 쓰는걸 고려해볼 수 있음 유니티 쓸려면 쓸 수도 있는데
언리얼쪽이 나나이트랑 루멘, 뭐 그런게 있어서 대규모 게임의 경우에는 최적화가 수월한 면이 있으니까
그래서 볼륨 작은 인디 게임을 만든다고 하면 대부분은 유니티를 쓰길 권장하겠음
여기서부터는 프로그래밍적인 이야기를 좀 하겠음
언리얼 엔진은 사용자에 대해서 상당히 강제적인 면모가 있음 있는 정도가 아니라 강함
유니티가 입맛대로 구조를 짤 수 있는 자유로움이 있다면
언리얼은 정해진 구조 내에서 제약된 스크립팅을 해야함 그게 꼭 족쇄 차고 프로그래밍 하는 기분임
당장 내가 진행했던 프로젝트에서도 메인 프로그래머가 언리얼에 적응 못해서 괴로워하더라
유니티에서는 구조를 원하는대로 자기 설계 사상대로 만들었었는데
언리얼은 자기네들의 설계사상을 강요하니까
나는 일단 그 부분에 대해서는 언리얼 엔진이 지향하는 방향에 순응하기로 했음
다만 순응한다면 그만큼 편리한 엔진도 또 없음
대부분 모든게 갖춰져있음 유니티에서는 플머가 직접 구현해야했던 기능들이 언리얼에서는 미리 갖춰져있음
아닌가...? 기분 탓일지도 모르겠는데 일단 나는 갖춰질게 전부 갖춰져있다고 느꼈음
특히 네트워크 쪽은 구조가 이미 완벽하게 짜여있기 때문에 서버 구현하는게 상당히 편함
아... 그리고 블루프린트의 사용은 불가피하더라
외국의 언리얼 권위자가 올린 유튜브 영상을 봤는데 정말 하나하나 내 마음을 뜨끔하게 만드는 이야기를 하더라
"언리얼에서는 순수한 프로그래머란 없다"
이게 프로그래머 종특인지는 모르겠는데 일단 모든걸 코드로 해결하고 싶어하는 성향이 있음
내 주변에도 노드 기반 비주얼 스크립팅 이거를 극혐하는 프로그래머가 꽤 있더라
결론적으로 말하자면, 언리얼 엔진이 지향하는 방향은 기본 구조를 C++로 짜고, 내용을 블루프린트로 채우는거임
이게 생산성 측면에서도 그렇게 될 수 밖에 없는 이유가 있음
언리얼 좀 다뤄봤다고 하는 프로그래머면 언리얼 엔진의 단점 중의 하나를 뼈저리게 느낄거임
컴파일 시간이 너무 오래걸려
유니티처럼 엔진 실행중에 코드 수정하고 저장하면 한 10초도 안걸려서 바로 적용되는데
언리얼 엔진은 일단 코드 작성하고 저장하면 아무것도 안이루어짐 코드를 저장하고 엔진에 있는 컴파일 버튼을 눌러야됨
그리고 그 컴파일 버튼 누르고 얼마나 오래 기다리는지 앎? 한 2분 정도 기다려야됨
프로젝트가 커지면 커질수록 그 시간이 정말 끔찍할 정도로 길어짐
그래서 디버그가 어려움
유니티에서 했던 방식대로 하면 생산성이 극악으로 떨어짐
그래서 언리얼 엔진에서는 구조만 C++로 짜고 내용을 블루프린트로 채우는 기법을 자주 쓰는거임
왜냐하면 블루프린트는 컴파일이 겁나 빠르니까!
그리고 에셋 참조 측면에서도 블루프린트를 쓰는게 이득임
언리얼 엔진에서는 에셋을 스트링 형태의 경로 이름으로 참조하는게 가능한데
이거 왠만하면 안하길 바람
왜냐하면 이거 하드코딩이니까
코드로 에셋을 참조해봤자 경로가 바뀌면 엔진이 오류를 뿜뿜 뿜어냄
게다가 참조시키고 있던 에셋을 삭제했다? 엔진은 아무런 경고도 안띄워줌
근데 블루프린트로 에셋을 참조하고 있었다?
엔진이 "어 너 여기 블루프린트에서 이 에셋 참조중인거 아니었음?" 하고 물어봐줌
저번 글에서 언리얼 엔진은 싱글톤 싫어한다고 말했는데
정확히는 지들은 싱글톤 쓰면서 플머한테는 쓰지말라고 그러는거임
싱글톤 대신 지네들이 서브시스템 이라는걸 만들어 놨으니까 그걸 쓰라는거고
일단은 이 글은 여기까지. 물어보고 싶은거 있으면 물어보고.
다음에도 노하우 같은거 더 풀어볼 생각. 반응 좋으면
나는 언리얼을 더많이 써서그런가 이미순응되서 불편한거 못느끼겠던데 ㅋㅋ 소규모라도 3D라면 생산성도 언리얼이 더좋은거같음 블루프린트로 대충 올리면 그럴싸하게나와서
컴파일 시간은 글카 씨피유 업글해서 보완하면 되고 엔진 폴더 통째로 ssd에 넣는것도 도움되긴 함. 그리고 블프는 난 동의못함 애님인스턴스, 비헤이비어 트리, UMG 같은 불가피한거에 사용하는건 찬성인데 이벤트 그래프, 레벨 블프같은데에다 덕지덕지 붙여놓는건 안좋은 습관이자 방법이라고 생각함, 디버깅도 꽤나 번거롭고 무엇보다도 가독성이 씹창임, c++에서 BlueprintImplementableEvent였나 이것도 같은 이치, 난 오히려 모든 로직들을 c++로 만들어야한다고 생각하고 나 또한 c++ 비율 9:1로 가져가는중 그렇게해서 펄업 면접 보기도함
c++ 블루프린트 비율은 뭐 각자가 지향하는 방향에 맞춰서 정하기 나름인거지. 외국 유튜버도 꼭 절대적인건 없다고 했으니까.
GAS같이 잘짜여진 프레임워크라면 블프쓰는것도 나쁘지않다고 생각함
오히려 그런경우 진입점이 명확해서 가독성은 좋을뿐더러 블루프린트에서 디버깅시 클라이언트, 서버중 어디에서 호출되었는지 파악할수 있다는게 가장큰 장점이라고 생각함
일단 개추
일단 컴파일 버튼 안눌러도 돼. 그것땜에 핫리로드 기능이 있는거고. 글고 언리얼 4에서는 컴파일 할 목록이 전체 정도였다면 언리얼 5오면서 컴파일을 기존에 필수항목 + 수정한 부분만 컴파일 하게 바뀌어서 그런건지 컴파일 속도 눈에띄게 상승해서 실제로 나 유니티로 빌드 + 플레이버튼 누르는 시간이랑 언리얼 빌드시간이랑 차이 없었음 - dc App
그런가? 유니티가 빌드 속도는 넘사인데
일단 컴파일 같은건 뭐 또이또이한 경우도 있긴 한데 패키징으로 가면 유니티가 압승이지... 언리얼에서 패키징 해서 실행파일 뽑으려면 진짜 큰 프로젝트는 1시간도 넘게 걸림
글고 할 줄 아는 사람이 없다는 엔진의 단점이 아니라 그건 그냥 그 사람들이 안하니까 그런거고.. 3D는 유니티보다 언리얼이 훨씬 생산성 좋은 게 맞아.. 이미 로직구현이 다 돼있는데 당연한거지. 이미 캐릭터 만들기도 오마클 후 블루프린트 생성 캐릭터버튼 클릭 자체만으로도 끝나는데 글고 언리얼이 지향하는 건 3d니까 당연 2d는 언리얼로 안하는 게 맞고 기능도 본인이 그냥 구현하면 되는데 대체 얼마나 자유로운 거 원하는겨 ㅋㅋ - dc App
근데 패키징이 왜 비교대상인겨.. 당연히 시작부터 든 게 많은 엔진이 오래걸리는 거는 맞고 근데 실행파일을 단순 테스트용으로 사용하는거면 언리얼에서 패키징 안하고 패키지용 플레이 버튼 있는데 그거 쓰면 되는데 딱히 불편할 것도 없지? - dc App
근데 이거 뭔가 이상하네 IDE 에서 에디터 빌드 해서 켰을 때, 에디터 컴파일 버튼을 누르면 일어나는게 hot reload인데. hot reload 기능이 있으니깐 컴파일 버튼 안눌러도 된다? 이게 뭔 소리지
혹시 live coding 이랑 햇갈린거 아님?
나는 적응한편이라 괜찮은데 유니티 스타일에 익숙해진 플머한테는 좀 제약사항이 많은 것 처럼 느껴진다고 하더라고. 생산성 부분은 뭐 언리얼을 배우면 그만인 부분이긴 한데, 언리얼이 원체 무겁다보니까 다른 직군들 컴퓨터로는 좀 접근하기 힘든 부분이 있지
와타마론// ?? 뭐지 뭔얘기하는거야? 나는 그냥 작성자가 엔진에서 컴파일 버튼 눌러줘야된다길래 그냥 핫리로드 키고 ide에서 빌드만 해주면 된다고 얘기한거임 - dc App
IDE에서 F7누르나 에디터에서 컴파일 버튼 누르나 똑같이 일어나는데
"코드 작성하고 저장하면 아무것도 안돼서 엔진에 컴파일 버튼 눌러야 된다"길래, 그럴 필요 없이 핫리로드 키고 ide에서 빌드만 해주면 된다 이 소리지 - dc App
그러니까 지금 말하고 싶은게 굳이 엔진 건드릴 필요 없이 IDE에서 작업하던 그대로 F7 누르면 컴파일 버튼이랑 같은 동작이 일어난다는거잖음. 좋은 테크닉 배웠음.
그래서 UE5 부턴 기본 빌드 버튼이 live coding으로 바뀜. 공식 문서에서도 hot reload 쓰지말고 live coding 쓰라고 하고
아 그런뜻이구만 이해를 못했음
난 라이브코딩 싫어함. 느리긴 뭐그리 느려 진짜.. 라이브 코딩 잘 쓰고 있음? 하다가 화딱지나서 그냥 핫리로드만 씀 - dc App
나도 라이브코딩 5부터 디폴트로되어있길레 걍 꺼버림 오히려 불편함;;
라이브코딩 ㄹㅇ 개쓰레기임 언리얼 6 나 되야 좋아질듯
라이브 코딩 좀 느리긴 한데 pie실행 도중에도 빌드 되고 그래서 그냥 쓰고 있음. 빌드 도중엔 커피타임 개꿀 ㅋㅋ;
근데 핫 리로드에 비해서 라이브 코딩이 뭐가 좋은거임? 몰라서 물어봄...
https://unrealcommunity.wiki/live-compiling-in-unreal-projects-tp14jcgs
나는 반대로 유니티를 찍먹하고 언리얼은 3년정도쓰고있는데 3D에 한해서는 언리얼이 훠어어얼씬 편함 진짜로 왠만한 기능은 이미 다있고 그리고 니가말하는 디자인패턴이나 설계구조같은거도 언리얼이 자향하는 바가 맞다고봄 언리얼 컨벤션같은거는 다른데서도 참고많이할정도로 잘만들어져있어서 일종의 정답지같은 느낌이듬
3년동안 출시한거 없으면 편하다고 하긴 어렵지 않노
현직게이라... 인디개발은 시작도안함
최근에야 주말에 깔짝대고있음
나는 유니티 2d로 시작했다가 원래 좋아하던게 3d 십덕겜 이라서 언리얼로 갈아탐. 처음엔 진짜 죽겠었음. 공부 방법도 사기꾼새끼들 말 듣고 했다가 시간낭비도 심했고. 근데 지금와서 돌이켜보면 3d는 걍 닥치고 언리얼임. 유니티에서 언리얼이 제공하는 기본 기능을 직접 구현하거나 에셋으로 때운다? 시간낭비 돈낭비 노력낭비 오지는거임
"언리얼 엔진은 사용자에 대해서 상당히 강제적인 면모가 있음 있는 정도가 아니라 강함 유니티가 입맛대로 구조를 짤 수 있는 자유로움이 있다면 언리얼은 정해진 구조 내에서 제약된 스크립팅을 해야함 그게 꼭 족쇄 차고 프로그래밍 하는 기분임"<<<이거 진짜 개씹공감
이것때문에 언리얼이 처음에 입문하기 굉장히 어렵다고느낌
자기 입맛대로 하려면 엔진 소스코드를 만지는 것외엔..
근데 언리얼은 오픈소스라서 엔진소스만지기가 쉬움... 걍 바꾸면그만
엔진내부 바꾸면 힘들어지잖아. 그뒤부터 엔진 버전 업마다 관리도 따로해줘야하고 팀단위로 엔진도 동기화해줘야하고.. 최대한 엔진은 안건드릴수 있으면 안건드는 쪽으로 수정하는게 훨씬 개발 편한데
플머라면 이거 무조건 공감임 이거 공감 못하는 플머면 다시 공부해야될 정도
ㄹㅇ... 윾니티는 내 ㅈ대로 만들어도 어떻게든 만들어지는데, 언리얼은 정해진 구조가 있다보니 규칙을 숙지하고 가야하는게 좀 불편하더라 언리얼 엔진 코드 수정의 경우엔 장점으로 작용할 수 있긴한데... 팀 단위로 몇 년씩 서비스하다보면 마냥 그렇진 않은듯
정해진 구조대로 작성하는게 익숙해지면 더 편하기도 하던데...
언리얼이 자기네는 싱글톤쓴다는 말이 언리얼엔진 만들때 싱글톤을 썼다는 얘기야? - dc App
엔진 내부적으로는 싱글톤을 쓰는 부분이 없진 않지
구조를 C++로 짠다는게 무슨 말인가요?
어쨌거나 다음편도 "해줘"
함수같은건 C++로 텅 빈 함수 만든 뒤에 블루프린트에서 오버라이드 한다는 말임