자주 묻는 질문들(FAQ)

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

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

간단히 말해서:

  • 개인적, 비영리, 사업 목적으로, 그 외 어떤 이유로든지 자유롭게 Godot를 다운로드하고 사용할 수 있습니다.

  • 비상업적이든 상업적이든 어떤 이유로든 Godot를 마음대로 자유롭게 수정하고, 배포하고, 재배포하고 리믹스할 수 있습니다.

이 문서의 모든 내용은 크리에이티브 커먼스 저작자 표시 3.0 (CC-BY 3.0) 라이선스 하에, "Juan Linietsky, Ariel Manzur, Godot Engine community"에 속합니다.

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

전체 세부 사항은 Godot 저장소의 COPYRIGHT.txt, LICENSE.txt, LOGO_LICENSE.txt 파일을 참고하세요.

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

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

에디터:

  • Windows

  • macOS

  • X11 (Linux, *BSD)

  • 웹

  • Android (시험용)

내보내는 게임:

  • Windows (그리고 UWP)

  • macOS

  • X11 (Linux, *BSD)

  • Android

  • iOS

  • 웹

64비트가 기본값이지만 32비트와 64비트 모두 지원합니다.

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

추가로 콘솔로 빌드하기 위한 비공식 서드 파티 작업이 있습니다. 하지만 아직 그 중 기본 빌드 스크립트나 내보내기 템플릿을 포함한 것은 없습니다.

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

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

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

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

C#은 비교적 최근부터 지원하기 시작했기 때문에 사용하다가 오류에 직면할 수도 있습니다. 우리의 친절하고 부지런한 개발 커뮤니티는 언제나 새 문제를 해결할 준비가 되어있습니다. 하지만 Godot는 오픈 소스 프로젝트이므로 스스로 해결해 보는 것을 추천합니다. Open Issues에서 토론을 찾아보는 것도 문제를 해결하는데 좋은 출발점이 됩니다.

GDNative / NativeScript / PluginScript 기능을 사용한 서드 파티를 통해 새로운 언어를 지원할 수 있습니다. (아래에 플러그인에 관한 질문을 참고하세요.) 예를 들어 Godot와 Python및 Nim간의 바인딩 개발이 비공식적으로 진행 중입니다.

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

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

GDScript를 사용하는 데는 여러 이유가 있습니다. 특히 프로토타입을 만들거나 프로젝트가 알파/베타 수준의 단계이거나 혹은 차세대 AAA급 게임을 만드는 것이 아니라면 말이죠. 하지만 GDScript를 사용하는 가장 두드러진 이유는 전체적인 복잡도 감소 입니다.

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

Godot가 오픈 소스 프로젝트이기 때문에 처음부터 추가 사용자 유치를 위한 더 친근한 프로그래밍 언어를 지원하는 것보다 더 통합되고 완벽한 경험을 우선시하는 것이 ― 특히 더 친근한 언어를 지원하는 것이 더 나쁜 결과로 이어질 때 ― 필연적이었습니다. Godot에서 다른 언어를 쓰고 싶은 마음을 이해합니다(위에서 지원하는 옵션 목록을 참고하세요). GDScript를 써보지 않았다면, 3일 동안 한번 써보세요. GDScript가 얼마나 강력한지, 개발 속도가 빨라지는지 보게 된다면 Godot처럼 마음에 들 것입니다.

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

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

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

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

  1. 대부분의 스크립트 가상 머신(Lua, Python, Squirrel, JS, AS 등)에서는 스레드 지원이 좋지 않지만 Godot는 스레드를 사용합니다.

  2. 대부분의 스크립트 가상 머신은 클래스 확장 지원이 부족하고 Godot의 작동 방식에 맞춰 변형하자면 너무 비효율적입니다 (Lua, Python, JS).

  3. 기존 대부분의 언어에는 많은 양의 코드, 버그, 병목, 그리고 전반적인 비효율을 유발하는, C++ 바인딩을 위한 끔찍한 인터페이스가 있습니다(Lua, Python, Squirrel, JS 등). 우리는 많은 통합이 아닌 좋은 엔진에 중점을 두고 싶었습니다.

  4. (vector3, matrix4 등의) 기본 벡터 타입이 없어서 커스텀 타입을 사용하게 되고 이로 인해 성능이 크게 감소합니다(Lua, Python, Squirrel, JS, AS 등).

  5. (Lua, Python, JavaScript, ActionScript 등의) 가비지 컬렉터는 속도 저하를 일으키고 불필요하게 많은 메모리를 사용합니다.

  6. 코드 완성, 실시간 편집 등 (이 전부를) 지원하기 위한 코드 에디터 통합이 까다롭습니다. GDScript는 이 부분을 잘 지원합니다.

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

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

Godot는 OpenCollada exporter (Maya, 3DSMax)를 통해 Collada를 지원합니다. Blender를 사용하고 있다면 저희의 Better Collada Exporter를 살펴보세요.

Godot 3.0부터 glTF를 지원합니다.

FBX는 Open Asset Import 라이브러리를 통해 지원됩니다. 하지만 FBX는 사유 소프트웨어이므로, 워크플로에 적합하다면 위에 나열된 다른 포맷의 사용을 권장합니다.

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

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

즉, Godot는 오픈 소스이고 모듈화 되어있으므로, 어느 누구라도 클로즈 SDK를 모듈로 추가해서 여러분의 게임에 사용해 출시해도 무방합니다(오픈 소스든지 클로즈 소스든지 말이죠).

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

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

어떻게 고도 에디터를 내 컴퓨터에 설치할 수 있나요?

Godot를 실행하기 위해 시스템에 설치할 필요가 없기 때문에 데스크톱에서 통합이 자동으로 수행되지 않습니다. 이를 극복하기 위해 두 가지 방법이 있습니다. 첫 번째는 Steam, Scoop, Hombrew 또는 Flathub에서 설치하는 것입니다. 이 방법들은 데스크톱 통합을 위해 필요한 몇 가지 절차를 요구할 것 입니다.

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

Windows

  • Godot를 안정적으로 실행할 수 있는 폴더로 (예를 들어 다운로드 폴더 밖으로) 이동하여 나중에 의도와 상관없이 Godot이 이동하여 Shotcut을 사용할 수 없는 경우를 피하시길 바랍니다.

  • Godot 실행파일을 오른쪽클릭하고 "바로 가기" 를 선택합니다.

  • Move the created shortcut to %LOCALAPPDATA%\Microsoft\Windows\Start Menu\Programs. This is the user-wide location for shortcuts that will appear in the Start menu. You can also pin Godot in the task bar by right-clicking the executable and choosing Pin to Task Bar.

macOS

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

리눅스

  • 실수로 Godot 실행파일을 다른 경로로 옮길경우 생성된 바로가기가 깨질 수 있으니 GODOT 바이너리 파일을 안정적인 위치로 (예를 들면 다운로드 폴더의 바깥으로) 옮기세요.

  • Godot 실행파일을 원하는 이름으로 변경하고 PATH 환경변수에 있는 디렉토리로 옮기세요. 일반적으로 /usr/local/bin/godot 또는 /usr/bin/godot 등의 경로가 자주 사용됩니다. 이 경로들로 파일을 옮기려면 보통 시스템 관리자 권한을 요구하지만, 옮길시 터미널에 godot 명령을 입력하므로써 Godot 를 실행할 수 있습니다.

    • Godot 편집기 바이너리를 보호된 위치로 옮길 수 없다면, 바이너리를 홈 디렉토리 어딘가에 보관하고, 아래 링크된 .desktop 파일의 Path= 줄을 수정하여 Godot 바이너리에 대한 전체 절대 경로를 포함할 수 있습니다.

  • Save this .desktop file to $HOME/.local/share/applications/. If you have administrator privileges, you can also save the .desktop file to /usr/local/share/applications to make the shortcut available for all users.

고도 에디터는 포터블 어플리케이션인가요?

In its default configuration, Godot is semi-portable. Its executable can run from any location (including non-writable locations) and never requires administrator privileges.

However, configuration files will be written to the user-wide configuration or data directory. This is usually a good approach, but this means configuration files will not carry across machines if you copy the folder containing the Godot executable. See File paths in Godot projects for more information.

If true portable operation is desired (e.g. for use on an USB stick), follow the steps in Self-contained mode.

Godot가 Direct3D 대신 Vulkan 또는 OpenGL을 사용하는 이유는 무엇인가요?

Godot는 무엇보다도 플랫폼 간 호환성과 개방형 표준을 목표로 합니다. OpenGL과 Vulkan은 개방적이고 (거의) 모든 플랫폼에서 사용할 수 있는 기술입니다. 이 디자인 결정 덕분에 Windows에서 Godot로 개발된 프로젝트는 Linux, macOS 등에서 즉시 실행됩니다.

Godot 렌더러를 작업하는 사람이 적기 때문에 저희는 유지 보수할 렌더링 백엔드가 더 적은 것을 선호합니다. 그 외에도 모든 플랫폼에서 단일 API를 사용하면 각 플랫폼별 문제를 줄이고 일관성을 높일 수 있습니다.

장기적으로, 우리가 (주로 Xbox용) Direct3D 12 렌더러를 개발할 가능성은 있지만 Vulkan 및 OpenGL은 Windows를 포함한 모든 플랫폼에서 기본 렌더링 백엔드가 될 것입니다.

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

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

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

  • 코드 유지 보수와 버그 관리. 매번 우리가 Godot 저장소(repository)에서 새로운 코드를 받을 때마다, 그 코드의 기여자들(contributors)은 보통 이것을 유지 보수하는 책임을 집니다. 어떤 기여자들은 제출한 코드가 병합(merge)된 뒤에는 계속 관심을 두지 않습니다. 이는 문제 있는 코드의 유지 보수를 어렵게 만듭니다. 결과적으로 기능이 제대로 보수되지 않고 버그투성이인 상태가 됩니다. 결국, 회귀를 위해 테스트하고 검사해야 하는 "API 표면"은 시간이 흐름에 따라 계속 증가합니다.

  • 기여의 편의성. 코드 베이스를 작고 깨끗하게 유지해서 전체 소스를 빠르고 쉽게 컴파일할 수 있습니다. 새로운 기여자들이 비싼 하드웨어 없이도 Godot를 쉽게 시작할 수 있습니다.

  • 에디터의 바이너리 크기를 작게 유지하기. 모두의 인터넷 회선이 빠르지는 않습니다. 아무라도 Godot 에디터를 5분 안에 내려받고, 압축을 풀고, 실행할 수 있게 한다면, 전 세계의 개발자들이 더 쉽게 Godot에 접근할 것입니다.

  • 템플릿 내보내기의 바이너리 크기를 작게 하기. Godot에서 내보낸 프로젝트 크기에 직접 영향을 끼칩니다. 모바일이나 웹 환경에서 파일 크기를 최소화하면 성능이 낮은 기기에서 빠르게 설치하고 로딩할 수 있습니다. 다시 말하지만, 지구상에는 초고속 인터넷을 이용할 수 없는 국가가 많습니다. 여기에 더해 이러한 국가에서는 엄격한 데이터 사용 상한제가 자주 시행됩니다.

For all the reasons above, we have to be selective of what we can accept as core functionality in Godot. This is why we are aiming to move some core functionality to officially supported add-ons in future versions of Godot. In terms of binary size, this also has the advantage of making you pay only for what you actually use in your project. (In the meantime, you can compile custom export templates with unused features disabled to optimize the distribution size of your project.)

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

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

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

  1. 게임의 기본 해상도를 고르세요. 해상도가 2K까지 올라가는 기기나 400p까지 내려가는 기기가 있더라도, 기기 안에 있는 균형 하드웨어 스케일링은 이 점을 성능 비용으로 다루진 않을 것입니다. 대부분은 1080p (1920x1080)이나 720p (1280x720) 근처가 기본 해상도입니다. 해상도가 높으면 애셋이 더 커지고, 더 많은 메모리를 차지하고, 로딩에 걸리는 시간이 더 길어진다는 것을 명심하세요.

  2. Godot에서 Stretch 설정을 사용해보세요. 화면 비율을 유지하면서 2D Stretching이 가장 잘 작동합니다. 사용하는 방법은 Multiple resolutions 튜토리얼을 확인해보세요.

  3. 최소 해상도를 정한 다음, 게임의 화면을 다른 화면 비율에 맞게 수직이나 수평으로 늘일지 또는 한 화면 비율만 사용하고 남은 공간을 검은 여백으로 처리할지 결정하세요. 이는 Multiple resolutions에서 설명합니다.

  4. 유저 인터페이스에 대해서는 앵커를 사용해서 Control이 이동하거나 정지해야 할 위치를 결정하세요. UI가 더 복잡하다면 Container 사용을 고려해보세요.

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

(가로 300화소도 안 되는) 오래된 기기의 작은 화면에서도 게임이 작동하려면 내보내기 옵션으로 이미지를 축소해서, 앱 스토어나 구글 플레이에서 해당 빌드를 특정 화면 크기에 사용하도록 설정할 수 있습니다.

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

Godot 에디터 플러그인을 제작하거나 추가적인 언어를 지원하고 싶다면 에디터 플러그인과 툴(tool) 스크립트를 참고하세요.

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

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

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

준비가 된다면요! 자세한 설명은 다음 버전은 언제 출시되나요?를 참고하세요.

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

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

처음으로 시작해야 할 부분은 Issues입니다. 공감되는 문제를 찾은 다음, 기여하는 방법 가이드를 따라가세요. 변경 사항과 함께 Pull Request (PR)를 포크 요청, 수정 및 제출하는 법을 배울 수 있습니다.

Godot에 대한 좋은 아이디어가 있습니다. 어떻게 이것을 공유할 수 있나요?

Godot에 아이디어를 보내는 것이 마치 거대한 핵심 변화를 불러일으키거나, 다른 종류의 게임 엔진을 흉내 내거나, 에디터에 내장하길 원하는 대체 워크플로가 생기는 것 같아서 매력적일 것입니다. 정말 좋아요, 그리고 이런 사람들이 Godot에 기여하기를 원한다는 사실에 감사하고 있습니다. 하지만 Godot의 초점은 로드맵 에 요약된 핵심 기능과 버그를 없애고 이슈를 다루는 것, 그리고 Godot 커뮤니티 회원들 간의 대화입니다.

대부분의 Godot 커뮤니티 개발자들은 이런 것을 배우는 데 더 흥미를 보일 것입니다:

  • 소프트웨어를 사용한 경험과 발생한 문제(우리는 아이디어보다 문제를 개선하는 일을 더 중요하게 여깁니다).

  • 프로젝트에 필요해서 구현하고자 하는 기능.

  • 소프트웨어를 배우면서 이해하기 어려운 개념.

  • 최적화하고 싶은 워크플로 부분.

  • 깔끔한 튜토리얼이 없거나 깔끔하지 않은 문서 부분.

Godot에 대한 아이디어를 환영하지 않는다고 생각하진 마세요. 대신 개발자들과 커뮤니티가 당신의 생각을 바탕으로 기술적 토대를 마련하기 위해, 먼저 아이디어를 문제로 재구성해주세요.

생각과 문제를 커뮤니티와 공유하는 좋은 방법은 이야기로 서술하는 것입니다. 무엇을 하려 했고, 어떤 일을 예상했는데, 그 뒤에 실제로 어떤 일이 일어났는지 설명하세요. 이 방법으로 문제와 생각을 정리하면 전체 커뮤니티가 개발자 경험 개선에 집중할 수 있습니다.

스크린샷, 구체적인 값, 테스트 케이스, (가능하다면) 예제 프로젝트를 첨부하면 추가 점수를 받습니다.

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

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

게임이 아닌 응용 프로그램을 제작할 때는 CPU와 GPU 사용률을 줄이기 위해 반드시 프로젝트 설정에서 low-processor mode를 활성화해주세요.

그렇긴 하지만 모바일 응용 프로그램 제작에는 Godot를 사용하지 말아 주세요. 아직 모바일 플랫폼에서는 저사양모드를 지원하지 않습니다.

Godot로 만든 오픈소스 예제 애플리케이션 Material Maker와 Pixelorama를 확인해보세요.

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

Godot는 에디터와 함께 사용하게 되어 있습니다. 길게 보면 시간을 절약할 수 있으므로 에디터를 사용하는 게 좋습니다. Godot를 라이브러리로 이용할 수 있도록 만들면 엔진의 다른 부분이 더 복잡해지고 숙달되지 않은 사용자들이 쓰기 어려워지기 때문에 그럴 계획은 없습니다.

만약 렌더링 라이브러리를 원하신다면, 대신 기존 렌더링 엔진 사용을 고려해보세요. 대부분의 렌더링 엔진 커뮤니티는 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는 왜 표준 템플릿 라이브러리(STL: Standard Template Library)를 사용하지 않나요?

(Qt와 같은) 다른 많은 라이브러리처럼 Godot는 STL을 사용하지 않습니다. 우리는 STL이 훌륭한 범용 라이브러리라고 생각하지만, Godot에게는 특별한 요구 사항이 있었습니다.

  • STL 템플릿은 매우 큰 심볼들을 만들어서, 결과적으로 거대한 디버그 바이너리를 만듭니다. 대신 Godot는 매우 짧은 이름의 템플릿을 조금만 사용합니다.

  • Copy-On-Write를 사용하고 데이터를 전달하기 위해 사용하는, 벡터와 같은 대부분의 컨테이너는, 성능을 위해 O(1) 접근 시간이 필요한 RID 시스템과 같은 특수 목적에 맞춰졌습니다. 이와 비슷하게 Godot 해시 맵은 내부 엔진 유형과 부드럽게 통합하도록 설계 및 구현되었습니다.

  • Godot 컨테이너에는 메모리 추적 기능이 내장돼 있어서, 메모리 사용량을 더 잘 추적합니다.

  • Godot에서 큰 배열은 사전에 할당된 버퍼 메모리 혹은 가상 메모리에 매핑되는 메모리 풀(Pool)을 사용합니다.

  • STL에서 제공하는 문자열 타입은 너무 단순하고 현지화 지원 기능이 부족하기 때문에 Godot는 커스텀 문자열 타입을 사용합니다.

왜 Godot는 예외(Exception)를 사용하지 않나요?

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

또한 예외는 실행 파일의 바이너리 크기를 상당히 늘립니다.

왜 Godot는 런타임 타입 정보(RTTI)를 강요하지 않나요?

Godot에는 선택적으로 런타임 타입 정보를 사용하는 자체 타입 캐스팅 시스템이 있습니다. Godot에서 런타임 타입 정보를 비활성화하면 약간의 성능 비용으로 바이너리 크기를 줄일 수 있습니다.

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

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

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

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

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

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

Ways to contribute를 참고하세요.

Godot는 누가 만드나요? 제가 연락할 수 있을까요?

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