Система сутності та візуалізація

Гаразд, що я знаю поки; Суб'єкт господарювання містить компонент (сховище даних), який містить схожу інформацію; - Текстура / спрайт - Шейдер - тощо

І тоді у мене є система візуалізації, яка все це малює. Але я не розумію, як має бути спроектований рендер. Чи повинен я мати один компонент для кожного "візуального типу". Один компонент без шейдера, один із шейдером тощо?

Просто потрібен деякий вклад про те, що "правильний спосіб" зробити це. Поради та підводні камені, на які слід стежити.

На це складне питання відповісти, оскільки кожен має власне уявлення про те, як повинна бути структурована система компонентів сутності. Найкраще, що я можу зробити, - поділитися з вами деякими речами, які я вважаю найбільш корисними для мене.

Суб'єкт

Я сприймаю жировий клас до ECS, ймовірно, тому, що вважаю екстремальні методи програмування дуже неефективними (з точки зору продуктивності людини). З цією метою сутність для мене - це абстрактний клас, який успадковується більш спеціалізованими класами. Суб'єкт має ряд віртуальних властивостей та простий прапор, який підказує мені, чи має існувати ця сутність. Отже, стосовно вашого запитання щодо системи візуалізації, це Entityвиглядає так:

public abstract class Entity {
    public bool IsAlive = true;
    public virtual SpatialComponent   Spatial   { get; set; }
    public virtual ImageComponent     Image     { get; set; }
    public virtual AnimationComponent Animation { get; set; }
    public virtual InputComponent     Input     { get; set; }
}

Компоненти

Компоненти "дурні" в тому, що нічого не роблять і не знають . Вони не мають посилань на інші компоненти, і вони, як правило, не мають функцій (я працюю в C #, тому я використовую властивості для обробки геттерів / сеттерів - якщо вони мають функції, вони базуються на пошуку даних, які вони містять).

Системи

Системи менш "дурні", але все ще тупі автомати. Вони не мають контексту загальної системи, не мають посилань на інші системи і не містять даних, крім кількох буферів, які можуть знадобитися для їх індивідуальної обробки. Залежно від системи, вона може мати спеціалізований Update, або Drawметод, або в деяких випадках і те, і інше.

Інтерфейси

Інтерфейси - це ключова структура в моїй системі. Вони використовуються для визначення того, що Systemможе обробляти, а на що Entityздатний. Інтерфейсами, які мають значення для візуалізації, є: IRenderableі IAnimatable.

Інтерфейси просто повідомляють системі, які компоненти доступні. Наприклад, система візуалізації повинна знати поле обмеження сутності та зображення для малювання. У моєму випадку це було б SpatialComponentі те ImageComponent. Так це виглядає приблизно так:

public interface IRenderable {
    SpatialComponent Component { get; }
    ImageComponent   Image     { get; }
}

Система візуалізації

Тож як система візуалізації малює сутність? Насправді це дуже просто, тож я просто покажу тобі збитий клас, щоб дати тобі уявлення:

public class RenderSystem {
    private SpriteBatch batch;
    public RenderSystem(SpriteBatch batch) {
        this.batch = batch;
    }
    public void Draw(List<IRenderable> list) {
        foreach(IRenderable obj in list) {
            this.batch.draw(
                obj.Image.Texture,
                obj.Spatial.Position,
                obj.Image.Source,
                Color.White);
        }
    }
}

Дивлячись на клас, система візуалізації навіть не знає, що Entityтаке. Все, про що вона знає, - IRenderableце просто список їх, щоб скласти.

Як це все працює

Це може допомогти зрозуміти, як я створюю нові ігрові об’єкти та як я їх подаю до систем.

Створення утворень

Усі ігрові об’єкти успадковуються від Entity, а також будь-які застосовні інтерфейси, які описують, що може зробити цей ігровий об’єкт. Приблизно все, що анімоване на екрані, виглядає приблизно так:

public class MyAnimatedWidget : Entity, IRenderable, IAnimatable {}

Годування систем

Я зберігаю перелік усіх сутностей, що існують у ігровому світі, в єдиному списку під назвою List<Entity> gameObjects. Кожен кадр я просіюю цей список і копіюю посилання на об'єкти до додаткових списків на основі типу інтерфейсу, наприклад List<IRenderable> renderableObjects, та List<IAnimatable> animatableObjects. Таким чином, якщо різним системам потрібно обробляти одну і ту ж сутність, вони можуть. Тоді я просто передаю ці списки кожній із систем Updateабо Drawметодів і дозволю системам робити свою роботу.

Анімація

Вам може бути цікаво, як працює система анімації. У моєму випадку ви можете побачити інтерфейс IAnimatable:

public interface IAnimatable {
    public AnimationComponent Animation { get; }
    public ImageComponent Image         { get; set; }
}

Головне, що тут слід помітити, - це ImageComponentаспект IAnimatableінтерфейсу не лише для читання; в ньому є сетер .

Як ви могли здогадатися, компонент анімації просто містить дані про анімацію; перелік кадрів (які є компонентами зображення), поточний кадр, кількість кадрів в секунду, яку потрібно намалювати, минулий час з моменту останнього збільшення кадру та інші параметри.

Анімаційна система використовує перевагу системи візуалізації та взаємозв'язку компонентів зображення. Він просто змінює компонент зображення об'єкта, збільшуючи рамки анімації. Таким чином, анімація виводиться опосередковано системою візуалізації.

Дивіться цю відповідь, щоб побачити, про яку систему я говорю.

Компонент повинен містити дані про те, що намалювати та як намалювати. Система візуалізації візьме ці деталі та намалює сутність у спосіб, визначений компонентом. Тільки якби ви використовували значно різні технології малювання, у вас були б окремі компоненти для окремих стилів.

Основна причина розділення логіки на компоненти полягає в створенні набору даних, які, поєднуючись в об'єкті, створюють корисну поведінку, що використовується багаторазово. Наприклад, розділення об'єкта на PhysicsComponent і RenderComponent має сенс, оскільки, ймовірно, не всі сутності матимуть фізику, а деякі сутності можуть не мати спрайта.

Для того, щоб відповісти на своє запитання, вам потрібно переглянути свою архітектуру та задати собі два питання:

1. Чи має сенс мати шейдер без текстури
2. Чи дозволить відділення шейдера від текстури уникати дублювання коду?

Розбиваючи компонент, важливо задати це питання, якщо відповідь на "так", то, ймовірно, у вас є хороший кандидат для створення двох окремих компонентів, одного з шейдером і одного з текстурою. Відповідь на 2. як правило, так для компонентів, таких як Position, де кілька компонентів можуть використовувати позицію.

Наприклад, і Physics, і Audio можуть використовувати одне і те ж положення, а не обидва компоненти, що зберігають дублюючі позиції, ви перефактуруєте їх в один PositionComponent і вимагаєте, щоб сутності, які використовують PhysicsComponent / AudioComponent, також мали PositionComponent.

Виходячи з інформації, яку ви нам надали, схоже, що ваш RenderComponent є хорошим кандидатом для розколу на TextureComponent і ShaderComponent, оскільки шейдер повністю залежить від текстури та нічого іншого.

Якщо припустити, що ви використовуєте щось подібне до T-Machine: Entity Systems, зразок реалізації RenderComponent & RenderSystem в C ++ виглядатиме приблизно так:

struct RenderComponent {
    Texture* textureData;
    Shader* shaderData;
};

class RenderSystem {
    public:
        RenderSystem(EntityManager& manager) :
            m_manager(manager) {
            // Initialize Window, rendering context, etc...
        }

        void update() {
            // Get all the entities with RenderComponent
            std::vector<RenderComponent>& components = m_manager.getComponents<RenderComponent>();

            for(auto component = components.begin(); entity != components.end(); ++components) {
                // Do something with the texture
                doSomethingWithTexture(component->textureData);

                // Do something with the shader if it's not null
                if(component->shaderData != nullptr) {
                    doSomethingWithShader(component->shaderData);
                }
            }
        }
    private:
        EntityManager& m_manager;
}

Pitfall №1: перероблений код. Подумайте, чи справді вам потрібна кожна річ, яку ви реалізуєте, тому що вам доведеться жити з нею досить довго.

Падіння №2: занадто багато об'єктів. Я б не використовував систему з занадто великою кількістю об'єктів (по одному для кожного типу, підтипу та будь-якого іншого), оскільки це просто ускладнює автоматизовану обробку. На мою думку, набагато приємніше кожен об'єкт контролювати певний набір функцій (на відміну від однієї функції). Наприклад, створення компонентів для кожного біту даних, що входить до візуалізації (компонент текстури, шейдерний компонент) занадто розділений - зазвичай вам все-таки потрібно мати всі ці компоненти разом, чи не згодні ви?

Падіння №3: надто суворий зовнішній контроль. Віддайте перевагу зміні імен на шейдери / текстурні об’єкти, оскільки об’єкти можуть змінюватися за допомогою рендерера / типу текстури / формату шейдера / будь-якого іншого. Імена - це прості ідентифікатори - вирішувати, що робити з них, залежить від рендерінга. Одного разу, можливо, ви хочете мати матеріали замість простих шейдерів (наприклад, додайте шейдери, текстури та режими накладання даних із даних). З текстовим інтерфейсом реалізувати це набагато простіше.

Що стосується візуалізації, то це може бути простий інтерфейс, який створює / знищує / підтримує / надає об'єкти, створені компонентами. Найпримітивнішим його представленням може бути щось подібне:

class Renderer {
    function Draw() { ... }
    function AddSprite( ... ) { ... return sprite; }
    function RemoveSprite( sprite ) { ... }
    ...
};

Це дозволить вам керувати цими об’єктами зі своїх компонентів і тримати їх досить далеко, щоб ви могли їх відтворити будь-яким способом.