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 предоставляет более лёгкие объекты для создания API, которые используют узлы. Обязательно помните об этом как о вариантах при разработке того, как вы хотите построить функции своего проекта.

  1. Object: максимально лёгкий объект, исходный Object должен использовать ручное управление памятью. С учётом сказанного, нетрудно создать свои собственные структуры данных, даже структуры узлов, которые также легче, чем класс Node.

    • Пример: Смотрите узел Tree. Он поддерживает высокий уровень настройки таблицы содержимого с произвольным количеством строк и столбцов. Данные, которые он использует для создания своей визуализации, на самом деле представляют собой дерево объектов TreeItem.

    • Преимущества: Упрощение API до объектов меньшего масштаба позволяет повысить его доступность и сократить время итерации. Вместо того чтобы работать со всей библиотекой Node, можно создать сокращённый набор объектов, из которых узел может генерировать и управлять соответствующими подузлами.

    Примечание

    С ними нужно быть осторожным. Можно сохранить объект в переменной, но эти ссылки могут стать недействительными без предупреждения. Например, если создатель объекта решит удалить его из ниоткуда, это вызовет состояние ошибки при следующем доступе к нему.

  2. RefCounted: Только немного сложнее, чем Object. Они отслеживают ссылки на себя, удаляя загруженную память только тогда, когда больше не существует ссылок на себя. Они полезны в большинстве случаев, когда нужны данные в пользовательском классе.

    • Пример: См. объект FileAccess. Он функционирует так же, как и обычный объект, за исключением того, что его не нужно удалять самостоятельно.

    • Преимущества: такие же, как и у объекта.

  3. Resource: Лишь немного сложнее, чем RefCounted. Он обладает врожденной способностью сериализовать/десериализовать (т.е. сохранять и загружать) свойства своих объектов в/из файлов ресурсов Godot.

    • Пример: Scripts, PackedScene (для файлов сцены) и другие типы, например каждый из классов AudioEffect. Каждый из них может быть сохранён и загружен, поскольку они расширяют Resource.

    • Преимущества: О преимуществах Ресурса перед традиционными методами хранения данных уже много сказано. Однако при сравнении ресурсов с узлами основным преимуществом ресурсов является совместимости с Инспектором. Будучи почти такими же легковесными, как Object/RefCounted, они все же могут отображать и экспортировать свойства в Инспекторе. Это позволяет им выполнять ту же задачу, что и вложенным узлам, с точки зрения удобства использования, но при этом повышает производительность, если планируется иметь много таких ресурсов/узлов в сцене.