GameDeelgate().Name should exactly equal the package name

[jkomoros]

Lots of things assume that. Document that's true. Also, should the default Name() method generated by stub use reflection (memoized) to detect the name of the containing package?

[jkomoros]

Add this, with a stuboptions.SuppressAutoName.

Fix #576 first, so that auto-generated displayname works.

[jkomoros]

• [x] NewGameManager should do one-time reflection to verify the name of the delegate matches the package name, and error if it doesn't (unless the import is github.com/jkomoros/boardgame)
• [x] gamepkg.Name() should clarify it's the name according to the package name, but that the core engine will barf if they don't match so it's a good assumption
• [ ] document in documentation that Name() needs to exactly equal the package name (and why... which includes researching why that is)
• [x] Create an auto-name code in e.g. memory to make sure it works
• [ ] update stub to have SuppressReflectedDelegateName, which is not false outputs the given name

[jkomoros]

Why does the game name have to not have "-" and ""? The go spec (https://golang.org/ref/spec#PackageName) says that package names can have "", even if that's non-idiomatic according to https://blog.golang.org/package-names.

The package name shows up in the name of the client renderer and player info, and it's weird to have "_" show up where "-" is more typical for URLs.

Perhaps could allow "_" to be rewritten to "-" canonically (although it would get confusing at various points on which one you had. logic would likely be in gamepkg

[jkomoros]

The central difficulty is that package names need to be all one word (although they can, non-idiomatically, have "_" in their names), but there's nothing that verifies that the reported game name via the package name and the name returned from delegate.Name() are the same, because one can be detected statically and one can only be detected at run-time. (Is there any check currently?)

The run-time one is used to report down to the client what the name of the game is, which includes which renderer to fetch (at /game-src/GAMENAME/boardgame-render-game-GAMENAME.js), where the former GAMENAME is written out by static.Build() based on the static package name, and the latter is encoded in the filenames of the client files by the author of the package, and where to look for it is encoded in the delegate.Name(). All of those have to match.

The one benefit of allowing "_" in package names is that that makes Auto Capitalization Logic for gamename easier to write. But that's pretty minor in the grand scheme of things and not worth the extra complexity.

[jkomoros]

If we really wanted to allow games to have _ in them, then there'd need to be a conversion step in gamepkg.Name() that transforms "_" to "-" immediately, and then ensure that delegate.Name() returns the same name by doing the same transformation of the package name, and then just almost everything would assume that the canonical name is actually the variant with "-". If that were the case than delegate.DisplayName() would have to handle splitting at "-" and title casing word boundaries

[jkomoros]

Yeah, just have all of them be no-gap names, and have NewGameManager use reflection once to verify delegate.Name() matches.

[jkomoros]

Actually, forgot to do the SuppressReflectedName