Настройки логики

Вы когда-нибудь задумывались, следует ли подходить к проблеме X со стратегией Y или Z? В этой статье рассматриваются различные темы, связанные с этими дилеммами.

Загрузка и предварительная загрузка

В GDScript существует глобальный метод preload. Он загружает ресурсы как можно раньше, чтобы предварительно загрузить «загрузочные» операции и избежать загрузки ресурсов в середине кода, чувствительного к производительности.

Его аналог, метод load, загружает ресурс только тогда, когда он достигает оператора load. То есть он загрузит ресурс на месте, что может вызвать замедление, когда это произойдет в середине важных процессов. Функция load также является псевдонимом для ResourceLoader.load(path), который доступен для всех языков сценариев.

Итак, когда именно происходит предварительная загрузка во время загрузки и когда следует ее использовать? Посмотрим на пример:

# my_buildings.gd
extends Node

# Note how constant scripts/scenes have a different naming scheme than
# their property variants.

# This value is a constant, so it spawns when the Script object loads.
# The script is preloading the value. The advantage here is that the editor
# can offer autocompletion since it must be a static path.
const BuildingScn = preload("res://building.tscn")

# 1. The script preloads the value, so it will load as a dependency
#    of the 'my_buildings.gd' script file. But, because this is a
#    property rather than a constant, the object won't copy the preloaded
#    PackedScene resource into the property until the script instantiates
#    with .new().
#
# 2. The preloaded value is inaccessible from the Script object alone. As
#    such, preloading the value here actually does not benefit anyone.
#
# 3. Because the user exports the value, if this script stored on
#    a node in a scene file, the scene instantiation code will overwrite the
#    preloaded initial value anyway (wasting it). It's usually better to
#    provide null, empty, or otherwise invalid default values for exports.
#
# 4. It is when one instantiates this script on its own with .new() that
#    one will load "office.tscn" rather than the exported value.
export(PackedScene) var a_building = preload("office.tscn")

# Uh oh! This results in an error!
# One must assign constant values to constants. Because `load` performs a
# runtime lookup by its very nature, one cannot use it to initialize a
# constant.
const OfficeScn = load("res://office.tscn")

# Successfully loads and only when one instantiates the script! Yay!
var office_scn = load("res://office.tscn")
using System;
using Godot;

// C# and other languages have no concept of "preloading".
public class MyBuildings : Node
{
    //This is a read-only field, it can only be assigned when it's declared or during a constructor.
    public readonly PackedScene Building = ResourceLoader.Load<PackedScene>("res://building.tscn");

    public PackedScene ABuilding;

    public override void _Ready()
    {
        // Can assign the value during initialization.
        ABuilding = GD.Load<PackedScene>("res://office.tscn");
    }
}

Предварительная загрузка позволяет сценарию обрабатывать всю загрузку в момент загрузки сценария. Предварительная загрузка полезна, но бывают случаи, когда этого не хочется. Чтобы различать эти ситуации, следует учесть несколько вещей:

  1. Если невозможно определить, когда может загрузиться сценарий, то предварительная загрузка ресурса, особенно сцены или сценария, может привести к дальнейшим загрузкам, которых нельзя было ожидать. Это может привести к непреднамеренной загрузке переменной длины поверх операций загрузки исходного сценария.

  2. Если что-то еще может заменить значение (например, экспортированная инициализация сцены), то предварительная загрузка значения не имеет смысла. Этот момент не является существенным фактором, если кто-то намеревается всегда создавать сценарий самостоятельно.

  3. Если кто-то хочет только «импортировать» ресурс другого класса (сценарий или сцену), то использование предварительно загруженной константы часто является лучшим способом действий. Однако в исключительных случаях я не хочу этого делать:

    1. Если «импортированный» класс может быть изменен, то вместо этого он должен быть свойством, инициализированным либо с помощью «экспорта», либо «загрузки» (и, возможно, даже не инициализированного позже).

    2. Если для сценария требуется очень много зависимостей, и кто-то не желает расходовать так много памяти, то может потребоваться загружать и выгружать различные зависимости во время выполнения по мере изменения обстоятельств. Если предварительно загрузить ресурсы в константы, то единственный способ выгрузить эти ресурсы — это выгрузить весь сценарий. Если вместо этого они загружают свойства, то можно установить для них значение `` null `` и полностью удалить все ссылки на ресурс (что, как расширяющийся тип Reference, приведет к самоудалению ресурсов из памяти).

Крупные уровни: статические и динамические

Если кто-нибудь создает большой уровень, какие обстоятельства являются самыми подходящими? Должны ли они создавать уровень как одно статичное пространство? Или они должны загружать уровень по частям и перемещать содержимое мира по мере необходимости?

Что ж, простой ответ: «когда этого требует производительность». Дилемма, связанная с этими двумя вариантами, является одним из старых вариантов программирования: оптимизировать ли память вместо скорости или наоборот?

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

Несмотря ни на что, нужно разбивать большие сцены на более мелкие (чтобы способствовать повторному использованию ресурсов). Затем разработчики могут проектировать узел, который управляет созданием/загрузкой и удалением/выгрузкой ресурсов и узлов в режиме реального времени. Игры с большими и разнообразными средами или процедурно генерируемыми элементами часто реализуют эти стратегии, чтобы избежать траты памяти.

С другой стороны, кодирование динамической системы является более сложным, т.к. использует больше программируемой логики, которая приводит к возможностям для ошибок и багов. Если кто-то не будет осторожен, они могут разработать систему, которая раздувает технический долг приложения.

Таким образом, лучшими вариантами были бы ...

  1. Использовать статику для небольших игр.

  2. Если у вас есть время / ресурсы для средней / большой игры, создайте библиотеку или плагин, который может кодировать управление узлами и ресурсами. Если со временем доработать, чтобы улучшить удобство использования и стабильность, то он может превратиться в надежный инструмент для всех проектов.

  3. Кодируйте динамическую логику для средней / большой игры, потому что у вас есть навыки кодирования, но нет времени или ресурсов для уточнения кода (игра должна быть завершена). Позже потенциально можно провести рефакторинг, чтобы передать код в плагин.

Примеры различных способов, которыми можно менять местами сцены во время выполнения, можно найти в документации «Изменить сцены вручную».