Return to Revisions

You probably are too deep in the code. This is not a particularly complex system when you consider the ordering, or the processing, from what I can see.

I've been trying for days to come up with a better system that gives me the freedom to apply 1-n effects to 1-n targets

OK, assuming that's your main concern...

public class Game
{
    public ArrayList<Card> cardsInPlay;

    public ArrayList<Card> GetCardsAffectedBy(Effect effect)
    {
        ArrayList<Card> results = new ArrayList<Card>();
        //run some sort of a filter here to know what is affected by what
        //this will be based on your cards'/effects' varying logic
        //and what else is in play, and by whom i.e. which player
        for (Card card : cardsInPlay)
        {
            if (card is pertinent to this effect) //your logic here!
                results.Add(card);
        }
        return results;
    }
}

public class Card
{
    public Game game; //set from Game itself on Card creation

    public void applyEffects
    {
        for (Effect effect : played.effects)
        {
            ArrayList<Card> cardsAffected = game.GetCardsAffectedBy(effect);
            for (Card card : cardsAffected)
            {
                effect.applyTo(card)
            }
            //or apply to players, enemies, allies, whatever.
        }
    }
}
Game.playCard(card); //or whatever, but call card.applyEffects();

Pass in whatever extra paramaters to whichever functions you like, e.g. GetCardsAffectedBy might need ID of player who just played that effect. We might need to keep data in Game itself till the turn resolves, e.g. a list of the effects played so far so we can evaluate order... and so on.

As for...

(single target effects will be the majority)

...Don't concern yourself with that. Loops accommodate one or many, that's all you need to know. Act as though there are always more than one, and the one-card case will be handled by-the-by.

Reporting

While it's important to build a game with logging / reporting in mind, I think you need to stop allowing that aspect from limiting your thinking in regards to making the game work relatively efficiently. Remember, it's not a game if you can't play it, and it's not an efficient, maintainable codebase if you can't tweak it to make things elegant. Really, logging comes as a secondary concern to these aspects, in my opinion at least. In my case I tend to do data driven design with a hierarchical data model and control hierarchy, and I expose all members as public so that any reporting tools can access these down the line (not a fan of shadowing every member with a get/set pair).