How can I design lots of different attack types that can be combined?

Question

I'm making a top down 2D game and I want to have a lot of different attack types. I'd like to make the attacks very flexible and combine-able the way The Binding of Isaac works. Here's a list of all the collectibles in the game. To find a good example, lets look at the Spoon Bender item.

Spoon Bender gives Isaac the ability to shoot homing tears.

If you look at the "synergies" section, you'll see it can be combined with other collectibles for interesting yet intuitive effects. For example, if it combines with The Inner Eye, it "Will enable Isaac to fire multiple homing shots at once". This makes sense, because The Inner Eye

Gives Isaac a triple shot

What's a good architecture to design things like this? Here's a brute force solution:

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

But that will get out of hand very fast. What's a better way to design a system like this?

Answer 1

You totally don't need to hand-code combinations. You can instead focus on the properties that each item gives you. For instance, Item A sets Projectile=Fireball,Targetting=Homing. Item B sets FireMode=ArcShot,Count=3. The ArcShot logic is responsible for sending out Count number of Projectile items in an arc.

These two items can be combined with any other items that modify these (or other) properties freely. If you add a new type of projectile it'll just automatically work with ArcShot, and if you add a new firing mode it'll automatically work with Fireball projectiles. Likewise, Targetting is a property that sets the controller for the projectiles while FireMode creates the projectiles, so they can be easily and trivially combined in any combination as makes sense.

You might also set of property dependencies and such. For instance, ArcShot requires that you have a provider of Projectile (which might just be the default). You might set priorities so that if you have two active items that both provide Projectile the code knows which one to use. Or you can provide UI to let the user select which projectile type to use, or simply require the player to unequip high-priority items he doesn't want, or use the most recent item, etc. You can further allow a system of incompatibilities, e.g. such that two items that both just modify Projectile cannot both be equipped simultaneously.

In general, when possible, prefer any kind of data-driven approach (or declarative) over procedural approaches (the big if-else messes) when it comes to the objects and such in your game. Higher-level generic logic that is configurable by simple data is much preferable over hard-coded lists of special-cased rules.

Answer 2

If you are using an OOP language, this sounds like a good place to employ the Decorator Pattern. When you want to modify how an attack happens just decorate it with the appropriate augmentation.

Crude c++ Example:

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

This method would be best if you have a very large number of attacks and you need to have them all behave in more or less the same way. If you want to substantially change the way the attack happens with the modifier (e.g. new animation with modifier) then this method is not for you.

Answer 3

As a fan of Binding of Isaac, I too have wondered how to go about something like this. The system in the game is robust enough where emergent behaviors come about from the combination of effects (the one that comes to my mind is getting mirror, spoon bender, and some range boosters results in a swirling, homing tear wall around Isaac, Magneto style). The sheer number of them would make an "if" block impractical.

My conclusion is that Isaac and his tears are two entities in the center of a massive Component-Entity Framework. The entities have some basic stats (movespeed, life, range, damage, sprite, etc) and each component would bring along a stat modifier and a verb.

In code, Isaac and his tears would each have a list that would contain things of an interface. Isaac would have a list of things that subscribe to interface IsaacMutator, and his tears tearMutator. IsaacMutator would have functions to modify Isaacs health, speed, range, looks, and some special verb. TearMutator would be similar. Once per game loop, Isaac would loop through all IsaacMutators that it has, and all living tears would too. To go by your English example, it would read like:

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

and so on. Because the types are additive, you can stack and add and remove to your hearts content.

Answer 4

I think your way works best. These sort of items each give a condition, if used together they produce a different condition, then you would effectively need all 3 possible conditions defined.

You could also go about it by creating a new type of definition when both items are present, but this actually adds to the convolution:

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

if spoon bender inner eye then ...