Comment puis-je concevoir de nombreux types d'attaque différents qui peuvent être combinés?

Je fais un jeu 2D descendant et je veux avoir beaucoup de types d'attaque différents. Je voudrais rendre les attaques très flexibles et combinables comme le fonctionne The Binding of Isaac. Voici une liste de tous les objets de collection du jeu . Pour trouver un bon exemple, regardons l' élément Spoon Bender .

Spoon Bender donne à Isaac la possibilité de tirer des larmes à tête chercheuse.

Si vous regardez la section "synergies", vous verrez qu'elle peut être combinée avec d'autres objets de collection pour des effets intéressants mais intuitifs. Par exemple, s'il se combine avec The Inner Eye , il "permettra à Isaac de tirer plusieurs coups de repérage à la fois". Cela a du sens, car The Inner Eye

Donne à Isaac un triple coup

Quelle est une bonne architecture pour concevoir des choses comme ça? Voici une solution de force brute:

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 ...

Mais cela deviendra incontrôlable très rapidement. Quelle est la meilleure façon de concevoir un système comme celui-ci?

Vous n'avez absolument pas besoin de coder manuellement les combinaisons. Vous pouvez plutôt vous concentrer sur les propriétés que chaque élément vous donne. Par exemple, l' article A définit Projectile=Fireball,Targetting=Homing. Élément B définit FireMode=ArcShot,Count=3. La ArcShotlogique est responsable de l'envoi du Countnombre d' Projectilearticles dans un arc.

Ces deux éléments peuvent être combinés avec tout autre élément qui modifie librement ces propriétés (ou d'autres). Si vous ajoutez un nouveau type de projectile, il fonctionnera automatiquement avec ArcShot, et si vous ajoutez un nouveau mode de tir, il fonctionnera automatiquement avec les Fireballprojectiles. De même, Targettingest une propriété qui définit le contrôleur pour les projectiles tout en FireModecréant les projectiles, afin qu'ils puissent être facilement et trivialement combinés dans n'importe quelle combinaison comme il est logique.

Vous pouvez également définir des dépendances de propriété, etc. Par exemple, ArcShotnécessite que vous ayez un fournisseur de Projectile(qui pourrait être juste la valeur par défaut). Vous pouvez définir des priorités de sorte que si vous avez deux éléments actifs qui fournissent tous les deux Projectilele code, vous savez lequel utiliser. Ou vous pouvez fournir une interface utilisateur pour permettre à l'utilisateur de sélectionner le type de projectile à utiliser, ou simplement demander au joueur d'équiper les éléments de haute priorité dont il ne veut pas, ou d'utiliser l'élément le plus récent, etc. Vous pouvez en outre autoriser un système d'incompatibilités , par exemple de telle sorte que deux éléments qui ne font que les modifier Projectilene peuvent pas être équipés simultanément.

En général, lorsque cela est possible, préférez tout type d' approche basée sur les données (ou déclarative ) aux approches procédurales (les gros gâchis si-sinon) en ce qui concerne les objets et autres dans votre jeu. Une logique générique de niveau supérieur configurable par des données simples est de loin préférable aux listes codées en dur de règles spéciales.

Si vous utilisez un langage POO, cela semble être un bon endroit pour utiliser le motif de décoration . Lorsque vous souhaitez modifier la façon dont une attaque se produit, décorez-la simplement avec l'augmentation appropriée.

Exemple c ++ brut:

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

Cette méthode serait préférable si vous avez un très grand nombre d'attaques et que vous devez toutes les faire se comporter plus ou moins de la même manière. Si vous voulez changer substantiellement la façon dont l'attaque se produit avec le modificateur (par exemple nouvelle animation avec modificateur), cette méthode n'est pas pour vous.

En tant que fan de Binding of Isaac, je me suis aussi demandé comment faire quelque chose comme ça. Le système du jeu est suffisamment robuste pour que les comportements émergents résultent de la combinaison d'effets (celui qui me vient à l'esprit est d'obtenir un miroir, une cuillère à cintrer et certains amplificateurs de gamme entraînent un mur de larmes tourbillonnant et homing autour d'Isaac, style Magneto ). Le nombre considérable d'entre eux rendrait impossible un bloc "si".

Ma conclusion est qu'Isaac et ses larmes sont deux entités au centre d'un cadre de composant-entité massif . Les entités ont des statistiques de base (vitesse de déplacement, durée de vie, portée, dégâts, sprite, etc.) et chaque composant apporterait un modificateur de statistiques et un verbe.

Dans le code, Isaac et ses larmes auraient chacun une liste qui contiendrait des éléments d'une interface. Isaac aurait une liste de choses qui s'abonnent à l'interface IsaacMutator, et ses larmes tearMutator. IsaacMutator aurait des fonctions pour modifier la santé, la vitesse, la portée, l'apparence et certains verbes spéciaux d'Isaac. TearMutator serait similaire. Une fois par boucle de jeu, Isaac parcourrait tous les IsaacMutators qu'il possède, et toutes les larmes vivantes le feraient également. Pour reprendre votre exemple anglais, cela se lirait comme suit:

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

etc. Parce que les types sont additifs, vous pouvez empiler et ajouter et supprimer le contenu de votre cœur.

Je pense que votre chemin fonctionne le mieux. Ces types d'articles donnent chacun une condition, s'ils sont utilisés ensemble, ils produisent une condition différente, alors vous aurez effectivement besoin des 3 conditions possibles définies.

Vous pouvez également vous y prendre en créant un nouveau type de définition lorsque les deux éléments sont présents, mais cela ajoute en fait à la convolution:

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

if spoon bender inner eye then ...