Collectible Card Game Headquarters

My first "complaint" is that I can't actually tell what the state of the button is after I click on it, since the icon doesn't change and the label still says the same thing. But it looks pretty solid to me. Is Attackers/Blockers the next planned phase for this, once it seems to be working well?

Re: button state, was thinking that myself, just haven't executed yet.

Next planned phase is for artifacts, then other cards that affect the global state, then eventually attacking/blocking. I'm trying to address the situation "why won't this card tap click click click card detail...think...hover...card detail...ohhh".

Looking good. Would still prefer to actually have auras appear on the side of the battlefield of the creature that it's actually enchanting, but this is definitely better than before in my opinion. Thanks!

@Moomarc - I know what you mean, but I'm trying to avoid redoing the whole battlefield - it's looming in the future though needs some work.

====

I just committed what should be a significant performance improvement - all of the in-game (match) calculations were being performed on the EDT, which should be strictly for UI operations. That's now fixed. Please report on results, or if your fingers get burnt because it's TOO FAST.

(actually, I probably broke something...hope not )

Doublestrike wrote:@Moomarc - I know what you mean, but I'm trying to avoid redoing the whole battlefield - it's looming in the future though needs some work.

Isn't there some slightly easier way to do it? Maybe each card has a 'view controller' which essentially sets card ownership for purposes of the view only. So Aura's would, for instance, use

Code: Select all

if (enchantedEntity instanceof Card) {
    enchantedEntity.setViewController(enchantedC.getController);
}

Actually, you wouldn't need to have each card getting a viewController. Wherever it is that checks who the owner is so it knows which side of the battlefield to put things, it just needs to check if the card has a viewController, otherwise use the owner.

I don't mind looking into it (sometime after the RtR release) if you can point me in the right direction.

Actually part of the reason I'm a bit apprehensive is because I have not dug into the battlefield at all. I just used the PlayArea instances that the previous UI used (they aren't so bad, anyway).

Which is to say, can't really steer ya anywhere...only to forge.gui.match.nonsingleton.VField.java which is where it all starts...after that, the dark side clouds my vision, master moomarc.

Hey Doublestrike,

While you were away I upgraded Forge Combat to the modern rules, which means players have to select order of blockers when more than one block happens. If you have a magical list (of not burning yourself out again) maybe you could add Gussying up the GuiAssignDamageFrame to it. I'm not exactly sure why the Images aren't showing up, and there could be some minor improvements to make it feel more like the rest of Forge, or better represent it's data to the user.

Doublestrike wrote:Ok fellas, just pounded out a targeting overlay!

Got most of the rough stuff sorted out and just committed. Right now, it's ONLY FOR ENCHANTMENTS. There's a toggle button in the dock, and a preference setting which remembers the state.

Please report any bugs or performance issues. If it's smooth sailing, I can implement for more stuff pretty easily.

Wow, Nice. What do you think of implementing it as a mouseover instead of a toggle option?

@friarsol - can do.

@xitax - I prefer the toggle myself, but I'm just one voice...if consensus goes to mouseover no worries I'll program it up, easy enough. Other opinions, anyone?

I chose toggle since I'm anticipating a performance issue when all the targeting arcs are running (combat, enchantment, artifact...others?) if there's a token-heavy game. The user may not want arcs taking up processing power. Then, if the b

Doublestrike wrote:@xitax - I prefer the toggle myself, but I'm just one voice...if consensus goes to mouseover no worries I'll program it up, easy enough. Other opinions, anyone?

Mouse over for enchantments and artifacts might be cool depending on the performance hit. I would prefer combat by toggle (and on by default).

I want to make life even more difficult and want the button to cycle through 3 modes: Off, All On, and On-for-card-mouse-is-currently-over. But that's just in my ideal little Utopia.

Doublestrike wrote:@friarsol - can do.

@xitax - I prefer the toggle myself, but I'm just one voice...if consensus goes to mouseover no worries I'll program it up, easy enough. Other opinions, anyone?

I chose toggle since I'm anticipating a performance issue when all the targeting arcs are running (combat, enchantment, artifact...others?) if there's a token-heavy game. The user may not want arcs taking up processing power. Then, if the b

Man, lots of cliffhanger posts lately.

Marc's suggestion has my vote , unless it's an annoying amount of wotk, in which case toggle.

Hellfish wrote:

Doublestrike wrote:Then, if the b...

Man, lots of cliffhanger posts lately.

Marc's suggestion has my vote , unless it's an annoying amount of wotk, in which case toggle.

Haha! Noticed that as well and almost commented the exact same thing (replacing Marc's suggestion with my actual suggestion of course)

Okey doke, can do.

Actually, just had a brain wave - the dock button can toggle through the three options (none, mouseover, permanent). I'll change the tooltip to indicate.

Oh, and one super-amazing-game-changing idea - we should modify th

Doublestrike wrote:Oh, and one super-amazing-game-changing idea - we should modify th

I love it!!