Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setActivePlayers mode that allows cycling through players in order #478

Open
nicolodavis opened this issue Sep 27, 2019 · 4 comments
Open
Labels
Milestone

Comments

@nicolodavis
Copy link
Member

Right now we allow adding "all" players or "other" players to the set of active players (and they can make moves in any order). However, you might also want them to be able to perform actions one after the other (all inside the same turn).

@pardahlman
Copy link
Contributor

this is very interesting. I assume that this mode will cycle through the players in the play order, with the first player being whoever is next of the current player? I have modeled something similar in a MTG implementation, where the next opponent enter the stage HasPriority and other opponents enters AwaitingPriority. When leaving the HasPriority stage, the player also ends the stage (no longer active).

In my scenario, an opponent can make a move (cast a spell) that would reset the cycling through the other players (including the currentPlayer). Once no player is in any stage (that is, all player has had priority and "passed" it), the currentPlayer should be returned to its stage she was prior to this cycling. To solve this, I currently have to save the currentPlayer's current state, as it might have changed if an opponent did trigger a restart of the cycling. Perhaps there is a better way to solve this within the framework?

@nicolodavis
Copy link
Member Author

I assume that this mode will cycle through the players in the play order, with the first player being whoever is next of the current player

Yes, that's the idea. Your use-case describes the intention of this change almost exactly.

@pardahlman
Copy link
Contributor

pardahlman commented Mar 14, 2020

How would you keep track of the currentPlayer's original stage i case that an opponent triggers a new cycling through (in which case currentPlayer is moved to whatever stage other players are moved). One naive approach would be add this information to G, but that feels like setActivePlayer event is bloating the state...? 🤔

edit: just realized that there are properties on the stage that is not displayed in debug after the call to SanitizeCtx.

@delucis
Copy link
Member

delucis commented Mar 14, 2020

@pardahlman Yes, there are already some fields that track past/future state when using the next and revert options with setActivePlayers, so something similar could be used for this too.

A way to get something like this using next would be:

ctx.events.setActivePlayers({
  value: { '0': 'play'  },
  next: {
    value: { '1': 'play' },
    next: {
      value: { '2': 'play' },
      next: {
        // cycle done, reset to current state
        value: { ...ctx.activePlayers }, 
      },
    },
  },
})

When the player uses endStage, activePlayers would become empty and move on to the next player, but this doesn’t work for your case I think, because you have multiple players in stages and want to trigger the next stage configuration before all players would have ended their stage. And there’s no way to manually call something like endActivePlayers or nextActivePlayers to progress the game. Would an event like that help your case? Then you could generate a cascade of next values to configure the flow and call a simple event to trigger the next step.

You might still have to keep track of some state in G for returning to the original stage, depending on how many layers deep you need to be able to revert.


@nicolodavis Now that I’m looking at it, maybe it would be a nicer syntax if setActivePlayers could receive an array of arguments, where the first element sets the active players and the rest are used as a “next stack”. That would make it simpler to generate cascades like the above. It would also make it easier for users to operate on what’s coming next, e.g. if you wanted to trigger a cycle but then continue with whatever steps were already in _nextActivePlayers, because you could do things like [{ /* new step */ }, ...ctx._nextActivePlayers].

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants