언리얼 엔진 vs 유니티 엔진

1. 개요

이 문서는 전세계적으로 가장 유명하고 자주 사용하는 게임엔진인 언리얼 엔진과 유니티 엔진의 특징을 비교하는 문서이다.

==# 관련 영상 #==

위에 두 영상은 각각 2021년, 2022년에 제작된 영상들로, 영상에서 언급된 내용이 실제와 조금 다를 수 있다는 것은 감안하고 봐야 한다.

2. 스크립트 언어

2.1. 언리얼 스크립팅

초보적인 프로그래머들로만 구성되어 있는 팀의 입장에서 본다면 언리얼 엔진은 스크립팅 언어로서 새로운 언어를 배워야 하는 부담을 없애기 위해 언리얼 엔진 3까지 써오던 Java 스타일의 UnrealScript를 제거하고 보다 대중적으로 다가서기 위해서 게임 프로그래머들에게 익숙한 C++를 채용했다.[1]

언리얼 엔진은 아래에서 언급될 비주얼 스크립팅 언어인 블루프린트와 프로그래밍 스크립트 언어를 함께 사용하여 복잡한 구조나 퍼포먼스가 필요한 부분은 프로그래밍 언어로 구성하고, 가변성이 높은 부분은 디자이너가 간단히 변경할 수 있게 블루프린트로 구성하여 상호 보완적으로 활용 가능하다. 때문에 타 직군과의 협업이 굉장히 원활하다.

언리얼 엔진의 핫 리로드는 기본 기능 변경시 원활하게 적용되나 외부 모듈(프로젝트 내에서 서브 모듈이나 플러그인 등)을 추가하면 수동으로 리로드를 해주어야 했으며엔진에서 상속받을 스크립트부터 찾아야하기에 스크립트 추가시 거의 반드시 엔진 컴파일 과정이 필요했다.[2]

물론 근본적으로 유니티의 속도를 따라가기는 힘들지만, 그래도 상술한 난점들은 지속적인 업데이트를 통해 어느정도는 개선되었는데, 언리얼 엔진 4.22 버전부터 추가된 라이브 코딩을 통해 오브젝트 리인스턴싱을 특별히 고려할 필요없이 개별 함수를 패치하므로, 규모가 큰 프로젝트의 신뢰성이 보장되며 작업속도의 증대와 확장성이 기존보다 훨씬 높아지게 되었다.

언리얼 엔진은 2015년 3월 이후 버전 4이후 소스 코드 전체(지속적으로 업데이트되는 버전 역시 항상 전체 소스 코드 공개)를 공개한다는 점은 굉장한 강점이다. 복잡한 코딩이 가능한 프로그래밍 전문가가 있는 팀의 경우에는 여러모로 언리얼 엔진이 훨씬 더 낫다. 언리얼 C++의 빌드 툴의 지속적인 개선과 엔진을 직접 건드릴수 있는 강점이 있기 때문. 또한 엔진 자체에서도 제공하는 기능이 굉장히 많기 때문에 엔진에 있는 기능만 사용해도 유연하게 해결되는 경우가 상당수이다.

또한, 언리얼 엔진 문서에는 언급이 되어 있지 않지만 해외 커뮤니티에서는 C++ 대신 C#을, 혹은 스크립트 언어인 Lua나 Ruby 등을 언리얼에서 사용하는 방법에 대해 연구하기도 하고 실제로 그러한 스크립트 언어를 사용하여 개발하고 출시한 상용 게임도 있다.

언리얼 엔진 5와 더불어 Verse라는 새로운 스크립팅 언어를 공개했다. Python과 비슷한 문법 구조를 채택하고 있어 해외 커뮤니티에서는 배우기 쉽고 기존의 언리얼 C++를 대체해 줄 것으로 예상하고 있다.
트위치 스트림 링크

Verse는 2023년 3월 22일 출시한 포트나이트 언리얼 에디터(UEFN)[3]에서 사용 가능하며 포트나이트의 유저 제작 모드에 사용된다.
Verse 언어 레퍼런스

Verse 프로그래밍 언어는 우선 포트나이트 전용으로 출시하여 수 많은 사용자들이 사용하는 과정에서 언어를 계속 다듬는 과정을 거치고 추후 언리얼 엔진에 완전히 포함될 예정이다.

2.2. 유니티 스크립팅

유니티는 C#을 기본 스크립트 언어로 사용한다. C# 언어 자체가 C++에 비해 적응이 빠른 편이라 비 프로그래밍 직군도 많이 접근하게 된다.

유니티의 경우 스크립트 생성시 Monobehaviour 만을 상속받아 스크립팅을 하게 만들었다. 해당 파이프라인을 하나로 통일해 놨기 때문에 추가적인 기능이 언리얼 엔진에 비해 부족해서 컴포넌트 애드온을 필요한 분량만큼 추가해주어야 한다.

다행히 컴포넌트를 붙이는데 제약이 크지 않고, 언리얼 엔진 4에서 도입된 Hot Reload 기능이 구비되어 있어서 개별 오브젝트에 컴포넌트를 붙이면 즉시 컴파일 되면서 사용 가능한 상태로 바꾸기 때문에, 필요한 요소는 직접 만들어 도입할 수 있다.

문제는 비 프로그래밍 직군 작업자에 대한 편의는 적은 편이다. 언리얼을 따라 비주얼 스크립트를 개발했지만 사실상 유명무실하며 결국에는 비 프로그래밍 직군의 인원도 코드를 알아야 정확한 작업을 진행할수 있다. 이는 하단에 유니티 비주얼 스크립팅 문단에 후술한다.

유니티는 엔진 소스 코드를 제공하지 않아 소스 코드를 제공받기 위해서는 별도로 고가의 계약 체결이 필요하다.[4] 때문에 고수준의 작업에서는 자잘한 문제가 발생하고, 이를 피하고 개선하기 위해 우회를 반복하다가 어느새 엔진내 소스를 스파게티처럼 만드는 경우도 더러 있다.

3. 비주얼 스크립팅

3.1. 언리얼 블루프린트

프로그래머가 없는 팀의 입장에서 본다면 언리얼 엔진 4에서 새롭게 등장한 블루프린트라는 시각적 프로그래밍 언어를 이용해 블럭들을 마우스로 쭉쭉 이어주기만 하면 코딩 한 줄 없이 프로그래밍이 가능하다. 작동법 하나하나가 매우 복잡하게 되어 있는 블루프린트도 디자이너의 입장에서는 복잡한 세부 구성들을 전혀 이해할 필요없이 최종적으로 보여지는 유저 친화적인 프로퍼티들만을 가지고서 매우 손쉽게 개발을 할 수 있다.

또한 마켓플레이스에 올라오는 다양한 유&무료 블루프린트 애셋이나 코드 플러그인 애셋들을 활용한다면 C++ 프로그래밍을 할 줄 아는 개발자가 전혀 없더라도 많은 기능들을 손쉽게 구현할 수 있다.

실제로 개발 작업에서 많은 시간이 소요되는 반복처리 및 테스트를 프로그래밍을 전혀 모르는 디자이너들만으로도 가능하게 해 주는 큰 이점이 있다. 물론 전혀 새로운 기능들을 만들기 위해서는 복잡한 세부 블루프린트들을 직접 구성해야 하며 이는 어느 정도의 프로그래밍 지식이 수반되기 때문에 완전히 디자이너들만을 위한 툴은 아니라는 비판도 있었지만, 꾸준한 버전업을 통해 많은 부분들이 개선되면서 초보자의 입장에서도 사용하기 편리하도록 구조를 바꾸는데 주력한다.

지속되는 버전업을 통한 또 다른 개선점으로는 블루프린트가 단지 스크립팅 부문에만 한정되는 것이 아니라 언리얼 엔진 4 전반에 걸친 모든 기능들이 차차 블루프린트화되어가면서 더욱 유저친화적이면서 직관적이고 편리하게 변해가고 있다.

블루프린트는 비주얼 스크립트이므로 당연히 C++ 코드보다 속도가 느리다. C++로 작성시 20ms인 코드가 블루프린트로만 작성했을때는 상황에 따라 5~15배 느린 100ms~300ms의 속도차이가 발생하는 경우도 더러 있었으나 지속적인 개선으로 점차 속도가 빨라지고 있다.

블루프린트는 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 지원 쪽은 완전히 손을 놓았다고 봐도 무방하다.

일례로 라이팅과 셰이딩 기능은 언리얼 엔진의 강점 중 하나로 꼽히지만, 정작 엔진의 2D 직교투영 카메라 모드에서는 언리얼 엔진의 수많은 렌더링 기능은 물론, 가장 기본적인 라이팅과 셰이딩조차도 제대로 적용이 안되는 버그가 4.0 시절부터 5.2 버전까지 있었다. 언리얼 엔진 포럼에 해당 문제의 해결법을 묻는 질문이 2017년 4월에 올라왔는데, 라이팅과 셰이딩이라는 핵심 기능의 버그 수정이 무려 5년 이상이나 방치되어 왔다. 심지어 5.3에서 버그를 해결하려고 시도한 이유도 2D 게임 개발에 차질이 있어서라는게 직접적 사유가 아니라 위의 로드맵 글에서 서술된 것처럼 건축 및 제조 분야에서 큰 문제가 된다는 사유#였고 2D 개발자를 위한 배려는 뒷전이었다. 에픽게임즈가 2D 게임 개발은 사실상 신경쓰지 않고 있음을 알 수 있다. 심지어 앞서 언급했듯이 5.3에서도 2D 카메라는 실험적 기능이며, 5.2까지 고질적인 문제를 일으키던 버그가 완전히 해결되지 않았다.#[9]

언리얼 2D 개발의 중핵인 Paper2D 플러그인의 경우, 언리얼 엔진 5로 버전업된 현재 시점까지도 3D 애니메이션에서는 당연하다시피 지원하는 기능인 애니메이션 스테이트, 소켓, 노티파이 기능조차 제공하지 않는 반쪽짜리 플러그인이라서, 제대로 쓰고 싶다면 PaperZD같은 유저 플러그인을 쓰거나 기존 3D 스켈레탈 애니메이션의 코드를 보고 기능을 직접 구현해야 한다. 2D 게임 개발에서 필수적으로 사용하는 스프라이트 타일맵 기능의 경우 엔진이 5로 버전업하기 이전에 8년이란 기간동안 실험적 기능이라는 Experimental 태그를 붙이고 방치되어 있었으며 타일맵 기능은 일부 요소만 보면 알만툴보다 뒤떨어진다.[10]

에픽게임즈는 기본적으로 2D 개발을 위한 기능 지원 자체를 경시하고 있어 버전 업데이트에도 2D 게임 개발을 위한 기능은 거의 추가되지 않으며, 그나마 있는 기존 기능에서 발생하는 버그 수정도 거의 이루어지지 않았고, 언리얼 엔진 5로 버전업하며 2D 템플릿은 아예 통으로 삭제되었다. 온라인 러닝으로 제공하는 2D 템플릿을 마켓플레이스에서 여전히 다운로드 받을 수 있긴 하지만, 기본 제공하던 템플릿을 버전업하며 제외한 것은 엔진의 개발 방향성이 전적으로 3D에 집중되었음을 알게 해준다.

물론 일단 명목상으로 개발할 수 있는 구색은 갖추고 있으므로 어떻게든 만들 수는 있다만, 2D 게임 개발의 경우에는 개발력이 애초부터 부족한 인디 팀이 2D 베이스가 두텁게 깔려있는 2D 전문 게임 엔진들을 두고, 개발사인 에픽부터 손을 반쯤 놓아서 기본적인 기능도 부실하고 버그도 방치된 상태인 언리얼을 선택할 이유는 거의 없다. 엔진이 제공하는 렌더링 퀄리티가 좋아서 그래픽이 잘 나올 포텐셜이 있다는 것 정도인데, 웬만한 2D 게임은 그렇게 높은 그래픽을 상정하지 않아 언리얼이 제공하는 렌더링 기능 대다수가 과유불급인데다, 단순한 과유불급 수준을 넘어 오히려 문제를 일으키는 경우가 많다. 최적화를 위한 밉맵 기능, 더 부드러운 그래픽을 위한 안티 앨리어싱 기능, 모션 블러 등이 픽셀을 뭉게버려서 흐릿하게 보이게 만든다거나 하는 식이다. 물론 이러한 기능들을 끄는 세팅을 통해 해결할 수 있지만 세팅을 하는 것도 고역인데다 끄는 것이 문제를 일으키기도 하며, 2D 카메라 버그 같은 일부 문제는 세팅으로 해결되지 않기에 3D 카메라를 사용해 2D를 우회적으로 표현하거나 엔진의 코드를 직접 수정하는 수준까지 들어가야 한다.

때문에 언리얼로 개발되는 2D 게임들은 거의 대부분 3D 모델링과 3D 카메라를 2D 스프라이트와 혼합한 스타일을 주로 사용한다.

그런 게임들은 3D 모델링 + 직교 투영이 아닌 3D 카메라를 혼용하여 사용한 유사 2D 게임이다. 넓은 의미에서 2D 그래픽을 사용한 게임은 맞지만, 완전 2D 그래픽으로 개발된 언리얼 게임은 거의 찾아보기 어렵다.

그러나 고전적 2D 시점에 버그가 많은 것일 뿐, 3D 부분은 안정적이기 때문에 과유불급이라는 각종 렌더링 기능도 과유불급이 아니게끔 제대로 살려서 뛰어난 퀄리티를 보여주는 게임들도 있으며, 캐릭터와 배경에 모두 스프라이트만 사용하는 고전적인 평면적 2D 게임이 아닌 2D와 3D를 적절하게 섞은 스타일의 게임들 같은 경우에는 언리얼 엔진을 사용하여 상당한 퀄리티를 가진 2D 그래픽을 낼 수 있는 잠재력이 있다.

결론적으로 말해서 언리얼로 2D 게임을 만들지 못하는 것은 아니지만, 기본적으로 언리얼은 고퀄리티 3D 게임을 만들기 위한 소 잡는 칼이며, 언리얼로 만들 수 있는 2D 게임은 유니티로도 대부분 비슷하게 만들 수 있다. 쌓인 2D 개발자 풀과 자료는 유니티 쪽이 풍부한데다 언리얼 자체가 고전적 2D 게임 개발은 매우 미흡하게 지원하기 때문에 가벼운 2D 게임을 만들 것이라면 언리얼은 좋지 못한 선택이다.

다만 3D와 혼합하여 고품질의 렌더링과 셰이딩 효과를 사용하는 대형 2.5D 게임들인 옥토패스 트래블러, 옥토패스 트래블러 II, 트라이앵글 스트래티지, 라이브 어 라이브 HD-2D 리메이크, 드래곤 퀘스트 III 전설의 시작 HD-2D 리메이크 같은 게임들의 예시에서 볼 수 있듯이 이러한 작품들의 경우에는 언리얼 엔진을 사용하는것이 탁월한 선택이 될 수 있다.

4.2. 유니티 2D 기능

2D 개발자들은 대부분 게임메이커, Godot Engine 또는 유니티를 사용한다. 전문 2D 툴보다는 부족한 부분도 많지만 웬만한 2D 게임은 무리없이 개발할 수 있는 수준이며 관련 레퍼런스나 자료도 두터운 편이다.

5. 애셋 시장

5.1. 언리얼 마켓플레이스 → 팹(Fab.com) (2024년 출시 에정)

언리얼 마켓플레이스는 언리얼 엔진의 각종 기술 데모 뿐 아니라 에픽 게임즈에서 직접 개발하다가 중단된 AAA급 게임의 리소스를 공짜로 제공하기에 여러 프로토 타입을 제작하거나 학습에 매우 유리하다.

2015년에는 모바일 게임인 인피니티 블레이드 던전, 2018년에는 무려 1200만 달러(한화로 127억원)의 개발비용이 투자된 파라곤의 리소스를 누구나 다운로드 받아서 사용할 수 있게 풀어서 AAA급 퀄리티를 가진 리소스 제작의 학습뿐 아니라 그대로 사용하던 수정해서 사용하던 해당 리소스들을 상용 게임에 활용하는데도 제한을 두지 않았기 때문에 중소규모의 개발사나 1인 개발자들에게도 엄청나게 큰 도움이 되고 있다. [11]

그리고 퀵셀 메가스캔을 인수하여 지속적으로 고품질의 애셋들을 무료로 공개하고 있다. 또한 상당한 퀄리티를 지닌 이달의 무료 콘텐츠를 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. 유니티 엔진

유니티 엔진은 2021년부터 한국어판을 지원한다.

7. 작업 결과물 품질에 따른 편의성 및 작업 속도

결과물 품질	프로젝트 규모	편의성 우위	작업 속도 우위
높음	복잡	언리얼	언리얼
높음	간단	언리얼	언리얼
중간	복잡	언리얼	경우에 따라 다름
중간	간단	경우에 따라 다름	유니티
낮음	복잡	경우에 따라 다름	경우에 따라 다름
낮음	간단	유니티	유니티

위와 같이 평가할 수 있다.

작업 편의성은 1인 개발 또는 적은 인원의 개발팀으로 진행되는 소규모 프로젝트 또는 작업기간이 짧거나 리소스, 개발인력 및 자금이라는 제한이 걸린경우 유니티를 사용하는게 다소 유리한 편이다.

그러나 프로젝트의 규모가 작더라도 경우에 따라서는 언리얼의 작업 속도가 더 빠르고 간결하면서도 높은 품질의 결과물을 얻을 수 있는 상황도 있으며, 특히 규모는 작지만 고퀄리티의 품질을 가진 프로젝트의 경우에는 편의성과 작업 속도 우위도 언리얼이 우세하다. 언리얼 마켓플레이스에 고품질의 무료, 저가 애셋들이 많이 풀려있기 때문에 특히 Fab이 정식 서비스된 후에는 작은 프로젝트에서도 언리얼의 강세가 확연하게 눈에 띌 것으로 예상된다.

개발하는 프로젝트의 규모가 크다면 언리얼 엔진이 훨씬 유리하다. 유니티로는 프로젝트의 일정 규모 이상으로 커지거나 복잡하게 되면 여러모로 감당하기 힘든 일들이 발생하기 때문에 유니티로는 대형 AAA급을 만드는 일은 아예 없다.

언리얼 엔진의 경우는 초기 진입비용이 세지만 그 이후에 드는 비용은 낮다고 볼 수 있다. 결과물 또한 어느정도 큰 차이를 보이니 최종 결과물에서 앞선다. 유니티에 비해 진입장벽이 어느정도 높은 것은 맞지만 언리얼 엔진이 버전업 되면서 점점 편의성이 강화되고 다양한 교육/참조자료들이 나오고 있어서 예전과 같이 더이상 유니티보다 훨씬 높은 진입장벽은 아니다.

기본 엔진 자체의 요구사양이 상당한데, 유니티는 비교적 저사양에서 실행 가능하며, 즉시에 가까울정도로 빠르게 컴파일되어 문제가 생기면 빠르게 빠르게 수정이 가능하고 특별히 개발 환경을 크게 세팅할 이유가 없지만, 언리얼 엔진은 유니티에 비해 기본 요구사양이 높고, 상황에 따라 컴파일 한번 하는데도 사양이 낮으면 낮을수록 10분, 20분 이상의 시간이 소요되는 경우도 있다. 따라서 1인 개발자나 소규모 개발팀의 경우에는 개발 장비가 일정 사양이 되지 않는다면 언리얼을 사용하는데 어려움을 겪을 수 있다.

이는 준비 비용에 많은 영향을 받는다. 유니티 엔진이 언리얼 엔진에 비해 기술적 수준이나 성능이 많이 떨어지고 부족한 것이 사실이지만, 그만큼 심플하기 때문에 1인 개빌이나 인디/소규모 수준의 적은 Cost(인력, 자원 등)에서 비교적 빠른 개발 진행이 가능한데 비해서, 언리얼은 시작부터 일정 Cost가 준비되어 있어야 안정적인 개발 진행이 가능하다.

순수한 애셋(메쉬, 애니메이션, 텍스처 등)의 작업물 퀄리티는 엔진과 직접적인 관련 없이 별개의 툴(3ds 맥스, 마야, 블렌더 등)에서 제작하기 때문에 높은 Cost가 투자된 애셋 작업물을 유니티에 올려서 돌릴 수도 있긴 하다.

그러나 그것을 엔진에 올려서 돌렸을 때 여러가지 효과를 받는 최종 결과물에서 유니티와 언리얼의 차이가 나타나게 되는데 소위 말하는 엔진빨의 차이가 발생한다.

그렇게 눈에 보이는 그래픽적 퀄리티의 차이도 있지만 더욱 중요한 점은 대규모 프로젝트의 효율적 리소스 관리와 최적화, 확장성을 고려한 소스 코드 구조에 따른 유연함으로 인한 개발 효율성에 있기 때문에 프로젝트의 규모와 복잡성, 그리고 지속적인 업데이트에 따른 여러가지를 고려했을 때 대규모 프로젝트를 유니티로 유지할 경우 많은 문제점과 난관에 봉착하게 되므로, 언리얼로 가는 것이 현명한 선택이다.

8. 엔진의 확장성 차이

언리얼 엔진의 경우 4.x 버전대 초창기까지는 언리얼에서 별도의 프로그래밍 및 최적화 작업 없이 기본적으로 지원하는 기능이 적었다. 원래 주어진 렌더링 파이프라인의 퀄리티는 좋고 원래 제공된 옵션들 중에서 골랐을 대의 편의성은 좋지만 이것을 수정해서 원하는 것을 창조하려고 한다면(예를 들어 카툰 렌더링) 유니티처럼 단순히 셰이더를 갈아끼우는 방식으로는 불가능하고 렌더링 된 결과를 후처리 가공해서 (일종의 페이크) 효과를 주거나 엔진 소스를 고쳐서 셰이딩 방식을 변경시켜야 한다. 구체적으로는 셰이더를 바꾸기 위해서 셰이더를 생성해주는 엔진의 기능인 머터리얼 에디터의 입력인 머터리얼을 변경하는 식으로 간접적으로 변경하고, 그 결과로 렌더링된 최종 결과물을 포스트프로세싱해야 한다.

초기에 버전 4.13까지는 반투명 머티리얼을 만들기가 상당히 까다로운 문제도 있었다.

유니티처럼 '렌더링 자체를 카툰 셰이더로' 하려면 엔진에서 머터리얼→셰이더의 생성 코드를 수정해 사용자가 원하는 라이팅 정보를 참조할 수 있도록 만들어야 하며, 라이팅와 연관된 엔진의 다른 여러 부분의 코드들도 그에 맞게 수정해 주어야 한다. 이러려면 당연하게도 셰이더와 렌더링 파이프라인에 관련하여 프로그래머로서의 상당한 지식을 필요로 하게 된다.

또한 1인칭으로 환경 위에서 캐릭터를 컨트롤하는 구조를 만들려고 할 때, 언리얼이 이미 제공되는(그리고 바꾸기 매우 어려운) 입력→입력 컨트롤러→플레이어 컨트롤러→페르소나 구조를 사용하여 거의 건드릴 것도 없이 상용 수준으로 다양하고 풍부한 조종이 가능한 결과물을 뚝딱 만들어 낼 수 있으나, 그냥 키보드의 W키가 눌릴 때 박스 하나의 좌표가 X방향으로 1m 바뀌었으면 좋겠다는 근원적인 제어를 원할 때 다른 모든 오브젝트 필요 없이 박스 하나를 놓고 스크립트에서 W키→X좌표 +1 이라는 직결구조를 만들 수 있는 것은 유니티이다.

그러나 언리얼 엔진도 버전업을 거듭하면서 언리얼 엔진이 기본 제공하는 기능이나 플러그인 추가로 다양한 문제를 해결할 수 있도록 업데이트되었는데, 반투명 문제 해결은 2016년도인 4.14 버전에서 해결됐으며, 언급된 카툰 렌더링의 경우도 2018년도에 나온 4.22 버전에서 간단히 구현할 수 있도록 이미 버전업되었고, 바로 위에 언급된 캐릭터 컨트롤 구조 만들기도 역시 5.0 버전에 나온 게임 피처(Game Features) 및 모듈형 게임플레이(Modular Gameplay) 등을 통해 이미 옛말이 되어버렸다.

소스 코드를 바탕으로 수정, 변경, 개량 등 엔진 자체를 확장하는 경우에는 언리얼 엔진은 잘 정돈되고 철저한 모듈, 컴포넌트화 등 유연한 구조 설계를 갖추고 있어 확장성이 뛰어나다. 그러나 유니티의 경우에는 풀 소스 코드 라이선스로 소스를 얻더라도 실질적으로 확장할 수 있는 데 한계가 크다.

9. 보안

게임 로직을 만드는 스크립팅 언어로 C#을 활용하기 위해 .NET 기반에 다이나믹 로더를 사용하는 유니티가 보안에 훨씬 취약하다.[12]

반면 게임 스크립팅 언어로 C++을 이용하는 언리얼 엔진은 게임 로직도 어셈블리로 컴파일 되기 때문에 상대적으로 안전하다.[13][14]

하지만 요즘은 유니티 역시 C++로 번역 후 컴파일하는 IL2CPP를 지원하고 있고, 최근의 대규모 개발들은 대부분 중요한 비즈니스 로직은 서버에 두고, 클라이언트는 서버에서 데이터를 얻어와서 사용하는 구조로 만들어지기 때문에 보안 수준은 결정적으로 프로그래머가 보안요소를 얼마나 적용하느냐가 결정한다. 싱글 플레이어 게임을 만든다면 언리얼을 쓰거나, 유니티를 쓴다면 중요 코드를 C++로 작성하는 것이 보안에 도움이 될 수도 있다. ~~그래도 털릴 코드는 뭘로 만들어도 털린다~~

10. 프로젝트 환경에 따라 적합한 엔진

이제까지 언리얼은 중~대규모 3D AAA급 프로젝트, 유니티는 대부분의 2D, 극소규모 ~ 중소규모급 3D 프로젝트에 사용하는 형태로 각각의 필요성에 따라 나뉘며 파이를 적절히 배분하고 있었으며, 현재도 그렇고, 앞으로도 그럴 것이다.

대형/AAA급 프로젝트는 고민의 여지없이 언리얼 엔진을 선택한다. 안정적인 최신 고급 기술 지원과 그에 대한 최적화 및 기술 호환성, 대규모 프로젝트에서의 효율적이고 안정적인 리소스 관리, 로우 레벨 단위에서의 엔진의 확장성과 소스 구조의 유연성, 엔진의 기능과 그대로 매칭되어 확장 가능한 툴의 유연성, 다양한 최적화 방안들에 있어서 엔진의 기본 설계부터가 근본적으로 유니티가 따라올 수 없는 구조이기 때문이다.

AAA급 이하 하이퀄리티 그래픽을 지향하는 게임 프로젝트들은 대체적으로 언리얼을 선호하는 경향이 강하다. 그만큼의 성과를 유니티에 비해 안정적이게 뽑아낼수 있기 때문이다. 유니티로도 비슷한 수준 정도의 퀄리티를 갖춘 프로젝트는 뽑아내는 것 자체는 가능하고 실제로 유니티 치고는 퀄리티가 높은 게임들도 가능하지만, 3D 게임을 만들때 엔진의 성능과 퀄리티를 올리기 위한 엔진 커스텀이나 추가 플러그인들의 의존이 많고, 그런 이유로 출시 이후 유지보수 비용도 언리얼에 비해 많이 드는 편이라 일정 수준 이상의 퀄리티가 필요한 프로젝트는 언리얼 엔진을 선택하는게 여러모로 이득이며, 실제로도 업계에서는 꼭 AAA급이 아니더라도 고퀄리티의 추구하는 게임 개발에는 언리얼 엔진을 사용해서 개발된 경우가 대부분이다.

고퀄리티를 추구하지는 않지만, 프로젝트의 규모가 중급 이상일 경우에도 언리얼 엔진으로 전환하는 경우가 많다. 언리얼 엔진의 기본 그래픽 구현 수준이 높고, C++ 소스 코드의 자유로운 수정이 가능한 점, 그리고 대규모 리소스 관리가 유리한 점 덕분에 게임의 개발이 유니티로 상당 부분 진행됐음에도 불구하고 개발 도중에 유니티의 성능에 한계를 느껴 실제로 엔진의 교체를 추진하는 경우도 많으며, 이미 유니티를 사용해서 출시가 됐거나 서비스 중인 게임, 또는 에피소드 형식의 게임들중에 일정 에피소드 이후부터는 언리얼 엔진으로 교체하는 경우도 많고, 최초 기획 단계에서는 유니티를 고려했다가 실제 프로젝트의 규모가 커지면서 언리얼 엔진으로 개발되는 경우가 발생하는 케이스도 있다.

반면 스마트폰/모바일 게임 개발은 상당수가 소규모/저예산 및 인디 게임들이 많기 때문에, 언리얼 엔진의 모바일 지원이 점점 강화되고 있긴 해도, 특히 규모가 작은 인디 게임의 경우에는 개발 진입장벽이 낮아서 부담없이 개발에 돌입할 수 있으므로 개발되는 숫자의 비율로 봤을 때 유니티가 더 선호되고 있는 추세다.

2D 게임이나 저예산/소규모 스타트업이나 인디 개발팀, 1인 개발자 등은 유니티를 선택하는 게 유리하다.

다만 개발팀은 소규모라도 프로젝트는 고급 퀄리티 또는 어느정도 규모가 있는 프로젝트를 추구한다면 언리얼을 선택하는 경우도 많아졌다. 2010년대 중반까지는 인디 프로젝트는 유니티에 비해 언리얼을 이용하는 경우가 드물었으나 2018년을 기점으로 해서 스팀에 출시되는 게임들이나 ModDB 등의 커뮤니티에서 확인해보면 인디/소규모 팀에서도 언리얼을 사용하는 빈도도 점점 늘어가고 있음이 확인되며, 2012년을 전후로 한 인디/소규모 게임 개발에 유니티의 급격한 유행시에 유니티로 개발에 입문하여 엔진 적응도에서 유니티만을 선호하는 개발자가 아니라면 언리얼도 많이 사용하는 편이다. 특히 신규 인디 개발자들은 예전같으면 유니티로 시작했겠지만 규모에 따라 요즘에는 언리얼을 고려하는 경우도 많다.

10.1. 유니티 엔진으로 개발된 게임이 언리얼 엔진으로 전환한 사례

그리고 유니티로 개발되던 게임이 개발도중 언리얼 엔진으로 교체하여 재개발하는 사례가 빈번하게 발생하고 있다.

상당수의 게임들이 유니티 엔진 기반으로 개발도중 기존에 유니티 기반으로 개발된 리소스를 모두 포기하고, 언리얼 엔진으로 교체하여 재개발하는 경우가 실제 사례들로 나타나고 있다.

주요한 이유는 개발하는 프로젝트의 규모가 커짐에 따라, 유니티로는 감당하기 힘든 대규모 프로젝트에서의 효율적이고 안정적인 리소스 관리, 로우 레벨 단위에서의 엔진의 확장성과 소스 구조의 유연성, 엔진의 기능과 그대로 매칭되어 확장 가능한 툴의 유연성, 다양한 최적화 방안 때문이다.

유니티는 비교적 툴이 단순하여 처음에는 익히기 쉽고 편리하게 느껴질 수 있지만, 개발과정의 깊이가 깊어질수록 한계가 드러나는 반면, 언리얼은 유니티와는 정 반대로 처음에는 복잡하고 어려워 보일 수 있어도, 개발과정이 진행되면서 방대한 규모에 대한 리소스 관리와 유연성 및 확장성 등 여러가지면에서 매우 효율적임을 알 수 있게 된다.

원래 유니티로 개발중인 게임의 엔진을 언리얼로 교체해서 개발하거나, 유니티를 사용해 이미 출시한 게임을 대규모 패치를 통해 언리얼로 엔진을 교체하거나, 유니티 엔진으로 개발됐던 에피소드 형식의 게임 중 차기 에피소드 등 특정 시점 이후에는 언리얼 엔진으로 개발하거나, 유니티 엔진으로 개발한 시리즈를 후속작/차기작부터는 언리얼 엔진으로 개발하는 게임들의 목록은 다음과 같다. 아래 목록이 전부는 아니고 찾아보면 이것들보다도 훨씬 더 많이 있다.

고스트러너
EVE 발키리
로딩 휴먼
데드 링거
워해머 40k 이터널 크루세이드
리틀 데빌 인사이드
화이트데이 2: 거짓말하는 꽃 [15]
화이트데이 2: 스완송
시스템 쇼크 리메이크
시스템 쇼크 3 기사 기사
스콘 인터뷰
언턴드 [16]
이카루스M
머더 마이너스 X
세션 스케이트보딩 게임
언어스드: 트레일 오브 이븐 바투타 [17]
보일링 보트
스컬프터 VR
Bendy and the Dark Revival [18]
MORDHAU [19]
Dark Deception [20]
Deck Nine Games의 Life is Strange 시리즈[21][22]
세션 스케이트 심
고스트 오브 어 테일 2
레이어스 오브 피어 2편 이후[23]
슬렌더: 더 어라이벌[24]
Killer Dolls Battle Arena[25]
팰월드 개발자 인터뷰

목록을 보면 알겠지만 인디에서도 유니티에서 언리얼로 이동하고 있는 것을 알 수 있는데 어찌보면 당연한 일인게, 대규모 프로젝트의 경우는 애초에 유니티를 사용하지 않고 언리얼로 시작하기 때문에 유니티에서 언리얼로 갈아타는 프로젝트들은 인디/소규모 게임일 수밖에 없다.

10.1.1. 반대 사례

소수 모바일 프로젝트의 프로토타입 단계에서 테스트 후 엔진을 변경한 사례는 있으나 개발규모가 작은 게임의 경우며, 그마저도 개발중간에 변경한 사례는 찾아볼 수 없는데 애초에 작은 규모의 게임을 만들던 팀은 개발 중간에 엔진을 바꿔서 새로 만들 여력이 없는 경우가 대부분이기 때문이다.

반대 사례 목록

달빛조각사 #

반대 사례는 달빛조각사의 경우가 있다. 처음 프로토 타입때는 언리얼로 개발하려고 했다가, 게임 자체가 대형급이 아니고 개발 규모가 작기 때문에 개발 비용 절감 등의 이유로 굳이 언리얼을 쓸 필요를 못 느꼈기 때문에 유니티로 다시 개발한 사례에 해당한다.

11. 결론

얼핏 보기에는 두 엔진이 비슷해 보일지 몰라도 유니티 엔진은 최소규모의 모바일, 2D 게임부터 중규모 게임까지에 주로 쓰이는 반면에 언리얼 엔진은 모바일도 어느정도 규모가 있는 정도부터 대형 AAA 온라인, 대규모 싱글, 콘솔 게임의 개발에 주로 쓰이는 엔진이고 그에 따라 엔진의 전체적인 구조 설계나 업데이트, 버전업 방향도 완전히 다르다.

물론 일정부분 교집합이 있으므로 어느정도 경쟁 구도를 취하고는 있지만 일반적인 게이머나 유저 입장이 아닌 게임 개발사 입장에서 본다면 두 엔진은 라이벌 관게가 아닌, 분야가 완전히 다른 엔진이다.

위에서 언급됐다시피 소규모/인디 게임에서도 유니티로 개발하던 프로젝트들이 언리얼 엔진으로 전환하는 사례도 빈번하게 나타나고 있긴하지만, 그 경우의 대부분이 개발 중 프로젝트의 규모가 커지거나 유니티로 구현하기 힘든 고퀄리티 그래픽 등 때문에 전환을 한 사례에 해당하며, 고퀄리티를 지향하지 않는 소규모 게임일 경우에는 유니티로 개발하는 경우가 많다.

게임 개발뿐만이 아닌 VR/AR이나 건축 디자인, 3D애니메이션 및 콘텐츠의 영역에서도 일반적으로 결과물이 고퀄리티로 렌더링 될 수요가 있는 경우는 언리얼을 사용하고, 실제 기기에서 가볍게 돌리는 체감형 콘텐츠는 비교적 작업과 프로그램이 가벼운 축에 속하는 유니티를 사용한다.

유니티는 비교적 툴이 단순해 보여서 처음에는 익히기 쉽고 편리하게 느껴지지만 프로젝트의 규모가 커지면서 개발의 깊이가 깊어질수록 유니티로는 감당하기 힘든 그 한계가 드러나는 반면에 언리얼은 유니티와는 정 반대로 처음에는 복잡하고 어려워 보이지만 대규모 프로젝트에 필수적인 철저한 리소스 관리와 고퀄리티 그래픽 대비 최적화, 규모에 맞는 개발 툴의 편의성, 그리고 방대한 규모의 코드에서 엔진의 확장성, 유연성을 크게 고려한 덕분에 오히려 중급 이상의 규모에서는 유니티보다 개발 난이도가 더 낮아진다고 볼 수 있다.

실제로 넥슨이나 넷마블 같은 개발사를 보더라도 중소규모급 이하의 프로젝트 개발에는 유니티를, 중~대규모 AAA급 이상의 프로젝트의 개발에는 언리얼을 사용하고 있다. 국내 개발사뿐 아니라 해외 개발사도 마찬가지다.

만일 세간의 인식처럼 정말로 두 엔진이 업계에서 둘 중 하나만 사용해야하는 경쟁 관계의 제품이었다면, 동일한 개발사에서 개발하는 모든 프로젝트에, 익숙한 하나의 엔진만 사용하는 게 회사 입장에서 여러모로 훨씬 이득이므로 두 엔진을 다 사용하지 않았을 것이다.

카메라로 비교한다면 언리얼은 전문가용 디지털 카메라 유니티는 일반 디지털 카메라에 비유가 가능하다.

일반인들의 간단한 사진 작업에 전문가용 카메라를 사용한다면 가볍게 가능한 작업까지도 복잡한 장비를 다루는 번거로움 때문에 일반 디카를 사용하는 게 더 편리할 수 있다.

반대로 전문가의 작업에 일반 디카를 사용한다면 일정 수준 이상의 작업을 하기에는 디카 성능의 한계가 명확하기 때문에 어느정도까지는 편법 등으로 커버하겠지만 그것도 한계가 있고 그 편법으로 커버하는 작업 자체도 전문가용 디카로 작업하는 것에 비해 효율이 많이 떨어질 것이다.

이처럼 일반 카메라와 전문가용 카메라는 서로 약간 겹친 부분이 있을지언정 서로 경쟁 관계가 아닌 명확하게 구분되는 각각의 시장이 구분되는 것과 마찬가지다.

12. 참고 자료

12.1. 언리얼

공식 사이트 문서 및 레퍼런스

공식 사이트의 기능별 설명 문서와 레퍼런스 자료는 매번 엔진 버전업시마다 버전별로 문서가 갱신된다.

언리얼 개발자 네트워크

규모가 어느정도 이상되는 개발사들이 체결하는 언리얼 커스텀 라이센스시 접근 가능한 언리얼 개발자 네트워크에서는 깊이 있는 기술이나 다양한 정보를 참조 및 공유할 수 있으며, 유니티보다 오래된 역사와 깊이 있는 개발에서의 다양한 사례를 가진만큼 고급 트러블 슈팅 등 각종 레퍼런스 자료들은 언리얼이 훨씬 방대하다.

udemy 언리얼 엔진 5 강좌(유료)

이득우의 언리얼 프로그래밍 강좌(유료)

12.2. 유니티

공식 사이트 문서 및 레퍼런스

언리얼과 마찬가지로 유니티도 버전별 문서가 갱신된다.

udemy 유니티 강좌(유료)

[1] UnrealScript의 주요 기능들을 계승하여 언리얼 엔진에 특화시킨 일종의 Unreal C++ 스크립팅 언어로서 기본적으로 언리얼 엔진의 구성 및 작동법을 잘 이해해야 제대로 사용할 수 있다.[2] 이는 C++ 각 객체별로 컴파일을 할수 있는것이 아니기 때문에, 엔진에서부터 시작한 상속받은 스크립트 전부 다 컴파일이 진행되어야 사용 가능하기 때문이다.[3] 포트나이트가 로블록스화 되어 포트나이트 게임 내에서 여러 유저 제작 게임들을 실행할 수 있다.[4] 언리얼 엔진이 소스 코드 공개화 정책을 시행하는데, 유니티 소스 코드 공개화 정책을 시행하지 않은 것을 두고 가혹한 라이센스를 취하고 있다는 의견도 있으나, 소스 코드는 소프트웨어 개발사에 있어서 막대한 자본과 시간, 그리고 노력의 산물이며 거의 대부분의 소프트웨어 회사는 자사 소프트웨어의 소스 코드를 당연히 공개하지 않는다. 언리얼 엔진의 소스 코드 공개화 정책은 시장의 지배를 위한 전략적인 판단에 따른 것이며 결코 언리얼 엔진의 소스 코드 가치가 낮아서 공개한 것이 절대 아니다. 소스 코드 공개화 정책 시행 이전의 언리얼 엔진은 소스 코드를 제공받는 계약 체결시 몇억원대의 라이센스 비용이 드는 엄청난 고가였으며, 그것을 포기하면서도 더 많은 것을 얻을 수 있었기에 가능한 정책인 것이다.[5] 특히 비트와 픽셀 레벨단위 수준의 구현[6] 코드를 연결하는 과정[7] 유니티 애셋 스토어의 비주얼 스크립팅. 2021년 현재에도 여전히 업데이트되고 있다.[8] 유니티는 유니티 자체에서 보기에 괜찮아보이는 플러그인을 애셋스토어에서 직접 인수해서 무료로 사용할 수 있도록 풀어 기능추가를 하는 경우가 왕왕 있는데, BOLT도 이런 경우에 속한다.[9] Ue4~5의 직교투영(Orthographic) 카메라는 못 써먹을 버그 덩어리고, 2D 쿼터뷰나 사이드뷰 시점을 투시(Perspective) 카메라로 재현하려면 카메라의 FOV값을 거의 2D에 가깝도록 조절해야 하는데, 어디까지나 수치로 비슷하게 내는 것이라 적당한 화면 사이즈를 맞추기 위해선 카메라 그림자 길이를 극도로 길게 늘려야 하고, 이 해결법을 사용하면 다른 버그가 발생한다.[10] 알만툴만 봐도 타일맵에 애니메이션을 지원하는 기능이 있지만, 언리얼의 Paper2D 타일맵은 스프라이트 애니메이팅 기능인 Flipbook과 전혀 연동되지 않아 코드를 뜯어고치지 않는 한 기본 상태로는 애니메이션을 주는게 불가능하다. 또한 알만툴은 타일의 특정 칸에 특정 이벤트를 연결하는 기능도 있지만, UE의 타일맵 기능은 특정 타일에 이벤트를 연결하는 기능이 없다. 클릭, 오버랩 이벤트 등은 지원은 하지만, 정작 이 이벤트들이 타일맵 전체에 적용되고 특정 타일을 클릭, 오버랩했을 때만 이벤트가 실행되도록 작성할 수 없기 때문에 거의 의미가 없다.[11] 사실 두 가지 조건이 있기는 하다. 하나는 당연하게도 상표권 사용 제한이며(즉 파라곤 리소스 사용 시에도 해당 프로젝트로 만들어진 게임의 이름이나 광고에 파라곤이란 상표를 사용을 하면 안된다.), 또 다른 건 오직 언리얼 엔진에서만 라이센스가 허가되어 있다. 물론 전자는 상식적으로 당연하고, 후자 또한 언리얼 엔진 환경으로써는 전혀 문제될 게 없다.[12] 게다가 유니티 5.5 전까지는 Mono 2.0(무려 2008년도에 나온거다 이거...)을 그대로 쓰고 있어서 보안이고 성능이고 상당히 처참했다.[13] 언리얼 엔진 3까지는 언리얼스크립트라는 고유의 스크립트 언어를 사용했었으나, 언리얼스크립트 대신 C++를 사용할 수도 있었고 키즈멧이라는 비주얼 스크립팅도 있었다. 언리얼 엔진 4부터는 C++와 블루프린트라는 비주얼 스립팅을 사용하며, Verse라는 새로운 스크립팅 언어가 도입 예정에 있다. Verse는 포트나이트 언리얼 에디터에 먼저 도입되어 사용중이다.[14] 사실 C++로 빌드를 하든 보안 솔루션을 붙이든 간에, 결국 클라이언트를 배포함과 동시에 코드나 내부 로직들은 까발려진다고 봐야한다. 단지 시간이 좀 더 걸릴 뿐..[15] 화이트데이: 학교라는 이름의 미궁(2017)는 유니티로 개발됐다.[16] 언턴드 버전 3까지는 유니티로 개발, 언턴드 버전 4부터는 언리얼 엔진 4로 개발되었다.[17] 에피소드 1은 유니티로 개발, 에피소드 2부터는 언리얼 엔진 4로 개발되었다.[18] Bendy and the Ink Machine에서는 유니티로 개발을 했었다.[19] 킥스타터 지원을 받아 개발된 인디 게임으로 처음 개발은 유니티 4로 시작해서 유니티 5로 업그레이드 했다가 중간에 언리얼 엔진 4로 변경하여 완성되었다.[20] 데모 버전은 유니티, 정식 버전은 언리얼로 개발되었다.[21] 시리즈의 최초 개발사인 DONTNOD Entertainment는 1편에 언리얼 엔진 3, 2편에 언리얼 엔진 4를 활용해서 개발했으나, 외전격인 비포 더 스톰의 개발사인 Deck Nine Games은 자신들이 유니티를 기반으로 개발사 자체 개량을 거친 StoryForge를 이용해 만들었다. 그러나 후에 1편을 Deck Nine Games에서 리마스터하면서 언리얼 엔진 4를 사용하기 시작했고, 1편 리마스터와 같이 리마스터된 비포 더 스톰의 리마스터는 비록 StoryForge에 유니티 버전업을 실시했으나 기존의 게임을 크게 건드리지 않고 리마스터하기 위함일뿐이었으며, 후속작인 트루 컬러즈를 비롯한 이후의 후속작들에 모두 언리얼 엔진을 사용하고 있다.[22] 특히 개발사인 Deck Nine Games는 자사의 게임 개발을 위해 유니티 기반의 StoryForge에 많은 투자를 했으나 그것으로 나온 게임은 Life is Strange: Before the Storm 단 한작품 및 그 리마스터뿐이며, AAA급 대규모 게임 개발에 유니티의 한계를 느껴 그간 투자한 StoryForge를 포기하고 향후 개발 기반을 언리얼 엔진 4로 교체하였다.[23] 1편은 유니티 엔진, 2편부터는 언리얼 엔진으로 개발됐고 최근 리부트 되는 레이어스 오브 피어도 언리얼 엔진으로 개발된다. 레이어스 오브 피어 1편 이후 해당 개발사에서 만드는 모든 게임이 언리얼 엔진으로 개발되고 있다.[24] 유니티 엔진에서 언리얼 엔진 5.2로 리마스터한다.[25] 유니티 엔진으로 개발 도중 언리얼 엔진 4.27로 전환했다. 중간에 언리얼 엔진 5.1로 업그레이드된 데모가 공개됐다. 출시 버전에서는 언리얼 엔진 버전이 더 올라갈 예정이다.