Come posso progettare molti diversi tipi di attacco che possono essere combinati?

Sto realizzando un gioco 2D dall'alto verso il basso e voglio avere molti tipi di attacco diversi. Vorrei rendere gli attacchi molto flessibili e combinabili come funziona The Binding of Isaac. Ecco un elenco di tutti gli oggetti da collezione nel gioco . Per trovare un buon esempio, diamo un'occhiata all'elemento Spoon Bender .

Spoon Bender dà a Isaac la possibilità di sparare lacrime di ritorno.

Se guardi la sezione "sinergie", vedrai che può essere combinato con altri oggetti da collezione per effetti interessanti ma intuitivi. Ad esempio, se si combina con The Inner Eye , "Permetterà a Isaac di sparare più colpi di homing contemporaneamente". Questo ha senso, perché The Inner Eye

Dà a Isaac un triplo tiro

Qual è una buona architettura per progettare cose come questa? Ecco una soluzione di forza bruta:

if not spoon bender and not the inner eye then ...
if spoon bender and not the inner eye then ...
if not spoon bender and the inner eye then ...
if spoon bender and the inner eye then ...

Ma questo sfuggirà di mano molto velocemente. Qual è il modo migliore per progettare un sistema come questo?

Non hai assolutamente bisogno di codificare manualmente le combinazioni. Puoi invece concentrarti sulle proprietà che ti dà ogni elemento. Ad esempio, l' articolo A imposta Projectile=Fireball,Targetting=Homing. Voce B set FireMode=ArcShot,Count=3. La ArcShotlogica è responsabile dell'invioCount numero di Projectileelementi in un arco.

Questi due elementi possono essere combinati con qualsiasi altro oggetto che modifica liberamente queste (o altre) proprietà. Se aggiungi un nuovo tipo di proiettile, funzionerà solo automaticamente ArcShote, se aggiungi una nuova modalità di fuoco, funzionerà automaticamente con i Fireballproiettili. Allo stesso modo,Targetting è una proprietà che imposta il controller per i proiettili mentre FireModecrea i proiettili, in modo che possano essere facilmente e banalmente combinati in qualsiasi combinazione, secondo il senso.

È inoltre possibile impostare dipendenze di proprietà e simili. Ad esempio, ArcShotrichiede di avere un provider di Projectile(che potrebbe essere solo il valore predefinito). È possibile impostare le priorità in modo che se si hanno due elementi attivi che entrambi fornisconoProjectile il codice sappiano quale utilizzare. Oppure puoi fornire l'interfaccia utente per consentire all'utente di selezionare il tipo di proiettile da utilizzare, o semplicemente richiedere al giocatore di annullare la divisione di oggetti ad alta priorità che non desidera, oppure utilizzare l'elemento più recente, ecc. Puoi inoltre consentire un sistema di incompatibilità , ad esempio in modo tale che due elementi che entrambi modificano Projectilenon possano essere equipaggiati contemporaneamente.

In generale, quando possibile, preferisci qualsiasi tipo di approccio basato sui dati (o dichiarativo ) rispetto agli approcci procedurali (i grossi pastelli if-else) quando si tratta di oggetti e simili nel tuo gioco. La logica generica di livello superiore configurabile da dati semplici è molto preferibile rispetto a elenchi codificati di regole con casing speciale.

Se stai usando un linguaggio OOP, questo suona come un buon posto per utilizzare il modello Decoratore . Quando si desidera modificare il modo in cui si verifica un attacco, è sufficiente decorarlo con l'appropriato potenziamento.

Esempio di c ++ grezzo:

class AttackBehaviour
{
    /* other code */
    virtual void Attack(double angle);
};

class TearAttack: public AttackBehaviour
{
    /* other code */
    void Attack(double angle);
};

class TripleAttack: public AttackBehaviour
{
    /* other code */
    AttackBehaviour* baseAttackBehaviour;
    void Attack(double angle);
};

void TripleAttack::Attack(angle)
{
    baseAttackBehaviour->Attack(angle-30);
    baseAttackBehaviour->Attack(angle);
    baseAttackBehaviour->Attack(angle+30);
}

Questo metodo sarebbe il migliore se hai un numero molto elevato di attacchi e devi farli comportare tutti più o meno allo stesso modo. Se vuoi cambiare sostanzialmente il modo in cui l'attacco si verifica con il modificatore (ad es. Nuova animazione con modificatore), questo metodo non fa per te.

Come fan di Binding of Isaac, anch'io mi sono chiesto come affrontare qualcosa del genere. Il sistema nel gioco è abbastanza robusto in cui i comportamenti emergenti derivano dalla combinazione di effetti (quello che mi viene in mente è ottenere specchio, piegatore a cucchiaio e alcuni amplificatori di portata si traducono in una parete lacrimante vorticosa e homing attorno a Isaac, in stile Magneto ). Il solo numero di questi renderebbe impraticabile un blocco "if".

La mia conclusione è che Isaac e le sue lacrime sono due entità al centro di un imponente Componente-Entità Quadro . Le entità hanno alcune statistiche di base (velocità di spostamento, vita, distanza, danno, sprite, ecc.) E ogni componente porterebbe un modificatore di stat e un verbo.

Nel codice, Isaac e le sue lacrime avrebbero ciascuna un elenco che conterrebbe elementi di un'interfaccia. Isaac avrebbe un elenco di cose che si abbonano all'interfaccia di IsaacMutator e le sue lacrimeMutator. IsaacMutator avrebbe funzioni per modificare la salute, la velocità, la portata, gli sguardi di Isaac e alcuni verbi speciali. TearMutator sarebbe simile. Una volta per ciclo di gioco, Isaac passava attraverso tutti gli IsaacMutator che ha, e anche tutte le lacrime viventi. Per andare dal tuo esempio inglese, si legge come:

Isaac has IsaacMutators:
--spoonbender which gives no stat change and: Tears are made homing
--MeatEater which give +1 health, +1 damage and: nothing
--MagicMirror which gives no stat change and: Tears are made reflecting

Tears have tearMutators:
--(depends on MeatEater) +1 damage and: nothing
--(depends on MagicMirror) no stat change and: +1 vector towards isaac
--(depnds on spoonbender) no stat change and: +1 vector towards enemytype

e così via. Poiché i tipi sono additivi, puoi impilare, aggiungere e rimuovere il contenuto del tuo cuore.

Penso che la tua strada funzioni meglio. Ciascuno di questi elementi dà una condizione, se usati insieme producono una condizione diversa, allora avresti effettivamente bisogno di definire tutte e 3 le possibili condizioni.

Potresti anche aggirare il problema creando un nuovo tipo di definizione quando sono presenti entrambi gli elementi, ma questo in realtà si aggiunge alla convoluzione:

if spoon bender and the inner eye then new spoon bender inner eye

if spoon bender inner eye then ...