mir.pe (일반/밝은 화면)
최근 수정 시각 : 2024-11-02 19:25:26

유니티(게임 엔진)

유니티3D에서 넘어옴
파일:하위 문서 아이콘.svg   하위 문서: 유니티(게임 엔진)/도움말
,
,
,
,
,
#!wiki style="display: inline; display: none;"
, }}}
||<tablebordercolor=#000,#fff><tablewidth=100%><tablebgcolor=#fff,#1c1d1f><bgcolor=#000,#fff> 게임 엔진 ||
{{{#!wiki style="margin: 0 -10px -5px; min-height: calc(1.5em + 5px);"
{{{#!folding [ 펼치기 · 접기 ]
{{{#!wiki style="margin: -5px -1px -11px;"
메이저 상용 게임 엔진
파일:언리얼 엔진 로고.svg 파일:언리얼 엔진 로고 화이트.svg 파일:유니티 로고.svg 파일:유니티 로고 화이트.svg
언리얼 엔진 유니티
관련 문서: 언리얼 엔진 vs 유니티 엔진
기타 엔진 목록 }}}}}}}}}

||<-3><table align=right><table width=500><bgcolor=#fff,#1f2023><table bgcolor=#fff,#1f2023><tablebordercolor=#000,#fff><colcolor=#000,#fff> Unity
유니티
||
파일:유니티 로고.svg 파일:유니티 로고 화이트.svg
<colbgcolor=#fff,#1f2023> 개발사 Unity Technologies
출시일 2005년 6월 8일
버전 LTS 6000.0.25( 2024- 10-31)
2022.3.51( 2024- 10-22)
2021.3.45( 2024- 10-16)
사전 릴리스 6000.1.0a2( 2024- 10-31)
유형 게임 엔진
프로그래밍 언어 런타임 C, C++[1]
스크립트 C#[2](지원 중)
UnityScript[3]
Boo[4]
그래픽
API
DirectX[5] | Vulkan | Metal | OpenGL[6] | WebGL
플랫폼 PC Windows | macOS | Linux
콘솔 PS3 | PS4 | PSP | PS VITA | PS5
XB360 | XB1 | XBX|S
Wii | Wii U | 3DS | Switch
모바일 iOS | visionOS | Android | Tizen | UWP
VR HMD Oculus Rift | HTC VIVE | PlayStation VR
Windows Mixed Reality | 구글 카드보드 | 기어 VR | 구글 데이드림
AR HMD ARKit | ARCore | Vuforia | Microsoft HoloLens | Apple Vision Pro
TV 안드로이드 TV | 삼성 스마트 TV | tvOS
클라우드 Stadia
자동차 테슬라 소프트웨어
요금[7] Personal 무료
(조건: 상한선 연매출 및 자본액 $100,000 / Unity 6부터는 $200,000)
Pro 월 ₩231,250 또는 연 ₩2,550,000
(상한선 연매출액 및 자본액 제한 없음)
Industry 월 ₩562,500 또는 연 ₩6,187,500
웹사이트 파일:홈페이지 아이콘.svg | 파일:홈페이지 아이콘.svg 한국

1. 개요2. 역사
2.1. Unity2.2. Unity 22.3. Unity 32.4. Unity 42.5. Unity 52.6. Unity 20172.7. Unity 20182.8. Unity 20192.9. Unity 20202.10. Unity 20212.11. Unity 20222.12. Unity 20232.13. Unity 6
3. 장단점
3.1. 장점
3.1.1. 직관적인 툴의 UI3.1.2. 간편한 빌드3.1.3. 낮은 요구 사양3.1.4. 에셋 스토어3.1.5. 넓은 사용자 층과 풍부한 관련 자료3.1.6. 저렴한 라이센스 비용
3.2. 단점
3.2.1. 낮은 버전 지원으로 인한 호환성 문제3.2.2. 제한적인 멀티스레드 기능3.2.3. GC 스파이크 문제3.2.4. 라이센스 문제3.2.5. 소스 코드 비공개3.2.6. 보안성 문제3.2.7. 버전 간 호환성 문제
4. 다른 개발도구와의 비교
4.1. 유니티 vs 언리얼 엔진4.2. 유니티 vs Godot Engine4.3. 유니티 vs 크라이엔진4.4. 유니티 vs 플래시 몰힐(Molehill)4.5. 유니티 vs Cocos2d-x4.6. 유니티 vs 쇼크웨이브
5. 학습6. 논란7. 기타

[clearfix]

1. 개요


Unity Technologies[8]가 개발하여 2005년 6월 8일 처음 출시된 게임 엔진이다.

주로 저사양/소규모 게임의 개발에 적합한 관계로, 특히 가벼운 모바일 게임에 많이 사용된다.
==# 트레일러/데모 #==
유니티 엔진으로 구현한 레이트레이싱 데모
실시간 시네마틱 티저 트레일러
파일:i8291144862.jpg
유니티 엔진 2019.3.14f1의 HDRP[9] 테크데모 SU:A(수아) 3.0

2. 역사

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

앞에서 언급한 플랫폼 이외에 VR HMD 또는 AR HMD 지원 기기 등을 비롯하여 현세대에 해당하는 대부분의 플랫폼으로 개발 가능한 게임 엔진이 되었다.

하지만 언리얼 엔진이 모바일 게임 시장까지 발을 넓혀가면서 그 입지가 서서히 양분화되어가는 추세로, 스마트폰도 점차 고사양화가 되며 고품질 AAA급 모바일 게임들은 언리얼 엔진을 사용하고, 저사양/소규모 프로젝트에는 유니티가 많이 쓰이는 상황이다. 언리얼 엔진이 교육정책에 힘을 쏟고 있는 것과 마찬가지로 유니티 역시 교육정책에 신경을 쓰고 있다.

또한 단순히 게임 엔진으로서 남지 않으려는 듯, 최근 여러 분야의 기술들을 확장 지원하고 시각효과 기업들을 인수합병하는 등 공격적인 확장 정책을 보이고 있다. 예를 들어, PyTorch를 통하여 게임 엔진 속의 오브젝트에게 머신러닝을 시키는 기능을 통합할 수 있는 ML-Agent 라던가, 자동차 및 제조산업을 위한 AR/VR을 제공하는 Unity Industrial Collection 라던가.

2021년만 해도 ' 아바타', ' 반지의 제왕', ' 왕좌의 게임' 등의 VFX 효과를 담당했던 웨타 스튜디오, 원격 데스크탑 및 스트리밍 기술기업인 Parsec, AR 건축 설계 기술기업인 비주얼라이브, 원격 동기화 협업 기술기업인 싱크스케치 등 다양한 분야의 가상현실 기업들을 흡수하고 있다.

유니티로 만들어진 게임영상은 유튜브 Unity GDC 채널에서 볼 수 있다. 공식 행사에서 뽑힌 퀄리티 높은 게임들을 묶어놓은 영상들이다.

공식 네이버 카페도 있다. 2018년 5월 말부터 한글 패치를 제공하고 있다.

2.1. Unity

2005년 6월 8일에 출시된 유니티 엔진의 최초 정식 버전으로, 초창기에는 macOS만 지원했으나 나중에 Windows와 PC 기반의 웹 브라우저들도 추가로 지원하게 되었다.

2.2. Unity 2

2007년에 출시된 첫 메이저 업그레이드 버전으로, 3D 기능 강화와 공동 작업 기능, 비디오 재생 기능을 비롯하여 50여가지의 새로운 기능들이 추가되었다.

2008년에 애플의 앱 스토어가 런칭되면서 iPhone OS(현 iOS)를 추가 지원하여 유니티 엔진으로 개발된 게임을 앱 스토어로도 배포할 수 있게 되었다.

2.3. Unity 3

2010년 9월에 출시된 버전으로, 기존의 PC 플랫폼과 iPhone OS( iOS)뿐만 아니라 Android 같은 모바일 플랫폼, PS3, Xbox 360, Wii 같은 콘솔 게임기 등의 다양한 플랫폼으로 확장되었고 동시에 전세계적으로 스마트폰의 대중화와 맞물려서 유니티 엔진으로 개발된 게임들이 급격하게 늘어났다.

현재 유니티 엔진 버전별로 모아 놓은 공식 아카이브에서는 2011년 7월 26일에 발표된 3.4 버전부터 다운로드 받아 사용할 수 있다.
5.0.0부터 다운로드 받아 사용할 수 있게 바뀌었다

2.4. Unity 4

2012년 11월 13일에 출시된 버전으로, DirectX 11을 지원하기 시작했고 새로운 애니메이션 도구가 추가되었다.

2013년에 페이스북이 유니티 엔진 기반의 게임을 위한 개발 도구를 통합함으로써 유니티 엔진으로 개발한 게임을 페이스북에 등록하기가 쉬워졌다. SNS 연동으로 다른 사용자에게 게임 추천 기능을 제공하여 접속할 수 있는 일종의 광고 캠페인 기능이 추가되었다.

2.5. Unity 5

2015년 3월 3일에 정식 출시된 버전으로, GDC 2015에서 언리얼 엔진 4의 완전 무료화에 이어 유니티도 개인용 무료화를 선언하였다. 그러나 완전 무료는 아니고 여러가지 조건에 따른 제약 사항이 따른다.

2015년 9월 8일에 발표된 5.2 버전부터는 Windows 10 유니버셜 앱 플랫폼을 추가 지원하며, 코드 작성에 있어서 비주얼 스튜디오 JetBrains Rider와의 연동이 가능하다.

2.6. Unity 2017

2017년 7월 10일에 정식 출시된 버전으로, Unity의 버전 이름이 연도 방식으로 변경되었을 뿐만 아니라 마이너 업데이트 버전의 형식도 2017.0.0 버전이 아니라 2017.1.0 버전부터 출발하는 것으로 변경되었다. 이후에 라이선스 정책도 변경되었다.

2017의 특정 버전부터 32비트 에디터를 더 이상 지원하지 않으므로 32비트에서 사용하려면 5 버전을 사용해야 한다.

2.7. Unity 2018

2018년 5월 2일에 정식 출시된 버전으로, 3D 그래픽 성능이 크게 개선되었고 잡 시스템과 ECS를 지원하여 멀티스레드를 이용한 포크-조인 방식의 병렬 프로그래밍이 유니티 스크립트에서도 사용 가능해졌다.

2.8. Unity 2019

2019년 4월 15일에 정식 출시된 버전으로, 경량 렌더 파이프라인이 정식으로 적용되어 2018 버전에 이어서 3D 그래픽 성능의 최적화가 개선되었고 버스트 컴파일러가 정식으로 적용되어 컴파일 속도가 개선되었다. 가비지 컬렉션 이슈가 일부 개선되었다.

안드로이드의 경우 64비트가 추가. 64비트 대응 추가 자체는 유니티 2017에도 비슷한 시기에 나온 2017.4.16f1부터 추가되었는데, 플레이 스토어에서 64비트 지원을 의무화하는[11] 구글 정책의 여파라고 한다. 다만, ARM 64비트 대응 과정에서 안드로이드의 x86_64 지원 여부때문에 사용 빈도로 대응 여부를 검토한 결과, 안드는 x86 쓰는 기기가 거의 없어 2019.3 버전부터 x86을 아예 빼버렸다. 그래서 안드로이드에서 유니티 엔진 쓰는 게임은 x86을 아예 미지원하는 경우가 늘었고[12] 이는 플레이 스토어의 어플리케이션 업데이트시 64비트 지원이 의무화된 2019년 8월부터 본격적으로 증가했다.

2.9. Unity 2020

2020년 현재 유니티의 게임 엔진으로 제작된 소프트웨어는 15억 개 이상의 기기에서 실행되고 있다. 유니티에 따르면 자사의 게임 엔진으로 제작된 앱은 전체 모바일 게임의 50%를 차지하고 매월 30억 회 이상 다운로드되고 있으며, 매일 약 15,000개의 새로운 프로젝트가 소프트웨어로 시작된다고 한다. 파이낸셜 타임즈는 유니티의 엔진이 "포켓몬 고와 액티비전의 콜 오브 듀티 모바일과 같은 세계에서 가장 수익성이 높은 모바일 게임 중 일부에 동력을 제공한다"고 보도했다.

2020년 6월, 유니티는 증강현실(AR) 애플리케이션 생성을 위한 추가 기능을 개발자에게 제공하는 MARS(Mixed and Augmented Reality Studio)를 선보였다. 유니티는 2020년 12월 9일 자동차 및 소매 솔루션 도구인 Unity Forma를 출시했다.

2020년 6월, 유니티는 유니티 에디터가 애플 실리콘을 지원할 것이라고 발표했다. 첫 베타 버전은 연도 말에 배포되었다.

2.10. Unity 2021

유니티 2021에는 유니티 비주얼 스크립팅 시스템인 Bolt, 멀티플레이어 게임을 지원하는 새로운 멀티플레이어 라이브러리, 향상된 IL2CPP 런타임 성능, 고화질 렌더 파이프라인을 위한 볼류메트릭 클라우드 등 다양한 신규 기능이 추가되다. 섀도 캐싱 및 HDRP용 스크린 스페이스 글로벌 조명, 유니버설 렌더 파이프라인의 경우 포인트 라이트 섀도, 디퍼드 렌더러, 일반 코어 엔진 개선 및 기타 수정사항이 포함되었다.

유니티 2021.2부터 애플 실리콘 정식 지원이 추가되었다. 애플 실리콘 에디터에 대한 Unity Hub 지원은 2022년 1월 버전 3.0부터 제공된다.

2.11. Unity 2022

유니티 2022의 변경 사항은 플레이 모드로 전환하고 파일을 임포트하는 데 필요한 시간을 단축하고 패키지 관리자에서 시각적 검색 쿼리와 다중 선택을 구현하여 생산성을 향상하였다. 2D 프로젝트의 경우 핵심 소프트웨어, 임포트, 애니메이션, 피직스 속도를 높이는 데 중점을 두고 변경 사항이 적용되었다.

스프라이트 아틀라싱이 수정되었다. 2D PSD 임포터에 PSD 확장 파일 및 레이어 관리 지원이 추가되었고 2D 물리학을 위한 Delaunay 테셀레이션이 추가되었다.

2.12. Unity 2023

HDRP 강화, 다중 플랫폼간 멀티플레이 환경 개발 개선, 제작하는 게임의 메뉴 등 UI를 실시간으로 확인하는 WYSIWYG 강화 등 개발 환경 개선이 많다.

DirectX 12와 플레이스테이션 5 환경에서 CPU 사용 효율이 최적화되었다.

하술하듯 유니티 2023은 사후 지원이 긴 LTS를 발매하지 않고 유니티 6으로 넘어갔다.

2.13. Unity 6

2023년 11월 16일, 유니티는 엔진의 다음 버전이 이전 버전 번호 매기기 규칙으로 되돌아가는 Unity 6라고 발표했다. Unity 6는 2024년에 출시될 예정이며, 새로운 제너레이티브 AI 툴인 Unity Muse와 Unity Sentis 등의 기능이 포함될 예정이다. 2024년 10월 정식으로 발매되었다.

기존 넘버링으로 버전 체계가 돌아간 것은 메인 버전이 "5"까지 출시된 언리얼 엔진 보다 숫자로 앞서 있다는 인식을 주기 위한 의도도 있는 것으로 보인다는 말도 있다. 플레이스테이션 3와 시절의 엑스박스가 엑스박스 "2"가 아닌 "360"으로 출시한 것, 그리고 언리얼 엔진이 4가 된지 얼마 되지 않은 시점이었던 지난 2016년도에 크라이엔진이 갑자기 넘버링을 크라이엔진 V(5)로 올렸던 것과 같은 의도다. 그러나 그게 아니더라도 유니티 5가 나온 시점은 지난 콘솔 세대였으며, 충분히 한 세대가 지난 시점에 넘버링을 올린 것이므로 굳이 그런 의도를 가지지 않은 것일 수도 있다. 5 버전을 유지해야할 시점인 몇 년 동안 버전에 년도를 붙였던 것이기 때문이다.

당초 Unity 2023의 세 번째 테크 스트림인 Unity 2023.3이 나올 예정이었으나 Unity 6 Preview라는 이름으로 출시되었다. 당초 2023 LTS로 알려졌던 버전은 Unity 6라는 이름으로 나올 예정이다. 다만 기존 버전과의 호환성을 위해 내부 버전 넘버링은 6000대를 사용한다.

주요 기능개선은, 렌더링 성능 향상: GPU Resident Drawer, 조명 워크플로우 최적화, Multiplayer 생성 단순화, 웹 런타임으로 멀티플랫폼 범위 확장(얼리 액세스), AI 개선, 여러가지 툴과 기능 업그레이드가 있다.

3. 장단점

3.1. 장점

유니티 엔진의 장점은 크게 다음과 같이 살펴볼 수 있다.
시간이 지난 요즘에는 여타 게임 엔진들도 엇비슷하게 따라간 상황이라 유니티만의 특별한 장점으로 보기 힘들어졌다.

3.1.1. 직관적인 툴의 UI

툴의 GUI가 매우 직관적이다. 내부 에셋들의 위치를 바꾸고 적용하거나, 임포트 등이 매우 손쉽게 가능하며 유니티가 소규모/ 인디 게임에 폭발적인 인기를 얻게 된 가장 큰 비결이었다. 게임 엔진에서 유저 친화적 UI가 얼마나 중요한지 상징적으로 보여줬으며, 향후의 게임 엔진들에 매우 많은 영향을 주었다.[13]

3.1.2. 간편한 빌드

버튼 몇 번만 누르면 다양한 플랫폼으로 빌드가 가능하다. 그러나 플랫폼별 특성에 맞게 어느 정도 조정작업 및 별도의 최적화도 필요하다. 플랫폼별로 특징이 다르므로 당연한 일이며 유니티를 쓴다고 해서 그런 조정작업이나 최적화가 자동으로 되지는 않는다. 게임 하나 만들어 놓고 별다른 노력도 없이 다양한 플랫폼으로 출시할 수 있는 건 아니니 반드시 유의해야 한다.

3.1.3. 낮은 요구 사양

버전 업되면서 요구 사양이 점점 높아졌지만 AAA급 고퀄리티 게임을 개발할 수 있는 다른 메이저 게임 엔진에 비하면 비교적 가벼운 편이라 저사양 PC에서도 저사양 타겟의 간단한 게임 정도는 무리없이 개발이 가능하다.
다만, 어디까지나 다른 메이저 게임에 비해 가볍다는거지, 여기서도 개발자의 최적화 능력이 부족하다면 요구사양에 비해 버벅이는 문제점이 생길 수도 있다.

3.1.4. 에셋 스토어

인디 게임개발자들이나 초보 개발자들에게 유리한 이점을 제공한다. 바로 에셋 스토어의 존재다. 각종 리소스부터 스크립트, 플러그인으로 사용할 수 있는 다양한 기능, 미리 만들어 놓은 AI 등 수많은 기능들을 이용자들이 올려서 서로 사고 팔 수 있는 장터를 제공한다. 이 정책은 크게 성공하여 유니티 붐을 일으키는 데 일조했다. 사용자가 많을수록 에셋 스토어에 더 많은 상품들이 올라오고, 그것을 본 사람들은 유니티 사용에 긍정적으로 접근하게 되고, 신규 유입된 사람들이 다시 스토어에 유니티 기능을 만들어 올리는 등 선순환 과정이 형성되어 있다. 그리고 유니티에서 운영하는 인디, 초보자들을 지원하는 프로그램 등 관련된 다양한 행사가 진행된다는 점도 강점이다. 엔진 자체의 확장성과 맞물려 게임 이외에 방송, 애니메이션, 툴 등 3D 게임 엔진으로 할 수 있는 각종 에셋들이 존재하며, 찾아보면 이런 것도 있나 싶을 정도로 방대한 생태계를 자랑한다.

웹사이트

유니티를 다른 엔진들에 비해 우월한 지위에 올려 준 가장 큰 요소이다. 디자인, 모델링부터 유니티에 기능을 추가하는 플러그인에 해당하는 에셋까지 누구나 무료로 배포하거나, 유료로 판매할 수 있는 에셋용 앱스토어이다. 코딩에 익숙하지 않은 디자이너들이나 리소스 제작이 힘든 개발자들이 이 에셋 스토어에서 구매하거나 무료로 다운받은 에셋을 사용하여 프로젝트를 수월하게 진행할 수 있도록 도와준다.
항목 에셋
GUI NGUI, Scaleform[14], Noesis GUI[15], ...
2D 2D Toolkit, ...
Shader Substance, Shader Forge, ...
Script Playmaker, uScript, ...
AI Simple Path, ...
Tween iTween, LeanTween, ...
Modeling UModeler, Simplygon, GameDraw, ProBuilder 2, ...
에셋 스토어 폴더에 파일이 너무 많으면 로드가 매우 느려질 수도 있으며, 빈 회색 화면만 보인다면 edit > project setting > player에서 use Direct3D 11을 체크 해제하면 해결될 수 있다.

3.1.5. 넓은 사용자 층과 풍부한 관련 자료

개발 초보자나 비 프로그래머에서부터 고급 개발자까지 사용자층이 다양하고 그 수가 많다. 특히 입문 장벽이 낮기 때문에 초보자 인구가 많은데, 이 때문에 인터넷을 검색해보면 관련 자료가 많이 나온다.

마이너하거나 사용자층이 한정될수록 인터넷 상에 자료들이 적고 제작사에서 제공하는 도움말이나 공식포럼이 고작인 경우가 많은데, 이는 사용자 수 자체가 적은 것도 있고, 사용자들이 이미 대부분 고여버려서 어지간한 상황에서 만나는 장애물들은 알아서 이미 해결가능하기 때문인 경우도 있다. 반면 유니티의 경우엔 정말 생초보들을 위한 그림책 수준의 강의부터 오만 잡다한 에러의 해결법 및 흔히 마주치는 실수, 사람들이 즐겨 사용하는 베스트 프랙티스까지 매우 많은 정보가 인터넷에 돌아다니고 있으며, 이것들이 엔진을 배우는 데 큰 도움이 된다. 그 형태도 블로그, 유튜브 강좌나 튜토리얼, 인터넷 강의, 소스 공유 사이트의 공개된 실습 코드등 매우 다양하기 때문에 동일한 기술을 배우는 데도 자기가 알아듣기 쉽고 따라하기 편한 매체를 고를 수 있다.

언리얼 엔진 공식 도큐먼트의 질이 더 좋다는 평이 많다. 그러나 인터넷에서 찾을 수 있는 수많은 실제 예제들이 이러한 불리함을 보충해 주고 있어, 특히 초보 개발자들에게 많은 도움이 되고 있다. 다만, 2020년대부터는 언리얼 엔진도 초보자 인구가 급격하게 늘어나면서 엇비슷해지고 있다.

3.1.6. 저렴한 라이센스 비용

2017 버전 이후 영구 라이센스는 없어졌으나 개인 라이센스는 여전히 무료로 유지하고 있으며, 연매출 20만불 이하일 경우 무료이며 어떠한 비용도 발생하지 않는다. 매출이 20만 달러 이하일 경우는 무료 라이센스를 사용할 수 있다. 1인 개발자의 경우, 여기에서 의미하는 20만 달러는 순수하게 유니티 엔진을 사용하여 번 돈을 의미한다. 예를 들어 유니티와 전혀 관계 없는, 연봉 10만 달러 이상의 금융 회사에 다니는 회사인이 있다고 가정해 보자. 그 회사인이 취미로 유니티를 이용하여 개인적으로 게임을 개발할 경우, 그 게임이 연 매출 20만 달러 이하라면 여전히 유니티를 무료로 사용하여 게임을 만들 수 있는 것이다. 이러한 값싼 라이센스 비용은 각종 엔진들이 무료화하는 데 큰 영향을 끼쳤으며, 게임이 출시되더라도 별도의 라이센스 비용을 청구하지 않는다. 이는 개발의 민주화라는 모토와 맞물려 게임개발의 대중화 및 인디/소규모 개발팀이 많이 생겨나는 계기를 만들어냈다.

이러한 장점들 덕분에 벤처 기업이나 소규모 스타트업 창업을 하는 사람들 입장에서는 굉장히 유용하게 사용할 수 있으며, 2D 기능 역시 최신 기능들이 계속 추가되고 있기에 2D, 3D 모두 개발이 가능하다. 특히 소규모/인디 개발에만 한정되던 초기와는 다르게 저사양 게임이지만 비교적 개발자본이 어느 정도 들어가는 규모의 게임까지, 그리고 장르 역시 MMORPG에서 전략/퍼즐/액션 등 다양하게 개발되고 있다.

기본적으로 연수입/자본금 20만 달러 이하의 경우에는 완전 무료이지만, 그 이상부터는 개발자 머릿수(Seat)당 월간 라이센스 비용의 형태로 비용이 발생한다. 연수입/자본금 20만 달러 이하의 경우에는 월 40달러 (1년 납부시) 이며 그 이상의 경우 무제한 라이센스인 Unity Pro로서 월 150달러를 지불해야 한다. 여기에 만일 추가로 유료 플러그인을 구매할 경우 각 플러그인의 라이센스 정책에 따라 일시불 혹은 구독료가 추가로 발생할 수 있다.

유료 라이센스의 비용이 상당한 편이지만 여기서 생각해야 할 점은, 유료 라이센스는 연 20만 달러[16]가 넘는 수익규모를 가진 개발팀에 적용되는 것이며, 이 정도 규모의 개발팀이면 시스템이나 개발툴을 갖추는 데에도 적지 않은 비용이 필요하고 팀을 운영하기 위한 고정비가 요구된다는 점을 감안해야 한다. 연 2.7억원이 넘는 매출을 나오면서 개발자 1인당 월 40달러 추가 지출을 못하는데, 필요한 개발자 seat 수가 대단히 많으며, 소스 코드 레벨 커스터마이징이 필요한 블록버스터 인디 팀은 사실상 없다.

경쟁 프로그램 중 하나인 언리얼 엔진은 기본 고정 라이센스 비용을 완전 무료화했고 매출에 대한 비율 로열티만 지불하는 정책으로 바뀌었다. 언리얼 엔진 5 발표 이후 한 프로젝트당 $1,000,000 이상의 총수익[17]을 벌지 않았다면 로열티를 지불하지 않는, 사실상의 전면 무료 선언을 했기 때문에 상대적으로 라이센스 매출액 상한이 낮은 유니티가 더 라이센스 비용을 지불하게 되는 등의 엎치락뒤치락하는 부분이 생겼다. 유니티는 매출과 자본액에 맞춰 고정 지출이 나가는 라이센스라는 단점을 가지고 있다. 만약에 언리얼 엔진으로 로열티 지불 기준을 넘은 그 이상의 천문학적 수준으로 수익을 벌었을 경우에는 퍼센트로 지불해야하는 언리얼보다 유니티 엔진이 경제적이라고 생각할 수 있으나 그런 수익을 벌게 된다면 라이센스 옵션을 로열티를 지불하지 않는 맞춤형 라이센스로 재계약[18]해서 로열티 지불을 전혀 하지 않기 때문에 결국 언리얼 엔진이 더 경제적이게 된다.

특히 공공기관에서 비상업적용도의 프로젝트 개발에 사용할 경우 유니티는 시트 비용이 필요하지만, 언리얼은 이런 경우에는 시트 비용도 무료다.

3.2. 단점

3.2.1. 낮은 버전 지원으로 인한 호환성 문제

유니티의 뜻 그대로 가져온 것들을 잘 통합해야 할 것인데, 잘 가져오지도 못하고 통합도 못하고 있다는 것이 사실 가장 큰 문제이다. C#의 경우 9.0조차도 불완전하게 지원하며, 닷넷 프레임워크도 4.x버전이며, AI를 외치는 파이썬도 3.10.9로 10버전대의 마지막 버전도 아니다. 모두 3년 이상 뒤쳐진 상태다. 이게 언뜻 보기에는 별 문제가 없어 보이지만, 최신 기능을 반드시 써야하는 경우(온디바이스 AI라던가) 엄청난 문제가 발생한다. 어떻게든 1가지 호환성 문제를 해결하면 다른 호환성 문제는 해결하기 어려운 상황이 계속해서 발생한다. 이런 문제가 1+1=3의 수준으로 증가한다. 그래서 유명한 다카하시 케이지로 등의 예시를 봐도 1번에 1개의 모델만을 돌리는 걸 알 수 있다. 거기에 추가로 버전별 호환성 문제가 또다시 중복된다. 다카하시 케이지로의 경우도 1개의 모델만을 돌려도 유니티 버전에 따라 실행되고 안되고가 크게 영향을 받는다는 걸 알 수 있다. 당연히 여러개의 모델을 돌리면 문제는 더욱 심각해진다. 물론 여러 처리단계가 필요한 경우도 마찬가지다.

참고로 위의 C#, 닷넷 프레임워크, 파이썬의 호환성 문제는 큰 줄기로써 대표적인 예시에 불과하다. 애플(IOS->AR관련), 구글(안드->AR관련), 스팀과 메타(VR등), ONNX 등도 원래 구현된 것들을 제대로 지원하지 않거나(버전이 낮은 것을 포함) 지원하더라도 뭘 지원하는지 제대로 표시하지 않거나 성능 상 문제가 있기도 하다. 또한 본인들 스스로가 새롭게 지원하는 기능이 기존에 있던 기능은 빼놓고 구현하는 등의 문제가 있다. 예를들어 새로운 입력시스템은 키 시뮬레이션을 지원하지 않는다. 심지어 마소의 dll파일을 불러와도 먹히지 않는다. 물론 구 입력 시스템은 키 시뮬레이션은 물론이고 마소의 dll파일도 잘 먹힌다.

이상하게 아무도 이 문제를 언급하지 않는 건 C++프로그래밍이나 클라우드, 처리의 분산을 통해서 이 문제를 우회하고 있기 때문일 것이다. 그러나 C++로 프로그래밍할 것이면 굳이 추가로 C#을 쓰는 유니티를 쓸 이유가 없다. 그리고 클라우드 서비스는 추가적인 요금이 발생한다. 싱글 패키지 게임은 다른 컴퓨터로 처리해서 넘기기가 불가능하다. 물론 여전히 legacy로 사용할 수도 있을 것이다.

또한 이 문제는 유니티 외부의 프로그램을 사용하지 않고 유니티 내부에서만 모든 것을 처리한다면(고전적인 게임 개발), 발생하지 않는다. 그러나 일단 그런 환경에 포함된다면 유니티 사용을 포기해야 할 정도로 중대한 문제이다.

아주 직접적으로 말해보자. 인디바이스로 복합 모델을 사용하는 AI를 포함시키고 싶다? 유니티를 쓰지 마라. 일단 C#쪽보다 C++쪽이 자료가 훨씬 많다. 물론 파이썬 쪽은 더더욱 많다. 그러나 유니티는 파이썬 지원 버전이 낮다. 추가적으로 파이썬 버전에 따른 각종 파이썬 API들의 호환성도 해결해야한다. 그러니 그냥 쓰지 마라. 어차피 C# 지원 버전도 낮다. 닷넷 프레임워크 쪽에서는 마이크로소프트가 AI관련 프레임워크를 여러 차례를 만들다 포기하다하길 반복했다. 앞으로도 그럴 것 같다. 자료도 별로 없다. 그리고 어차피 닷넷 프레임워크도 4.x밖에 지원하지 않는다. 그러니 포기해라. 그냥 C++을 쓰는 게 성능 면에서도 물론이고 훨씬 낫다.

이런 수년 동안 쌓인 문제가 빠르게 해결될 것 같지도 않고, 그냥 애당초 해결할 의지가 있어 보이지도 않는다.
유니티는 AI에 대해 비전을 제시하면서 무한한 열린 세계로의 연결이 아니라 결국 자신들의 새로운 구독제를 제시하는 것으로 보인다. 갈라파고스화하는 것이다. 열린 AI의 세계를 포기하거나 굳이 또다시 C++프로그래밍을 추가하거나 유니티나 클라우드에 돈을 얼마든지 지불할 의사가 있다면 유니티를 계속 써도 좋을 것이다.

3.2.2. 제한적인 멀티스레드 기능

유니티 API가 메인 스레드 외에서는 호출이 안전하지 않기 때문에[19] 제한적으로만 멀티 스레드를 적용할 수 있으며 결국 이를 통해서 높은 성능 향상을 꾀할 수는 없다. 유니티 API가 없는 순수한 연산 집약적 동작을 병렬 처리하는 것인데, 이는 전체 동작에 대한 완전 병렬화가 아니다. 또한 연산 관련 코드에서 API를 통하지 않는 경우는 많지 않으면서, 대부분의 연산 능력을 API에서 요구하기 때문. 즉, 병렬화가 되는 부분이 극히 일부이기 때문에 높은 이득을 취할 수는 없다. 암달의 법칙 참고.

설령 어찌해서 구현했다 해도 노력 대비 얻는 성능 향상이 크지 않아서 이를 동적 로딩( 프리로드)에 응용하는 경우도 볼 수 있는데, 마찬가지로 유니티 API를 멀티스레드에서 안전하게 사용할 수 없으니 완벽한 동적 로딩을 구현하기는 힘들고 성능 향상도 기대에 미치지는 못한다. 즉, 고도의 편법을 완벽하게 익혀서 문제가 될 부분을 최소화하여 적용하지 않는 이상, 성능 이슈가 될 가능성이 높은 부분을 병렬화하지 못해 0번 코어만 죽어라 갈구는 경우가 될 가능성이 높다는 것이다.

실제로 유니티 엔진 4로 개발된 로켓 발사 시뮬레이션 게임인 Kerbal Space Program은 시뮬레이션 특성상 물리연산을 엄청 빡세게 하는데 이 물리연산 스레드를 코어 하나가 전부 감당해야 하기 때문에 어디가서 성능 좀 된다 하는 CPU도 부품이 많아지면 프레임을 제대로 못뽑는 상황이 무조건 발생한다. 이때문에 개발자가 유니티 엔진 5로 엔진을 갈아타는(!) 작업을 완료해 업데이트를 했지만, 그나마도 우주선 하나당 코어 하나씩 분담시키는 수준이 한계라고 밝혔다. 멀티스레딩이 안되어서 생기는 문제의 아주 대표적인 예. 물론, 이 문제는 KSP 못지 않게 연산량이 드럽게 많은 시티즈: 스카이라인도 마찬가지인데[20], 이 게임은 아예 유니티 본사 측에서 기술 지원을 해줬다(...). 그나마도 8스레드까지 인식하지만 실질적인 스레드 분담은 4스레드까지. 그래서 짝퉁 멀티코어 지원이라고 까이고 있다.

다수의 저성능 코어를 빅 리틀 솔루션까지 적용해가며 끌어모은 모바일 환경은 물론, 각 코어당 성능이 높은 편인 PC에서까지 영 좋지 않은 자원 활용도를 보일 수밖에 없다. 따라서 일정 수준 이상의 규모가 되는 게임을 개발하기에는 아쉬움이 크다.

다행히 2018.1 버전부터 C# 잡 시스템(JobSystem)[21]과 ECS[22]이라는 방법으로 멀티스레드를 이용한 병렬 처리를 지원한다. 하지만, 아직 문제가 많고 불안정해서 많은 개발자들이 지켜보고 있는 상황이다.

시티즈: 스카이라인 2이 유니티 엔진을 그대로 사용하다가 증가한 게임의 규모에 비해 심각한 최적화 문제가 발생해 왜 언리얼엔진을 사용하지 않았냐는 질문이 나오고 평가를 하락시키는 상황까지 왔다. 팰월드는 개발도중에 유니티엔진에서 언리얼엔진으로 바꾸는 선택을 했고 이는 매출과 평가를 높이는데 크게 기여하였다.

3.2.3. GC 스파이크 문제

유니티 엔진이 스크립팅용 언어로 C#을 사용하는 만큼 실제 실행과정에서는 .NET 런타임의 가비지 컬렉터가 메모리 관리를 담당하고 있으며 유니티 측에서는 이에 대해서 가상머신의 가비지 컬렉터가 담당하는 관리 영역과 가비지 컬렉터가 담당하지 않는 비관리 영역을 구분하고 있다.

.NET 런타임은 추적 기반 가비지 컬렉터를 사용하므로 프로그램 실행 중에 현재 할당되어 있는 모든 메모리를 한꺼번 조사하여 접근 불가능한 객체의 경우 삭제한다. 다만 이 과정에서 프로그램이 일시 정지가 되므로 실시간으로 실행하는 프로그램이 뚝뚝 끊긴다는 문제가 있고 관리되는 메모리 영역이 많아질수록 조사 시간이 걸려 GC Spike 등의 성능 문제가 자주 발생하며 이와 관련된 대표적인 게임이 Escape from Tarkov다.

'Use incremental GC' 옵션으로 GC Spike를 완화 할 수 있는데, 이는 GC가 한 프레임이아닌 여러 프레임에 걸쳐 작업 되게 만드는 옵션이기에 결국에는 프레임레이트를 희생해 스파이크를 낮추는 효과로 나타난다. 따라서 결국 애초부터 GC 동작을 예측하고 프로그래밍하는것이 중요하다.

사실 유니티는 일단은 가비지 컬렉션 관련 기능을 수동으로 제어하거나 심지어는 C/C++로 이루어진 코어 부분의 메모리 영역에 접근하는 방법을 만들어 둬 이를 작정하고 이용해 최적화 할경우 GC Spike등의 문제를 최소화 할수 있다. 문제는 유니티 엔진을 쓰는 회사들 규모가 상대적으로 작은 편이라 그렇게 까지 최적화를 할 필요성을 못느끼는 개발자들이 많기 때문에 단순 GC Spike 뿐만이 아니라 유니티에서도 메모리 누수가 빈번히 발생하는 게임들을 볼수있다.[23] 핵심은 유니티가 GC 에 의존한다기 보다는 제대로 메모리를 관리하지 않고 GC에게 일임해버리는 개발자들이 문제인 셈.

3.2.4. 라이센스 문제

위의 장점 항목에서처럼 인디~저매출 기업에게 매우 유리한 라이센스 정책으로 엔진에게 큰 홍보효과를 얻는 반면, Unity 본사와 달리 Unity Korea에서는 대학에 과금을 시도하려는 조짐이 보이고 있어 게임학과에서 큰 반발을 불러오고 있다. 美 게임 엔진 '유니티', 대학에 사용료 받나... 학계 공동대응 예고

또한, 점점 유료 라이센스의 가격이 비싸지고 있다. 엔진의 발전이 더딘데 가격만 오르고 있어서, 해당 엔진 사용자 입장에서는 불만이 가득한 편. 결국 그 동안 쌓이던 불만이 다운로드 횟수에 따른 종량제 논란을 기점으로 한꺼번에 폭발했다.

사실, 이러한 갑작스런 요금제 변경발표에는 지난 20여년간의 누적된 적자, 이로인한 투자자들의 압박이 요금제 개편압박으로 작용했다고 볼 수 있다. 하지만, CEO 존 리치티엘로가 사태에 책임을 지고 사임하고, 무료사용 매출 기준을 20만달러로 완화하여 인디개발자들에게 이전보다 더 나은 혜택을 주고, 런타임요금제 또한 매출의 2.5%와 설치당 비용중 적은쪽을 선택하여 지불할 수 있으며, 설치당비용을 선택할 경우, 설치회수는 이용자가 직접 집계하여 보고할수 있도록하였다.

2024년 10월 런타임 요금제를 폐지하고, 프로와 엔터프라이즈 라이센스 이용료를 올리기로 결정했다. #

3.2.5. 소스 코드 비공개

유니티는 기본적으로 월간 비용을 지속 지불하더라도 전체 소스코드는 여전히 비공개며, 전체 소스코드가 포함된 라이선스를 원할 경우 그 비용은 언리얼 엔진 커스텀 라이선스 비용과 맞먹게 된다. 유니티 측은 프로 라이선스도 소스 코드에 엑서스 할 수 있는 것 마냥 선전하고 있지만 실상은 구독과 별개로 소스코드를 구매해야 한다고 한다. 여기에 개발기간이 길어진다던가, 개발팀 인원이 증가된다던가, 타 스튜디오 등의 지원을 받아서 유니티의 시트당 사용자수가 늘어날 경우에 따라서 개발 비용이 지나치게 높아질 수 있으므로 상황에 따라서 언리얼 엔진의 사용을 고려해야 할 수도 있다. 언리얼 엔진은 4.0 이후 버전부터는 소스 코드를 모든 사용자에게 무료로 공개하는 정책을 고수하고 있다.

3.2.6. 보안성 문제

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

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

그래서 해당 부분을 암호화하기 위하여 애셋 스토어에 CodeGuard나 Anti-Cheat-Toolkit 등의 서드파티 툴이 기본적인 코드 난독화, 메모리 해킹감지 등을 제공했다. 물론 완벽하게 막아줄 수는 없다.

최신 버전에 들어서면서 Mono 대신 .Net framework 4 이상의 버전으로 마이그레이션함과 동시에 아예 C++로 변환 후 네이티브 코드를 생성하는 IL2CPP / Burst Compiler를 도입하여 이 약점에 대응하는 수단이 등장했다. 네이티브 코드의 경우 C#이 해독되는 가장 큰 약점인 중간 바이트코드가 없이 C/C++과 동일하게 어셈블리 코드를 생성하므로 해당 문제점이 나타나지 않는다. 초기에는 IL2CPP의 컴파일 시간이나 버그에 대한 불만이 있었으나 현재는 거의 안정화된 상태.

3.2.7. 버전 간 호환성 문제

유니티는 버전 간의 완벽한 호환성이나 버그 무결성을 추구하는 것보다는 신기술과 트렌드를 빨리 도입하고 시장 강화적인 마케팅에 더 힘을 쏟는 정책을 펼치고 있다.

때문에 FEEDBACK과 ISSUE TRACK에 올라온 치명적 버그가 수십~수백개에 달하며 심지어 그 중 몇몇 개는 엔진 자체를 사용 못하게 만드는 버그임에도 불구하고 대응 속도가 아직도 너무 느리다. 예를 들면 다음 링크 모음과 같은 버그들이 있다. 버전관리가 안돼서 이전에 잡힌 버그도 계속 부활한다. 이쯤 되면 회사가 버그를 잡아서 해결하는 것이 아니라 제작사가 알려진 버그를 피해서 해결하라는 이야기.
#1, #2, #3, #4, #5, #6, #7, #8, #9, #10, #11

위 포럼의 이슈들은 2019년 기준이나, 2024년에도 별반 다르지 않다.

한편, 상기 언급된 바와 같이 유니티 엔진은 대규모 개발로 사용되기엔 부적합하여 인디 환경 위주로 많이 쓰이는 편인데, 인디 개발 환경 특성상 최적화를 잘하지 못하는 경우가 흔하기 때문에 두가지 단점이 시너지를 일으켜서 유니티를 사용한 게임들은 버그 덩어리라는 오명을 얻는 일도 흔하다. 유니티 엔진을 사용한 고사양 3D 게임 치고 심각한 버그 문제를 겪지 않은 게임이 손에 꼽을 정도다.

그런 반면 대외적 홍보, 강사 초빙, 세미나 등에 초점을 맞춰 마케팅에 집중하며, VFX 업체나 고퀄리티 3D 스캔 업체를 인수합병 하는 등, 게임개발도구로서의 장인기업보다는 종합 시각화/가상현실 솔루션 기업으로 나아가려는 모습을 보이고 있다.

4. 다른 개발도구와의 비교

4.1. 유니티 vs 언리얼 엔진

파일:상세 내용 아이콘.svg   자세한 내용은 언리얼 엔진 vs 유니티 엔진 문서
번 문단을
부분을
참고하십시오.

4.2. 유니티 vs Godot Engine

대형 게임은 언리얼 엔진으로 개발한다면 소규모 게임이나 인디 게임을 개발 한다면 유니티와 고도 엔진이 좋은 선택지가 될 수 있다는점과 C#을 스크립트용 언어로 사용한다는 점에서 유사한 점을 공유한다.

큰 차이점은 고도 엔진은 오픈소스에 사용권이 완전 무료이고 유니티 엔진보다 몇배는 가볍다는 장점이 있다. 따라서 자신이 원하고 실력만 된다면 고도 엔진을 유니티보다 훨씬 더 자유자제로 커스텀 할 수 있다. 하지만 유니티가 고도보다 많은 정보량, 에셋이 있고 에셋을 제외해도 유니티가 가진 여러 개발 생태계에서 숙련된 많은 인력이 있어 비교적 신생 엔진인 고도에게는 부족한 점이 많다.

하지만 둘다 C#을 사용하기에 여러 유니티의 스크립트 에셋을 고도로 변환하는 것이 가능하기도 하고 언리얼보다는 고도의 인력 연결고리가 더 가까운편이라 프로그래머 한정으로는 고도을 선택 하는것이 나쁘지 않는 선택이 될 수 있다.

유니티 엔진 요금제 개편 논란이 떠오를 당시 대체재로 여러 게임 개발사에서 고도 엔진 사용을 검토한다는 소식이 많았다. 하지만, 유니티가 최근에 엔진 요금제 개편을 철회한 데다, 고도 엔진 개발진이 정치적 올바름 지지선언 논란을 자초하면서 상당수의 고도 엔진 이용자들이 다른 엔진으로 갈아타거나 유니티로 복귀하고 있는 상황이다.

4.3. 유니티 vs 크라이엔진

크라이 엔진은 모바일에서의 사용이 전무하며, 2018년 이후 시점에서는 PC/콘솔의 대형 프로젝트에서의 입지도 거의 잃은 상황이라 사실상 비교하기 힘들다.

4.4. 유니티 vs 플래시 몰힐(Molehill)

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

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

4.5. 유니티 vs Cocos2d-x

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

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

2019년 기준으로 2D쪽으로도 유니티가 압도적으로 생산성이 좋다.

Cocos는 CocosCreator 쪽으로 집중하느라 Cocos2D-X는 업데이트 주기가 점점 길어지고 있다. 또한, 업데이트되면 기능이 좋아지거나 추가되거나 버그가 없어지거나 해야 되는데, 정반대로 CocosStudio를 포함하여 있던 기능도 제거되고, 지원 플랫폼도 줄어들고 버그도 늘어나고 있는 중이다. 게임 엔진중에서 거의 유일하게 공식적으로 닌텐도 스위치를 지원하지 않는다(...).

4.6. 유니티 vs 쇼크웨이브

유니티 초창기 시절에 비교되었으며 이때는 웹 브라우저상에서 3D를 구현하는 가장 편리하고 성능 좋은 방법 중 하나로 어도비 쇼크웨이브가 자리잡고 있었고, 유니티 웹 플레이어는 후발주자인 상황이었다. 하지만 유니티는 게임 엔진이고 쇼크웨이브는 그저 웹 브라우저 등에 사용되는 멀티미디어 플레이어일 뿐이므로 둘은 적절한 비교 대상이 아니다.

5. 학습

5.1. Unity Learn

유니티에서 만든 공식 튜토리얼이다. 동영상 강의도 있지만 대부분이 글과 사진으로 되어있는데, 취향에 따라서는 이쪽이 유튜브나 동영상 강의보다 더 맞을 수도 있다. 학습 길잡이의 Unity Essentials Junior Programmer 순으로 들으면 된다.

5.2. Unity Documentation

유니티 공식 문서 이다. 한국어를 설정 할 수 있어 영어가 힘들면 한국어로 보면 된다.[27] 위의 Unity Learn 보다는 학습용으로 어려울 수 있지만, 어느정도 익숙해진 사용자들은 더 많은 공식 정보를 얻기에 굉장히 유용하다.[28] 각 기능마다의 소개 페이지가 하나씩 있으니 모르는 기능의 소개 페이지부터 읽으면 된다. 즉 Unity Learn는 직접 먹여주는것이라면 Unity Documentation는 큰 상차림에 가깝다.

5.3. 유튜브

5.4. 웹사이트

6. 논란

6.1. 요금제 개편 논란

파일:상세 내용 아이콘.svg   자세한 내용은 유니티 엔진 요금제 개편 논란 문서
번 문단을
부분을
참고하십시오.

7. 기타

7.1. 유니티 엔진 기반 게임들

파일:상세 내용 아이콘.svg   자세한 내용은 유니티(게임 엔진)/게임 목록 문서
번 문단을
부분을
참고하십시오.

7.2. SU:A(수아) 인물 데모

파일:20200610122043_2801.jpg

on-mind라는 스타트업에서 제작한 Digital human. Unity HDRP를 사용했으며, 딥페이크를 사용한 2D 기반이 아닌 실제 리얼타임 기반으로 캐릭터가 사용자와 소통 가능한걸 목표로 제작중이다. 디지털 휴먼이 유니티 코리아의 모델이 되었다는 기사에 여러 커뮤니티 -루리웹기사링크에서 뜨거운 관심을 받은 캐릭터이기도 하다. 현재수아 디지털 on-mind로 사명을 바꾸고 넵튠 자회사로 편입 최근 SK스퀘어에서 100억 규모로 투자가 진행되었다는 소식이 있다.

실제 인물을 3D 스캔 해서 제작하는 방식이 아닌 제로 베이스에서 제작된 캐릭터로 얼굴을 자세히보면 여러 아이돌의 느낌이 난다.

2020년 1월 첫 공개되었을 땐 머리카락은 움직이지 않지만, 3월에 공개되었을 때는 머리카락도 물리엔진이 적용되었다. 이후 웨비나 헤어 솔루션은 Deform dynamics의 솔루션을 사용했다고 밝혔으며, 실시간으로 사용자와 소통하는 모습을 보여줬다 유니티웨비나링크. 이후 AMD와 협업해 TressFX 헤어 솔루션을 변경한 것으로 보인다(무려 47만뷰다).

제작 비화를 밝힌 김형일[31]은 일반적인 극사실 모델링이 실재 인물을 바탕으로 3D 스캔해서 만들지만 SU:A는 Z브러쉬로 일일이 그려서 제작했는데, 어차피 3D 스캐닝도 수작업으로 후보정을 해야해서 걸리는 시간은 비슷했다고 한다. 오히려 이 때문에 개인적으로는 3D 스캐닝을 비효율적이라고 봤다. 오히려 만들기 어려웠던 건 머리카락이었다고 토로했다. #

가정에서 사용되는 수준의 PC에서도 동작 가능하다고 하며, 버전 3.0 기준으로 API도 일반적인 다이렉트X 11을 사용하였다. #

틱톡 계정
인스타그램 계정 사진합성을 하는 것으로 보인다.

7.3. 유니티짱

파일:상세 내용 아이콘.svg   자세한 내용은 유니티짱 문서
번 문단을
부분을
참고하십시오.


[1] 게임 엔진은 C++로 개발, API는 C#을 스크립팅 언어로 활용하여 작성한 형태를 띄고 있다. [2] 사실, .NET 기반 언어이면 모두 사용 가능하다. F#도 가능하다는 이야기. 추가로, Python을 사용할 수 있게 해주는 플러그인도 있다. [3] JavaScript를 기반으로 하는 유니티 엔진의 자체 스크립트였으나, 2017 버전부터 서서히 퇴출 수순을 밟더니 2018.2 버전부터 지원이 완전히 중단되었다. [4] 이전에는 Boo라고 하는 언어도 지원했고 지금도 쓸 수는 있으나 5.0 버전으로 넘어오면서부터 API 문서를 지원하지 않는다고 공지하였다. 사실상의 퇴출 수순. 사실 Boo는 Python과 굉장히 유사한 언어고 기존에는 JS와 함께 여타 언어를 쓰던 유저들을 잡을 목적으로 지원했지만 그래도 제법 쓰고 있는 JS에 비해 사용률이 매우 저조했기 때문에... 현재 이곳에서 볼 수 있는 사용 가능 스크립트에도 아예 빠져있다. [5] DX 9/10/11/12 [6] OpenGL ES 포함 [7] 출처 [8] 2004년 덴마크 코펜하겐에서 설립되었으며, 미국 샌프란시스코로 본사를 이전했다. [9] High Definition Render Pipeline 그외에 레이트레이싱 SSAO가 적용되었다. [10] 프로젝트당 약 3억 [11] 의무화의 경우 유니티 5.6 이하는 2021년까지 유예. [12] 이 경우는 ARM을 가상화 하는 안드로이드 가상 에뮬레이터에서만 실행이 가능한데, 크롬북이나 태블릿중 인텔 계열 CPU를 쓰면서 안드로이드 호환으로 대응하는 경우도 마찬가지로 미지원 문제가 생겼다. [13] 언리얼 엔진도 이 영향을 많이 받았는데 언리얼 엔진 3까지는 GUI가 다소 복잡하여 처음 접하는 사람들은 적응에 시간이 좀 걸리는 편이었으나, UDK 공개이후 매달 공개되는 UDK의 버전업과 함께 전반적인 인터페이스가 점차 직관적인 GUI로 변경되면서 언리얼 엔진 3 최종 버전을 언리얼 엔진 3 초기 버전과 비교할 경우 인터페이스 편의성이 크게 다르다. 언리얼 엔진 4의 경우에는 에디터의 외형부터 완전히 직관적으로 변경되었으며, 버전업되면서 모든 기능들이 드래그 앤 드롭과 클릭 몇번으로 작동될 수 있게 되었고, 새로 추가되는 기능들도 모두 그렇게 개발되고 있다. [14] Flash. 다만 유니티 스케일폼은 업데이트나 기술지원이 썩 활발한 편은 아니기에 말 그대로 있다 수준에 그치는 정도인데다 정작 이 항목의 에셋 스토어에는 있지도 않은데 이유는 더이상 기술지원을 안하고 아예 내다버려서이다. 실제로도 해당 플러그인은 게임계 전반으로 봐도 기존 전성기에 비해서는 쇠퇴하고 있다. [15] XAML. [16] 한화 약 2.6~2.7억 [17] The first $1,000,000 in lifetime gross revenue for each Product [18] 흔한 오해 중 하나가, 언리얼 엔진의 사용요금이 기본 무료화에 수익이 일정 이상 발생하면 무조건 퍼센트로 로열티 지불을 하는 것으로 알려진 경우가 많은데 사실은 그렇지 않으며, 프로젝트당 라이센스 비용을 비싸게 지불하는 대신에 수익이 얼마가 나도 로열티를 전혀 지불하지 않는 맞춤형 라이센스가 계속 존재하고 있었다. [19] Thread-Unsafe는 여러 스레드가 동일한 레지스터에 동시 접근해서 잘못된 결과를 내는 것을 말한다. [20] i9를 넣어도 3배속 플레이가 안 된다.(!!!) [21] 최대 10개의 스레드가 작동한다. 발표에서 선보인 예제는 100만개 이상의 군세를 렉 없이 업데이트하고 렌더링하는 퍼포먼스를 보여주었다. [22] 객체 지향이 아닌 데이터 지향으로 동작을 관여하는 스크립트가 객체마다 생성되었던 것을 1개로 줄여 인스턴싱 효과를 얻을 수 있는 시스템이다. [23] GC가 동작하는 방법때문이기도 하다. C#의 GC는 접근 불가능한 객체에 대해 검사해 사용 권한을 회수하는 방식이라 개발자가 객체관리를 제대로 안하면 GC도 객체가 실제로는 쓰지않는 객체가 늘어나도 사용할수 있다고 보고 회수하지 않는다. [24] 물론 완벽하게 일치하지는 않는다. 컴파일을 진행하면서 전체적인 흐름을 깨지 않는 수준에서 최적화를 위해, 코드의 순서는 바뀌게 되기 때문. 그래도 스크립트의 전체적인 흐름은 파악하고도 남는다. 완전히 해커의 손에 떨어지는 셈. [25] 유니티의 경우 다이나믹 로더를 이용하기 때문에 이것이 가능하다. 물론, 스크립트 복호화 모듈이 해커에 의해 완전통제되면 답이 없다. [26] 모바일 앱인 안드로이드 앱의 경우 Java 패키징 형태로 제작되므로 해체에 대단히 느슨하다. [27] 몇몇 문서는 한국어로 설정해도 영어로 뜨는 경우도 많다. [28] 하지만 공식 문서인데도 없는 정보도 많다. [29] 이마저도 비판하는 사람들을 맥락을 모르는 것들(Out of full context)이라 비하하고 성의없는 3줄로만 사과하다가 사람들이 스크랩하지 못하게 스크린샷으로 올린 사과문이라 자신이 비판할 때는 잘난 척하더니 남한테 비판받는 것은 싫다는 내로남불 티를 내서 게임 팬덤과 개발자 업계에서 단단히 찍혔다. [30] 유니티 엔진에 대한 의존도가 높아진 게임 시장에서 엔진이 공중분해되는 것은 어도비 플래시의 서비스가 종료되는 것과 비슷하나 더 큰 파장을 불러일으킬 것이기 때문이다. [31] 현재 온마인드 대표