자주 묻는 질문들(FAQ)

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

Godot는 OSI가 인정한 MIT 라이선스로 사용할 수 있는 무료이자 오픈 소스 소프트웨어입니다. "무료 맥주"일 뿐 아니라 "자유 연설" 수준의 자유라는 말입니다.

간단히 말해서:

  • 개인적으로, 비영리로, 사업으로, 그 외 어떤 이유든지 자유롭게 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비트 모두 지원합니다.

또한 Raspberry Pi와 같은 Linux의 ARM 기반 시스템에서도 Godot를 성공적으로 사용했다는 일부 사용자들의 보고가 있습니다.

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

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

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

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

대개 Godot 개발이나 게임 개발을 목적으로 엔진을 켜게 된다면, Godot에 네이티브로 동작하는 GDScript를 배우고 사용하는데 추천하는 언어입니다. 스크립트 언어는 장기적인 면에서 다른 로우 레벨 언어보다 퍼포먼스가 떨어지는 경향이 있지만, 프로토타입이나 소규모 제품을 제작하거나 개발 시간에 중점을 둔다면, 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를 제작하게 된 동기가 무엇입니까?

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는 위와 같은 문제들을 줄이고자 설계되었습니다.

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

Godot는 OpenCollada 내보내기를 통해 Collada를 지원합니다 (Maya, 3DSMax).

Blender를 사용한다면 Better Collada Exporter를 참고하세요.

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

FBX SDK는 제한적인 라이센스를 갖고 있기 때문에, Godot의 오픈 라이선스와 맞지 않습니다. 즉, FBX 지원은 아직 제 3자의 플러그인으로만 사용할 수 있습니다. (아래의 플러그인 질문을 참고하세요.)

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

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

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

선택한 SDK를 지원하도록 하는지 알아보려면 아래 플러그인 질문을 참고하세요.

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

다양한 해상도와 화면 비율에 맞도록 하려면 어떻게 애셋을 만들어야 할까요?

이 질문은 자주 나타났습니다. 다행이라면 Apple이 기기의 해상도를 원래 두 배로 했기 때문에 나온 오해에서 비롯되었습니다. 이 때문에 사람들이 같은 애셋을 다른 해상도로 만드는 것이 좋은 생각으로 여기고, 많은 사람들이 그렇게 했습니다. 이 작업은 원래 Apple 기기에 초점을 맞췄습니다. 하지만 다양한 해상도와 화면 비율을 가진 여러 Android와 Apple 기기가 만들어졌습니다. 그들은 매우 넓은 화면과 DPI를 갖고 있었죠.

가장 일반적이고 적합한 방법은 게임을 위한 하나의 기본 해상도를 사용하고 가로 세로 비율 만을 다르게 하는 것입니다. 2D라면 이 작업이 필요하겠지만, 3D에서는 카메라 X시야나 Y시야의 단순한 문제입니다.

  1. 게임을 위한 기본 해상도를 고르세요. 해상도가 2K까지 올라가는 기기나 400p까지 내려가는 기기가 있더라도, 기기 안에 있는 균형 하드웨어 스케일링은 이 점을 성능 비용으로 다루진 않을 것입니다. 대부분의 선택은 1080p (1920x1080)이나 720p (1280x720) 근처입니다. 해상도가 높으면 애셋은 더 커지고 더 많은 메모리를 먹고 더 긴 로딩이 걸릴 것이니 명심하세요.
  2. Godot에서 Stretch 옵션을 사용해보세요; 화면 비율을 유지하는 2D Stretch가 좋습니다. 사용하는 방법은 Multiple resolutions 튜토리얼에서 확인해보세요.
  3. 최소 해상도를 선택한 다음 게임의 화면을 다른 화면 비율에 맞게 수직이나 수평으로 펴낼 수 있습니다. 아니면 화면 비율을 유지하는 대신 검은 여백이 나타나게 할 수 있습니다. 이 또한 Multiple resolutions에서 설명합니다.
  4. 사용자 인터페이스에 대해서는 앵커하기를 사용해서 Control이 이동하거나 정지해야 할 위치를 결정하세요. UI가 더 복잡하다면 Container 사용을 고려해보세요.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • STL 템플릿은 매우 큰 심볼들을 만들고, 그것은 거대한 디버그 바이너리를 초래합니다. 우리는 대신 매우 짧은 이름의 템플릿을 거의 사용하지 않습니다.
  • 우리의 컨테이너 대부분은 이런 특수 목적에 맞춰졌습니다, Vector의 경우는, 가상 메모리 쓰기 시 복사 (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 웹사이트에서 해당 페이지를 참고하세요.