Collectible Card Game Headquarters

friarsol wrote:I'm not really sure how we should handle the UI for declaring creatures as part of a band. Does anyone have any ideas?

If I remember correctly, I think this is how the old Microprose game did it, and I thought it worked pretty well: If a banding creature has been declared as attacking or blocking (once it has the combat indicator on it) and you select another attacker or blocker, you get prompted whether you want the "new" attacker/blocker to join the band. This would require a check - whenever an attacker / blocker is declared, if a bander has already been declared, then ask.

This strikes me as a little bit like soulbond, actually.

This method could be a pain if you're playing a token / weenie swarm deck. However, in that case, you could just declare the attacker / blocker with banding *last* to avoid getting prompted for each other one.

Another consideration is how this would / should interact with the alpha strike shortcut key. Maybe in that case, assume the bander(s) are declared "last", and don't ask. If I've got 15 potential attackers, one of which has banding, and I want to aplha strike and band one other guy with the bander, I can always press A, then deselect the bander and the one I want joining up, then reselect the bander, then reselect the other guy.

This probably sounds much more complicated than it would be in practice. I use the A key then deselect the creatures I want held back all the time. ("No, Priest of Titania, you're not going over there.")

As for the AI, in worst-case scenario it could ignore banding on its own creatures, and just treat attacking bands as a single attacker with power and toughness equal to the group's total stats, which isn't far off anyway. Teaching the AI not to suicide attack into a banding group may be a whole other kettle of fish...

Zirbert wrote:If I remember correctly, I think this is how the old Microprose game did it, and I thought it worked pretty well: If a banding creature has been declared as attacking or blocking (once it has the combat indicator on it) and you select another attacker or blocker, you get prompted whether you want the "new" attacker/blocker to join the band. This would require a check - whenever an attacker / blocker is declared, if a bander has already been declared, then ask.

This strikes me as a little bit like soulbond, actually.

This method could be a pain if you're playing a token / weenie swarm deck. However, in that case, you could just declare the attacker / blocker with banding *last* to avoid getting prompted for each other one.

Another consideration is how this would / should interact with the alpha strike shortcut key. Maybe in that case, assume the bander(s) are declared "last", and don't ask. If I've got 15 potential attackers, one of which has banding, and I want to aplha strike and band one other guy with the bander, I can always press A, then deselect the bander and the one I want joining up, then reselect the bander, then reselect the other guy.

From what I remember of Shandalar, I believe you had to attack with the banding creatures second to create an attacking band. Basically the game would say "Oh the creature you are attacking with has banding do you want to band it?" Which is basically what Diogenes is saying he'd like to avoid. Yes, Soulbond is basically a cleaned up form of Banding. (Although the reminder text is pretty poor for Soulbond)

There is no such thing as Blocking in a Band.

I'm not going to have any interactions with Alpha Strike and Banding. If things go well, you will be able to assign already attacking creatures into a band.

I'm going to try something that's about halfway what I was thinking and halfway what Diogenes suggests and see how it comes out.

friarsol wrote:
There is no such thing as Blocking in a Band.

Good point - it's been so long since I've seen a bander hit the table that the details got fuzzy. You're absolutely right, there's no need to "declare" blocking in a band. It only matters at damage assignment. As long as at least one creature in a group that's blocking a single attacker has banding, the defender chooses how damage is distributed.

Good luck with banding - I'd love to see it implemented (it should give us quite a few more scriptables), and I'm looking forward to seeing how it comes out!

Ok, I'm committing the first Banding card, along with v 0.8 of Attacking in Bands. I haven't done anything for AI (attacking or blocking) with Banding. But I figured if i do it at the beginning of the cycle we'll at least have time to figure out AI blocking a Band logic.

friarsol wrote:Ok, I'm committing the first Banding card, along with v 0.8 of Attacking in Bands. I haven't done anything for AI (attacking or blocking) with Banding. But I figured if i do it at the beginning of the cycle we'll at least have time to figure out AI blocking a Band logic.

I'll write some scripts for banding cards.

Performing big changes about targeting.
Target class is split into TargetRestrictions and TargetChoices - to separate rules from choices made.

Adding interface ITargetable to make references to SAs, Players and Cards.
I also suspect that it is incorrect to target SAs, instead SpellAbilityStackInstances should be targeted.

Final aim is to implement Spellskite and Redirect with Wild Ricochet

Is that possible to implement targets chosen by a nonactive player？

swordshine wrote:Is that possible to implement targets chosen by a nonactive player？

Cannot say now. My changes are more about compositoin of data in structures.

Spellskite implemented, Redirect added.
M13 is now complete. (Is it the first core set to implement 100% or cards?)

Wild Ricochet is scriptable now.

End of changes about targeting.

Can't be blocked by (keyword) - I want to build description from filter expression.

I think I just figured out Bands with Others. May not be able to post it until next week though.

I have no plans. Waht do you like me to do?

Max mtg wrote:I have no plans. Waht do you like me to do?

You said you were going to implement multiplayer. Please? Pretty please? Pretty please with sugar on top?

Max mtg wrote:I have no plans. Waht do you like me to do?

For a shorter term goal, if you'd like to, maybe you'd like to take a look at improving LKI so that the game can correctly detect and resolve effects that trigger when the card on the battlefield is already dead (as discussed currently in the "Card Contributions" thread)? If you'd like to look into that, I can also join in and assist if any assistance is necessary - I wasn't too lucky with this in the past though, but I can give it another shot, especially if in team with a decent coder such as yourself. Of course, totally up to you, just throwing around ideas.

- Agetian

Ok, my closest plans include abstraction from observers.

Whenever CField calls

Code: Select all

        // Observers
        CField.this.player.getZone(ZoneType.Hand).addObserver(observerZones);
        CField.this.player.getZone(ZoneType.Battlefield).addObserver(observerPlay);
        CField.this.player.addObserver(observerDetails);


It adds a reference to CField.this into Player, a core game class that must not be tied to UI directly.

I want to replace all notifyObservers calls to more specific game events. UI updates shall be triggered by game events delivered by an event bus.
Unlike parameterless notifyObservers calls when observers have to re-read the current player state, these events should contain useful information, so that subscribers would be able to react somehow without querying game for details or perform just partial updates.
For instance, if a card changes zone, the matching event should include the card itself (or its ID for remote observers) and both source and destination zones.

This is needed to make game classes less coupled with UI to allow different types of observers, including remote ones.