Come posso progettare un efficace schema di interazione di oggetti di gioco con un'architettura basata su componenti?

Questa è una domanda di progettazione ... Sono sicuro che questo potrebbe essere generalizzato di più, ma sto facendo fatica a farlo. Mi chiedo il design per le interazioni con gli oggetti di gioco: ecco il mio esempio (puzzle-platform 2D).

Supponiamo che il giocatore stia provando ad avanzare di livello. Ci sono molte luci che possono essere puntate in diverse direzioni. Ecco un esempio di come questi oggetti luminosi potrebbero interagire ...

• Una luce proietta una piattaforma che consente al giocatore di attraversare un gap
• Una luce riduce i coefficienti di attrito di qualsiasi cosa tocchi, un'altra la aumenta
• Una luce annulla gli effetti di tutte le luci, il che farebbe scomparire la piattaforma mentre quella luce è accesa e annullare i modificatori di attrito
• Eccetera...

Qual è il modo migliore per affrontare questo problema quando si utilizza un'architettura componente? I componenti di ciascun oggetto principale sembrano ovvi, così come un modo pulito per definire i loro effetti sull'ambiente. Una classe per "risolvere" l'interazione (sembra che potrebbe diventare rapidamente un casino)? Qualche utilizzo del motivo decorativo per creare oggetti combinati per coloro che interagiscono in un determinato momento? Una struttura di dati che si presta a questo?

Inoltre, connetti l'audio a queste interazioni? Sembra che collegare l'audio al sistema sarebbe come collegare qualsiasi altra proprietà, come la visibilità o il movimento / collisione del giocatore.

Ovviamente con l'aggiunta di più componenti sarebbe bello se esistesse un sistema robusto in grado di gestire quelli nuovi con poche modifiche, ma non ho familiarità con il modo di progettare questo.

Altre informazioni: Il motore che sto usando è un motore XNA chiamato IceCream .

In un sistema orientato agli oggetti, l'unica vera risposta alla domanda su qual è il modo migliore per fare X è che dovresti semplicemente farlo nel modo più semplice in cui riesci a pensare di far funzionare qualcosa e poi cambiarlo quando un l'espressione più facile diventa evidente. Preoccuparsi di scegliere il modello giusto prima di aver scritto qualsiasi codice è un buon modo di mettersi in sella con la risposta sbagliata sin dall'inizio; lascia che tutti i pensieri su modelli e componenti si dissolvano e segui questi passaggi, iniziando da dove sei oggi (supponendo che tu abbia implementato un componente leggero):

1. Aggiungi il codice al componente luce alle piattaforme di progetto. (Fallo funzionare.)
2. Copia quel componente in un nuovo componente, rimuovi gli elementi della piattaforma e aggiungi il codice per ridurre l'attrito degli oggetti appropriati. (Fallo funzionare, verifica che il numero 1 funzioni ancora.)
3. Copia quel componente in un nuovo componente, rimuovendo il "nuovo" codice e aggiungi elementi per disabilitare gli effetti degli altri componenti. (Fallo funzionare, quindi verifica che il numero 1 e il numero 2 funzionino ancora.)

A questo punto, avrai (probabilmente) un sacco di codice duplicato. Estrai il codice comune in funzioni o in un'altra classe (forse una classe base) o qualunque cosa sembri appropriata. Solo perché hai iniziato con un "componente leggero" non significa che LightComponent sia una base appropriata; potrebbe essere che qualunque codice costituisca il componente luce non sia in realtà un "componente" di per sé e forse sarà meglio rappresentato da un insieme di funzioni o anche da una classe separata che viene aggregata nei nuovi componenti (come variabile membro ).

In termini generali, quando un oggetto di tipo A interagisce con un oggetto di tipo B, si desidera avere un certo effetto C. Questo si chiama "doppio dispacciamento" ed è molto difficile farlo elegantemente in linguaggi simili a C.

Il modo efficace ma difficile da mantenere è solo una serie di istruzioni switch e if, a seconda del tipo di oggetti. Ti sentirai sporco a scriverlo ma riuscirà a fare il lavoro.

Il modello Visitor è una soluzione più robusta che nasconde la commutazione di tipo sgradevole, ma può essere complicata da configurare.

Normalmente qualsiasi tipo di switch di tipo nel tuo codice è un odore, ma qui stai cercando di generalizzare il polimorfismo, che normalmente cambia le funzioni in base a un singolo tipo, per cambiare le funzioni in base a due tipi. Il polimorfismo è un fondamento di OOP, quindi non è un odore.

Fammi vedere. Questo è solo qualcosa che mi sono inventato in testa mentre scrivevo, quindi scusami se mi manca qualcosa.

Ottieni tutti i nodi di luce a una distanza ragionevole dal tuo amico.

Per ogni luce si esegue il rendering di un poligono che rappresenta l'area di effetto di un oggetto framebuffer. Quindi un cono di luce creerebbe un cono di un tipo di pixel nel tuo FBO. Renderizza ogni tipo di nodo in passaggi con priorità appropriata. Potresti codificare le informazioni in ogni pixel come il canale verde potrebbe essere la frizione, il rosso la gravità, il blu e l'alfa essere qualcos'altro.

Le tecniche di fusione dei colori intelligenti potrebbero quindi creare effetti interessanti. Ogni livello può avere le proprie regole di fusione. È inoltre possibile aggiungere l'ombreggiatura dei frammenti per effetti dinamici psichedelici come la gravità pulsante ecc.

Infine, controlla quali pixel tocca il tuo mandude ed esegui il ricalcolo della bitmap ogni volta che ti avvicini ai bordi dell'area precalcolata.

Scetch grezzo fatto in 2 minuti per illustrare la mia idea:

Modifica: in pratica questo significa che l'unica cosa di cui hai bisogno è un componente luminoso che emette un certo colore. Le regole si collegano a quale colore fa ciò che può essere completamente da qualche altra parte. Puoi codificare molti dati nei 32 bit che hai il pixel pr. In alternativa puoi avere più FBO che contengono attributi diversi che non si influenzano a vicenda. Potresti avere un FBO a gravità / attrito e un FBO da collisione a 1 bit. Se lo scegli, dovresti ovviamente contrassegnare in quale FBO deve essere renderizzato la tua luce.

Il modello di osservatore è una delle migliori soluzioni. Il messaggio verrà inviato solo a quegli oggetti (componenti) che sono veramente interessati a esso. Quindi il destinatario deve iscriversi su questo messaggio / tipo di evento.

Esistono molte implementazioni di segnale / slot. Ad esempio, in C ++ c'è una libreria sigslot

Per maggiori informazioni leggi i segnali e gli slot Qt .