Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Checking the stable version of the documentation...

오토로드 대 일반 노드

Godot는 프로젝트의 루트에 자동으로 노드를 불러오는 기능을 지원해 전역적으로 접근이 가능하도록 합니다. 따라서 싱글톤: 싱글톤 (오토로드)의 목적에 부합합니다. 오토로드된 노드들은 코드에서 SceneTree.change_scene_to_file로 씬을 변경할 때 할당이 해제되지 않습니다.

이 가이드에서는 오토로드 기능을 사용해야 할 때와 이를 사용하지 않기 위한 기법을 배우게 됩니다.

오디오 잘림 문제

다른 엔진에서는 전역으로 접근 가능할 오브젝트에 다양한 기능을 구현한 "관리자" 싱글턴 클래스를 만들어 쓰는 것을 권장할 지도 모릅니다. Godot는 노드 트리와 시그널 덕분에 이러한 전역 상태의 선언을 회피할 수 있는 다양한 방법을 제공합니다.

예를 들어, 플랫포머 게임을 제작하면서 동전을 먹을 때 소리 효과가 나게 하고 싶다고 해 봅시다. 이를 위한 노드가 있습니다: AudioStreamPlayer. 하지만 소리가 재생되고 있는 도중 AudioStreamPlayer를 호출하면, 새로운 소리가 첫 번째 소리가 끝나기 전에 재생됩니다.

해결책은 전역 오토로드된 소리 매니저 클래스를 코딩하 것입니다. 여기에서 AudioStreamPlayer 노드의 풀을 생성해서 새로운 소리 효과가 요청될 때마다 하나씩 순회하도록 하는 것입니다. 이 클래스를 Sound라고 한다면 프로젝트 어디에서든 Sound.play("coin_pickup.ogg")를 호출하여 사용할 수 있습니다. 이렇게 하면 일시적으로 문제가 해결되지만 더 많은 문제가 발생하게 됩니다:

  1. 전역 상태: 한 오브젝트가 이제 모든 오브젝트의 데이터를 담당합니다. Sound 클래스에 오류가 있거나 AudioStreamPlayer를 사용할 수 없다면, 이를 호출하는 노드들 모두가 제대로 동작하지 않을 것입니다.

  2. 전역 접근: 이제 모든 오브젝트가 어디서든 Sound.play(sound_path) 를 호출할 수 있으므로, 버그의 출처를 찾기가 어려워집니다.

  3. 전역 리소스 할당: AudioStreamPlayer 노드 풀을 처음에 생성하기 때문에 너무 적게 생성하면 버그가 발생하고 너무 많이 생성하면 메모리를 비효율적으로 사용하게 됩니다.

참고

전역 접근의 문제점은 어딘가의 어떤 코드든지 예제의 Sound 오토로드에 잘못된 데이터를 전달할 수 있다는 점입니다. 결과적으로 버그를 찾기 위해 프로젝트 전체를 탐색해야 합니다.

코드를 씬 내에 국한시킬 경우, 오디오와 관련된 스크립트는 한 두개 뿐일 것입니다.

이것과 반대로 각 씬이 필요한 만큼의 AudioStreamPlayer 노드를 유지하면 이 문제는 사라집니다:

  1. 각 씬은 자체적인 상태 정보를 관리합니다. 데이터에 문제가 생기면, 해당 데이터가 있는 씬 내에서만 문제를 일으킵니다.

  2. 각 씬은 자기 자신의 노드들에만 접근합니다. 따라서 버그가 일어난다면 어느 노드가 문제인지 특정하기가 쉽습니다.

  3. 각 씬은 자신에게 정확히 필요한 양의 리소스만을 할당합니다.

공유 기능 및 데이터 관리

오토로드를 써야 하는 또 다른 이유는 동일한 메서드나 데이터를 여러 씬에서 재사용하고 싶기 때문입니다.

함수의 경우 GDScript의 class_name <doc_scripting_continued_class_name>`키워드를 사용해 개별 씬에 기능을 지원하도록 새로운 타입의 ``Node` 를 만들 수 있습니다.

데이터의 경우 다음이 가능합니다:

  1. 데이터를 공유하기 위해 새로운 유형의 Resource를 만듭니다.

  2. 예를 들어 씬의 루트 노드에 접근하기 위해 owner 속성을 사용하는 것과 같이 데이터를 각 노드가 접근할 수 있는 오브젝트에 저장합니다.

오토로드를 사용해야 할 때

GDScript는 static func을 통해 static 함수를 만들 수 있습니다. class_name과 같이 활용하면 인스턴스화 하지 않고도 도우미 함수의 라이브러리를 만들 수 있습니다. 정적 함수의 한계점은 멤버 변수와 비정적 함수, 또는 self를 참조할 수 없다는 점입니다.

Godot 4.1부터 GDScript는 static var를 사용하여 static 변수도 지원합니다. 이제 별도의 오토로드를 만들지 않고도 클래스의 인스턴스 간에 변수를 공유할 수 있다는 뜻입니다.

여전히 오토로드된 노드를 사용하면 넓은 범위에서 시스템을 위해 사용되는 코드를 간결하게 유지할 수 있습니다. 오토로드가 스스로의 정보를 관리하고 다른 오브젝트의 데이터를 침범하지 않는 한, 넓은 범위의 작업을 관리하기에는 좋은 방법입니다. 예를 들자면 퀘스트나 대화 상자 시스템의 경우가 있겠습니다.

참고

오토로드가 싱글톤일 필요는 없습니다. 오토로드된 노드의 복사본을 인스턴스화하는데 아무런 제약이 없기 때문입니다. 오토로드는 그저 씬 트리의 루트 노드의 자식으로 노드를 자동으로 불러오는 기능일 뿐입니다. 게임의 노드 구조가 어떤지, 현재 어떤 씬이 실행되고 있는지(예를 들어 F6를 눌렀을 경우처럼)와 관계없이 말입니다.

결과적으로 만약 오토로드의 이름이 Sound라면 get_node("/root/Sound")를 호출해서 오토로드된 노드를 얻을 수 있습니다.