Allow multiple gametypes on the same server

[jkomoros]

Delegate.Name() should return something short and distinct, like "tictactoe" or "tickettoride". Delegate.DisplayName() returns what .Name() returns today. Unique, but pretty.

/api/new/game returns the game ID and its gamename so we can redirect correctly.

NewServer(takes multiple managers. When installed, each one is interrogated for its shortname) to hook those points. They should all use the same storage.

The rendering has /game-src//main-element

[jkomoros]

The hardest part is figuring out how to multi-plex /game-src/main-element

[jkomoros]

At some point in server we need to dispatch to the right manager based on type name.

This will be much easier to play around with and make work once we actually have two example game types.

Then we'll create an examples/metaserver that imports multiples.

[jkomoros]

Should we include the gamename in the URL? It is useful for people to see in the url they share with friends, and it would allow the route to extract which game renderer to load.

Then just gutcheck the name that comes back with the game is the same the route thinks it will be.

[jkomoros]

How do I make it so that it can fall back on rendering default content?

Maybe have a render-game-view that does the importHref, but renders default content before that loads.

Also note that if we have more fragments to load, we'll need to list more of them in polymer.json

[jkomoros]

• [x] The way we render gameURLs for API should also use UrlForGame()
• [ ] New game form renders a select if multiple managers are enabled (reverts to hidden form if only one)
• [x] NewServer takes (storage, ...GameManager)
• [x] Fix the terrible hackiness where server.ListGames() passes a random manager (gross!) (also doesn't work--the game is rejected if the name doesn't match). Do something with interfaces and a GameStub.
• [ ] Game-view shoudl show a loading indicator until the renderer either fails or suceeds
• [x] Create the multiserver example to stress test having two servers
• [x] game-view takes the name of the renderer and fetches it dynamically. In the meantime, it simply renders Diagram until the other thing is instantiated.
• [x] Pass state and diagram to the game-renderer
• [x] Get state and diagram live-updating in the instantiated game-renderer (something like newElem.addEventListener('prop-changed', _=>{ this.parentProp = newElem.prop }) )
• [x] make sure that we don't stamp multiple copies of game-renderer each time we switch back to it (we're just doing appendChild and not replacing)
• [x] boardgame-render-game moves from game-src to src
• [x] Update README about game-src, overridding options, etc.

[jkomoros]

This is actually now done now that we've captured the two remaining minor things in the two new issues.