Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

자주 묻는 질문들(FAQ)

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

Godot is Free and open source Software available under the OSI-approved MIT license. This means it is free as in "free speech" as well as in "free beer."

간단히 말해서:

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

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

All the contents of this accompanying documentation are published under the permissive Creative Commons Attribution 3.0 (CC BY 3.0) license, with attribution to "Juan Linietsky, Ariel Manzur and the Godot Engine community."

로고와 아이콘은 일반적으로 동일한 크리에이티브 커먼스 라이선스 하에 속합니다. 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 (시험용)

  • Web (experimental)

내보내는 게임:

  • Windows

  • macOS

  • Linux, *BSD

  • Android

  • iOS

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

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

Godot 팀은 콘솔 제조업체의 라이선스 조건으로 인해 오픈 소스 콘솔 내보내기를 제공할 수 없습니다. 그러나 사용하는 엔진과 관계없이 콘솔에서 게임을 출시하는 것은 항상 많은 작업을 필요로 합니다. 이에 대해 더 자세한 내용은 여기에서 확인하실 수 있습니다: Godot의 콘솔 지원.

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

참고

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

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

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

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

Note that C# support is still relatively new, and as such, you may encounter some issues along the way. C# support is also currently missing on the web platform. Our friendly and hard-working development community is always ready to tackle new problems as they arise, but since this is an open source project, we recommend that you first do some due diligence yourself. Searching through discussions on open issues is a great way to start your troubleshooting.

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

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

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

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

The original intent of creating a tightly integrated, custom scripting language for Godot was two-fold: first, it reduces the amount of time necessary to get up and running with Godot, giving developers a rapid way of exposing themselves to the engine with a focus on productivity; second, it reduces the overall burden of maintenance, attenuates the dimensionality of issues, and allows the developers of the engine to focus on squashing bugs and improving features related to the engine core, rather than spending a lot of time trying to get a small set of incremental features working across a large set of languages.

Since Godot is an open source project, it was imperative from the start to prioritize a more integrated and seamless experience over attracting additional users by supporting more familiar programming languages, especially when supporting those more familiar languages would result in a worse experience. We understand if you would rather use another language in Godot (see the list of supported options above). That being said, if you haven't given GDScript a try, try it for three days. Just like Godot, once you see how powerful it is and rapid your development becomes, we think GDScript will grow on you.

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

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

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

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

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

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

  3. Many existing languages have horrible interfaces for binding to C++, resulting in a large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.). We wanted to focus on a great engine, not a great number of integrations.

  4. No native vector types (Vector3, Transform3D, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

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

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

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

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

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

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

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

That said, because Godot is open source and modular, nothing prevents you or anyone else interested in adding those libraries as a module and shipping your game with them, as either open- or closed-source.

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

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

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

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

Also, see the official blog post on GDExtension, a way to develop native extensions for Godot:

You can also take a look at the GDScript implementation, the Godot modules, as well as the Jolt physics engine integration for Godot. This would be a good starting point to see how another third-party library integrates with Godot.

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

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

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

Windows

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

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

  • Move the created shortcut to %APPDATA%\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를 찾을 수 있습니다.

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 실행 파일이 포함된 폴더를 복사하는 경우 설정 파일이 시스템 간에 전달되지 않습니다. 자세한 정보는 :ref:`doc_data_paths`를 참조하세요.

만약 진정한 포터블 동작이 필요한 경우 (예: USB 스틱에서 사용), :ref:`doc_data_paths_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으로 구현할 수 있는 기능들은 의도적으로 포함하지 않습니다. 고급 인공 지능 같은 것이 그 예입니다.

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

  • Code maintenance and surface for bugs. Every time we accept new code in the Godot repository, existing contributors often take the responsibility of maintaining it. Some contributors don't always stick around after getting their code merged, which can make it difficult for us to maintain the code in question. This can lead to poorly maintained features with bugs that are never fixed. On top of that, the "API surface" that needs to be tested and checked for regressions keeps increasing over time.

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

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

  • Keeping the binary size small for export templates. This directly impacts the size of projects exported with Godot. On mobile and web platforms, keeping file sizes low is important to ensure fast installation and loading on underpowered devices. Again, there are many countries where high-speed Internet is not readily available. To add to this, strict data usage caps are often in effect in those countries.

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

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

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

The most common and proper way to achieve this is to, instead, use a single base resolution for the game and only handle different screen aspect ratios. This is mostly needed for 2D, as in 3D, it's just a matter of camera vertical or horizontal FOV.

  1. Choose a single base resolution for your game. Even if there are devices that go up to 1440p and devices that go down to 400p, regular hardware scaling in your device will take care of this at little or no performance cost. The most common choices are either near 1080p (1920x1080) or 720p (1280x720). Keep in mind the higher the resolution, the larger your assets, the more memory they will take and the longer the time it will take for loading.

  2. Use the stretch options in Godot; canvas items stretching while keeping aspect ratios works best. Check the Multiple resolutions tutorial on how to achieve this.

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

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

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

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

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

Which Godot version should I use for a new project?

새 프로젝트에는 Godot 4.x를 사용하는 것이 좋지만, 필요한 기능 세트에 따라 3.x를 사용하는 것이 더 나을 수도 있습니다. 자세한 내용은 :ref:`doc_release_policy_should_i_upgrade_my_project`를 참조하세요.

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

일부 새 버전은 다른 버전보다 업그레이드하는 것이 더 안전합니다. 일반적으로 업그레이드 여부는 프로젝트의 상황에 따라 달라집니다. 자세한 내용은 :ref:`doc_release_policy_should_i_upgrade_my_project`를 참조하세요.

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

Awesome! As an open source project, Godot thrives off of the innovation and the ambition of developers like you.

Godot에 기여를 시작하는 가장 좋은 방법은 Godot을 사용하면서 발생하는 `문제 <https://github.com/godotengine/godot/issues>`_를 보고하는 것입니다. 명확한 재현 단계가 포함된 좋은 버그 리포트는 기여자들이 버그를 빠르고 효율적으로 수정하는 데 도움이 됩니다. 또한 `온라인 문서 <https://github.com/godotengine/godot-docs/issues>`_에서 발견한 문제를 보고할 수도 있습니다.

If you feel ready to submit your first PR, pick any issue that resonates with you from one of the links above and try your hand at fixing it. You will need to learn how to compile the engine from sources, or how to build the documentation. You also need to get familiar with Git, a version control system that Godot developers use.

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

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

We are always looking for suggestions about how to improve the engine. User feedback is the main driving force behind our decision-making process, and limitations that you might face while working on your project are a great data point for us when considering engine enhancements.

If you experience a usability problem or are missing a feature in the current version of Godot, start by discussing it with our community. There may be other, perhaps better, ways to achieve the desired result that community members could suggest. And you can learn if other users experience the same issue, and figure out a good solution together.

If you come up with a well-defined idea for the engine, feel free to open a proposal issue. Try to be specific and concrete while describing your problem and your proposed solution — only actionable proposals can be considered. It is not required, but if you want to implement it yourself, that's always appreciated!

If you only have a general idea without specific details, you can open a proposal discussion. These can be anything you want, and allow for a free-form discussion in search of a solution. Once you find one, a proposal issue can be opened.

Please, read the readme document before creating a proposal to learn more about the process.

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

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

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

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

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

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

  • Godot는 모든 PC 플랫폼, 모든 모바일 플랫폼, 여러 콘솔, WebAssembly 등 12개의 다양한 플랫폼에서 컴파일할 수 있습니다.

  • 개발자는 여러 플랫폼을 동시에 컴파일해야 하거나, 심지어 같은 플랫폼의 다른 타깃을 컴파일해야 하는 경우가 많습니다. 매번 프로젝트를 재구성하고 다시 빌드할 여유가 없습니다. SCon을 사용하면 빌드를 중단하지 않고도 이 작업을 손쉽게 수행할 수 있습니다.

  • SCon은 아무리 많은 변경, 구성, 추가, 제거 등을 해도 빌드를 절대 깨뜨리지 않습니다.

  • Godot의 빌드 프로세스는 간단하지 않습니다. 여러 파일이 코드(바인더)로 생성되고, 다른 파일은 파싱(셰이더)되며, 다른 파일은 커스터마이징을 제공해야 합니다(modules). 이를 위해서는 복잡한 로직이 필요한데, 대부분 빌드 전용 매크로 기반 언어를 사용하는 것보다 실제 프로그래밍 언어(예: Python)로 작성하는 것이 더 쉽습니다.

  • Godot's build process makes heavy use of cross-compiling tools. Each platform has a specific detection process, and all these must be handled as specific cases with special code written for each.

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

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는 (스크립트에서 추적할 수 있는) 오류를 작성한 다음, 가능한 한 정상적으로 게임을 복구한 후 계속 진행합니다.

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

왜 고도는 ECS (Entity Component System)를 사용하나요?

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

That said, nothing prevents you from making use of composition in your project by creating child Nodes with individual scripts. These nodes can then be added and removed at run-time to dynamically add and remove behaviors.

More information about Godot's design choices can be found in this article.

Why does Godot not force users to implement DOD (Data-Oriented Design)?

While Godot internally attempts to use cache coherency as much as possible, we believe users don't need to be forced to use DOD practices.

DOD is mostly a cache coherency optimization that can only provide significant performance improvements when dealing with dozens of thousands of objects which are processed every frame with little modification. That is, if you are moving a few hundred sprites or enemies per frame, DOD won't result in a meaningful improvement in performance. In such a case, you should consider a different approach to optimization.

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

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

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

Ways to contribute를 참고하세요.

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

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