Collectible Card Game Headquarters

Tentative target release date: Friday December 13.

The Auto button for automatically paying mana costs using AI logic is ready to go. In practice, it greatly improves the speed of game play, particularly when playing mono-color decks or playing one spell/ability on a given turn.

That said, there's definitely room for improvement in the AI logic in terms of deciding what mana sources to leave for later when you have more than enough to pay for something. For example, ideally, I think the AI logic should look at all cards in hand and in play to determine what else, if anything, could be played following the current spell/ability, and try to focus on leaving mana sources open for those if possible. Which would mean making this function in PlayerControllerAi use some brains:

Code: Select all

@Override
public Mana chooseManaFromPool(List<Mana> manaChoices) {
    return manaChoices.get(0); // no brains used
}


If you have any feedback from trying out the Auto button, please let me know.

In addition to the Auto button, I also made a couple other usability improvements to game play in terms of skipping unnecessary combat prompts. These changes, along with the Auto button, are described in this excerpt from CHANGES.txt:

- Game usability/speed improvements -
When paying mana costs, you can now press Enter/Spacebar or click the Auto button in the Prompt to automatically pay the mana cost using available mana sources if possible.
- The Auto button will be disabled if you cannot pay the mana cost at that time, in which case Enter/Spacebar will cancel the spell/ability instead.
- Uses the same logic the AI uses to pay mana costs. This means it will try to use mana in your pool before mana sources in play, using colorless mana to pay the colorless part of the cost if any is available.
- You can still manually pay the cost by clicking mana sources in play (e.g. lands) or clicking symbols in your mana pool, which might be a good idea if you want to save specific mana sources for a later play that turn.
You'll no longer be prompted for attackers if you have no creatures that can attack.
You'll no longer be prompted for blockers if you have no creatures that can block any attacking creature.

Great job on the Auto button, I love it! So far so good!
Also, auto-skipping unnecessary combat phases seems to work fine so far and makes the game phases somewhat faster.

- Agetian

What does that method runAsAi in PlayerController mean to do?

If you want any actions to be performed by AI on behalf of human, care to move these above the level of playercontroller. (even better to move these out of forge.game package)

Just another point: consider this PlayerController class to be an interface to remote player, connected to your game over network. So how are they supposed to execute any Runnable you are passing as parameters?

--Moving this conversation here, because I didn't want to spam the features request thread.

drdev wrote:To clarify, Enter/Space simply activates the button with focus in the prompt. It has always worked like this. Enter/Space will only Cancel when Auto is disabled because you can't pay the cost, and therefore Cancel has focus, which is exactly how it worked before when paying mana costs. It's just that now, if Auto is enabled because the cost is payable, then that button will receive focus instead and Enter/Space will activate it. Does that make sense?

Right, the focus is on "auto" when it used to just always be on "cancel" (since Auto didn't exist, and there are generally no other choices here) which I think might be confusing. If we want Auto to have a key-shortcut, I don't think it should be tied to something that people are already accustomed to.

"Oh shit I clicked on my Oblivion Ring instead of my White Knight, let me cancel. <Space> Oh shit, it just auto-cast Oblivion Ring"

friarsol wrote:--Moving this conversation here, because I didn't want to spam the features request thread.

drdev wrote:To clarify, Enter/Space simply activates the button with focus in the prompt. It has always worked like this. Enter/Space will only Cancel when Auto is disabled because you can't pay the cost, and therefore Cancel has focus, which is exactly how it worked before when paying mana costs. It's just that now, if Auto is enabled because the cost is payable, then that button will receive focus instead and Enter/Space will activate it. Does that make sense?

Right, the focus is on "auto" when it used to just always be on "cancel" (since Auto didn't exist, and there are generally no other choices here) which I think might be confusing. If we want Auto to have a key-shortcut, I don't think it should be tied to something that people are already accustomed to.

"Oh shit I clicked on my Oblivion Ring instead of my White Knight, let me cancel. <Space> Oh shit, it just auto-cast Oblivion Ring"

The Auto button is essentially the confirmation button that you want to pay the mana cost, much like how the "OK" button is used for other things. As such, I think it makes perfect sense that it use the Enter/Space shortcut. It's also much faster that way as you can basically just use Enter/Spacebar and a few clicks to easily cast a spell or two, attack, and end the turn, which is what most of your turns will look like. Having to switch between Enter/Spacebar and another key or shortcut would not be nearly as user friendly.

Might I suggest we make the Escape key always trigger the Cancel button regardless of whether the OK button is enabled. That way, people will have a button that will always trigger Cancel and can retrain themselves to use that rather than Enter/Space for the purpose of cancelling a mana payment. It's also more inline with how other programs work.

If it helps, I'll add a setting that will focus Cancel instead of Auto by default so Enter/Space will work as before, but I doubt many people will use that setting. I could also add a setting that would add a second prompt after pressing Auto to either OK what mana sources were used or Cancel, which would give you the chance to undo misclicking Auto or not liking the way Auto chose to pay the cost. Just let me know what would help.

Thanks.
-Dan

Max mtg wrote:What does that method runAsAi in PlayerController mean to do?

If you want any actions to be performed by AI on behalf of human, care to move these above the level of playercontroller. (even better to move these out of forge.game package)

Just another point: consider this PlayerController class to be an interface to remote player, connected to your game over network. So how are they supposed to execute any Runnable you are passing as parameters?

The point of runAsAi is to run a procedure for a player using a PlayerAiController, even if that player is human. For PlayerControllerAi, it just runs the procedure with no other changes needed. For PlayerControllerHuman, it temporarily sets its controller to a new PlayerControllerAi instance, runs the procedure, then restores the original controller.

It made the most sense for this to live on the PlayerController interface so the behavior could be easily different based on the current type of controller for the player.

As for your concern about remote players, I would image their implementation of runAsAi would match PlayerControllerHuman. Given that, would you prefer I remove runAsAi from the PlayerController interface and refactor runWithController in the Player class to be called runAsAi, not take a controller parameter, and only temporarily change the controller if its current controlller isn't a instance of PlayerControllerAi? I'd be ok with that.

drdev wrote:It's also much faster that way as you can basically just use Enter/Spacebar and a few clicks to easily cast a spell or two, attack, and end the turn, which is what most of your turns will look like. Having to switch between Enter/Spacebar and another key or shortcut would not be nearly as user friendly.

I'm not particularly convinced that "Auto" being focused for Mana Costs and "Cancel" being focused for Targets is more user friendly than the same button always being focused.

I agree that a setting wouldn't really be useful here, but having the Escape key Cancel things may alleviate it. (Since we could then remove the Focus from any "Cancel" button)

friarsol wrote:

drdev wrote:It's also much faster that way as you can basically just use Enter/Spacebar and a few clicks to easily cast a spell or two, attack, and end the turn, which is what most of your turns will look like. Having to switch between Enter/Spacebar and another key or shortcut would not be nearly as user friendly.

I'm not particularly convinced that "Auto" being focused for Mana Costs and "Cancel" being focused for Targets is more user friendly than the same button always being focused.

I agree that a setting wouldn't really be useful here, but having the Escape key Cancel things may alleviate it. (Since we could then remove the Focus from any "Cancel" button)

Maybe I could implement an Auto button for targeting too, then the two prompts would be more consistent. I could see that being useful for the many cards or cases where there's only one available target (or only one that makes sense for effects like "target player draws two cards" or "target player discards two cards"), where it could avoid you needing to move your mouse to click on a player or card. The Auto button being disabled would also add an indication that there are no available targets, much like how it being disabled for Auto mana payment indicates the cost can't be paid. I could even implement an optional second prompt to confirm the targets chosen by the AI logic, similar to what I proposed above for Auto mana payment.

With the two Auto features together, the UI steps for casting Hymn to Tourach, for example, would go from

• Click Hymn to Tourach card in hand at bottom middle of screen
• Move mouse to opponent's avatar at top left of screen and click to select as target
• Move mouse to first Swamp near bottom left of screen and click
• Move mouse to second Swamp and click

to

• Click Hymn to Tourach card in hand
• Press spacebar to auto-select your opponent as the target
• (Optional) Press spacebar to confirm the target
• Press spacebar to auto-tap your two Swamps
• (Optional) Press spacebar to confirm how the cost was paid

One click and 2-4 keypresses is much faster and easier than 4 clicks that require moving your mouse to 3 different areas of the screen.

All that said, does Auto targetting sound like a desirable feature? Either way, I plan to add Escape as a shortcut for Cancel as discussed.

drdev wrote:Maybe I could implement an Auto button for targeting too, then the two prompts would be more consistent. I could see that being useful for the many cards or cases where there's only one available target (or only one that makes sense for effects like "target player draws two cards" or "target player discards two cards"), where it could avoid you needing to move your mouse to click on a player or card. The Auto button being disabled would also add an indication that there are no available targets, much like how it being disabled for Auto mana payment indicates the cost can't be paid. I could even implement an optional second prompt to confirm the targets chosen by the AI logic, similar to what I proposed above for Auto mana payment.

Does that sound like a desirable feature? Either way, I plan to add Escape as a shortcut for Cancel.

Could be useful, although I'm not sure where it fits in your large list of UI improvement priorities. Obviously the AI may not know how to Auto-target for all SAs, since that's part of what prevents the AI from being able to use it.

The way I'd picture this as being most useful for me in each of these scenarios is some type of highlighting/border-coloring for the card(s) that are about to be auto paid/targeted. That way you can glance to see what the Auto choice is before you actually select Auto Target, and change your course if what you want to do is something different. Of course, as you say, if the Auto button is disabled it will either mean "The AI doesn't know how to correctly do this" or "The AI doesn't think this is a legal move". I'd bet a card like Cadaverous Bloom would cause the Auto button to be disabled, even though it would still be possible for you to pay costs with it.

Escape for Cancel should at least fix my initial worries. I do think the Auto payment will be huge net positive.

That downside of highlighting what mana sources will be used or what targets will be chosen is that if you want to make a decision for yourself and not use the Auto button, you can't avoid seeing what the AI would choose in that instance.

I think a far better way is to add the second prompt to confirm the Auto effect after being able to visually see what mana sources or targets the AI chose. That also alleviates concerns of misclicking Auto or not liking what the AI chose, freeing you up to use Auto without fear that it will choose something you don't like. And if you're confident that the AI will choose correctly (such as if there's only one valid target or one way to pay the cost), then you can just double click Auto or press Enter/Spacebar twice in succession. I'll still add an option to disable this second prompt for power users that want even faster play, but I think I'll enable the second prompt by default. Even with the second prompt, you still avoid all the mouse movement between cards that is the real usability culprit and reason for adding the Auto button support.

As for your concern about effects the AI doesn't know how to do correctly, we'd still enable the Auto button in that case as long as there are valid targets so the user doesn't get confused, and we'll just show an alert if Auto is clicked indicating that the AI can't pick the targets for X reason.

How does this plan sound to everyone?

Actually, on further thought, rather than needing a second prompt for both auto-targeting and auto-mana payment, I'll just add a single additional prompt after both targets are chosen and mana is paid to confirm the spell or ability immediately before its put on the stack. I'll then make a single setting with the following options regarding under what condition this prompt is shown:

• Always
• If either no prompt or Auto used for final prompt (default)
• Only if no prompt
• Only if Auto used for final prompt
• Never

This way, the prompt is not unique to the use of the Auto button, and it solves a usability problem I've wanted to address by providing a way to cancel non-mana abilities for cards that don't prompt for targets or mana payment, such as : Gain 5 life. It different setting options give power users the ability to avoid this prompt completely, while protecting against mis-clicks for everyone else.

Sound good?

@ drdev: I like the fact that I can simply hit Space/Enter to do the Auto tap. If I had to switch focus or use my mouse to click the Auto button I think I'd hate the thing for being too slow. Anyhow, I agree that using Escape to cancel sounds like a reasonable feature proposal, and your idea with an extra configurable prompt sounds like a plan, too.

- Agetian

First of all, the feature of auto payment of mana cost is doubtful. As for me, the target selection and tapping lands for mana is core game experience that should never be automated. It would be nice to highligh valid choices in that cases, but never do the choice for human.

Now, to implementation:
playAsAi - unsiutable for playercontroller. Moved it to base class InputPayMana.

drdev wrote:and only temporarily change the controller if its current controlller isn't a instance of PlayerControllerAi? I'd be ok with that.

That controller substitution is also somewhat... odd, but I din't figure out how to achieve the same effect in a different way.

Evaluator<T> - there is already guava's Supplier<T> class for that purpose. However, if you really need it to be Runnable and to keep the return value inside that class, then you'll probably need a separate class (that inherits Evaluator<T>, for convinience, to have a chance to use guava's methods)

ManaCost.getCostString() - drdev, first you've changed the default behaviour how ManaCost is converted to string, and now you have to revert it for some cases. It would be much better if you restored the old way how getSimpleString worked (it returned shards separated by spaces and without brackets) and then, on consumer's side you could wrap this string into curly braces and replace spaces with "}{" character sequence. The core class would be cleaner then for having a single (and simpliest) toString method
It's always a bad practice to keep all that sorts of formatting in model class (good, you haven't yet yet added methods to produce html-formatted mana cost and a json representation of mana cost to transfer it somewhere else) This is the sort problem they are solving with patterns like MVVM or MVC. Even java itself has DateTime class and aside all possible means to represent the data as string in a class named DateTimeFormatter.

Max mtg, I'm sorry you doubt the appeal of auto mana payment, but I can tell you it's a very sought after feature by many, including myself, who would rather not have to manually click a card or mana pool icon once for every single mana in the cost of each spell/ability. If you don't want to use it, you don't have to.

I can look into Supplier<T>, but I created Evaluator<T> so I'd have a simple way to capture a return value from a Runnable in the many places that ask for a Runnable with Forge's codebase. I don't really see the harm in such a class existing.

As for getCostString(), I would argue the toString() ManaCost really should be of the form "{G}", since that's what it looks like in all Strings containing mana costs and other text, such as spell descriptions. toString() is also used more commonly that getCostString() right now, so for performance it makes sense that the extra replace operation should be on the less common case. Also, now that I see the purpose of getCostString() in the places now calling is to create a string that can be re-parsed into a new ManaCost or ManaCostBeingPaid object, it's worth noting that that didn't even actually work before in the cases of hybrid and phyrexian mana, since something like "3 GU" in the script would output as "3 G/U" from toString().

My current plan is to enhance the replace operation used by getCostString() to fix the bug with hybrid and phyrexian mana to ensure "G/U" is properly converted back to "GU" and "G/P" is properly converted back to "PG", but otherwise leave it as it stands.