[ADVISED] Advise needed for specific JS Behaviour

[Badguizmo]

Hello (again) !!

I am facing a "conception" problem.
In the card game "Riftforce" one of the 3 phases is "Activation" :

1. You discard one card from your hand in order to activate 1 to 3 card.
2. The possible "activatable" cards depend on the value and/or the guild (4 for each players) of the discarded card
3. The activated card uses its own guild special power ability

Most of the guild special power is "deal damage to opponent card XXXX" but one of the guild ability is "deal damage and Heal a card".

What I do in JS

• Depending on the discarded card, I add a class "card-possible-activation" for each card matching the value and/or guild. This class is associated with a CSS class that "purple outline" the cards available for activation.
• Then, when I click on a card, some triggers right away the power (because the target is by design the first opponent card) but some have to target some other cards. I highlight these other cards with a "orange outline"
• Everything is, for the moment, working (don't worry you will have all the time during alpha to find bugs ) but I face a problem when I have to heal a card

My "player steps" are :

1. select a hand card
2. validate by clicking on a button ==> then JS highlight in purple the available cards
3. click on a board card

And there is my problem
if he clicks on a card that will propose to heal some other self card, it may happens that a same card can be activated and healed

One solution could be to disable all activable cards as soon as one is clicked. But this behaviour implies "no missclick" by the players (or create another button to cancel).
Another one is to rework the activation phase with button to validate the selected card, but as you can activate up to 3 cards, that is a lot of button
Or maybe a button only for the healing activation ?

For example, the 2 images below show
- 7 of Air is discarded, so 7 of Thunderbolrt (left one) and 7 of Light (right one) can be activated (purple outlined) https://imgur.com/a/9VULEdH
- 7 of Light have been clicked, as this Guild (Light) can heal 1 damage, the possible target is the 7 Thunderbolt https://imgur.com/a/vjwK2bU

But the 7 Thunderbolt have 2 events listeners
- Self Activation
- Light Target

is there a "clean" way/advise to deal with this ? Even if this means rework part of the implementation

[robinzig]

Not sure I'm very well qualified to give advice, given that:
1) I'm not familiar with the game you're adapting
2) I'm new to BGA framework myself, being a few weeks into my own first development - and far from sure I'm "correctly" following all the BGA user-interface guidelines

However, with those qualifications - my thoughts would be that, as a user, I would expect to see the "light target" card(s) highlighted in a different colour to indicate that these are my choices for what to target. As far as event listeners are concerned, you could just have one that first checks if the card has a particular CSS class - if it does have the one indicating that it's a "light target" then do that action, otherwise do the "normal activation".

As for the possibility of misclicks, I would think that's not a big deal - an undo button seems fine to me, as long as you've not sent anything to the server since selecting the initial card (which I don't see why you will have)?

[paramesis]

I wouldn't recommend removing and re-adding click event listeners based on the interface's next expected step. It ends up being pretty cumbersome, introduces the possibility for bugs that are harder to diagnose, and is harder to follow logically in the future, even if you're documenting everything extensively.

Instead, I would recommend defining a variable in your gameui's constructor that you can use to track information about the current interface step. That way, whatever function is handling clicking cards is able to logically determine what to do based on a context defined within the entire interface.

Code: Select all

        clickCard: function( evt ) {
            switch( this.next_step ) {
                case 'heal': {
                    // whatever happens when you heal a card
                    break;
                }
                case 'activate': {
                    // whatever happens when you activate a card
                    break;
                }
            }
        },

On recent projects, I've taken this concept to the extreme of having only a single function that handles all click events in the entire game area, which determines logically what to do from a few key variables (evt.target.id, evt.target.closest( '.card-possible-activation' ), this.gamedatas.gamestate.name, this.next_step, etc...) This is connected only once during the interface setup. After the interface is loaded, I never have to use dojo.connect, or dojo.disconnect, or keep track of individual elements with connected click event listeners.

[Victoria_La]

In this case you will have to do two steps and use client states or custom prompt override.
On step one you add class for active purple class.
When user select one, you remember that is (or add class "card-selected"), you remove class that highlighting them, change prompt and select the other set. Also add Cancel button
(nothing should be sent to server at this point).
Then user can select orange card or click cancel. Use that info + previously select purple card to send to server

See docs here https://en.doc.boardgamearena.com/BGA_S ... _Selection

[Tisaac]

I wouldn't recommend removing and re-adding click event listeners based on the interface's next expected step. It ends up being pretty cumbersome, introduces the possibility for bugs that are harder to diagnose, and is harder to follow logically in the future, even if you're documenting everything extensively.

That's funny because I would exactly advise the opposite ^^
I use 'this.connect' a lot in onEnteringState functions, to add event listener that clear off once I leave the state. That way I don't have any useless listener and always listen exactly to what I need. (In fact I even use a custom "onClick" function that also auto add the class 'selectable', and remove it when leaving the state).

And (one more time ^^) I would also advise the opposite of Victoria: I would send the first selection to my backend to avoid game logic duplication.
I would maybe group phase a) and b) in one state, but definitively separate phase c) to let my backend handle the flow.
(In this case you might indeed need an undo button if you are afraid of misclick).

In summary, one of my motto is "no game logic in js" (mostly to avoid duplication, as I love DRYed code), so I always try to cut my flow in atomic parts to make front/end interactions as simple as possible.
But that's not the only way to do it, there aren't really bad solutions so just pick one and go with it.

[Badguizmo]

Hello.
I knew there was no "simple" solution

Thanks for the different ways to do that.

I will complie that and come up with a solution in the few days, for the moment this specific case is not at the top of my list