자주 묻는 질문들(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 스크립팅 가이드를 참고하세요.

GDScript를 사용하는 여러 이유가 있습니다--특히 프로토타입을 만드는 경우, 프로젝트의 알파/베타 수준의 스테이지를 만드는 경우에, 혹은 만드는 게임이 AAA급이 아니라면 말이죠--그러나 전체적으로 가장 두드러진 이유는 복잡성 감소입니다

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, JS, AS 등).
  6. 코드 완성, 실시간 편집 등 (이 전부를) 지원하기 위한 코드 편집기 통합이 까다롭습니다. GDScript는 이 부분을 잘 지원합니다.

GDScript was designed to curtail the issues above, and more.

Godot는 무슨 유형의 3D 모델을 지원하나요?

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

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

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

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

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

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

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

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

Why does Godot use Vulkan or OpenGL instead of Direct3D?

Godot aims for cross-platform compatibility and open standards first and foremost. OpenGL and Vulkan are the technologies that are both open and available (nearly) on all platforms. Thanks to this design decision, a project developed with Godot on Windows will run out of the box on Linux, macOS, and more.

Since Godot only has a few people working on its renderer, we would prefer having fewer rendering backends to maintain. On top of that, using a single API on all platforms allows for greater consistency with fewer platform-specific issues.

In the long term, we may develop a Direct3D 12 renderer for Godot (mainly for the Xbox's purposes), but Vulkan and OpenGL will remain the default rendering backends on all platforms, including Windows.

다양한 해상도와 화면 비율에 맞는 에셋을 만드는 방법

이런 고민은 아마도 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 스크립트를 참고하세요.

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

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

When is the next release of Godot out?

When it's ready! See When is the next release out? for more information.

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

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

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

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

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

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

  • 소프트웨어를 사용한 경험과 문제 (우리는 아이디어보다 이것을 개선하는 일을 더 중요하게 여깁니다).
  • 프로젝트에 필요해서 구현하고자 하는 기능.
  • 소프트웨어를 배우면서 이해하기 어려운 개념.
  • 최적화하고 싶은 워크플로 부분.
  • 깔끔한 튜토리얼이 없거나 깔끔하지 않은 문서 부분.

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

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

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

Godot는 라이브러리로서 사용될 수 있을까요?

Godot is meant to be used with its editor. We recommend you give it a try, as it will most likely save you time in the long term. There are no plans to make Godot usable as a library, as it would make the rest of the engine more convoluted and difficult to use for casual users.

If you want to use a rendering library, look into using an established rendering engine instead. Keep in mind rendering engines usually have smaller communities compared to Godot. This will make it more difficult to find answers to your questions.

Godot가 STL (표준 템플릿 라이브러리)을 사용하지 않는 이유

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

  • STL templates create very large symbols, which results in huge debug binaries. We use few templates with very short names instead.
  • Most of our containers cater to special needs, like Vector, which uses copy on write and we use to pass data around, or the RID system, which requires O(1) access time for performance. Likewise, our hash map implementations are designed to integrate seamlessly with internal engine types.
  • Our containers have memory tracking built-in, which helps better track memory usage.
  • 큰 배열의 경우, 풀(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 웹사이트에서 해당 페이지를 참고하세요.