Library contracts

[johnameyer]

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 Game manager implementation #47
• Can we wrap more common functionality/boiler-plate into a class?
  • Considered in Game manager implementation #47
• Can we add a test to make sure everything is exported and proper?
  • Considered in Game manager implementation #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?
• 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?

[johnameyer]

Current implementation thoughts:

• New generic class called GameManager in core which contains the common functionality
• Every package exports an instance of GameManager, and removes the other components from being exported
• Generally we want the onus of more complicated functionality to be on the less-implemented components, e.g. creating a new presenter, handler, or new game should be as simple as possible