일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 게임개발
- 아트토이
- 버그리포트 #유니티
- TypeScript
- 머신러닝 #의사결정트리 #GINI
- egret
- 메이커스페이스
- 카드캡터사쿠라
- HTML5
- 한글오류
- 한국과학창의재단
- 디지털대장간
- 게임잼
- 진공성형기
- 카드캡터체리
- 진공성형
- 게임개요서 #공모전 #게임기획
- 그래픽
- N15
- 한성대학교
- 메이커
- 3D모델링
- 레진아트
- 상상랩
- 소켓
- 한글깨짐
- vacuum
- 시민창작단
- 회고
- 디버깅
- Today
- Total
당신에게 꽃을
[HTML5] 게임 엔진 종류 소개 본문
최초 글 작성 시기가 오래되어서 더이상 업데이트 되지 않는 엔진이 있어
2023년 12월 27일자로 수정된 내용이 있습니다 :) 참고바랍니다.
이 글에서는 HTML5 게임 클라이언트 개발에 주로 쓰이는 엔진/프레임워크들을 소개합니다.
0. 서론
2020년 12월 31일, 어도비 플래시가 공식적으로 지원 종료되었습니다.
어도비는 2017년 하반기즈음에 플래시 지원 종료 의사를 밝혔는데요, 국내 시장에서는 이미 플래시 게임의 인기가 한 풀 꺾인 후였지만, 북미나 러시아 등 해외에서는 페이스북등의 플랫폼을 통해 여전히 수많은 플래시 게임들이 라이브 서비스 중이였습니다. 당시 라이브로 플래시 게임을 운영중이던 게임사들은 플래시->HTML5 포팅 작업을 시작합니다.
이식(移植) 또는 포팅(porting)은 컴퓨터 과학에서 실행 가능한 프로그램이 원래 설계된 바와 다른 컴퓨팅 환경(이를테면 CPU, 운영 체제, 서드 파티 라이브러리 등)에서 동작할 수 있도록 하는 과정을 가리킨다 - 위키피디아
또한 멀티플랫폼에 대한 수요가 높아지면서, 웹브라우저만 구동된다면 하드웨어 종류를 가리지 않고 플레이 가능한 HTML5 게임의 수요도 증가했습니다.
HTML5 게임 제작에 주로 선택된 프레임워크/엔진들에는 Cocos creator, PixiJS, Phaser, Unity tiny 등이 있었고, 각 개발사는 여러가지 기술 검토 후에 이들 중 하나의 엔진을 골라 포팅을 시작했습니다.
지금부터 각 프레임워크/엔진들의 특징과 장단점에 대해 간단히 써 보려 합니다. 여러분께서 각 엔진을 고르시는 대에 좀 더 도움이 되었으면 합니다.
1. Unity WebGL 빌드와 Unity Tiny(지원종료)
요약: 모바일 네이티브용으로 개발된 게임을 WebGL 포팅하는 데에는 제약조건이 많다. 23년 현재 타이니는 개발이 중단 된 것으로 보인다.
Unity는 대략 5.X 버전부터 WebGL 빌드를 지원했어요. (공식문서 링크)
Technical limitations - Unity 매뉴얼
Web technology imposes restrictions on Unity web applications which are designed to run in web browsers. Make sure you are aware of the following technical limitations before you build your application for the Web platform.
docs.unity3d.com
Unity는 emscripten 컴파일러 툴체인을 사용하여 Unity 런타임 코드(C 및 C++로 작성 )를 WebAssembly로 교차 컴파일하는 방식을 통해 WebGL 빌드가 가능하다고 해요.
단, Unity WebGL 빌드에는 다음과 같은 제약조건이 있어요.
주로 플랫폼의 한계 때문에 Unity의 일부 기능은 WebGL 빌드에 사용할 수 없습니다. 구체적으로 설명하면 다음과 같습니다.
- 스레드는 지원되지 않습니다. JavaScript에서 스레딩이 지원되지 않기 때문입니다. Unity에서 성능을 높이기 위해 스레드를 내부적으로 사용하는 경우와 스크립트 코드 및 관리 dll에서 스레드를 사용하는 경우 모두 스레딩이 지원되지 않습니다. 기본적으로 System.Threading 네임스페이스 안에 있는 것은 모두 지원되지 않습니다.
- WebGL 빌드는 Visual Studio에서 디버그할 수 없습니다.
- 보안 문제로 인해, 브라우저에서는 네트워킹을 위한 IP 소켓의 직접 액세스를 허용하지 않습니다.
- WebGL 그래픽스 API는 몇 가지 제한이 있는 OpenGL ES 2.0 및 3.0과 동일합니다.
- WebGL 빌드에서는 Web Audio API 기반 커스텀 백엔드를 오디오에 사용합니다. 기본 오디오 기능만 지원됩니다.
- WebGL은 AOT 플랫폼이므로 System.Reflection.Emit를 사용하여 코드를 동적으로 생성할 수 없습니다. 다른 모든 IL2CPP 플랫폼, iOS, 그리고 대부분의 콘솔도 마찬가지입니다.
사실 JS 환경이나 WebAssembly에서 스레드 비슷한 것을 아예 지원하지 않는 것은 아닙니다, 그러나 Unity의 WebGL빌드에서는 모종의 문제(?)로 아직까지는 완성형의 지원이 되지 않고 있는 듯 합니다. (WebGL 멀티쓰레딩에 관한 포럼 글)
또한 당연한 이야기이지만, Unity WebGL 빌드로 게임을 제작할 경우 몇가지 성능 최적화에 대해 신경 써 주는 것이 게임 플레이 환경에 이롭다고 하네요. 이 내용에 대해서는 유니티 공식 문서에 다음과 같이 친절히 설명되어 있어요.
WebGL 메모리 | WebGL에서 메모리를 관리하는 방법. |
WebGL: 브라우저 스크립팅과 상호 작용 | WebGL에서 브라우저 스크립팅에 사용되는 다양한 방법. |
WebGL 성능 고려 사항 | WebGL 성능 고려 사항. |
WebGL 빌드 디버깅 및 문제 해결 | WebGL 빌드 디버깅 및 문제 해결. |
WebGL의 커서 잠금 및 전체 화면 모드 | WebGL에서 커서 잠금 및 전체 화면 모드 지원. |
WebGL 입력 | WebGL에서 지원되는 입력 유형을 나열합니다. |
WebGL 네트워킹 | WebGL에서 네트워킹을 사용하는 방법. |
<Unity WebGL 빌드, 장점>
이론상으로는 기존 유니티 프로젝트를 그대로 WebGL 빌드 할 수 있어요. (Unity User Manual 2023.2의 빌드 메뉴얼)
실제로 많은 경량 게임들이 유니티로 제작되어 웹 환경에서 서비스되는것을 확인할 수 있습니다.
<Unity WebGL 빌드, 단점>
23년말 기준으로 HTML5 게임의 핵심은 '빠르고 가볍게 돌아가는 컨텐츠' 인 것 같아요. 웹브라우저 환경에서 실행되는 컨텐츠임을 전제하기 때문에 많은 유저가 버벅임이나, 느린 로딩 속도를 견디지 못하고 실행 도중에 이탈합니다.
Unity WebGL 빌드는 기존 유니티 프로젝트를 거의 그대로 사용할 수 있어 모바일용 빌드를 그대로 HTML5 포팅 할 수 있을 것 같아 편리하다는 생각이 들지만...
환경 차이가 있겠으나, 유니티 2D 프로젝트를 하나 생성해서 아무 작업 없이 WebGL 빌드를 뽑아보니 대략 2.4MB의 용량이 나옵니다. 다른 HTML5 엔진들은 깡통빌드 용량이 1MB 내외입니다. 속도가 핵심인 HTML5 게임에서 1MB 차이는 치명적일 수 있어요.
더불어 3D로 제작된 프로젝트의 경우 더더욱 최적화가 안 된 결과물이 등장합니다. 폴리곤 많고 매끄러운 그래픽의 게임을 Unity WebGL로 포팅하는 것은 플랫폼 서비스 특성상 힘들 것 같습니다. (다만, 플랫폼 특성상 힘들다는 것이지 기술적 불가능에 대한 이야기는 아닙니다 -> 빌드 사이즈를 줄이는 것에 대한 유니티 포럼 글 )
또한 공식 문서에 따르면 모바일 기기 호환성을 보장하지 않습니다. 일부 모바일 기기에서는 빌드가 작동하지 않을 가능성이 있습니다.
요약하자면 플랫폼에 맞춤화된 최적화를 진행하기가 힘듭니다.
따라서 보다 편리하게 유니티로 HTML 5 개발을 하기 위해서는 아래서 언급하는 Unity Tiny 런타임을 별도로 설치하는 것이 좋아요. 2023년 12월 현재는 업데이트가 중단 된 것으로 보여요.
<Unity Tiny, 장점>
유니티 패키지 매니저를 통해 설치 할 수 있는 Unity Tiny의 대표적인 장점으로는, Unity 엔진 자체가 가장 메이저한 게임 엔진이라는 점이에요. 현재 Unity Tiny는 실험적인 개발 단계이나, Unity에서 지속적으로 개발을 진행 중인 만큼 발전 가능성이 크다고 할 수 있을 것 같아요.
엔진 자체의 GUI 서포팅도 잘 되어서 입문자도 tiny 공식 유튜브를 시청하며 비교적 쉽게 사용 방법을 배울 수 있어요. GUI가 Unity 베이스이기 때문에 기존에 유니티로 게임 개발을 하시던 분들이 엔진 사용에 쉽게 적응할 수 있다는 것도 큰 장점 중 하나에요.
또한, Unity Tiny 모드를 사용하여 작업하면 별도의 로컬 서버를 구축할 필요 없이 게임을 웹브라우저로 실행하여 디버그 할 수 있다는 것도 장점 중 하나에요.
<Unity Tiny, 단점>
모바일/PC 네이티브 타겟으로 개발된 게임을 Unity tiny로 WebGL 포팅하는 것은 굉장히 공수가 많이 들어요. Unity tiny는 기존 유니티의 MonoBehaviours를 사용하지 않기 때문이에요. (tiny 2기준)
또한 Tiny는 현재 실험적인 개발 단계를 거치고 있어 관련 개발 자료가 PixiJS나 Phaser에 비해 많지 않아요.
결국 일반적인 방법으로는 Unity를 사용해 네이티브 게임&플래시 게임을 HTML5게임으로 손쉽게 포팅할 수는 없어요. 그러나 Unity를 사용해 처음부터 HTML5 게임을 개발하여 라이브 서비스 단계까지 가는 것은 가능해요!
2. PixiJS
요약: 빠르고 간단한 2D WebGL renderer PixiJS! 하지만 프레임워크는 아니다.
WebGL 3D 렌더러에 three.js가 있다면 2D에서는 PixiJS가 있다고 할 수 있죠.
"어라...엔진이라면서 왜 라이브러리랑 비유를 해요...?"
그것은 PixiJS는 다음 기능을 기본으로 제공하지 않기 때문입니다. (공식문서 발췌)
- 사용자 설정 관리
- 오디오 라이브러리
- 개체 스크립팅
- 모바일 앱 빌드
- UI 라이브러리
- 개발 환경과 편집기
Unity나 Game Maker studio등의 게임 엔진을 주로 접해보신 분들은 '게임 엔진'임에도 불구하고 위 기능들이 없는 것이 다소 생소할 수 있어요.
저도 이전까지 '엔진'에 대해 인식할때 UI 라이브러리가 포함되어있는 형태의 엔진들을 주로 떠올렸거든요. 그래서 개발 환경을 따로 구축한 뒤 라이브러리를 import해서 사용하는 PixiJS의 존재를 접했을 때 굉장히 새로웠습니다.
위와 같이 Pixi.js는 monolithic하기보다는 micro service적 면모를 많이 가지고 있어요. 전용 편집기가 없다는 점, 별도 task runner의 도움을 받는게 편리하다는 점 등등, 지금까지 보아왔던 '게임 엔진'들과는 사용의 방향성이 다르다고 생각이 듭니다. 깃허브 공식 레포지토리에서 자체적으로 다양한 플러그인을 제작해 배포하고 있고, 지원이 되는 서드파티도 많아서 범용성에는 문제가 없습니다.
<Pixi.js, 장점>
Pixi.js는 단일 라이브러리만 가지고는 게임을 만들기에는 다소 가벼울 수 있는 엔진이에요. 그러나 WebGL 2D 렌더링에 관련된 기능들만 들어있기 때문에 굉장히 빠르고 가벼워요. 또한 사용자가 원하는 대로 각종 라이브러리를 붙여 개발 환경을 구축할 수 있다는 점이 큰 장점이 되는 경우도 많아요.
Pixi.js는 게임만이 아닌 다양한 HTML5 웹페이지에 유연한 적용이 가능해요. 배포 방식 또한 일반 웹페이지를 배포하는 것과 동일합니다. 아래의 웹페이지들은 Pixi.js를 사용하여 만들어졌다고 해요. 들어가 보시면 정말 화려하다는 것을 느끼실 수 있으실 거에요.
- inicio
- https://art4globalgoals.com/en
The art of achieving #GlobalGoals
Check out Leon Löwentraut’s artistic interpretations of the Global Goals and help erase our planet’s 17 biggest issues.
art4globalgoals.com
<Pixi.js, 단점>
가볍다!는 것이 단점일 수 있는 엔진이에요. 일단 개발 환경을 엔진단에서 준비해주지 않으니, 개발자가 개발 초기에 따로 챙겨야 할 것들이 있습니다. 대표적으로 다음과 같은 것들이 있으면 좋아요.
- 웹 서버 - 필수
- UI 서드파티 - 주로 tilemap 플러그인, Spine 플러그인, Fairy GUI 등을 사용할 수 있어요.
- 오디오 라이브러리
- Task Runner - gulp.js, Grunt 등을 사용할 수 있어요.
결국 Pixi.js 단일 환경으로는 게임을 만들기가 어렵다는 점, 게임 엔진보다는 그래픽 렌더러로 주로 이용된다는 점이 단점으로 작용합니다.
3. Phaser
요약: 가장 접하기 무난하고 유명한 프레임워크
Phaser는 HTML5 게임 개발에 입문했을때 가장 무난하게 접할 수 있는 프레임워크에요. 공식 홈페이지의 가이드 문서 뿐만 아니라 한국어로 된 블로그 개발 자료도 많아서, 개발 도중 어려움이 닥쳤을 때 도움을 받기가 타엔진들에 비해 상대적으로 쉽기도 해요.
Phaser는 Phaser2와 Phaser3로 나뉘어요. Phaser2는 WebGL 렌더링을 위해 Pixi.js를 사용하고 있어요. 그러나 Phaser3에서는 자체 개발한 WebGL 렌더러를 사용하고 있다고 합니다. 이외에도 디테일에서 많은 차이가 있어요. 아쉽지만 Phaser2로 만들어진 게임의 엔진을 Phaser3로 손쉽게 업그레이드 하는 것은 불가능해요.
이 파트에서는 Phaser3 위주로 설명을 드릴 건데요, Phaser3도 ‘음...? 게임엔진...?’스러운 부분이 있어요. 다음 부분들은 Phaser3를 이용하기 위해서 사용자가 직접 선택하고 구축해야 하는 것들이에요.
- 로컬 웹 서버
- IDE 개발 환경
- UI 라이브러리 또는 플러그인 - 엔진 자체에 붙어있지는 않습니다.
- Task Runner - Grunt를 권장해요
위 준비 과정을 얼핏 보면 Pixi.js와 비슷하다는 느낌을 받기도 해요. 그러나 Phaser는 게임 프레임워크로서 게임 제작 자체에 최적화가 되어 있어요. 다음과 같은 기능을 지원하고 제어해요.
- 애니메이션 / IO / 장면 / 사운드 관리자
- Time step
- 게임 루프와 생명주기
<Phaser3, 장점>
Phaser의 최대 장점은 ‘게임 개발’자체에 치중된 UX를 제공하고, 이에 따라 수많은 참고자료를 얻을 수 있도록 생태계가 형성되어 있다는 점이에요. 제가 리서치를 하면서 본 HTML5 게임 엔진/렌더러 중 Phaser의 개발자료와 정보가 압도적으로 많았어요.
- 다양한 개발자료, 튜토리얼, 커뮤니티
- Pixi.js 보다는 HTML5 게임 제작에 최적화된 UX를 제공
<Phaser3, 단점>
Phaser의 단점은 Pixi.js의 단점을 축소해 놓은 느낌이에요. 초기 구축 단계에서 사용자가 신경 쓸 부분이 일부 있답니다.
- 로컬 웹서버 미지원
- UI Editor는 별도
- 3D 미지원
- 자체적으로 모바일 앱 빌드를 지원하지는 않습니다.
그러나 이러한 일부 귀찮음을 감수하면 Phaser는 사용자 입장에서 굉장히 파워풀한 엔진이에요. 아무리 엔진 자체가 잘 만들어졌어도, 개발 생태계가 제대로 구축되지 않아 관련 자료를 얻기가 힘들면 엔진 사용자도 자연스레 줄게 되고, 포럼이 작아지고...엔진 업데이트가 되지 않고...같은 극단적인 악순환이 생기기도 하니까요.
4. Cocos Creator
요약: UGUI에 익숙한 개발자를 구원해줄 HTML5 제작 엔진, Cocos2d-x와는 다른 엔진이니 헷갈려서 설치하지 말자.
성능에 엄청나게 예민한 컨텐츠를 만드는게 아닌 이상 저는 Cocos Creator를 강력 추천합니다.
엔진의 기본 사용법이나 GUI가 Unity와 거의 동일하기 때문에 디자이너, 기획자와 협업이 무척 용이합니다.
<Cocos Creator, 장점>
- UGUI와 굉장히 흡사한 GUI를 제공, 기존 Unity나 Game Maker 사용자라면 굉장히 쉽게 적응 가능
- 오픈소스, 무료
- 로컬 웹서버를 지원하여 따로 구축 작업을 하지 않아도 됨
<Cocos Creator, 단점>
- Pixi.js, Phaser보다는 결과물이 무겁고 용량이 큼, 최적화가 필요
- 엔진에 자잘한 버그와 오류가 꽤 있는 편인데, 빨리 픽스되지 않는 편
- Cocos Creator 3.X와 Cocos Creator 2.X가 있는데, 3버전은 하위호환을 지원하지 않는다. API가 완전히 다름
- 쉐이더나 인스펙터 커스텀등의 기능을 머리 잡아 뜯지 않고 사용하려면 필히 3.X 버전을 사용하자. 메뉴얼이 더 친절하다.
X. 결론 및 요약
* "단순 빌드 용량"의 경우 <minify 여부/엔진 버전/프레임워크 포함여부>등에 따른 용량 변경등을 자세히 고려하여 적은 것은 아니며, 깡통빌드일 경우의 대략적인 참고 수치로 봐주시면 됩니다. 최적화하기에 따라 용량은 천차만별이 될 수 있어요.
Unity WebGL | PixiJS | Phaser | Egret | CocosCreator | |
로컬 웹서버 지원 | ○ | X | X | ○ | ○ |
다양한 개발 자료 | ○ | ○ | ○ | X | ○ |
Task Runner 필요 여부 | X | △ | △ | X | X |
GUI 서포팅 | ○ | X | X | X | ○ |
3D 지원 여부 | ○ | X | X | △ | ○ |
지원언어 | C# | JS/TS | JS/TS | JS/TS | JS/TS |
과금 형태 | 2023 LTS 이후로는 정책에 따라 과금 | 오픈소스 | 오픈소스 | 오픈소스 | 오픈소스 |
단순 빌드 용량 | 2MB 이상 | 1MB 미만 | 1MB 미만 | 1MB 미만 | 1MB 미만 |
'Game development' 카테고리의 다른 글
Git Branch 전략 (0) | 2022.07.29 |
---|---|
[JS/TS] Proxy 사용하여 Object의 값 변화 감지 (0) | 2022.06.24 |
[HTML5] Egret Engine 관련 미세팁 (0) | 2021.12.14 |
[게임 기획 개요서] Recycle Life ~쓰레기 사후재판~ (0) | 2019.06.12 |
[JAVA 네트워크 소켓 프로그래밍] Who Is The Mafia (0) | 2018.02.13 |