Яку техніку я повинен використовувати для полегшення спілкування між XNA GameComponents (або між компонентами будь-якого типу в грі)?

Я починаю свій перший «правильний» ігровий проект, і я неминуче потрапляю на блок, намагаючись вирішити, як ігрові компоненти в XNA повинні спілкуватися.

З попередніх подій програмування (Java) графічного інтерфейсу, обробники та слухачі здавалися дорогою вперед. Тож у мене був би якийсь автобус подій, який приймає реєстрації подій та класи, підписані на ці події, з обробниками, які мають справу з ними. Наприклад (псевдокод):

class SpriteManager
    Update(){
        if(player.collidesWith(enemy)
             // create new 'PlayerCollisionEvent'
    }

class HUDManager
    onPlayerCollisionEvent(){
        // Update the HUD (reduce lives etc)
    }

Однак я не впевнений у налаштуванні коду (на C #), який би знадобився для повного виконання цього завдання. Що відстежує події (якась шина?), І як вона структурована?

Також, мабуть, багато згадується про ігрові сервіси, за допомогою яких ви можете зареєструвати GameComponent в своєму головному класі Game.cs, а потім отримати його з будь-якої точки вашого коду, яка має посилання на головний об’єкт 'Game'. Я спробував це з моїм об'єктом SpriteBatch, і це здається дуже простим .. однак, я не можу бачити, щоб це було настільки гнучко, як модель події.

Візьмемо для прикладу, коли ворог гине. Ми хочемо оновити рахунок гри. Використовуючи сервіси, я можу отримати посилання на мій об’єкт StateManager, створений в Game1 та доданий як послуга, а потім встановити «оцінка» на нове значення. Я б подумав, що подія "onEnemyDeath", яку можна по-різному обробляти безліччю класів, але ініційоване 1 рядком коду у відповідному розділі "Виявлення смерті ворога", було б краще, ніж індивідуальне введення кожного необхідного GameComponent, а потім виклик будь-якого потрібні методи.

Або ці нижчі стратегії чимось іншим?

Я усвідомлюю, що це частково мої слабкі знання на C # стільки, скільки парадигми ігрового спілкування, але я дуже хотів би зрозуміти цю фундаментальну річ.

Оновлення

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

Оновлення 2

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

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

Причина, по якій ви не знайдете багато про автобуси подій у C #, полягає в тому, що, на моєму досвіді, я не думаю, що хтось поза Явою називає таку річ «автобусом». Більш поширеними умовами можуть бути черга повідомлень, менеджер подій, сигнали / слоти, публікація / підписка тощо.

Вам не потрібен жоден із них, щоб зробити робочу гру, але якщо це така система, якою ви зручні, вона вам також добре послужить і тут. На жаль, ніхто не може точно сказати, як їх зробити, тому що всі згортають їх трохи інакше, якщо вони взагалі їх використовують. (Я, наприклад, не.) Ви можете почати з простої System.Collections.Generic.List<Event>для черги, з різних подій, як підкласи подій, і список підписників для кожного типу подій. Для кожної події в черзі отримайте список передплатників, а для кожного абонента телефонуйте handle(this_event)за ним. Потім вийміть її з черги. Повторіть.

Також, мабуть, багато згадується про ігрові сервіси, за допомогою яких ви можете зареєструвати GameComponent в своєму головному класі Game.cs, а потім отримати його з будь-якої точки вашого коду, яка має посилання на головний об’єкт 'Game'. Я спробував це з моїм об'єктом SpriteBatch, і це здається дуже простим .. однак, я не можу бачити, щоб це було настільки гнучко, як модель події.

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

Я усвідомлюю, що це частково мої слабкі знання на C # стільки, скільки парадигми ігрового спілкування, але я дуже хотів би зрозуміти цю фундаментальну річ.

C # майже однакова мова Java. Все, що ви зробили на Java, можна зробити в C #, лише з різним синтаксисом. Якщо у вас виникли проблеми з перекладом поняття, це, мабуть, тільки тому, що ви знаєте лише ім'я, яке стосується Java.

Ви пробували просто використовувати прості статичні події? Наприклад, якби ви хотіли, щоб ваш клас балів знав про те, коли загинув ворог, ви зробите щось подібне:

Score.cs

class Score
{
    public int PlayerScore { get; set; }

    public Score()
    {
        EnemySpaceship.Death += new EventHandler<SpaceshipDeathEventArgs>(Spaceship_Death);
    }

    private void Spaceship_Death(object sender, SpaceshipDeathEventArgs e)
    {
        PlayerScore += e.Points;
    }
}

EnemySpaceship.cs

class EnemySpaceship
{
    public static event EventHandler<SpaceshipDeathEventArgs> Death;

    public void Kill()
    {
        OnDeath();
    }

    protected virtual void OnDeath()
    {
        if (Death != null)
        {
            Death(this, new SpaceshipDeathEventArgs(50));
        }
    }
}

SpaceshipDeathEventArgs.cs

class SpaceshipDeathEventArgs : EventArgs
{
    public int Points { get; private set; }

    internal SpaceshipDeathEventArgs(int points)
    {
        Points = points;
    }
}

Якщо вам неприємно з підходом до подій, спробуйте Artemis C # спробувати, це система Entity System, заснована на http://t-machine.org/index.php/2007/09/03/entity-systems-are -майбутнє-mmog-розвиток-частина-1 /

Джерело: https://github.com/thelinuxlich/artemis_CSharp Приклад гри: https://github.com/thelinuxlich/starwarrior_CSharp

спробуйте використовувати агрегатор подій, як цей