Хранение данных в игровых объектах

Question

Я сейчас создаю игру с XNA, и в настоящее время мои компоненты игрового объекта настроены так:

class Character : GameComponent
{
public int health, state;
public float speed;
}

и т.д. После создания системы меню я поиграл с объектами типа контейнера данных, скажем, у меня есть базовый класс DataContainer, а затем подклассы, такие как IntContainer, FloatContainer. В зависимости от своего подкласса они возвращают содержащийся в них тип данных. Я хочу подключить эту систему меню к компонентам, чтобы я мог легко их редактировать, мне интересно, стоит ли мне менять свои компоненты, чтобы также принять эту модель хранения контейнеров общих данных вместо явно типизированных данных, например, так:

class Character : GameComponent
{
public DataContainer[] data;

public int health()
{
return (data[0].getValue());
}
}

Я мог бы сохранить методы с соответствующим именем, как указано выше, поэтому получение значения по имени в коде все равно будет простым. Потребуется немного усилий, чтобы переключить мой движок на этот метод хранения данных, поэтому мне интересно, если у кого-то есть вход, влияет ли более общий метод на производительность каким-либо измеримым образом? Вызов двух методов, чтобы получить значение хуже, чем захват значения напрямую?

Answer 1

Вызов метода всегда будет немного медленнее, чем непосредственное получение поля, но это не будет иметь заметного эффекта, если их не вызывать сотни раз за кадр. (Пример: вы, вероятно, не должны использовать getTile(x, y) в вашем коде рендеринга, код освещения, что бы ни применимо)

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

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

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

Вот пример в вашем случае:

public int Health
{
    get
    {
        return (data[0].getValue());
    }
    set
    {
        data[0].setValue(value);
    }
}

Таким образом, вы можете просто изменить свои поля на свойства, реализуя свою логику. Также обратите внимание, как я уже говорил ранее, как методы вызывают очень и очень небольшое количество времени, которое нужно использовать. Свойства на самом деле являются методами под капотом, поэтому вызов get или set будет таким же, как вызов метода. Это в сочетании с поиском data массив для указанного члена, будет очень быстрым, но не так быстро, как поле. Таким образом, с учетом вышесказанного вы не должны замечать каких-либо задержек, но если игра достаточно большая, их может быть немного (хотя сейчас это не должно вас беспокоить, на самом деле это применимо только в том случае, если вы хотите добавить индексирование на свой тайл). массив или что-то, просто мысль)

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