Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Checking the stable version of the documentation...

자주 묻는 질문

Godot로 무엇을 할 수 있나요? 가격은 얼마인가요? 라이선스 조항은 어떻게 되나요?

Godot는 OSI가 승인한 MIT 라이선스로 사용 가능한 자유 및 오픈 소스 소프트웨어입니다. 이 말인 즉, Godot는 "언론의 자유(Free)", "무료(Free) 맥주"에서의 free의 뜻을 모두 지니고 있다는 것이죠.

간단히 말해서:

개인적, 비영리, 사업 목적으로, 그 외 어떤 이유로든지 자유롭게 Godot를 다운로드하고 사용할 수 있습니다.
비상업적이든 상업적이든 어떤 이유로든 Godot를 마음대로 자유롭게 수정하고, 배포하고, 재배포하고 리믹스할 수 있습니다.

이 문서의 모든 내용은 크리에이티브 커먼스 저작자 표시 3.0 (CC-BY 3.0) 라이선스 하에 자유롭게 사용할 수 있으며, 저작권은 "Juan Linietsky, Ariel Manzur 및 Godot 엔진 커뮤니티"에 속합니다.

로고와 아이콘은 일반적으로 동일한 크리에이티브 커먼스 라이선스 하에 속합니다. Godot의 소스 코드에 포함된 일부 서드 파티 라이브러리에는 다른 라이선스가 적용될 수 있으므로 유의하세요.

For full details, look at the COPYRIGHT.txt as well as the LICENSE.txt and logo LICENSE.txt files in the Godot repository.

Godot 웹 사이트의 라이선스 페이지도 참조하세요.

Godot는 어떤 플랫폼을 지원하나요?

편집기:

Windows
macOS
Linux, *BSD
Android (실험적)
웹 (실험적)

게임을 내보낼 수 있는 플랫폼:

Windows
macOS
Linux, *BSD
Android
iOS
웹

32비트와 64비트 바이너리 모두 지원되며, 64비트가 기본값입니다. 공식 macOS 빌드는 x86_64 뿐만 아니라 Apple Silicon 또한 기본적으로 지원합니다.

일부 사용자들은 Linux로 Raspberry Pi와 같은 ARM 기반 시스템에 Godot를 성공적으로 빌드하고 사용했다고 말합니다.

Godot 웹 사이트의 라이선스 페이지도 참조하세요.

자세한 정보는 내보내기와 Godot를 직접 컴파일하기섹션을 참고하세요.

참고

Godot 3는 유니버설 Windows 플랫폼(UWP)도 지원했습니다. 이 플랫폼 포트는 유지 관리 부족으로 인해 Godot 4에서 제거되었으며 Microsoft에서 더 이상 지원하지 않습니다. 관심 있는 사용자를 위해 현재 안정된 Godot 3 릴리스에서 계속 사용 가능합니다.

Godot는 어떤 프로그래밍 언어를 지원하나요?

Godot가 공식으로 지원하는 언어는 GDScript와 C#, C++입니다. 스크립팅 섹션에서 각 언어별 하위 카테고리를 참고하세요.

Godot 또는 게임 개발을 막 시작한 경우 일반적으로 Godot에서 네이티브로 동작하는 GDScript를 배우고 사용하는 것을 권장합니다. 스크립트 언어는 장기적으로 다른 저수준 언어보다 퍼포먼스가 떨어지는 경향이 있습니다. 하지만 프로토타이핑, 최소 기능 제품(MVP) 개발, 판매할 때까지 걸리는 시간(TTM)에 중점을 둔다면 GDScript는 게임을 개발하는데 빠르고, 친절하고, 유능한 방법을 제공합니다.

C#은 비교적 최근부터 지원하기 시작했기 때문에 사용하다가 오류에 직면할 수도 있습니다. 또한 C# 지원은 아직 웹 플랫폼에서는 사용할 수 없습니다. 우리의 친절하고 부지런한 개발 커뮤니티는 언제나 새 문제를 해결할 준비가 되어있습니다만, Godot는 오픈 소스 프로젝트이므로 스스로 해결해볼 수도 있습니다. 열린 이슈 목록에서 토론을 찾아보는 것은 문제 해결에 있어 좋은 출발점이 될 것입니다.

새로운 언어의 경우 GDExtension 등을 통해 지원이 가능합니다. (아래 플러그인 관련 문의 사항 참고). 예를 들어 Godot와 Python및 Nim간의 바인딩 개발이 비공식적으로 진행 중입니다.

GDScript는 무엇이고 왜 이것을 써야 하나요?

GDScript는 Godot에 내장된 스크립트 언어입니다. GDScript는 처음부터 짧은 코드로도 Godot의 잠재력을 극대화할 수 있도록 만들어져 있어 초심자와 전문 개발자가 Godot의 강점을 가능한 한 빨리 활용할 수 있습니다. 이전에 Python 같은 언어를 사용해 보신 적이 있다면 익숙할 겁니다. GDScript 예제, 기능에 대한 전체 개요, 역사는 GDScript 스크립팅 가이드를 참고하세요.

GDScript를 사용하는 데는 여러 이유가 있습니다. 하지만 GDScript를 사용하는 가장 두드러진 이유는 전체적인 복잡도 감소 입니다.

철저하게 통합된 Godot 전용 스크립트 언어는 본래 두 가지 의도로 만들어졌습니다. 첫째, Godot를 실행하는 시간을 단축시켜 개발자들이 생산성에 중점을 두고 엔진에 빠르게 접근하도록 하기 위함입니다. 둘째, 전반적인 유지 보수 부담을 줄여 문제를 간단하게 만들고, 엔진 개발자가 많은 언어 집단에서 작동하는 자잘한 기능을 얻으려고 많은 시간을 소모하는 대신에 엔진 핵심 버그를 없애고 기능을 개선하는데 집중할 수 있도록 하기 위함입니다.

Godot는 오픈 소스 프로젝트이기 때문에, 사용자층을 늘리기 위해 친근한 프로그래밍 언어를 지원하기보다는 처음부터 더 통합되고 완벽한 경험을 제공하는 일을 우선시할 필요가 있었습니다. 특히 더 친근한 언어를 지원하는 것이 더 나쁜 결과로 이어질 수 있었다면 더욱 그랬습니다. 물론 Godot에서 다른 언어를 쓰고 싶은 마음을 이해합니다 (위에서 지원되는 옵션의 목록 참조). 하지만 GDScript를 써보지 않았다면, 딱 3일만 한 번 써보세요. GDScript가 얼마나 강력한지, 개발 속도가 얼마나 더 빨라지는지 알고 나면 분명 Godot처럼 마음에 들 것입니다.

GDScript 또는 동적 타입 언어에 익숙해지려면 GDScript: 동적 언어 소개 튜토리얼을 참고하세요.

GDScript를 만들게 된 동기가 무엇인가요?

처음에는 Lua 스크립팅 언어를 사용했습니다. Lua는 빠르지만 (Fallback을 사용해서) 객체 지향 시스템에 바인딩을 생성하는 일은 복잡하고 느리면서도 엄청난 양의 코드가 필요했습니다. Python으로도 몇 번 실험해봤지만 엔진에 내장하기 어려웠습니다.

Godot 전용 스크립트 언어를 개발하게 된 주요 이유는 이러합니다:

대부분의 스크립트 가상 머신(Lua, Python, Squirrel, JS, AS 등)에서는 스레드 지원이 좋지 않지만 Godot는 스레드를 사용합니다.
대부분의 스크립트 가상 머신은 클래스 확장 지원이 부족하고 Godot의 작동 방식에 맞춰 변형하자면 너무 비효율적입니다 (Lua, Python, JS).
현존하는 수많은 언어들은 많은 양의 코드, 버그, 병목 현상과 전반적인 비효율을 유발하는 끔찍한 C++ 바인딩 인터페이스를 가지고 있습니다 (Lua, Python, Squirrel, JS 등). 우리는 그 수많은 통합보다는 더 좋은 엔진에 중점을 두고 싶었습니다.
(Vector3, Matrix4 등의) 기본 벡터 타입이 없어서 커스텀 타입을 사용하게 되고 이로 인해 성능이 크게 감소합니다 (Lua, Python, Squirrel, JS, AS 등).
(Lua, Python, JavaScript, ActionScript 등의) 가비지 컬렉터는 속도 저하를 일으키고 불필요하게 많은 메모리를 사용합니다.
코드 완성, 실시간 편집 등 (이 전부를) 제공하기 위한 코드 편집기를 통합라는 것은 까다롭습니다.

GDScript는 위의 문제 등을 줄이기 위해 설계되었습니다.

어떤 프로그래밍 언어가 가장 빠르나요?

대부분의 게임에서 스크립트 언어 자체가 성능 문제의 원인이 되지는 않습니다. 대신, 성능은 비효율적인 알고리즘(모든 언어에서 느림), GPU 성능, 또는 물리나 내비게이션 같은 일반적인 C++ 엔진 코드에 의해 저하됩니다. Godot가 지원하는 모든 언어는 범용 스크립팅에 충분히 빠릅니다. 사용 편의성, 익숙함, 플랫폼 지원, 또는 언어 기능과 같은 다른 요소를 기반으로 언어를 선택해야 합니다.

일반적으로 C#과 GDScript의 성능은 비슷한 수준이며, C++는 둘보다 더 빠릅니다.

GDScript의 성능을 C#과 비교하는 것은 까다롭습니다. 특정 상황에서는 C#이 더 빠를 수 있기 때문입니다. C# 언어 자체는 일반적으로 GDScript보다 빠른 경향이 있어, Godot 엔진 코드를 호출하는 횟수가 적은 상황에서는 C#이 더 빠를 수 있습니다. 그러나 많은 Godot API 호출이 필요한 경우, 변환처리 비용 때문에 C#이 GDScript보다 느려질 수 있습니다. 또한 C#의 성능은 임의의 예측 불가능한 순간에 발생하는 메모리 관리(GC)로 인해 저하될 수 있으며, 이로 인해 복잡한 프로젝트에서 버벅이는 문제가 발생할 수 있습니다. 이 문제는 Godot에만 국한된 것이 아닙니다.

C++는 GDExtension을 사용하면 거의 항상 C#이나 GDScript보다 빠릅니다. 하지만 C++는 C#이나 GDScript보다 사용하기 어렵고 개발 속도도 느립니다.

단일 프로젝트 내에서 여러 언어를 사용할 수도 있습니다. 교차 언어 스크립팅 을 사용하거나 GDExtension과 스크립팅 언어를 함께 사용하여 가능합니다. 다만, 그렇게 하면 자체적인 복잡성이 따릅니다.

Godot는 어떤 타입의 3D 모델 형식을 지원하나요?

지원되는 형식, 3D 모델링 소프트웨어에서 내보내는 방법, Godot용으로 가져오는 방법에 대한 자세한 정보는 3D 씬 가져오기 설명서에서 확인할 수 있습니다.

Godot에서 [FMOD, GameWorks 등 클로즈드 SDK]가 지원될까요?

Godot의 목표는 모듈 방식에 확장 가능한 자유 및 오픈 소스 MIT 라이선스 엔진을 만드는 것입니다. 핵심 엔진 개발 커뮤니티는 클로즈드 소스/독점 SDK와 통합하는 것은 Godot의 정신에 반하기에 이를 지원할 계획이 없습니다.

즉, Godot는 오픈 소스이고 모듈화되어있기에, 누구든 이런 라이브러리를 모듈로 추가해서 게임에 사용해 출시할 수 있습니다. 그것이 오픈 소스든지 클로즈드 소스든지 말이죠.

여러분이 선택한 SDK에 대한 지원은 아래 플러그인 질문을 읽어보세요.

혹시 Godot가 지원하진 않지만 무료이고 오픈 소스로 제공하는 다른 SDK를 아신다면 직접 통합 작업을 시작해보세요. Godot는 한 사람의 것이 아닙니다; Godot는 한 사람의 소유가 아닌 커뮤니티에 속해 있으며, 당신과 같은 야심 찬 커뮤니티 기여자들과 함께 성장합니다.

어떻게 Godot를 확장할 수 있나요?

Godot 편집기 플러그인을 만들거나 추가적인 언어의 지원을 추가하는 등 Godot를 확장하고 싶다면 EditorPlugins와 툴 스크립트를 살펴보세요.

이 주제에 관한 공식 블로그 게시물도 참고하세요:

여기 GDNative가 있어요!

GDScript 구현, Godot 모듈, Godot에 대한 비공식 Python 지원을 살펴보세요. Godot가 어떻게 서드 파티 라이브러리와 통합하는지를 알 수 있는 좋은 출발점입니다.

어떻게 Godot 편집기를 내 시스템(데스크톱 통합용)에 설치하나요?

Godot를 실행하기 위해 시스템에 설치할 필요가 없기 때문에 데스크톱에서 통합이 자동으로 수행되지 않습니다. 이를 극복하기 위해 두 가지 방법이 있습니다. 당신은 Godot를 Steam (all platforms), Scoop (Windows), Homebrew (macOS) 또는 Flathub (Linux) 을 통해 설치할 수 있습니다. 이 방법들은 데스크톱 통합을 위한 과정들을 자동으로 수행할 것 입니다.

또는 설치 프로그램이 수행하는 단계를 수동으로 수행할 수 있습니다 :

Windows

Godot를 안정적으로 실행할 수 있는 폴더로 (예를 들어 다운로드 폴더 밖으로) 이동하여 나중에 의도와 상관없이 Godot가 이동하여 Shotcut을 사용할 수 없는 경우를 피하시길 바랍니다.
Godot 실행 파일을 오른쪽 클릭하고 바로 가기 만들기를 선택합니다.
생성된 바로 가기를 %LOCALAPPDATA%\Microsoft\Windows\Start Menu\Programs로 이동하세요. 이 폴더는 시작 메뉴에 표시될 바로 가기의 사용자 위치입니다. 다른 방법으로는, 실행 파일을 오른쪽 클릭해서 작업 표시줄에 고정을 선택하여 Godot를 작업 표시줄에 고정할 수 있습니다.

macOS

추출한 Godot 애플리케이션을 /Applications/Godot.app으로 드래그하세요, 추가로 원할 경우 Dock으로도 드래그하세요. 애플리케이션이 /Applications 또는 ~/Applications에 있다면 Spotlight에서 Godot를 찾을 수 있습니다.

Linux

실수로 Godot 실행파일을 다른 경로로 옮길경우 생성된 바로가기가 깨질 수 있으니 GODOT 바이너리 파일을 안정적인 위치로 (예를 들면 다운로드 폴더의 바깥으로) 옮기세요.
Godot 실행파일을 원하는 이름으로 변경하고 PATH 환경변수에 있는 디렉터리로 옮기세요. 일반적으로 /usr/local/bin/godot 또는 /usr/bin/godot 등의 경로가 자주 사용됩니다. 이 경로들로 파일을 옮기려면 보통 시스템 관리자 권한을 요구하지만, 옮길시 터미널에 godot 명령을 입력하므로써 Godot 를 실행할 수 있습니다.
- Godot 편집기 바이너리를 보호된 위치로 옮길 수 없다면, 바이너리를 홈 디렉터리 어딘가에 보관하고, 아래 링크된 .desktop 파일의 Path= 줄을 수정하여 Godot 바이너리에 대한 전체 절대 경로를 포함할 수 있습니다.
이 데스크톱 파일을 $HOME/.local/share/applications/ 에 저장하세요. 만약 관리자 권한이 있다면, 이 .desktop 파일을 /usr/local/share/applications 에 저장하여 모든 사용자들이 접근할 수 있는 바로 가기를 만들 수 있습니다.

Godot 편집기는 휴대용 애플리케이션입니까?

Godot는 디폴트 구성으로 세미-포터블입니다. 실행 파일은 (쓰기 불가능한 위치를 포함한) 모든 위치에서 실행 가능하며 관리자 권한이 필요하지 않습니다.

하지만, 구성 파일은 사용자의 구성 또는 데이터 디렉터리에 기록됩니다. 이는 일반적으로 좋은 방식이지만, Godot 실행 파일이 포함된 폴더를 복사하는 경우 구성 파일이 시스템 간에 전달되지 않습니다. 자세한 정보는 프로젝트 준비하기를 참조하세요.

만약 진정한 포터블 동작이 필요한 경우 (예: USB 스틱에서 사용), :ref:`doc_data_paths_self_contained_mode`의 단계를 따르세요.

왜 Godot는 주요 기능을 작게 유지하려고 하나요?

Godot는 매우 자주 쓰이지 않는 이상 add-on으로 구현할 수 있는 기능들은 의도적으로 포함하지 않습니다. 고급 인공 지능 같은 것이 그 예입니다.

이렇게 하려는 이유가 몇 가지 있습니다:

코드 유지 보수와 버그 관리. 매번 우리가 Godot 저장소(repository)에서 새로운 코드를 받을 때마다, 그 코드의 기여자들은 보통 이것을 유지 보수하는 책임을 집니다. 어떤 기여자들은 제출한 코드가 병합된 뒤에는 관심을 두지 않기 때문에, 문제가 있는 코드를 관리하기 어렵게 만듭니다. 이로 인해 수정되지 않은 버그로 인해 기능이 제대로 유지되지 않을 수 있습니다. 여기에 회귀 테스트 및 확인이 필요한 "API surface"는 시간이 지날수록 계속 증가하게 됩니다.
기여의 편의성. 코드 베이스를 작고 깨끗하게 유지해서 전체 소스를 빠르고 쉽게 컴파일할 수 있습니다. 새로운 기여자들이 고사양 하드웨어 없이도 Godot를 쉽게 시작할 수 있습니다.
편집기의 바이너리 크기를 작게 유지하기. 모두의 인터넷 회선이 빠르지는 않습니다. 아무라도 Godot 편집기를 5분 안에 내려받고, 압축을 풀고, 실행할 수 있게 한다면, 전 세계의 개발자들이 더 쉽게 Godot에 접근할 것입니다.
내보내기 템플릿의 바이너리 크기를 작게 유지합니다. 이는 Godot로 내보낸 프로젝트의 크기에 직접적인 영향을 미칩니다. 모바일 및 웹 플랫폼에서는 저사양 기기에서 빠른 설치 및 로딩을 보장하기 위해 파일 크기를 낮게 유지하는 것이 중요합니다. 다시 말하지만, 고속 인터넷을 쉽게 사용할 수 없는 국가들이 많습니다. 이에 더해, 해당 국가에서는 엄격한 데이터 사용량 제한이 적용되는 경우가 많습니다.

위와 같은 이유로 어떤 것을 Godot의 핵심 기능으로 넣을지 선택해야만 합니다. 이것이 저희가 일부 핵심 기능을 미래의 Godot 버전에서 공식 지원 add-on으로 만들려는 이유입니다. 바이너리 크기 측면에서 프로젝트에 실제 사용하는 것만을 포함하는 장점이 있습니다. (그동안 프로젝트의 배포 크기를 최적화하기 위해 사용하지 않는 기능을 비활성화해서 커스텀 내보내기 템플릿을 컴파일할 수 있습니다.)

다양한 해상도와 화면 비율에 맞는 애셋을 어떻게 만드나요?

이런 고민은 아마도 Apple 사가 언젠가 자사 제품의 해상도를 두 배로 늘렸을 때 생긴 오해 때문일 겁니다. 이 때문에 사람들은 다양한 해상도에서 동일한 애셋을 보여주는 것이 좋은 아이디어라 생각했습니다. 그런데 이런 통념은 짧은 기간 Apple 제품에 한에서는 적용됐지만, 얼마 지나지 않아 다양한 해상도와 화면 비율, DPI의 Android 기기들과 Apple 기기들이 시장에 출시되면서 이제는 불필요해졌습니다.

이제 다양한 기기에 대응할 수 있는 가장 일반적이고 적절한 방법은 2D 게임의 경우 한 해상도에 다양한 화면 비율을 지원해주는 것입니다. 3D 게임에서는 단순히 카메라의 XFov나 YFov를 조절하는 것으로 해결할 수 있습니다.

게임의 기본 해상도를 고르세요. 해상도가 2K까지 올라가는 기기나 400p까지 내려가는 기기가 있더라도, 기기 안에 있는 균형 하드웨어 스케일링은 이 점을 성능 비용으로 다루진 않을 것입니다. 대부분은 1080p (1920x1080)이나 720p (1280x720) 근처가 기본 해상도입니다. 해상도가 높으면 애셋이 더 커지고, 더 많은 메모리를 차지하고, 로딩에 걸리는 시간이 더 길어진다는 것을 명심하세요.
Godot에서 Stretch 설정을 사용해보세요. 화면 비율을 유지하면서 2D Stretching이 가장 잘 작동합니다. 사용하는 방법은 다양한 해상도 튜토리얼을 확인해보세요.
최소 해상도를 정한 다음, 게임의 화면을 다른 화면 비율에 맞게 수직이나 수평으로 늘릴지 또는 한 화면 비율만 사용하고 남은 공간을 검은 여백으로 처리할지 결정하세요. 이는 다양한 해상도에서 설명합니다.
유저 인터페이스에 대해서는 앵커를 사용해서 Control이 이동하거나 정지해야 할 위치를 결정하세요. UI가 더 복잡하다면 Container 사용을 고려해보세요.

다 됐습니다! 여러분의 게임은 이제 다양한 해상도에서 작동합니다.

Godot의 다음 릴리스는 언제인가요?

준비되면요! 자세한 정보는 다음 버전은 언제 출시되나요?를 참조하세요.

새 프로젝트에 어떤 Godot 버전을 사용해야 하나요?

새 프로젝트에는 Godot 4.x를 사용하는 것이 좋지만, 필요한 기능 세트에 따라 3.x를 사용하는 것이 더 나을 수도 있습니다. 자세한 정보는 어떤 이동 메서드를 사용해야 할까요?를 참조하세요.

새 Godot 버전을 사용하려면 프로젝트를 업그레이드해야 하나요?

일부 새 버전은 다른 버전보다 업그레이드하는 것이 더 안전합니다. 일반적으로 업그레이드 여부는 프로젝트의 상황에 따라 달라집니다. 자세한 정보는 프로젝트를 새 엔진 버전으로 업그레이드해야 할까요?를 참조하세요.

Forward+, Mobile, 또는 Compatibility 렌더러 중 어떤 것을 사용해야 할까요?

렌더러에 대한 자세한 비교는 렌더러의 개요.에서 찾을 수 있습니다.

저도 기여하고 싶어요! 어떻게 시작해야 하나요?

좋아요! 오픈 소스 프로젝트로서 Godot는 여러분같은 개발자들의 혁신과 야망을 바탕으로 번창합니다.

Godot에 기여를 시작하는 가장 좋은 방법은 Godot를 사용하면서 발생하는 문제를 보고하는 것입니다. 명확한 재현 단계가 포함된 좋은 버그 리포트는 기여자들이 버그를 빠르고 효율적으로 수정하는 데 도움이 됩니다. 또한 온라인 문서에서 찾은 문제를 보고할 수도 있습니다.

첫 번째 PR을 보낼 준비가 되었다고 생각했다면, 위의 링크 중 하나에서 마음이 가는 문제를 골라 해결해 보세요. 소스에서 엔진을 컴파일하는 방법이나 문서를 작성하는 방법을 배워야 합니다. 또한 Godot 개발자들이 사용하는 버전 제어 시스템인 Git에 익숙해질 필요가 있습니다.

엔진 소스 작업 방법, 문서 편집 방법 및 기여 방법에 대한 설명은 기여자를 위한 문서에 수록되어 있습니다.

Godot를 게임이 아닌 응용프로그램 제작에 이용할 수 있을까요?

네! Godot는 광범위한 내장 UI 시스템을 갖추고 있고 Godot의 작은 배포 크기는 Electron, Qt와 같은 프레임 워크의 적절한 대안이 될 수 있습니다.

자세한 정보는 3D 안티앨리어싱을 참조하세요.

Godot를 라이브러리로 이용할 수 있을까요?

Godot로 게임을 만들고 싶다면 Godot는 편집기와 함께 사용하도록 설계되었다는 점을 명심하세요. 장기적으로 시간을 절약할 수 있으므로 시도해 보는 것이 좋습니다.

보다 전문화된 애플리케이션의 경우 Godot를 라이브러리로 사용하는 것이 합리적일 수 있습니다. Godot 4.6부터 LibGodot 형태의 정적 또는 공유 라이브러리로 Godot를 사용하기 위한 실험적 지원이 있습니다. 이는 현재 Windows, macOS 및 Linux에서 지원됩니다. Android 및 iOS에 대한 지원은 향후 릴리스에서 계획되어 있습니다.

`migeran/libgodot_project GitHub 저장소 <https://github.com/migeran/libgodot_project>`__에서 Godot를 라이브러리로 사용하는 샘플 애플리케이션을 찾을 수 있습니다.

Godot는 어떤 유저 인터페이스 툴킷을 사용하나요?

Godot는 GTK나 Qt, wxWidgets와 같은 표준 GUI 툴킷을 사용하지 않는 대신 OpenGL ES나 Vulcan으로 렌더링하는 자체 유저 인터페이스 툴킷을 사용합니다. 이 툴킷은 (C++로 작성된) 편집기를 렌더링할 때 사용되는 컨트롤 노드의 형태로 노출되어 있습니다. 물론 이 컨트롤 노드들은 Godot가 지원하는 어느 스크립트 언어로든지 사용할 수 있습니다.

이 사용자 지정 툴킷 덕분에 하드웨어 가속의 이점을 누릴 수 있고 모든 플랫폼을 아울러 일정한 외관을 유지할 수 있습니다. 그에 더해 GTK나 Qt에 붙어 있는 LGPL 라이센스 조건을 신경 쓸 필요도 없습니다. 마지막으로 편집기 자체가 Godot UI 시스템의 가장 복잡한 사용자 중 하나이기 때문에 Godot는 개밥 먹기(eating its own dog food)를 하는 것이기도 합니다.

이 사용자 지정 UI 툴킷은 라이브러리로 사용할 수 없지만, 편집기를 이용하여 Godot로 비게임 애플리케이션을 만들 수는 있습니다.

왜 Godot는 SCons 빌드 시스템을 사용하지 않나요?

Godot는 SCons 빌드 시스템을 사용합니다. 가까운 시일 내에 다른 빌드 시스템으로 전환할 계획은 없습니다. 다른 대안 대신 SCons를 선택한 데에는 여러 가지 이유가 있습니다. 예를 들어:

Godot는 모든 PC 플랫폼, 모든 모바일 플랫폼, 여러 콘솔, WebAssembly 등 12개의 다양한 플랫폼에서 컴파일할 수 있습니다.
개발자는 여러 플랫폼을 동시에 컴파일해야 하거나, 심지어 같은 플랫폼의 다른 타깃을 컴파일해야 하는 경우가 많습니다. 매번 프로젝트를 재구성하고 다시 빌드할 여유가 없습니다. SCon을 사용하면 빌드를 중단하지 않고도 이 작업을 손쉽게 수행할 수 있습니다.
SCon은 아무리 많은 변경, 구성, 추가, 제거 등을 해도 빌드를 절대 깨뜨리지 않습니다.
Godot의 빌드 프로세스는 간단하지 않습니다. 여러 파일이 코드(바인더)로 생성되고, 다른 파일은 파싱(셰이더)되며, 다른 파일은 커스터마이징을 제공해야 합니다(modules). 이를 위해서는 복잡한 로직이 필요한데, 대부분 빌드 전용 매크로 기반 언어를 사용하는 것보다 실제 프로그래밍 언어(예: Python)로 작성하는 것이 더 쉽습니다.
Godot 빌드 프로세스는 크로스 컴파일 도구를 많이 사용합니다. 각 플랫폼에는 특정 탐지 프로세스가 있으며, 이러한 모든 프로세스는 각각에 대해 작성된 특수 코드를 사용하여 특정 케이스로 처리해야 합니다.

Godot를 직접 만들 계획이라면 열린 마음을 가지고 SCons에 대해 조금이라도 익숙해지도록 노력하세요.

Godot는 왜 표준 템플릿 라이브러리(STL: Standard Template Library)를 사용하지 않나요?

스레딩 프리미티브와 같은 몇 가지 예외를 제외하면 Qt와 같은 다른 많은 라이브러리처럼 Godot는 STL을 사용하지 않습니다. 우리는 STL이 훌륭한 범용 라이브러리라고 생각하지만, Godot에 특별한 요구 사항이 있었습니다.

STL 템플릿은 매우 큰 심볼들을 만들어서, 결과적으로 거대한 디버그 바이너리를 만듭니다. 대신 Godot는 매우 짧은 이름의 템플릿을 조금만 사용합니다.
Copy-On-Write를 사용하고 데이터를 전달하기 위해 사용하는, 벡터와 같은 대부분의 컨테이너는, 성능을 위해 O(1) 접근 시간이 필요한 RID 시스템과 같은 특수 목적에 맞춰졌습니다. 이와 비슷하게 Godot 해시 맵은 내부 엔진 유형과 부드럽게 통합하도록 설계 및 구현되었습니다.
Godot 컨테이너에는 메모리 추적 기능이 내장돼 있어서, 메모리 사용량을 더 잘 추적합니다.
큰 배열에는 미리 할당된 버퍼나 가상 메모리에 매핑할 수 있는 풀링된 메모리를 사용합니다.
STL에서 제공하는 문자열 타입은 너무 단순하고 현지화 지원 기능이 부족하기 때문에 Godot는 커스텀 문자열 타입을 사용합니다.

대안을 알아보려면 Godot의 컨테이너 유형을 확인하세요.

왜 Godot는 예외를 사용하지 않나요?

우리는 게임이 어떤 경우에도 고장나지 않아야 한다고 생각합니다. 예기치 못한 사태가 벌어지면, Godot는 (스크립트에서 추적할 수 있는) 오류를 작성한 다음, 가능한 한 정상적으로 게임을 복구한 후 계속 진행합니다.

또한 예외는 실행 파일의 크기를 늘리고 결과적으로 컴파일 시간이 늘어납니다.

Godot가 ECS(Entity Component System)를 사용하나요?

Godot는 ECS를 사용하지 않고 대신에 상속에 의존합니다. 일반적으로 더 좋은 접근 방식이 없는 한 우리는 상속 기반 접근 방식을 사용하면 대부분의 사용 사례에서 충분히 빠르면서도 사용성이 향상된다는 사실을 발견했습니다.

그렇다고 해도, 개별 스크립트로 자식 노드를 만들어 프로젝트에서 컴포지션을 활용하는 것을 막을 수는 없습니다. 이러한 노드는 런타임에 추가 및 제거하여 행동을 동적으로 추가하고 제거할 수 있습니다.

Godot의 설계 선택에 대한 자세한 내용은 이 글에서 확인할 수 있습니다.

Godot는 왜 데이터 지향 디자인(DoD) 구현을 강제하지 않나요?

Godot는 내부적으로 많은 고성능 작업 처리를 위해 가능한 한 캐시 일관성을 사용하려 하지만, 저희는 대부분의 사용자가 DoD 관행을 따라야 할 필요가 없다고 생각합니다.

DoD는 대개 캐시 일관성 최적화를 뜻하며, 이는 즉 수 만 개의 객체가 있는 경우에만 (그리고 객체가 모든 프레임에서 수정이 거의 없이 처리되는 경우에만) 상당한 성능 향상을 볼 수 있습니다. 만약 프레임마다 수 백 개의 스프라이트나 적을 이동한다 하면 DoD는 도움이 되지 않으므로, 최적화에 있어서 다른 접근법을 생각해 봐야 하는 것이죠.

대다수의 게임은 DoD가 필요하지 않고 Godot는 DoD가 필요한 대부분의 경우에 작업을 수행할 수 있는 편리한 도우미를 제공합니다.

게임이 정말로 많은 양의 객체를 처리해야 한다면 높은 성능이 필요한 부분은 C++과 GDExtension을 사용하고 그 외 나머지 부분은 GDScript (혹은 C#)을 사용하길 권합니다.

어떻게 Godot 개발을 돕거나 후원할 수 있나요?

기여하는 방법을 참조하세요.

Godot는 누가 만드나요? 어떻게 연락할 수 있나요?

Godot 웹사이트에서 해당 페이지를 참고하세요.