Quale tecnica dovrei usare per facilitare la comunicazione tra XNA GameComponents (o tra componenti di qualsiasi tipo in un gioco)?

Sto iniziando il mio primo progetto di gioco "corretto" e ho inevitabilmente colpito un blocco cercando di decidere come comunicare i componenti di gioco in XNA.

Dai precedenti eventi di programmazione della GUI (Java), i gestori e gli ascoltatori sembravano la strada da percorrere. Quindi avrei una specie di bus per eventi che accetta le iscrizioni agli eventi e le classi iscritte a quegli eventi, con gestori che li gestiscono. Ad esempio (pseudocodice):

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

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

Tuttavia, non sono sicuro dell'impostazione del codice (in C #) che sarebbe necessaria per ottenere questo risultato. Cosa tiene traccia degli eventi (una specie di autobus?) E come è strutturato?

Sui Servizi di gioco sembra anche essere molto menzionato, per cui puoi registrare un GameComponent nella tua classe Game.cs principale, quindi recuperarlo da qualsiasi parte del codice che abbia un riferimento all'oggetto principale "Game". L'ho provato con il mio oggetto SpriteBatch e sembra molto semplice .. tuttavia, non riesco a vedere che sia flessibile come un modello di eventi.

Prendi ad esempio quando un nemico muore. Vogliamo aggiornare il punteggio del gioco. Usando i servizi posso ottenere un riferimento al mio oggetto StateManager creato in Game1 e aggiunto come servizio, quindi impostare 'punteggio' sul nuovo valore. Pensavo che un evento "onEnemyDeath", che può essere gestito in modo diverso da una moltitudine di classi, ma avviato da 1 riga di codice nella relativa sezione "Rilevazione della morte nemica", sarebbe meglio che lanciare individualmente ogni GameComponent richiesto quindi chiamare qualunque sono richiesti metodi.

O queste strategie inferiori sono qualcos'altro?

Mi rendo conto che questa è in parte la mia scarsa conoscenza di C # tanto quanto i paradigmi di comunicazione del gioco, ma mi piacerebbe davvero che questa cosa fondamentale fosse corretta.

Aggiornare

Dopo aver esaminato i Servizi è più dettagliato, ne sono meno convinto: sostanzialmente passa una variabile globale (da quello che ho capito).

Aggiornamento 2

Dopo aver dato un'occhiata a questo tutorial di base sulla gestione degli eventi e testare il codice di esempio, sembra che gli eventi sarebbero una scelta logica per ciò di cui sto discutendo. Ma non posso usarlo molto nei campioni che ho visto. C'è qualche ovvio motivo per cui non si dovrebbe?

Dai precedenti eventi di programmazione della GUI (Java), i gestori e gli ascoltatori sembravano la strada da percorrere. Quindi avrei una specie di bus per eventi che accetta le iscrizioni agli eventi e le classi iscritte a quegli eventi, con gestori che li gestiscono.

Il motivo per cui non troverai molto sugli autobus per eventi in C # è perché non credo che nessuno al di fuori di Java definisca una cosa del genere "autobus", nella mia esperienza. Termini più comuni potrebbero essere coda dei messaggi, gestore eventi, segnali / slot, pubblicazione / iscrizione, ecc.

Non hai bisogno di nessuno di questi per creare un gioco funzionante, ma se questo è il tipo di sistema con cui ti senti a tuo agio, ti sarà utile anche qui. Sfortunatamente nessuno può dirti esattamente come realizzarne uno perché tutti li fanno rotolare in modo leggermente diverso, se addirittura li usano. (Non lo so, per esempio.) Potresti iniziare con un semplice System.Collections.Generic.List<Event>per la coda, con i tuoi vari eventi che sono sottoclassi di Evento e un elenco di abbonati per ciascun tipo di evento. Per ogni evento in coda, ottenere l'elenco degli abbonati e, per ogni abbonato, chiamarlo handle(this_event). Quindi rimuoverlo dalla coda. Ripetere.

Sui Servizi di gioco sembra anche essere molto menzionato, per cui puoi registrare un GameComponent nella tua classe Game.cs principale, quindi recuperarlo da qualsiasi parte del codice che abbia un riferimento all'oggetto principale "Game". L'ho provato con il mio oggetto SpriteBatch e sembra molto semplice .. tuttavia, non riesco a vedere che sia flessibile come un modello di eventi.

Probabilmente non è così flessibile, ma è più facile eseguire il debug. Eventi e messaggi sono complicati perché disaccoppiano la funzione di chiamata dalla funzione chiamata, il che significa che le tue pile di chiamate non sono estremamente utili durante il debug, azioni intermedie possono causare un guasto che normalmente funziona, le cose possono fallire silenziosamente se non agganciate correttamente , e così via. Il metodo esplicito di "afferrare un componente e chiamare ciò di cui hai bisogno" funziona bene quando si tratta di rilevare errori in anticipo e di avere un codice chiaro ed esplicito. Tende solo a codice strettamente accoppiato e molte dipendenze complesse.

Mi rendo conto che questa è in parte la mia scarsa conoscenza di C # tanto quanto i paradigmi di comunicazione del gioco, ma mi piacerebbe davvero che questa cosa fondamentale fosse corretta.

C # è praticamente un linguaggio identico a Java. Tutto ciò che hai fatto in Java può essere fatto in C #, solo con una sintassi diversa. Se hai problemi a tradurre un concetto, probabilmente è solo perché conosci solo un nome specifico di Java per esso.

Hai provato ad usare semplici eventi statici? Ad esempio, se vuoi che la tua classe di punteggio sappia quando è morto un nemico, faresti qualcosa del genere:

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;
    }
}

Se ti senti a disagio con l'approccio basato sugli eventi, prova Artemis C #, è un framework di Entity System basato su http://t-machine.org/index.php/2007/09/03/entity-systems-are -la-futuro-di-MMOG-sviluppo-parte-1 /

Fonte: https://github.com/thelinuxlich/artemis_CSharp Esempio di gioco: https://github.com/thelinuxlich/starwarrior_CSharp

prova ad usare un aggregatore di eventi come questo