While most of the state is now in a form that is serializable, the part tied up in the game driver async/generator is not. Some sort of state machine should be created to allow this to be preserved.

As identified in #42 , the current setup works well but requires every concrete handler implementation to re-implement the message function and all future systems. Since this functionality also falls into classes e.g. bot discards messages, intermediary handler sends it to the intermediary, e.t.c. we should be able to break these up using an entity-component-system-type setup.

Might be useful at some level to just generate the diffs that responses from users or general game flow cause. Possible use might be to send only the change to users, or not send to users at all if nothing has changed from their perspective.

Penalties should be less severe - don't slap the user with their entire hand if any of their plays are invalid
Should objects be recreated to make sure there is no object modification used to work around the checks?

yargs is conflicting the '-n' of the name setting with '-n' of max rounds.

As the library has generally settled and common usages known, we should consider the higher form of the library as we look towards a 1.0 release. (This is a high level issue and doesn't contain anything specifically actionable, actionable tasks will be linked)

Things to consider:

• Do the StateTransformer and ResponseValidator classes need to be exported? Would there ever be a case these would be overriden?
  • Considered in #47
• Can we wrap more common functionality/boiler-plate into a class?
  • Considered in #47
• Can we add a test to make sure everything is exported and proper?
  • Considered in #47
• Can we add hooks to the driver class to support open/close principal?
• Can we decide how to handle the higher level abstractions and common functionality of the game like names and chat?
  • Moved to #60
• Can we clean up the ideas of sync vs async handlers and the queues?
• Can we make the handler <> intermediary <> presenter nicer and fallback if operations are not supported?
• Can we add a built-in package lookup/import by game type?
• Can we avoid including the web presenter/remove dependencies on console libraries?
• Can we break out the state from being passed in the handler methods?
  • Nope, but we can change a protocol so that it is only sent before a change.
• Can we make the game state iterator FSMs less verbose, more declarative? Redux-esque architecture perhaps?
  • Moved to #113

Currently presentable (things we should print to the user) is used in place of what should be serializable (things we know by default how to convert to/from JSON), and preferably the former should be a subset of the latter. The deck for example should be serializable but not presentable.

Add mechanic for setting up a game before launching it to the framework

Ref #104

Rather than having a flat state for each game, refactor common functionality into separate components that can be chosen arbitrarily by games. Consumers should be able to expect a subset of the state (e.g. only {messages: MessagesState}). As well, use controllers to wrap each component so that only expected operations are performed and the state remains consistent.

Upload pre-existing code but decide how to structure project

Currently, a game loop will continue completely until it is done. Ideally, in a hosted scenario, there should be a mechanism by which the awaits for user decisions are abstracted so that user action is not actually waited upon.

Currently @cards-ts/hearts doesn't override fromStr in state-transformer when it should - leading to other errors when that is used.

Would be ideal for the platform to support sending of chat messages of some form and implementation of how that would look for the 'intermediary'.

Currently, the handlers and intermediaries use a system of returning a promise to indicate that the data has been sent wherever, and uses the response queue to push promises or synchronous results. However, this doesn't particularly make sense for Euchre, as the intermediary has two distinct sends (maybe a generator at the intermediary level?). As an initial implementation, we may just clear up the ordering of events or prevent the game from continuing before all grouped events are processed (and remove the undefined event for Euchre).

Game packages should include some kind of mechanism to simulate the game and prompt the user for certain actions

As a player, when another player puts cards on the table, I want to be notified

As outlined in #42 , there isn't a real pressing need to have the ResponseValidator, StateTransformer, or GameStateIterator broken out as separate components in the exports. As such there should be a 'GameManager' class that contains the logic to instantiate those components as well as use them in the common paths. As well, we can then add a 'test' (typescript type assertion) to check the types.

Noticed in the most recent release that built changes from a PR branch were published on the main branch, which should not be the case. Need to verify if incremental build will always attempt that or whether we will need to clean before building.

Currently there is not a good separation of concerns between the game and main files.

Implementation of the game 'war.' Not very interesting to play, but good to have from a testing and demo stand-point.

Today, we encapsulate handler data inside of each and every message type which is quite repetitive across the structs as well as the relevant handlers and validators.

Ideally the data would be brought out to a new struct encapsulating the message

Ideally as a part of making this change we could clean up how the handlers process this data - namely allowing them to have strict typing through generics

Lerna has caused a number of headaches due to:

1. it publishing to git before actually publishing to npm / building packages
2. it using the global typescript over the locally installed one (e.g. lerna run prepack works fine

along with others, causing around a 50% success rate when trying to publish a new version.

We should also try to move away from local publishing and towards publishing in a Github action.

The names mechanism was removed in order to support the shared interface of all the Handlers methods but should be added back in a event-cognizant manner.

It should be possible to make the engine generic, to make an easy template for implementing other card games.

Support of limiting a waiting period on an action and default handler in that scenario.

Would be useful for Mafia or others

Support sending a message once a player has completed an action, regardless of if the group has.

In war, for example, there is no harm to saying what the player flipped over while waiting on the opponent.

Will have to involve modifying the checks of when the iterator runs or moving message functionality out of there entirely.

In can-i-have-that you can say you want a card even before your turn. This is not currently supported by the game, but the data should be stored and waiting updated based on that.

Inquirer allows us to cancel our prompts so we will likely model our other promises after - https://github.com/SBoudrias/Inquirer.js?tab=readme-ov-file#canceling-prompt

Max score defaults to 100 instead of 10 - see

As identified in #62

• Can we make validation more declarative - i.e. type matchers on fields, then high level validation if need be
  • hasCard
• Can we sharpen up our event validation the same way we are for states? Length checks, type checks, etc.
• Potentially implement message-type expectation validation (e.g. at this stage we are expecting only certain events
  • This may live better as a larger scale task about also clarifying the ordering of events, async ness, etc.
  • Moved to #125 / #113

Interest had been expressed in an online form for playing mafia and this is well within the capabilities of the platform.

The 'whose-turn' designation should not be managed by the individual libraries, but instead wrapped into the larger frame of the 'waiting on player' concept.

Example:
If a library needs every player to respond, then the naive implementation of the current whose-turn would be to say that it is waiting on everyone. To be more accurate, the incoming responses would need to filter through this mechanic to update. This is shared functionality and so it should be supported on a higher level.

As a user, if my hand was entirely live after I had gone down, the game should give me a way to play on others.
As a user, if my hand was entirely live and I can't go down, this should be handled somehow (grabbing cards from the deck until not live? simply ending the round there?)

Implementation of Euchre

The can-i-have-that TurnResponseMessage can be broken up into multiple segments since the player naturally only does one at a time and this would reflect real play better.

Of course the discard message is what signifies that the turn is over.

Checking should be done on played to make sure that only valid is applied
Should not be able to discard live cards

For certain games, it might be nice to identify a formatting setting that might, for example in hearts, visually identify cards that give points.

https://en.wikipedia.org/wiki/Durak

There should be tests to make sure that the bots can follow the rules in a majority of scenarios, finish the game, do not take too long with their turns, and perform significantly better than a random bot (i.e. a bot that makes valid choices randomly).

Allow for messages to contain references (like the player's name) for things that can change over time / be processed separately.

Support for other languages when using hard-coded strings.

Since most of the state transformers just use JSON stringify and parse under the hood, we can move that up to the parent class and have children only override to/fromObj.

The base intermediary class should support 'advanced' components by breaking them down to the user as a composite of simpler components. That way, when a new component is introduced, it does not have to be supported by all the intermediaries.

Game packages should vend some sort of metadata e.g. description, type of game, number of players

For libraries that are game implementations (e.g. hearts and can-i-have-that, not core), there should be a (package) test that ensures that a minimum set of members are exported that would make it possible to be run (by the framework or on a server) in a game-agnostic manner. As well, the test should make sure that the game can run through to the end using the default bots.

As a user, I would like to have some control over how the game is set up
E.g. smaller deck, different point values, different bots, e.t.c.