Turn Order Customizations

[nicolodavis]

EDIT: Closed in favor of #477 and #478.

• setActionPlayers option that allows others to play, but following a turn order (not simultaneously).
• Retire the Pass move. It's better to just document a pattern on how to implement passing or convert it to an event.

[Stefan-Hanke]

OK, let's assume we've got a Dominion implementation and want to make Militia work. For this, we'd need the first bullet point. As far as I've understood the new API, we'd need an event that must currently be directly implemented in FlowWithPhases, since there is currently no possibility to have events defined by a Game.

If that event existed, a game could dispatch a call to it which would be triggered during the update call. That event (changeActionPlayers or something like that) would need the actual players that ought to perform a move.

Did I get anything wrong?

[nicolodavis]

Yes, that's correct.

[Stefan-Hanke]

Since this allows concurrent state modifications, we'd need a way to reconcile state on a client with one that is synced. I don't know whether it's a good idea to let the game handle that process?

Sidenote about order of players to take actions: Actually, Dominion must enforce an order of action players since in case of that Militia, dropping cards could trigger e.g. Marktplatz (don't know its english name), which may give you a Gold, which you don't when the pile is empty. So it's not the best example to choose... sigh.

[nicolodavis]

What concurrent state modification are you referring to?

[Stefan-Hanke]

The kind of modification where two states need to be merged somehow. E.g. two players simultaneously click on Drop Card, or one player is selecting cards to drop whereas the other one already has selected etc.

[nicolodavis]

That's already taken care of via the stateID mechanism is it not?

[nicolodavis]

An unsynced client cannot make a move basically.

[Stefan-Hanke]

Ah, maybe I don't know the specific multiplayer implementation. I'd like to avoid the case where one player loses part of his move because another is faster and comitted his...

[nicolodavis]

That will only happen if the user plays before the update caused by the other players reaches them, i.e. will only be seen if there is noticeable network lag. Maybe we can build a mechanism in the future to perform a true merge, so that an out of date client can be usable in some cases, but this is what we have right now.

[nicolodavis]

We might have to provide a hook to allow the game developer to specify how the stateID should change, and they could use a major.minor version system to indicate which state updates break old clients and which ones can tolerate a move from a client that hasn't seen the most recent state.

[titanxxh]

The Events API is still under development? No docs for it, right?

[nicolodavis]

There is a pending PR to add some documentation. I'm just waiting to get some time to add some interactive examples as well before I get that in.

[titanxxh]

Actually, I have a question about the best case for Phase. I’d like to know which one below is the best practice?

1. Game is divided into different phases. In each phase players can take their turns one by one. For example, Agricola game can have setting, drafting, round, harvest... phases.
2. The turn of a player can divided into small phases. Let’s take Agricola for example again, one can do many Moves before he confirms to end his turn. He can click the “Plow and Sow” action, then enters into a “Plow” phase, in which he can only plow a field on his farm space or undo his decision or confirm to end this “Plow” phase. After that, he enters a “Sow” phase.

Or we should not mix the two concepts into “phase”?

[nicolodavis]

The idea was to allow both use cases independently. endPhase and endTurn just transition the state into a new phase or turn. This has led to some confusion, so we could rework it a little bit. It could also be fixed with better documentation, which we should do anyway.

[nicolodavis]

@titanxxh An easy way to fix your problem would be for the framework to not accept endTurn from any player other than currentPlayer.

[titanxxh]

But this will not solve the endPhase triggered in one player's moves problem.

[nicolodavis]

But that's actually necessary in most cases (and in your case it doesn't actually matter if we don't allow the subsequent endTurn, correct?).

[Stefan-Hanke]

Ad retiring Pass: do you have any specifics in mind? It looks like a useful turn order implementation.

[nicolodavis]

Now that we're storing stats about who has played this turn / phase, and even exporting bits like allPlayed, I'm wondering if we should just document a simple pattern on how to implement passing.

The other option would be to make it an event, but I'd like to limit the number of events if possible (i.e. let's go this route only if it's that much simpler to use over implementing your own).

I don't have a clear idea of which option is best yet, so we have some exploring to do.

[nicolodavis]

Closing this in favor of #477 and #478.