Combat Refactoring

[Marek14]

I've got it working!!!!

I implemented it in the "new" way, and it works like a charm. I've resolved some of the possible issues mentioned by Marek14 (thanks, most of them were indeed an issue) and changed it to use minimum breaking restriction rather than most fulfilling (IMO the comp rules should be updated in that way also), and it seems to work, at least with the stuff I've tested, including Ekundu Cyclops, Viashino Bey, War's Toll, Scarred Puma, Okk. The only thing that really needs to be done is AI, but I'm a complete noob when it comes to the AI code... Maybe I'll just add a safeguard for now, so that the AI always has a legal way of attacking, and other people can optimise that later.

Minimum breaking restriction and most fulfilling are basically equivalent IF the number of restrictions is kept constant -- the problem is that the logic might not feel very intuitive in that case. Minimum breaking is easier to understand correctly.

Did you use the "negative requirement" approach?

[elcnesh]

Huge salute for this! One important bit - how does this all reflect on banding? Banding is possibly the biggest white ability, and probably the biggest ever non-evasion combat ability there's ever been in the game and having it work or grounds to even develop decent AI for it would be huge for getting older sets to play right?

It would be, but as I mentioned I know next-to-nothing about AI programming (be it Forge or otherwise), so I'm afraid I can't do that. What I did was only rules-based, that is, getting Forge to work consistently with the rules. Of course, if someone else is going to make the AI work with my code, they could also do some work on banding, but that's not up to me.

Minimum breaking restriction and most fulfilling are basically equivalent IF the number of restrictions is kept constant -- the problem is that the logic might not feel very intuitive in that case. Minimum breaking is easier to understand correctly.

Did you use the "negative requirement" approach?

IF it is, but that depends on how you read the cards
In the end I didn't use it. I'll reread it to see if it can be an improvement to the current code

[friarsol]

I'm not sure what part of the refactoring caused this, but there's a bug that was added as part of this code (or maybe other similar changes in the last month).

Basically in PhaseHandler.py this block of code exists:

Code: Select all

                case COMBAT_END:
                    // End Combat always happens
                    game.getEndOfCombat().executeUntil();
                    game.getEndOfCombat().executeAt();

                    if (combat != null) {
                        combat.endCombat();
                    }
                    //SDisplayUtil.showTab(EDocID.REPORT_STACK.getDoc());
                    break;


But "combat.endCombat()" seems to clear out attackers and blockers and things like that. But that's completely wrong. Creatures are still attacking and blocking until the Combat Phase ends, and the EndCombat step is part of the Combat Phase. Maybe this was added in an attempt to fix combat icons not being removed, but this is the wrong course of action. If you look later in this file, in "phaseEnd" there's a combat.endCombat() call to handle all of the clear out combatants at the right time.

With this code, the card Desert is completely unplayable, along with other tricks that happen during this step. (Like Reconnaissance)

[elcnesh]

I don't think I edited that part of the code... I only changed the attack declaration, not any other parts of combat.

Edit: isn't the solution as simple as just removing those lines?

[friarsol]

Edit: isn't the solution as simple as just removing those lines?

I tried that last night, but the UI wasn't updating the Icons when combat was actually ending.

Ahh.. it looks like it was actually added by DrDev in r27875, http://svn.slightlymagic.net/websvn/rev ... &peg=27875

Didn't realize there was multiple things happening to Combat at the same time.

[drdev]

Edit: isn't the solution as simple as just removing those lines?

I tried that last night, but the UI wasn't updating the Icons when combat was actually ending.

Ahh.. it looks like it was actually added by DrDev in r27875, http://svn.slightlymagic.net/websvn/rev ... &peg=27875

Didn't realize there was multiple things happening to Combat at the same time.

Yeah, now that you mention I do remember making that change, and it had to do with the combat icons. I'm certainly not attached to my implementation if there's a better one that aligns with the way the combat phase should work rules-wise.

[elcnesh]

Hi everyone,

So I'm nearly there with block refactoring, there's just one part that I can't seem to get a grip on. Maybe someone else has an idea?

When a creature "must be blocked" by anything, I have trouble determining which creature should block it. If I choose a creature right away, it might be the wrong one, ie. one we need for another attacker. I can postpone this choice, but now suppose there's a few of these choices, each featuring a unique set of legal blockers. How can we determine if such a set can still be fulfilled?
Put differently: suppose X has to be blocked, and its legal blockers are A and B. Now Y also has to be blocked, and can be by C and D. All is fine up until this point. Now Z comes along, who can be blocked by B and C. How do we (quickly/efficiently) determine if Z can still be blocked? (Of course, this can become much more complex with many attackers and blockers!)

Other than this, everything is finished

[Marek14]

If you block X by B and Y by C, then the number of broken requirements will stay if we add another blocker or if we switch one blocker to another attacker, so we reach a plateau. So is it necessary to add an operation "switch one blocker while simultaneously adding another"?

Not sure how to resolve this issue. Maybe to try, for each unblocked "must be blocked" creature, to grab a blocker from elsewhere in a way that wouldn't break requirements on the blocking creature, and then see if any broken requirements on the attacking creatures can be satisfied by a "free" blocker?