Boardgame.io: moveLimit syntax inside setActivePlayers

[nicolodavis]

I'm not the biggest fan of having a parallel structure inside moveLimit:

setActivePlayers({
  player: 'A',
  others: 'B',
  moveLimit: {
    player: 1,
    others: 2,
  }
})

How about we support the following instead:

setActivePlayers({
  player: { stage: 'A', moveLimit: 1 },
  others: { stage: 'B', moveLimit: 2 },
})

This is also consistent with how we do it in setStage (you can either pass a single string which is treated as a stage name, or an object containing the stage and moveLimit).

[delucis]

@nicolodavis I could definitely get behind this. Should a simple moveLimit option still be supported?

setActivePlayers({
  player: 'A',
  others: 'B',
  moveLimit: 2
})

[nicolodavis]

Yeah I think let's continue to support a simple integer for moveLimit as well.

[delucis]

I’m having a go at this and here’s one other consideration: currently moveLimit allows a value field like setActivePlayers, which sets _activePlayersMoveLimit directly and supports more complex configurations.

setActivePlayers({
  value: {
    0: 'A',
    1: 'B',
    2: 'C'
  },
  moveLimit: {
    value: {
      0: 2,
      1: 3,
      2: 1
    }
  }
})

How could we support that behaviour when moving moveLimit alongside stages?

[delucis]

One option would be to refactor the value API itself:

// involves adding a somewhat redundant activePlayers key
setActivePlayers({
  value: {
    activePlayers: {
      0: 'A',
      1: 'B',
      2: 'C'
    },
    moveLimit: {
      0: 2,
      1: 3,
      2: 1
    }
  },
})

or

// involves removing the directness of the current value API
setActivePlayers({
  value: {
    0: { stage: 'A', moveLimit: 2 },
    1: { stage: 'B', moveLimit: 3 },
    2: { stage: 'C', moveLimit: 1 }
  },
})

[nicolodavis]

I think we have two options here:

1. Don't support it

I can't think of any games that require such a complex configuration of move limits. Maybe people should use a series of setStage calls instead? (I don't think we support changing state for another player in setStage yet, but it's easy enough to add a playerID parameter to it that's set by the caller).

2. Use the same pattern we use elsewhere

It sounds like we're standardizing around certain fields that can be either:

• A string, in which case they are interpreted as a stage name.

• An object, in which case they can contain other things like moveLimit etc.

[nicolodavis]

I think we both said the same thing at the same time (Option 2 in my reply) :)

[nicolodavis]

Just to clarify, I don't think we'd be removing anything from the current API. We are just extending the value syntax to also support objects in addition to stage names. Is that what you were thinking also?

[delucis]

Just to clarify, I don't think we'd be removing anything from the current API. We are just extending the value syntax to also support objects in addition to stage names. Is that what you were thinking also?

Yes exactly. Ok, that looks like the best choice to me too. I think the main use case for this kind of thing would be player-specific move limits derived from game state (dice rolls, territory controlled, card played, etc.)

[nicolodavis]

OK great, let's do that then.

[nicolodavis]

Separately, I realized one difficulty in defining the semantics of setStage and setActivePlayers.

The concept of playerID only makes sense when a specific player calls this event directly or inside a move.

However, you can also call the event from inside a phase's onBegin for example. There is no concept of a turn or a currentPlayer at this point yet. We should probably prevent the event from being called in such situations (or log an error).

[delucis]

Oh right. When setActivePlayers is called with turn.activePlayers, playerID is already set to currentPlayer though, right?

[nicolodavis]

Yes, but only because we pass in currentPlayer explicitly to the call.