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の通知

Godotのすべてのオブジェクトは _notification メソッドを実装します。その目的は、オブジェクトがそれに関連する可能性のあるさまざまなエンジンレベルのコールバックに応答できるようにすることです。たとえば、エンジンが CanvasItem に「描画(draw)」するように指示すると、_ notification(NOTIFICATION_DRAW) が呼び出されます。

drawなどのこれらの通知の一部は、スクリプトでオーバーライドするのに役立ちます。Godotは、Godotがそれらの多くを専用関数で公開するほどです:

• _ready() : NOTIFICATION_READY

• _enter_tree() : NOTIFICATION_ENTER_TREE

• _exit_tree() : NOTIFICATION_EXIT_TREE

• _process(delta) : NOTIFICATION_PROCESS

• _physics_process(delta) : NOTIFICATION_PHYSICS_PROCESS

• _draw() : NOTIFICATION_DRAW

ユーザーが気付いていないかもしれないのは、Nodeではないタイプにも通知が存在するということです。たとえば次の例です:

• Object::NOTIFICATION_POSTINITIALIZE: オブジェクトの初期化中にトリガーされるコールバック。スクリプトからアクセスできません。

• Object::NOTIFICATION_PREDELETE: エンジンがオブジェクトを削除する前にトリガーされるコールバック。つまり「デストラクタ」です。

また、ノードに存在するコールバックの多くには専用のメソッドはありませんが、それでも非常に便利です。

• Node::NOTIFICATION_PARENTED: a callback that triggers anytime you add a child node to another node.

• Node::NOTIFICATION_UNPARENTED: a callback that triggers anytime you remove a child node from another node.

The universal _notification() method provides access to all these custom notifications.

注釈

"virtual" というラベルの付いたドキュメント内のメソッドも、スクリプトによってオーバーライドされることを目的としています。

典型的な例は、Objectの _init メソッドです。NOTIFICATION_* に相当するものはありませんが、エンジンはメソッドを呼び出します。ほとんどの言語(C#を除く)は、コンストラクターとして使用します。

So, when should you use each of these notifications or virtual functions?

_process 対 _physics_process 対 *_input

Use _process() when you need a framerate-dependent delta time between frames. If code that updates object data needs to update as often as possible, this is the right place. Recurring logic checks and data caching often execute here, but it comes down to how often the evaluations need to update. If they don't need to execute every frame, then implementing a Timer-timeout loop is another option.

GDScriptC#C++

# Allows for recurring operations that don't trigger script logic
# every frame (or even every fixed frame).
func _ready():
    var timer = Timer.new()
    timer.autostart = true
    timer.wait_time = 0.5
    add_child(timer)
    timer.timeout.connect(func():
        print("This block runs every 0.5 seconds")
    )

Use _physics_process() when you need a framerate-independent delta time between frames. If code needs consistent updates over time, regardless of how fast or slow time advances, this is the right place. Recurring kinematic and object transform operations should execute here.

While it is possible, to achieve the best performance, you should avoid making input checks during these callbacks. _process() and _physics_process() will trigger at every opportunity (they do not "rest" by default). In contrast, *_input() callbacks will trigger only on frames in which the engine has actually detected the input.

You can check for input actions within the input callbacks just the same. If you want to use delta time, you can fetch it from the related delta time methods as needed.

GDScriptC#C++

# Called every frame, even when the engine detects no input.
func _process(delta):
    if Input.is_action_just_pressed("ui_select"):
        print(delta)

# Called during every input event.
func _unhandled_input(event):
    match event.get_class():
        "InputEventKey":
            if Input.is_action_just_pressed("ui_accept"):
                print(get_process_delta_time())

_init 対 初期値 対 エクスポート値

スクリプトがシーンなしで独自のノードサブツリーを初期化する場合、そのコードは _init() で実行する必要があります。その他のプロパティまたは SceneTree に依存しない初期化もここで実行する必要があります。

注釈

C#でGDScriptの _init() メソッドに相当するのは、コンストラクタです。

_init() は _enter_tree() または _ready() の前にトリガーされますが、スクリプトがプロパティを作成して初期化した後にトリガーされます。シーンをインスタンス化するときに、プロパティ値は次の順序に従って設定されます。

1. 初期値のセット: プロパティには初期値がセットされます。指定されていない場合はデフォルト値がセットされます。セッターが存在する場合は使用されません。

2. _init() assignment: the property's value is replaced by any assignments made in _init(), triggering the setter.

3. エクスポートされた値のセット: エクスポートされたプロパティの値は、インスペクターで設定された任意の値に置き換えられ、セッターがトリガーされます。

GDScriptC#C++

# test is initialized to "one", without triggering the setter.
@export var test: String = "one":
    set(value):
        test = value + "!"

func _init():
    # Triggers the setter, changing test's value from "one" to "two!".
    test = "two"

# If you set test to "three" from the Inspector, it would trigger
# the setter, changing test's value from "two!" to "three!".

その結果、スクリプトとシーンのインスタンス化は、初期化とエンジンがセッターを呼び出す回数の両方に影響する可能性があります。

_ready 対 _enter_tree 対 NOTIFICATION_PARENTED

最初に実行されたシーンに接続されたシーンをインスタンス化する場合、Godot はツリーの下のノードをインスタンス化して (_init 呼び出しを行います)、ルートから下に向かってツリーを構築します。これにより _enter_tree 呼び出しがツリーの下に向かってカスケードされます。ツリーが完成すると、リーフ ノードは _ready を呼び出します。すべての子ノードが呼び出しを終えると、ノードはこのメソッドを呼び出します。これによりツリーのルートに戻る逆カスケードが発生します。

スクリプトまたはスタンドアロン シーンをインスタンス化する場合、ノードは作成時にSceneTreeに追加されないため、 _enter_tree() コールバックはトリガーされません。代わりに _init() 呼び出しのみが発生します。シーンが SceneTree に追加されると _enter_tree() および _ready() 呼び出しが発生します。

If you need to trigger behavior that occurs as nodes parent to another, regardless of whether it occurs as part of the main/active scene or not, you can use the PARENTED notification. For example, here is a snippet that connects a node's method to a custom signal on the parent node without failing. Useful on data-centric nodes potentially created at runtime.

GDScriptC#C++

extends Node

var parent_cache

func connection_check():
    return parent_cache.has_user_signal("interacted_with")

func _notification(what):
    match what:
        NOTIFICATION_PARENTED:
            parent_cache = get_parent()
            if connection_check():
                parent_cache.interacted_with.connect(_on_parent_interacted_with)
        NOTIFICATION_UNPARENTED:
            if connection_check():
                parent_cache.interacted_with.disconnect(_on_parent_interacted_with)

func _on_parent_interacted_with():
    print("I'm reacting to my parent's interaction!")