언리얼 엔진 vs 유니티 엔진
덤프버전 :
관련 문서: 언리얼 엔진 1. 개요[편집]
이 문서는 언리얼 엔진과 유니티 엔진의 특징을 비교한다.
2. 스크립트 언어[편집]
2.1. 언리얼 스크립팅[편집]
초보적인 프로그래머들로만 구성되어 있는 팀의 입장에서 본다면 언리얼 엔진 4는 스크립팅 언어로서 새로운 언어를 배워야 하는 부담을 없애기 위해 언리얼 엔진 3까지 써오던 Java 스타일의 UnrealScript를 제거하고 보다 대중적으로 다가서기 위해서 게임 프로그래머들에게 익숙한 C++를 채용했다.[1]
언리얼 엔진 4는 아래에서 언급될 비주얼 스크립팅 언어인 블루프린트와 프로그래밍 스크립트 언어를 함께 사용하여 복잡한 구조나 퍼포먼스가 필요한 부분은 프로그래밍 언어로 구성하고, 가변성이 높은 부분은 디자이너가 간단히 변경할 수 있게 블루프린트로 구성하여 상호 보완적으로 활용 가능하다. 때문에 타 직군과의 협업이 굉장히 원활하다.
언리얼 엔진 4의 핫 리로드는 기본 기능 변경시 원활하게 적용되나 외부 모듈(프로젝트 내에서 서브 모듈이나 플러그인 등)을 추가하면 수동으로 리로드를 해주어야 했으며엔진에서 상속받을 스크립트부터 찾아야하기에 스크립트 추가시 거의 반드시 엔진 컴파일 과정이 필요했다.[2]
물론 근본적으로 유니티의 속도를 따라가기는 힘들지만, 그래도 상술한 난점들은 지속적인 업데이트를 통해 어느정도는 개선되었는데, 언리얼 엔진 4.22 버전부터 추가된 라이브 코딩을 통해 오브젝트 리인스턴싱을 특별히 고려할 필요없이 개별 함수를 패치하므로, 규모가 큰 프로젝트의 신뢰성이 보장되며 작업속도의 증대와 확장성이 기존보다 훨씬 높아지게 되었다.
언리얼 엔진은 2015년 3월 이후 버전 4의 소스 코드 전체(지속적으로 업데이트되는 버전 역시 항상 전체 소스 코드 공개)를 공개한다는 점은 굉장한 강점이다. 복잡한 코딩이 가능한 프로그래밍 전문가가 있는 팀의 경우에는 여러모로 언리얼 엔진이 훨씬 더 낫다. 언리얼 C++의 빌드 툴의 지속적인 개선과 엔진을 직접 건드릴수 있는 강점이 있기 때문. 또한 엔진 자체에서도 제공하는 기능이 굉장히 많기 때문에 엔진에 있는 기능만 사용해도 유연하게 해결되는 경우가 상당수이다.
또한, 언리얼 엔진 4 문서에는 언급이 되어 있지 않지만 해외 커뮤니티에서는 C++ 대신 C\#을, 혹은 스크립트 언어인 Lua나 Ruby 등을 언리얼에서 사용하는 방법에 대해 연구하기도 하고 실제로 그러한 스크립트 언어를 사용하여 개발하고 출시한 상용 게임도 있다.
언리얼 엔진 5와 더불어 Verse라는 새로운 스크립팅 언어를 공개했다. Python과 비슷한 문법 구조를 채택하고 있어 해외 커뮤니티에서는 배우기 쉽고 기존의 언리얼 C++를 대체해 줄 것으로 예상하고 있다.
트위치 스트림 링크
Verse는 2023년 3월 22일 출시한 포트나이트 언리얼 에디터(UEFN)[3]에서 사용 가능하며 포트나이트의 유저 제작 모드에 사용된다.
Verse 언어 레퍼런스
Verse 프로그래밍 언어는 우선 포트나이트 전용으로 출시하여 수 많은 사용자들이 사용하는 과정에서 언어를 계속 다듬는 과정을 거치고 추후 언리얼 엔진에 완전히 포함될 예정이다.
2.2. 유니티 스크립팅[편집]
유니티는 C#을 기본 스크립트 언어로 사용한다. C# 언어 자체가 C++에 비해 적응이 빠른 편이라 비 프로그래밍 직군도 많이 접근하게 된다.
유니티의 경우 스크립트 생성시 Monobehaviour 만을 상속받아 스크립팅을 하게 만들었다. 해당 파이프라인을 하나로 통일한 덕에 추가적인 기능은 UE에 비해 부족해 컴포넌트 애드온을 필요한 분량만큼 추가해주어야 하지만, 그 대신 컴포넌트를 붙이는데 제약이 적고 수정시 에디터상에 즉각 반영이 되는 Hot Reload 기능이 굉장히 강력하게 구비 되어있다. 주 언어가 C#인것도 한 몫 하는데, 어느 객체를 만들었으면 해당 객체에 대해서만 컴파일이 완료되면 바로 실행이 가능하다.
문제는 비 프로그래밍 직군 작업자에 대한 편의는 적은 편이다. 언리얼을 따라 비주얼 스크립트를 개발했지만 사실상 유명무실하며 결국에는 비 프로그래밍 직군의 인원도 코드를 알아야 정확한 작업을 진행할수 있다. 이는 하단에 유니티 비주얼 스크립팅 문단에 후술한다.
유니티는 엔진 소스 코드를 제공하지 않아 소스 코드를 제공받기 위해서는 별도로 고가의 계약 체결이 필요하다.[4] 때문에 고수준의 작업에서는 자잘한 문제가 발생하고, 이를 피하고 개선하기 위해 우회를 반복하다가 어느새 엔진내 소스를 스파게티처럼 만드는 경우도 더러 있다.
3. 비주얼 스크립팅[편집]
3.1. 언리얼 블루프린트[편집]
프로그래머가 없는 팀의 입장에서 본다면 언리얼 엔진 4에서 새롭게 등장한 블루프린트라는 시각적 프로그래밍 언어를 이용해 블럭들을 마우스로 쭉쭉 이어주기만 하면 코딩 한 줄 없이 프로그래밍이 가능하다. 작동법 하나하나가 매우 복잡하게 되어 있는 블루프린트도 디자이너의 입장에서는 복잡한 세부 구성들을 전혀 이해할 필요없이 최종적으로 보여지는 유저 친화적인 프로퍼티들만을 가지고서 매우 손쉽게 개발을 할 수 있다.
또한 마켓플레이스에 올라오는 다양한 유&무료 블루프린트 애셋이나코드 플러그인 애셋들을 활용한다면 C++ 프로그래밍을 할 줄 아는 개발자가 전혀 없더라도 많은 기능들을 손쉽게 구현할 수 있다.
실제로 개발 작업에서 많은 시간이 소요되는 반복처리 및 테스트를 프로그래밍을 전혀 모르는 디자이너들만으로도 가능하게 해 주는 큰 이점이 있다. 물론 전혀 새로운 기능들을 만들기 위해서는 복잡한 세부 블루프린트들을 직접 구성해야 하며 이는 어느 정도의 프로그래밍 지식이 수반되기 때문에 완전히 디자이너들만을 위한 툴은 아니라는 비판도 있었지만, 꾸준한 버전업을 통해 많은 부분들이 개선되면서 초보자의 입장에서도 사용하기 편리하도록 구조를 바꾸는데 주력한다.
지속되는 버전업을 통한 또 다른 개선점으로는 블루프린트가 단지 스크립팅 부문에만 한정되는 것이 아니라 언리얼 엔진 4 전반에 걸친 모든 기능들이 차차 블루프린트화되어가면서 더욱 유저친화적이면서 직관적이고 편리하게 변해가고 있다.
블루프린트는 비주얼 스크립트이므로 당연히 C++ 코드보다 속도가 느리다. C++로 작성시 20ms인 코드가 블루프린트로만 작성했을때는 상황에 따라 5~15배 느린 100ms~300ms의 속도차이가 발생하는 경우도 더러 있었으나 지속적인 개선으로 점차 속도가 빨라지고 있다.
그리고 언리얼 엔진 4.15부터는 블루프린트 네이티브화 기능이 추가되어 혹여라도 속도가 필요한 부분을 블루프린트로 작성하여 속도가 안나온다면 그 부분의 블루프린트를 C++로 자동 변환해서 블루프린트로 호출하는 방식을 사용할 수도 있다.
블루프린트는 C++와의 조화를 이루어 개발하는 것이 기본이다. 속도가 필요한 부분은 C++로 작성하고 이것을 블루프린트로 호출하여 상호간의 연결, 조합, 속성 설정 등의 작업을 해주는 것이며, 프로그래밍 지식이 필요한 수준의 복잡한 로직 작성이 필요한 경우는 프로그래머가 세부적인 블루프린트를 구현하고 복잡한 블루프린트 그래프를 단위별로 묶어서 카테고리화하고 간단한 속성만 노출한 블루프린트 액터 생성 후 디자이너는 그 간단하게 속성만 노출한 블루프린트 액터를 가지고 마우스로 선을 끌어서 연결, 조합, 해제 및 속성 변경, 상태 설정 등을 쉽게 가능하게 만들어주는 것이 블루프린트 작업의 표준이며 실제로 블루프린트를 제대로 활용한 프로젝트라면 전부 다 위와 같은 방식으로 개발되어 있다.
즉, 블루프린트는 속도가 중요한 로직이나 모든 프로그래밍에 대한 코딩[5]을 편하게 하기 위한 수단이 아니고 오브젝트(액터) 간 상호작용[6] 측면과 속성 변경, 상태 정의 등을 디자이너 입장에서 효율적이고 편하게 작업하기 위한 것이다.
애초에 블루프린트가 만들어진 목적 자체가 단순하거나 반복적인 스크립트의 변환 작업이 필요할 때 디자이너들이 프로그래밍 지식을 굳이 습득할 필요 없이 편리하고 효율적으로 작업 할 수 있도록 착안한 것이다. 완전히 소규모 프로젝트거나 복잡한 로직이 전혀 필요없는 프로젝트인 경우는 모든 스크립트를 100% 블루프린트로만 짜는 경우도 가능하지만 일반적으로는 블루프린트로 모든 스크립트 코드를 작성하지 않으며 그것을 권장하지도 않는다.
해당 부분을 잘 나뉘도록 매니지먼트가 잘 되어있는 팀일수록 빛을 발하며, 이러한 작업분할로 최종적으로 개발자, 디자이너 구분없이 팀내 모두가 같은 결과물을 공유할 수 있는 점은 최종적으로 유니티가 근본적으로 따라올수 없는 장점이기도 하다.
3.2. 유니티 비주얼 스크립팅[편집]
유니티는 기본적으로 C#을 이용해 게임 스크립트를 작성하고 비주얼 스크립팅은 주력이 아니라고 보아야 한다. 낮은 진입장벽의 비주얼 스크립팅과 복잡한 C++을 병행하는 전략을 취하는 언리얼에 비해 C#의 언어적 복잡성은 그 중간 정도에 위치하고 있어 비주얼 스크립팅의 필요성(난이도의 격차)가 상대적으로 적다.
과거부터 플레이메이커(PlayMaker)라는 서드파티 비주얼 스크립팅 유료 에셋이 있었다.[7] 하지만 언리얼의 블루프린트와 블루프린트 에셋들에 비하면 한참 부족한 수준이다. 애초에 플레이메이커나 에셋 스토어에 있는 비슷한 유/무료 에셋들은 언리얼 블루프린트처럼 엔진의 전반적인 기능들을 제어하는 핵심 요소로서 포함된 수준이 아닌 추가 플러그인 에셋일뿐이고 그런 비슷한 에셋은 언리얼 마켓플레이스에서 볼 수 있는 단순히 블루프린트 에셋이나, 기타 비주얼 스크립팅 에디터 에셋 수준에 불과하기 때문에 언리얼 엔진 4의 블루프린트와는 비교 자체가 성립되지 않는다.
언리얼에 대응하기 위함인지, 2018년 11월에 개최한 Unite LA에서 앞으로의 로드맵을 공개했는데 유니티 2019.2부터의 프리뷰로 시작해서 유니티도 엔진 자체적으로 비주얼 스크립팅 기능을 추가한다고 발표했고, 2019년 9월 26일 유튜브에 올라온 로드맵에선 2020.1 버전 프리뷰 영상에선 해당 기능의 추가를 예고했다. 해당 기능은 BOLT라는 이름으로 추가되었으며[8], 아직 사용자가 많지 않아 평가는 유보적인 상황이다.
4. 2D 지원[편집]
4.1. 언리얼 2D 기능[편집]
언리얼 엔진은 기본적으로 고급 3D 그래픽을 구현하는 각종 신기술 도입에 집중한 엔진이기 때문에 2D 그래픽 개발 지원은 상당히 미흡하다. 언리얼 엔진 4.0 출시 시기인 2014년 2월부터 Paper2D라는 플러그인을 시험적으로 지원했으나 미흡한 면이 많았으며, 언리얼 엔진이 버전업하면서 AAA급 고퀄리티 3D 게임 개발, 렌더링, 건축, 자동차, 시뮬레이션 등의 수요에 맞추기 위한 3D 기술 개발에 집중하느라 2D 지원 쪽은 완전히 손을 놓았다고 봐도 무방하다.
직교투영 렌더링은 건축 및 제조 분야에서 프로젝트를 시각화하는 매우 일반적인 방법이며, 게임에서도 스타일리시한 카메라 선택으로 사용됩니다. 오랫동안 UE에서 카메라 옵션으로 사용할 수 있었지만 많은 렌더링 기능이 지원되지 않아 사용하기가 비현실적이었습니다.
5.3부터 직교투영 렌더링이 실험단계로 지원됩니다. 엔진의 여러 영역이 고정되어 원근 투영과 직교 투영 사이의 패리티를 달성했습니다. 이제 루멘, 나나이트, 섀도우를 포함한 UE5의 최신 기능 대부분이 작동합니다. 이것은 진행 중인 작업을 나타내며 프로젝트에서 이를 사용하려고 시도하는 귀하의 피드백을 듣는 데 관심이 있습니다.
2023년 6월 9일, 언리얼 엔진 공개 로드맵 사이트의 직교투영(Orthographic) 렌더링 지원 공지#
일례로 라이팅과 셰이딩 기능은 언리얼 엔진의 강점 중 하나로 꼽히지만, 정작 엔진의 2D 직교투영 카메라 모드에서는 언리얼 엔진의 수많은 렌더링 기능은 물론, 가장 기본적인 라이팅과 셰이딩조차도 제대로 적용이 안되는 버그가 4.0 시절부터 5.2 버전까지 있었다. 언리얼 엔진 포럼에 해당 문제의 해결법을 묻는 질문이 2017년 4월에 올라왔는데, 라이팅과 셰이딩이라는 핵심 기능의 버그 수정이 무려 5년 이상이나 방치되어 왔다. 심지어 5.3에서 버그를 해결하려고 시도한 이유도 2D 게임 개발에 차질이 있어서라는게 직접적 사유가 아니라 위의 로드맵 글에서 서술된 것처럼 건축 및 제조 분야에서 큰 문제가 된다는 사유#였고 2D 개발자를 위한 배려는 뒷전이었다. 에픽 측이 얼마나 2D 게임 개발을 경시하는지 알 수 있다. 심지어 앞서 언급했듯이 5.3에서도 2D 카메라는 실험적 기능이며, 5.2까지 고질적인 문제를 일으키던 버그가 완전히 해결되지 않았다.#[9]
언리얼 2D 개발의 중핵인 Paper2D 플러그인의 경우, 언리얼 엔진 5로 버전업된 현재 시점까지도 3D 애니메이션에서는 당연하다시피 지원하는 기능인 애니메이션 스테이트, 소켓, 노티파이 기능조차 제공하지 않는 반쪽짜리 플러그인인데[10], 언리얼로 2D 개발을 하려면 해당 플러그인의 부족한 부분을 스스로 땜빵하면서 써야 한다. 2D 게임 개발에서 필수적으로 사용하는 스프라이트 타일맵 기능의 경우 엔진이 5로 버전업하기 이전에 8년이란 기간동안 실험적 기능이라는 Experimental 태그를 붙이고 방치되어 있었으며 타일맵 기능은 일부 요소만 보면 알만툴보다 뒤떨어진다.[11]
에픽 게임즈에서도 기본적으로 2D 개발을 위한 기능 지원 자체를 경시하고 있어 버전 업데이트에도 2D 게임 개발을 위한 기능은 거의 추가되지 않으며, 그나마 있는 기존 기능에서 발생하는 버그 수정도 거의 이루어지지 않았고, 언리얼 엔진 5로 버전업하며 2D 템플릿은 아예 통으로 삭제되었다. 온라인 러닝으로 제공하는 2D 템플릿을 마켓플레이스에서 여전히 다운로드 받을 수 있긴 하지만, 기본 제공하던 템플릿을 버전업하며 제외한 것은 엔진의 개발 방향성이 전적으로 3D에 집중되었음을 알게 해준다.
물론 일단 명목상으로 개발할 수 있는 구색은 갖추고 있으므로 어떻게든 만들 수는 있다만, 2D 게임 개발의 경우에는 개발력이 애초부터 부족한 인디 팀이 2D 베이스가 두텁게 깔려있는 2D 전문 게임 엔진들을 두고, 개발사인 에픽부터 손을 반쯤 놓아서 기본적인 기능도 부실하고 버그도 방치된 상태인 언리얼을 선택할 이유는 거의 없다. 엔진이 제공하는 렌더링 퀄리티가 좋아서 그래픽이 잘 나올 포텐셜이 있다는 것 정도인데, 웬만한 2D 게임은 그렇게 높은 그래픽을 상정하지 않아 언리얼이 제공하는 렌더링 기능 대다수가 과유불급인데다, 단순한 과유불급 수준을 넘어 오히려 문제를 일으키는 경우가 많다. 최적화를 밉맵 기능, 더 부드러운 그래픽을 위한 안티 앨리어싱 기능, 모션 블러 등이 픽셀을 뭉게버려서 흐릿하게 보이게 만든다거나 하는 식이다. 물론 세팅을 통해 해결할 수 있지만 세팅을 하는 것도 고역이고, 2D 카메라 버그 같은 일부 문제는 세팅 따위로는 해결되지 않고, 3D 카메라를 사용해 2D를 우회적으로 표현하거나 엔진의 코드를 직접 수정하는 수준까지 들어가야 한다.
때문에 언리얼로 개발되는 2D 게임들은 거의 대부분 3D 모델링과 3D 카메라를 2D 스프라이트와 혼합한 스타일을 주로 사용한다.[12] 고전적 2D 시점에 버그가 많은 것일 뿐, 3D 부분은 안정적이기 때문. 과유불급이라는 각종 렌더링 기능도 과유불급이 아니게끔 제대로 살려서 뛰어난 퀄리티를 보여주는 게임들도 있으며, 캐릭터와 배경에 모두 스프라이트만 사용하는 고전적인 평면적 2D 게임이 아닌 2D와 3D를 적절하게 섞은 스타일의 게임들 같은 경우에는 언리얼 엔진을 사용하여 상당한 퀄리티를 가진 2D 그래픽을 낼 수 있는 잠재력이 있다.
결론적으로 말해서 언리얼로 2D 게임을 만들지 못하는 것은 아니지만, 기본적으로 언리얼은 고퀄리티 3D 게임을 만들기 위한 소 잡는 칼이며, 언리얼로 만들 수 있는 2D 게임은 유니티로도 대부분 비슷하게 만들 수 있다. 쌓인 2D 개발자 풀과 자료는 유니티 쪽이 풍부한데다 언리얼 자체가 고전적 2D 게임 개발은 매우 미흡하게 지원하기 때문에 가벼운 2D 게임을 만들 것이라면 언리얼은 좋지 못한 선택이다. 다만 3D와 혼합하여 고품질의 렌더링과 셰이딩 효과를 사용하는 대형 2.5D 게임이라면 언리얼도 포텐셜 면에서는 나쁘지 않은 선택이라 볼 수 있다.
4.2. 유니티 2D 기능[편집]
2D 개발자들은 대부분 게임메이커, Cocos2d 또는 유니티를 사용한다. 전문 2D 툴보다는 부족한 부분도 많지만 왠만한 2D 게임은 무리없이 개발할 수 있는 수준이며 관련 레퍼런스나 자료도 두터운 편이다.
5. 애셋 시장[편집]
5.1. 언리얼 마켓플레이스 → 팹(Fab.com) (2024년 출시 에정)[편집]
언리얼 마켓 플레이스는 2023년 기준으로 이제 활성화된지 6년 이상 됐다.
언리얼 엔진 4의 각종 기술 데모 뿐 아니라 에픽 게임즈에서 직접 개발하다가 중단된 AAA급 게임의 리소스를 공짜로 제공하기에 여러 프로토 타입을 제작하거나 학습에 매우 유리하다.
2015년에는 모바일 게임인 인피니티 블레이드 던전, 2018년에는 무려 1200만 달러(한화로 127억원)의 개발비용이 투자된 파라곤의 리소스를 누구나 다운로드 받아서 사용할 수 있게 풀어서 AAA급 퀄리티를 가진 리소스 제작의 학습뿐 아니라 그대로 사용하던 수정해서 사용하던 해당 리소스들을 상용 게임에 활용하는데도 제한을 두지 않았기 때문에 중소규모의 개발사나 1인 개발자들에게도 엄청나게 큰 도움이 되고 있다.
그리고 퀵셀 메가스캔을 인수하여 지속적으로 고품질의 애셋들을 무료로 공개하고 있다. 또한 상당한 퀄리티를 지닌 이달의 무료 컨텐츠를 5개를 선정해서 매달 무료로 제공하여 학습에 굉장히 유리한게 언리얼 마켓플레이스의 강점이다. 아예 풀 시네마틱이 들어간 프로젝트들도 더러 있으며 파티클이나 레벨디자인을 다룬 프로젝트도 있고 당연하게도 기본적인 메테리얼만 다룬 것도 있다. 전반적으로 상당한 퀄리티의 다양한 프로젝트들을 손쉽게 무료로 받아 참고하여 공부해볼 수 있다.
언리얼 엔진 5 등장 이후 시점에서는 유료뿐 아니라 무료로 제공하는 애셋들 중에서도 고급 애셋들이 매우 많다.
2023년 3월 23일부터 25일까지 열린 GDC 2003에서 공개한 바에 따르면 2023년 하반기에는 멀티 플랫폼 마켓플레이스인 팹(Fab.com)이 출시될 예정이다. 팹은 2023년 3월 23일 포트나이트 언리얼 에디터 얼리 액세스와 함께 알파 버전이 공개되었으며 수천개의 애셋을 사용할 수 있는데, 하반기에 정식 출시되면 그 수는 수백만개로 늘어날 예정이라고 한다. 이 멀티 플랫폼 마켓플레이스인 팹은 언리얼 엔진 마켓플레이스와, 에픽이 인수한 스케치팹, 아트스테이션 마켓플레이스, 퀵셀 메가스캔 라이브러리를 통합하여 3D, VFX, 환경 등 모든 종류의 애셋을 위한 단일 콘텐츠 소스로서, 이제 질로나 양으로나 유니티 애셋 스토어의 규모를 훨씬 넘어서서 인디나 개인 개발자들이 사용할 소규모 애셋부터 중급규모, AAA급의 대규모 애셋들까지 방대한 생태계를 구성할 것으로 보인다.
2023년 10월 15일 기준, 팹(Fab.com) 에 따르면 출시시점이 2024년으로 연기되었다.
5.2. 유니티 에셋 스토어[편집]
소규모 개발팀이나 1인 개발자들의 입장에서는 엔진용 컨텐츠를 쉽게 구할 수 있는 점에서 2021년 기준으로 약 11년 이상 활성화된 유니티용 컨텐츠몰인 에셋 스토어의 존재와 방대한 추가 에셋의 양은 인디 제작자들이 유니티를 사용하는데 있어서 결정적인 요소 중 하나이다. 지금도 수많은 소규모 제작사와 인디 개발팀은 에셋 스토어의 은혜를 입고 있다. 필요한 게 있다면 일단 유니티 에셋 스토어를 검색해보고 나온 결과물과 자신이 만들었을때 비용을 대조해보고 생각하는것이 우선일 정도로, 없는게 거의 없다.
엔진 자체가 기능이 정형화되고 안정화에 들어간 지금으로써는 엔진 버전 업데이트시 기존 리소스가 망가지는 현상도 상대적으로 적은 편이다. 기껏 비싼 돈을 들여 구매했는데 체계가 바뀌어 쓸모없어지거나 해당 리소스를 쓰기 위해 엔진 업데이트를 미루는 일을 줄일수 있다.
유니티 에셋 스토어는 오랜 기간 활성화된만큼 판매되는 에셋의 수가 많으며 이에 비례해서 소규모 개발사나 개인 개발자들을 위한 저렴한 가격의 에셋도 많이 판매되고 있어서 소규모 개발팀이나 1인 개발자들의 좋은 대안이 되어주고 있다.
6. 한국어 지원[편집]
6.1. 언리얼 엔진[편집]
한국어 지원의 경우 초보자가 보기에 언리얼 엔진이 좀 더 진입장벽이 낮다. 이미 언리얼 엔진 3 시절인 2009년부터 문서 한국어판 지원이 시작되었고 언리얼 엔진 3의 최종 버전과 함께 기본적인 문서들은 대부분 한국어판 작성이 이루어졌다. 언리얼 엔진 4는 지속 버전업 되면서 신기술이 개발되어 감에 따라 새로운 기능들은 한국어 지원이 조금 늦는 감이 있긴 한 편이나 점진적으로 한국어 지원이 이루어지고는 있다. 다만 심층적인 기술 이해가 필요한 부분은 한국어 지원은 진행되지 않는 점도 있어 영어 문서를 참고해야 하는 상황이다. 특히 초보자를 위한 블루프린트는 한국어 레퍼런스와 자료가 있지만 깊이 들어가야 하는 C++ API 쪽은 번역도 미비하고 설명이 부실한 편이다.
언리얼 엔진 4는 엔진 자체도 한국어판이 존재하며 주요 메뉴명이나 기술적인 부분 등 전문용어가 사용되는 부분은 한국어 변환으로 인한 혼란이 초래되지 않도록 완역이 아닌 음역으로 옮겼고 엔진의 설정 메뉴에서 클릭만으로 여러가지 언어로 변경이 가능하다.
6.2. 유니티 엔진[편집]
유니티의 경우 공식 튜토리얼 동영상만으로는 진입하는 데 어려움을 느낄 수도 있다. 해외에는 두 엔진 모두 관련 자료들이 넘쳐나지만 국내에서는 공식 카페를 제외하고는 고수준의 개발과정을 다루는 기술 포럼은 찾기 힘들다. 그러나 도서 시장에서는 얘기가 좀 달라지는데, 2016년 기준으로 두 엔진 모두 관련 우리말 서적들이 시장에 출판되고 있다. 양쪽 모두 국내지사에 의해 다양한 행사를 개최한다. 2016년 기준으로 언리얼 엔진 쪽이 더 지원과 행사에 신경을 쓰고 있는 모습을 여실히 느낄 수 있다. 에픽 게임즈에서 직접 올려주는 언리얼 엔진 유튜브 강좌도 꼬박꼬박 한국어 자막이 달리고 있다.
유니티 엔진은 2021년부터 한국어판을 지원한다.
7. 작업 결과물 품질에 따른 편의성 및 작업 속도[편집]
라고 평가 할 수 있다.
작업 편의성은 1인 개발 또는 적은 인원의 개발팀으로 진행되는 소규모 프로젝트 또는 작업기간이 짧거나 리소스, 개발인력 및 자금이라는 제한이 걸린경우 유니티를 사용하는게 다소 유리한 편이다.
하지만 프로젝트의 규모가 작더라도 경우에 따라서는 언리얼의 작업 속도가 더 빠르고 간결하면서도 높은 품질의 결과물을 얻을 수 있는 상황도 있으며 언리얼 마켓플레이스에도 고급 품질의 무료, 저가 애셋들이 많이 풀려있기 때문에 어떤 것을 만드느냐에 따라 상황은 달라질 수 있고, 특히 Fab이 정식 서비스되고 나면 작은 프로젝트에서도 언리얼의 강세가 확연하게 눈에 띌 것으로 예상된다.
개발하는 프로젝트의 규모가 크다면 언리얼 엔진이 훨씬 유리하다. 유니티로는 프로젝트의 일정 규모 이상으로 커지거나 복잡하게 되면 여러모로 감당하기 힘든 일들이 발생하기 때문에 유니티로는 대형 AAA급을 만드는 일은 거의 없다.
언리얼 엔진의 경우는 초기 진입비용이 세지만 그 이후에 드는 비용은 낮다고 볼수있다. 결과물 또한 어느정도 큰 차이를 보이니 최종 결과물에서는 앞선다. 유니티에 비해 진입장벽이 어느정도 높은 것은 맞지만 언리얼 엔진이 버전업 되면서 점점 편의성이 강화되고 다양한 교육/참조자료들이 나오고 있어서 예전과 같이 더이상 유니티보다 훨씬 높은 진입장벽은 아니다.
기본 엔진 자체의 요구사양이 상당한데, 유니티는 비교적 저사양에서 실행 가능하며, 즉시에 가까울정도로 빠르게 컴파일되어 문제가 생기면 빠르게 빠르게 수정이 가능하고 특별히 개발 환경을 크게 세팅할 이유가 없지만, 언리얼 엔진은 유니티에 비해 사양을 높고 상황에 따라 컴파일 한번 하는데도 사양이 낮으면 낮을수록 10분, 20분 이상의 시간이 소요되는 경우도 있다. 따라서 1인 개발자나 소규모 집단 개발자의 경우에는 개발 장비가 일정 사양이 되지 않는다면 언리얼을 사용하는데 어려움을 겪을 수 있다.
이는 준비 비용과 생산성에 영향을 끼칠수밖에 없다. 유니티 엔진이 성능상 매우 떨어지는건 누구라도 아는 사실이지만 그만큼 심플하다. 인디게임이나 1인개발, 빠른 개발등 어떤 Cost(인력, 자원 등)에도 맞춰 진행이 가능한데 언리얼은 시작부터 일정 Cost가 준비되지 않으면 프로젝트의 독이 될수 있다. 그리고 사실 같은 Cost라면 유니티도 그렇게 많이 차이나지 않는 퀄리티의 작업물을 내놓을수도 있다. 왜냐면 순수한 애셋(메쉬, 애니메이션 등, 텍스처 등)의 작업물 퀄리티는 엔진과 직접적인 관련 없이 별개의 툴(마야, 맥스, 블렌더 등)에서 제작하기 때문이며 그것을 엔진에 올리고 돌렸을 때 받는 엔진빨에서 여러가지 효과를 받는 퀄리티 차이가 나기 때문이다.
여기서 유니티와 언리얼의 차이는 눈에 보이는 그래픽적 퀄리티의 차이도 있지만, 대규모 프로젝트의 효율적 리소스 관리와 최적화, 확장성을 고려한 소스 코드 구조에 따른 유연함으로 인한 개발 효율성에 있는 것이다.
8. 엔진의 확장성 차이[편집]
과거에는 언리얼에서 별도의 프로그래밍 및 최적화 작업 없이 기본적으로 지원하는 기능이 적었다. 그러나 이런 부분들은 모두 옛말로, 버전업을 거듭하면서 언리얼 엔진이 기본 제공하는 기능이나 플러그인 추가로 문제를 해결할 수 있도록 업데이트되었다. 반투명 문제 해결은 2016년도인 4.14 버전에서 해결됐으며, 언급된 카툰 렌더링의 경우도 2018년도에 나온 4.22 버전에서 간단히 구현할 수 있도록 이미 버전업되었고, 바로 위에 언급된 캐릭터 컨트롤 구조 만들기도 역시 5.0 버전에 나온 게임 피처(Game Features) 및 모듈형 게임플레이(Modular Gameplay) 등을 통해 이미 옛말이 되어버렸다. 즉, 현재 시점에서는 위에 열거된 언리얼의 단점들이 모두 해당되지 않기 때문에 시간이 지날수록 유니티보다 언리얼의 장점이 점점 더욱 부각되는 상황이 되고 있다.
9. 보안[편집]
엔진 자체의 보안성에 대해서는 둘 모두 큰 차이가 없다. 일단 유니티는 .NET 기반에 다이나믹 로더를 사용하지만, 그 부분은 게임 로직을 만드는 스크립팅 언어로써 C\#를 활용하는 것이지, 엔진 자체는 C++ 이라서 유니티와 비교해도 큰 차이가 없다. 하지만 게임 로직 코드는 .NET을 사용하는 유니티가 훨씬 털리기 쉽다.[13] 반면 C++을 이용하는 언리얼 엔진은 게임 로직도 어셈블리로 컴파일 되기 때문에 상대적으로 안전하다.[14] 하지만 요즘은 유니티 역시 C++로 번역 후 컴파일하는 IL2CPP를 지원하고 있고, 최근의 대규모 개발들은 대부분 중요한 비지니스 로직은 서버에 두고, 클라이언트는 서버에서 데이터를 얻어와서 사용하는 구조로 만들어지기 때문에 보안수준은 결정적으로 프로그래머가 보안요소를 얼마나 적용하느냐가 결정한다. 하지만 싱글 플레이어 게임을 만든다면 언리얼을 쓰거나, 유니티를 쓴다면 중요 코드를 C++로 작성하는 것이 보안에 도움이 될 수도 있다.
10. 프로젝트 환경에 따라 적합한 엔진 [편집]
이제까지 언리얼은 중~대규모 AAA급 프로젝트, 유니티는 대부분의 2D, 극소규모 ~ 중소규모급 3D 프로젝트에 사용하는 형태로 각각의 필요성에 따라 나뉘며 파이를 적절히 배분하고 있었고 현재에도 그렇고 앞으로도 그럴 것이다.
2D 게임을 고려한다면 언리얼은 보통 배제된다. 유니티와 언리얼 모두 기본적으로 2D 게임 개발과 3D 게임 개발을 둘 다 지원하지만, 언리얼의 경우 2D 게임 개발을 위한 기능인 Paper2D는 거의 명목상의 구색만 갖춘 수준으로 지원하고 있어서 실제 개발에 있어 애로사항이 매우 크기 때문이다.
이를테면 2D 게임 개발에 있어 필수적이라 할 수 있는 Pixel Pefpect를 맞추는 세팅도 까다롭고, 엔진에서 제공하는 카메라의 2D 뷰 모드인 Orthography 세팅은 라이팅과 셰이딩이 제대로 적용되지 않는 매우 심각한 버그가 있었음에도 5.3까지 버전업되는동안 무려 5년동안이나 방치되었으며, 타일맵의 경우도 언리얼은 명목상 지원은 하지만 내부 기능은 알만툴이나 게임메이커보다 못할 정도로 형편없다. 심지어 그 형편없는 기능조차도 언리얼 엔진이 5.0으로 넘어가기 전 한참동안 불안정한 실험적 기능이라는 Experimental 태그[15] 를 붙이고 아무런 기능 추가 없이 방치했으며 현재도 4.27 버전 Paper2D TileMap 문서에는 Experimental 태그가 붙어 있다.
언리얼 2D 기능의 핵심을 담당하는 Paper2D 플러그인의 경우 수차례의 버전업에도 아무런 기능 추가 없이 거의 방치된지 오래이며, 3D 애니메이션에서는 제공하는 애니메이션 스테이트 기능은 물론 노티파이 기능조차 없는 허접한 반쪽짜리다. 에픽이 Paper2D 플러그인에 더 이상의 기능 추가를 방치하다시피 한 것이 거진 10년이 넘는지라 언리얼로 2D를 개발하는 개발자들은 기능을 직접 개발하거나 유저 플러그인에 의존해야 한다.[16]
심지어 5로 버전업하며 구색으로나마 제공하던 2D 템플릿은 아예 통으로 삭제되었다. 온라인 러닝으로 제공하는 2D 템플릿을 마켓플레이스에서 여전히 다운로드 받을 수 있긴 하지만, 기본 제공하던 템플릿을 빼버린 것은 엔진의 개발 방향성이 전적으로 3D에 집중되었음을 알게 해준다.
물론 일단 명목상으로 구색은 갖추고 있으므로 어떻게든 만들 수는 있다만, 개발력이 애초부터 부족한 인디 팀이 2D 베이스가 두텁게 깔려있는 유니티를 두고 언리얼을 선택할 이유는 크게 없긴 하다. 엔진이 제공하는 렌더링 퀄리티가 좋아서 그래픽이 잘 나올 포텐셜이 있다는 것 정도인데, 웬만한 2D 게임은 그렇게 높은 그래픽을 상정하지 않아 언리얼이 제공하는 렌더링 기능 대다수가 과유불급인 경우가 많다. 물론 그 과유불급을 과유불급이 아니게끔 제대로 살려서 압도적인 퀄리티를 낸 2D 게임이 없지는 않지만, 대부분의 2D 게임은 그정도까지 가지 않는 경우가 많다.
심지어 에픽 측에서도 기본적으로 2D 개발을 위한 기능 지원 자체를 경시하고 있어 버전 업데이트에도 2D 게임 개발을 위한 기능은 전혀 추가되지 않으며, 그나마 있는 기존 기능에서 발생하는 버그 수정도 거의 방치하다시피하는 막장스러운 스탠스를 취하고 있다. 유니티가 이미 확보한 2D 개발자들과 이들이 방출하는 레퍼런스나 자료가 두텁다는 점이 스노우볼이 구르며 계속 강화되고 있다. 이러한 점은 플러그인 등지에서도 다르지 않아서 Spine 등의 스켈레탈 2D 애니메이션 툴 역시 명목상으로 양대 엔진을 모두 지원하지만, 언리얼 쪽의 지원은 처참하기 이를 데 없다. Spine을 사용하는 대다수의 서브컬쳐 게임이 유니티로 개발되는 사유다.
다만 3D 인디게임을 생각한다면 언리얼 쪽이 유니티에 상당한 우세를 점한다. 이 때문인지 언리얼이 소규모 프로젝트에서도 파이를 조금씩 늘려가는 추세가 있다. 불과 몇 년전만 하더라도 인디 프로젝트는 유니티에 비해 언리얼을 이용하는 경우가 드물었으나 2018년을 기점으로 해서 스팀에 출시되는 게임들이나 ModDB 등의 커뮤니티에서 확인해보면 인디/소규모 팀에서도 언리얼을 사용하는 빈도도 점점 늘어가고 있음을 알 수 있다. 2012년을 전후로 인디/소규모 게임 개발에 유니티의 급격한 유행 이후 엔진 적응도에서 유니티만을 선호하는 경우가 아니라면 점차 언리얼로 넘어가는 편이고 특히 신규 인디 개발자들은 예전같으면 유니티로 시작했겠지만 규모에 따라 요즘에는 언리얼을 고려하는 경우도 많다.
앞서 서술했듯 아직도 절대다수의 2D게임이나 소규모 인디팀은 유니티의 선호도가 높은데, 언리얼의 2D 지원이 처참하며 아직까지 인디 개발팀이나 아마추어 등 소규모 개발자가 참고하기에 유리한 레퍼런스나 자료는 활용도가 유니티가 많은 편이고 또한 시간 대비 생산성은 유니티가 언리얼보다 우위에 있기 때문에 소규모 스타트업이나 인디 개발팀, 1인 개발자 등은 유니티를 선택하는 게 유리하다. 다만 개발팀은 소규모라도 프로젝트는 고급 퀄리티 또는 어느정도 규모가 있는 프로젝트를 추구한다면 언리얼을 선택하는 게 유리하고 언리얼 엔진 4를 이용한 1인 개발 게임 브라이트 메모리 인피니트처럼 실제로 그런 경우도 많다.
3D 중, 대규모 프로젝트의 경우 게임의 개발이 유니티로 상당 부분 진행됐음에도 불구하고 개발 도중에 유니티의 성능에 한계를 느껴 실제로 엔진의 교체를 추진해서 이미 출시가 됐거나 개발 중이며 이 외에도 다수의 게임들이 유니티로 개발 도중 언리얼 엔진 4로 갈아타거나 최초 기획 단계에서 유니티를 고려했다가 실제 프로젝트의 규모가 커지면 언리얼 엔진 4로 개발되는 경우가 발생하는 케이스도 있다.
언리얼 엔진의 그래픽 구현 수준, 그리고 C++ 소스 코드의 자유로운 수정 가능이라는 우위 때문에 유니티는 언리얼 엔진에 서서히 잠식될 것이라는 예상이 많으며, 2016년 중후반까지는 저사양 스마트폰/모바일 게임의 개발에 한해서 유니티가 더 선호되고 있는 추세이나 언리얼 엔진 4의 모바일 지원이 점점 강화되면서 언리얼 엔진을 이용한 모바일 히트작이 하나둘씩 출시되어 가고 또 모바일의 고사양화가 가속화되면 3D모바일에 한해서 언리얼 엔진도 어느정도 많이 쓰이게 될것으로 보인다.
하이퀄리티 콘솔 및 PC 프로젝트에서는 고퀄리티를 가진 AAA급 콘솔 및 PC MMORPG는 프로젝트는 언리얼을 선호하는 경향이 강하고 그만큼의 성과를 유니티에 비해 안정적이게 뽑아낼수 있다. 유니티로도 일정한 수준 정도의 퀄리티를 갖춘 프로젝트는 뽑아내는게 가능하고 실제로 유니티 치고는 퀄리티가 높은 게임들도 드물게 있지만, 3D게임을 만들때 엔진의 성능과 퀄리티를 올리기 위한 엔진 커스텀이나 추가 플러그인들의 의존이 많고 그런 이유로 출시 이후 유지보수비용도 언리얼에 비해 많이 드는편이라 일정 수준 이상의 퀄리티가 필요한 프로젝트는 언리얼 엔진을 선탹할 수 밖에 없다.
또한 에픽게임즈에서 언리얼 엔진을 위한 투자를 늘림에 따라 퀵셀 믹서, 메가스캔 등 언리얼 엔진에서 무료로 사용가능한 강력한 툴들이 늘어나고 있는 점 또한 강점이 되고있다.
11. 결론[편집]
결론부터 말하자면 경쟁관계가 아닌 파이가 다른 엔진이다.
얼핏 보기에는 두 엔진이 비슷해 보일지 몰라도 유니티 엔진은 최소규모의 모바일, 2D 게임부터 중규모 게임까지에 주로 쓰이는 반면에 언리얼 엔진은 모바일도 어느정도 규모가 있는 정도부터 대형 AAA 온라인, 대규모 싱글, 콘솔 게임의 개발에 주로 쓰이는 엔진이고 그에 따라 엔진의 전체적인 구조 설계나 업데이트, 버전업 방향도 완전히 다르다.
물론 일정부분 파이가 겹치는 부분이 있어서 어느정도 경쟁 구도를 취하고는 있지만 일반적인 게이머나 유저 입장이 아닌 게임 개발사 입장에서 본다면 두 엔진은 라이벌 관게가 아닌, 분야가 완전히 다른 엔진이다. 해당 설명들이 게임에 치중되어서 그렇지, VR/AR이나 건축 디자인, 3D애니메이션 및 컨텐츠의 영역으로 갈때도 여러가지 다방면으로 비교되나 일반적으로 결과물이 고퀄리티로 렌더링 될 수요가 있는 경우는 언리얼, 실제 기기에서 가볍게 혹은 계속 업데이트해서 올리는 체감형 컨텐츠는 비교적 작업과 프로그램이 가벼운 축에 속하는 유니티가 강세이다.
유니티는 비교적 툴이 단순해 보여서 처음에는 익히기 쉽고 편리하게 느껴지지만 프로젝트의 규모가 커지면서 개발의 깊이가 깊어질수록 유니티로는 감당하기 힘든 그 한계가 드러나는 반면에 언리얼은 유니티와는 정 반대로 처음에는 복잡하고 어려워 보이지만 대규모 프로젝트에 필수적인 철저한 리소스 관리와 고퀄리티 그래픽 대비 최적화, 규모에 맞는 개발 툴의 편의성, 그리고 방대한 규모의 코드에서 엔진의 확장성, 유연성을 크게 고려한 덕분에 오히려 중급 이상의 규모에서는 유니티보다 개발 난이도가 더 낮아진다고 볼 수 있다.
실제로 넥슨이나 넷마블 같은 개발사를 보더라도 중소규모급 이하의 프로젝트 개발에는 유니티를, 중~대규모 AAA급 이상의 프로젝트의 개발에는 언리얼을 사용하고 있다. 국내 개발사뿐 아니라 해외 개발사도 마찬가지다.
만일 세간의 인식처럼 정말로 두 엔진이 업계에서 경쟁 관계로 인식되고 있다면 같은 개발사에서 개발하는 모든 프로젝트에 익숙한 하나의 엔진만 선택해서 개발하는 게 여러모로 훨씬 이득이므로 두 엔진을 다 사용하지 않을 것이다.
카메라로 비교한다면 언리얼은 전문가용 디지털 카메라 유니티는 일반 디지털 카메라에 비유가 가능하다.
일반인들의 간단한 사진 작업에 전문가용 카메라를 사용한다면 가볍게 가능한 작업까지도 복잡한 장비를 다루는 번거로움 때문에 일반 디카를 사용하는 게 더 편리할 수 있다.
반대로 전문가의 작업에 일반 디카를 사용한다면 일정 수준 이상의 작업을 하기에는 디카 성능의 한계가 명확하기 때문에 어느정도까지는 편법 등으로 커버하겠지만 그것도 한계가 있고 그 편법으로 커버하는 작업 자체도 전문가용 디카로 작업하는 것에 비해 효율이 많이 떨어질 것이다.
이처럼 일반 카메라와 전문가용 카메라는 서로 약간 겹친 부분이 있을지언정 서로 경쟁 관계가 아닌 명확하게 구분되는 각각의 파이를 가지고 있는 것과 마찬가지다.
12. 참고자료들[편집]
12.1. 유니티[편집]
유니티보다 더 구조가 단순하고 쉬운 엔진들도 많지만, 유니티의 접근성을 크게 높여주는 것 중 하나가 수많은 인터넷의 정보들이다.
유니티의 개발 자료들은 인터넷에 널려 있다 말해도 좋을 정도로 풍부하다. 사실 공식 사이트의 레퍼런스를 전혀 보지 않아도 유튜브나 블로그의 자료만 보고 공부해도 될 정도. 영문 자료를 읽는 데 어려움을 느끼는 비전공자들이 우리나라 네이버/티스토리 블로그에 공개된 예제나 따라하기 글들만 봐도 정보를 넘치게 얻을 수 있다는 점이 유니티 생태계가 넓은 데에서 오는 이점이라고 볼 수 있다. 유튜브에서도 한국인들이 우리말과 한글로 만든 수많은 유니티 공부 영상을 찾을 수 있다.
특히 유용한 것이 순수한 소프트웨어 개발 이외의 퍼블리싱 사이트에 등록하는 절차라든가, 각종 수익모델과의 연동이라거나, 광고회사에 등록하고 운영하는 방법이라든가 하는 행정적인 정보들인데, 이것들은 경험적인 팁이 필요하고 실수했을 때 불이익이 올 수 있는 민감한 사항들이 많아서 실제 사례들이 풍부한 것이 접근성에 대단히 크게 작용한다. 이런 측면에서 우리나라 사람들이 중,소규모 입장에서 자신의 경험담이나 실수담, 주의사항 등을 기록한 것이 많은 것이 상대적으로 장점이 된다.
소스코드 공유 사이트나 학교/연구소의 전산 이론 구현에도 유니티를 3D 렌더러처럼 사용하여 기술시연을 한 것이 많기 때문에, 어떠한 렌더링 기법이나 게임 알고리즘이 연구된 바 있다면 그 구현 사례에 유니티를 사용한 테스트 코드나 공개 프로젝트를 거의 대부분 찾아볼 수 있는 편이다.
12.2. 언리얼[편집]
규모가 어느정도 이상되는 개발사들의 경우에는 언리얼이 유니티보다 훨씬 오래된 역사와 사례를 가진만큼 언리얼 관련 고급 트러블 슈팅 등 각종 레퍼런스 자료들은 유니티보다 언리얼이 훨씬 방대하다. 언리얼 커스텀 라이센스 시 개발사의 직접적 지원외에도 언리얼 커스텀 라이센시들만이 접근 가능한 언리얼 개발자 네트워크에서 깊이 있는 기술이나 다양한 정보를 참조 및 공유할 수 있다.
이 문서의 내용 중 전체 또는 일부는 2023-12-09 02:06:59에 나무위키 언리얼 엔진 vs 유니티 엔진 문서에서 가져왔습니다.[1] UnrealScript의 주요 기능들을 계승하여 언리얼 엔진에 특화시킨 일종의 Unreal C++ 스크립팅 언어로서 기본적으로 언리얼 엔진 4의 구성 및 작동법을 잘 이해해야 제대로 사용할 수 있다.[2] 이는 C++ 각 객체별로 컴파일을 할수 있는것이 아니기 때문에, 엔진에서부터 시작한 상속받은 스크립트 전부 다 컴파일이 진행되어야 사용 가능하기 때문이다.[3] 포트나이트가 로블록스화 되어 포트나이트 게임 내에서 여러 유저 제작 게임들을 실행할 수 있다.[4] 언리얼 엔진이 소스 코드 공개화 정책을 시행하는데, 유니티 소스 코드 공개화 정책을 시행하지 않은 것을 두고 가혹한 라이센스를 취하고 있다는 의견도 있으나, 소스 코드는 소프트웨어 개발사에 있어서 막대한 자본과 시간, 그리고 노력의 산물이며 거의 대부분의 소프트웨어 회사는 자사 소프트웨어의 소스 코드를 당연히 공개하지 않는다. 언리얼 엔진의 소스 코드 공개화 정책은 시장의 지배를 위한 전략적인 판단에 따른 것이며 결코 언리얼 엔진의 소스 코드 가치가 낮아서 공개한 것이 절대 아니다. 소스 코드 공개화 정책 시행 이전의 언리얼 엔진은 소스 코드를 제공받는 계약 체결시 몇억원대의 라이센스 비용이 드는 엄청난 고가였으며, 그것을 포기하면서도 더 많은 것을 얻을 수 있었기에 가능한 정책인 것이다.[5] 특히 비트와 픽셀 레벨단위 수준의 구현[6] 코드를 연결하는 과정[7] 유니티 에셋 스토어의 비주얼 스크립팅. 2021년 현재에도 여전히 업데이트되고 있다.[8] 유니티는 유니티 자체에서 보기에 괜찮아보이는 플러그인을 에셋스토어에서 직접 인수해서 무료로 사용할 수 있도록 풀어 기능추가를 하는 경우가 왕왕 있는데, BOLT도 이런 경우에 속한다.[9] Ue4~5의 직교투영(Orthographic) 카메라는 못 써먹을 버그 덩어리고, 2D 쿼터뷰나 사이드뷰 시점을 투시(Perspective) 카메라로 재현하려면 카메라의 FOV값을 거의 2D에 가깝도록 조절해야 하는데, 어디까지나 수치로 비슷하게 내는 것이라 적당한 화면 사이즈를 맞추기 위해선 카메라 암의 길이를 극도로 길게 늘려야 하고, 이 해결법을 사용하면 다른 버그가 발생한다.[10] 이걸 어떻게든 사람답게 쓰고 싶다면 PaperZD같은 유저 플러그인을 쓰거나 기존 3D 스켈레탈 애니메이션의 코드를 보고 기능을 새로 구현해야 한다.[11] 알만툴만 봐도 타일맵에 애니메이션을 지원하는 기능이 있지만, 언리얼의 Paper2D 타일맵은 스프라이트 애니메이팅 기능인 Flipbook과 전혀 연동되지 않아 코드를 뜯어고치지 않는 한 기본 상태로는 애니메이션을 주는게 불가능하다. 또한 알만툴은 타일의 특정 칸에 특정 이벤트를 연결하는 기능도 있지만, UE의 타일맵 기능은 특정 타일에 이벤트를 연결하는 기능이 없다. 클릭, 오버랩 이벤트 등은 지원은 하지만, 정작 이 이벤트들이 타일맵 전체에 적용되고 특정 타일을 클릭, 오버랩했을 때만 이벤트가 실행되도록 작성할 수 없기 때문에 거의 의미가 없다.[12] 옥토패스 트래블러, 옥토패스 트래블러 II, 트라이앵글 스트래티지, 라이브 어 라이브 HD-2D 리메이크, 드래곤 퀘스트 III 전설의 시작 HD-2D 리메이크 등 언리얼 2D 게임이라고 알려진 게임 모두가 모두 3D 모델링 + 직교 투영이 아닌 3D 카메라를 혼용하여 사용한 유사 2D 게임이다. 넓은 의미에서 2D 그래픽을 사용한 게임은 맞지만, 고전적 2D 스타일로 개발된 언리얼 게임은 거의 찾아보기 어렵다.[13] 게다가 유니티 5.5 전까지는 Mono 2.0(무려 2008년도에 나온거다 이거...)을 그대로 쓰고 있어서 보안이고 성능이고 상당히 처참했다.[14] 언리얼 엔진3 까지는 유니티와 비슷한 스크립트 언어였다.[15] 해당 태그는 개발중인 '실험적인 기능'에 붙는 태그로 개발중인 기능이라 안정적이지 않고 지원을 받기 어려울 수도 있다는 문구다.[16] PaperZD를 비롯해 Paper2D의 허접한 기능을 좀 쓸만하게 증강시키는 유명한 유저 플러그인들이 있다.