Managing actions requiring input from other players

[zetaLeonis]

I'm new here and still learning, so apologies if this question turns out to be basic and or silly.

In the game I'm coding, the active player can perform various actions, most of them are straightforward but in some cases, their action requires input from another player.

For example, during a move action, if the active player wants to move their pieces past another player, they can but they need to "ask for permission." Another example is during combat: after the attacker rolls the dice, the defender rolls as well. If the defender is unhappy with the result, they can spend resources to re-roll (even though it's not their turn).

So, my question is: how do I handle actions where another player's input is required during the active player's turn?

I believe the solution lies in the states.inc.php file, but I'm not sure how to implement this. Any guidance would be appreciated!

[imralav]

You are correct about needing to work with states.inc.php.

I believe you will need to introduce additional states for the other players to make their move. So Player 1 initiates some longer process, invokes an action, the action then transitions to another state, where another Player 2 is activated.

[thoun]

You can check how other projects managed similar things. I think Exploding Kittens has a Stop card requiring this kind of action.

[zetaLeonis]

You can check how other projects managed similar things. I think Exploding Kittens has a Stop card requiring this kind of action.

Thank you both. Indeed exploding kittens has something akin the problem I'm trying to solve, this is a snippet of the states.inc.php

Code: Select all

// ... a bunch of code before ...
$setupStates = [
    ST_PLAYER_TURN => [
        "name" => "playerTurn",
        "description" => clienttranslate('${actplayer} must take their turn(s) (${nrOfTurnsRemaining} turn(s) remaining)'),
        "descriptionmyturn" => clienttranslate('${you} must take your turn(s) (${nrOfTurnsRemaining} turn(s) remaining)'),
        "args" => "argPlayerTurn",
        "type" => "activeplayer",
        "possibleactions" => [
            ACT_PLAY_CARD,
            ACT_END_TURN
        ],
        "transitions" => [
            "goToPlayerTurn" => ST_PLAYER_TURN,
            "favor" => ST_FAVOR_SELECT_PLAYER,
            "cardPlayed" => ST_PLAYER_REACT_START,
            "endTurn" => ST_PLAYER_TURN_END,
            "stealCard" => ST_STEAL_CARD
        ],
        "updateGameProgression" => true
    ],

    // ... a bunch of code in the middle ...
  
    ST_FAVOR_SELECT_PLAYER => [
        "name" => "favorSelectPlayer",
        "description" => clienttranslate('${actplayer} must ask a FAVOR'),
        "descriptionmyturn" => clienttranslate('${you} must ask a FAVOR'),
        "args" => "argFavorSelectPlayer",
        "type" => "activeplayer",
        "possibleactions" => [
            ACT_FAVOR_SELECT_PLAYER,
        ],
        "transitions" => [
            "" => ST_PLAYER_REACT_START
        ],
    ]

    // ... more code ...

];

Long story short: the first action (by the active player) transitions in another action that can ask another player for something, and then that player takes command, then returns to the original player. I still trying to understand the code but that's the gist.

[thoun]

You can have multiple ways to handle that :
- use only single player states, you need to remember the real active player id, and change back and forth
- use multiple player states for actions from others than active player. A multiple state where you will activate only one player, the one you wait an input from. That's the solution I use because it keeps the active player "real".

[imralav]

You can have multiple ways to handle that :
- use only single player states, you need to remember the real active player id, and change back and forth
- use multiple player states for actions from others than active player. A multiple state where you will activate only one player, the one you wait an input from. That's the solution I use because it keeps the active player "real".

I am not clear on what you mean by keeping the active player "real" in the multiplayeractive state approach. Would you please elaborate on that point?