Collectible Card Game Headquarters

Tentative target release date: Friday September 12 2014.

I have developed a bit more the Battlebox variant. Now it 'supports' shared Library. You can check it and try it if you want to include it on a future version.

I Know that changes shouldn't be uploaded like this, but for the first updates, I'd rather prefer to let you know the files modified and what kind of modification has been included. (See the readme file for a more detailed explanation).

To install it simply overwrite the source files where required (or apply the code changes) and rebuild. The decks provided go to a new directory: /decks/battlebox

I hope this may be interesting to you!

FYI, inline with the auto-targeting support I added last release for "target opponent" cards, I decided to also support auto-targeting cards for triggered abilities if there's only one such valid target. The concern we had for spell and activated abilities doesn't apply for triggered abilities, as they occur regardless of user input and you must select the only valid target. So since it's not making a decision for the player, it's safe to auto-select.

An example is playing Shriekmaw onto a battlefield containing only one non-black, non-artifact creature. You have no choice but to select that creature as a target, so we might as well not force the user to click to do so.

Let me know if you have any objections to this.

Alright, since I pretty much have no idea what I'm doing here, I'm going to give you all a patch to try out.

I got really tired of my pain lands stabbing me in the back when I was auto-paying mana and decided to give a fix a shot. I've created a patch that appears to be a little smarter at tapping lands (in short testing, the pain lands will be avoided when possible and will tap for instead).

The attached patch contains this fix and may be able to be included, but I don't want to commit it just yet. It's also not super smart and will only try to use abilities that contain the exact mana cost. I don't expect things like Mana Confluence to be sorted right (but they should work anyway). With any luck, this doesn't have any side effects and can also be used to give AI a few more options in cards.

Test case:
(On your field:) 2 Battlefield Forge, 1 Plains
Attempt to play Preeminent Captain.

Without the patch, Forge will hit you for 2 life. With it, Forge will correctly use the abilities to pay for Preeminent Captain's .

Edit: It seems that this still needs more work. It'll always pay with a card that can produce when paying with another card would leave more options open without any change in result. I'll look at changing this over the next few days to track which cards own which abilities to select the best one.

KrazyTheFox wrote:I got really tired of my pain lands stabbing me in the back when I was auto-paying mana and decided to give a fix a shot.

Yeah this is an important one to fix. It's something that both the AI stabs itself with continuously and something that, like you observed, stabs the player in the back upon pressing "Auto". Good luck on fixing it and thanks for your effort!

- Agetian

Can somebody explain to me the purpose of the Commander Effect token? I'm trying to improve the UI for Commander on the mobile game, and it's taking up unnecessary space. Clicking it seems to do nothing, and it always shows up Black.

I'd like to eliminate it unless there's an important reason it needs to exist.

EDIT: It seems to be implemented as an Emblem that grants the ability to return the Commander to the command zone when it would leave play. Is that right? Is there a reason that couldn't be simply an ability added to the commander itself? That way it would show up on the dialog that appears when you choose whether to put the commander back into the command zone.

drdev wrote:Can somebody explain to me the purpose of the Commander Effect token? I'm trying to improve the UI for Commander on the mobile game, and it's taking up unnecessary space. Clicking it seems to do nothing, and it always shows up Black.

I'd like to eliminate it unless there's an important reason it needs to exist.

EDIT: It seems to be implemented as an Emblem that grants the ability to return the Commander to the command zone when it would leave play. Is that right? Is there a reason that couldn't be simply an ability added to the commander itself? That way it would show up on the dialog that appears when you choose whether to put the commander back into the command zone.

I looked into that back when I started tweaking Forge, but I was never able to figure out the code back then. It does seem like the ability would be the way to go, however. I can't think of any reason off the top of my head why the current way would need to stay.

When Hellfish was implementing Commander there was a handful of different issues that were cropping up due to how he was implementing it. All of these went away when the Commander Effect was introduced:

The conversation starts around viewtopic.php?f=52&t=8895&start=180#p131342

If you can get it to work keeping in consideration the things that were issues, then feel free to convert it to rules code as opposed to a game object.

So after my quick attempt to eliminate the effect failed, I've decided to make it so the effect is simply hidden on the UI but still exists within the game model. I'm also tweaking some other UI logic so that the commander's image and other UI info is used when the effect needs to be displayed (such as in the dialog that appears on the mobile game when applying the replacement effect when it leaves play).

Sound good?

So, as an update, I just committed r27191, which eliminates the black display rectangle for the Commander effect from the UI for both the desktop and mobile games. It also makes it so the replacement effect dialog shows the commander's name (and image in the case of the mobile game), instead of "Commander effect".


Note that the effect is still a separate Card as far as the game logic is concerned, so the only thing I changed is how such an effect is handled by the UI. I also wrote this code to be reusable for other effects that need to be coded like the Commander Effect, which can now use the new DetachedCardEffect class (which derives from Card). Are there any other such effects that should be refactored at this point?

Let me know if you have any questions or concerns about these changes.

Thanks.
-Dan

Looks good, Dan! I think this way of displaying this effect is much better! I have a question though about related functionality and other changes you've made thus far: is the new game mode (Momir) and the new way to display the Command Zone also available in the desktop version or is it only in the mobile version at the moment? (I haven't found the relevant options anywhere at the moment).

- Agetian

Agetian wrote:Looks good, Dan! I think this way of displaying this effect is much better! I have a question though about related functionality and other changes you've made thus far: is the new game mode (Momir) and the new way to display the Command Zone also available in the desktop version or is it only in the mobile version at the moment? (I haven't found the relevant options anywhere at the moment).

- Agetian

Mobile version only at this point. I'm already planning to add Momir Basic to the desktop game (should be really easy at this point other than maybe changing the layout of the checkboxes). As for the Command Zone change, I'm definitely game with making that change for the desktop game too if others are on board. It'd be nice to eliminate the Command Zone tab, which with tabs hidden allows the battlefield to be bigger. As my screenshot shows, I currently have it moved to the right anyway to avoid the need for tabs.

Sounds like a plan. I find this new way of displaying the command zone rather non-obstructive and intuitive. However, I think it's a good idea to either keep the "separate tab" version an option (configurable in the preferences) or at least add some icon-ish way to display the contents of the Command Zone similar to Graveyard, Exile, and other zones for the players who may be willing to distinguish more precisely what is located in this zone once things get crowded on the battlefield (not a very common scenario, but still: let's say it's a Vanguard match and in addition to the avatar there's a lot of CoP and Nafs Asp like effects displayed in the command zone (at least that's where they are displayed at the moment even though I don't think they are a part of the zone according to the rules... or are they? :\ ). Will it still be easy to distinguish what is on the battlefield in each zone if there are also multiple lands and creatures and artifacts and whatnot on the field at the same time?

- Agetian

It might be a lot trickier for the desktop game than the mobile game where everything appears in 2 rows and I just lock the position of the command zone and put a border around it. Perhaps we could make it a modeless dialog that appears in the lower right (or upper right for opponent) by default, but would allow you to move it around. That way we can just display the battlefield as normal and simply allow the user to move the dialog if they want to (they could even move them outside the battlefield). The dialog would also have a titlebar that would say "Command Zone" to make it clear what it is and differentiate it from the cards on the field.

Along those lines, I could look into adding support for floating and docking tabs in general, in case, for instance, you want the stack floating over the top right of the battlefield like it is for the mobile game. I could even make these floating tabs support dynamic size and visibility based on the content so the stack could appear only when it's needed and grow as more stuff is added like the mobile game supports. However, we'd still support docking the stack, command zone, etc. if users wanted, so there would be no loss of the current customization options.

What do you think?

Alright, guys!

I've added in much better code that handles mana abilities. Grab the latest revision and give it a try. The AI now gives cards with mana abilities a score that takes into account card type and the number of types of mana a card can produce (I haven't figured out how to get the quantity of the same mana yet, so that may still not work quite as well as it could).

For example:
On the field: 1 Graypelt Refuge, 1 Elvish Mystic
Cast: Elvish Mystic
Game taps: Elvish Mystic, leaving 2 types of mana open.

On the field: 2 Battlefield Forge, 1 Temple of Triumph, 1 Plains
Cast: Brimaz, King of Oreskos
Game taps: Plains, Temple of Triumph, Battlefield Forge (for ).

In the last example there, even though another Battlefield Forge could be tapped for instead of the Temple of Triumph, it is still given a higher priority to be left untapped since it produces 3 types of mana. I don't know how to easily solve this without being able to query if an ability is beneficial or not, which I don't know how to do (is this even possible?). If that can be done in a simple way, it'd be very easy to add that in to the current algorithm.

Regardless, I think we can all agree that it's at least a bit better than getting hit for 1 when it's not required.