유니티(게임 엔진)

(Unity 3D에서 넘어옴)
이 문서는 준보호 상태입니다.

이 문서는 잦은 문서 훼손 및 수정 전쟁으로 인해 자동 인증된 사용자만 수정하도록 제한되었습니다.
Unity
개발사Unity Technologies
출시일2005년 6월 8일
최신 버전2016년 7월 28일 5.4.1
유형게임 엔진
기반 언어C, C++, C\#,
Javascript를 빙자한 UnityScript, Boo[1][2]
요금무료 / 정기 사용료 지불
unity3d.com

1 소개

소규모/저사양 게임에 적합한 게임 엔진.

2005년 6월 8일에 처음 발표한 게임 엔진으로 스마트폰이 대중화되기 전까지는 Windows, Mac OS X같은 PC 기반 플랫폼에서만 지원했으나, 2010년 Unity 3부터는 기존의 PC 플랫폼뿐만 아니라 iOS, Android같은 모바일 플랫폼, PS3, XBOX 360, Wii 같은 콘솔 게임기 등의 다양한 플랫폼발표기사으로 확장되면서 2012년 Unity 4가 발표된 이후 유니티 엔진으로 개발된 게임들이 급격하게 늘어났고 2015년 GDC에서 언리얼 엔진 4의 완전 무료화에 이어 유니티도 Unity 5를 정식 발표함과 동시에 개인용 무료화를 선언하였다. 그러나 완전 무료는 아니고 여러가지 조건에 따른 제약사항이 따른다.

현재의 유니티 엔진은 앞에서 언급한 플랫폼 이외에 VR 기기를 비롯하여 현세대에 해당하는 대부분의 플랫폼으로 개발 가능한 게임 엔진이 되었고 최신 버전은 2016년 10월 기준으로 5.4.1버전이다. 2015년 9월에 발표한 5.2버전부터는 Windows 10 유니버셜 앱 플랫폼을 추가 지원하여 코드 작성에 있어서 Visual Studio 2015와의 연동이 가능하다. 또한 Windows 10을 지원하기 때문에 최신 API인 DirectX 12를 실험적으로 지원하고 있다.[3]

본래는 플래시가 한창 잘나가던 시절 플래시로 구현이 힘든 3D시장 공략을 노린 3D 타겟 웹미디어 제작툴이었다(초기 유니티 엔진은 멀티플랫폼 중 하나로 브라우저 역시 주력 지원했고, '유니티 웹 플레이어'라는 이름으로 현재까지 남아 있다. 현재는 웹플랫폼보다는 모바일 기반이 주력이 되었지만). 하지만 전문적인 게임엔진에 비해 비교적 단순하고 사용법이 쉽다는 점에 착안한 개발자들이 이를 이용해 게임을 만들기 시작하면서 아예 게임 엔진으로 방향이 선회되었다. 언리얼 엔진의 라이센스 정책 변경 전에는 유니티의 라이센스 비용이 매우 저렴하고, 여타의 고급 엔진들로 대형 프로젝트를 개발하는 것에 비해 단순한 게임들을 만들어 내기에는 비교적 쉬운 편이라서 아이폰을 필두로 한 모바일 게임이 새로운 블루오션으로 떠오르던 스마트폰 게임시장 태동기에 절묘한 타이밍으로 선점을 한 효과 덕분에 큰 성능이 필요없는 스마트폰 모바일에서 승승장구하였고 있다. Shiva3D와 같은 유사한 경쟁자들이 여럿 있으나, 에셋 스토어라는 생태계의 조성 및 넓은 사용자 풀이라는 조건이 형성되면서 독보적으로 치고 나아가는 모양새다.

그러나 언리얼 엔진이 의 모바일 시장까지 발을 넓혀가면서 그 입지가 서서히 양분화 되어가는 추세이며 2016년 기준으로도 아직 저사양/소규모 프로젝트에는 유니티가 많이 쓰이고 있는 상황이나 스마트폰도 차차 고사양화 되어가면서 고품질의 모바일 게임들이 언리얼 엔진으로 하나둘씩 히트하면서 스마트폰 게임 시장에서도 유니티의 독주체제를 막아서며 언리얼 엔진의 입지가 조금씩 넓어지고 있다.

언리얼 엔진이 교육정책에 힘을 쏟고 있는 것과 마찬가지로 유니티 역시 교육정책에 신경을 쓰고 있다.

2 장점

GUI가 아주 직관적이다. 그리고 셰이더, 물리 엔진, 네트워크, 지형 조작, 오디오 & 비디오, 애니메이션 등. 게임을 만드는 데 필요한 웬만한 기능을 자체적으로 지원한다. 따라서 초보 개발자도 쉽게 접근할 수 있다.

버튼 하나만 누르면 수많은 플랫폼으로 빌드가 가능하다. 즉, 게임 하나 만들어 놓으면 수많은 플랫폼에서 사용할 수 있단 소리다. 물론, 어느 정도 조정은 필요하다. 유니티가 지원하는 플랫폼은 웹브라우저[4][5], 윈도우, 맥, 리눅스, iOS, 안드로이드, 블랙베리, 윈도우 스토어 앱, 윈도우폰, 엑스박스 360, 엑스박스 원, 플레이스테이션 3, 플레이스테이션 4, PS Vita, Wii U, New 닌텐도 3DS[6]가 있다.
유니티 멀티플랫폼 안내 페이지

인디 개발자 혹은 초보자들을 지원하는 프로그램들이 적극적으로 이루어지고 있으며, 이로 인해 신규 진입하는 개발자들이 참고하거나 도움을 받을 만한 곳이 많다는 것도 장점. 다른 전문적인 엔진들의 경우 기본적으로 어느 정도 기반 지식이 있는 사람이라야 이해하기 용이한 자료가 대부분이지만 유니티의 경우 정말 생초보가 볼 수 있는 자료부터 보아도 충분히 많은 정보들이 인터넷 도처에 많이 제공되고 있다. 공식 포럼 뿐만 아니라 유니티를 이용하는 많은 신규 개발자들간의 정보공유가 되고 있다는 것도 '쉬운 엔진'으로서 기업대상 엔진들에 비해 갖는 이점.

무엇보다 유리한 것은 유니티에서 제공하는 '에셋 스토어' 생태계다. 유니티에서 사용할 수 있는 각종 리소스에서부터 스크립트, 플러그인으로 사용할 수 있는 여러 기능, 써먹을 수 있게 미리 만들어 놓은 AI 등 수많은 기능들을 이용자들이 올려서 사고 팔 수 있는 장터를 자체적으로 제공한다. 이 정책은 크게 성공하여 유니티 붐을 일으키는 데 일조했다. 사용자가 늘어나면 에셋 스토어에 더 많은 상품들이 올라오고, 그것을 본 사람들은 유니티 사용에 긍정적으로 접근하게 되고, 신규 유입된 사람들이 다시 스토어에 유니티 기능을 만들어 올리는 등 선순환 과정이 형성되어 있다. 애플의 앱스토어가 아이폰 자체의 기능을 넘어서 사용자들에게 매력요소가 된 것과 비슷한 원리.

몇몇 기능이 빠져있는 "유니티"는 무료이며 유료 버전은 "유니티 프로"이다. 하지만 프로버젼의 가격이 165만원으로 수억원에 달하는 다른 엔진들에 비해 싸다. 단, 다른 엔진들의 가격이 소스 코드를 포함하는 것과 달리 유니티는 소스 코드를 포함하지 않는다. 또한, 프로버전은 30일간의 무료 기간이 주어진다. 그리고 유니티 5를 발표함과 동시에 퍼스널 버전의 무료화를 선언하며, 그 전날 무료화를 선언한 에픽 게임즈에 맞섰다. 경쟁 사회 만세!

이러한 장점들 덕분에 벤처 기업이나 소규모 스타트업 창업, 또는 업종 전환을 하는 사람들 입장에서는 굉장히 유용하게 사용할 수 있다. 기본적으로는 3D로 개발하는 게임 엔진이지만 구현 방식을 조금 손보면 2D 게임도 문제없이 제작할 수 있다.[7] 나무위키에 개설된 유니티 기반 게임은 아래 항목에도 나와 있듯이 매우 많다. 지금도 많은 게임이 이 엔진으로 제작되고 있다.

유니티로 만들어진 게임을 보고 싶다면 유튜브에 Unity GDC[8]를 검색해보자. 공식 행사에서 뽑힌 퀄리티 높은 게임들을 묶어놓은 영상인데 2013년도 영상, 2014년도 영상 두개가 올라와 있다. 당장에 영상만 봐도 전반적인 완성도는 알 수 없지만 상당히 감각적이고 그래픽 퀄리티가 높은 기발한 게임들이 몇몇 보인다.

2.1 에셋 스토어

유니티를 다른 동급엔진에 비해 우월한 지위에 올려 준 요소 중 하나. 디자인, 모델링부터 유니티에 기능을 추가하는 플러그인에 해당하는 에셋까지 누구나 무료로 배포하거나, 유료로 판매할 수 있는 에셋용 앱스토어이다. 코딩에 익숙지 않은 디자이너들이나 리소스 제작이 힘든 개발자들이 이 에셋 스토어에서 구매하거나 무료로 다운받은 에셋을 사용하여 프로젝트를 수월히 진행해 주도록 도와준다.

항목에셋
GUINGUI, Scaleform[9], Noesis GUI[10], ...
2D2D Toolkit, ...
ShaderSubstance, Shader Forge, ...
ScriptPlaymaker, uScript, ...
AISimple Path, ...
TweeniTween, LeanTween, ...
ModelingSimplygon, GameDraw, ProBuilder 2, ...

에셋 스토어 폴더에 파일이 너무 많으면 로드가 매우 느려질 수도 있다. 그리고 빈 회색 화면만 보인다면 edit > project setting > player에서 use Direct3D 11을 체크 해제해 보자.

3 단점

간편하게 적용할수 있는 고급기능이 별로 없다. 고급기능을 활용하기 위해서는 개발자의 삽질이 필수적이다.

엔진 자체의 최적화가 아직 부실한 탓인지 일부 기기에선 프레임 드랍이 일어나기도 한다. 무엇보다 한국어 지원이 너무나도 부실해, 이 엔진으로 개발된 게임은 열이면 열 일부 또는 전체 글씨가 보이지 않는 버그가 생긴다. 한국인으로서는 큰 걸림돌. 윈도우에서 처음 구동시 사용자 계정명이 한글로 되어있으면 제대로 실행조차 되지 않는다. 더욱이 기본적으로 마이크로소프트 계정 연동으로 인해 계정명이 기본적으로 실명으로 생성되는 윈도 8 유저들이라면 유니티 하나 돌리겠답시고 새 계정을 만드는 곤혹스러운 과정을 치뤄야한다. 그야말로 병크다.

하지만 청강대에서 열렸던 유니티 로드쇼 2015에서 올해 내로 중국어를 제치고 한국어를 정식 지원하기로 언급했다.하지만 결국...

그리고 멀티 코어 프로그래밍이 불가능하다고 잘못 알려져 있지만, 실질적으로는 가능하다. 유니티 API가 메인 스레드 외에서는 호출이 안전하지 않기 때문에 제한적으로만 멀티 스레드를 적용할 수 있다. 하지만 이를 통해서 높은 성능 향상을 꾀할 수는 없다.[11] 노력 대비 얻는 성능 향상이 크지 않아서 이를 동적 로딩[12]에 응용하는 경우도 볼 수 있는데, 마찬가지로 유니티 API를 멀티 스레드에서 안전하게 사용할 수 없으니 완벽한 동적 로딩을 구현하기는 힘들고 성능 향상도 기대에 미치지는 못한다. 즉, 고도의 편법을 완벽하게 익혀서 문제가 될 부분을 최소화하여 적용하지 않는 이상, 성능 이슈가 될 가능성이 높은 부분을 병렬화하지 못해 0번 코어만 죽어라 갈구는 경우가 될 가능성이 높다는 것이다. 이런 상황이 높은 성능을 요구하는 게임에서 발생한다면 그야말로 망했어요. 실제로 유니티 엔진 4로 개발된 로켓 발사 시뮬레이션 게임인 KSP는 시뮬레이션 특성상 물리연산을 엄청 빡세게 하는데 이 물리연산 스레드를 코어 하나가 전부 감당해야 하기 때문에 어디가서 성능 좀 된다 하는 CPU도 부품이 많아지면 프레임을 제대로 못뽑는 상황이 무조건 발생한다. 이때문에 개발자가 유니티 엔진 5로 엔진을 갈아타는(!) 작업을 하는 중이라고... 그나마도 우주선 하나당 코어 하나씩 분담시키는 수준이 한계라고 밝혔다. 멀티스레딩이 안되어서 생기는 문제의 아주 대표적인 예.그렇게 AMD CPU 노트북은 죽어나간다 물론, 이 문제는 KSP 못지 않게 연산량이 드럽게 많은 시티즈: 스카이라인도 마찬가지인데, 여긴 아예 유니티 본사측에서 기술지원을 해줬다(...). 그나마도 실질적인 스레드 분담은 4스레드까지.

다수의 저성능 코어를 빅 리틀 솔루션까지 적용해가며 끌어모은 모바일 환경은 물론, 각 코어당 성능이 높은 편인 PC에서까지 영 좋지 않은 자원 활용도를 보일 수밖에 없다. 따라서 일정 수준 이상의 규모가 되는 게임을 개발하기에는 아쉬움이 크다. 그리고, 무엇보다도 다른 게임 엔진에서는 안전한 멀티 스레딩을 너무나도 당연하게 지원한다(...).[13] 미칠듯한 공밀레를 시니어 프로그래머에게 시전하면... 될까? 시니어 프로그래머는 안 그래도 할 게 많을 텐데

보안에 대해서도 말이 많은데, C# 프레임워크인 Mono에 기반했기 때문에 보안이 영 좋지 못한 수준을 넘어서 하나도 되지 않는다고 보는 게 정신건강에 이롭다. 강제로 오픈소스화된다고 할 정도로, 게임 내의 모든 리소스를 포함해서 스크립트의 코드를 담고 있는 DLL 또한 압축해제와 리버싱을 통해 얼마든지 내용이 드러나게 된다.[14] 이는 결과물이 중간 바이트코드인 대부분의 경우에 공통적으로 해당된다. 기계어 수준까지 컴파일이 되는 경우는 역컴파일이 쉽지 않고, 그마저도 현재는 C로 제한적인 표현이 가능한 수준이다. 그것도 다른 언어로 컴파일된 것이면 해석이 더욱 어렵다.

보안 문제는 메모리 해킹 방어, 스크립트 암호화[15]변수 암호화 및 다중화, 체크섬 및 패킷 암호화 등 프로그래머들이 갈려나가면서 보안성을 마련하면 어느 정도는 해결될 수는 있다.[16] 문제는 유니티의 낮은 진입장벽에 의해 코드 암호화를 하지 않는 프로그래머가 대다수라는 점이 문제다. 어차피 모바일 환경이 보안성을 살릴 수 없는 환경이라는 점과[17] "어차피 털릴 어플은 털린다."라는 생각을 가지는 개발자들이 대부분이고 현장의 인식도 여기에서 크게 다르지 않은 상태라서 많은 게임들은 클라이언트-서버 구조로 제작해서 중요한 부분을 서버에서 처리하는 형태로 운영되고 있다. 이러면 다행이기라도 하지, 아에 보안장치를 마련하지 않는 사례도 수두룩하다.

그래도 에셋 스토어에서 CodeGuard나 Anti-Cheat-Toolkit 등을 구입한다면 기본적인 코드 난독화, 메모리 해킹감지 등을 적용할 수는 있다. 물론 완벽하게 막아줄 수는 없다. 할 일 없는 해커들의 공격은 집요한 법

4 다른 개발도구와의 비교

4.1 유니티3D VS 언리얼 엔진 4

언리얼 엔진은 버전업 되면서 지원 플랫폼 증대, 라이센스 가격의 대폭 인하, 2D 게임 개발 기능 추가 등을 통해 기존 버전에서의 부족한 점을 보완했다. 또한 유니티도 그래픽이나 퍼포먼스 등 여러 면을 개선해왔기에 이제는 개발자의 취향이나 상황에 따라 선택하는 편이 좋으리라 보인다.

최신 유니티 5.x에서도 갖은 최신 비주얼을 보여줄 수 있는 렌더링 기술들을 많이 포함시켰으나 그것을 구동하는 퍼포먼스와 최적화는 아직도 언리얼 엔진에 한참 못 미치는 수준이고[18] 기본 태생과 기술적인면 자체에 있어서 워낙에 차이가 크기 때문에 고사양 게임에서는 유니티의 사용이 전무한 수준이다.

프로그래밍 면에서 유니티에서는 C#이나 자바스크립트로만 프로그래밍이 가능한 반면, 언리얼 엔진의 경우 블루프린트라는 시각 프로그래밍 언어를 지원해 블럭 덩어리를 갖다가 마우스로 쭉쭉 이어주기만 하면 어려운 코딩은 한 줄도 없이 프로그래밍이 가능한 것으로 보이기 때문에 언리얼 엔진이 초보 개발자에게 더욱 적합해 보일 수 있다. 하지만 실제로 해보면 알겠지만 블루프린트는 playmaker와 같은 유니티의 비쥬얼 스크립팅 유료 에셋[19]과 비교해보았을 때 프로그래밍을 잘 모르는 초보자는 제대로 만질 수조차 없는 물건으로 느껴지기도 한다. 코딩의 측면에서도 언리얼의 처음과 끝은 사실상 Unreal C++ (각종 매크로를 끼얹어서 마개조한 C++) 이며, 이에 대한 고수준 구사 실력만을 가지고 게임업계에서 밥줄로 써먹을 수 있을 정도로 속이 깊은 물건이다. 오히려 단순한 수준에서 조금씩 확장해 나가는 초보자의 입장에서는 유니티의 방식이 더 접근하기 쉽게 느껴질 수도 있다.

하지만 언리얼 엔진 4의 빠른 사용자들 피드백과 업데이트에 힘입어 블루프린트에 대해서도 지속 개선 및 초보자의 입장에서도 접근성이 높도록 점점 사용자 편의성이 증대되고 있으며 블루프린트 점점 커지는 언리얼 엔진 4 마켓플레이스의 유&무료 애셋을 통해 여러가지로 접근 편의성과 사용자 친화력이 강화되고 있으므로 초보자가 제대로 만질수 조차 없는 물건으로 느껴진다는 것은 점점 옛말이 되어가고 있다. 코딩에서도 언리얼 C++ 역시 지속적 빌드 툴 및 환경의 개선의 과 각종 예제와 도큐먼트 그리고 수 많은 언리얼 엔진 유저들에 의한 참고자료도 많이 나오고 있기 때문에 이 역시 초보자의 입장에서도 쉽사리 접근이 가능하도록 사용자 친화성이 강화되고 있다. 그리고 언리얼 엔진 4 문서에는 언급이 되어 있지 않지만, 해외 커뮤니티에서는 C++ 대신 C#나 Lua 또는 Ruby 같은 기타 스크립트 언어를 언리얼에서 사용하는 방법에 대해 연구하기도 하고 실제로 그러한 스크립트 언어를 사용하여 개발되고 출시된 언리얼 엔진 사용 게임도 있다.

복잡한 코딩을 할 수 있는 전문가의 경우에는 길게 볼 것 없이 여러모로 언리얼 엔진이 더 낫다. 유니티는 소스 코드를 열어볼 수조차 없고, 스크립트를 연결하는 방식의 프로그래밍만 가능하지만, 언리얼 엔진은 2015년 3월 이후 버전 4의 소스 코드 전체(지속적으로 업데이트 되는 버전 역시 항상 전체 소스코드 공개)를 공개한다. 다만, 유니티도 개발사와 유니티 社와의 계약을 통해 엔진 소스코드를 제공받을 수 있다. 다만 무료가 아니란 점이 문제.

2015년 3월 2일, 언리얼 엔진 4가 매달 19달러 + 매출액 5%의 기존 라이센스 가격을 무료+매출액 3000달러 이상시 5%로 또다시 유니티를 엿먹이는 정책으로 선회함에 따라 언리얼 엔진4가 크게 유리한 상태가 되었다. 게다가 GitHub 등을 통해 엔진 소스 코드를 오픈소스화하는 기존 정책은 여전히 유효하다. 유니티 5에서 파격적인 정책을 발표하지 않는 이상, 유니티 기반 개발자들이 언리얼 엔진4로 몰려들 가능성이 높아졌다. 이에 바로 다음날에 유니티 5의 퍼스널 버전 무료화를 선언했다. 하지만, 여전히 언리얼 엔진과 비교했을 때 다수의 제한이 있으면서도 상대적으로 높은 금액을 요구하는 것에서 경쟁성에 불리한 점을 갖는다. 퍼포먼스의 효율까지 생각한다면 언리얼 엔진으로 넘어가는 다수의 유니티 개발자들을 막지 못할 가능성이 크다.

실제로 유니티 기반의 게임들이 개발도중에 언리얼 엔진 4로 갈아탄 사례가 많다. EVE 발키리, 로딩 휴먼, 데드 링거, 워해머 40k 이터널 크루세이드, 리틀 데빌 인사이드 등의 게임이 이미 개발이 유닡로 상당부분 진행됐음에도 불구하고 개발 도중에 유니티의 성능에 한계를 느껴 실제로 엔진의 교체를 추진해서 이미 출시가 됐거나 개발중이며 이 외에도 다수의 게임들이 유니티로 개발도중 언리얼 엔진 4로 갈아타거나 최초 기획단계에서 유니티를 고려했다가 실제 프로젝트는 언리얼 엔진 4로 개발되는 경우가 허다하다. 이 경우 대부분 규모가 작은 프로젝트로 시작했다가 프로젝트의 덩치가 점점 커지면서 유니티로는 감당이 안되기에 언리얼 엔진 4로 교체하는 사례가 많으며 경우에 따라서는 소규모 프로젝트도 유니티에서 언리얼 엔진 4로 교체하는 경우가 있다.

언리얼 엔진 4의 관록있는 그래픽 구현 수준, 그리고 C++ 소스 코드의 자유로운 수정 가능[20]이라는 우위 때문에 유니티는 언리얼 엔진에 서서히 잠식될 것이라는 예상이 많으며, 2016년 중후반까지는 저사양 스마트폰/모바일 게임의 개발에 한해서 유니티가 더 사용되고 있는 추세이나 언리얼 엔진 4의 모바일 지원이 점점 강화되고 있으며 언리얼 엔진을 이용한 모바일 히트작이 하나 둘씩 나와가고 또 모바일의 고사양화가 가속화되면 상황은 점점 언리얼 엔진쪽으로 기울게 될 것은 자명한 일이다. 하지만 극소규모 프로젝트나 초저사양 게임들에는 유니티가 여전히 사용될 가능성은 다분하기도 하며 이는 향후 언리얼 엔진이 소규모 및 저사양에 어떻게 대응하느냐에 따라 달릴 것이다.

엔진용 컨텐츠를 쉽게 구할 수 있는 점에서는 2016년 기준으로 약 5년 이상 활성화 된 유니티용 컨텐츠몰인 에셋 스토어의 존재는 유니티를 이용하게 하는 결정적인 요소가 되기도 한다.[21]

언리얼 엔진의 컨텐츠몰인 마켓 플레이스는 2016년 7월 기준으로 이제 활성화 된지 고작 1년 남짓으로 유니티 에셋 스토어에 비해 규모가 작은 편이고 아직까지는 대부분의 컨텐츠가 그래픽 리소스에 편중되어 있기도 하지만 생각보다 매우 빠른 속도로 활성화가 되어가고 있고 공개된 리소스들도 그 하나하나가 모두 질이 매우 뛰어난 편이기 때문에 유니티 에셋 스토어의 규모를 넘어서는 것은 시간문제로 보이기도 한다.

유니티나 언리얼이나 레퍼런스와 공식 튜토리얼 동영상만으로는 진입하는 데 어려움을 느낄 수도 있다. 해외에는 두 엔진 모두 관련 자료들이 넘쳐나지만 국내에서는 공식 까페를 제외하고는 고수준의 개발과정을 다루는 포럼은 거의 찾기 힘들다. 2016년 기준으로 두 엔진 모두 관련 서적들도 한글판으로 꽤나 나와있다. 양쪽 모두 국내지사에 의해 다양한 행사를 개최하는데 2016년 기준으로 언리얼 엔진쪽이 더 지원과 행사에 신경을 쓰고 있는 모습을 여실히 느낄 수 있다.

엔진 자체의 한글화는 언리얼 엔진은 이미 언리얼 엔진 3 시절의 2009년부터 이루어졌고 유니티는 2016년 7월 기준으로도 아직 한글화가 되지 않았다. 공식 문서나 비디오 튜토리얼 등 공식적으로 제공하는 자료들의 한글화도 거의 MSDN을 방불케 하는 언리얼쪽과는 달리 유니티쪽운 번역을 하다 그만둔 수준이다.

보안성에 대해서는 큰 차이가 없다. 양쪽 모두 .Net 기반에 다이나믹 로더를 사용하기 때문. 사실 유니티는 스크립팅 언어로써 C\#를 활용하는 것이지, 실제로는 C++라고 봐도 무방하다.[22] 따라서 보안수준은 결정적으로 프로그래머가 보안요소를 얼마나 적용하느냐가 결정한다.

4.2 유니티3D VS 크라이엔진

엔진의 가격이나 개발난이도, 개발머신의 요구사양등에서 크라이엔진이 다소 밀린다. 플랫폼 지원역시 모바일, PC, 웹을 아우르는 유니티에 비해 PC와 콘솔만을 지원하는 크라이엔진이 중-소형 개발업체나 모바일 게임등에서는 쓰기 힘들다.

하지만 크라이엔진이 지원하는 기술의 격차가 상당하고 최적화역시 넘사벽으로 많이 차이나기에 그래픽 요구 수준이 높고 인력과 예산이 충분한 대형게임사에서는 많이 쓰는편.

4.3 유니티3D VS 플래시 몰힐(Molehill)

웹에서 실행할 수 있다는 점에서 비슷한 쓰임새를 가진다. 정확히 따지자면 유니티3D는 게임 엔진이고, 플래시의 몰힐은 DirectX나 OpenGL과 같은로우 레벨 API이다.(참고 사이트) 조금 다르지만 비유를 들자면 화가와 물감의 관계에 가깝다.

굳이 비교를 하자면 유니티3D는 직관적인 GUI를 통해 3D 쪽에서 높은 생산성과 함께 진입 장벽이 낮다. 플래시는 유니티3D보다 OOP적이며 높은 생산성, 특히 2D에 유리하다. 퍼포먼스는 몰힐이 로우 레벨 API라는 점에서 기기의 GPU 성능만 어느 정도 된다면 대체로 플래시의 몰힐이 더 높은 성능을 낼 것이다.라이센스 면에선 유니티3D는 다른 수억 대의 엔진들에 비하면 싸긴 해도 일단 돈이 들긴 드는데 비해, 몰힐은 그냥 공짜다. 가령 Flash Professional은 유료. 몰힐 자체는 공짜라서 몰힐을 Flex Builder에서 쓰든 공짜 툴인 Flash Develop, Haxe에서 쓰든 아무 상관없다. 사실 적용 대상이 달라 차이를 비교하기는 어렵다.

4.4 유니티3D VS cocos2d-x

몰힐의 비교와 비슷하다. 유니티는 C# 스크립트가 주가 되지만 cocos2d-x 는 C++ 코드가 주로 사용된다. cocos2d-x 는 드로우콜에 관련된 부분은 전부 OpenGL에 의존하며. 원래부터 GUI 기반의 에디터가 존재하지 않는 하드코딩이다. 나중에 GUI 에디터를 기반으로 개발된 Cocos Studio가 나왔지만, 나온지 얼마 안 되서 그런건지 기능적인 지원 수준이 유니티 엔진에 비하면 부족한 편이다. 3D도 지원하긴 하지만 지금으로써는 거진 OpenGL로 3D 게임을 만드는 것보다 약간 더 편리한 정도 차이 밖에 없다. 3D 기능을 사용하고 싶다면 코코스2dx를 사용하는 것보다 유니티 엔진이나 언리얼 엔진을 사용하는것이 훨씬 낫다. 아니, 비교가 불가능할 정도.

2D에 특화된 코코스2dx라서 2D쪽으로는 유니티 엔진과 경쟁할 정도로 생산성이 높다지만... 코코스에서 지원하는 기능만을 사용해서 개발하기엔 무리다. 언제가 되었든 간에 반드시 클래스와 객체지향적 프로그래밍을 알아야 하기 때문에, 첫 진입장벽은 꽤 높은 편이다.

4.5 유니티3D VS 쇼크웨이브

유니티 초창기에 있던 떡밥. 이때까지만 하더라도 윕상에서 3D를 구현하는 가장 편리하고 성능좋은 방법중 하나로 쇼크웨이브가 자리잡고 있었고, 이에 유니티 웹 플레이어가 도전하는 입장이었다.
초기에는 듣보잡 취급도 받았지만 점점 유니티쪽으로 기울더니 유니티3에서 모바일 지원을 해버리면서 지금은 사실상 유니티의 승리. 또 어도비에서 플래시를 민다며 플래시의 3D성능, 기능도 대폭 강화했기에 전혀 쓸일이 없다.

5 기타

대한민국 서울이 2012년 유니티 엔진 사용 집계에서 전 세계 도시 중 1위를 차지했다(관련 기사). 또 소규모 업체들에게는 연매출 10만 달러 미만이면 유니티 5 엔진을 무상 제공하기로 했다. #

5.1 유니티 기반의 게임들

나무위키에 관련 페이지가 등재된 것들만 이곳에 기입합니다.

5.2 유니티짱

해당 항목 참조.
  1. ↑ 엔진은 C++로 개발, API는 C#을 스크립팅 언어로 활용하여 작성한 형태를 띄고 있다. 이전에는 Boo라고 하는 언어도 지원했고 지금도 쓸 수는 있으나 5.0으로 넘어오면서부터 API 문서를 지원하지 않는다고 공지하였다. 사실상의 퇴출 수순. 사실 Boo는 파이썬과 굉장히 유사한 언어고 기존에는 JS와 함께 여타 언어를 쓰던 유저들을 잡을 목적으로 지원했지만 그래도 제법 쓰고있는 JS에 비해 사용률이 매우 저조했기 때문에...2016 6 10 현재 https://unity3d.com/kr/unity 에서 볼 수 있는 사용 가능 스크립트에도 아예 빠져있다.
  2. ↑ 사실, .Net 기반 언어이면 모두 사용 가능하다. F#도 가능하다는 이야기. 추가로, 파이썬을 사용할 수 있게 해주는 플러그인도 있다.
  3. ↑ 경쟁 게임 엔진인 언리얼 엔진 4 역시 2015년 8월 31일에 발표한 4.9.0버전부터 DirectX 12를 실험적으로 지원하기 시작했고 2015년 11월 11일에 발표한 4.10.0버전에서부터는 Visual Studio 2015를 정식으로 지원하기 시작했다.
  4. ↑ NPAPI를 사용한다. 따라서 크롬에서는 사용할 수 없다.
  5. ↑ 버전 5부터 플러그인 형태의 WebPlayer지원이 종료되고 WebGL기반의 새로운 플랫폼을 지원한다.
  6. ↑ 구다수라고 불리는 기존 3DS는 지원이안된다 유니티 기사
  7. ↑ 최신버전에 2D 전용 기능들을 좀 더 강화하는 등 영역을 확장 중이다.
  8. ↑ 검색하기 귀찮으면 여기를 들어가자 고맙다
  9. ↑ Flash. 다만 유니티 스케일폼은 업데이트나 기술지원이 썩 활발한 편은 아니기에 말 그대로 있다 수준에 그치는 정도인데다 정작 이 항목의 에셋 스토어에는 있지도 않은데 이유는 더이상 기술지원을 안하기 때문에 아예 내려버려서이다. 실제로도 해당 플러그인은 게임계 전반으로 봐도 기존 전성기에 비해서는 쇠퇴하고 있다.
  10. ↑ XAML
  11. ↑ 유니티 API가 없는 순수한 연산 집약적 동작을 병렬처리하는 것인데, 이는 전체 동작에 대한 완전 병렬화가 아니다. 또한 연산 관련 코드에서 API를 통하지 않는 경우는 많지 않으면서, 대부분의 연산능력을 API에서 요구하기 때문. 즉, 병렬화가 되는 부분이 극히 일부이기 때문에 높은 이득을 취할 수는 없다. 암달의 법칙 참고.
  12. ↑ 오픈월드나 대규모 맵에서 사용하는 프리로드를 의미.
  13. ↑ 물론 멀티스레딩 자체가 쉽게 접근할 수 있는 분야는 아니지만, (지원을) 안하는 것과 (개인의 실력 때문에) 못하는 것은 차이가 크다! 그야 실력좋은 프로그래머를 멀티스레드 지원하는 엔진에 갈아넣으면 되니까요
  14. ↑ 물론 완벽하게 일치하지는 않는다. 컴파일을 진행하면서 전체적인 흐름을 깨지 않는 수준에서 최적화를 위해, 코드의 순서는 바뀌게 되기 때문. 그래도 스크립트의 전체적인 흐름은 파악하고도 남는다. 완전히 해커의 손에 떨어지는 셈.
  15. ↑ 유니티의 경우 다이나믹 로더를 이용하기 때문에 이것이 가능하다. 물론, 스크립트 복호화 모듈이 해커에 의해 완전통제되면 답이 없다.
  16. ↑ 물론 시간 많고 능력 좋은 수준급 해커와 만나면 털리는 것은 시간문제이긴 하지만...
  17. ↑ 모바일 앱인 안드로이드 앱의 경우 Java 패키징 형태로 제작되므로 해체에 대단히 느슨하다.
  18. ↑ 기본적으로 엔진을 구동했을 경우의 이야기이며 언리얼 엔진이라고 해도 전적으로 제작자의 최적화 정도에 따라 차이가 극심하다. 제약사항에 따라 이것저것 옵션을 끄기 시작하면 유니티에서 만들어지는 결과만도 못한 제품이 탄생할 가능성도 있다. 실제상황으로, UI 구성을 아무 생각없이 했다가는 드로우콜이 치솟고, 이를 적정수준으로 맞추기 위해 작업을 해나가다 보면 UI의 형태가 버틸 수가 없는 상황에 이르게 되기도 한다. 물론 이는 제작자의 역량에 따라 큰 차이가 있다.
  19. ↑ 유니티 에셋 스토어의 비주얼 스크립팅 항목에 많은 해결책이 있다. Playmaker, uScript Visual Scripting Tool, uFrame Game Framework 등등
  20. ↑ 유니티는 개발사가 직접 컨택하여 특정 계약을 맺어야 소스 코드를 전달받을 수 있다.
  21. ↑ 어지간한 중규모 이상의 개발사만 되더라도 그래픽/음원 리소스 제작팀을 포함하기 때문에 큰 영향이 없을 수도 있을 것이라 생각할 지 모르겠지만, 게임 업계에는 중,대규모 개발사만 있는 것이 아니다. 지금도 수많은 소규모 제작사와 인디 개발팀은 에셋 스토어의 은혜를 입고 있다. 1인 개발이나 인디 개발팀에게는 에셋 스토어만한 리소스 제공처도 드물다. 어디까지나 2016년 7월 시점에서 본 것이며 앞으로의 판도는 얼마든지 뒤바뀔 수 있다.
  22. ↑ 애초에 .Net에 기반을 둔 언어는 로직만 비슷하다면 각 언어별 특성에 따른 부분을 제외한다면 비슷한 코드를 생산하게 된다.
  23. ↑ 생 유니티 엔진을 사용한것이 아닌 개조된 엔진을 사용했다.
  24. ↑ 어쌔신 크리드 시리즈 중 유일하게 자체 제작 엔진을 사용하지 않은 작품이다. 그런데도 그래픽이 콘솔/PC판 어쌔신 크리드 시리즈와 느낌이 비슷하다.