자주 묻는 질문들(FAQ)

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

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

간단히 말해서:

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

  • Godot를 마음대로 자유롭게 수정하고, 배포하고, 재배포하고 수정할 수 있습니다. 그 이유가 비상업적이든지 상업적이든지 말이죠.

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

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

전체 세부 사항은 Godot 저장소에 있는 COPYRIGHT.txtLICENSE.txt, LOGO_LICENSE.txt 파일을 참고하세요.

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

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

편집기의 경우:

  • Windows

  • macOS

  • X11 (Linux, *BSD)

내보내는 게임의 경우:

  • Windows (그리고 UWP)

  • macOS

  • X11 (Linux, *BSD)

  • Android

  • iOS

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

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

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

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

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

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

대개 Godot 개발이나 게임 개발을 목적으로 엔진을 켜게 된다면, Godot에 네이티브로 동작하는 GDScript를 배우고 사용하는데 추천하는 언어입니다. 스크립트 언어는 장기적인 면에서 다른 로우 레벨 언어보다 퍼포먼스가 떨어지는 경향이 있습니다. 하지만 시제품 제작이나 최소 기능 제품(MVP)을 개발하기 위해서, 그리고 판매할 때까지 걸리는 시간(TTM)에 중점을 둔다면, GDScript는 게임을 개발하는데 빠르고, 친절하고, 유능한 방법을 제공할 것입니다.

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

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

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

GDScript는 Godot에 통합된 스크립트 언어입니다. 이것은 초심자와 전문 개발자가 동등하게 Godot의 강점을 가능한 빨리 활용할 수 있도록, 짧은 코드로도 Godot의 잠재력을 극대화할 수 있도록 바닥부터 지어졌습니다. 이전에 Python 비슷한 언어를 사용해 보신 적이 있다면 익숙할 것입니다. 예제, 역사, 그리고 GDScript가 가진 힘의 전체 개요는 GDScript 스크립팅 가이드를 참고하세요.

There are several reasons to use GDScript--especially when you are prototyping, in alpha/beta stages of your project, or are not creating the next AAA title--but the most salient reason is the overall reduction of complexity.

Godot를 위한 맞춤 스크립트 언어를 만들게 된 원래 의도는 두 가지 입니다: 먼저 Godot를 켜고 실행하는 많은 시간을 줄입니다. 개발자는 생산성에 중점을 두고 엔진에 빠르게 접근할 수 있습니다; 두 번째로 전반적인 유지 보수의 부담을 줄여줍니다. 문제의 어려움을 줄이고 엔진 개발자는 엔진 핵심 버그를 없애고 기능을 개선하는데 집중할 수 있습니다--많은 언어에서 작동하는 자잘한 기능들을 얻으려고 많은 시간을 소모하는 일이 없게 됩니다.

Godot가 오픈 소스 프로젝트가 되면서 부터, 처음부터 더 통합되고 완벽한 경험까지 우선 순위를 정했을 때, 추가 사용자 유치를 위한 더 친근한 프로그래밍 언어를 지원하는 것이 최우선이었습니다--특히 더 친근한 언어를 지원하는 것이 더 나쁜 결과로 이어질 때 그랬습니다. Godot에서 다른 언어를 사용하는 것을 이해합니다 (아래에 지원하는 옵션을 참고하세요). GDScript를 사용하지 않아봤다면, 3 일 동안 한번 사용해보세요. Godot처럼 GDScript가 강력하고 개발하는 것을 빠르게 하는 것을 보게 된다면, 우리는 GDScript가 성장할 것이라고 생각합니다.

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

GDScript를 제작하게 된 동기가 무엇입니까?

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

Godot를 위한 맞춤 스크립트 언어를 개발하게 된 주요 이유는 이러합니다:

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

  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는 Collada를 지원하기 때문에 Maya나 3DS Max를 사용한다면 가장 호환성이 좋은 OpenCollada 내보내기 도구를 살펴보세요. Blender를 사용한다면 우리가 만든 Better Collada Exporter 를 살펴보세요.

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

FBX는 Open Asset Import 라이브러리를 통해 지원됩니다. 하지만 FBX는 독점이므로 워크플로우에 적합한 경우, 위에 나열된 다른 형식을 사용하는 것을 권장합니다.

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

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

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

선택한 SDK에 대한 지원이 어떻게 제공되는지 알아보려면 아래 플러그인 질문을 참고하세요.

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

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

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

Godot는 렌더러 작업하는 사람이 적기 때문에, 유지 관리 할 렌더링 백엔드가 더 적은 것을 선호합니다. 또한 모든 플랫폼에서 단일 API를 사용하면서 플랫폼 별 문제를 줄이고 일관성을 높입니다.

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

왜 Godot은 주요 특징을 작게 유지하려고 하나요?

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

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

  • ** 코드 유지 보수 와 버그 관리** 매번 우리가 Godot 리포지터리(repository)에 새로운 코드를 받을 때마다, 그 코드의 contributors(기여자/참여자)는 종종 이것을 유지하는 책임을 집니다. 어떤 contributors은 그들이 제출한 코드가 merge된 뒤에는 계속 관심을 두지 않습니다. 그래서 이러한 경우 문제 있는 코드를 유지하는 것이 어려워 집니다. 이러한 상황은 기능들이 제대로 보수되지 않고 버그투성이인 상태로 남게 됩니다. 결국, 회귀를 위해 테스트하고 검사해야 하는 "API surface"는 시간이 흐름에 따라 계속 증가합니다.

  • 쉬운 기여하기. 코드베이스를 작고 깨끗하게 유지함으로써, 전체 소스를 컴파일하는 것이 빠르고 쉽게 유지될 것입니다. 이것은 새로운 기여자들이 비싼 하드웨어없이도 Godot을 시작하기 쉽게 만들 것입니다.

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

  • 템플릿 내보내기를 위한 바이너리 크기를 작게하기. 이것은 Godot에서 내보낸 프로젝트 크기에 영향을 끼칩니다. 모바일이나 웹 환경에서는, 파일 크기를 최소화하는 것이 성능이 낮은 기계에서 빠른 설치와 로딩에 도움을 줍니다. 다시 말하자면, 지구 상에는 고속 인터넷이 불가능한 나라가 아직 많습니다. 추가로, 이런 나라들에서는 데이터 사용량을 제한하는 것도 효과가 있습니다.

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

다양한 해상도와 화면 비율에 맞는 에셋을 어떻게 만듭니까?

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

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

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

  2. Godot에서 Stretch 설정을 사용해보세요; 화면 비율을 유지하는 2D Stretch가 좋습니다. 사용하는 방법은 Multiple resolutions 튜토리얼에서 확인해보세요.

  3. 최소 해상도를 선택한 다음, 게임의 화면을 다른 화면 비율에 맞게 수직이나 수평으로 펼칠 수 있습니다. 아니면 화면 비율을 유지하는 대신 검은 여백이 나타나게 할 수 있습니다. 이 또한 Multiple resolutions에서 설명합니다.

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

다 됐습니다! 여러분의 게임은 다양한 해상도에서 작동 할 것입니다.

(가로 300화소도 안되는) 오래된 기기의 작은 화면에서도 게임이 작동하기를 정말 원한다면, 내보내기 설정으로 이미지를 압축해서 앱 스토어나 구글 플레이에 적합한 화면으로 만들 수 있습니다.

Godot의 기능확장을 어떻게 합니까?

Godot 편집기 플러그인 제작이나 추가적인 언어 지원을 하고 싶다면 편집기 플러그인과 tool 스크립트를 참고하세요.

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

GDScript 구현, Godot 모듈, Godot을 위한 비공식 Python 지원 을 살펴볼 수도 있습니다. 이것이 Godot과 어떻게 제 3자 라이브러리와 통합하는 지를 보여주는 좋은 출발점이 될 것입니다.

Godot의 다음 릴리스는 언제입니까?

준비가 되었다면, 자세한 설명을 위해 편집기에서 코드 실행하기 를 참고하세요.

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

좋습니다! 오픈 소스 프로젝트인 만큼 Godot은 당신같이 혁신적이고 야심 찬 개발자들에 의해 번창합니다.

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

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

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

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

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

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

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

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

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

그러니 Godot이 여러분의 생각을 달갑게 여기지 않는다고 생각하진 마세요. 다만 개발자와 커뮤니티가 생각을 바탕으로 기술적 토대를 마련하기 위해, 먼저 문제점 순으로 재구성해주세요.

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

스크린샷이나, 구체적인 값, 실험 사례, (가능하다면) 예제 프로젝트를 가져오면 추가 점수가 될 것입니다.

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

예! Godot는 광범위한 내장 UI 시스템을 특징으로하며 작은 배포 크기로 인해 Electron 또는 Qt와 같은 프레임 워크에 적합한 대안이 될 수 있습니다.

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

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

Godot으로 만든 오픈소스 예제 어플리케이션으로 Material MakerPixelorama 를 참고하세요.

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으로 비게임 어플리케이션을 만들 수는 있습니다.

Why does Godot not use STL (Standard Template Library)?

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

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

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

  • 컨테이너는 메모리 추적 기능이 내장되어 있어서, 메모리 사용량을 추적하는데 더 도움이 됩니다.

  • 큰 배열의 경우, 풀(Pool)로 된 메모리를 사용합니다, 사전에 지정된 버퍼 메모리 혹은 가상 메모리에 매핑될 수 있습니다.

  • STL에서 제공하는 문자열 유형은 너무 단순하고 현지화 지원 기능이 부족해서 맞춤 문자열 유형을 사용합니다.

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

우리는 게임이 무엇이든 간에 충돌하지 않아야 한다고 생각합니다. 예기치 못한 사태가 벌어지면, Godot은 오류를 작성합니다 (스크립트에서도 추적할 수 있습니다), 그런 다음 가능한 한 정상적으로 복구한 후 계속 진행합니다.

또한 예외는 실행 파일에서 이진 크기를 상당히 늘립니다.

왜 Godot는 런타임 유형 정보(RTTI)를 시행하지 않나요?

Godot은 선택적으로 런타임 유형 정보를 사용하는 자체 유형 캐스팅 시스템을 제공합니다. Godot에서 런타임 유형 정보를 끄게 되면 약간의 성능을 더 소모하지만 상당히 작은 바이너리 크기를 얻을 수 있습니다.

Godot은 왜 DoD(데이터 지향 디자인) 구현을 강제하지 않습니까?

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

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

대부분의 게임에는 필요하지 않을 테지만, Godot은 이런 작업의 대부분의 경우에 도움을 줄 편리한 도우미를 제공합니다.

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

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

Ways to contribute를 참고하세요.

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

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